rfc435.txt

RFC 的详细文档！


RFC 435                      TELNET Issues                5 January 1973


                         <------------------<
   A          Process 1                        Process 2
                         >------------------>
                         neither end echoes


                         <------------------<
   B          Process 1  <--+                  Process 2
                            ^
                         >--^--------------->
                        one end echoes for itself


                         <------------------<
   C          Process 1  <--------------+     Process 2
                                        ^
                         >--------------^--->
                        one end echoes for the other


                         <--------------V---<
   D          Process 1  <--+           V       Process 2
                            ^           +--->
                         >--^--------------->
                        both ends echo for themselves


                         <-----V------------<
   E          Process 1  <--+  V               Process 2
                            ^  +------------>
                         >--^--------------->
                        one end echoes for both ends

   The TENEX group suggested to us that four commands are sufficient to
   deal with completely symmetric echoing.  We have actually already
   mentioned the four commands -- the two possible meanings for each of
   ECHO and NO ECHO.  Explicitly, the commands would be I'LL ECHO TO
   YOU, YOU ECHO TO ME, DON'T ECHO TO ME and I'LL NOT ECHO TO YOU.
   Echoing is now the negotiation of two options, and the initial,
   default modes are DON'T ECHO TO ME and I'LL NOT ECHO TO YOU.

   In the case where the server or user knows which he is, the
   modification to the scheme is minimal since the commands never had
   ambiguous meanings in these cases.  When an 'end' truly doesn't know,
   then things are a little more complicated -- for example, consider
   both ends in I'LL ECHO TO YOU mode, but even then the problems are
   not insurmountable.




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


   Once the principle of symmetry is adopted, it is no longer possible
   to use a function in two different ways.  On pages 5 and 6 of RFC
   318, Postel gives a description of INS and SYNC which indicates that
   they are used to simulate a 'break' user-to-server, but flush the
   output buffers server-to-user.  Since we do believe in symmetry, we
   suggest that the INS/DATA-MARK be treated the same in both directions
   and that a new CLEAR YOUR BUFFER option be added.

Command Format

   Extending full symmetry through the other options we have suggested,
   we can now describes the compacted command format referred to
   earlier.

   Rather than having four commands for each option (I WILL, I WON'T,
   YOU DO, YOU DON'T), there would be four 'prefixes' -- WILL, WON'T,
   DO, DON'T -- which would be used before the single command devoted to
   each option, WON'T and DON'T being the default modes.  To give an
   example, assume the codes for WILL and WON'T are 140 and 141, and the
   codes for ECHO REMOTE and HIDE INPUT are 132 and 133.  Then several
   of the possible command combinations would be:

                   140 133 -- DO HIDE INPUT
                   140 132 -- DO ECHO REMOTE
                   141 132 -- WON'T ECHO REMOTE
                   141 133 -- WON'T HIDE INPUT

   These are some of the commands that we believe should exist:

   I WILL (140)
   I WILL NOT (141)
   YOU DO (142)
   YOU DO NOT (143)
   QUOTE (144)
   SYNC (163)
   SYNC REPLY (164)

   ECHO REMOTE (132)
   SEND A CHARACTER-AT-A-TIME (146)
   SEND INDEPENDENT CR and LF (147)
   SEND IN EBCDIC (162)
   HIDE INPUT (133)
   USE DAVIDSON'S ECHOING STRATEGY (145)

   An important virtue of this command structure, and of our entire
   viewpoint, is that Hosts need no longer even be aware of what all the
   options are.  If we call the mode of operation in which every
   alternative is in its default state the 'NVT', then a site, of



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


   course, must handle an NVT, but beyond that if it merely responds no
   to any command it does not understand, then it can totally ignore
   options it chooses not to implement.  Thus, options would truly be
   optional (for a change), not only to the user who may choose not to
   invoke them, but also to the systems builders who may now choose not
   to offer them!

   We hereby volunteer to rigorously specify a version of TELNET which
   embodies the principles we have described and to do so at any level
   of complexity deemed sufficient by the network community.









































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


Appendix: A Sample Implementation

   The basis scheme we described represents most of what we have been
   thinking about the further extensions are just that, extensions.  We
   fear, however, that some who are spiritually in league with us might
   be frightened off by the magnitude of all the changes we suggest.  To
   combat this, we here provide an example of how simply and straight-
   forwardly the basis scheme could be implemented for the TIP [5].

   For each user terminal the TIP would keep three state bits: whether
   the terminal echoes for itself (NO ECHO always) or not (ECHO mode
   possible), whether the (human) user prefers to operate in ECHO or NO
   ECHO mode, and whether the connection to this terminal is in ECHO or
   NO ECHO mode.  We call these three bits P(hysical), D(esired) and
   A(ctual).

   When a terminal dials up the TIP, the P-bit is set appropriately, the
   D-bit is set equal to it, and the A-bit is set to NO ECHO.  The P-
   and A-bits may be manually reset by direct commands if the user so
   desires for instance, a user in Hawaii on a 'full-duplex' terminal
   might know that whatever the preference of a mainland server, because
   of satellite delay his terminal had better operate in NO ECHO mode --
   he would direct the TIP to change his D-bit from ECHO to NO ECHO.

   When a connection is opened from the TIP terminal to a server, the
   TIP would send the server an ECHO command if the MIN (with NO ECHO
   less than ECHO) of the P- and D-bits is different from the A-bit.  If
   a NO ECHO or ECHO arrives from the server, the TIP will set the A-bit
   to the MIN of the received request, the P-bit and D-bit.  If this
   changes the state of the A-bit, it will send off the appropriate
   acknowledgement if it does not, then the TIP 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 TIP
   terminal user changes either the P- or D-bit, the TIP will repeat the
   above tests and send off an ECHO or NO ECHO, if necessary.  When the
   connection is closed, the TIP would reset the A-bit to NO ECHO.

   While the TIP's implementation would not involve ECHO or NO ECHO
   commands being sent to the server except when the connection is
   opened or the user explicitly changes his echoing mode, we would
   suppose that bigger Hosts might send these commands quite frequently.
   For instance, if a JOSS subsystem were running, the server might put
   the user in NO ECHO mode, but while DDT was running, the server might
   put the user in ECHO mode.






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


   [1] We have assumed that TELNET is defined as suggested by Jon Postel
   in RFC 318.

   [2] Notice that a faulty implementation could achieve the effect of a
   loop by repeatedly sending a command which has previously been
   refused.  We consider this a property of the implementation, not of
   the scheme in general, a command which has be rejected should not be
   repeated until something changes -- for instance, not until after a
   different program has been started up.

   [3] Will Crowther, with an eye towards building higher protocols upon
   TELNET, has suggested that a SYNC command (not to be confused with
   the existing SYNCH), and a SYNC REPLY be added to TELNET.  For
   example, a server might want to wait until the output buffer of a
   user's terminal were empty before doing something like closing the
   connection or passing the connection to another server.  Although we
   see no current use for the command pair, they seem to be a handy
   enough building block that we recommend that they be included.

   [4] It is perhaps appropriate to mention that most of the connections
   in the network are TELNET connections, which are full duplex.
   Wouldn't it be reasonable to make all Host/Host protocol connections
   full duplex, rather than simplex? If, for some reason, one truly
   needs a simplex connection, the reverse direction can always just be
   ignored.

   [5] Readers unfamiliar with the TIP may read the TIP Users Guide --
   NIC 10916.











        [This RFC was put into machine readable form for entry]
    [into the online RFC archives by Helene Morin, Via Genie, 12/99]










Cosell & Walden                                                [Page 10]