by Darius Kazemi, Jan 2 2019
A mystery, so soon??
RFC-2 kicks off with a bang: the first page is lost to history!!!! As a result we don't actually know what this RFC is titled.
Okay we do know the title, as it was mentioned by name in RFC-3, but that wasn't officially recognized until 2010 when an official RFC Errata was published stating:
RFC0002 was actually titled “HOST SOFTWARE”. This missing historical information is provided by RFC0003. Source: http://tools.ietf.org/html/rfc3
So... same title as RFC 1. Original.
(Update Jan 23 2019: there is now a scan of this missing page. It... looks exactly like every other RFC cover page from this era. Exciting. More on this here.)
This RFC is not exactly dated but according to RFC-2555 it was published on April 9, 1969, two days after RFC-1. Also according to Jake Feinler's recollections in RFC-2555, while RFC-1 was typed on a typewriter,
RFC 2 was produced online via the SRI NLS system and was entered into the online SRI NLS Journal. However, it was probably mailed to each recipient via snail mail by the NIC, as email and the File Transfer Protocol (FTP) had not yet been invented.
“Jake”, incidentally, is Elizabeth J. Feinler's nickname, as explained on the wiki page above. She's the first woman to show up in my little history project here. She was not involved directly in these early documents but she would join Englebart's group at Stanford in 1972 and would play a huge role in ARPANET over the next two decades.
The technical content
Here we get a significant expansion on how links work. The breezy prose of RFC 1 is replaced with technical bullet points that that are more useful for actually implementing the damn thing. The algorithms are painstakingly laid out in outline form. Not quite pseudocode because it's still all English (“This results in a successful return from the monitor to the requestor. The link number is returned to the requestor, and the link is established.”) but it's very specific English that can easily be converted to computer code. I write almost exactly in this style in a plain text document when I'm building a complex program as a kind of todo list.
Nothing earth shattering here, just expanding on what was already laid out in RFC 1:
- connections between hosts comprise of 32 links (distinct communication channels) labeled 0 to 31
- link 0 is reserved for meta communication about who is talking when
- links 1-31 are reserved by a specific user at any given point. basically if you start sending information over link 7, you're going to continue hogging link 7 until you close your connection.
- you can open up more than one link if you need to (but holy crap there's only 31 of them, please be nice)
We have our first mention of 8-bit ASCII character sets (important because most of these computer systems weren't remotely standardized so you needed to agree on like, what a letter “A” is represented by numerically).
Near as I can tell, almost nothing here conflicts with RFC 1. It simply expands what was proposed there in much greater detail. I guess that's why it has the same title as RFC 1. They really could be considered the same document.
This document was authored by Bill Duvall, who is implied in RFC 1 as being, uh, basically Jeff Rulifson's assistant at Stanford Research Institute. (“Also present was Bill Duvall of SRI who has recently started working with Jeff Rulifson.”) I imagine his lack of seniority made him the natural choice to write up the meeting minutes.
This document also immediately establishes a pattern we'll continue to see in RFCs: a document that says “okay we talked about the stuff in a previous RFC and have some more concrete ideas of how it might work and here are those ideas.”
There's some irreverence in here too.
5b3 Interrogate status auxilliary link. 5b3a Don’t know what, exactly, this should do, but it seems as though it might be useful.
I enjoyed this note on character translation:
4a1c3b How should we decide which messages should be translated, i.e. is it desirable to not translate everything (YES!!) and by what means can we use to differentiate?
I think the idea here is that while the host might not use ASCII, we could leave it up to the IMP to translate messages to ASCII for transmission. But that's a computationally expensive operation, so they would like to identify if a message doesn't need translation in the first place so they can skip the whole damn process. The
YES!! makes me imagine some uhhh heated moments in the meeting.
This document is written more like I expect a specification to be written: “here's your algorithms, now go translate them to code.”
Formatting by future generations
Oh and I forgot to mention with RFC 1: it seems that these early RFCs were transcribed from their original typewritten (sometimes handwritten) form into an electronic format in the late 1990s. So these documents I'm reading and that the public has access to are not the originals (the closest digital equivalent would be scans of the typewritten or sometimes handwritten documents.) I am currently reaching out to some computer historians to see if there are scans available. There are some scans widely available, for example of RFC-8, and I will post these as they come up.
This particular RFC was transcribed in October 1998 by Robbie Bennet and formatted in a fixed width layout by Kelly Tardif in October 1999. No I'm not going to list this for every RFC but I figured I'd do it once to acknowledge the historical preservation work.
It might be fun to look at the errata listing for this document? IDK.