by Darius Kazemi, Feb 9 2019
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.)
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.
Now seems a good time to mention that this blog was partially inspired by Evert Pot's blog series on the HTTP status codes!