What is an RFC?
A short reference on RFCs — what Request for Comments documents are, who publishes them, why the name is a 50-year-old misnomer, what MUST and SHOULD legally mean, and which numbers are worth recognizing on sight.
The one-line definition
An RFC (Request for Comments) is a numbered document in the series that defines how the internet works — from IP and TCP to HTTP, DNS1 and email. Published today by the RFC Editor under the IETF's processes, the series began in 1969 as informal working notes for the ARPANET, and the name has been a polite lie for most of its life: a published RFC is not requesting comments; many are binding standards.
🔗 Learn more — 1 What is DNS?
Why the name is a misnomer
The first RFCs really were requests for comment — memos circulated among the handful of 1969 ARPANET researchers, deliberately titled to sound non-authoritative so that graduate students could publish without stepping on official toes. The humility was tactical, and it worked so well that the series became the official record. The name stuck. Today "RFC" in engineering slang means almost the opposite of its expansion: the document of record, the thing you cite to end an argument. (Many companies borrowed the term for internal design docs, where it honestly does mean "please comment.")
Not all RFCs are standards
Every RFC has a status, and the status matters more than the number:
| Status | Meaning |
|---|---|
| Standards Track | The real thing — Proposed Standard, then (rarely) Internet Standard. TCP, IP, HTTP live here |
| Informational | Published for the record; no normative force. RFC 3092, the etymology of foo, is one |
| Experimental | Defined so people can try it; not endorsed |
| Best Current Practice | Operational guidance with teeth (BCP 14 is the famous one, see below) |
| Historic | Superseded; kept because RFCs are never deleted |
RFCs are also immutable: once published, a number's text never changes. Corrections come as errata; real changes come as a new RFC that obsoletes the old one. The document trail is append-only, which is why you can still read Jon Postel's 1981 assigned-numbers ledger exactly as the localhost story left it.
MUST, SHOULD, MAY
Standards-track RFCs use capitalized keywords with precise definitions from RFC 2119 (BCP 14):
- MUST / MUST NOT — absolute requirement. Violate it and you are non-compliant.
- SHOULD / SHOULD NOT — do this unless you have a good, understood reason not to.
- MAY — genuinely optional.
This is why spec prose reads strangely formal: "Addresses of this form MUST NOT appear outside a host" is not stylistic shouting, it is a legal operator. Once you know the keywords, RFCs stop being walls of text and become checklists.
Numbers worth recognizing
| RFC | What it is |
|---|---|
| 791 / 793 | IPv42 and TCP — the 1981 twin pillars |
| 790 | Postel's assigned numbers, where 127 was reserved |
| 1122 | Host requirements — the "MUST NOT appear outside a host" one |
| 1918 | Private address space (10/8, 172.16/12, 192.168/16) |
| 2119 | The MUST/SHOULD/MAY definitions |
| 3092 | The etymology of foo, published April 1 |
| 6761 | Special-use domains — why localhost never hits DNS |
| 9110 | HTTP semantics, current home of the status codes |
🔗 Learn more — 2 IPv4 vs IPv6: what actually changed
The April 1st tradition
Since 1978 the series has published joke RFCs on April Fools' Day, fully formatted and deadpan: IP over Avian Carriers (RFC 1149, later "implemented" with actual pigeons), HTCPCP (RFC 2324, the coffee-pot protocol that gave HTTP its 418 "I'm a teapot" status), and the foo etymology. They are the best proof of the series' health — a standards body secure enough to satirize itself in its own archival format.
How to read one
- Canonical copies live at
rfc-editor.org/rfc/rfcNNNN— plain text, stable URLs, no paywall ever. - Check the header first: status, date, and whether it has been obsoleted by something newer (the HTML view links this).
- Search for the keywords: reading just the MUSTs of an RFC is a legitimate first pass at implementing it.