rfc435.txt

RFC 的详细文档！

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
   them.

Echoing

   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
   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                                                 [Page 2]

RFC 435                      TELNET Issues                5 January 1973


      4) A party only changes its echo mode when it receives an
         admissible request.

      5) When a command is received, the party replies with its echo
         mode, unless it did not have to change mode to honor the
         request.

   Several properties of this scheme are worthy of note:

      1) NO ECHO is retained as the nominal connection mode.  A
         connection will work in ECHO mode only when both parties agree
         to operate that way.

      2) The procedure cannot loop.  Regardless of which party (or both)
         initiates a change, or in what time order, there are at most
         three commands sent between the parties [2].

      3) Servers are free to specify their preferred mode of operation.
         Thus, human, or machine, users do not have to learn the proper
         mode for each server.

Three Principles

   Let us mention the general principles we alluded to at the beginning
   of this note.  The principles are: default implementation, negotiated
   options and symmetry.  The principle of default implementation merely
   states that for all options, defaults are declare which must be
   implemented.  It is this principle which leads us to seek out the
   'minimum' for each option (to keep the required burden on everybody
   as small as possible), and prevents loops in protocol.  The principle
   of negotiated options merely states that options must be agreed upon
   by all (both) parties concerned.  It is this principle which dictated
   the positive/negative acknowledgement scheme.  The principle of
   symmetry merely states that neither party should have to 'know'
   whether it is the server or the user.  Our scheme, as described thus
   far, is not totally symmetrical we will consider this matter in a
   later section.

   The ECHOING scheme we have described, together with the principles
   stated above, form the heart of our comments on the TELNET protocol.
   The remainder of this note consists of further ways in which the
   protocol can be expanded on the whole, these suggestions are all
   really only applications and development of the principles we have
   already put forward.  However, the fecundity of these expansions, and
   the 'good feel' they have, make us yet more convinced of the '
   rightness' of our original proposals.





Cosell & Walden                                                 [Page 3]

RFC 435                      TELNET Issues                5 January 1973


   Thus far, we have made a simple, concrete suggestion that we believe
   should be immediately sanctioned.  Looking beyond that proposal,
   however, has suggestion a large number of further, more ambitious
   changes.  The remainder of this RFC describes ideas which we don't
   feel have the immediacy of the proposal above, but should,
   nonetheless, be kept in mind if the network community decides to
   embark on revamping the protocol.

Synchronization

   One complaint we have heard about the present convention for
   establishing an echoing mode is about the lack of a provision to
   synchronize a change of echoing mode with the user-to-server data
   stream our scheme, too, is guilty on this count.  John Davidson of
   the University of Hawaii has documented, in RFC 357, a more elaborate
   echoing scheme which doesn't have this problem.  We, however, feel
   that it is possible to eliminate most of the trouble involved with
   normal changing of echo mode at a more modest cost than that required
   by the highly interactive scheme described by Davidson.  We can do
   this by borrowing a small piece of that scheme.  The rule we would
   incorporate is that whenever a party initiates a request for a change
   in echo mode, it then buffers, without transmitting or processing,
   all data in the user-to-server data stream until it receives an
   acknowledgement, positive or negative, at which time it deals with
   the buffered data in the newly negotiated mode.  Since with both our
   proposed and the current schemes such a request is guaranteed to be
   acknowledgement, the buffering time is bounded.

   An important aspect of this technique of eliminating the
   synchronization problem is that it need not ever become part of the
   official protocol.  Since its operation is entirely internal to the
   server or user, each may independently weigh the value of elegance
   against the cost of the required code and buffer space.

Other options

   Abhay Bushan has suggested to us that whether the user and server
   operate line-at-a-time or character-at-a-time mode (see RFC 318)
   should also be a negotiated option.  Further, he suggested that
   whether the terminal follows the TELNET end-of-line convention or not
   should also be negotiated.  Thus, when a connection is opened, in
   addition to being set to NO ECHO mode, the terminal would also be set
   to LINE-AT-A-TIME and EOL modes.  We could augment the command space
   with the new commands LINE, NO LINE (=CHARACTER), EOL and NO EOL
   (=separate CR and LF).






Cosell & Walden                                                 [Page 4]

RFC 435                      TELNET Issues                5 January 1973


   Once started in this direction, we found several further
   applications.  HIDE YOUR INPUT could be made an option, as could
   Davidson's echoing scheme, and even the character set to be used!
   Consider that an APL subsystem might well want to suggest to its user
   that EBCDIC be used for the connection.

   In mentionaing that the character set could be negotiated, it was
   implicit that 7-bit USASCII was the default.  The possibility of
   having the default be straight binary suggests itself.  If we
   augmented the protocol with a QUOTE character, the byte after which
   were to be always interpreted as data, then codes 128-255 could be
   retained as the 'TELNET command space' independently of the data mode
   in use by merely prefixing all data bytes in this region with a
   QUOTE.  If BINARY were a permissible data mode, then it is easy to
   visualize many higher level protocols, e.g., perhaps, File Transfer
   and Graphics, being built on top of, and into, the TELNET protocol.
   What we would have accomplished is to promote TELNET from being a
   constrained, terminal-oriented protocol to its being a flexible,
   general protocol for any type of byte oriented communication.  With
   such a backbone, many of the higher level protocols could be designed
   and implemented more quickly and less painfully -- conditions which
   would undoubtedly hasten their universal acceptance and availability
   [3].

   Looking toward a better world of the future, we have come up with a
   more compact and flexible command scheme.  We'll describe it after
   the next section.

Symmetry

   Some of the TENEX group (in particular, Thomas, Burchfiel and
   Tomlinson) have pointed out to us that although we have made the
   rules for the protocol symmetrical, we have not made the meanings of
   the commands symmetrical.  For example, the interpretations of the
   ECHO command -- 'I'll echo to you' and 'You echo to me' -- implicitly
   assume that both the server and user know who is which.  This is a
   problem not only for server-server connections where it is not clear
   which is the user, but also for user-user connections, e.g., in
   linking Teletypes together, where it is not clear which is the
   server.

   Responding to this, we came to understand that there are only five
   reasonable modes of operation for the echoing on a connection pair
   [4]:







Cosell & Walden                                                 [Page 5]