RFC-102
by Darius Kazemi, April 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.
The Glitch Cleaning Committee
RFC-102 is titled “Output of the Host/Host Protocol Glitch Cleaning Committee”. Its primary author is Steve Crocker in his role as Chairman of said committee. It's dated February 22-23, 1971.
A business note: my ten-month Mozilla Fellowship has supported this project up until now, but that has ended. If you like what I'm doing here, please consider supporting me via my Patreon.
The technical content
This committee was formed just a week before at the Urbana NWG meeting to tackle different Host-Host protocol issues, including:
- Echo
- Message type
- Interrupts
- Marking and/or padding
- Half duplex vs. full duplex communication during initial socket connection
I've discussed all of thes topics here before, and message types and marking/padding have had multiple RFCs devoted to them. So they're all pretty contentious issues.
The RFC is mercifully short and is truly focused on “output”, meaning the agreements that everyone came to about these problems.
- They settle on the bit length of several different commands.
- They agree to elimintate message data types from the Host/Host protocol, saying that these are more appropriate for higher level protocols.
- They get rid of
ACK (CEASE)which is a message that says “I got your message but I'm out of memory so please stop sending me stuff” - They add some commands so that a computer can tell another computer “I messed up, please disregard all your knowledge of what I'm doing because I have fully reset”
- They agree with RFC-64 and get rid of marking. They also state that the header (“leader” in their terms) of a message should be followed with a number indicating the length of the remaining message in bytes, along with the byte size. (Recall that there are all sorts of byte length computers at this point including 12-bit, 10-bit, 24-bit, and other esoteric numbers.)
- They want to implement a third-level interrupt code that is independent of the individual interrupt characters for computers. Recalling that some computers even interpret 250 milliseconds of silence as an interrupt command, it seems reasonable to side-step the issue entirely.
Some unresolved issues remain, too.
- whether to limit the length of control messages
- where to begin the first byte of data: should there be one message comprised of a header, byte count, and byte size, followed by padding and then the data itself? Or should there be two wholly separate messages, one with the byte count and byte size, and then a second message with the data?
- whether to change the algorithm for remote memory allocation
Analysis
Okay first of all: Glitch Cleaning Committee! What a cool name.
This meeting has been described (see “Further reading” section below) as the final settlement of the Host/Host protocol, which has been in flux for almost two years at this point, since RFC-1.
Also, this RFC mentions that the interrupt character on the PDP-10 is control+c, which if you're a programmer or just a command line terminal user you've probably encountered and perhaps use on a daily basis. I don't know if the PDP-10 is the originator of control+c to interrupt a program but that's pretty neat anyway.
Further reading
The ARPANET Completion Report describes the meeting of this committee:
At a NWG meeting held in mid-February 1971 at the University of Illinois, a subcommittee was appointed to look at the host-to-host protocol to see what changes were immediately desirable or necessary. This subcommittee went directly from Illinois to Cambridge, Massachusetts, where it met for two days, wrote an interim report, and then reconvened a month later in Los Angeles. It appears that with the efforts of this committee (known as the “host-to-host protocol glitch cleaning committee”) the design of the ARPANET host-to-host protocol was finally coming close to being settled.
So people flew from the Illinois meeting described in RFC-101 straight to Cambridge for this meeting! Anyway, this report is a 200 page document prepared in January 1978 to sum up the whole decade of the ARPANET project. There's lots of good stuff in there.
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 both ActivityPub and the Dat Project. You can support my work via my Patreon.