Network Working Group J. Postel
Request for Comments: 857 J. Reynolds
ISI
Obsoletes: NIC 15390 May 1983
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
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
<---------------- \ 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 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.
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.
6. A Sample Implementation of the Option
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 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.
Back to the Telnet Protocol
