365 RFCs

by Darius Kazemi, Feb 16 2019

In 2019 I'm reading one RFC a day in chronological order starting from the very first one. More on this project here. There is a table of contents for all my RFC posts.

Potential embarrassment

RFC-47 is by Jon Postel and Steve Crocker, although the author of the actual content is William Crowther. It's titled “BBN's Comments on NWG/RFC #33” and it does what it says on the tin. It's dated April 20th, 1970 (b-blaze it?).

The technical content

The document opens with a note from Postel and Crocker:

BBN has given us the attached comments on NWG/RFC 33, but wouldn't publish them being relectant [sic] to embarrass us. Embarrassment notwithstanding, we found the comments particularly useful and decided to share them with our friends. Bill Crowther is the author.

The remainder of the document is Crowther's commentary. He is a designer of the IMP (Interface Message Processor, the router-like thing on the network) and he's pointing out some misunderstandings in Crocker's RFC-33 paper about how the IMP works.

He first establishes that they want to make it so that traffic jams (my term) don't happen on the network, but it's really hard to do so they've had to resort to some complicated signaling about when messages are ready to be sent (the RFNM, request-for-new-message). They've also reluctantly had to add buffers to hold network packets temporarily in place, which slows down the transmission but can clear up a traffic jam.

The RFC-33 paper states that a single HOST or process shouldn't take up multiple links on the IMP, but actually the IMP is designed for that use case. If you need more links for more bandwidth, you are welcome to grab those.

The IMP has a memory buffer for its dedicated HOST but the buffer can only hold three full length messages at once. So the HOST needs to empty out the buffer as fast as possible, to the point where Crowther “violently” insists that “the IMP's buffers must be empty or they are not serving their communication purpose.”

Crowther also corrects a complaint in RFC-33 that the communication channels lock up for 80 milliseconds at a time. He notes that the 80 milliseconds is a hardware default, which can be changed (and presumably shortened) by using a screwdriver to adjust a screw in the IMP!

Analysis

Because of the way RFCs are filed, sometimes the “author” of an RFC only wrote a small percentage of the text. This is why I try to say so-and-so “authored” an RFC rather than “wrote” an RFC unless it's obvious to me that the author is also the writer of the document. For example, this RFC may have Postel and Crocker listed as the author, but the bulk of the content was written by Crowther.

What I'm getting from Crowther's insistence on the IMP buffers needing to be essentially empty at all times is that they really aren't much of a buffer at all. It's almost more like a little swap space that happens to look and act like a buffer but has other primary uses. I imagine the mechanic's repair pit at a car race: while it is a flat asphalt area where a small number of cars can park, it is not a parking lot. Cars are supposed to go in and out of there as quickly as possible and get back into the race.

On the note that opens the RFC: I spoke with Steve Crocker a little bit about this, and he related that the BBN folks were essentially a lot more formal in what they published and tended to not just throw out ideas to see what stuck (at least externally; internally there was lively exchange of ideas from what I've read of their own accounts). Crowther sent him the notes privately because he didn't think they were appropriate for a public channel but really they were in the exact spirit of the RFC project. Recall the ground rules from RFC-3:

The content of a NWG note may be any thought, suggestion, etc. related to the HOST software or other aspect of the network. Notes are encouraged to be timely rather than polished. 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. The minimum length for a NWG note is one sentence.

Further reading

I found this BBN quarterly technical report for January 1st 1970 through March 31st 1970.

On page 7 of the report we see exactly what Crowther was relating to the Network Working Group in his notes:

The network can be described as a taut communication system in the sense that each message entering the net proceeds directly to its destination. We observed that messages do not wander about the net, even at high traffic loads. The net easily handles sequences of single-character messages typed at the IMP teletype.

Interestingly, there is a further note on page 8 that states that buffers get really full during

the use of multiple links by a Host (for fanning messages), which causes a large part (or all) of the source IMP's store and forward buffers to be filled.

This seems to somewhat contradict Crowther's insistence that the IMP is absolutely meant to support multiple links per host! And this is from a report written right around the same time this RFC was.

How to follow this blog

You can subscribe to this blog's RSS feed or if you're on a federated ActivityPub social network like Mastodon or Pleroma you can search for the user “@365-rfcs@write.as” and follow it there.

About me

I'm Darius Kazemi. I'm a Mozilla Fellow and I do a lot of work on the decentralized web with both ActivityPub and the Dat Project.

by Darius Kazemi, Feb 15 2019

In 2019 I'm reading one RFC a day in chronological order starting from the very first one. More on this project here. There is a table of contents for all my RFC posts.

A power move

RFC-46 is by Edwin E. Meyer, Jr. of MIT's Project MAC. It's titled “ARPA Network Protocol Notes”, and is a bit of a latecomer in the “feedback on RFCs 33 and 36” genre.

The technical content

This is 16 pages long. Sigh. I will do my best to summarize. The main points seem to be:

• the dynamic reconnection system is confusing and should be put off to a later date (echoing what previous commenters have said as well)
• they like the error messages outlined in RFC-40
• processes should be interruptable (for example, if a process is locked up you should be able to kill it)
• stateful sockets
• the creation of a User Control and Communication subsystem on a HOST that is in charge of starting up processes on foreign HOSTs

There is a colophon at the end of the document that says this document is prepared using RUNOFF and QED.

RUNOFF is an early document layout program that influenced roff and then nroff and groff, among other programs. I had never heard of these programs before this project, but if you are on MacOS you can open your terminal and type groff and you probably have it installed!

QED is a line-level editor (a text editor that only operates on a single line of text at a time) whose immediate descendent ed is ALSO probably on your MacOS machine or other unix-like system.

Analysis

This document is kind of a power move? Instead of just providing suggestions for improvements to the protocol, this is a rewrite of the entire protocol with the suggestions already included. It's the difference between writing to your favorite novelist saying “please include my original character in your novel” and rewriting the whole novel with your character in there and sending them that as a suggested improvement.

So even though this is 16 pages long, I'd say 70% of it is rewording or slight technical tweaking of things that have been expressed in previous RFCs.

The official transcription is completely missing Figure 3! Here is a photo I took of Figure 3 at the Computer History Museum:

Further reading

There's a great history of the still-heavily-used text editor Vim called Where Vim Came From that goes into the details of how QED influenced the entire family tree of text editors. For exampled, QED begat ed, and if you want to write a buffer to disk in ed, you need to type 'w', and if you want to quit you have to type 'quit'. This is where the famous :wq command in Vim comes from.

How to follow this blog

You can subscribe to this blog's RSS feed or if you're on a federated ActivityPub social network like Mastodon or Pleroma you can search for the user “@365-rfcs@write.as” and follow it there.

About me

I'm Darius Kazemi. I'm a Mozilla Fellow and I do a lot of work on the decentralized web with both ActivityPub and the Dat Project.

by Darius Kazemi, Feb 14 2019

In 2019 I'm reading one RFC a day in chronological order starting from the very first one. More on this project here. There is a table of contents for all my RFC posts.

See you in Atlantic City

RFC-45 is by Jon Postel and Steve Crocker of UCLA, dated April 14th, 1970. It's ominously titled “New Protocol is Coming”.

The technical content

Postel and Crocker are giving the RFC participants two weeks' notice that they will be sending out what they hope is a final version of the new HOST-to-HOST protocol based on the feedback they've received in the last couple months.

They suggest that since pretty much everyone is going to be at the Spring Joint Computer Conference in Atlantic City, New Jersey, that they meet there in the afternoon of May 7th to discuss the protocol. That morning everyone is expected to attend Larry Roberts' network session to see the latest and greatest computer networking papers, including a paper on the protocol itself.

The afternoon meeting is “for everyone to exchange gripes, suggestions and schedules.”

Analysis

At this point, we have read through a whole calendar year's worth of RFCs! The first RFC is dated April 7th, 1969, and this is one year and one week later. So we've averaged a little less than one RFC per week in this first year. And remember, this whole time it's been distributed via the postal service.

Further reading

The Joint Computer Conference was a big deal for about 30 years. It used to alternate between the east and west coasts of the United States. For a while they were known as the Eastern and Western Joint Computer Conferences, then as the Spring and Fall Joint Computer Conferences, and then finally merged into the National Computer Conference.

For your perusal: all 739 pages of the full conference proceedings of the 1970 Spring Joint Computer Conference. The ARPANET related papers are on pages 543 to 597 (those are the paper page numbers, jump to page 553 in the PDF).

How to follow this blog

You can subscribe to this blog's RSS feed or if you're on a federated ActivityPub social network like Mastodon or Pleroma you can search for the user “@365-rfcs@write.as” and follow it there.

About me

I'm Darius Kazemi. I'm a Mozilla Fellow and I do a lot of work on the decentralized web with both ActivityPub and the Dat Project.

by Darius Kazemi, Feb 13 2019

In 2019 I'm reading one RFC a day in chronological order starting from the very first one. More on this project here. There is a table of contents for all my RFC posts.

A word from SDC

RFC-44 is from System Development Corporation, a group I've mentioned before in the context of them being an ARPANET contributor and the first ever company dedicated entirely to the creation of computer software. We don't hear from them often in the RFC series. This one is authored by Arie Shoshani, Robert E. Long, and Abe S. Landsberg, titled “Comments on NWG/RFC 33 and 36”, and dated April 10th 1970.

The technical content

This document provides commentary on the new HOST-HOST protocol proposed by Crocker et al in RFC-33 and RFC-36.

First they propose simplifying the new dynamic reconnection mechanism (recall there was much dismay at how complex it was) by allowing it to work for reconnecting different sockets within the same physical HOST machine, but not for reconnecting sockets in different HOST machines. They claim the usefulness of the latter is in doubt but don't explain why (although I'll note that at least according to a SDC document I link in “Further reading” below, it wasn't until 1971 that “interprocess communication” between two separate HOSTs was fully tested).

They offer a few suggestions for streamlining the new protocol, mostly by removing what they consider to be redundant information.

They also highlight a few other protocol issues and that they would like people to at least agree on a date to resolve them, as the problems were brought up two weeks ago at the UCLA network meeting “but were put aside.” The most significant one is around encoding: they believe that ASCII-8 (USASCII, I presume) will not suffice for all applications, especially for transmitting graphics over the network. They propose that ARPANET keep using ASCII for now but that a Network Common Code should be phased in. They don't explain the details though.

Analysis

The authors note that in “RFC#33 the term PORT was introduced.” I wonder then, was that the first usage of the term PORT in the context of computer networking?

Further reading

I found a 1971 System Development Corporation report summarizing six months of ARPA-funded computing research at SDC. (It's dated April 15 1970 on the cover page but has 1971 listed through the rest of the document.) It's from almost a year after this RFC but I'm including it anyway because it's a fascinating snapshot of the state of computing at the time. They use the word “data base” but not as a compound; incidentally E.F. Codd was essentially in the process of inventing relational databases in the period 1970 to 1972, and he also used the term “data base”. See his 1970 paper (PDF) if you're curious.

How to follow this blog

You can subscribe to this blog's RSS feed or if you're on a federated ActivityPub social network like Mastodon or Pleroma you can search for the user “@365-rfcs@write.as” and follow it there.

About me

I'm Darius Kazemi. I'm a Mozilla Fellow and I do a lot of work on the decentralized web with both ActivityPub and the Dat Project.

by Darius Kazemi, Feb 12 2019

In 2019 I'm reading one RFC a day in chronological order starting from the very first one. More on this project here. There is a table of contents for all my RFC posts.

A meeting at Lincoln Laboratory

RFC-43 is by Alan G. Nemeth of MIT Lincoln Laboratory, dated April 8th 1970. It's titled “Proposed Meeting”.

The technical content

This RFC is proposing a meeting at Lincoln Laboratory in Lexington, Massachusetts to discuss the Local Interaction Language (LIL). It is yet another attempt to provide rich applications over the ARPANET.

Analysis

I can't find any real records of Local Interaction Language in significant use anywhere outside of MIT L.L., which leads me to believe it was mostly dead in the water like the Decode/Encode Language and the Network Interface Language.

Further reading

The full paper from Licoln Laboratory describing Local Interchange Language can be found in their May 31st 1970 semiannual technical report titled “Graphics”.

Here's a photo of Alan Nemeth working with Carma Forgie at Lincoln Laboratory, date unknown:

Since this is, according to the caption, a photo of people doing time-sharing on the TX-2, the photo is probably from the early 1960s. Fun fact: the TX-0 and TX-2 computers were the basis for DEC's PDP-1, the first of which was purchased by BBN in 1960 for $150,000, approximately $1.2 million in 2019 money. It was even leased rather than purchased outright, and as recalled by Leo Beranek (the second “B” in BBN), the company bought the computer because they knew it would be useful, but they didn't have any contracts for it at the time. They had to go out and get the money to pay for it after the fact.

The photo is from the 2011 MIT Lincoln Lab retrospective that I've linked here before, and the BBN tidbit is from this history of BBN edited by Dave Walden and Ray Nickerson.

How to follow this blog

You can subscribe to this blog's RSS feed or if you're on a federated ActivityPub social network like Mastodon or Pleroma you can search for the user “@365-rfcs@write.as” and follow it there.

About me

I'm Darius Kazemi. I'm a Mozilla Fellow and I do a lot of work on the decentralized web with both ActivityPub and the Dat Project.

by Darius Kazemi, Feb 11 2019

In 2019 I'm reading one RFC a day in chronological order starting from the very first one. More on this project here. There is a table of contents for all my RFC posts.

A proposal for typed messages

RFC-42 is authored by Enrico I. Ancona of MIT Lincoln Laboratory on March 31st, 1970. It's called “Message Data Types”.

The technical content

This document proposes that the first 8 bits of any “normal” message is reserved for a code that tells you what kind of message will follow. It proposes translation programs on the receiving and sending end of messages that add the data type to a message (on the sending end) and decode the data type (on the receiving end). This is a little bit like what MIME types do for HTTP messages today, so a web browser knows if it's dealing with text or an image or video et cetera.

Ancona provides a way for this system to be extensible, so that different HOST systems could make their own data types available to other HOSTs.

Specifically this proposal is framed in terms of a feared explosion of potentially conflicting technical conventions:

It is important that conventions regarding the contents of messages be set up early so that there will not be a large proliferation of such conventions between every pair of programs running on the network.

Analysis

The document opens with a bit of art that, in my opinion, is far better in the original than in the normalized official ASCII art version. Here's a photo I took at the Computer History Museum's archives:

Compare to the ASCII art version:

        Socket    Port
        |    |      |    ____________
        |    V      V   /            \
        V              /              \
            |=|    /==|                |
-------(+)->|Y|--><   |                |
            |=|    \==|                |
                      |    PROCESS     |
                      |                |
            |=|    /==|                |
-------(-)->|X|<--<   |                |
            |=|    \==|                |
                       \              /
                        \____________/

You'll also note a transcription error in the diagram! The original “Socket” label is clearly pointing to the (+), with another arrow to its right that has been crossed out. In the transcribed official version, both arrows were left in, with nothing to indicate that the second arrow under “Socket” was crossed out.

In general I found this RFC a bit light on details and kind of hand-wavey, making promises for future compatibility that I can't really see evidence of in the proposal itself.

How to follow this blog

You can subscribe to this blog's RSS feed or if you're on a federated ActivityPub social network like Mastodon or Pleroma you can search for the user “@365-rfcs@write.as” and follow it there.

About me

I'm Darius Kazemi. I'm a Mozilla Fellow and I do a lot of work on the decentralized web with both ActivityPub and the Dat Project.

by Darius Kazemi, Feb 10 2019

In 2019 I'm reading one RFC a day in chronological order starting from the very first one. More on this project here. There is a table of contents for all my RFC posts.

Please provide timestamps

RFC-41 is by John Melvin of SRI/ARC, dated March 30th 1970. It's called “IMP/IMP Teletype Communication”.

The technical content

Melvin is referring to an “annoying” thing that happens when he gets messages to his teletype via the IMP. The messages aren't stamped with the date and time, so he has no idea if it just came in or if it's several days old and would be pointless to respond to.

He implores people to tag their messages with at least the 24 hour time and time zone.

Further reading

This specifically mentions teletype communication. I think I've mentioned here before but a teletype is a kind of typewriter that is hooked up to a communications line. You type into it like a normal typewriter, onto paper, but it also sends those messages out. It receives messages back and types them back at you, kind of like a player piano. Here is a four-minute video that demonstrates what it's like to program a computer by teletype:

Teletype, incidentally, is a brand name that eventually came to be associated with the entire category of product. Technically these are teletypewriters or teleprinters, and “Teletype” is a brand, but like Kleenex and Xerox, everyone just used the brand name.

There's a really beautiful 40-page illustrated brochure called “The Teletype Story”, published by the Teletype company in 1957 for its 50th anniversary.

How to follow this blog

You can subscribe to this blog's RSS feed or if you're on a federated ActivityPub social network like Mastodon or Pleroma you can search for the user “@365-rfcs@write.as” and follow it there.

About me

I'm Darius Kazemi. I'm a Mozilla Fellow and I do a lot of work on the decentralized web with both ActivityPub and the Dat Project.

by Darius Kazemi, Feb 9 2019

In 2019 I'm reading one RFC a day in chronological order starting from the very first one. More on this project here. There is a table of contents for all my RFC posts.

Detailed errors and statuses

RFC-40 is by Eric Harslem and John Heafner of RAND and is a direct follow-up to their RFC-39, in response to a request from Steve Crocker to provide more detail. It's called “More Comments on the Forthcoming Protocol” and is dated March 1970.

The technical content

They specify the error codes more precisely here, assigning numeric ranges to them:

The ranges of <Code> are shown below in hexidecimal.

     00     Unspecified error types
     10-0F  Resource errors
     10-1F  Status errors
     20-2F  Content errors
     30-3F  Unused

(I assume that first 10-0F should read 01-0F. Unclear if that was a transcription error or an error in the original doc.)

The document goes on to list the specific errors and codes, which I won't repeat here.

They expand the definition of the “query” command to specify the payload of the text field, which wasn't specified in RFC-39.

They seem to change the mechanism of the HOST Status command from a kind of interrupt driven thing (“I am up! I am down”!) to a more passive thing where when a HOST goes up it broadcasts a message to all the NCPs which have to keep track of the state of the remote HOSTs. I think. I could have this wrong, it's possible this is an additional feature on top of the ones described in RFC-39 rather than replacing the functionality. (At least I kind of hope it is, requiring everyone to keep state like that seems... a lot.)

Analysis

Assigning numerical ranges to errors using the most significant digit to categorize them is really similar to what we see today with HTTP status codes:

100 - 199 Informational
200 - 299 Success
300 - 399 Redirection
400 - 499 Client Error
500 - 599 Server Error

This way even if you don't personally remember what an error 474 is, you at least know it's a client error before looking it up. I'm sure it was common practice in computing long before this but it's interesting to note these parallels.

Further reading

Now seems a good time to mention that this blog was partially inspired by Evert Pot's blog series on the HTTP status codes!

How to follow this blog

You can subscribe to this blog's RSS feed or if you're on a federated ActivityPub social network like Mastodon or Pleroma you can search for the user “@365-rfcs@write.as” and follow it there.

About me

I'm Darius Kazemi. I'm a Mozilla Fellow and I do a lot of work on the decentralized web with both ActivityPub and the Dat Project.

by Darius Kazemi, Feb 8 2019

In 2019 I'm reading one RFC a day in chronological order starting from the very first one. More on this project here. There is a table of contents for all my RFC posts.

Error and status

RFC-39 is yet another response to RFC-36. This is authored by John Heafner and Eric Harlsem at RAND, and it proposes some changes to the new HOST-HOST protocol. It's dated March 25th, 1970.

The technical content

Our authors propose some key additions to the protocol, including:

• error messages
• a way to query the status of a socket
• notifications to all users connected to a HOST (“system going down for maintenance!”)

They also believe that Crocker's dynamic reconnection algorithm is too resource-intensive but are also kind of apologetic that they don't have a better solution yet.

There are 3 types of error messages they specify: content errors, status errors, and resource errors. A content error is something like “you asked me to close a link but it's not actually open in the first place” or “your message to me was malformed”. A status error could be a message like “you tried to send a message over link 5 but that link is currently reserved”. A resource error is “we ran out of memory” or “the program you are trying to run doesn't exist.”

Analysis

Error messages and status codes are a really great idea! One of the most common pieces of feedback I send (and get sent) in code review is “uhh maybe add some error messages and a way to query the system status” so. Yeah. This is an early example of a very common piece of programming feedback.

Further reading

Before working on ARPANET, Heafner was involved in the GRAIL Project (GRAphical Input Language) at RAND. It was an early formal investigation into using CRT monitors for human-computer interfaces. The paper even begins stating that when they started the project, they realized there was a mismatch between the 2D display of a monitor and the linear input of a keyboard so figured they needed to invent a tablet/pen for 2D input! There is a fascinating post mortem of the project that was published in 1969 and you can read the whole thing on RAND's website. Here's a blurry scan of the tablet and monitor interface from the paper:

How to follow this blog

You can subscribe to this blog's RSS feed or if you're on a federated ActivityPub social network like Mastodon or Pleroma you can search for the user “@365-rfcs@write.as” and follow it there.

About me

I'm Darius Kazemi. I'm a Mozilla Fellow and I do a lot of work on the decentralized web with both ActivityPub and the Dat Project.

by Darius Kazemi, Feb 7 2019

In 2019 I'm reading one RFC a day in chronological order starting from the very first one. More on this project here. There is a table of contents for all my RFC posts.

Multiplexing

RFC-38 is authored by Stephen M. Wolfe of UCLA, and is a reply to RFC-36.

The technical content

Wolfe proposes that it might make sense to allow multiple connections to share the same physical link, especially if a single computer requires multiple connections to get some work done. That way a whole bunch of physical connections won't be hogged by one computer. He also says that it might be useful in another high-traffic situation where an entire new internal network (multiple HOSTs with multiple users) connects to ARPANET and needs to connect out to the rest of the network.

He then proposes some minor additions to the new network protocol that wouldn't allow multiple shared connections in and of themselves, but would make it possible in the future. He also asks a question about whether certain situations require referencing the physical link or the software connection.

How to follow this blog

You can subscribe to this blog's RSS feed or if you're on a federated ActivityPub social network like Mastodon or Pleroma you can search for the user “@365-rfcs@write.as” and follow it there.

About me

I'm Darius Kazemi. I'm a Mozilla Fellow and I do a lot of work on the decentralized web with both ActivityPub and the Dat Project.