365 RFCs

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

A data sharing committee

RFC-146 is titled “Views on Issues Relevant to Data Sharing on Computer Networks”. It's authored by Peggy Karp and D. C. M. Wood of MITRE, and Douglas B. McKay of IBM and dated May 12, 1971.

The technical content

This RFC opens by concurring with Arie Shoshani's suggestion that a committee be formed to discuss data sharing on the ARPANET.

One thing this RFC does that Shoshani does not is make the explicit connection between data sharing and Bhushan's file transfer protocol. In addition to Shoshani's technology-oriented classifications of data sharing, these authors propose user-oriented classifications of data sharing. Their three use cases are:

1. Hosts provide data handling to the user, such as discussed in Jim White's Simple-Minded File System described in RFC-122. The user logs in directly to some service on a remote host to manipulate files.
2. The user talks to a remote program that doesn't require knowledge of the file system. It's a “data control facility” (either centralized or decentralized) that provides specific higher-level data services. One example is the Data Reconfiguration Service proto-API discussed in RFC-138.
3. The user plugs into the network as a whole and just asks for files “by name” willy-nilly, not caring where they come from. This is ultimately pretty similar to the World Wide Web, where you can, for example, load an index.html from one server which embeds image files from a bunch of other servers. The “by name” seems to imply a system like the URIs we have today. They cite RFC-51 as something close to this, and RFC-51 is pretty much the only RFC thus far that I completely could not understand! This is conceptually a really advanced topic and I think a lot of the descriptive language for it just isn't here in 1971.

They recommend that the committee be responsible for discussions regarding:

• File transfer
• Transfer of existing databases to specialized data computers
• Ways to define restructuring of data
• Data transformation (such as the Data Reconfiguration Service)
• Maintenance of data consistency across duplicate copies of data on multiple network sites
• Data privacy and access control

Analysis

Later in the RFC they mention that a “data control facility can range anywhere from a simple interface to an intelligent front-end processor to a network-wide referral system.” An “intelligent front-end processor” sounds to me a lot like a web browser, and “a network-wide referral system” sounds like URIs.

Given all of this focus on interactivity or potential interactivity it's no surprise that they also cite RFC-5, which if you'll recall is the Decode-Encode Language, which was a very early proposal for a rich application layer.

Further reading

I am 99% sure that the D. C. M. Wood who co-authored this paper is the same David C. Wood of Mitre who wrote this 1975 paper on packet-switching networks. It's a really interesting paper and is a great overview of eight different pre-Internet networks—many (all?) of which would eventually be connected into what we now know as the Internet.

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.

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

Initial connection correction

RFC-145 is titled “Initial Connection Protocol Control Commands” and is by Jon Postel of UCLA. It's dated May 4th, 1971.

The technical content

This updates Postel's RFC-127 Initial Connection Protocol algorithm to correct for an error pointed out by Eric Harslem of RAND. It does not address the issue brought up in RFC-143.

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.

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

Data sharing

RFC-144 is titled “Data Sharing on Computer Networks” by Arie Shoshani of System Development Corporation. It's dated April 30, 1971.

The technical content

This RFC is referenced in RFC-140 as an RFC “yet to come by Shoshani” (no pressure, Arie). It's meant as discussion fodder for the Tuesday morning session on the Data Reconfiguration Service and Data Management System during the upcoming Network Working Group meeting.

The RFC is to provide an introduction to concepts of data sharing among users of a computer network.

The author implies, via a list of implementation considerations, that a data sharing system should be:

• uniform (you access data on one part of the network the same way you do on any other part of the network)
• encouraging of regular use
• compatible with existing data systems
• resilient against network failure
• extensible
• fast

Four possible approaches are laid out.

1. Centralized data management system (CDMS). This is a computer or a set of computers that are tasked with providing data sharing services for the entire network. The idea is that most computers would not handle data sharing, but would talk to these network resources to do it for them instead. This is kind of like how an iPhone uses iCloud to handle data sharing.
2. Standardized data management system (SDMS). This is where all computers use the exact same local data management system. Sort of the equivalent of saying “every computer must use file system X with database software Y”.
3. Integrated data management system (IDMS). This would be some kind of protocol that allows a local data management system to talk to a remote data management system. This is similar to modern specifications like GraphQL.
4. Unified data management system (UDMS). This seems to me like the same thing as the IDMS? I'm unsure of the difference.

They suggest that if a common language for data management is to be designed, it should perhaps be offered in two layers: an easy-to-use high level language, and then a more formal “intermediate language” that programmers can use if the high level language isn't expressive enough for their needs.

The author suggests the IDMS approach as the best way to go, though the author's brief coverage of the UDMS approach leads me to believe that he is perhaps as confused as I am as to what the differencebetween the two is.

Analysis

This document presumes that people already know what data sharing actually is, and thus never defines it, which… seems counterproductive.

Further reading

If you're wondering what SDC has been up to around the time of this RFC, here is an April 1971 report that they submitted to ARPA on the status of their various ARPA-related projects including many related to the Network.

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.

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

Race conditions

RFC-143 is titled “Regarding Proferred Official ICP”. It's authored by William Naylor et al., and dated May 3rd 1971.

The technical content

This RFC points out a race condition in the Initial Connection Protocol. “The problem arises when the server attempts to initiate a second connection to the user's receive socket and the first connection is not yet closed.”

They offer a solution to this race condition that removes a user-level “close” command, instead allowing the user's NCP to solely handle it based on some new prerequisite connection state stuff.

They point out another underspecified condition and recommend that if connection is remotely closed, the local user should be notified of it somehow (either through a message from the remote host, or perhaps by a polling mechanism to the remote host).

There is a snarky comment at the end (okay it's not written snarky but I read it as snark) that if dynamic reconnection as proposed in RFC-36 had been implemented, none of this would be a problem.

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.

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

Time out

RFC-142 is titled “Time-out Mechanism in the Host-Host Protocol”. It's authored by Charley Kline and Johnny Wong of UCLA and dated May 3rd, 1971.

The technical content

The issue at hand here is related to an error case not specified in the Host-Host protocol. Namely: what happens when no messages are sent over the connection for a long time? In other words, what happens when the connection stalls for some reason? That's qualitatively different from an error message.

They suggest the following algorithm.

• if you request a connection and don't get anything back from the remote host in T seconds (standard across the whole network), then you should send out the “close connection” command
• if you don't get acknowledgment of the “close connection” command you just sent within T seconds of sending it, then you should assume the connection closed

The problem here is that if you assume the connection is closed, then you reconnect on the same socket, and then you get a response from the server for some very old message you sent in the previous session, then that is a confusing situation. There's no way to truly know if this new response is related to the old session or the new session. The authors are merely bringing this confusing situation to light and asking people for ideas for solving it.

Analysis

My suggested solution is: don't reconnect on the same (local) socket after you close a connection. This would prevent this weird race condition from happening in the first place.

Hopefully we will see the answer to this in a future RFC.

Further reading

This is the first RFC authored by Charley Kline, who was apparently the person who sent the first message over the ARPANET. Here is an All Things Considered interview with Kline about that message and ARPANET in general.

I have more information about Johnny Wong in my RFC-117 post.

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.

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

Nine comments on file transfer

RFC-141 is titled “Comments on RFC 141 (A File Transfer Protocol)”. It's authored by Harslem and Heafner of RAND and dated April 29th, 1971.

The technical content

The authors have provided 9 short numbered comments, so I'll just summarize each short comment by its number here.

1. FTP is needed.
2. Bhushan's proposal in RFC-114 seems like a good one.
3. FTP should be able to access even files not created via FTP and perhaps this should be in the spec.
4. In addition to being able to append to a file, they'd like support for arbitrary insertion, deletion, and replacement within a range of a file.
5. They'd like to be able to get a list of all available files owned by the logged-in user.
6. Since there is an “execute” function, FTP should provide status information on the job executed similar to the remote job entry system.
7. They offer specific recommendations as to what context remote execution should happen in.
8. They request as large an information dump as possible upon abnormal termination (of an execution, I think, though it could mean a connection) in order to aid debugging.
9. They'd like some specific examples of experimentation with the Bhushan's protocol to date at MIT, since it was mentioned that MIT has done some experiments.

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.

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

Atlantic City agenda

RFC-140 is titled “Agenda for the May NWG Meeting”. It's authored by Steve Crocker and dated May 4th, 1971.

The technical content

This is the agenda for the big Network Working Group (NWG) meeting that is being held in two weeks' time. It's co-located with the Spring Joint Computer Conference in Atlantic City, meant to take advantage of the fact that a lot of the people involved in the ARPANET will be over there anyway.

There will be discussion of the usual suspects: the IMPs, various file transfer protocols, Telnet, the NIC, data reconfiguration, initial connection protocol, and long-range planning for the network. This has all been planned for in previous RFCs, especially those related to committee work, so I won't go into detail on these items.

Interestingly, discussion time is set aside for people to talk about the similarities between operating system protocols and network protocols! Because coordination over the network is about remote processes talking to each other, these protocols “are similar to interprocesses [sic] communication faciities within operating systems.”

Peggy Karp of MITRE is going to talk about a data management system she is building.

They also plan to spend an evening talking about the NWG itself and how it is “perhaps not optimally organized for technical work.”

Analysis

I'm impressed that this agenda mostly tracks with what they planned a month prior.

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.

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

Telnet context

RFC-139 is titled “Discussion of TELNET Protocol”. It's authored by Thomas O'Sullivan of Raytheon and dated May 7th, 1971.

The technical content

This RFC provides additional context to RFC-137, which is a proposal for a Telnet protocol. This seems much-needed, since my comment on RFC-137 was that “I can't figure out how any programmer could implement a Telnet program based off of this.” This document comes with a disclaimer that it is simply commentary and not meant to be taken as specification.

Apparently there was a lot of divisive discussion on the Telnet committe. Tensions included:

• getting a simple protocol out early vs. providing a richer protocol later
• interaction models and rendering on the user side of the connection should be well-specified vs. left to local implementation
• how to handle the fact that 7-bit ASCII only provides 128 characters but some systems need more than 128 characters to be “useful”
• default of “echo on” versus “echo off”

Remember that IBM 2741 terminal we've had a few RFCs about? That is the same terminal which mind-blowingly interprets 250 milliseconds of silence on the line as an interrupt signal. This RFCs says that it should correspond to a telnet command code of X'81', or BREAK, and it's up to someone making a Telnet client for a 2741 to capture that 250 ms electrical signal and convert it to the 8-bit word encoding and send it over the line, and vice versa.

There are a ton of interesting use cases provided at the end of the document, including:

• what happens if you connect to a remote host via Telnet and request a feature that the host has not implemented
• interactions between line-at-a-time and character-at-a-time systems
• suggestions for how to implement a minimal versus maximal Telnet client
• what happens when interrupt isn't supported by a remote host (you connect and disconnect instead)

The RFC ends on “an important open question.” The question is, should Telnet itself be responsible for features beyond pure terminal features? For example, should Telnet provide for a PRINT command that prints things at a remote site, or is that best left to the remote site itself? Should Telnet be able to kill a user process on the remote site if it was invoked through the current Telnet connection in the first place?

Analysis

I love the concrete examples in this document! I particularly liked the following example about line-at-a-time and character-at-a-time systems interacting with each other. It really helped make the problems involved more understandable to me.

A user on a line at a time system (Multics, System 360, GECOS, etc.)  is working through the Network on a serving site that operates a character at a time.  The application is a debugging aid that permits the user to type in a memory location = to which it will respond with n where n represents the current contents of that location.  The serving site process does not expect to see the location = followed by a carriage return line feed sequence.  The user at the using site should be able to type in the location, follow it with a signal to suppress the end of a line convention, followed by a new line or return, and expect the location number = to be transmitted immediately without an end of line sequence.

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.

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

Data reconfiguration for Atlantic City

RFC-138 is titled “Status Report on Proposed Data Reconfiguration Service” and authored by Anderson, et al. It's dated April 28th, 1971.

The technical content

Much like RFC-137, this RFC is the result of a committee formed at Crocker's suggestion in RFC-116 to make the best use of the available time at the upcoming Atlantic City NWG meeting. Where RFC-137 reported findings of the Telnet committee, this RFC reports the findings of the data reconfiguration committee.

If you've forgotten, the data reconfiguration service (DRS) was proposed in RFC-83 by Anderson, Harslem, and Heafner of RAND. It is basically a language that is meant to transform one arbitrary data format into another. It's meant to allow programmers to concise provide formulas that can quickly translate, say, the first 20 characters of an ASCII message into EBDIC and append the length of the resulting entire message. It's functionally a little bit like a regular expression with more of a focus on alteration of content. In theory you could come up with a single-line formula that you could feed into a data reconfiguration service and then suddenly you have a function that translates IMP messages into messages that your NCP can read. And if the specifications of a format change, instead of having to write a whole new program, you could just change the single line of your formula and everything would work with the new format.

A user who wants to use this service would use Telnet to connect to the DRS at a well-known site and socket. Anyone who knows the site/socket combination can connect and request a data reconfiguration. A user can connect to the DRS and either request that it accept input data from one socket and send the output to another, or to operate it in interactive mode (where the user provides the input and receives the output, presumably over the Telnet socket itself).

The actual specification of the DRS “form syntax” (the formal rules you can provide to the DRS to explain what you want it to do) does not vary all that much from what was outlined in RFC-83. The big difference here is that it's more precisely defined, specific limits are imposed on things like field length, and many useful recipes are provided that act as illustrations of what this could be useful for.

Analysis

One interesting thing is that this is a service that lives on the network. This RFC is effectively describing what we might think of as a “web API” in 2019: you send some data to a server, it does a calculation and sends you back new data. Of course, this is some 18 years before the invention of the World Wide Web.

MIT, UCLA, UCSB, and RAND are all planning to implement a DRS and provide it as a service to the network.

I really love that the document ends with the list of recipes and then the list of proposed uses of the DRS. Here's a recipe (my term, not theirs, by the way):

VARIABLE LENGTH RECORDS

   Some devices, terminals and programs generate variable length records.  To following rule picks up variable length EBCDIC records and translates them to ASCII.

   CHAR(,E,,#),       /*pick up all (an arbitrary number of)
                        EBCDIC characters in the input stream*/
   (,X,X"FF",2)       /*followed by a hexadecimal literal,
                        FF (terminal signal)*/
   :(,A,CHAR,),       /*emit them as ASCII*/
   (,X,X"25",2);      /*emit an ASCII carriage return*/

And some of the proposed uses include:

• reformatting during file transfer
• translating an image specified in one graphics format to another
• as a description language for message formats
• input validation before insertion into databases

In my opinion it's really effective to put forth examples and use cases. It makes a strong case for the DRS as a critical service that should be implemented as soon as possible. Whether it is implemented, I suppose we'll see.

Further reading

This is very explicitly an early example of I/O streams over a network as an organizing principle of programming. (Though the concept itself goes back to the early 1960s.) James Halliday (aka Substack) has written a guidebook on I/O streams in Node.js. Specific technology aside, I think it does a good job of explaining some of the advantages of stream-based thinking/programming.

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.

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

Telnet for Atlantic City

RFC-137 is titled “TELNET Protocol”. It's by Thomas O'Sullivan of Raytheon and dated April 30th, 1971.

The technical content

Telnet has been in the works since RFC-15 way back in September 1969. This document is a draft protocol distrbuted via RFC for Network Working Group members to read before the Atlantic City meetings that are coming up.

The Telnet protocol offered here is the result of the Telnet committee suggested by Steve Crocker in RFC-116. He specifically asked that a Telnet committee be formed to create a protocol document to be discussed at the Atlantic City meeting, so, here we are.

O'Sullivan is the Chairman of the committee, and it's comprised of members from BBN, SDC, SRI-ARC, Harvard, MIT Project MAC, and MIT Lincoln Lab.

The purpose of Telnet is to make it so that using a remote computer is nearly identically to using a computer at your local site. That is to say, if you're sitting in California and connected to a PDP-10 in Massachusetts via your local teletype, it should be no different from connecting to a PDP-10 down the hall.

We get our first “official” definition of the different “levels” of the ARPANET!

• Level 1 is the Host-IMP protocol (not the inter-IMP protocol as I think I previously guessed on this blog)
• Level 2 is the Host-Host protocol (so how an NCP at one host talks to an NCP at another HOST)
• Level 3 is stuff that happens on either end of a connection between the NCP and the operating system of the local computer (the application layer)

There is a very neat diagram (Figure 1 in the document) that shows the anatomy of a network message and its relevance to the different levels. Basically, the “leader” is what matters to the Host-IMP connection, the “preamble” (or the full header) is what matters for Host-Host, and the actual text content is what matters to the applications on either end.

Telnet provides a Network Virtual Terminal (NVT), which is a kind of generic terminal that more specifical local terminals will be translated to before being sent over the network. The NVT considers CR/LF to be its “end of line” character (more on this in my post on RFC-97).

Telnet will use the Intitial Connection Protocol to negotiate initial connections, and will use ASCII as its character encoding. Using sites (any site that wishes to provide Telnet as a service to its users) must provide their users the ability to input the full set of ASCII characters plus certain Telnet control signals. Since 7-bit ASCII is being used for character encoding (numbers 0-127 in an 8-bit word), that leaves the upper numerical range (128-255 in an 8-bit word) reserved for Telnet control signals. The control signals negotiate things like echoing and interrupt conventions between using site and serving site. There are also some Telnet control signals that are purely local for the user at a using site to indicate certain information to Telnet itself.

Analysis

It's interesting that Telnet is immediately established in the very first clause of the very first sentence as a “third-level protocol”. The concept of levels seems to have become extremely important to the NWG since the concept was first thrown around in early 1970.

This is an extremely sparse protocol so it's a good thing that it's a draft for discussion. Offhand I can't figure out how any programmer could implement a Telnet program based off of this.

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.