Telnet Echo Option
RFC 857

Document Type RFC - Internet Standard (May 1983; No errata)
Also known as STD 28
Last updated 2013-03-02
Stream Legacy
Formats plain text pdf htmlized bibtex
Stream Legacy state (None)
Consensus Boilerplate Unknown
RFC Editor Note (None)
IESG IESG state RFC 857 (Internet Standard)
Telechat date
Responsible AD (None)
Send notices to (None)
Network Working Group                                          J. Postel
Request for Comments: 857                                    J. Reynolds
                                                                     ISI
Obsoletes: NIC 15390                                            May 1983

                           TELNET ECHO OPTION

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

1. Command Name and Code

   ECHO       1

2. Command Meanings

   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.

3. Default

   WON'T ECHO

   DON'T ECHO

      No echoing is done over the TELNET connection.

4. Motivation for the Option

Postel & Reynolds                                               [Page 1]



RFC 857                                                         May 1983

   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.

5. Description of the Option

   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:

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

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

Postel & Reynolds                                               [Page 2]



RFC 857                                                         May 1983

      
                <----------------
                             \
      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 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
Show full document text