365 RFCs

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

Protocols

RFC-295 is titled “Report of the Protocol Workshop”. It's authored by Jon Postel of UCLA and dated October 12, 1971.

The technical content

This RFC tells us what happened at the protocol workshop at the Network Working Group meeting in October 1971. Recall from RFC-212 that this workshop was part of the NWG meeting and was run by both BBN and UCLA people (representing, respectively, the IMP-Host Protocol of level one and the Host-Host Protocol of level two).

A proposal for an extension of the IMP-Host protocol to provide status reports (presumably on the IMPs themselves) was rejected due to its high cost and low benefit.

A bunch of edge cases in the Host-Host Protocol are explored and discussed. The GVB (“give back [memory]“) command has been a source of trouble for a long time. It seems like someone must have suggested removing it and pointed to the fact that literally nobody uses it as a justification. It was overturned because someone might use it in the future.

The authors suggest that some prohibitions be put in place on “spontaneous commands” in Host-Host, mostly ones that are meant to reply to another command. You can imagine that if you flooded the network with “yup I heard what you said” in response to nothing, that would result in a situation where another person could interpret that as a response to something unrelated that they just sent.

They recommend logging errors you get from a remote host instead of just throwing them away.

The Initial Connection Protocol is “found to be satisfactory” with only minor issues.

The Telnet Protocol needs a ton of work, which makes sense to me because all the Telnet documents to date seem woefully under-specified (by which I mean that any two people implementing Telnet software going off these documents have a strong chance of writing incompatible software). The usual suspects are brought up as pain points: definition of duplex modes, character vs line mode, funky ASCII stuff like what an end-of-line is supposed to look like, interrupts, the virtual terminal, and more.

Analysis

It makes sense to me that ICP is mostly satisfactory because it was the first protocol to be fully supported at basically every active host site (yes, even moreso than the host-host protocol).

They specifically ask for a new document defining Telnet, which I take as prodding to write a new document from scratch rather than merely modify the existing, shaky foundation.

Interestingly they agree that upper and lower case letters should be supported universally on Telnet! I guess that makes sense because why would you throw away nearly half the 7-bit ASCII characters?

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

Negotiating data types

RFC-294 is titled “The Use of 'Set Data Type' Transaction in File Transfer Protocol”. It's authored by Abhay Bhushan of MIT and dated January 25, 1972.

The technical content

The transcription of this RFC is incomplete and somewhat garbled so it's a little hard to interpret, but the gist of it is that Bhushan wants the “set data type” operation in the latest File Transfer Protocol, RFC-265 to be clarified, at least in the case of retrieving data.

As it's laid out in RFC-265, “set data type” is a command that identifies the data type and byte size of any following transactions. Bhushan says that this isn't clear and says that if it precedes a retrieve request, the server should interpret that as a request from the user to get data in a certain format, but that the request can be denied. Unfortunately the transcription cuts off at the point of saying what the denial should look like, though from the figure on page two I can guess that the server should send back its own “set data type” notification that tells the user what to expect instead.

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 20 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 numbers

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

The technical content

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

The numbers this time, from January 3 to January 15:

• 89 dead
• 50 open
• 12 timed out
• 9 half open

Analysis

Slight improvement in availability, with 31.2% of all attempted connections working, and 39% if you only count the original 12 sites that were measured by these tests. Even though there are 16 ARPANET sites that are online, only the ones at UCLA, SRI, MIT, and BBN can be said to have meaningful uptime.

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

First pass at graphics

RFC-292 is titled “Graphics Protocol – Level 0 Only”. It's authored by Jim Michener and Ed Meyer of MIT Project MAC, Ira Cotton of MITRE, Karl Kelly of University of Illinois, and Dave Liddle of Owens-Illinois. It's dated January 12, 1972.

The technical content

This RFC is a result of November's Network Graphics Meeting. The minutes of the meeting are already published in RFC-282. This RFC is documents a graphic protocol that they've landed on.

This is a “level 0” implementation of the protocol. The graphics committee defined this in the meeting as a protocol that describes only how graphics might be sent to a remote graphical display to be rendered. It doesn't cover interactivity. It also has nothing to do with the connection itself: this is simply a data format specification.

Because this protocol contains a lot of functionality, they are kind of ranking each chunk of functionality based on how hard it is to implement, and letting individual sites say “we support all graphics functions ranked level X and below at this site”.

The protocol works in 8-bit bytes. Commands are a command byte followed by some number of arguments. Individual arguments can be fixed or variable length. Arguments are typed and include “value” (a single 8-bit integer) and “string” (which is variable length).

Coordinates are sent as twos-complement fractions. I won't explain these in depth, and I can't find a good reference link for using twos-complement fractions, mostly because people don't often do that sort of thing anymore. But essentially it's a way to represent a fraction in binary and not use up a lot of bytes in the process.

In addition to being twos-complement, the coordinates are signed, meaning that they can represent a range of positive and negative numbers. The virtual screen that the protocol works with is a unit square, so if you can represent values between -½ and +½ on the X and Y axes then you can represent any value on the screen. Non-square hardware displays are supposed to take this data and use the largest square area they can on their given display.

A user can set the number of bytes used for coordinate data. This allows a user to send high-precision coordinate data as needed (basically the more bits you have, the more decimal points of precision you have in your data).

They very wisely decide to stick to atomic commands in the level 0 protocol. Specifically the rule is that the only outside information that can affect the output of a given command is the current beam position (the location of the pen, if you will) at the start of the command.

The list of commands is pretty similar to what we've seen in previous graphics protocol proposals, including: move beam, draw line to point from current beam, draw dot at point, display text. The only thing really different here is the inclusion of an “escape to device specifics” command, which is not recommended for use and lets you send device-specific commands if you know what device you're talking to (so like, on a dual screen device you could send its native command to start writing on screen 2 instead of screen 1 or whatever).

Analysis

The twos-complement fraction thing reminds me that all this is happening more than a decade before the IEEE 754 floating point standard was published.

I'm not sure if their “value” data type is signed or unsigned, or if it matters. I assume it would be signed since this is all stuff happening on a relative coordinate system around a 0,0 origin in the middle of the screen and having easy representation of negative numbers would be helpful, but that's just a guess. Also I guess if their coordinate data type is twos complement then that has negative value representation built in.

Apparently there was a ton of arguing about what commands get assigned which opcodes:

Each command in the graphics protocol will be assigned a non-negative value which will represent this command in the byte stream.  The algorithm whereby values and commands are associated is, it turns out, a very touchy subject.  There are five or ten different criteria for a "best" algorithm, each criterion different in emphasis.

This is hilarious to me, but also goes to show that so much of nitty-gritty computer programming is just emotional decision making. See also: the massive months-long debate about host site mnemonics.

Further reading

Owens-Illinois is a massive manufacturing company that specializes in glass. Of relevance to ARPANET is that in the early 1970s they manufactured plasma displays for interactive graphics systems. There will be more on this in a future RFC.

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

Speakers and protocols

RFC-291 is titled “Data Management Meeting Announcement”. It's authored by Douglas McKay of IBM and dated January 14, 1972.

The technical content

There will be a Data Management meeting from February 23 to 24 at MITRE in Northern Virginia. This is a followup to the meeting that was held in August 1971.

Apparently the last meeting highlighted the need to lern more about potential applications for data sharing, so there will be a series of talks from different groups explaining their use cases. The speakers include:

• Captain Roger Moore of US Army R&D Command speaking about medical file sharing.
• Dr. John Senior of the National Medical Board of Examiners speaking about sharing test results.
• Thomas McCauley of Hughes Aircraft discussing unspecified applications (tentative).
• Richard Watson of the NIC talking about the possibility of distributing the NIC archives across the network.
• Someone from MITRE talking about their work for the Internal Revenue Service.

The other piece of the meeting will be to come to agreements on a spec for a data management protocol. A tentative spec will be sent to attendees ahead of time and the plan is to discuss that rather than start from a clean slate. They encourage attendees to submit their own protocol specs as well. The idea is that this protocol will enable “indirect usage” in the RFC-114 sense of the word where users can simply interact with programs and not worry about the file system structure on a remote server at all.

Analysis

The meeting in 1971 never had any minutes or notes published as an RFC. It's an important reminder that while RFCs are important, they are a small slice of the communication happening inside the Network Working Group.

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 17 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 papers

RFC-290 is titled “Computer networks and data sharing: A bibliography”. It's authored by Alvin P. Mullery of IBM and dated January 11, 1972.

The technical content

This is another bibliography, similar to Mullery's RFC-243, and seems to be an update with a lot more papers. This RFC lists 115 papers compared to RFC-243 which had 65.

In particular, the data security section has 16 papers instead of the one paper he listed in RFC-243.

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