365 RFCs

Commenting on one RFC a day in honor of the 50th anniversary of the first RFC.

by Darius Kazemi, December 31 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 letter

RFC-365 is titled “A Letter to All TIP Users”. It's authored by Dave Walden of BBN and dated July 11, 1972.

The technical content

Continuing the theme of actually maybe documenting the ARPANET for users, this RFC is a kind of newsletter for TIP users. It lets Terminal IMP users know that they will be getting a new edition of the “TIP User's Guide”. New commands have been added. Many are related to users whose TIP is equipped with magnetic tape storage (read/write/delete operations).

There are now 11 TIPs on the network., many of which are installed at US government agencies.

The core TIP software is automatically updated in the background by BBN; they plan to add a notification to users when this has happened and you'll be able to type the @NEWS command to learn about the new features of your TIP.

The TIP is notable for its limited memory, and in particular available buffer space suffers. A TIP can support up to 63 attached devices but provides only 26 total bytes of I/O buffer on average per device. BBN is happy to help you upgrade the memory for your TIP, and they are also looking into modularizing the TIP software so if your TIP isn't using a given feature, they can remove it from memory, freeing up precious memory for your devices.

Walden also gives updates on the general status of the TIP project: things they are working on, and a road map for features to come. And I love the parenthetical in the last sentence:

If you've got a suggestion (especially if it doesn't take any memory), let me hear from you.

Analysis

This is it, my last RFC blog in my 365 RFCs series. I'll be writing more posts that do higher level analysis and present related research, but wow, this was such a fun project and I learned so so much. Thank you, especially to those readers who followed along, or at least tried!

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 an independent technologist and artist. I do a lot of work on the decentralized web with ActivityPub, including a Node.js reference implementation, an RSS-to-ActivityPub converter, and a fork of Mastodon, called Hometown. You can support my work via my Patreon.

by Darius Kazemi, December 30 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.

Our documentation sucks

RFC-364 is titled “Serving Remote Users on the ARPANET”. It's authored by Marshall D. Abrams of the National Bureau of Standards and dated July 11, 1972.

The technical content

Abrams starts this RFC by enumerating the two biggest problems on the ARPANET:

  1. remote hosts being offline a whole bunch
  2. end users having absolutely no idea what to do once they're connected to a remote host

Basically, most ARPANET sites require you to already know how to use their software in order to use their software. Their software is either not documented, or hardly documented. As of July 1972, the most efficient way to learn to use an ARPANET Host is to fly to a Network Working Group meeting and spend time face-to-face with the people who work at that host site.

Abrams is critical of the ARPANET Resource Notebook, which is the main printed and disseminated documentation for users, which he finds unacceptably high-level. He provides something like 50 additional questions that he would like the Notebook to answer regarding each site.

And he's right, all of this documentation would greatly increase the utility of the ARPANET to users who aren't also the actual architects of the entire system.

Further reading

Similar complaints come in RFC-369, where the author says, re: using the ARPANET:

By far the most annoying difficulty was obtaining adequate documentation.  The resource notebook was found to be interesting but of limited utility.

The Resource Notebook (I can't find a 1972 edition right now) will eventually morph into the ARPANET Resource Handbook. The 1978 edition I've linked weighs in at a whopping 1026 pages.

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 an independent technologist and artist. I do a lot of work on the decentralized web with ActivityPub, including a Node.js reference implementation, an RSS-to-ActivityPub converter, and a fork of Mastodon, called Hometown. You can support my work via my Patreon.

by Darius Kazemi, December 29 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.

List management

RFC-363 is titled “ARPA Network Mailing Lists”. It's dated August 8, 1972 and authored (presumably) by Jeanne North of the SRI NIC.

The technical content

This RFC updates RFC-329, and consists of three different distribution list for documents related to ARPANET. As in RFC-329, RFC-303, RFC-300, RFC-211, and RFC-168, List A is essentially the critical sites that need information as soon as possible, and lists B and C are for secondary sites.

A smattering of new sites have been added to the distribution lists since the last edition.

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 an independent technologist and artist. I do a lot of work on the decentralized web with ActivityPub, including a Node.js reference implementation, an RSS-to-ActivityPub converter, and a fork of Mastodon, called Hometown. You can support my work via my Patreon.

by Darius Kazemi, December 28 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.

Network status

RFC-362 is titled “Network Host Status”. It's authored by Ellen Westheimer of BBN and dated June 28, 1972.

The technical content

This is another report from BBN on the status of various ARPANET hosts in the same series as RFC-353, RFC-344, RFC-342, RFC-332, RFC-330, RFC-326, RFC-319, RFC-315, RFC-306, RFC-298, RFC-288, RFC-287, RFC-267, RFC-266, RFC-255, RFC-252, RFC-235, and RFC-240.

The numbers, from June 5 to June 16:

  • 57 dead
  • 88 open
  • 18 half open
  • 3 timed out
  • 1 refused

One TIPs came online in this period, at ARPA itself in Alexandria, VA. Again, there are not any notable changes in network host site uptime during this period compared to previous ones.

Analysis

Ellen Westheimer would produce just a few more of these reports before leaving BBN on August 4, 1972 to go back to school, as reported in her final RFC, RFC-376.

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 an independent technologist and artist. I do a lot of work on the decentralized web with ActivityPub, including a Node.js reference implementation, an RSS-to-ActivityPub converter, and a fork of Mastodon, called Hometown. You can support my work via my Patreon.

by Darius Kazemi, December 27 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.

Deamons [sic]

RFC-360 is titled “Deamon Process on Host 106”. It's dated July 5, 1972 and authored by Bob Bressler in his role as personnel working on the MIT Project MAC Dynamic Modeling Computer Graphics PDP-10.

The technical content

Bressler is letting the Network Working Group know that the MIT DMCG Host now offers the Echo Process and Discard Process proposed by Jon Postel in RFC-347 and RFC-348. These are not guaranteed to be working all the time: if the Host is too busy with other requests, they will refuse a connection. Connections will be closed after two minutes of inactivity.

Bressler also asks if anyone would like them to provide a random character generator, which he suggests would be useful for debugging new Network Control Programs or gathering statistics on the network.

Further reading

Bressler is referring to “daemons”, which as a computing term actually originates with MIT Project MAC, the computing group that Bressler is affiliated with. It comes from Maxwell's Demon (a famous thought experiment in physics) but the “daemon” spelling associates it with the ancient Greek concept of a daemon: a kind of guiding spirit, often the embodiment of a person's soul or a force within their soul. In the Greek context it is a sort of value-neutral entity, not necessarily good or evil.

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 an independent technologist and artist. I do a lot of work on the decentralized web with ActivityPub, including a Node.js reference implementation, an RSS-to-ActivityPub converter, and a fork of Mastodon, called Hometown. You can support my work via my Patreon.

by Darius Kazemi, December 26 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.

Finally, an RJE protocol

RFC-360 is titled “Proposed Remote Job Entry Protocol”. It's authored by Chuck Holland of UCSD and dated June 24, 1972.

The technical content

Remote Job Entry has been a resource on the ARPANET at least since RFC-88 was published in January 1971. But there has been no attempted at an official protocol to this point. All people had to work from were reference implementations and some prose description of how the system worked.

At the Data and File Transfer Workshop at MIT in April 1972, it was decided that RJE needed a published protocol. This RFC is the result.

Recall that RJE is a way to run arbitrary computing jobs on a remote Host computer. It is not that dissimilar in utility from cloud computing services offered by Amazon and others today. RJE supports both human users and nonhuman agents (which the spec refers to as “user processes”). This means they have both an interactive mode for human users, and what we would call an API today for computer agents.

The most interesting thing about this specification is that it makes use of many pre-existing protocols. Like most other protocol to dates, it uses the Initial Connection Protocol to start things up, but it also uses Telnet for all of its control mechanism, and it uses FTP to send and receive files.

Otherwise, the functionality of the specification is standard RJE as we've known it to date. But now it's all written down.

Analysis

In my post about RFC-354 I noted that it was the first time I'd ever seen error codes in the same numerical orgnization scheme as we use for HTTP today: 1xx is informational, 2xx is success, 4xx is unsuccessful, 5xx is illegal. But the RFC said it was based off of the RJE status codes.

There is some date confusion here: RFCs are not necessarily published in chronological order. So RFC-354 was published (or at least dated!) two weeks after RFC-360. So this document (and the workshop that produced it) may in fact be the ultimate origin of today's 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 an independent technologist and artist. I do a lot of work on the decentralized web with ActivityPub, including a Node.js reference implementation, an RSS-to-ActivityPub converter, and a fork of Mastodon, called Hometown. You can support my work via my Patreon.

by Darius Kazemi, December 25 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.

Continued failure to upgrade

RFC-359 is titled “Status of the Release of the New IMP System (2600)”. It's authored by Dave Walden of BBN and dated June 22, 1972.

The technical content

The new IMP software promised in RFC-343 still has not been successfully deployed! Walden says that on their first try, BBN completely underestimated the difficulty of deploying at 25 sites. On their second try, they deployed but encountered bugs and had to roll it back. On their third try, it worked except for Terminal IMP systems, so they had to roll it back yet agian. On their fourth try, it seemed to work but then mysteriously broke after 24 hours of operation.

They plan to try again soon.

Analysis

This is the most #relatable RFC ever written.

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 an independent technologist and artist. I do a lot of work on the decentralized web with ActivityPub, including a Node.js reference implementation, an RSS-to-ActivityPub converter, and a fork of Mastodon, called Hometown. You can support my work via my Patreon.

by Darius Kazemi, December 24 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.

Not issued

RFC-358 was never issued, even though its existence was promised in RFC-357. I think what happened was: 357 referenced 358, but they never got around to writing it. But because 358 was already referenced, the NIC couldn't just assign that number to the next available RFC, because the reference was in place and it would be confusing to go look up 358 thinking you'd get satellite uplink discussions and instead see something totally unrelated.

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 an independent technologist and artist. I do a lot of work on the decentralized web with ActivityPub, including a Node.js reference implementation, an RSS-to-ActivityPub converter, and a fork of Mastodon, called Hometown. You can support my work via my Patreon.

by Darius Kazemi, December 23 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.

Remote controlled echoing

RFC-357 is titled “An Echoing Strategy for Satellite Links”. It's authored by John Davidson of University of Hawaii, Will Crowther of BBN, John McConnell of ILLIAC, and Jon Postel of UCLA. It's dated June 26,1972.

The technical content

This is a formal, cross-institutional outcome of the discussion of high latency satellite links in RFC-346 and RFC-355. It describes an echoing strategy for Telnet over high latency connections.

Recap: remote echoing is when you type something, and it goes to the remote server, and then it comes back to you and what you typed is printed on the screen. Generally speaking, we like echoing because it confirms that the thing we typed is in fact the thing that the remote server thinks we typed! Modern ssh clients do full echoing, where you type a letter, and if there is a delay in the system your letter doesn't appear on the screen until you hear back from the remote host that it did register your keystroke. This can be annoying when your connection is bad, but generally connections in 2019 are far more reliable than connections in 1972 so it's not a huge deal. (There is also local echoing, where you type something on your local computer and it prints what you just typed: aka, how normal typing works!)

They recommend a fairly byzantine-seeming scheme for a Telnet client to specify its “wakeup character”, aka the character that indicates to Telnet to stop merely echoing locally and to send the entirety of the current character buffer. They call this scheme “remote controlled echoing”. The most clever thing about their design is that they essentially take the Terminal Handler, which handles local echoing, and generalize it into a remote system!

Analysis

This RFC also says that there will be more discussion published in RFC-358... but 358 was never published!

Further reading

Remote controlled echoing eventually will morph into the Remote Controlled Transmission and Echoing (RCTE) standard. This will be an optional standard that no Telnet system is strictly required to put into place: RFC-854, widely considered the first “stable” Telnet specification, mentions that “although options exist to enable a "remote" echoing mode of operation, no host is required to implement this option”.

I went looking and did find a reference to RCTE in the bowels of the PuTTY source code.

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 an independent technologist and artist. I do a lot of work on the decentralized web with ActivityPub, including a Node.js reference implementation, an RSS-to-ActivityPub converter, and a fork of Mastodon, called Hometown. You can support my work via my Patreon.

by Darius Kazemi, December 22 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.

24/7 support

RFC-356 is titled “ARPA Network Control Center”. It's authored by Ralph Alter of BBN and dated June 21, 1972.

The technical content

The Network Control Center (mentioned previously in RFC-218) is basically the help center that BBN runs for the ARPANET. If you are experiencing network troubles and you think the Interface Message Processor is the source of the issue, you should call them on the phone.

This RFC announces that the help center is now operating 24/7, and that people who call in should now be less likely to get a busy signal.

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 an independent technologist and artist. I do a lot of work on the decentralized web with ActivityPub, including a Node.js reference implementation, an RSS-to-ActivityPub converter, and a fork of Mastodon, called Hometown. You can support my work via my Patreon.

Enter your email to subscribe to updates.