How to Read and Understand Old Internet RFCs

RFCs (Request for Comments) are the internet’s original specification documents — genuine primary sources for understanding how foundational internet technologies were actually designed, in the designers’ own words, rather than through later secondhand summary.

Step 1: find the RFC index

rfc-editor.org → RFC Index

The RFC Editor maintains the complete, authoritative index of every RFC ever published, searchable by number, title, and keyword.

Step 2: start with a historically significant, readable early RFC

RFC 821 (Simple Mail Transfer Protocol, 1982)
RFC 1149 ("A Standard for the Transmission of IP Datagrams
  on Avian Carriers" — a well-known April Fools' RFC, useful
  as a gentle, genuinely funny introduction to RFC format)

Starting with a foundational, well-documented protocol you likely already understand conceptually (email, in SMTP’s case) makes the formal specification language easier to follow than diving into something less familiar first.

Step 3: understand the RFC numbering and status system

RFCs are numbered sequentially and never renumbered or deleted once published, even when superseded — an RFC can carry a status like “Standards Track,” “Informational,” “Experimental,” or “Historic,” which tells you whether it’s still an active specification or a preserved historical record of something no longer current.

Step 4: check for a “obsoletes” or “obsoleted by” note

Each RFC's header lists related RFCs it obsoletes or
  is itself obsoleted by

Since old RFCs are never deleted, checking whether a specific RFC has since been superseded is essential for understanding whether you’re reading the current specification for something or a preserved record of an earlier version.

The obsoletes chain is not a technicality — for long-lived protocols it is the protocol’s biography. HTTP/1.1 is the canonical example: specified in RFC 2068 (1997), revised as RFC 2616 (1999), rewritten as the six-document RFC 7230–7235 series (2014), then reorganized again into RFCs 9110–9112 (2022). All of those documents remain published and readable, and all describe “HTTP/1.1” — so knowing which generation you are reading, and why each rewrite happened, is half of understanding the protocol’s history. The IETF Datatracker (datatracker.ietf.org) renders these relationships as a browsable graph per document, along with authorship, working-group history, and errata links, and the RFC Editor’s errata database records verified corrections — worth checking before treating any specific sentence of an older RFC as gospel.

Step 5: learn the normative vocabulary before arguing about a spec

RFC 2119: "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", "MAY"
RFC 8174: only the UPPERCASE forms carry that meaning

Since 1997, standards-track RFCs use a small defined vocabulary for requirements: RFC 2119 gives capitalized MUST/SHOULD/MAY their precise meanings (“SHOULD” means “do this unless you understand and accept the consequences,” not “optional”), and RFC 8174 later clarified that only the uppercase forms are normative. Misreading a lowercase “should” as binding — or an uppercase SHOULD as optional — is the most common way secondhand summaries mangle what a specification actually requires, and it’s checkable in seconds once you know the convention exists.

Step 6: read the introduction and terminology sections first

Most RFCs open with a plain-language introduction explaining the actual problem being solved, before moving into the more formal technical specification — reading this section first, even if you skip deeper technical sections, gives you the genuine historical context for why the specification exists at all.

Step 7: use an RFC to verify a specific historical or technical claim directly

If you’ve read a secondhand claim about how a specific old protocol worked, the actual RFC is the primary source that settles it — considerably more authoritative than a blog post or forum summary describing the protocol secondhand.

Step 8: read RFC 1 itself for the very origin of the format

RFC 1: "Host Software" (April 7, 1969)

RFC 1 itself, written by Steve Crocker, predates even the “Request for Comments” name becoming a formalized process — reading it directly shows how informal and exploratory the earliest network specification work actually was, a useful corrective to any assumption that early internet design was more rigorously formalized from the outset than it actually was.

The series’ institutional continuity is itself remarkable: Jon Postel edited the RFCs for nearly three decades, from the ARPANET era until his death in 1998, personally shaping the document culture that made the series citable; the RFC Editor function was institutionalized afterward and continues today. The series even documented its own history in an RFC — RFC 8700, published for the fiftieth anniversary of RFC 1 — which is as good a demonstration as any that these documents are the internet’s primary historical record, maintained in public, by the community that built the thing they describe.

Why primary specification documents beat secondhand summaries

A blog post, textbook, or Wikipedia article describing “how SMTP works” is an interpretation, however careful — the actual RFC is the original artifact those interpretations are all derived from, and going back to it directly is the single most reliable way to verify a specific technical historical claim about how an internet protocol was actually specified to work.

Related:

Sources: