365 RFCs

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

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

Levels

RFC-49 is by Edwin W. Meyer, Jr. of MIT's Project MAC. It's dated April 25th, 1970 and titled “Conversations with Steve Crocker (UCLA)”.

The technical content

This document is a summary of two telephone conversations between Meyer, Crocker, and Thomas P. Skinner (also of Project MAC).

First off, Meyer explains that Crocker believes dynamic reconnection will eventually be accepted as necessary by everyone, which is consistent with Crocker's assertions in RFC-48. Crocker allowed dynamic reconnection to be temporarily set aside in the interest of cooperation with the other participants.

Next, Meyer talks about the interrupt (INT) command on the network. This was proposed by Meyer in RFC-46, Crocker supported it in RFC-48, and now Meyer is expanding on it a little bit and giving some more rationale for it. The details have already mostly been covered in previous RFCs.

There is some splitting hairs of whether including certain identifiers on sockets would be duplicating unnecessary information or not.

The fundamental design idea is repeated that the Network Control Program (basically, how you encode messages to send to the IMP) needs to send freeform data around. There will be no formal restrictions on character encoding or on message length.

Once again, preferences on how to deal with “word boundaries” (which I described in a little detail in yesterday's article are put forth.

Next we have a horrible name collision, as the document simultaneously refers to RFCs as Request For Comment and Request For Connection. It leads to a “who's on first” kind of situation where sometimes an RFC is a paper document and sometimes an RFC is a command that is sent over the network. Anyway, they talk about how they have now been convinced that a request for connection shouldn't be immediately rejected if a socket is busy; rather it should be queued for a little bit of time, and if the socket clears up in that time, it will be accepted.

The User Control and Communication protocol (UCC) that Meyer discussed in RFC-46 is (rightly, in my opinion) shot down by Crocker as far too complex. If you'll recall, this is supposed to be a way for a computer at one physical site to request that a computer at a different site start up a process/program. There is a significant discussion of several possible implementations of this idea. The main issue seems to be that they are highly concerned with keeping implementation of different “levels” of the network distinct. For example, Crocker offered a potential solution but Meyer and Skinner rejected it because caused a kind of leakage into the NCP level of things that should remain elsewhere. (The NCP is supposed to be fast, so the less responsibility it has, the better.)

Analysis

In addition to the tension in not causing overlap between different “levels” of the network, there is also a tension in keeping things standardized versus letting everyone do what they want. According to this document, Crocker proposed that everyone could implement their own UCC or UCC-type thing. Project MAC wants everyone on the same network software so every computer can talk to every other computer. These tensions are not resolved in this document.

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.

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

Plateaus

RFC-48 is by Jon Postel and Steve Crocker. It's dated April 21st, 1970 and poetically titled “A Possible Protocol Plateau”. This RFC is their attempt to synthesize the suggestions and comments from everyone in the Network Working Group over the last month or so. They have about ten days to settle the matter before they present their paper at the Spring Joint Computer Conference in Atlantic City.

The technical content

The paper tries to enumerate the various concerns brought up by the group.

The first concern is around padding of messages. The basic problem is: if my HOST's hardware is only capable of sending whole “word” messages (so perhaps messages that are multiples of 8 bits in length), what do you do when you want to send a message that is like 12 bits in length (which is halfway between 8 and 16 bits)? The IMP was built assuming that messages would be sent in these kind of round numbers, but that's not actually the case. It would be an expensive and inconvenient hardware fix to change how the IMP works so various software-level solutions are discussed. Postel and Crocker have no strong preferences as to which of these are used.

The next concern is reconnection (which is not “my modem hung up and I have to reconnect” but rather the process of connecting processes and peripherals to each other and then again and again). Specifically, Crocker's “dynamic reconnection” proposal in RFC-33 has been pushed back on very hard by multiple people at multiple institutions over the last month. The authors acknowledge this:

A very large population of networkers has beat upon us for including dynamic reconnection in the protocol. We felt it might be of interest to relate how it came to be included.

The authors then compare the standard literature on the problem of reconnection to the actual implementations, strongly implying that the theoretical literature doesn't help much in the real world.

There is a three-page defense of the idea of dynamic reconnection, along with a slight modification to how it was originally proposed. The section concludes: “We are agreed that reconnection should not be required in the initial protocol, and we will offer it later as an optional and experimental tool.”

(As a reader I was not expecting this capitulation at the end of a thorough and impassioned and long defense!)

The next issue is whether links and connections should be tightly coupled, basically whether a connection (which is a software construct) should be tied to a specific link (which is a hybrid software/hardware construct). The original proposal had them tied to one another; two working group members suggested decoupling them. The author say they can't picture a solid reason why decoupling would be useful so they suggest that the link and the connection remain coupled in the interest of simplicity.

Another issue is the error messages proposed in RFC-40. The authors agree that error messages are good and they should have them. However, they suggest some tweaks on the basis that certain things tagged as “errors” in the proposal aren't “true errors” and so should probably send a different kind of message.

They also recommend that error messages be logged locally on the server and only optionally sent back to the user. Their worry is error messages will just clog up a system that is by definition already having problems. Also they are confident that the IMPs will generate very few errors, with most errors coming from HOSTs or NCPs (the software interface between the HOST and the IMP).

The next issue is figuring out ways to debug when something goes wrong on the network. They suggest reserving link 255 (the highest link) for these messages and sending an ECO (“echo”) request to a HOST. The idea is you send a brief message, and if the HOST is online, it sends a copy of the message back (hence “echo”).

To address issues of experimentation, they suggest that links 2 through 31 be used for regular network communication, with links 32 through 255 reserved for, basically, messing around and testing new network protocol stuff. They reject the idea of typed messages proposed in RFC-42

The next part is in relation to questions about sockets and ports on HOSTs brought up by working group members. The authors remind the other implementers that they fully intend for HOSTs to be idiosyncratic and any implication that the internal systems of a HOST should work one way or another is just a convenient illustration and not meant to be taken as a requirement.

The next part is a little mind-blowing. They designed the network assuming that important signals would all be, you know, encoded as data. And therefore able to be assigned an ASCII character. Turns out that some hardware (model 37 TTY's and the IBM 2741) communicates the concept of a hardware interrupt (“drop what you are doing and pay attention to the next message”) as a “long space” AKA just 250 milliseconds of silence. I like to save my editorializing for the Analysis section of these blog posts but: WHAT??? This is so weird to me. It's like your mom saying “if I don't hear from you for 24 hours I'm going to assume you've been murdered.” Moms shouldn't do this, and neither should computers.

Anyway, this necessitates a special interrupt command, which they then propose.

They reject a broadcasting feature proposed by RAND because they fail to see the use of it. (Understandably, because RAND did not provide a use case in RFC-39.) And they reject what they see as another over-complicating feature from Meyer in RFC-46.

And finally they admit that “AEN” (Another Eight-bit Number) is probably a really bad name. They are open to replacements.

The remainder of the paper lays out a suggested implementation on the HOST side of the NCP and other entities but the authors note

that this material is offered only to provide clues as to what the implementation difficulties might be and not to impose any particular discipline.

Analysis

The authors are very clear (and have been since day one) that HOSTs are essentially allowed to do whatever they want as long as they play nice with the IMPs and the rest of the network. This is one key to what makes ARPANET different from networks that predate it, which were communications between nearly identical computers.

It shows what an experimental network ARPANET was that they suggest the group dedicate 87.5% of the network capacity to experimentation and only the remainder to basic communication!

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.

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

Potential embarrassment

RFC-47 is by Jon Postel and Steve Crocker, although the author of the actual content is William Crowther. It's titled “BBN's Comments on NWG/RFC #33” and it does what it says on the tin. It's dated April 20th, 1970 (b-blaze it?).

The technical content

The document opens with a note from Postel and Crocker:

BBN has given us the attached comments on NWG/RFC 33, but wouldn't publish them being relectant [sic] to embarrass us. Embarrassment notwithstanding, we found the comments particularly useful and decided to share them with our friends. Bill Crowther is the author.

The remainder of the document is Crowther's commentary. He is a designer of the IMP (Interface Message Processor, the router-like thing on the network) and he's pointing out some misunderstandings in Crocker's RFC-33 paper about how the IMP works.

He first establishes that they want to make it so that traffic jams (my term) don't happen on the network, but it's really hard to do so they've had to resort to some complicated signaling about when messages are ready to be sent (the RFNM, request-for-new-message). They've also reluctantly had to add buffers to hold network packets temporarily in place, which slows down the transmission but can clear up a traffic jam.

The RFC-33 paper states that a single HOST or process shouldn't take up multiple links on the IMP, but actually the IMP is designed for that use case. If you need more links for more bandwidth, you are welcome to grab those.

The IMP has a memory buffer for its dedicated HOST but the buffer can only hold three full length messages at once. So the HOST needs to empty out the buffer as fast as possible, to the point where Crowther “violently” insists that “the IMP's buffers must be empty or they are not serving their communication purpose.”

Crowther also corrects a complaint in RFC-33 that the communication channels lock up for 80 milliseconds at a time. He notes that the 80 milliseconds is a hardware default, which can be changed (and presumably shortened) by using a screwdriver to adjust a screw in the IMP!

Analysis

Because of the way RFCs are filed, sometimes the “author” of an RFC only wrote a small percentage of the text. This is why I try to say so-and-so “authored” an RFC rather than “wrote” an RFC unless it's obvious to me that the author is also the writer of the document. For example, this RFC may have Postel and Crocker listed as the author, but the bulk of the content was written by Crowther.

What I'm getting from Crowther's insistence on the IMP buffers needing to be essentially empty at all times is that they really aren't much of a buffer at all. It's almost more like a little swap space that happens to look and act like a buffer but has other primary uses. I imagine the mechanic's repair pit at a car race: while it is a flat asphalt area where a small number of cars can park, it is not a parking lot. Cars are supposed to go in and out of there as quickly as possible and get back into the race.

On the note that opens the RFC: I spoke with Steve Crocker a little bit about this, and he related that the BBN folks were essentially a lot more formal in what they published and tended to not just throw out ideas to see what stuck (at least externally; internally there was lively exchange of ideas from what I've read of their own accounts). Crowther sent him the notes privately because he didn't think they were appropriate for a public channel but really they were in the exact spirit of the RFC project. Recall the ground rules from RFC-3:

The content of a NWG note may be any thought, suggestion, etc. related to the HOST software or other aspect of the network. Notes are encouraged to be timely rather than polished. Philosophical positions without examples or other specifics, specific suggestions or implementation techniques without introductory or background explication, and explicit questions without any attempted answers are all acceptable. The minimum length for a NWG note is one sentence.

Further reading

I found this BBN quarterly technical report for January 1st 1970 through March 31st 1970.

On page 7 of the report we see exactly what Crowther was relating to the Network Working Group in his notes:

The network can be described as a taut communication system in the sense that each message entering the net proceeds directly to its destination. We observed that messages do not wander about the net, even at high traffic loads. The net easily handles sequences of single-character messages typed at the IMP teletype.

Interestingly, there is a further note on page 8 that states that buffers get really full during

the use of multiple links by a Host (for fanning messages), which causes a large part (or all) of the source IMP's store and forward buffers to be filled.

This seems to somewhat contradict Crowther's insistence that the IMP is absolutely meant to support multiple links per host! And this is from a report written right around the same time this RFC was.

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.

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

A power move

RFC-46 is by Edwin E. Meyer, Jr. of MIT's Project MAC. It's titled “ARPA Network Protocol Notes”, and is a bit of a latecomer in the “feedback on RFCs 33 and 36” genre.

The technical content

This is 16 pages long. Sigh. I will do my best to summarize. The main points seem to be:

  • the dynamic reconnection system is confusing and should be put off to a later date (echoing what previous commenters have said as well)
  • they like the error messages outlined in RFC-40
  • processes should be interruptable (for example, if a process is locked up you should be able to kill it)
  • stateful sockets
  • the creation of a User Control and Communication subsystem on a HOST that is in charge of starting up processes on foreign HOSTs

There is a colophon at the end of the document that says this document is prepared using RUNOFF and QED.

RUNOFF is an early document layout program that influenced roff and then nroff and groff, among other programs. I had never heard of these programs before this project, but if you are on MacOS you can open your terminal and type groff and you probably have it installed!

QED is a line-level editor (a text editor that only operates on a single line of text at a time) whose immediate descendent ed is ALSO probably on your MacOS machine or other unix-like system.

Analysis

This document is kind of a power move? Instead of just providing suggestions for improvements to the protocol, this is a rewrite of the entire protocol with the suggestions already included. It's the difference between writing to your favorite novelist saying “please include my original character in your novel” and rewriting the whole novel with your character in there and sending them that as a suggested improvement.

So even though this is 16 pages long, I'd say 70% of it is rewording or slight technical tweaking of things that have been expressed in previous RFCs.

The official transcription is completely missing Figure 3! Here is a photo I took of Figure 3 at the Computer History Museum:

Communication paths between requestor process and logger and created process at foreign HOST. A flow diagram.

Further reading

There's a great history of the still-heavily-used text editor Vim called Where Vim Came From that goes into the details of how QED influenced the entire family tree of text editors. For exampled, QED begat ed, and if you want to write a buffer to disk in ed, you need to type 'w', and if you want to quit you have to type 'quit'. This is where the famous :wq command in Vim comes from.

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.

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

See you in Atlantic City

RFC-45 is by Jon Postel and Steve Crocker of UCLA, dated April 14th, 1970. It's ominously titled “New Protocol is Coming”.

The technical content

Postel and Crocker are giving the RFC participants two weeks' notice that they will be sending out what they hope is a final version of the new HOST-to-HOST protocol based on the feedback they've received in the last couple months.

They suggest that since pretty much everyone is going to be at the Spring Joint Computer Conference in Atlantic City, New Jersey, that they meet there in the afternoon of May 7th to discuss the protocol. That morning everyone is expected to attend Larry Roberts' network session to see the latest and greatest computer networking papers, including a paper on the protocol itself.

The afternoon meeting is “for everyone to exchange gripes, suggestions and schedules.”

Analysis

At this point, we have read through a whole calendar year's worth of RFCs! The first RFC is dated April 7th, 1969, and this is one year and one week later. So we've averaged a little less than one RFC per week in this first year. And remember, this whole time it's been distributed via the postal service.

Further reading

The Joint Computer Conference was a big deal for about 30 years. It used to alternate between the east and west coasts of the United States. For a while they were known as the Eastern and Western Joint Computer Conferences, then as the Spring and Fall Joint Computer Conferences, and then finally merged into the National Computer Conference.

For your perusal: all 739 pages of the full conference proceedings of the 1970 Spring Joint Computer Conference. The ARPANET related papers are on pages 543 to 597 (those are the paper page numbers, jump to page 553 in the PDF).

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.

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

A word from SDC

RFC-44 is from System Development Corporation, a group I've mentioned before in the context of them being an ARPANET contributor and the first ever company dedicated entirely to the creation of computer software. We don't hear from them often in the RFC series. This one is authored by Arie Shoshani, Robert E. Long, and Abe S. Landsberg, titled “Comments on NWG/RFC 33 and 36”, and dated April 10th 1970.

The technical content

This document provides commentary on the new HOST-HOST protocol proposed by Crocker et al in RFC-33 and RFC-36.

First they propose simplifying the new dynamic reconnection mechanism (recall there was much dismay at how complex it was) by allowing it to work for reconnecting different sockets within the same physical HOST machine, but not for reconnecting sockets in different HOST machines. They claim the usefulness of the latter is in doubt but don't explain why (although I'll note that at least according to a SDC document I link in “Further reading” below, it wasn't until 1971 that “interprocess communication” between two separate HOSTs was fully tested).

They offer a few suggestions for streamlining the new protocol, mostly by removing what they consider to be redundant information.

They also highlight a few other protocol issues and that they would like people to at least agree on a date to resolve them, as the problems were brought up two weeks ago at the UCLA network meeting “but were put aside.” The most significant one is around encoding: they believe that ASCII-8 (USASCII, I presume) will not suffice for all applications, especially for transmitting graphics over the network. They propose that ARPANET keep using ASCII for now but that a Network Common Code should be phased in. They don't explain the details though.

Analysis

The authors note that in “RFC#33 the term PORT was introduced.” I wonder then, was that the first usage of the term PORT in the context of computer networking?

Further reading

I found a 1971 System Development Corporation report summarizing six months of ARPA-funded computing research at SDC. (It's dated April 15 1970 on the cover page but has 1971 listed through the rest of the document.) It's from almost a year after this RFC but I'm including it anyway because it's a fascinating snapshot of the state of computing at the time. They use the word “data base” but not as a compound; incidentally E.F. Codd was essentially in the process of inventing relational databases in the period 1970 to 1972, and he also used the term “data base”. See his 1970 paper (PDF) if you're curious.

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.

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

A meeting at Lincoln Laboratory

RFC-43 is by Alan G. Nemeth of MIT Lincoln Laboratory, dated April 8th 1970. It's titled “Proposed Meeting”.

The technical content

This RFC is proposing a meeting at Lincoln Laboratory in Lexington, Massachusetts to discuss the Local Interaction Language (LIL). It is yet another attempt to provide rich applications over the ARPANET.

Analysis

I can't find any real records of Local Interaction Language in significant use anywhere outside of MIT L.L., which leads me to believe it was mostly dead in the water like the Decode/Encode Language and the Network Interface Language.

Further reading

The full paper from Licoln Laboratory describing Local Interchange Language can be found in their May 31st 1970 semiannual technical report titled “Graphics”.

Here's a photo of Alan Nemeth working with Carma Forgie at Lincoln Laboratory, date unknown:

Since this is, according to the caption, a photo of people doing time-sharing on the TX-2, the photo is probably from the early 1960s. Fun fact: the TX-0 and TX-2 computers were the basis for DEC's PDP-1, the first of which was purchased by BBN in 1960 for $150,000, approximately $1.2 million in 2019 money. It was even leased rather than purchased outright, and as recalled by Leo Beranek (the second “B” in BBN), the company bought the computer because they knew it would be useful, but they didn't have any contracts for it at the time. They had to go out and get the money to pay for it after the fact.

The photo is from the 2011 MIT Lincoln Lab retrospective that I've linked here before, and the BBN tidbit is from this history of BBN edited by Dave Walden and Ray Nickerson.

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.

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

A proposal for typed messages

RFC-42 is authored by Enrico I. Ancona of MIT Lincoln Laboratory on March 31st, 1970. It's called “Message Data Types”.

The technical content

This document proposes that the first 8 bits of any “normal” message is reserved for a code that tells you what kind of message will follow. It proposes translation programs on the receiving and sending end of messages that add the data type to a message (on the sending end) and decode the data type (on the receiving end). This is a little bit like what MIME types do for HTTP messages today, so a web browser knows if it's dealing with text or an image or video et cetera.

Ancona provides a way for this system to be extensible, so that different HOST systems could make their own data types available to other HOSTs.

Specifically this proposal is framed in terms of a feared explosion of potentially conflicting technical conventions:

It is important that conventions regarding the contents of messages be set up early so that there will not be a large proliferation of such conventions between every pair of programs running on the network.

Analysis

The document opens with a bit of art that, in my opinion, is far better in the original than in the normalized official ASCII art version. Here's a photo I took at the Computer History Museum's archives:

Compare to the ASCII art version:

        Socket    Port
        |    |      |    ____________
        |    V      V   /            \
        V              /              \
            |=|    /==|                |
-------(+)->|Y|--><   |                |
            |=|    \==|                |
                      |    PROCESS     |
                      |                |
            |=|    /==|                |
-------(-)->|X|<--<   |                |
            |=|    \==|                |
                       \              /
                        \____________/

You'll also note a transcription error in the diagram! The original “Socket” label is clearly pointing to the (+), with another arrow to its right that has been crossed out. In the transcribed official version, both arrows were left in, with nothing to indicate that the second arrow under “Socket” was crossed out.

In general I found this RFC a bit light on details and kind of hand-wavey, making promises for future compatibility that I can't really see evidence of in the proposal itself.

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.

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

Please provide timestamps

RFC-41 is by John Melvin of SRI/ARC, dated March 30th 1970. It's called “IMP/IMP Teletype Communication”.

The technical content

Melvin is referring to an “annoying” thing that happens when he gets messages to his teletype via the IMP. The messages aren't stamped with the date and time, so he has no idea if it just came in or if it's several days old and would be pointless to respond to.

He implores people to tag their messages with at least the 24 hour time and time zone.

Further reading

This specifically mentions teletype communication. I think I've mentioned here before but a teletype is a kind of typewriter that is hooked up to a communications line. You type into it like a normal typewriter, onto paper, but it also sends those messages out. It receives messages back and types them back at you, kind of like a player piano. Here is a four-minute video that demonstrates what it's like to program a computer by teletype:

Teletype, incidentally, is a brand name that eventually came to be associated with the entire category of product. Technically these are teletypewriters or teleprinters, and “Teletype” is a brand, but like Kleenex and Xerox, everyone just used the brand name.

There's a really beautiful 40-page illustrated brochure called “The Teletype Story”, published by the Teletype company in 1957 for its 50th anniversary.

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.

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

Detailed errors and statuses

RFC-40 is by Eric Harslem and John Heafner of RAND and is a direct follow-up to their RFC-39, in response to a request from Steve Crocker to provide more detail. It's called “More Comments on the Forthcoming Protocol” and is dated March 1970.

The technical content

They specify the error codes more precisely here, assigning numeric ranges to them:

The ranges of <Code> are shown below in hexidecimal.

     00     Unspecified error types
     10-0F  Resource errors
     10-1F  Status errors
     20-2F  Content errors
     30-3F  Unused

(I assume that first 10-0F should read 01-0F. Unclear if that was a transcription error or an error in the original doc.)

The document goes on to list the specific errors and codes, which I won't repeat here.

They expand the definition of the “query” command to specify the payload of the text field, which wasn't specified in RFC-39.

They seem to change the mechanism of the HOST Status command from a kind of interrupt driven thing (“I am up! I am down”!) to a more passive thing where when a HOST goes up it broadcasts a message to all the NCPs which have to keep track of the state of the remote HOSTs. I think. I could have this wrong, it's possible this is an additional feature on top of the ones described in RFC-39 rather than replacing the functionality. (At least I kind of hope it is, requiring everyone to keep state like that seems... a lot.)

Analysis

Assigning numerical ranges to errors using the most significant digit to categorize them is really similar to what we see today with HTTP status codes:

100 - 199 Informational
200 - 299 Success
300 - 399 Redirection
400 - 499 Client Error
500 - 599 Server Error

This way even if you don't personally remember what an error 474 is, you at least know it's a client error before looking it up. I'm sure it was common practice in computing long before this but it's interesting to note these parallels.

Further reading

Now seems a good time to mention that this blog was partially inspired by Evert Pot's blog series on the HTTP status codes!

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.