by Darius Kazemi, Jan 15 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.
Proposing TELNET
RFC-15 is authored by Steve Carr, a representative of University of Utah's computer science program (UTAH in ARPANET parlance). He was present at the first Network Working Group Meetings I mentioned in my RFC-1 post. I couldn't quickly find a lot of info on him but according to this article he was a grad student of early computer graphics expert David C. Evans when he authored this. (Incidentally, Carr would have been there at the same time as one of my personal computing heroes, Alan Kay.)
Titled “Network Subsystem for Time Sharing Hosts”, this RFC is dated Sep 25th, 1969, about one month before the first message would be sent over the ARPANET.
Technical content
This RFC is really important! It proposes a program called TELNET (now called Telnet) that solves the problem of how two computers running different hardware and different operating systems can somehow talk to one another over the network.
Carr begins by pointing to RFC-11 and summarizing Déloche's list of required “network primitives” that allow a computer to talk to ARPANET:
- Open primary connection
- Open auxiliary connection
- Transmit over connection
- Close connection.
He says that these will operate at the level of system calls, “most likely a part of the resident monitor” for maximum speed/responsiveness. Both the SDS 940 and the PDP-10 offered a way for users to write their own system calls, and in the context of a time-shared computer, all users would need access to these calls.
A “resident monitor” is a tiny program that is always present in memory that is run over and over — it is resident in memory and it is generally used to monitor when critical things need to happen. Usually the available memory for this program is very small so it often is just a single instruction that says “go to this other place in memory and run the program there”. These aren't used in modern computers but similar concepts are used in the simple embedded systems you might find in a kitchen appliance.
The RFC describes how computers running different hardware and different operating systems could talk to each other in the context of a time-sharing system. The process goes:
- log in to your local computer
- start up the TELNET program
- define your local escape character (so you can define “this is the button I press when I'm about to send a special command rather than just plain old typing data”)
- TELNET makes the system call to open the network connections so the individual doesn't need to worry about it. Assuming the remote computer is accepting remote logins, we then...
- log in to the remote computer
- you can type like you were locally logged in on the other computer now!
- if you want to transfer a file from your local computer, there is a special routine for sending files (make sense, since the IMPs have their own file transfer methods, which require special link connections to be opened by the system)
- logout, presumably (never mentioned but heavily implied!)
Carr also states that Telnet needs to take up a really small amount of memory so that it's fast. Which is why it doesn't do much (there's explicitly no translating between different character sets).
Analysis
Telnet has been in continuous use since 1969, and although it began to fall out of favor in the 1990s, it's had an incredible run as far as “ways to access the internet” go. Telnet was quickly adopted although there wasn't a formal attempt to standardize it beyond this proposal until RFC-97 in 1971.
In fact, telnet was standard on all modern consumer operating systems until very very recently. Apple only stopped shipping telnet on its Macs in 2017. On a personal note, Telnet was how I first accessed the internet, via bulletin board systems when I was ten years old in 1993.
In this RFC about logging in to a remote computer the word “password” is never used. In fact the only prerequisites for accessing a remote computer are: the remote computer is accepting remote logins, and the local computer has the local user cleared for connecting to remote computers. This is the modern equivalent of “if you don't want strangers logging in to your computer, deny all login attempts.” Of course, at this point all the potential users of ARPANET knew each other! So, not a big deal yet.
Carr mentions an “SPOP” on the SDS 940 system. I believe he is referring to “SYSPOP”, which functions much like a UUO does on a PDP-10. This would make sense as Carr would have been much more familiar with the PDP-10 since that's what they used at UTAH. (A PDP-10 at UTAH would eventually become the fourth node on the ARPANET.)
In a sense, Telnet is a simpler, text-only alternative proposal to the media-rich DEL system outlined in RFC-5 that was never implemented.
Further reading
A history of Telnet.
A set of notes on SDS-940 lectures given by Butler W. Lampson in June 1966. Lampson was one of the developers of the SDS 940, and would later go on to cofound Xerox PARC and help invent a million other things.
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.
