365 RFCs

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

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

Hope

RFC-289 is titled “What We Hope Is An Official List of Host Names”. It's authored by Richard Watson of the SRI-ARC Network Information Center and dated December 21, 1971.

The technical content

This RFC is “what we hope will be accepted” as the host names and nicknames for each host. Watson provides a brief history of how we got here, beginning with RFC-226. The current system of a short “formal name” and a long “nickname” is painted as a “reasonable compromise” that was reached at a Network Working Group meeting.

The list published here reflects input from “almost all sites”.

Analysis

Watson closes with this note:

I think people should feel free to change their host name when ever the situation warrants.

I smell trouble, though I could be wrong.

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, October 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.

More dismal results

RFC-288 is titled “Network Host Status”. It's authored by Ellen Westheimer of BBN and dated January 6, 1972.

The technical content

This is another report from BBN on the status of various ARPANET hosts in the same series as RFC-287, RFC-267, RFC-266, RFC-255, RFC-252, RFC-235, and RFC-240.

The numbers this time, from December 20 to December 30:

  • 85 dead
  • 29 open
  • 11 timed out
  • 11 half open

Analysis

Once again, even only measuring computers that have been online since the start of these measurments, the results are bad. Only 27% of measurements result in reaching a computer that is fully online.

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, October 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.

Dismal results

RFC-287 is titled “Status of Network Hosts”. It's authored by Ellen Westheimer of BBN and dated December 22, 1971.

The technical content

This is another report from BBN on the status of various ARPANET hosts in the same series as RFC-267, RFC-266, RFC-255, RFC-252, RFC-235, and RFC-240.

The numbers this time, from December 6 to December 17:

  • 94 dead
  • 29 open
  • 12 timed out
  • 14 half open
  • 1 refused

Analysis

These numbers look worse than previous weeks, even when we only consider computers that have been online since the start of these measurments: a mere 24% of measurements result in reaching a computer that is fully online.

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, October 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.

Network all the libraries

RFC-286 is titled “Network Library Information System”. It's authored by Ernest Forman of MITRE, and dated December 21, 1971.

The technical content

Georgetown University is building a digital catalog for their holdings, and the author floats the possibility of making this catalog searchable on the ARPANET.

He also suggests designing a general system to query all libraries everywhere that he calls the “Network Library Information System”. He asks interested parties to contact him.

Analysis

This is........ not a small task. To get a sense of how difficult this problem is (and I imagine that Forman, not being a library scientist, had little idea of the true difficulty), you can read about this history of the library catalog in American Libraries Magazine.

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, October 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.

Think creatively

RFC-285 is titled “Network Graphics”. It's authored by first-time RFC author Donald Huff of Case Western Reserve University. It's dated December 15, 1971. (This will be Huff's only RFC authorship.)

The technical content

Huff (who I believe was in the third year of his bachelor's program at the time of writing this RFC) is making an appeal to ARPANET users to think more creatively about their use of the ARPANET! In particular he points out that on the network, you could have one very powerful computer dedicated to graphics processing, with another very powerful computer dedicated to I/O and computation, and thus “graphics on the NET need not be anything like what we know it as now”.

He points to attention handling (aka interactivity) as a huge potential area of trouble in development of network graphics (these troubles are evident in RFC-178). Keeping data state in sync on both sides of a network connection presents problems.

He agrees that a simple drawing-based protocol is not enough for network graphics, and that organizational data like the scene graphs proposed in RFC-192 will be necessary for a complete network graphics protocol.

He comments on several papers that have been presented to the Network Graphics community thus far.

Lastly he proposes a general model for a network graphics system. It involves each of the user and server keeping track of graphics state locally, and thus they only need to synchronize at certain points (though in the case of interaction this may need to happen several times a second).

Analysis

I almost spit out my drink when Huff opens the RFC with “Not much has been written about graphics on the ARPANET”, but I suppose his point is that there are only about 20 papers and yet there are 8000 documents available on the Network Information Center thus far.

He's also pushing for something like what we'd in 2019 call cloud graphics computing, where an entire computer acts as a kind of GPU over the network!

The model he proposes at the end of the paper seems pretty reasonable to me.

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, October 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.

Not issued

RFC-284 was never issued.

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, October 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.

Jobs for TIPs

RFC-283 is titled “NETRJT — Remote Job Service Protocol for TIPS”. It's authored by Bob Braden of the UCLA Campus Computing Center. It's dated December 20, 1971.

The technical content

This RFC updates RFC-189 which was an interim set of specifications for the Remote Job Service at UCLA. In particular this update has to do with the Terminal IMP (TIP), which I've discussed before. It is essentially a cheap, read-only terminal that lets people who don't own a computer access the ARPANET by bypassing the “middleman” of a computer and going straight to the IMP.

The author says that despite the massive limitations of a TIP, including its inability to support file transfer, there could be a way for a TIP user to use the remote job service. Recall that the RJS lets you send computer programs to a remote computer in batches that are processed at some later time and then the results are returned to you. If a printer were connected to a TIP, then programs could be sent to RJS and then RJS could send the results back to the TIP's printer, which would print them out. (He outllines a couple other ways it could work but I don't understand them!)

The big differences between NETRJS and this new NETRJT for TIPs are that:

  • NETRJT actively sends data to the TIP when the data is ready
  • NETRJT does not assume that the user can “speak” the Data Transfer Protocol, and provides some of this functionality itself

The document closes with a detailed specification of how NETRJT is implemented.

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, October 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.

Quite hampering

RFC-282 is titled “Graphics Meeting Report”. It's authored by first-time RFC author Mike Padlipsky of MIT Project MAC and dated December 8, 1971.

The technical content

This RFC is the meeting notes from the long-planned and long-delayed Network Graphics Group Meeting at Stanford Artificial Intelligence Lab in late November 1971.

The document is divded into : reports on experiments, presentations, and the results of a discussion about a “first-pass” network graphics protocol. (Keep in mind that many have been proposed to date, but none accepted.) I won't mention everything here but I'll offer some highlights.

Experiments

RAND and UCSB demonstrate remote usage of the UCSB On-Line System via graphics terminals at RAND. They even show the film that they promised in RFC-225.

Several experiments are reported as having been “plagued with problems” ranging from difficulty coordinating people across time zones to software and hardware bugs. Jack Bouknight from University of Illinois expresses “concern as to whether the Network as a whole is as yet sufficiently reliable to support graphics work”. The Multics host is apparently the most reliable, and the consensus at the end was that the reliability of the network overall “is not crippling to graphics work, but can be quite hampering”.

Presentations

Various prepared talks include papers submitted ahead of time as RFCs, like RFC-178 on attention handling, as well as a presentation on issues in interactive graphics, a proposal for using Telnet for simple graphics, and how protocol needs are different for different kinds of graphics devices.

Protocol

A committee is formed to make a graphics protocol, modeled on the committee that made the (wildly successful, in my opinion) Initial Connection Protocol. There is agreement that a handbook should be prepared specifically for network graphics. General consensus is reached on some basic assumptions to be embedded in a network graphics protocol, including:

  • use of a virtual screen
  • origin (0,0) is in the center of the screen with coordinates being signed fractions
  • ASCII for text
  • absolute, relative, and local (relative to a defined sub-frame) drawing modes

The protocol will be concerned only with display to begin with. Later iterations will tackle interactive graphics. The functions discussed are kind of the usual suspects we've seen in earlier protocol proposals, very similar to what is found in say RFC-86.

They hope to convene a second meeting in mid-April 1972, at which point they would like to have a draft protocol.

Futher reading

This article published in 2000 by Mike Padlipsky is full of juicy, gossipy reminiscences of the Network Working Group, RFCs, and the NIC . It also addresses the various claims that so-and-so “invented” the internet or “invented” email. In particular he calls out the idea that Ray Tomlinson invented email, and claims that Tomlinson was not even present at the meeting where they all agreed to add mail to the FTP protocol.

In fact, according to Padlipsky, he invented (though apparently this is a controversial claim) anonymous FTP specifically to help people grab RFCs from the NIC:

I remember pretty clearly [..] being at SRI for some sort of meeting sometime around 1973 and being told that “the NIC” (or at least Jake [=Elizabeth Feinler – PHS]) was worried about this idea to put the RFCs on-line, because they'd have to establish all sorts of accounts so people could FTP them. “That's easy,” I said, “just use my NETML trick.” By which I meant, and went on to explain, that just as I'd had to propound a conventional universal “dummy” id and password [...] all the NIC needed to do was establish a single, known account everybody could use to slurp the RFC's from. “'guest' would be a perfectly fine id,” I went on, “and the password should be 'anonymous', since we'd gain some measure of security in that people'd have to know how to spell it and of course not everybody does.”

Padlipsky died in 2011.

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, October 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.

Restart

RFC-281 is titled “A Suggested Addition to the File Transfer Protocol”. It's authored by Alex McKenzie of BBN and dated December 8, 1971.

The technical content

This RFC proposes a “restart” procedure be added to the File Transfer Protocol of RFC-265.

Basically, FTP has been designed thus far for transferring maybe a few pages of text at a time. But Remote Job Services will potentially need to send a lot more data. To remind you, a remote job service is something that lets you connect to a remote computer, enter the code for a computer program, and then have it work on that “job” for some period of time and send you the results at the end. You might be asking it to work overnight making millions of calculations for you, and the result might be hundreds of pages of data. The remote computer needs to be able to send you the results, and FTP seems like a good way to do that.

But FTP right now doesn't have great support for sending huge files. So the idea of the “restart” procedure is to be able to start over if there's a failure during a massive file transfer. This wouldn't be a complete restart, but it might involve going back to an earlier chunk of the file where you're positive everything was going okay and starting over from there. The author proposes using the sequence numbers for messages as a way of both user and server agreeing on what this position should be.

This “restart procedure” requires the creation of four new FTP commands:

  • append at sequence number: begin appending data at a given point in the sequence
  • retrieve at sequence number: begin reading data at a given point in the sequence
  • use the sequence number: used as a reply to one of the above two commands, essentially saying “that sequence number you gave me was invalid, use this one instead”
  • resume retrieve: assuming we stopped retriving a file earlier, this says “start again on that file at a given sequence number”

One really interesting consequence is that this means sequence numbers and files must be stored on non-volatile storage so that they won't just randomly change during a file transfer. Seems like the kind of thing that people would already be doing but storage is expensive in 1971 so I guess it makes sense that they'd avoid using it wherever possible!

There's also a very nice set of use cases that explain what the back-and-forth communication between the user and server would look like. I wish more documentation in 2019 had stuff like this.

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.

Or, subscribe via email:

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, October 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.

Closure at last?

RFC-280 is titled “A Draft Set of Host Names”. It's authored by Richard Watson of SRI-ARC and dated November 17, 1971.

The technical content

Could this be it? The end of the arguments around host names? To refresh your memory, this has spanned eight RFCS over two months:

  • RFC-226: Standardization of Host Mneumonics [sic], Karp
  • RFC-229: Standard Host Names, Postel
  • RFC-233: Standardization of Host Call Letters, Bhushan
  • RFC-236: Standard Host Names, Postel
  • RFC-237: The NIC's View of Standard Host Names, Watson
  • RFC-239: Host Mnemonics Proposed in RFC #226, Braden
  • RFC-247: Proferred Set of Standard Host Names, Karp
  • RFC-273: More on Standard Host Names, Watson

Watson provides a list of Formal Names and Nicknames, per his RFC-273 guidelines. 17 of them are chosen by their host sites. The remaining 28 are assigned by the NIC.

Analysis

One thing that stands out to me is that MITRE clearly insisted on their institutional mnemonic being “MITRE” instead “MITR”, which means their institutional mnemonic is longer than the prescribed 4 characters. This just shows that a lot of flexibility went into this list in order to placate people and meet their emotional needs around what their host names look like.

Also, in his last RFC Watson wanted to have everything settled by November 5 but it looks like we're already almost two weeks past that deadline.

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.

Or, subscribe via email:

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.