RFC 559

RFC 559: Comments on the new TELNET Protocol and its Implementation 🎀✨

Okay bestie, here's the deets 💅 The author is Abhay K. Bushan from MIT Project MAC, and it's a Request For Comments #559 (NIC # 18482) dated August 15, 1973. It doesn't list a category, and it doesn't obsolete or update anything. 🦋

We at MIT-DN built the new TELNET protocol, both the server and the user side 🌸 This RFC is our experience with it, especially how we used GO AHEAD and how we got the new User and Server TELNETs running. Fair warning: the new TELNET is not compatible with the old one 😭 We also have a few suggestions to help other implementors and make the switch smoother 🫶

---

I. OUR TELNET SERVER IMPLEMENTATION 💜

Our new server TELNET accepts both the "old" and the "new" TELNET "control sequences" 🧚 Right now we've got the ECHO and "Suppress Go Ahead" options implemented, and we handle Interrupt Process (IP), Erase Character (EC), Abort Output (AO), Are You There (AYT), Break, and Synch character sequences to varying degrees of "the right thing" 💀

A. The ECHO Option 🔥

The TELNET server starts up in the default local echo mode and accepts both the old and the new TELNET control sequences. It kicks off negotiation for remote echo (server echoing) by sending IAC WILL ECHO, but it only switches echo mode once it gets an affirmative IAC DO ECHO back 👑 After the cutoff date for the old protocol, we'll stop "honoring" the old TELNET control sequences.

B. The Go Ahead and Suppress GA option 🌈

The server starts up in the send GA mode, and it transmits the required IAC GA sequence whenever it detects that it needs to send a GA. Ngl, our GA scheme works most of the time but not all of the time 😭

There's really no reliable way for our server TELNET to figure out when a process is actually waiting for network input. On our system, the server TELNET doesn't "control" the user's process. It just acts as a terminal handler at the TTY level 🙈

A quick investigation showed that this problem (sending GA's reliably) isn't just an ITS thing. TENEX (ref. conversation with Ray Tomlinson) and DEC-10 (ref. conversation with Ed Taft at Harvard) systems will run into similar issues 🍓

Our fix was to have the server wait 2.5 seconds after sending output, to see if more output is coming. If the server has been "idle" for more than 2.5 seconds in the "output-sent" state, it sends a GA and goes into an I/O wait state (looking for input or output). This works most of the time (but isn't guaranteed), and it doesn't cause any noticeable delay. The server can send an extra GA sometimes 🫠 Our experiments showed that 1-5 seconds was a good range for this "idling time constant" ✨

We do implement the "suppress GA" option, and we won't send GA to hosts that agree to negotiate out of it. Our server does try to negotiate the suppress GA option 💖

C. Other Options and TELNET Control Sequences 🍓

Our server refuses all other options by sending the appropriate DONTs and WONTs. Besides ECHO and Suppress GA, we recognize the following TELNET "control sequences" 💅

1. Interrupt Process (IP) - The server substitutes the system wide interrupt character <control-Z> (ACII SUB), which immediately interrupts the process and hands control to the immediately superior process. If the user is several levels down in their process tree, they may have to send several IP's to reach the top level 🌳 Note that IP does not interrupt the running process the way <control-G> interrupts muddle. It only passes control up to the superior 🫶

2. Erase Character (EC) - The server substitutes the system wide standard erase character <rubout> (ACII DEL). The deletion isn't done by the server, though. It's done by the receiving process 🙈 It's conceivable that some process (like a user TELNET) takes no action on receiving EC. Most processes will echo the deleted character(s). Several EC's will delete the several previous characters. (If the console is declared to be an IMLAC, the deleted character is removed from the screen 🖥️)

3. Abort Output (AO) - The server substitutes the character <control-S> (ACII DC3). Many but not all of our programs follow the control-S convention 🛑 What happens on receiving AO depends on the program. A normal outcome is that output and the current command are aborted (without necessarily running to completion). In many programs, there's no way to stop output except by sending an IP and "killing" the inferior process 💀

4. Are You There (AYT) - The server prints the message ****connections still open*****, preceded and followed by CRLF's, when it receives an AYT 📨 Someday we may also report on the state of the user's job 👀

5. Erase Line (EL) - We're a character-at-a-time system, so EL has little meaning here. We throw it (and the preceding IAC) away 🗑️

6. Break (BRK) - We substitute three NUL's upon receiving BRK. This matches what happens when the "Break" key is hit on local teletypes 🖨️ Programs generally do nothing useful when break is received (except echo |@|@|@), but sending BRK may cause strange program reactions, so beware ⚠️

7. Synch - Whenever the server receives the synch INS, it flushes all characters except the interesting (control sequence) characters until it receives a DM. We also cause an implicit IP on receipt of SYNCH 🧹

8. We follow the CRLF and CRNUL convention for transmitting EOL and CR, respectively 🎀

---

II. OUR USER-TELNET IMPLEMENTATION 🦋

The new user-TELNET (implemented in CALICO NETWORK using a new "TELCOM" subroutine) accepts negotiation for the ECHO and suppress GA options. The program tries to negotiate out of receiving GA's, and it tries the ECHO negotiation if the settings file for the host says remote echo 🌸 Special characters are defined for EC, EL, AO, AYT, BRK, SYNCH, IP, and the ESCAPE character to command level. Each one has a default value, and the user can change it by typing the symbol followed by the new character at NETWRK command level 💜 To send EC, EL, and so on, the user just types the special character for that function. The user can also send these characters with the send.special command at NETWRK command level 🧚

In "line mode", EC and EL do a "local" character and line erase instead of sending EC and EL to the remote host ✨ Here are the default values for the "special" characters in TELNET:

     ESCAPE - backslash
     EC - <DEL>
     EL - <CAN> or |X
     AO - |S
     IP - |R
     AYT - |T
     Synch - |Y
     Break - no preassigned value.

The user can change their echo mode by escaping to NETWRK command level and using the commands echo.local or echo.remote 👑 Note that the modes only change when the negotiation for the mode change succeeds. Either way, the user is told how the negotiation went 📣

---

III. INSTALLING THE NEW TELNETS 🚀

On Monday July 2, we brought up the user and server TELNETs briefly, and we found that most hosts did not "recognize" IAC's and did not honor the new protocol 😭 Usage of both our server and user TELNETs was chaotic. So we didn't install the new user and server TELNETs, and the old TELNETs are still running 🫠

The new and old TELNETs are definitely not compatible 🚫 The server tries (and should try) to negotiate out of sending GA's and also to send echo. That negotiation causes problems with "old-style" user TELNETs 💀 Also, if the Suppress GA negotiation is unsuccessful (which is the case with "old" user-TELNETs), the server keeps sending IAC GA's when appropriate.

We found one way to make our "new" server compatible with "old" user TELNETs: come up in a mode that doesn't start any option negotiation and doesn't send GA's unless requested (ie, the default is to suppress GA"s). As mentioned earlier, the server also accepts the old "TELNET control" sequences. This makes the server compatible with both the old and the new user TELNETs (except it violates protocol by not sending GA's) 🙈 We propose to install this server on our socket 1 🔌

To encourage experimentation with the new TELNET protocol, we installed the new server TELNET on socket 60 (octal 105) 🧪 This new server follows the new protocol (ie, it sends GA's) and starts spontaneous negotiation for remote echo and suppress GA. Implementors on other hosts are encouraged to use this service to debug their user TELNETs (and our server) 💖 We think the transition to the new protocol will be smoother if new TELNET servers come up on experimental sockets. We're also willing to help debug other servers from our User TELNET 🫶

Finally, we'd like to lobby for making suppress GA the default (like our present server on socket 1) 📣 Only a few hosts seem to need GA's (AMES-67 and UCLA-CON). I think the reason sending GA is the default in the current protocol specification is that representatives from the concerned hosts wanted GA to be implemented. It doesn't matter to them whether sending GA or suppress GA is the default, as long as they can get a remote server to send a GA 🤷‍♀️ The protocol could be specified so that everyone has to implement a "send GA option". Making "suppress GA" the default would avoid unnecessary negotiation in a great majority of cases ✨ Another advantage is that not sending GA's makes the new server compatible with both old and new user TELNETs 🌈

Bestie, that's the whole thing! 🎀

[ This RFC was put into machine readable form for entry ] [ into the online RFC archives by Serge Hallyn 9/97 ]