by Darius Kazemi, November 14 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.
Neither clear nor succinct
RFC-318 is titled “Telnet Protocol”. It's authored by Jon Postel and dated April 3, 1972.
The technical content
This is Postel's attempt to summarize the Telnet protocol as it exists on the ARPANET at the moment. He is not happy with the protocol as it exists and in addition to providing a summary, also presents some suggestions for improvement (on behalf of others who have made the suggestions).
The first thing that needs to be defined is the Network Virtual Terminal (NVT). This is a piece of software (hence “virtual”) that emulates a physical teletypewriter terminal. The NVT consists of a “printer”, which is the input data stream, and a “keyboard”, which is the output data stream. The keyboard can output any ASCII value from 0 to 127. The printer can output the printable characters (values 32 to 126), and also a handful of control characters like BELL, back space, line feed, carriage return. “End of line” is defined as carriage return followed by line feed: CR, LF. (More on that here.) The point of the NVT is to provide a standardized terminal “to eliminate the need for using and serving sites to keep information about characteristics of each other's terminals”. That is, if you can all agree on a standard subset of terminal functionality then as long as you get your own actual (non-virtual) terminal speaking that standard, you're good to go.
Telnet uses the Initital Connection Protocol to establsih a connection with a remote host, and then the main interface for writing and reading data back and forth is the NVT, and then the Telnet control signals are what controls the flow of that data under the hood.
The telnet signals consist of 8-bit values 128 and above, so as not to interfere with the values 0 through 127 that are for the NVT as described earlier.
There are codes for things like interrupts, for hiding input (like when a user is typing in a password, you don't want to display it), and for marking where data blocks begin and end.
Postel provides recipes for both a minimal implementation of Telnet (on both client and server) and a “standard” implementation of Telnet.
Of course, there are problems. For starters, if you send the character “a” to a remote terminal that only supports upper case letters... well, you've successfully sent “a” from your NVT to their NVT, but now they need to translate that letter into something that they can show. Presumably they'll translate it to upper case “A”, but you don't actually know for sure unless you ask someone over there what it looks like! One suggestion is to allow users to specify that translation themselves... but now you've more or less rendered the NVT useless.
There are also concerns about extending Telnet to be able to represent graphics and so on.
Things get weirder where the codes for more abstract control commands come in. When you send a “CR;LF” newline across the network, the receiving host might not actually have CR and LF available locally! Instead it could interpret it and then translate it to an internal, non-ASCII “new line” command before sending it to the main computer's processes. The state of CR;LF in computing on the ARPANET is summarized by Postel as follows:
Telnet defines the end of a line to be indicated by the ASCII character pair CR LF. Several of the real devices in the world have only a single new line (NL) function. Several of the computer systems have in some programs used the CR and LF functions to have semantic meaning larger than the format effect they provide. Further, several computer systems allow the CR and LF functions to be used separately (e.g., such that a line may be overprinted).
One solution that could work is to follow any CR that is not going to be followed with an LF with a NUL instead. This lets the recipient know that the CR can be interpreted as semantically distinct from a newline command.
Postel also points out some inconsistencies with echoing and the hide-your-input functionality (do you print X's instead of letters? nothing? etc). Similarly the interrupt signal has different semantic meanings on different computers and as such isn't so simple to interpret. He suggests using the BREAK (interrupt) signal in conjuction with the DATA MARK signal in order to communicate more detail about the type of interrupt that is being sent.
There are some changes to Telnet proposed by others—the big one to my eye being the proposal that all data types be scrubbed from the protocol in favor of pure ASCII.
Analysis
Of all the people in the history of the APRANET and early Internet, Jon Postel (1943-1998) is spoken of in glowing terms. He was largely beloved, and remains so to this day. Yes he was instrumental to the network and essentially ran huge chunks of the internet by hand for years, but also everyone just liked him so much. I think that the opening paragraph of this RFC is an example of his signature “poetic and whimsical” style:
At the October 1971 Network Working Group Meeting, I promised to promptly produce a document which clearly and succinctly specified and explained the Official Telnet Protocol. This document fails to meet any part of that promise. This document was not produced promptly. This document is neither clear nor succinct. There is NO Official Telnet Protocol.
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.
