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:

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:

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?


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.