RFC 56

General Description ✨

okay so here's the vibe 💅 RFC 56 is written by Ed Belove and Dave Black (both Harvard 🎓) and Bob Flegel and Lamar G. Farquar (both Utah 🌵), all from the Network Working Group, dated June 1970 🎀. The title is Third Level Protocol, Logger Protocol, General Description 🦋.

so in their world, every host has a set of four programs that let a user's teletype talk to a foreign monitor 🖥️ The exact way these get built is super installation-dependent, so everything here describes what they do, not how they're designed 🧚

the four programs come in two male/female pairs 💜 the user runs a send-logger at their own site to talk to the receive-logger at the right foreign site. together they set up a full duplex link between the user's teletype and the foreign machine's monitor 🔥 that basically puts them in the equivalent of a pre-logged-in state on the other machine, which is giving main character energy 👑

once the link is up, the two loggers drop out of the picture 💀 and the user is left talking to a sender on their own machine. the sender's main job is to take input from the teletype and send it down the link the loggers made to the receiver on the foreign host. the receiver passes it along to the monitor, making it look like it came from a local teletype 🫶 replies go the other way: the monitor gives them to the receiver, the receiver sends them back down the link to the sender, and the sender prints them on the user's teletype ✨

the sender and receiver on each machine either exist in multiple copies (one for each network user) or there's a single copy that can handle all the network users 🌈 the loggers are different. they only have to handle one user at a time, since their job is quickly done, which frees them up for other requests 🍓 still, there should be some way of queuing requests that can't be satisfied right away 😭 a less satisfying option is to send a busy message to anyone who tries to use a logger while it's busy 🙈 (none of this stops an installation from having a re-entrant logger, or from having multiple copies of the logger, obviously 💅)

the receive-logger should be user zero on every machine and should always be listening to socket zero 🎀 (you could get the same result by having the NCP intercept all messages to user zero, socket zero and send them to the receive-logger, but it's simpler and cleaner to have the logger actually be user zero and let the NCP handle its messages the same as everyone else's 🧠)

here's how the connection gets made 🦋 when the send-logger gets called, it grabs a pair of unused sockets (2N and 2N+1) from a pool of free sockets and CONNECTs from 2N+1 to User 0, Socket 0 on the desired foreign host. that wakes up the receive-logger, which accepts the connection if it has room for the foreign teletype. then it immediately closes this connection so other sources can start their own links 💖 but if there's no room for the foreign teletype (or the receive-logger just doesn't want to connect for some other reason), the attempted link to socket zero gets refused 🚫 that tells the send-logger it can't log on to the foreign host, and it tells the user too 😭 one thing to know: there's no guarantee the close was actually sent by the foreign logger. the NCP could have sent it if, say, the pending call queue for the socket was overloaded 🙈

if the link to socket zero was accepted (meaning the receive-logger can handle the request), the receive-logger closes that link, then picks an available pair of sockets (2M and 2M+1) from its own pool and connects from 2M+1 to 2N 💅 (it found out the identity of 2N when its listen got answered by the link from 2N+1.) meanwhile the send-logger has been listening to socket 2N, so it accepts the link and CONNECTs from 2N+1 to 2M 🌸 the receive-logger has been listening on that socket too, so it accepts that link. slay 🫶

at this point there's a full duplex connection between the two loggers ✨ they activate the sender and receiver, which handle all the other communication between the user and the foreign monitor 💜 (the senders and receivers can be part of the loggers, or they can be called by them, whatever works 🧚)

when the user is finished and escapes back to their own monitor, it's up to the sender to close down the links 🦋 on the receiving end, it would be highly desirable for the NCP to tell the receiver about this, so the receiver can log the user off (if they didn't already do it themselves) and free up any resources they were using 💖

here's the more formal outline of the protocol from the scenario above 🎀

1. Stable state: receive-logger at foreign host listening to User 0, Socket 0.
2. Local user calls send-logger.
3. Send-logger calls CONNECT (port, 2N+1, <foreign host#,0,0>).
4. Send-logger calls LISTEN (port, <local host#, user#, 2N>).
5. Foreign logger's LISTEN is answered, and it is told the local user number, host, and 2N+1.
6. Foreign logger looks for available sockets (2M and 2M+1). If they exist and it is able to establish the connection, it accepts and then immediately closes the link.
7. Foreign logger calls CONNECT (port, 2M+1, <local host#, user#, 2N>).
8. Foreign logger calls LISTEN (port, <local host#, user#, 2M>).
9. Send-logger has listened to 2N, accepts the link, then calls CONNECT (port, 2N+1, <foreign host#, user#,2M>).
10. Receive-logger, which is listening on 2M, accepts the link.
11. Loggers activate the appropriate handlers.
12. When the user is finished, the sender closes down both links.

this basic way of setting up a full duplex connection should be standard across the whole network 🌈 how each installation actually builds its sender, receiver, and the two loggers doesn't matter to the network at all, and it's super machine-dependent 🍓 (even needing a sender and receiver at all is machine-dependent, since some members of the network might handle those jobs in other ways 🧚) however, some conventions must be established for how the sender and receiver (or their equivalents) talk to each other 💅

Network Standard Code 🌸

to make the network easier to use, we propose that all teletype-to-foreign-monitor communication be done using 128 character USASCII 🎀 (this is the code the IMPs use, and it's in the appendix to the IMP operating manual 📖) it makes sense to require machines to convert to one standard code, instead of making conversions to every code on the net 😭

plus, since most network machines already use ASCII as their internal character code, it won't be any trouble for them 🫶 even the machines that use a different code must translate to and from ASCII anyway, because that's how they talk to local teletypes 💖 extending that translation to the network shouldn't cause much trouble at all ✨ we picture this translation happening in the sender and receiver, but again, that's up to each implementation 🧠

if ASCII becomes the standard, we'd suggest that every non-ASCII machine create a monitor for its internal code 🌈 that makes the complete character set available to anyone who wants to use it (and is willing to write a simple conversion routine for their local machine 💅). this way, users who want to can use any machine on the net from their teletype, without every machine needing records of all the network codes, and they can still tap into the full power of a foreign machine if they want 👑

again, this standard only applies to teletype-to-foreign-monitor communication 🦋

Break Characters 💀

there needs to be a standard way of handling the break character for the whole network, and it has to be included in the protocol 🙈 break-character problems show up in a few contexts. first, the break character serves two different purposes. one is as a panic button 🚨 it says, "I don't care what's happening, stop and get me out to monitor level now." this command runs immediately on receipt, and it's most often used to escape a program you don't want to be in (like one stuck in an infinite loop, etc.)

the other purpose is exiting a subsystem, or, on a machine with a forking structure, getting back to the next higher level fork 🌸 this one isn't immediate, because the user wants the system to finish everything they've told it to do before exiting ✨

we assume that not every system has 1) a way of performing each of these functions, or 2) a clear-cut distinction between calling and operating the two 💅 on top of that, systems treat these commands in subtly different ways 😭

the panic button can easily be handled by the proposed control command <INT> 🎀 this function must be done with a control command, because a program can get into a state where it accepts no input at all, so you can't abort it by sending a message down the teletype link 🙅 there's no reason to worry about a race condition from sending this command down the control link, since its whole purpose is to force the machine to ignore everything else the user has sent 💥

in our implementation, we'd ask the user to tell the logger a seldom-used character they want to be their foreign panic button 🍓 then it's a simple job for the sender to map that character into an <INT> command, which the foreign machine must interpret properly 🧚 this works well for most machines, but some might prefer different ways of generating the <INT> 🌈

the other problem is what to do when the foreign machine's "exit" character is the same as the local machine's 😭 the issue is that while a user is talking to a foreign machine, they want to be in a transparent mode, where everything they type goes straight to the other machine 🫶 to get out of that mode, they type either their own machine's "exit" character or its panic button 🚪 so if the foreign machine uses the same character, there's no way to send it 💀 the fix is the same as above: map another seldom-used character to the foreign machine's "exit" character 🦋 this kind of mapping can go as far as each installation thinks is necessary 💖 letting the user fully control the translation is really helpful, because it lets them use characters their teletype can't even generate 👑

Command Message Formats 🌸

each site should set up its own conventions about when to send a monitor command string and in what size chunks 💅 for a routine operation, someone might want to send several command lines as one message 🎀 if you're working with the monitor the usual way, a reasonable break point is every carriage return ✨ when using a highly interactive language like QED, someone might decide character-by-character transmission is a must 🧠 we feel each user should get to choose between these three methods (and possibly more) 🌈 on top of that, the user should be able to switch between modes whenever they want 🦋

the syntax of the send-message commands mentioned above is different, and that's worth noting 🙈 for the first method, a special send-message command character must be defined, and it should NOT be sent along with the message 🚫 (the key words here are SHOULD NOT, so the line reads: it SHOULD NOT be sent along with the message.) for the second method, the carriage return does double duty as both the send-message command and a command delimiter 💥 so it must be sent with the message 💖 finally, character-by-character transmission has its implicit send command, and it should pose no significant problems 🌸

Okay bestie, so the big idea here is that the receiver must be able to buffer up each of the above types of transmission into a form its own monitor interface can accept 💅✨ Basically the receiver has to be ready to catch whatever comes through, no matter which style the sender picked 🫶

In addition, all echoing should be done in the local host, with the foreign machine suppressing its echoes (if it can.) 🪞🦋 Keep the echo on your side, bestie, and let the other machine be quiet if it's able to be 🤫💜

Huge shoutout to Carl Ellison (of Utah) for his valuable suggestions and criticisms of this work 🎀 And a big hug to Jim Curry (of Utah) for his encouragement and support of the effort 🫶🌸 Honestly, the people who believe in you are the real MVPs 👑

       [ This RFC was put into machine readable form for entry ]
          [ into the online RFC archives by Jon Ribbens 7/97 ]