RFC 98

RFC 98: Logger Protocol Proposal 🎀

Part 1 of 2 💖

• Network Working Group 🌸 Request for Comments #98, Network Information Center #5744
• Authors: Edwin W. Meyer, Jr. and Thomas P. Skinner 👑
• Date: February 11, 1971 📅
• Category, status, obsoletes, updates: none are listed on this one, so nothing is obsoleted or updated 🦋

---

Okay so, with the ARPA Network Host-to-Host Protocol specified and at least partly implemented at a bunch of sites, the big question is what to do next ✨ Basically everyone in the Network seems to agree the first step should be specifying and implementing what people have been calling the "Logger Protocol" 🔥 The Computer Network Group at project MAC is on board too. "Logger" is the usual name for the basic mechanism you use to get access (to "log in") to a system from a console. A network logger is meant to spell out how a host's existing logger should plug into the network so you can log in from a console attached to a different host 🧚

Logging in over the network is giving necessary energy, ngl 💅 For one, Network people obviously want to learn more about remote systems, and nothing beats using them directly in real time 👀 For another, the technical problems with remote logins are probably less complicated than stuff like generalized file transfer. So a Logger Protocol could get built pretty fast, which would hype everyone up to take even more steps after that 🚀

We wrote this document to give everyone something to discuss (and, at the very most, a first draft of a Logger Protocol) 📝 It tries to lay out a minimal set of conditions for building one. It only covers the mechanism for logging in 🫶 What happens after login isn't discussed here, because we feel more experimentation is needed before anyone can make a general console communication protocol official. Until then, each site should write its own experimental standards for console communications after login 🌈

Some of the points here have already reached a certain level of consensus among Network participants, and at least one point is pretty new 🍓 Still, no matter how individual issues get settled, Networkwide agreement on some general protocol should happen ASAP ⭐ This matters even more because some points that should be covered will probably only show up during implementation, so the sooner everyone has a shared basis to build on, the sooner a more rigorous protocol can be written 💜

Before we get into 1) what the protocol should deal with and 2) specs for where the protocol is right now, we have to acknowledge that someone could argue for skipping the whole Logger Protocol headache by just saying each host gets to specify its own, maybe totally unique, preferences for being approached over the Network 🙈 That's definitely possible, but it's not something we think is a good idea. For one, it would slow down general Network progress, because dealing with some 20 systems is way more time-consuming than dealing with "one" system, even if each of those separate interfaces is simpler than the single one 💀 Another reason is less practical but still important: agreeing on one common protocol builds a real sense of Network "community" ✨ The local option route would fragment that. Honestly, the Host-to-Host Protocol could've been handled on a per-host basis too, and I'd guess one reason it wasn't has to do with similar, kinda abstract considerations 🦋

Context

Structurally, logging a user in over the Network has two parts 🌸 One part sits at the using host, and the other sits at the serving host. The using (or local) host is the one the user's typewriter is plugged into directly. It has a module that channels and transforms communications between the Network connection and the typewriter 🎀 The serving (or foreign) host is the one that provides the service being used. It has programming that adapts the logger and command system so they can be used through the Network instead of a local typewriter 👑

A login through the network has three phases 💖

1. Connection phase: The user's console gets connected to the serving logger through the Network. This is obviously the most important phase from the protocol's point of view 🔥
2. Dialog phase: A sequence of exchanges between the user and the logger that identifies the user and checks that they have the right to use the system. On some hosts this phase might be minimal or basically nonexistent 🧚
3. Admission phase: This happens after the user has successfully finished the login dialog. It means switching their network typewriter connections from the logger over to an entity that provides some kind of command processor 🚀 On some hosts this switch might be totally conceptual, while on others there may be a real internal switch between entities ✨

The Connection Phase

Specifying a protocol for implementing login gets split into two big parts 💅 First is how to establish and maintain the network connection between the typewriter and the logger. Second is how to run a dialog once the connection is made 🫶 The first part is called the Initial Connection Protocol by Harlem and Heafner in RFC 80 🌈 It has two subparts: how to establish a connection, and how and when to destroy it 🍓

We endorse the connection-establishing proposal from RFC 80, so here's a quick recap for convenience ⭐ It's a two-step process that uses NCP control messages to set up a connection between the logger and the console of a potential user 💜 First, the user causes their host's NCP to send a "request for connection" control message to the serving host's logger contact socket 👀 This message has two jobs: it tells the logger that this user wants to start a login dialog, and it communicates the identifiers of the receive and send sockets the user wants to use for it 🔥 The logger rejects this request so it can free up its contact socket 💀 For the second step, the logger picks two sockets to connect to the user's sockets, then sends connection requests for those 🚀 If the user accepts the connection within a reasonable period, the connection phase is over and the dialog phase can begin 🎀 If the user doesn't respond, the requests get aborted and the logger gives up on this login attempt 🙈

There's also the other side of an NCP: when and how to disconnect 🦋 There are two basic situations where a logger should disconnect 🌸 The first can come from the serving host's own volition: the logger may decide to abandon a login attempt, or a logged-in user may decide to log out 💖 The second can be due to the using host's volition or to network difficulties 👑 This happens when the serving host receives a "close connection" control message, or one of the network error messages saying that further transmission is impossible 😭 It can happen for either the "read" or the "write" connection ✨ Disconnecting means deleting the network connections and stopping any activity at the serving host related to that user 🔥 If the login is still in progress, it should be abandoned 💅 If the user is already logged in, their process should be stopped, since they no longer have control over what it's doing 🧚 This isn't meant to restrict absentee (i.e. consoleless) jobs 🌈

SPECIFICATIONS ✨

Initial Connection Protocol - Connection Phase 🔌

The following sequence is copied from RFC 80 so you have everything in one place. 💖

Step 1: the request 🚀 To start things off, the using process asks for a connection from its receive socket (US) to a socket (SERV) on the serving host. By convention, SERV has its 24-bit user number field set to zero. The 8-bit tag (AEN) field is set to one, which marks the socket as a sending socket. US can be any socket you like, as long as it's the right gender (a receive socket). So the using NCP sends this:

User -> Server

       8        32          32         8
    +-----+------------+------------+-----+
    | RTS |     US     |   SERV     |  P  |
    +-----+------------+------------+-----+

It goes over control link one, where P is the receive link the user's NCP assigned. 🎀

Step 2: the serving host decides 🤔 Now the serving host can either accept the request or close it. There are two paths here, bestie.

a. If it sends a close, the user knows the foreign host can't take the request right now. The serving host's NCP sends:

Server -> User

       8        32          32
    +-----+-----------+------------+
    | CLS |    SERV   |     US     |
    +-----+-----------+------------+

and the user's NCP sends back an echoing close:

User -> Server

       8        32          32
    +-----+-----------+------------+
    | CLS |     US    |    SERV    |
    +-----+-----------+------------+

b. If the serving host is down to help, it accepts the connection and then immediately closes it. 💅 The serving host's NCP sends:

Server -> User

       8        32          32
    +-----+-----------+------------+
    | STR |    SERV   |     US     |
    +-----+-----------+------------+

       8        32          32
    +-----+-----------+------------+
    | CLS |    SERV   |     US     |
    +-----+-----------+------------+

Then the user's NCP sends the echoing close:

User -> Server

       8        32          32
    +-----+-----------+------------+
    | CLS |     US    |    SERV    |
    +-----+-----------+------------+

Quick heads up: the echoing closes are required by the host-to-host protocol, NOT by the logger initial connection protocol. 🙈

Character Set 🔤

The login dialog uses standard ASCII, as documented in "American National Standard Code for Information Interchange", ANS X3, 4-1968, American National Standard Institute, October, 1968. 📚 A logger at a serving host can ask for any kind of input that can be written as a string of one or more ASCII characters, and it can send back any string like that too. It's giving total flexibility. ✨

Every ASCII character is legal, graphics and control characters included. 🌈 Still, the only standard way to end a console line is the line feed character (012). This matches a change to the ASCII standard that's expected down the road. 🦋

Right now ASCII allows two ways to end a line. The first is a single line feed (012), which does line space and carriage return to the left-hand margin in one go. The second is also allowed by ASCII, and it uses two characters, line feed (012) followed by carriage return (015), to do the same job. 💁‍♀️

There's a proposal to change ASCII so that every vertical motion character that moves at least one full space (line feed, vertical tab, and new page) also returns to the left-hand margin. That would kill the two-character line ending, since it wouldn't be needed anymore. 🙌

For a character in a host's own character set that has no ASCII equivalent, the suggestion is to use the two-character ASCII sequence ESC (033) plus one of the ASCII characters. 🧚 Each host SHOULD publish a list of the escape sequences it has defined.

Transaction Block Format 🧱

All the textual messages swapped between user and logger have to be made of one or more "transaction blocks". Each block is a run of 8-bit elements in this shape:

<code> <count> <char1> ... <charn>

<code> is an 8-bit element this protocol doesn't interpret. In the general console communications protocol they're planning, this field will describe communication modes or special traits of the block. Here, <code> is zero. 🍓

<count> is an 8-bit element that tells you how many character elements come after it in the block. It's read as a binary integer from 0 to 127, and the most significant bit is zero. 🔢

<chari> is an 8-bit element holding one standard 7-bit ASCII character, right-adjusted, with the most significant bit set to zero. The number of <chari> items is decided by <count>. A block can hold anywhere from zero to 127 characters. 💜

Every one of these elements has its most significant bit set to zero, so each element only uses seven bits. Why? Two reasons. First, the eighth bit of the <chari> elements is saved for future expansion. Second, it lets some implementations turn the incoming stream from 8-bit elements into 7-bit elements before decoding it, which is a big vibe for compatibility. 🦋

With one exception, splitting a logger-user message into one or more transaction blocks doesn't mean anything semantically. The sending host can chop up the message string and spread it across several blocks however it likes. If the message is under 128 characters, it can go in one block. ✂️ The exception: separate messages may not appear in the same transaction block. A message has to start at the beginning of a block and finish at the end of one. 🎯 Also, there's no syntax for marking the last block of a message. It's assumed that the logger and the end user both know the format well enough to tell when the whole message has arrived. 🫶

One more thing, and it's important: the first 8 bits of data sent over a newly established connection MUST be a type code, as specified in Protocol Document 1. That type code MUST be sent before the first transaction block, and the receiving host SHOULD discard it. 🔥

Acknowledgments 🌸

Robert Bressler, Allen Brown, Robert Metcalfe, and Michael Padlipsky directly helped shape the ideas here. Thanks also to Michael Padlipsky and others for their editorial comments. 👑

---

[ This RFC was put into machine readable form for entry ] [ into the online RFC archives by Carl Moberg 1/98 ]