History

The RFC culture

The rules the internet runs on are written down in numbered text files that anyone may read and whose very name asks for objections. That this worked is more remarkable than the technology described inside them.

A title as an apology

When the first of these documents appeared in 1969, their authors were graduate students. They were writing down how the machines on the emerging ARPANET ought to talk to each other, and faced a problem that had nothing to do with technology: they had no authority whatsoever to tell anyone to do anything.

The solution was the name. "Request for Comments." Not a standard, not a specification, not an instruction. A proposal asking to be contradicted. The label was meant as a courtesy, so that nobody would feel passed over.

It became a principle. A document that asks for comments invites participation rather than submission — and as a result the proposals were followed, not because anyone ordered it, but because they were convincing and because everyone had had a hand in writing them.

Why this matters for email

Email is the best evidence for both the strength and the weakness of that method.

The strength: the protocol is openly documented, owned by nobody and implementable by anyone. That is precisely why email could work for decades between systems that had never heard of one another, and why you can still set up a mail server today without asking anybody's permission.

The weakness: a method that rests on consent can take nothing back. When it became clear that the trust assumptions of the early days no longer held, the protocol could not simply be changed — there was nobody who could have enforced a change, and millions of existing systems that had to keep working.

Everything added since therefore had to be bolt-on: voluntary, backwards compatible, breaking nothing for those who do not join in. That sender authorisations live in the DNS and signatures in an extra header line is not an aesthetic decision. It was the only shape of construction available.

How to read an RFC

Anyone dealing with email will run into these documents — and they are more approachable than their reputation suggests. Three things help when starting out:

• The number says nothing about validity. A higher RFC does not automatically replace a lower one. Every document carries its status at the top and records what it obsoletes and what has obsoleted it. Those lines are the first thing to look at.
• The keywords are defined. Words such as MUST, SHOULD and MAY have a fixed meaning laid down in a document of their own. In an RFC the difference between "must" and "should" is not a matter of style but the line between obligation and recommendation.
• Examples are at the end. Almost every protocol RFC contains complete example dialogues. If you find the prose heavy going, start there and read backwards.