365 RFCs

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

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

A Telnet client

RFC-206 (PDF) is titled “A User TELNET: Description of an Initial Implementation”. It's by Jim White of UCSB and dated August 9, 1971.

The technical content

This document describes the implementation of a Telnet client at UCSB. (The phrase White uses is “user Telnet” but that is in opposition to what we'd call a “server Telnet”; the phrase we'd use to today is “client”.) I'm not going to get into the nitty-gritty because it's a pretty straightforward, if partial, implementation of the RFC-158 Telnet. Still, there is some interesting information in here.

The author notes that the users of the Culler-Friend On-Line System at UCSB do not have access to the ARPANET by default. This privilege must be earned, or at least requested. They need to contact their Computer Center liaison to get special access first.

When a user connects to Telnet at OLS, the user is asked for a remote site number, and then for a remote socket number, at which point a connection is attempted.

The document contains a list of 21 ARPANET sites and their site numbers, for reference. The default socket you connect to for Telnet is 1, but you have the option to connect to a different socket if you have a special need.

Most of the rest of the document discusses the peculiarities of character encoding and the virtual teletype system used by this Telnet client.

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 ActivityPub, including a Node.js reference implementation, an RSS-to-ActivityPub converter, and a fork of Mastodon, called Hometown. You can support my work via my Patreon.

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

Telnet for text editors

RFC-205 is titled “NETCRT – A Character Display Protocol”. It's authored by Bob Braden of UCLA and dated August 6, 1971.

The technical content

We learn of a system that hasn't been mentioned in an RFC before: URSA, which is a “conversational remote job entry” system at UCLA. It's a more interactive RJE system than the ones we have previously heard about. In particular, URSA is designed with a full-screen text editor, the kind of thing that you probably use every day: an entire page of the document is shown on a screen at once, and you can move a cursor around and edit whole paragraphs at a time. While this is normal today, many text editors in 1971 are what are called “line editors”, and are designed for teletypes, which you may remember are souped-up typewriters that support input and output. A typewriter only lets you edit one line of a document at a time, and that is what a line editor is optimized for. (I mentioned this in my RFC-46 post, but there is a great article about the history of the line editor called Where Vim Came From that is absolutely worth a read.)

Because TELNET is designed for teletypes, and hence line editors, it is not suitable for full-screen text editors like the one running on URSA. So this RFC introduces a new protocol called NETCRT to remedy the problem.

At the moment of publication of this RFC, NETCRT has not yet been implemented, and UCLA only plans to implement it if there is interest from a number of other ARPANET sites in accessing their URSA system.

Like the latest incarnation of TELNET, NETCRT is organized around the concept of a virtual display terminal simulated in the user host. The virtual terminal has a display capable of showing N lines of M characters in its display, and also an N x M memory buffer that you write to. Updating a character in the memory buffer will update it on the screen. Writing to the memory buffer is controlled by a “cursor register” which addresses locations in the buffer. The virtual terminal also has a special communications channel through which it receives control commands from the server.

The cursor register's current location is indicated by an underscore or other suitable effect on the screen. When a user issues a “transmit” command, the keyboard is locked and a portion of the data on the screen is sent to the server, which then responds with some kind of new information drawn to the screen and then unlocks the keyboard. There are also up-down-left-right commands to move the cursor location on the screen, a clear screen command, and a way to send an interrupt message to the server.

Braden complains about “squishiness” built into the Network Control Programs at various ARPANET sites. I'm assuming this refers to inconsistent response times that make interactive applications frustrating to use.

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 ActivityPub, including a Node.js reference implementation, an RSS-to-ActivityPub converter, and a fork of Mastodon, called Hometown. You can support my work via my Patreon.

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

The socket czar's opening gambit

RFC-204 is titled “Sockets in use” and is authored by Jon Postel of UCLA. It's dated August 5, 1971.

The technical content

Jon Postel would like to know what sockets are being used for standard programs. This is because sockets, at least for initial connection for programs, need to be well-known. A socket number combined with a host site number forms a unique identifier that lets a computer program at site A connect to a computer program at site B.

Postel notes that RFC-196 suggests the use of socket 5 for the Mail Box Protocol, and he asks whether anyone objects, and if anyone has any suggestions about how to handle socket number assignments.

Further reading

By late 1973, Jon Postel would be affectionately called the “Socket Czar” by Bob Braden in RFC-599.

Just as socket numbers were needed to be agreed upon for different network programs in 1971, port numbers are needed to be agreed upon for different network programs in 2019. When you ask to connect to example.com over HTTPS, your browser looks up something like a host site number (IP address) and it knows ahead of time that the port, which is kind of like a socket, is number 443.

In a real sense, today's IANA Port Number Registry is the grandchild of an effort that began with this RFC.

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 ActivityPub, including a Node.js reference implementation, an RSS-to-ActivityPub converter, and a fork of Mastodon, called Hometown. You can support my work via my Patreon.

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

Error-resistant communication

RFC-203 is titled “Achieving Reliable Communication”. It's authored by Richard B. Kalin of MIT Lincoln Lab and dated August 10, 1971.

The technical content

This RFC introduces an idea for a “non-standard protocol” that is specifically for error-resistant communication.

The paper defines two kinds of transmission errors: errors where you don't get a message you were sent, and errors where you get a message that wasn't intended for you. So detecting an error of this type requires you to be able to tell if a message has been lost, and also to be able to tell if a message was the one you were supposed to receive.

“Garbled” messages can be detected by standard methods like checksums. Detecting the order in which a sequences of messages needs to be reconstructed can be solved simply by numbering messages sequentially.

Determining that a message has been lost needs to be done indirectly by making inferences, which can lead to false positives, but you could assume that an expected message that hasn't arrived in a long time can be lost, or a missing message in a sequence is lost, and so on. Lost messages can simply be requested a second time, and again, until the expected message is received.

Kalin proposes some rules for recovering lost messages, including that all messages should be in a sequence of messages, and messages received out of sequence should be discarded. He also says that there should be acknowledgement of receipt of every message, and that the sending host should not send a new message until it hears from its receiving host that the host has gotten the message.

He also offers a modified version that essentially allows for N messages to be sent before the sender waits for receipts, so that there's a sort of buffer of unacknowledged messages that is acceptable.

There are also some weird problems of starting and stopping messages that he addresses.

Analysis

This is a pretty dry paper, and also I wish he'd cover the drawbacks of this kind of error-resistant communication in detail. He's not proposing a replacement, simply an extra channel for presumably emergency communications that must be statistically zero-error, but the tradeoffs here are presumably high (I'm just thinking about all the waiting around that the sender and receiver have to do!).

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 ActivityPub, including a Node.js reference implementation, an RSS-to-ActivityPub converter, and a fork of Mastodon, called Hometown. You can support my work via my Patreon.

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

Deadlock

RFC-202 is titled “Possible Deadlock in ICP”. It's authored by Steve Wolfe and Jon Postel of UCLA and dated July 26, 1971.

The technical content

The UCLA folks have once again found a bug in the Initial Connection Protocol. (The first time was reported in RFC-143. The issue at hand is that if both sides of a connection send a “request for connection” at the same time, then both will simply wait for the other to reply, forever. The authors suggest a minor tweak to the ICP to avoid this.

Note that this condition is present in the old ICP defined in RFC-123 and not the new one recently proposed in RFC-197.

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 ActivityPub, including a Node.js reference implementation, an RSS-to-ActivityPub converter, and a fork of Mastodon, called Hometown. You can support my work via my Patreon.

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

Not issued

RFC-201 was never issued.

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 ActivityPub, including a Node.js reference implementation, an RSS-to-ActivityPub converter, and a fork of Mastodon, called Hometown. You can support my work via my Patreon.

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

Another RFC list

RFC-200 is titled “RFC List by Number”. It's by Jeanne B. North of SRI NIC. It's dated August 1, 1971.

The technical content

This is an update to RFC-170, and it's a list of RFCs to date in the same format.

Analysis

You'll note that this was published August 1, 1971. RFC-170 was published June 1, 1971. Either this was a coincidence, or the intention would have been to publish a new RFC list every two months on the first of the month. At any rate, if this was the intent, it was never carried out.

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 ActivityPub, including a Node.js reference implementation, an RSS-to-ActivityPub converter, and a fork of Mastodon, called Hometown. You can support my work via my Patreon.

by Darius Kazemi, July 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 tablets

RFC-199 (PDF) is titled “Suggestions for a Network Data-Tablet Graphics Protocol”. It's authored by one T. Williams of SDC, and dated July 15, 1971.

The technical content

Yes, this is another suggestion for a network graphics protocol. I am getting tired of these! For those keeping count, this has been the topic, more or less, of:

You'll notice that starting at RFC-174 there is a flood of these proposals. This is because RFC-134 announced a Network Graphics Meeting in late July 1971 where in order to participate, you had to submit a working paper about graphics as an RFC ahead of time. So, yeah. This flood of graphics RFCs is everyone submitting their homework that was assigned 3 months ago right before the deadline. Thanks, Al Vezza.

Anyway.

This paper says that RFC-177 provides a good basis for non-interactive graphics, so this paper is instead interested in interactive graphics, and in particular, data tablets. Data tablets are kind of like the touch pad on a laptop: a 2D surface that does not have an embedded display, and clicking on it, usually with some kind of stylus or pen, corresponds to some (x,y) coordinate on a screen.

There are four kinds of data that you can expect from a data tablet:

  1. Single shot: a click on the tablet that corresponds to a single (x,y) coordinate. The author proposes that each click be sent as a single 6-byte (48-bit) packet of data.

  2. Raw asynchronous input: a series of sampled inputs based on some kind of condition, like the pen has moved a certain distance and so it samples another (x,y) coordinate and sends it to the computer. The author suggested that each “stroke” of the pen is sent as an entity, so an initial 6 byte header is sent including the number of pen strokes to expect, and then an initial (x,y) is sent in 4 bytes, and then for each stroke a (delta-x, delta-y) is sent as in 2 bytes.

  3. Raw syncrhonous input: a tablet with a clock signal where N times each second it samples data from the pen. The data format is the same as the asynchronous one, except the sampling rate is included in the header.

  4. Preprocessed data.

The fourth category, preprocessed data, requires some explanation. A data tablet might have a noisy input, so it might make sense to run a smoothing algorithm on it before sending the raw data over the network. At SDC they use “an 8-point moving average” to smooth the inputs. So the preprocessed data essentially operates like the raw data formats above, but it also contains some metadata about the smoothing algorithm used, for example the number of points used in a moving average or the “window” of a filter.

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 ActivityPub, including a Node.js reference implementation, an RSS-to-ActivityPub converter, and a fork of Mastodon, called Hometown. You can support my work via my Patreon.

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

Lincoln Labs checks in

RFC-198 is titled “Site Certification – Lincoln Labs 360/67”. It's authored by John Heafner of RAND, and dated July 20, 1971.

The technical content

Recall that John Heafner of RAND has been given the duty of collecting up to date information about the hardware and software at different host sites.

This is a brief note to let the Network Working Group know that MIT Lincoln Laboratory now has a working NCP, ICP, ASCII telnet client and server, login procedure, and remote access to the CP/CMS operating system. The whole thing is running “very smooth under moderate to heavy load”.

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 ActivityPub, including a Node.js reference implementation, an RSS-to-ActivityPub converter, and a fork of Mastodon, called Hometown. You can support my work via my Patreon.

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

Further ICP consideration

RFC-197 is titled “Initial Connection Protocol—Reviewed”. It's authored by Arie Shoshani of SDC and Eric Harslem of RAND, and dated July 14, 1971.

The technical content

One action item coming out of the meeting at SJCC was that the Initial Connection Protocol had a bunch of errors in it and thus a cleanup committee was assigned to fix it up.

RFC-165 was the sort of initial knee-jerk output of the committee, published just a week after the SJCC meeting. This RFC is the more refined output of that cleanup committee, with a two-month turnaround (not bad!).

A big change is that this new ICP being proposed supports both simplex (one-way data transfer) and duplex (two-way simultaneous data transfer) connections. The idea is the initiating host messages its recipient saying “I would like to open a connection on a particular socket and send you some data, please either accept or refuse.” This is a much simpler process than a duplex connection setup, which requires a handshake and some back-and-forth to establish 4 sockets total (send and receive sockets on both sides).

They also offer a simplified duplex connection process as compared to earlier RFCs. The main improvement is that no data or memory allocation happens on the initial connection to the well-known socket; instead what happens is the well-known socket will immediately send back a different socket to connect to.

This new ICP also offers fewer restrictions on what sockets are reserved for connections. As previously defined, your input socket needed to be an even number and your output socket needed to be an odd number, and they needed to be sequential numbers. The numbers no longer need to be sequential, and in fact even/odd doesn't make a difference in this protocol.

The authors also suggest a change to the Network Control Program that would make the ICP simpler overall.

They also note that, right now, “CLS” (the “close” command) is used for closing an open connection, rejecting a request for a connection, and temporarily refusing a connection due to a memory allocation issue. The authors suggest that this be separated into three different commands.

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 ActivityPub, including a Node.js reference implementation, an RSS-to-ActivityPub converter, and a fork of Mastodon, called Hometown. You can support my work via my Patreon.

Enter your email to subscribe to updates.