The year 1969 was a turning point for the nascent field of digital communication. Previously computers could only communicate with another machine if they acted as an extension of that computing environment. Terminals could only communicate with other machines that shared their hardware and software requirements. If you connected a specific machine to the mainframe on MITs campus it had to have a specific interface and operating system with its own commands and procedures. Machines that were connected to the University of California Berkeley could only communicate with that one type of computer. If you wanted to connect to two different networks, you need two different machines.
In 1969 that was all about to change. But first, there were a lot of questions.
How could four computers, scattered around the West, signal each other in a way that was flexible, extensible, and reliable? This bigger question spawned smaller questions like the heads of the hydra. How much should the underlying protocols do for an engineer writing a program? At the cost of precious bytes, should the network guarantee delivery of information? Or leave that up to the individual application? How should little packets of information route themselves between these four machines? How many more machines were likely to be added to the network? (certainly not more than 256...).
These questions pressed themselves against a group of current and recent graduate students with more excitement than experience at UCLA. They would go on to write the rules and standards that would govern the predecessor to the internet (the ARPAnet), which would be codified into what we recognize as the internet today. They would pen the standards and protocols used in the now almost 25 billion devices connecting nearly half of the worlds population.
But as 1968 stretched into 1969 they mostly had a lot of questions, a lot of ideas, and somewhat ironically no way to efficiently communicate those ideas about efficient networked communication.
One member of the group (which called itself the Network Working Group), Steve Crocker, suggested they start by taking notes during their various meetings. He wrote up the document and circulated it around the involved university campuses on printed paper under the title "Request for Comment". It wasn’t until the third one of these memos, or circulated notes that the official format was proposed. The third RFC (Request for Comment) was titled “Documentation Conversations”. And here is where some important, but potentially subtle decisions were made. This format would, in my opinion, forever shape the underlying ethos of our internet.
RFC 3: “Documentation Conversations”
RFC 3, titled "Documentation Conversations" laid the requirements for creating one of these memos. It read "The content of a NWG note may be any thought, suggestion, etc. related to the HOST software or other aspect of the network". Here the HOST software is talking about the software that would run on a given computer that would allow it to connect and communicate with other computers (i.e. a network). So the content of an RFC should relate to computers and networks. Nothing too shocking, it was the Network Working Group after all.
The RFC continues "Notes are encouraged to be timely rather than polished". This was a group of implementers - individuals who loved to program and create. While they sat in the ivory tower they kept their eyes on the ground and didn't want the perfect to be the enemy of the good. They were young, Steve Crocker was 24. They wanted things quickly - also not surprising. It was the final bit that might cause an eyebrow to raise.
"Philosophical positions without examples or other specifics, specific suggestions or implementation techniques without introductory or background explication, and explicit questions without any attempted answers are all acceptable."
(Emphasis my own)
That is a very trusting statement. In my opinion it stands counter to the ideas of rigor and proof that we might expect from a set of engineers and researchers.
Essentially Crocker is saying just toss out your ideas and we can shoot them down or build them up together.
I think it's worth pausing here to contrast the difference of this stance with typical scientific communication methods. Below is a picture of an article from Nature. I grabbed it at random. It represents the opposite of everything an RFC stands for.
While there are some inequalities comparing what was an intensely practical project (creating the internet) and what is a highly theoretical pursuit (most articles published in a research journal), I think the comparison nicely highlights the importance and divergence of the RFC format.
The Nature article is researched, tested and analyzed before it even reaches the stage of submission. It’s been a while since I’ve been around the academic scientific community, but the timescale here is months to years. It's not a suggestion written up in a weekend. It’s not the manifestation of a “shower idea”. It's polished, formatted and scattered with highly technical language. This beast is dense.
My critique of the academic paper format is not original or unique. Karl Popper, a philosopher and scientist known for his pursuit of empiricism, has remarked that "We should, as a matter of course, give the widest freedom to scientists to write papers as they think fit." (In the collection of his essays The Myth of the Framework). How many ideas are dismissed out of course because they just don't fit themselves nicely to the word count and style guidelines of Abstract, Introduction, Methods, Discussion? It’s nice that we don’t have to learn Latin anymore, but you better have the internet close at hand to look up all those acronyms.
Popper argues that this method of scientific discourse causes researchers to wall themselves off from the world and, to a degree, from each other. The pretense of the Scientific Article (capital S and capital A) cools intellectual debate because we can hardly parse what and where the new idea actually is within all that encasing text. And our response better have a lot of time and effort put into backing it up.
"[scientists should] avoid like the plague the suggestion that we are in the possession of knowledge which is too deep to be clearly and simply expressed."
Popper goes on to say that open and easily understood modes of expression are "... one of the greatest and most urgent social responsibilities of scientists. It may be the greatest. For this task is closely linked with the survival of an open society and of democracy."
Let me now return to the Request for Comment. Below is a screen grab from RFC 3, the main topic of this article. While it is not flashy and doesn't have the usual pizzazz we expect from a webpage, we can easily image ourselves creating such a document. I could do it in notepad! (I wouldn't. But I could).
The format is simple, the minimum length of an RFC, outlined in RFC 3 is one sentence. Once an RFC is submitted it is circulated (originally by paper, now it is posted and hosted here), and then the community can comment. It is a place for discussion and discourse, not statements and gauntlets.
Since the first RFC in 1969, there have been over 9000 documents added. Usually they are on the topic of network protocols (but not always). It is a giant meta conversation lasting over fifty years about the digital conversation that is a network.
The more and more I learn about RFCs the more I am delighted by their good faith approach to debate.
There are several reasons I want to explore these RFCs. The first is because I find it technically exciting. These are the original documents that went on to (and still do) help the Internet Engineering Task force implement protocols that are more ubiquitous than any spoken language. They are the constitution of the internet’s mechanical bits and bobs. As someone trying to better my craft, this is exciting to explore.
The second reason is that RFCs feel like the engineering sprite at its finest. This tool is an amazing feat of human cooperation and even compassion. It wasn't designed to addict us. It was designed by curious people trying to making something together.
These documents have had a profound influence on how the internet has been designed and implemented. I would like to make this more accessible. I've selected several RFCs of note that I would like to go on and highly and explain in a less technical manner in this series.
It is easy to write manuals and specs without soul - these documents show that are designers and creators we can do more.