rfc1143.txt

著名的RFC文档,其中有一些文档是已经翻译成中文的的.


RFC 1143                        Q Method                   February 1990


      proven to work.  Hence the above rule.

      A more restrictive solution would be to buffer all data and do
      absolutely nothing until the response comes back.  There is no
      apparent reason for this, though some existing TELNET
      implementations do so anyway at the beginning of a connection,
      when most options are negotiated.

5. How to reallow the request queue

   DISCUSSION:

      The above rule prevents queueing of more than one request through
      the network.  However, it is possible to queue new requests within
      the TELNET implementation, so that "option typeahead" is
      effectively restored.

      An obvious possibility is to maintain a list of requests that have
      been made but not yet sent, so that when one negotiation finishes,
      the next can be started immediately.  So while negotiating for a
      WILL, TELNET could buffer the user's requests for WONT, then WILL
      again, then WONT, then WILL, then WONT, as far as desired.

      This requires a dynamic and potentially unmanageable buffer.
      However, the restrictions upon possible requests guarantee that
      the list of requests must simply alternate between WONT and WILL.
      It is wasteful to enable an option and then disable it, just to
      enable it again; we might as well just enable it in the first
      place.  The few possible exceptions to this rule do not outweigh
      the immense simplification afforded by remembering only the last
      few entries on the queue.

      To be more precise, during a WILL negotiation, the only sensible
      queues are WONT and WONT WILL, and similarly during a WONT
      negotiation.  In the interest of simplicity, the Q method does not
      allow the WONT WILL possibility.

      We are now left with a queue consisting of either nothing or the
      opposite of the current negotiation.  When we receive a reply to
      the negotiation, if the queue indicates that the option should be
      changed, we send the opposite request immediately and empty the
      queue.  Note that this does not conflict with the RFC 854 rule
      about automatic regeneration of requests, as these new requests
      are simply the delayed effects of user or process commands.

   An implementation SHOULD support the queue, where support is defined
   by the rules following.




Bernstein                                                       [Page 6]

RFC 1143                        Q Method                   February 1990


   If it does support the queue, and if an option is currently under
   negotiation, it MUST NOT handle a new request from the user or
   process to switch the state of that option by sending a new request
   through the network.  Instead, it MUST remember internally that the
   new request was made.

   If the user or process makes a second new request, for switching back
   again, while the original negotiation is still incomplete, the
   implementation SHOULD handle the request simply by forgetting the
   previous one.  The third request SHOULD be treated like the first,
   etc.  In any case, these further requests MUST NOT generate immediate
   requests through the network.

   When the option negotiation completes, if the implementation is
   remembering a request internally, and that request is for the
   opposite state to the result of the completed negotiation, then the
   implementation MUST act as if that request had been made after the
   completion of the negotiation.  It SHOULD thus immediately generate a
   new request through the network.

   The implementation MAY provide a method by which support for the
   queue may be turned off and back on.  In this case, it MUST default
   to having the support turned on.  Furthermore, when support is turned
   off, if the implementation is remembering a new request for an
   outstanding negotiation, it SHOULD continue remembering and then deal
   with it at the close of the outstanding negotiation, as if support
   were still turned on through that point.

   DISCUSSION:

      It is intended (and it is the author's belief) that this queue
      system restores the full functionality of TELNET.  Dave Borman has
      provided some informal analysis of this issue [1]; the most
      important possible problem of note is that certain options which
      may require buffering could be slowed by the queue.  The author
      believes that network delays caused by buffering are independent
      of the implementation method used, and that the Q Method does not
      cause any problems; this is borne out by examples.

6. Rule: Separate WANTNO and WANTYES

   Implementations SHOULD separate any states of negotiating WILL/DO
   from any states of negotiating WONT/DONT.

   DISCUSSION:

      It is possible to maintain a working TELNET implementation if the
      NO/YES/WANTNO/WANTYES states are simplified to NO/YES/WANT.



Bernstein                                                       [Page 7]

RFC 1143                        Q Method                   February 1990


      However, in a hostile environment this is a bad idea, as it means
      that handling a DO/WILL response to a WONT/DONT cannot be done
      correctly.  It does not greatly simplify code; and the simplicity
      gained is lost in the extra complexity needed to maintain the
      queue.

7. Example of Correct Implementation

   To ease the task of writing TELNET implementations, the author
   presents here a precise example of the response that a compliant
   TELNET implementation could give in each possible situation.  All
   TELNET implementations compliant with this RFC SHOULD follow the
   procedures shown here.

   EXAMPLE STATE MACHINE
   FOR THE Q METHOD OF IMPLEMENTING TELNET OPTION NEGOTIATION

      There are two sides, we (us) and he (him).  We keep four
      variables:

         us: state of option on our side (NO/WANTNO/WANTYES/YES)
         usq: a queue bit (EMPTY/OPPOSITE) if us is WANTNO or WANTYES
         him: state of option on his side
         himq: a queue bit if him is WANTNO or WANTYES

      An option is enabled if and only if its state is YES.  Note that
      us/usq and him/himq could be combined into two six-choice states.

      "Error" below means that producing diagnostic information may be a
      good idea, though it isn't required.

      Upon receipt of WILL, we choose based upon him and himq:
         NO            If we agree that he should enable, him=YES, send
                       DO; otherwise, send DONT.
         YES           Ignore.
         WANTNO  EMPTY Error: DONT answered by WILL. him=NO.
              OPPOSITE Error: DONT answered by WILL. him=YES*,
                       himq=EMPTY.
         WANTYES EMPTY him=YES.
              OPPOSITE him=WANTNO, himq=EMPTY, send DONT.

      * This behavior is debatable; DONT will never be answered by WILL
        over a reliable connection between TELNETs compliant with this
        RFC, so this was chosen (1) not to generate further messages,
        because if we know we're dealing with a noncompliant TELNET we
        shouldn't trust it to be sensible; (2) to empty the queue
        sensibly.




Bernstein                                                       [Page 8]

RFC 1143                        Q Method                   February 1990


      Upon receipt of WONT, we choose based upon him and himq:
         NO            Ignore.
         YES           him=NO, send DONT.
         WANTNO  EMPTY him=NO.
              OPPOSITE him=WANTYES, himq=NONE, send DO.
         WANTYES EMPTY him=NO.*
              OPPOSITE him=NO, himq=NONE.**

      * Here is the only spot a length-two queue could be useful; after
        a WILL negotiation was refused, a queue of WONT WILL would mean
        to request the option again. This seems of too little utility
        and too much potential waste; there is little chance that the
        other side will change its mind immediately.

      ** Here we don't have to generate another request because we've
         been "refused into" the correct state anyway.

      If we decide to ask him to enable:
         NO            him=WANTYES, send DO.
         YES           Error: Already enabled.
         WANTNO  EMPTY If we are queueing requests, himq=OPPOSITE;
                       otherwise, Error: Cannot initiate new request
                       in the middle of negotiation.
              OPPOSITE Error: Already queued an enable request.
         WANTYES EMPTY Error: Already negotiating for enable.
              OPPOSITE himq=EMPTY.

      If we decide to ask him to disable:
         NO            Error: Already disabled.
         YES           him=WANTNO, send DONT.
         WANTNO  EMPTY Error: Already negotiating for disable.
              OPPOSITE himq=EMPTY.
         WANTYES EMPTY If we are queueing requests, himq=OPPOSITE;
                       otherwise, Error: Cannot initiate new request
                       in the middle of negotiation.
              OPPOSITE Error: Already queued a disable request.

      We handle the option on our side by the same procedures, with DO-
      WILL, DONT-WONT, him-us, himq-usq swapped.

8. References

   [1] Borman, D., private communication, April 1989.

   [2] Borman, D., private communication, May 1989.

   [3] Borman, D., private communication, May 1989.




Bernstein                                                       [Page 9]

RFC 1143                        Q Method                   February 1990


   [4] Borman, D., Editor, "Telnet Linemode Option", RFC 1116, Cray
       Research, August 1989.

   [5] Borman, D., BSD Telnet Source, November 1989.

   [6] Braden, R., Editor, "Requirements for Internet Hosts --
       Application and Support", RFC 1123, USC/Information Sciences
       Institute, October 1989.

   [7] Postel, J., and J. Reynolds, "Telnet Protocol Specification", RFC
       854, USC/Information Sciences Institute, May 1983.

9. Acknowledgments

   Thanks to Dave Borman, [e-mail], for his helpful comments.

Author's Address

   Daniel J. Bernstein
   5 Brewster Lane
   Bellport, NY 11713

   Phone:  [phone]

   Email:  [e-mail]


























Bernstein                                                      [Page 10]