rfc1143.txt

RFC 的详细文档！

Network Working Group                                       D. Bernstein
Request for Comments: 1143                                           NYU
                                                           February 1990


         The Q Method of Implementing TELNET Option Negotiation


Status of This Memo

   This is RFC discusses an implementation approach to option
   negotiation in the Telnet protocol (RFC 854).  It does not propose
   any changes to the TELNET protocol.  Rather, it discusses the
   implementation of the protocol of one feature, only.  This is not a
   protocol specification.  This is an experimental method of
   implementing a protocol.  This memo is not a recommendation of the
   Telnet Working Group of the Internet Engineering Task Force (IETF).
   This RFC is Copyright 1990, Daniel J. Bernstein.  However,
   distribution of this memo in original form is unlimited.

1. Introduction

   This RFC amplifies, supplements, and extends the RFC 854 [7] option
   negotiation rules and guidelines, which are insufficient to prevent
   all option negotiation loops.  This RFC also presents an example of
   correct implementation.

   DISCUSSION:

   The two items in this RFC of the most interest to implementors are
   1. the examples of option negotiation loops given below; and 2. the
   example of a TELNET state machine preventing loops.

      1. Implementors of TELNET should read the examples of option
         negotiation loops and beware that preventing such loops is a
         nontrivial task.

      2. Section 7 of this RFC shows by example a working method
         of avoiding loops.  It prescribes the state information that
         you must keep about each side of each option; it shows what
         to do in each state when you receive WILL/WONT/DO/DONT from
         the network, and when the user or process requests that an
         option be enabled or disabled.  An implementor who uses the
         procedures given in that example need not worry about
         compliance with this RFC or with a large chunk of RFC 854.

   In short, all implementors should be familiar with TELNET loops, and
   some implementors may wish to use the pre-written example here in



Bernstein                                                       [Page 1]

RFC 1143                        Q Method                   February 1990


   writing a new TELNET implementation.

   NOTE: Reading This Document

      A TELNET implementation is not compliant with this RFC if it fails
      to satisfy all rules marked MUST.  It is compliant if it satisfies
      all rules marked MUST.  If it is compliant, it is unconditionally
      compliant if it also satisfies all rules marked SHOULD and
      conditionally compliant otherwise.  Rules marked MAY are optional.

      Options are in almost all cases negotiated separately for each
      side of the connection.  The option on one side is separate from
      the option on the other side. In this document, "the" option
      referred to by a DONT/WONT or DO/WILL is really two options,
      combined only for semantic convenience.  Each sentence could be
      split into two, one with the words before the slash and one with
      the words after the slash.

      An implementor should be able to determine whether or not an
      implementation complies with this RFC without reading any text
      marked DISCUSSION.  An implementor should be able to implement
      option negotiation machinery compliant with both this RFC and RFC
      854 using just the information in Section 7.

2. RFC 854 Option Negotiation Requirements

   As specified by RFC 854: A TELNET implementation MUST obey a refusal
   to enable an option; i.e., if it receives a DONT/WONT in response to
   a WILL/DO, it MUST NOT enable the option.

   DISCUSSION:

      Where RFC 854 implies that the other side may reject a request to
      enable an option, it means that you must accept such a rejection.

   It MUST therefore remember that it is negotiating a WILL/DO, and this
   negotiation state MUST be separate from the enabled state and from
   the disabled state.  During the negotiation state, any effects of
   having the option enabled MUST NOT be used.

   If it receives WONT/DONT and the option is enabled, it MUST respond
   DONT/WONT repectively and disable the option.  It MUST NOT initiate a
   DO/WILL negotiation for an already enabled option or a DONT/WONT
   negotiation for a disabled option.  It MUST NOT respond to receipt of
   such a negotiation.  It MUST respond to receipt of a negotiation that
   does propose to change the status quo.





Bernstein                                                       [Page 2]

RFC 1143                        Q Method                   February 1990


   DISCUSSION:

      Many existing implementations respond to rejection by confirming
      the rejection; i.e., if they send WILL and receive DONT, they send
      WONT.  This has been construed as acceptable behavior under a
      certain (strained) interpretation of RFC 854.  However, to allow
      this possibility severely complicates later rules; there seems to
      be no use for the wasted bandwidth and processing.  Note that an
      implementation compliant with this RFC will simply ignore the
      extra WONT if the other side sends it.

   The implementation MUST NOT automatically respond to the rejection of
   a request by submitting a new request.  As a rule of thumb, new
   requests should be sent either at the beginning of a connection or in
   response to an external stimulus, i.e., input from the human user or
   from the process behind the server.

   A TELNET implementation MUST refuse (DONT/WONT) a request to enable
   an option for which it does not comply with the appropriate protocol
   specification.

   DISCUSSION:

      This is not stated as strongly in RFC 854.  However, any other
      action would be counterproductive.  This rule appears in
      Requirements for Internet Hosts [6, Section 3.2.2]; it appears
      here for completeness.

3. Rule: Remember DONT/WONT requests

   A TELNET implementation MUST remember starting a DONT/WONT
   negotiation.

   DISCUSSION:

      It is not clear from RFC 854 whether or not TELNET must remember
      beginning a DONT/WONT negotiation.  There seem to be no reasons to
      remember starting a DONT/WONT negotiation: 1. The argument for
      remembering a DO/WILL negotiation (viz., the state of negotiating
      for enabling means different things for the data stream than the
      state of having the option enabled) does not apply.  2. There is
      no choice for the other side in responding to a DONT/WONT; the
      option is going to end up disabled.  3. If we simply disable the
      option immediately and forget negotiating, we will ignore the
      WONT/DONT response since the option is disabled.

      Unfortunately, that conclusion is wrong.  Consider the following
      TELNET conversation between two parties, "us" and "him".  (The



Bernstein                                                       [Page 3]

RFC 1143                        Q Method                   February 1990


      reader of this RFC may want to sort the steps into chronological
      order for a different view.)

      LOOP EXAMPLE 1

         Both sides know that the option is on.

         On his side:
       1 He decides to disable.  He sends DONT and disables the option.
       2 He decides to reenable.  He sends DO and remembers he is
         negotiating.
       5 He receives WONT and gives up on negotiation.
       6 He decides to try once again to reenable.  He sends DO and
         remembers he is negotiating.
       7 He receives WONT and gives up on negotiation.
         For whatever reason, he decides to agree with future requests.
      10 He receives WILL and agrees. He responds DO and enables the
         option.
      11 He receives WONT and sighs. He responds DONT and disables the
         option.
         (repeat 10 and then 11, forever)

         On our side:
       3 We receive DONT and sigh.  We respond WONT and disable the
         option.
       4 We receive DO but disagree.  We respond WONT.
       8 We receive DO and decide to agree.  We respond WILL and enable
         the option.
       9 We decide to disable.  We send WONT and disable the option.
         For whatever reason, we decide to agree with future requests.
      12 We receive DO and agree.  We send WILL and enable the option.
      13 We receive DONT and sigh.  We send WONT and disable the option.
         (repeat 12 and then 13, forever)

      Both sides have followed RFC 854; but we end in an option
      negotiation loop, as DONT DO DO and then DO DONT forever travel
      through the network one way, and WONT WONT followed by WILL WONT
      forever travel through the network the other way.  The behavior in
      steps 1 and 9 is responsible for this loop.  Hence this section's
      rule.  In Section 6 below is discussion of whether separate states
      are needed for "negotiate for disable" and "negotiate for enable"
      or whether a single "negotiate" state suffices.

4. Rule: Prohibit new requests before completing old negotiation

   A TELNET implementation MUST NOT initiate a new WILL/WONT/DO/DONT
   request about an option that is under negotiation, i.e., for which it
   has already made such a request and not yet received a response.



Bernstein                                                       [Page 4]

RFC 1143                        Q Method                   February 1990


   DISCUSSION:

      It is unclear from RFC 854 whether or not a TELNET implementation
      may allow new requests about an option that is currently under
      negotiation; it certainly seems limiting to prohibit "option
      typeahead".  Unfortunately, consider the following:

      LOOP EXAMPLE 2

         Suppose an option is disabled, and we decide in quick
         succession to enable it, disable it, and reenable it.  We send
         WILL WONT WILL and at the end remember that we are negotiating.
         The other side agrees with DO DONT DO. We receive the first DO,
         enable the option, and forget we have negotiated.  Now DONT DO
         are coming through the network and both sides have forgotten
         they are negotiating; consequently we loop.

      (All possible TELNET loops eventually degenerate into the same
      form, where WILL WONT [or WONT WILL, or WILL WONT WILL WONT, etc.]
      go through the network while both sides think negotiation is over;
      the response is DO DONT and we loop forever.  TELNET implementors
      are encouraged to implement any option that can detect such a loop
      and cut it off; e.g., a method of explicitly differentiating
      requests from acknowledgments would be sufficient.  No such option
      exists as of February 1990.)

      This particular case is of considerable practical importance: most
      combinations of existing user-server TELNET implementations do
      enter an infinite loop when asked quickly a few times to enable
      and then disable an option.  This has taken on an even greater
      importance with the advent of LINEMODE [4], because LINEMODE is
      the first option that tends to generate such rapidly changing
      requests in the normal course of communication.  It is clear that
      a new rule is needed.

      One might try to prevent the several-alternating-requests problem
      by maintaining a more elaborate state than YES/NO/WANTwhatever,
      e.g., a state that records all outstanding requests.  Dave Borman
      has proposed an apparently working scheme [2] that won't blow up
      if both sides initiate several requests at once, and that seems to
      prevent option negotiation loops; complete analysis of his
      solution is somewhat difficult since it means that TELNET can no
      longer be a finite-state automaton.  He has implemented his
      solution in the latest BSD telnet version [5]; as of May 1989, he
      does not intend to publish it for others to use [3].

      Here the author decided to preserve TELNET's finite-state
      property, for robustness and because the result can be easily



Bernstein                                                       [Page 5]