365 RFCs

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.