RFC 857

TELNET ECHO OPTION 🎀

okay bestie, so this is RFC 857 📜 It's from the Network Working Group and it was written by J. Postel and J. Reynolds at ISI in May 1983. It obsoletes NIC 15390, so that older doc is officially retired 💀 The status line says it specifies a standard for the ARPA Internet community, and hosts on the ARPA Internet are expected to adopt and implement it 🫶

---

1. Command Name and Code ✨

the option has one name, ECHO, and it's command code 1 🔢

ECHO       1

2. Command Meanings 💅

there are four commands, and each one has its own vibe 🦋

2.1. IAC WILL ECHO

• IAC WILL ECHO means the sender REQUESTS to start echoing the data characters it gets over the TELNET connection back to whoever sent them, or it's confirming that it will now begin 🌸

2.2. IAC WON'T ECHO

• IAC WON'T ECHO means the sender DEMANDS that echoing stops, or it refuses to start 🙅‍♀️

2.3. IAC DO ECHO

• IAC DO ECHO means the sender REQUESTS that the receiver start echoing, or it's confirming the receiver is expected to echo the characters it gets back to the sender 🔥

2.4. IAC DON'T ECHO

• IAC DON'T ECHO means the sender DEMANDS the receiver stop echoing, or not start 👑

3. Default 🍓

the default is WON'T ECHO and DON'T ECHO, which basically means no echoing happens over the TELNET connection 💜

4. Motivation for the Option 🧚

okay so the NVT has a printer and a keyboard, and they're nominally hooked up so that "echoes" never have to travel over the network 🖨️ Basically the NVT normally runs in a mode where whatever you type gets turned around locally and printed 💻

But in highly interactive situations, it's giving "the remote process should control the echo" 👀 That means the command language interpreter, or whatever process the characters are going to, should be the one deciding how they get echoed on the printer ✨ So there needs to be a TELNET option that lets both ends agree that characters typed on an NVT keyboard get echoed by the party on the other end of the connection 🫶

5. Description of the Option 💖

when the echoing option is in effect, the party doing the echoing is expected to transmit (echo) the data characters it receives back to the sender 📣 The option doesn't require the echoed characters to be exactly the ones received. For example, a bunch of systems echo the ASCII ESC character as something other than ESC 🙈 When echoing is not in effect, the receiver of data characters should not echo them back to the sender. That doesn't stop the receiver from responding to the characters it got, though 🌈

The normal TELNET connection is two way 🔁 Data flows in each direction independently, and neither, either, or both directions may be operating in echo mode at the same time 🦋 There are five reasonable modes of operation for echoing on a connection pair, and here they are:

                <----------------

      Process 1                   Process 2
                ---------------->
                 Neither end echoes

                <----------------
                   \
      Process 1    /              Process 2
                ---------------->
             One end echoes for itself

                <----------------
                             \
      Process 1              /    Process 2
                ---------------->
          One end echoes for the other

                <----------------
                   \         /
      Process 1    /         \    Process 2
                ---------------->
          Both ends echo for themselves

                <----------------
                   \ /
      Process 1    / \            Process 2
                ---------------->
           One end echoes for both ends

this option lets you decide whether or not either end will echo for the other 🎀 It does not control whether an end echoes for itself. That's left totally up to the systems at each end, though they can use info about the state of "remote" echoing negotiations when they make that call 💅

⚠️ Watch out: if BOTH hosts enter the mode of echoing characters transmitted by the other host, then any character sent in either direction will get "echoed" back and forth indefinitely 😭 So each implementation should take care that, if one site is echoing, echoing is not permitted to be turned on at the other site 🚫

as the TELNET Protocol Specification explains, both parties to a full-duplex TELNET connection start out assuming each direction is in the default mode, which is non-echo. (Non-echo means not using this option, and it's the same as DON'T ECHO and WON'T ECHO) 🌸

if either party wants itself to echo characters to the other party, or wants the other party to echo characters to it, that party sends the appropriate command (WILL ECHO or DO ECHO) and then waits (and hopes) for the option to be accepted 🤞 If the request is refused, the connection keeps operating in non-echo mode. If it's accepted, the connection goes into echo mode ✨

once a connection is in echo mode, either party can demand that it go back to non-echo mode by sending the appropriate DON'T ECHO or WON'T ECHO command. The other party has to confirm that, which lets the connection operate in non-echo mode again 👑 Just like each direction can enter remote echoing mode independently, each direction has to be removed from remote echoing mode separately 🦋

implementations of the echo option, like implementations of every other TELNET option, must follow the loop preventing rules in the General Considerations section of the TELNET Protocol Specification 🔒 Also, so that switches between echo and non-echo mode happen with minimal confusion (momentary double echoing, etc.), mode switches should be timed precisely with the reception and transmission of echo requests and demands ⏱️ For instance, if one party answers a DO ECHO with a WILL ECHO, then all data characters received after the DO ECHO should be echoed, and the WILL ECHO should come right before the first of the echoed characters 💜

the echoing option by itself usually won't be enough to get what people normally call remote computer echoing of characters typed on a terminal keyboard 🙃 You'll normally have to invoke the SUPPRESS-GO AHEAD option along with the ECHO option to get character-at-a-time remote echoing 🎀

6. A Sample Implementation of the Option 🌈

here's a description of a possible implementation for a simple user system called "UHOST" 🖥️

so for each user terminal, the UHOST could keep three state bits: whether the terminal echoes for itself (UHOST ECHO always) or not (ECHO mode possible), whether the (human) user prefers ECHO mode or non-ECHO mode, and whether the connection from this terminal to the server is in ECHO or non-ECHO mode. We'll call these three bits P(hysical), D(esired), and A(ctual) 🧠

when a terminal dials up the UHOST, the P-bit gets set appropriately, the D-bit is set equal to it, and the A-bit is set to non-ECHO 📞 The P-bit and D-bit can be manually reset with direct commands if the user wants 🫶 For example, a user in Hawaii on a "full-duplex" terminal would choose not to operate in ECHO mode, no matter what a mainland server prefers 🌺 They'd tell the UHOST to change their D-bit from ECHO to non-ECHO 🏝️

when a connection is opened from the UHOST terminal to a server, the UHOST would send the server a DO ECHO command if the MIN of the P- and D-bits (with non-ECHO counted as less than ECHO) is different from the A-bit 🧮 If a WON'T ECHO or WILL ECHO arrives from the server, the UHOST sets the A-bit to the MIN of the received request, the P-bit, and the D-bit 💅 If that changes the state of the A-bit, the UHOST sends the appropriate acknowledgment. If it doesn't change anything, the UHOST sends the appropriate refusal, but only if 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 the UHOST terminal user changes either the P-bit or the D-bit while a connection is open, the UHOST repeats the tests above and sends a DO ECHO or DON'T ECHO if it's necessary 🔁 When the connection closes, the UHOST resets the A-bit to indicate UHOST echoing 🌸

the UHOST implementation wouldn't send DO ECHO or DON'T ECHO commands to the server except when the connection opens or the user explicitly changes their echoing mode. Bigger hosts might switch modes pretty often though 🏢 For example, while a line-at-a-time system is running, the server might try to put the user in local echo mode by sending WON'T ECHO. But while a character-at-a-time system is running, the server might try to turn on remote echoing for the user by sending WILL ECHO ⌨️ Also, while the UHOST will never send WILL ECHO and will only send WON'T ECHO to refuse a DO ECHO from the server, a server host might often send both WILL and WON'T ECHO 🦋