Telnet issues
RFC 435

Document Type RFC - Unknown (January 1973; No errata)
Updates RFC 318
Last updated 2013-03-02
Stream Legacy
Formats plain text pdf html bibtex
Stream Legacy state (None)
Consensus Boilerplate Unknown
RFC Editor Note (None)
IESG IESG state RFC 435 (Unknown)
Telechat date
Responsible AD (None)
Send notices to (None)
Network Working Group                                          B. Cosell
Request for Comment: 435                                         BBN-NET
NIC: 13675                                                     D. Walden
Category: TELNET, Protocols, Echoing                             BBN-NET
References: 318, 357                                      5 January 1973

                             TELNET Issues

   This RFC discusses a number of TELNET related issues which have been
   bothering us [1].  The basic, central issue we started from was that
   of echoing.  We worked downward from our difficulties to discover the
   basic principles at the root of our unhappiness, and from there
   worked back upwards to design a scheme which we believe to be better.
   In this note we will discuss both the alternate scheme and its
   underlying principles.

   As something of a non sequitur, before discussing echoing we feel it
   expedient to dismiss one possible stumbling block, outright.  HIDE
   YOUR INPUT may or may not be a good idea, this question not
   concerning us at the moment.  Whatever the case, the issue of hiding
   input is certainly separable from that of echoing.  We, therefore,
   strongly recommend that a STOP HIDING YOUR INPUT command be
   sanctioned to replace the multiplexing of this function on the NO
   ECHO command.  Once this has been done, the pair of commands HIDE
   YOUR INPUT and STOP HIDING YOUR INPUT can be kept or discarded
   together, and we can discuss the issue of echoing independently of


   The basic observation that we made regarding echoing was that servers
   seem to be optimized to best handle terminals which either do their
   own echoing or do not, but not both.  Therefore, the present TELNET
   echoing conventions, which prohibit the server from initiating a
   change in echo mode, seemed overly confining.  The servers are
   burdened with users who are in the 'wrong' mode, in which they might
   not otherwise have to be, and users, both human and machine, are
   burdened with remembering the proper echoing mode, and explicitly
   setting it up, for all the different servers.  It is our
   understanding that this prohibition was imposed on the servers to
   prevent loops from developing because of races which can arise when
   the server and user both try to set up an echo mode simultaneously.
   We will describe a method wherein both parties can initiate a change
   of echo mode and show that the method does not loop.

Cosell & Walden                                                 [Page 1]
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
Show full document text