RFC 435 (rfc435) - Page 2 of 10
Telnet issues
Alternative Format: Original Text Document
RFC 435 TELNET Issues 5 January 1973
This alternate specification relies on three primary assumptions.
First as above, the server, as well as the user, should be able to
suggest the echo mode. Second, all terminals must be able to provide
their own echoes, either internally or by means of the local Host.
Third, all servers must be able to operate in a mode which assumes
that a remote terminal is providing its own echoes. Both of these
last two result from the quest for a universal, minimal basis upon
which to build. It is fairly easy for a Host which normally supplies
echoes to disable the appropriate code, but it will difficult for a
Host which does not do echoing to integrate such routines into its
system similarly, it is easier for a local Host to supply echoes to a
terminal which cannot provides its own, but it borders on the
impossible to undo echoing in a terminal which has automatic echoing
built into it.
Our proposed specification would use the present ECHO and NO ECHO
commands as follows: ECHO, when sent by the server to the user, would
mean 'I'll echo to you' ECHO, when sent by the user to the server,
would mean 'You echo to me'. NO ECHO, when sent by the server to the
user, would mean 'I'll not echo to you'; NO ECHO, when sent by the
user to the server, would mean 'Don't you echo to me'. These are, of
course, nearly the same meanings that the commands currently have,
although most current implementations seem to invert the server-to-
user meanings.
In our specification, whenever a connection is opened both server and
user assume that the user is echoing locally. If the user would, in
fact, prefer the server to echo, the user could send off an ECHO
command. Similarly, if the server prefers to do the echoing (for
instance, because the server system is optimized for very interactive
echoing), the server could send off an ECHO command. Neither is
required to do anything, it is only a matter of preference. Upon
receipt of either command by either party, if that is an admissible
mode of operation the recipient should begin operating in that mode,
and if such operation reflects a change in mode, it should respond
with the same command to confirm that (and when) the changeover took
place. If the received command request an inadmissible mode of
operation, then the command's inverse should be sent as a refusal
(this must be NO ECHO, since neither party can refuse a change into
NO ECHO). To state these rules more formally:
1) Both server and user assume that a connection is initially in
NO ECHO mode.
2) Neither party can refuse a request to change into NO ECHO mode.
3) Either party may send an unsolicited command only to request a
change in mode.
Cosell & Walden