How to Read an RFC

Mark Nottingham

recent entries<br>all entries<br>feed

Hi, I’m Mark Nottingham.<br>I write about the Web, protocol design, HTTP, Internet governance, and more. This is a personal<br>blog, it does not represent anyone else.<br>Find out more.

Comments? Let's talk on Mastodon.<br>@mnot@techpolicy.social

other Standards posts

The Nature of Internet Standards (series)

RFC 9518 - What Can Internet Standards Do About Centralisation?<br>Tuesday, 19 December 2023

RFC 8890 - The Internet is for End Users<br>Friday, 28 August 2020

How to Read an RFC

Tuesday, 31 July 2018

Standards

For better or worse, Requests for Comments (RFCs) are how we specify many protocols on the Internet. These documents are alternatively treated as holy texts by developers who parse them for hidden meanings, then shunned as irrelevant because they can’t be understood. This often leads to frustration and – more significantly – interoperability and security issues.

However, with some insight into how they’re constructed and published, it’s a bit easier to understand what you’re looking at. Here’s my take, informed from my experiences with HTTP and a few other things.

Where to start?

What kind of RFC is it?

Is it Current?

Understanding Context

Interpreting Requirements

SHOULD

Reading Examples

On ABNF

Security Considerations

Finding Out More

Where to start?

The canonical place to find RFCs is the RFC Editor Web Site. However, as we’ll see below, some key information is missing there, so most people use tools.ietf.org.

Even finding the right RFC can be difficult since there are so many (currently, nearly 9,000!). Obviously you can find them with general Web search engines, and the RFC Editor has an excellent search facility on their site.

Another option is rfc.fyi, which I put together to allow searching RFCs by their titles and keywords, and exploration by tags.

It’s no secret that plain text RFCs are difficult to read bordering on ugly, but things are about to improve; the RFC Editor is wrapping up a new RFC format, with much more pleasing presentation and the option for customisation. In the meantime, if you want more usable RFCs, you can use third-party repositories for selected ones; for example, greenbytes keeps a list of WebDAV-related RFCs, and the HTTP Working Group maintains a selection of those related to HTTP.

What kind of RFC is it?

All RFCs have a banner at the top that looks something like this:

Internet Engineering Task Force (IETF) R. Fielding, Ed.<br>Request for Comments: 7230 Adobe<br>Obsoletes: 2145, 2616 J. Reschke, Ed.<br>Updates: 2817, 2818 greenbytes<br>Category: Standards Track June 2014<br>ISSN: 2070-1721

At the top left, this one says “Internet Engineering Task Force (IETF)”. That indicates that this is a product of the IETF; although it’s not widely known, there are other ways to publish an RFC that don’t require IETF consensus; for example, the independent stream.

In fact, there are a number of “streams” that a document can be published on. Only the IETF stream indicates that the entire IETF has reviewed and has declared consensus on a protocol’s specification .

Older documents (before about RFC5705) say “Network Working Group” there, so you have to dig a bit more to find out whether they represent IETF consensus; look at the “Status of this Memo” section for a start, as well as the RFC Editor site.

Under that is the “Request for Comments” number. If it says “Internet-Draft” instead, it’s not an RFC ; it’s just a proposal, and anyone can write one. Just because something is an Internet-Draft doesn’t mean it’ll ever be adopted by the IETF.

Category is one of “Standards Track”, “Informational”, “Experimental”, or “Best Current Practice”. The distinctions between these are sometimes fuzzy, but if it’s produced by the IETF (see above), it’s had a reasonable amount of review. However, note that Informational and Experimental are not standards, even if there’s IETF consensus to publish.

Finally, the authors of the document are listed on the right side of the header. Unlike in academia, this is not a comprehensive list of who contributed to the document; often, that’s done near the bottom in an “Acknowledgments” section. In RFCs, this is literally “who wrote the document.” Often, you’ll see “Ed.” appended, which indicates that they were acting as an editor, often because the text was pre-existing (like when an RFC is revised).

Is it Current?

RFCs are an archival series of documents; they can’t change, even by one character (see the diff between RFC7158 and RFC7159 for an example of this taken to the extreme; they got the year wrong ;).

As a result, it’s important to know that you’re looking at the right document. The header contains a couple of bits of metadata that help here:

Obsoletes lists the RFCs that this document completely replaces; i.e., you should be using this document, not that one. Note that an old version of a protocol isn’t necessarily obsoleted when a newer one comes out; for example,...