As per Relevance of the word terminal, we have this rfc below:
Network Working Group J.
Request for Comments: 857 J.
Obsoletes: NIC 15390 May 1983
TELNET ECHO
This RFC specifies a standard for the ARPA Internet community. Hosts
the ARPA Internet are expected to adopt and implement this standard
1. Command Name and
ECHO 1
2. Command
IAC WILL
The sender of this command REQUESTS to begin, or confirms that
will now begin, echoing data characters it receives over
TELNET connection back to the sender of the data characters
IAC WON'T
The sender of this command DEMANDS to stop, or refuses to start
echoing the data characters it receives over the TELNET
back to the sender of the data characters
IAC DO
The sender of this command REQUESTS that the receiver of
command begin echoing, or confirms that the receiver of
command is expected to echo, data characters it receives over
TELNET connection back to the sender
IAC DON'T
The sender of this command DEMANDS the receiver of this
stop, or not start, echoing data characters it receives over
TELNET connection
3.
WON'T
DON'T
No echoing is done over the TELNET connection
4. Motivation for the
Postel & Reynolds [Page 1]
RFC 857 May 1983
The NVT has a printer and a keyboard which are
interconnected so that "echoes" need never traverse the network;
is to say, the NVT nominally operates in a mode where
typed on the keyboard are (by some means) locally turned around
printed on the printer. In highly interactive situations it
appropriate for the remote process (command language interpreter
etc.) to which the characters are being sent to control the way
are echoed on the printer. In order to support such
situations, it is necessary that there be a TELNET option to
the parties at the two ends of the TELNET connection to agree
characters typed on an NVT keyboard are to be echoed by the party
the other end of the TELNET connection
5. Description of the
When the echoing option is in effect, the party at the end
the echoing is expected to transmit (echo) data characters
receives back to the sender of the data characters. The option
not require that the characters echoed be exactly the
received (for example, a number of systems echo the ASCII
character with something other than the ESC character). When
echoing option is not in effect, the receiver of data
should not echo them back to the sender; this, of course, does
prevent the receiver from responding to data characters received
The normal TELNET connection is two way. That is, data flows in
direction on the connection independently; and neither, either,
both directions may be operating simultaneously in echo mode.
are five reasonable modes of operation for echoing on a
pair
<----------------
Process 1 Process 2
---------------->
Neither end
<----------------
\
Process 1 / Process 2
---------------->
One end echoes for
Postel & Reynolds [Page 2]
RFC 857 May 1983
<----------------
\
Process 1 / Process 2
---------------->
One end echoes for the
<----------------
\ /
Process 1 / \ Process 2
---------------->
Both ends echo for
<----------------
\ /
Process 1 / \ Process 2
---------------->
One end echoes for both
This option provides the capability to decide on whether or
either end will echo for the other. It does not, however,
any control over whether or not an end echoes for itself;
decision must be left to the sole discretion of the systems at
end (although they may use information regarding the state
"remote" echoing negotiations in making this decision).
It should be noted that if BOTH hosts enter the mode of
characters transmitted by the other host, then any
transmitted in either direction will be "echoed" back and
indefinitely. Therefore, care should be taken in each
that if one site is echoing, echoing is not permitted to be turned
at the other
As discussed in the TELNET Protocol Specification, both parties to
full-duplex TELNET connection initially assume each direction of
connection is being operated in the default mode which is non-
(non-echo is not using this option, and the same as DON'T ECHO, WON'
ECHO).
If either party desires himself to echo characters to the other
or for the other party to echo characters to him, that party
the appropriate command (WILL ECHO or DO ECHO) and waits (and hopes
for acceptance of the option. If the request to operate
connection in echo mode is refused, then the connection continues
operate in non-echo mode. If the request to operate the
in echo mode is accepted, the connection is operated in echo mode
Postel & Reynolds [Page 3]
RFC 857 May 1983
After a connection has been changed to echo mode, either party
demand that it revert to non-echo mode by giving the
DON'T ECHO or WON'T ECHO command (which the other party must
thereby allowing the connection to operate in non-echo mode).
as each direction of the TELNET connection may be put in
echoing mode independently, each direction of the TELNET
must be removed from remote echoing mode separately
Implementations of the echo option, as implementations of all
TELNET options, must follow the loop preventing rules given in
General Considerations section of the TELNET Protocol Specification
Also, so that switches between echo and non-echo mode can be
with minimal confusion (momentary double echoing, etc.), switches
mode of operation should be made at times precisely coordinated
the reception and transmission of echo requests and demands.
instance, if one party responds to a DO ECHO with a WILL ECHO,
data characters received after the DO ECHO should be echoed and
WILL ECHO should immediately precede the first of the
characters
The echoing option alone will normally not be sufficient to
what is commonly understood to be remote computer echoing
characters typed on a terminal keyboard--the SUPPRESS-GO AHEAD
will normally have to be invoked in conjunction with the ECHO
to effect character-at-a-time remote echoing
6. A Sample Implementation of the
The following is a description of a possible implementation for
simple user system called "UHOST".
A possible implementation could be that for each user terminal,
UHOST would keep three state bits: whether the terminal echoes
itself (UHOST ECHO always) or not (ECHO mode possible), whether
(human) user prefers to operate in ECHO mode or in non-ECHO mode,
whether the connection from this terminal to the server is in ECHO
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.
P-bit and D-bit may be manually reset by direct commands if the
so desires. For example, a user in Hawaii on a "full-duplex
terminal, would choose not to operate in ECHO mode, regardless of
preference of a mainland server. He should direct the UHOST
change his D-bit from ECHO to non-ECHO
When a connection is opened from the UHOST terminal to a server,
Postel & Reynolds [Page 4]
RFC 857 May 1983
UHOST would send the server a DO ECHO command if the MIN (
non-ECHO less than ECHO) of the P- and D-bits is different from
A-bit. If a WON'T ECHO or WILL ECHO arrives from the server,
UHOST will set the A-bit to the MIN of the received request,
P-bit, and the D-bit. If this changes the state of the A-bit,
UHOST will send off the appropriate acknowledgment; if it does not
then the UHOST will send off the appropriate refusal if not
meant that it had to deny the request (i.e., the MIN of the P-
D-bits was less than the received A-request).
If while a connection is open, the UHOST terminal user changes
the P-bit or D-bit, the UHOST will repeat the above tests and
off a DO ECHO or DON'T ECHO, if necessary. When the connection
closed, the UHOST would reset the A-bit to indicate UHOST echoing
While the UHOST's implementation would not involve DO ECHO or DON'
ECHO commands being sent to the server except when the connection
opened or the user explicitly changes his echoing mode, bigger
might invoke such mode switches quite frequently. For instance
while a line-at-a-time system were running, the server might
to put the user in local echo mode by sending the WON'T ECHO
to the user; but while a character-at-a-time system were running,
server might attempt to invoke remote echoing for the user by
the WILL ECHO command to the user. Furthermore, while the UHOST
never send a WILL ECHO command and will only send a WON'T ECHO
refuse a server sent DO ECHO command, a server host might often
the WILL and WON'T ECHO commands
Postel & Reynolds [Page 5]
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
