RFC-57
by Darius Kazemi, Feb 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.
Edge cases
RFC-57 is called “Thoughts and Reflections on NWG/RFC #54” and is authored by Mike Kraley and John Newkirk of Harvard University. It's dated June 19th, 1970.
The technical content
As the title suggests, this document is related to RFC-54, although RFC-48 also plays a big role.
To jog your memory if you've been reading along with this blog, RFC-54 is the first ever submission of a formal specification as an RFC, and the authors of this RFC were co-authors on that document. RFC-54 was an attempt at a truly-really-definitely-official host-host protocol, which is the basic language that computers on the network use to talk to each other. This document is kind of an addendum to that host-host protocol. It contains ideas that arose during the writing of the protocol but were untested or under-discussed so they felt they should leave it out of the official protocol and instead discuss it in this separate document.
First, the authors distinguish between a “real error” and an “overflow condition”. Basically a real error is when there is an actual bug in the software or hardware that causes a problem. The idea there is someone messed up in their implementation and they need to fix it. An “overflow condition” is when, for example, there's a traffic jam on the network and messages can't be sent. Nobody did anything wrong here. There were simply too many people using the ARPANET at one time.
Specifically, in RFC-54 an overflow condition can trigger an error message that looks like a real error! So the programmer who gets the error message might waste a bunch of time looking for bugs in their code when really the problem was just congestion on the network.
They go on to specify a bunch of error types and error metadata that would make error messages far more verbose and useful for debugging.
The other section of the document proposes a solution for when a remote computer crashes. It needs a way to come back online and say, “hey, I had crashed but I'm back now, please don't forget about me.” These are provided through a proposed pair of RESET and RESET REPLY messages that broadcast out to the network when coming back from a crash or manual reset.
Analysis
Both of these proposals seem reasonable. If I were reading this RFC in June 1970 I would give it my vote of approval.
I had to laugh a bit at this paragraph:
Overflow does not require serious consideration if it is a significantly rare occurrence. We do not believe this will be the case, and we further believe that its absence will be an unnecessary restriction upon the user.
What an amazing double negative! My translation: “None of this will matter if traffic jams are going to be rare occurrences on the network, but we are pretty certain that there are going to be a ton of traffic jams so please listen to us.”
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 a Mozilla Fellow and I do a lot of work on the decentralized web with both ActivityPub and the Dat Project.