RFC-97

by Darius Kazemi, April 7 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 protocol

RFC-97 is called “A First Cut at a Proposed Telnet Protocol”. It is authored by John T. Melvin and Richard W. Watson of SRI-ARC and dated February 15th, 1971.

In addition to the usual text version of the RFC, there is a scanned PDF version you can read at the official RFC Editor site.

The technical content

If you'll recall, the last formal document on Telnet was RFC-15 way back in September 1969. That RFC proposed something called “Telnet” and loosely described what it did, but was not specific enough to be a formal specification for consistent implementation. As a result, Telnet was implemented in more than one site but in different ways. This RFC is the first attempt to formalize Telnet.

One big thing set out here is that an important convention is to have Telnet itself sit in between the NCP of the Host and what we'd today call I/O (input/output) device interfaces. Basically, from the point of view of computer with Telnet installed on it, Telnet is just another piece of hardware. The computer doesn't care if character messages are coming from Telnet via ARPANET or from a teletype machine hooked up directly to the computer. Similarly, writing to Telnet from a computer should be like writing to a teletype for output. Meanwhile, Telnet is what talks to the NCP. This is laid out in Figure 1:

A flow chart: User Terminal to Terminal Control HW/SW to Telnet to NCP to Network to NCP to Terminal Control HW/SW to Server Program

There will be situations where the user might want to talk directly to the NCP so the authors recommend that direct connection to the NCP from user processes should still be allowed.

The authors establish that instead of using the terms “full/half duplex” for different kinds of connections they will instead talk about “echo control” methods. This is because Telnet connections are all actually full duplex. There will be different command modes for the cases described in previous RFCs with character-at-a-time transmission or line-by-line transmission.

Servers will assume that any remote connections will use the default character set that the server is used to. Control characters and two-character sequences pose a problem. (They still do today in all sorts of computing applications.)

Analysis

Section 3E begins,

The carriage return (CR) character can be the source of considerable difficulty.

This character vexes programmers five decades later and is still the source of countless bugs and even security holes.

Further reading

Here's a history of line ending encoding by Luke Maciak that nicely summarizes all the context around CR/LF, including the role that teletype machines played. I learned from this that there's a reason that carriage return almost always precedes line feed, aka why it's CR/LF and not LF/CR. The reason? Carriage return is the movement of the print/type head from the far right to the far left of the paper and takes a while to happen. Line feed is just scrolling the paper a fraction down so the next line can be printed. Since CR takes longer than LF and both could happen at the same time, by sending a CR/LF command you could get a “free” line feed without having to wait for the carriage return to finish! (On slow teletypes this would make no difference.) Here is a timing diagram with some timings I completely made up but it gets the idea across:

A timing diagram that shows an LF command occurring during the entirety of a CR command, assuming some kind of clock latching the inputs.

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 a Mozilla Fellow and I do a lot of work on the decentralized web with both ActivityPub and the Dat Project.