RFC 435

TELNET Issues 🎀

okay bestie, this is RFC 435 🦋 (NIC 13675), written by B. Cosell and D. Walden from BBN-NET, dated 5 January 1973. It's filed under TELNET, Protocols, and Echoing, and it references RFC 318 and RFC 357. It doesn't obsolete or update any other RFCs. ✨ (Part 1 of 2)

This RFC is about a pile of TELNET stuff that's been bugging the authors [1] 😭. The main issue they started from was echoing. They worked down from their problems to find the root principles behind their unhappiness, then built back up to a scheme they think is way better 💖. This note covers both the alternate scheme and the principles under it.

Before echoing, they want to clear one thing out of the way, because it's a total non sequitur 🙈. HIDE YOUR INPUT might or might not be a good idea, but that's not what they're asking right now. Hiding input is totally separate from echoing. So they strongly recommend a STOP HIDING YOUR INPUT command be sanctioned, to replace multiplexing that function onto the NO ECHO command 🫶. Once that's done, HIDE YOUR INPUT and STOP HIDING YOUR INPUT can be kept or dropped together, and echoing can be discussed on its own.

---

Echoing 🦋

okay so the basic observation about echoing is that servers seem to be optimized for terminals that either echo their own input or don't, but not both 💅. The current TELNET echoing conventions don't let the server start a change in echo mode, and honestly that feels way too restrictive 💀. Servers end up stuck with users in the "wrong" mode, which they wouldn't have to deal with otherwise. Users, both human and machine, have to remember the right echo mode for every single server and set it up by hand 😤.

As far as the authors understand it, that prohibition was put in place to stop loops. The problem was races: the server and the user both trying to set up an echo mode at the same time 🌀. The authors describe a method where either party can start a change, and they show that it doesn't loop 🔥.

This alternate spec leans on three main assumptions ✨:

• First, the server, as well as the user, should be able to suggest the echo mode.
• Second, all terminals must be able to provide their own echoes, either internally or through the local Host.
• Third, all servers must be able to run in a mode that assumes a remote terminal is providing its own echoes.

The last two come from wanting a universal, minimal base to build on 🧚. A Host that normally supplies echoes can turn that code off fairly easily, but a Host that doesn't do echoing would find it hard to fit those routines into its system. It's easier for a local Host to supply echoes to a terminal that can't do its own. Undoing echoing in a terminal with automatic echoing built in, though, is basically impossible 😭.

Here's the plan. The existing ECHO and NO ECHO commands keep their names, but now they mean this 💜:

• ECHO from the server to the user means 'I'll echo to you'.
• ECHO from the user to the server means 'You echo to me'.
• NO ECHO from the server to the user means 'I'll not echo to you'.
• NO ECHO from the user to the server means 'Don't you echo to me'.

These are pretty much what the commands already mean, except most current implementations flip the server-to-user meanings 🙃.

In this spec, when a connection opens, both server and user assume the user is echoing locally 🌸. If the user would rather the server do the echoing, the user can send an ECHO command. If the server would rather echo (say, because it's optimized for very interactive echoing), the server can send an ECHO command too. Neither one is required to do anything, since it's just a matter of preference 💖.

When either party gets either command, here's what happens ✨. If the requested mode is admissible, the recipient should start operating in that mode. If that's an actual change, it should reply with the same command to confirm that the changeover happened, and when. If the command asks for an inadmissible mode, the recipient should send back the command's inverse as a refusal. That refusal has to be NO ECHO, since neither party can refuse a change into NO ECHO 🙅‍♀️.

The formal rules, bestie 👑:

1. Both server and user assume that a connection is initially in NO ECHO mode.
2. Neither party can refuse a request to change into NO ECHO mode.
3. Either party may send an unsolicited command only to request a change in mode.
4. A party only changes its echo mode when it receives an admissible request.
5. When a command is received, the party replies with its echo mode, unless it did not have to change mode to honor the request.

Several properties of this scheme are worth noting 🦋:

1. NO ECHO stays as the nominal connection mode. A connection only works in ECHO mode when both parties agree to operate that way.
2. The procedure cannot loop. No matter which party (or both) starts a change, or in what time order, there are at most three commands sent between the parties [2] 🔁.
3. Servers are free to specify their preferred mode of operation. That means human and machine users don't have to learn the proper mode for each server 🎀.

---

Three Principles 💅

Now let's go back to the general principles the authors mentioned at the start: default implementation, negotiated options, and symmetry 🌈.

The principle of default implementation says that for every option, defaults are declared and must be implemented. This is why the authors go looking for the minimum for each option, to keep the burden on everybody as small as possible, and it also prevents loops in the protocol 🧠.

The principle of negotiated options says that options must be agreed upon by all (both) parties concerned. This is what led to the positive/negative acknowledgement scheme ✨.

The principle of symmetry says that neither party should have to know whether it's the server or the user 🪞. The scheme as described so far isn't totally symmetrical, though, and the authors say they'll come back to that in a later section 👀.

The echoing scheme plus these principles make up the heart of the authors' comments on TELNET 💖. The rest of the note covers further ways the protocol could be expanded overall. These suggestions are really just applications and developments of the principles already on the table. The fecundity of these expansions, and the good feel they give off, make the authors even more convinced they were right the first time 🥹.

Thus far, they've made one simple, concrete suggestion that they believe should be sanctioned right away 🚀. Looking past that, though, they've come up with a whole bunch of more ambitious changes. The rest of the RFC describes ideas that don't feel as urgent as the proposal above, but that should still be kept in mind if the network community decides to revamp the protocol 🔮.

Symmetry 🪞

okay so bestie, some of the TENEX crew (Thomas, Burchfiel and Tomlinson, literal big brains 🧠) pointed out that we made the protocol rules symmetrical but NOT the meanings of the commands 😭. Like, the ECHO command ("I'll echo to you" vs "You echo to me") quietly assumes both sides already know who's the server and who's the user. That's a mess for server-server connections, where it's unclear who's the user, AND for user-user connections, like linking Teletypes together, where it's unclear who's the server 💀.

So we looked into it and realized there are only five reasonable modes of echoing on a connection pair [4]. Here they are, A through E 🦋:

                     <------------------<
A          Process 1                        Process 2
                     >------------------>
                     neither end echoes


                     <------------------<
B          Process 1  <--+                  Process 2
                        ^
                     >--^--------------->
                    one end echoes for itself


                     <------------------<
C          Process 1  <--------------+     Process 2
                                    ^
                     >--------------^--->
                    one end echoes for the other


                     <--------------V---<
D          Process 1  <--+           V       Process 2
                        ^           +--->
                     >--^--------------->
                    both ends echo for themselves


                     <-----V------------<
E          Process 1  <--+  V               Process 2
                        ^  +------------>
                     >--^--------------->
                    one end echoes for both ends

The TENEX group suggested that four commands are enough to handle completely symmetric echoing ✨. We'd already mentioned them, honestly: the two possible meanings for each of ECHO and NO ECHO. Spelled out, they're I'LL ECHO TO YOU, YOU ECHO TO ME, DON'T ECHO TO ME and I'LL NOT ECHO TO YOU. Echoing is now the negotiation of two options, and the starting defaults are DON'T ECHO TO ME and I'LL NOT ECHO TO YOU 🎀.

When the server or user knows which one it is, the change is minimal, since these commands never had ambiguous meanings in those cases. When an end truly doesn't know, it gets a bit more complicated. Consider both ends in I'LL ECHO TO YOU mode, for example. Even then, the problems are not insurmountable 💅.

Once you commit to symmetry, you can't use one function in two different ways anymore 🙈. On pages 5 and 6 of RFC 318, Postel describes INS and SYNC as a way to simulate a 'break' from user to server, but they flush the output buffers from server to user. Since we really do believe in symmetry, we suggest treating INS/DATA-MARK the same in both directions and adding a new CLEAR YOUR BUFFER option ⭐.

Command Format 🎀

Now that we've extended full symmetry through the other options we've suggested, we can describe the compacted command format we mentioned earlier 🧚.

Instead of four commands per option (I WILL, I WON'T, YOU DO, YOU DON'T), there would be four 'prefixes': WILL, WON'T, DO and DON'T. Each one goes before the single command for each option, and WON'T and DON'T are the default modes. For example, say the codes for WILL and WON'T are 140 and 141, and the codes for ECHO REMOTE and HIDE INPUT are 132 and 133. Then a few of the possible combinations look like this:

140 133 -- DO HIDE INPUT
140 132 -- DO ECHO REMOTE
141 132 -- WON'T ECHO REMOTE
141 133 -- WON'T HIDE INPUT

These are some of the commands we think should exist 🍓:

• I WILL (140)
• I WILL NOT (141)
• YOU DO (142)
• YOU DO NOT (143)
• QUOTE (144)
• SYNC (163)
• SYNC REPLY (164)
• ECHO REMOTE (132)
• SEND A CHARACTER-AT-A-TIME (146)
• SEND INDEPENDENT CR and LF (147)
• SEND IN EBCDIC (162)
• HIDE INPUT (133)
• USE DAVIDSON'S ECHOING STRATEGY (145)

Here's the iconic part 👑. Hosts don't even need to know what all the options are! If we call the mode where every option is in its default state the 'NVT', then a site obviously has to handle an NVT. Beyond that, if it just answers no to any command it doesn't understand, it can totally ignore the options it doesn't want to implement. So options would actually be optional (for once 😤), not just for the user who can skip them, but also for the systems builders who can choose not to offer them!

We hereby volunteer to rigorously specify a version of TELNET that embodies the principles we've described, at whatever level of complexity the network community thinks is sufficient 🫶.

Appendix: A Sample Implementation 🧁

The basic scheme we described is the core of what we've been thinking about. The further extensions are just that: extensions ✨. We worry, though, that people who are spiritually on our side might get scared off by how many changes we're suggesting. So to fight that, we're providing an example of how simply and straightforwardly the basic scheme could be implemented for the TIP [5] 💖.

For each user terminal, the TIP would keep three state bits: whether the terminal echoes for itself (NO ECHO always) or not (ECHO mode possible), whether the (human) user prefers ECHO or NO ECHO mode, and whether the connection to this terminal is in ECHO or NO ECHO mode. We call these three bits P(hysical), D(esired) and A(ctual) 🌸.

When a terminal dials up the TIP, the P-bit is set appropriately, the D-bit is set equal to it, and the A-bit is set to NO ECHO. The P- and A-bits can be reset manually with direct commands if the user wants. For instance, a user in Hawaii on a 'full-duplex' terminal might know that, whatever a mainland server prefers, their terminal had better operate in NO ECHO mode because of satellite delay. They would direct the TIP to change their D-bit from ECHO to NO ECHO 🌈.

When a connection is opened from the TIP terminal to a server, the TIP sends the server an ECHO command if the MIN (with NO ECHO less than ECHO) of the P- and D-bits is different from the A-bit. If a NO ECHO or ECHO arrives from the server, the TIP sets the A-bit to the MIN of the received request, the P-bit and the D-bit. If this changes the state of the A-bit, it sends off the appropriate acknowledgement. If it doesn't change the A-bit, then the TIP sends off the appropriate refusal, since not changing meant it had to deny the request (that is, the MIN of the P- and D-bits was less than the received A-request). If, while a connection is open, the TIP terminal user changes either the P- or D-bit, the TIP repeats the tests above and sends off an ECHO or NO ECHO if necessary. When the connection closes, the TIP resets the A-bit to NO ECHO 🔥.

The TIP's implementation wouldn't send ECHO or NO ECHO commands to the server except when the connection opens or the user explicitly changes their echoing mode. But bigger Hosts might send these commands quite often 👀. For instance, if a JOSS subsystem were running, the server might put the user in NO ECHO mode, but while DDT was running, it might put the user in ECHO mode 🧚‍♀️.

[1] We have assumed that TELNET is defined as suggested by Jon Postel in RFC 318.

[2] Notice that a faulty implementation could achieve the effect of a loop by repeatedly sending a command that was previously refused. We consider this a property of the implementation, not of the scheme in general. A command that has been rejected should not be repeated until something changes, for instance, not until after a different program has been started up 🙈.

[3] Will Crowther, with an eye towards building higher protocols upon TELNET, has suggested adding a SYNC command (not to be confused with the existing SYNCH) and a SYNC REPLY to TELNET. For example, a server might want to wait until a user's terminal output buffer is empty before doing something like closing the connection or passing the connection to another server. Although we don't see a current use for the command pair, they seem like a handy enough building block that we recommend including them 🫶.

[4] It's perhaps worth mentioning that most of the connections in the network are TELNET connections, which are full duplex. Wouldn't it be reasonable to make all Host/Host protocol connections full duplex, rather than simplex? If, for some reason, one truly needs a simplex connection, the reverse direction can always just be ignored 💜.

[5] Readers unfamiliar with the TIP may read the TIP Users Guide, NIC 10916.

[This RFC was put into machine readable form for entry] [into the online RFC archives by Helene Morin, Via Genie, 12/99]