365 RFCs

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.

Further 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.

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

Electronic mail: potentially useful

RFC-278 is titled “Revision of the Mail Box Protocol”. It's authored by Bhushan, Braden, Harslem, Heafner, McKenzie, Melvin, Sundberg, Watson, and White. (This is mostly the same committee in charge of the Data Transfer Protocol and the File Tranfer Protocol.) It's dated November 17, 1971.

The technical content

The Mail Box Protocol was originally proposed in RFC-196 by Richard Watson of the Network Information Center, and then updated in RFC-221 by Watson.

The committee met to discuss the Mail Box Protocol and the “potential utility for the mechanism was confirmed”.

The commitee has decided that the protocol needs to be limited to ASCII characters formatted for printers. Previously it allowed any kind of file attachment.

The protocol will make use of the new Attach With Create method outlined in RFC-265.

There's a new mail addressing format that lets you specify if you want to send your message directly to the printer at a site, or if there is a mailbox on the computer that you simply want to append your message to.

Terminal IMP users are not going to be able to use this protocol for a while, at least not for receiving mail messages.

Analysis

Just for context, before this there had been many electronic mail implementations within institutions, so for example a user of a Multics machine at MIT in the 1960s could send mail messages to other users of that machine. This is different because it's a mail protocol that lets you send messages from one institution to another, no matter what kind of computer or operating system you happen to be using.

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 4 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-277 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 3 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.

Online System course

RFC-276 is titled “NIC Course”. It's authored by Richard Watson of SRI-ARC and dated November 8, 1971.

The technical content

The Network Information Center is offering a class on using its Online System (NLS). This includes use of the Journal software, which I showed bits of in RFC-254 and was essentially a piece of early bulletin board or forum software.

They'd especially like administrative workers at various host sites to attend, the rationale being that they could then transcribe local documents directly into NLS and then the NIC could make those documents available to everyone on the ARPANET.

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.