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