How to Read and Understand Old Internet RFCs
A complete walkthrough finding, reading, and actually understanding Request for Comments documents — the original, primary-source specifications behind email, the early internet, and much of the web's foundational technology.
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 IndexThe 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 bySince 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.
Step 5: 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 6: 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 7: 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.
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.