Every page on this site cites them

Look at any tool documentation here, or any protocol article, and you will find a four-digit number after the letters . RFC 2616 for HTTP (Hypertext Transfer Protocol), RFC 8446 for TLS (Transport Layer Security) 1.3, RFC 1918 for the private address ranges you assign every week. Practitioners cite these numbers constantly and almost nobody is taught what the series is, who decides what goes in it, or why a document that defines the protocol carrying most of the world's commerce is titled a request for comments.

April 1969: the hedge that became the tradition

In 1969 the did not yet work. A handful of graduate students at four universities were writing the software that would make four computers talk, and the professors who might have imposed a design were not doing so. , then at UCLA, wrote up the group's notes on host software and faced a problem of standing: he was a student with no authority to tell anyone anything. His solution was the title. He called it a Request for Comments so as not to seem presumptuous or authoritative, and published it on 7 April 1969 as RFC 1. He said later that while much of the development followed a grand plan, the creation of the RFCs was largely accidental.

The culture was set within weeks, in the documents themselves. RFC 3, in April 1969, is called Documentation Conventions and reads in part: the Network Working Group seems to consist of - and then names five people - membership is not closed. Notes may be produced at any site by anybody and included in this series. The content may be any thought or suggestion related to the host software. And, the line worth memorising: notes are encouraged to be timely rather than polished. Philosophical positions without examples, specific suggestions without background, and explicit questions with no attempted answer are all explicitly declared acceptable.

That is a governance model disguised as a style guide. Anyone may write; nothing needs to be finished; asking counts as contributing. By RFC 53, in June 1970, Crocker was describing how an official protocol would be established and changed - proposals circulated as RFCs, a cutoff date, comments from anyone interested - which is, in miniature, the process the Internet Engineering Task Force () still runs. The series began before email existed; the early ones were typed, duplicated and posted.

What the numbers actually mean

Four things trip up practitioners who cite RFCs daily.

An RFC is not necessarily a standard. The series carries proposed standards, informational documents, experimental protocols, best current practices and outright jokes, and the number tells you nothing about which. The status is metadata, printed on the document and in the index. Many of the most-cited RFCs in operational work - RFC 1918 on private addresses is one - are best current practice, not standards.

RFCs are never revised. A published RFC is immutable. When the specification changes, a new RFC is published which obsoletes the old one, and the old one stays where it is, marked. This is why HTTP/1.1 is RFC 2616 in older documentation and RFC 7230 through 7235, then RFC 9110 onward, in newer: the protocol did not change name, the documents were replaced. Anyone citing a version-specific behaviour should check whether the RFC they are quoting has been obsoleted, because the internet's own archive will happily serve a document that stopped being true in 2014.

A draft is not an RFC. Work happens in Internet-Drafts, which expire after six months and are explicitly not citable as anything. A protocol may be widely deployed while still a draft - QUIC was - and a practitioner reading documentation should notice which of the two is being cited.

The number is chronological, not hierarchical. RFC 9293 is not more important than RFC 793; it is the same protocol, TCP (Transmission Control Protocol), respecified fifty years on.

No kings

The IETF was formed in 1986, out of the working-group tradition the RFCs had created. Its ethos was given its permanent phrasing by of MIT in a 1992 presentation, in a slide that has been quoted at every subsequent argument about internet governance: we reject kings, presidents and voting; we believe in rough consensus and running code.

Both halves matter and the second is the one operators feel. Rough consensus is not unanimity and not a majority vote; it is the working group chair's judgement that the objections have been heard and addressed, which makes standardisation a matter of argument rather than of counting. Running code means a specification is expected to have been implemented by someone before it is blessed, which is why internet protocols tend to be things that already work rather than things that ought to. The protocol wars between and the formally correct OSI stack were decided on exactly this difference: one had a committee and a document, the other had running code and an installed base.

The practical consequence for anyone reading a specification: an RFC describes what implementers agreed to do, not what a decreed. When implementations differ, the RFC is often ambiguous rather than one implementation being wrong, and the fights over that ambiguity are in the public mailing-list archives, which anyone can read.

The first of April

The series has published an April Fools' RFC most years since 1978, and they are worth knowing because they are how the community makes technical arguments through comedy.

RFC 1149, from 1 April 1990, specifies the transmission of IP datagrams over avian carriers: datagrams are printed on scrolls of paper and wrapped around a pigeon's leg. It has a real point - it is a valid, if absurd, demonstration that IP is indifferent to its link layer, which is the whole argument for layering - and on 28 April 2001 the Bergen Linux User Group actually implemented it, printing each ping packet as hexadecimal, taping it to a pigeon and scanning it at the far end about five kilometres away. Their own write-up records the result: nine packets sent, four replies, round-trip times from 3,211 to 6,389 seconds - and a delay of about an hour when the pigeons chose to fly with a neighbour's flock first. RFC 2549 later added quality of service; RFC 6214 updated the protocol for IPv6.

, from 2003, proposes the security flag in the IPv4 header: a single bit that attackers set to declare their packets malicious, so firewalls need only test one bit. The joke is a serious argument about the difference between describing an intention and enforcing a policy, and it is quoted whenever a product claims to detect intent from a header field. Practitioners call it the evil bit, and it has become the standard shorthand for a control that assumes the attacker's cooperation.

Why the hedge held

The name has survived nine thousand documents and fifty-seven years, and it still says something true about how the internet is specified: nobody involved has the authority to command, so agreement has to be produced in public, in writing, by people who show their work. The EFF article records a lawsuit establishing that source code is speech; this series is the older and quieter version of the same idea. The specification of the network is a public document that anyone may read, cite, criticise or implement, and it has been since the first one, written by a student who did not think he was in charge.

Sources