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

Logging in

RFC-98 is titled “Logger Protocol Proposal”, authored by Edwin W Meyer, Jr. and Thomas P. Skinner of MIT's Project MAC. It's dated February 11, 1971.

The technical content

The authors state that since the Host-Host protocol is at least somewhat “done”, the next step of ARPANET on a software level should be the development of a “logger protocol”. When a programmer today hears “logger” they might think of a program that writes messages to, for example, an error log, which is a log book that you can audit to see what went wrong with a program. This is not what they mean here.

In this paper, a “logger protocol” is meant to define how “log in” to a remote computer. At the time of this RFC, you had to log in to different systems using different mechanisms. The proposal here is trying to make a single mechanism for login (kind of like various flavors of OAuth try to do on the web).

They suggest tackling this kind of system before attempting a file transfer system because they suspect it's simpler to do, and still necessary, so they might as well get it out of the way first before tackling the big problem.

The authors break the login process into three parts:

  1. “Connection phase”, the establishment of an initial connection
  2. “Dialog phase”, for verification that the user has the right to use the system
  3. “Admission phase”, when the program hands off control from the logger to a system process so the user is no longer just talking to the logger

For the connection phase, the authors endorse the one laid out in RFC-80 from Harslem and Heafner of RAND. But the authors of this RFC also note that disconnection is important: the connections and links need to be cleaned up and freed if this occurs for any reason.

Next is the dialog phase, the actual “logging in” part, where you say “I am user X and I would like access to this computer”. The RFC says that there should be a standard character encoding here and that it should probably be ASCII. Dialog occurs in “transaction blocks” which are sets of ASCII characters preceded by a command code (which is always 0), and then a binary integer indicating the number of characters to be expected in the block (0 to 127; the most significant bit is always 0 so it's a 7-bit number). The character length indicator is to get around some of the character-based vs line-based processing issues we continually encounter.

They don't specify anything for the admission phase, and they note that this is probably going to be trivial in a lot of cases.

They end the document on a note about some edge cases.

First they discuss echoplex (not to be confused with the tape delay effect. Most teletype machines, when you pressed a key like A, would simultaneously move the mechanical print head to print “A” on paper and also send A to the computer. A teletype with echoplex would wait until it got confirmation from the computer that it received A before printing “A” on your roll of paper. Logins should not support this, to reduce complexity.

If someone makes a mistake while logging in, they can use “input editing conventions” to fix it, or just abort their connection and restart the login process.

The logger should only allow an idle connection for “perhaps a minute” until dropping the connection.

Under the current scheme the logger would need to assign a local socket before login was complete; it might be useful in future cases to assign a specific local socket during the admission phase, after the user's identity is determined.


In addition to the authors' pragmatic reasoning for wanting a login protocol, they also posit that

agreement on a common [login] protocol would tend to foster a sense of Network “community”, which would tend to be fragmented [without a common protocol.]

I haven't seen an assertion like this before in the RFC series and it's an interesting one. It makes sense that it would come from Multicians, whose extremely strong community exists to this day. Sitting here in 2019 it seems almost obvious that common protocols would foster community, but I think the idea would have been far less obvious in 1971.

When discussing disconnection the authors note that when a user disconnects, their associated processes should also stop. This reminds me of modern Unix systems, where disconnecting from an ssh connection will stop your processes unless you specify that they are to be run continuously in your absence via something like nohup.

The recommendation of ASCII for the dialog phase may explain why lots of computers still balk at the idea of having an accented character in a username. Recall that ASCII doesn't support characters like é.

Further reading

Forgive me but I'm about to digress about typography. I believe this is the first RFC chronologically in the RFC Editor site to have its own HTML rendering. Something about the strictly-justified text formatting causes me to suspect it might have been formatted in RUNOFF, which would certainly make sense given that RUNOFF was developed for Multics, and Project MAC was the home of Multics. (By “justified” I mean the number of spaces between words is varied between one and two in order to make the length of each line exactly 72 characters per line, which makes it a “72 CPL” text document. According to Wikipedia many teletypes could print up to but no more than 72 characters per line.)

Dave Walden once again comes to the rescue here with his paper, “An informal look into the history of digital typography”. In it, he references the CTSS Programmer's Guide, written in December 1966, which in its introduction highlights justification as a key RUNOFF feature.

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.