<pre>Network Working Group                                          J. Postel
Request for Comments: 857                                    J. Reynolds
                                                                     ISI
Obsoletes: NIC 15390                                            May 1983

                           <span class="h1">TELNET ECHO OPTION</span>


This RFC specifies a standard for the ARPA Internet community.  Hosts on
the ARPA Internet are expected to adopt and implement this standard.

<span class="h2"><a class="selflink" id="section-1" href="#section-1">1</a>. Command Name and Code</span>

   ECHO       1

<span class="h2"><a class="selflink" id="section-2" href="#section-2">2</a>. Command Meanings</span>

   IAC WILL ECHO

      The sender of this command REQUESTS to begin, or confirms that it
      will now begin, echoing data characters it receives over the
      TELNET connection back to the sender of the data characters.

   IAC WON'T ECHO

      The sender of this command DEMANDS to stop, or refuses to start,
      echoing the data characters it receives over the TELNET connection
      back to the sender of the data characters.

   IAC DO ECHO

      The sender of this command REQUESTS that the receiver of this
      command begin echoing, or confirms that the receiver of this
      command is expected to echo, data characters it receives over the
      TELNET connection back to the sender.

   IAC DON'T ECHO

      The sender of this command DEMANDS the receiver of this command
      stop, or not start, echoing data characters it receives over the
      TELNET connection.

<span class="h2"><a class="selflink" id="section-3" href="#section-3">3</a>. Default</span>

   WON'T ECHO

   DON'T ECHO

      No echoing is done over the TELNET connection.

<span class="h2"><a class="selflink" id="section-4" href="#section-4">4</a>. Motivation for the Option</span>


<span class="grey">Postel &amp; Reynolds                                               [Page 1]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-2" ></span>
<span class="grey"><a href="./rfc857">RFC 857</a>                                                         May 1983</span>


   The NVT has a printer and a keyboard which are nominally
   interconnected so that "echoes" need never traverse the network; that
   is to say, the NVT nominally operates in a mode where characters
   typed on the keyboard are (by some means) locally turned around and
   printed on the printer.  In highly interactive situations it is
   appropriate for the remote process (command language interpreter,
   etc.) to which the characters are being sent to control the way they
   are echoed on the printer.  In order to support such interactive
   situations, it is necessary that there be a TELNET option to allow
   the parties at the two ends of the TELNET connection to agree that
   characters typed on an NVT keyboard are to be echoed by the party at
   the other end of the TELNET connection.

<span class="h2"><a class="selflink" id="section-5" href="#section-5">5</a>. Description of the Option</span>

   When the echoing option is in effect, the party at the end performing
   the echoing is expected to transmit (echo) data characters it
   receives back to the sender of the data characters.  The option does
   not require that the characters echoed be exactly the characters
   received (for example, a number of systems echo the ASCII ESC
   character with something other than the ESC character).  When the
   echoing option is not in effect, the receiver of data characters
   should not echo them back to the sender; this, of course, does not
   prevent the receiver from responding to data characters received.

   The normal TELNET connection is two way.  That is, data flows in each
   direction on the connection independently; and neither, either, or
   both directions may be operating simultaneously in echo mode.  There
   are five reasonable modes of operation for echoing on a connection
   pair:


                &lt;----------------

      Process 1                   Process 2
                ----------------&gt;
                 Neither end echoes


                &lt;----------------
                   \
      Process 1    /              Process 2
                ----------------&gt;
             One end echoes for itself






<span class="grey">Postel &amp; Reynolds                                               [Page 2]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-3" ></span>
<span class="grey"><a href="./rfc857">RFC 857</a>                                                         May 1983</span>



                &lt;----------------
                             \
      Process 1              /    Process 2
                ----------------&gt;
          One end echoes for the other


                &lt;----------------
                   \         /
      Process 1    /         \    Process 2
                ----------------&gt;
          Both ends echo for themselves


                &lt;----------------
                   \ /
      Process 1    / \            Process 2
                ----------------&gt;
           One end echoes for both ends

   This option provides the capability to decide on whether or not
   either end will echo for the other.  It does not, however, provide
   any control over whether or not an end echoes for itself;  this
   decision must be left to the sole discretion of the systems at each
   end (although they may use information regarding the state of
   "remote" echoing negotiations in making this decision).

   It should be noted that if BOTH hosts enter the mode of echoing
   characters transmitted by the other host, then any character
   transmitted in either direction will be "echoed" back and forth
   indefinitely.  Therefore, care should be taken in each implementation
   that if one site is echoing, echoing is not permitted to be turned on
   at the other.

   As discussed in the TELNET Protocol Specification, both parties to a
   full-duplex TELNET connection initially assume each direction of the
   connection is being operated in the default mode which is non-echo
   (non-echo is not using this option, and the same as DON'T ECHO, WON'T
   ECHO).

   If either party desires himself to echo characters to the other party
   or for the other party to echo characters to him, that party gives
   the appropriate command (WILL ECHO or DO ECHO) and waits (and hopes)
   for acceptance of the option.  If the request to operate the
   connection in echo mode is refused, then the connection continues to
   operate in non-echo mode.  If the request to operate the connection
   in echo mode is accepted, the connection is operated in echo mode.


<span class="grey">Postel &amp; Reynolds                                               [Page 3]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-4" ></span>
<span class="grey"><a href="./rfc857">RFC 857</a>                                                         May 1983</span>


   After a connection has been changed to echo mode, either party may
   demand that it revert to non-echo mode by giving the appropriate
   DON'T ECHO or WON'T ECHO command (which the other party must confirm
   thereby allowing the connection to operate in non-echo mode).  Just
   as each direction of the TELNET connection may be put in remote
   echoing mode independently, each direction of the TELNET connection
   must be removed from remote echoing mode separately.

   Implementations of the echo option, as implementations of all other
   TELNET options, must follow the loop preventing rules given in the
   General Considerations section of the TELNET Protocol Specification.
   Also, so that switches between echo and non-echo mode can be made
   with minimal confusion (momentary double echoing, etc.), switches in
   mode of operation should be made at times precisely coordinated with
   the reception and transmission of echo requests and demands.  For
   instance, if one party responds to a DO ECHO with a WILL ECHO, all
   data characters received after the DO ECHO should be echoed and the
   WILL ECHO should immediately precede the first of the echoed
   characters.

   The echoing option alone will normally not be sufficient to effect
   what is commonly understood to be remote computer echoing of
   characters typed on a terminal keyboard--the SUPPRESS-GO AHEAD option
   will normally have to be invoked in conjunction with the ECHO option
   to effect character-at-a-time remote echoing.

<span class="h2"><a class="selflink" id="section-6" href="#section-6">6</a>. A Sample Implementation of the Option</span>

   The following is a description of a possible implementation for a
   simple user system called "UHOST".

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

   When a terminal dials up the UHOST the P-bit is 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 may be manually reset by direct commands if the user
   so desires.  For example, a user in Hawaii on a "full-duplex"
   terminal, would choose not to operate in ECHO mode, regardless of the
   preference of a mainland server.  He should direct the UHOST to
   change his D-bit from ECHO to non-ECHO.

   When a connection is opened from the UHOST terminal to a server, the


<span class="grey">Postel &amp; Reynolds                                               [Page 4]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-5" ></span>
<span class="grey"><a href="./rfc857">RFC 857</a>                                                         May 1983</span>


   UHOST would send the server a DO ECHO command if the MIN (with
   non-ECHO less than ECHO) of the P- and D-bits is different from the
   A-bit.  If a WON'T ECHO or WILL ECHO arrives from the server, the
   UHOST will set 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, the
   UHOST will send off the appropriate acknowledgment; if it does not,
   then the UHOST will send off the appropriate refusal if not changing
   meant that it had to deny the request (i.e., the MIN of the P-and
   D-bits was less than the received A-request).

   If while a connection is open, the UHOST terminal user changes either
   the P-bit or D-bit, the UHOST will repeat the above tests and send
   off a DO ECHO or DON'T ECHO, if necessary.  When the connection is
   closed, the UHOST would reset the A-bit to indicate UHOST echoing.

   While the UHOST's implementation would not involve DO ECHO or DON'T
   ECHO commands being sent to the server except when the connection is
   opened or the user explicitly changes his echoing mode, bigger hosts
   might invoke such mode switches quite frequently.  For instance,
   while a line-at-a-time system were running, the server might attempt
   to put the user in local echo mode by sending the WON'T ECHO command
   to the user; but while a character-at-a-time system were running, the
   server might attempt to invoke remote echoing for the user by sending
   the WILL ECHO command to the user.  Furthermore, while the UHOST will
   never send a WILL ECHO command and will only send a WON'T ECHO to
   refuse a server sent DO ECHO command, a server host might often send
   the WILL and WON'T ECHO commands.























Postel &amp; Reynolds                                               [Page 5]
</pre>