home *** CD-ROM | disk | FTP | other *** search
/ Unix System Administration Handbook 1997 October / usah_oct97.iso / rfc / 1100s / rfc1143.txt < prev    next >
Text File  |  1990-02-28  |  23KB  |  563 lines
  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7. Network Working Group                                       D. Bernstein
  8. Request for Comments: 1143                                           NYU
  9.                                                            February 1990
  10.  
  11.  
  12.          The Q Method of Implementing TELNET Option Negotiation
  13.  
  14.  
  15. Status of This Memo
  16.  
  17.    This is RFC discusses an implementation approach to option
  18.    negotiation in the Telnet protocol (RFC 854).  It does not propose
  19.    any changes to the TELNET protocol.  Rather, it discusses the
  20.    implementation of the protocol of one feature, only.  This is not a
  21.    protocol specification.  This is an experimental method of
  22.    implementing a protocol.  This memo is not a recommendation of the
  23.    Telnet Working Group of the Internet Engineering Task Force (IETF).
  24.    This RFC is Copyright 1990, Daniel J. Bernstein.  However,
  25.    distribution of this memo in original form is unlimited.
  26.  
  27. 1. Introduction
  28.  
  29.    This RFC amplifies, supplements, and extends the RFC 854 [7] option
  30.    negotiation rules and guidelines, which are insufficient to prevent
  31.    all option negotiation loops.  This RFC also presents an example of
  32.    correct implementation.
  33.  
  34.    DISCUSSION:
  35.  
  36.    The two items in this RFC of the most interest to implementors are
  37.    1. the examples of option negotiation loops given below; and 2. the
  38.    example of a TELNET state machine preventing loops.
  39.  
  40.       1. Implementors of TELNET should read the examples of option
  41.          negotiation loops and beware that preventing such loops is a
  42.          nontrivial task.
  43.  
  44.       2. Section 7 of this RFC shows by example a working method
  45.          of avoiding loops.  It prescribes the state information that
  46.          you must keep about each side of each option; it shows what
  47.          to do in each state when you receive WILL/WONT/DO/DONT from
  48.          the network, and when the user or process requests that an
  49.          option be enabled or disabled.  An implementor who uses the
  50.          procedures given in that example need not worry about
  51.          compliance with this RFC or with a large chunk of RFC 854.
  52.  
  53.    In short, all implementors should be familiar with TELNET loops, and
  54.    some implementors may wish to use the pre-written example here in
  55.  
  56.  
  57.  
  58. Bernstein                                                       [Page 1]
  59.  
  60. RFC 1143                        Q Method                   February 1990
  61.  
  62.  
  63.    writing a new TELNET implementation.
  64.  
  65.    NOTE: Reading This Document
  66.  
  67.       A TELNET implementation is not compliant with this RFC if it fails
  68.       to satisfy all rules marked MUST.  It is compliant if it satisfies
  69.       all rules marked MUST.  If it is compliant, it is unconditionally
  70.       compliant if it also satisfies all rules marked SHOULD and
  71.       conditionally compliant otherwise.  Rules marked MAY are optional.
  72.  
  73.       Options are in almost all cases negotiated separately for each
  74.       side of the connection.  The option on one side is separate from
  75.       the option on the other side. In this document, "the" option
  76.       referred to by a DONT/WONT or DO/WILL is really two options,
  77.       combined only for semantic convenience.  Each sentence could be
  78.       split into two, one with the words before the slash and one with
  79.       the words after the slash.
  80.  
  81.       An implementor should be able to determine whether or not an
  82.       implementation complies with this RFC without reading any text
  83.       marked DISCUSSION.  An implementor should be able to implement
  84.       option negotiation machinery compliant with both this RFC and RFC
  85.       854 using just the information in Section 7.
  86.  
  87. 2. RFC 854 Option Negotiation Requirements
  88.  
  89.    As specified by RFC 854: A TELNET implementation MUST obey a refusal
  90.    to enable an option; i.e., if it receives a DONT/WONT in response to
  91.    a WILL/DO, it MUST NOT enable the option.
  92.  
  93.    DISCUSSION:
  94.  
  95.       Where RFC 854 implies that the other side may reject a request to
  96.       enable an option, it means that you must accept such a rejection.
  97.  
  98.    It MUST therefore remember that it is negotiating a WILL/DO, and this
  99.    negotiation state MUST be separate from the enabled state and from
  100.    the disabled state.  During the negotiation state, any effects of
  101.    having the option enabled MUST NOT be used.
  102.  
  103.    If it receives WONT/DONT and the option is enabled, it MUST respond
  104.    DONT/WONT repectively and disable the option.  It MUST NOT initiate a
  105.    DO/WILL negotiation for an already enabled option or a DONT/WONT
  106.    negotiation for a disabled option.  It MUST NOT respond to receipt of
  107.    such a negotiation.  It MUST respond to receipt of a negotiation that
  108.    does propose to change the status quo.
  109.  
  110.  
  111.  
  112.  
  113.  
  114. Bernstein                                                       [Page 2]
  115.  
  116. RFC 1143                        Q Method                   February 1990
  117.  
  118.  
  119.    DISCUSSION:
  120.  
  121.       Many existing implementations respond to rejection by confirming
  122.       the rejection; i.e., if they send WILL and receive DONT, they send
  123.       WONT.  This has been construed as acceptable behavior under a
  124.       certain (strained) interpretation of RFC 854.  However, to allow
  125.       this possibility severely complicates later rules; there seems to
  126.       be no use for the wasted bandwidth and processing.  Note that an
  127.       implementation compliant with this RFC will simply ignore the
  128.       extra WONT if the other side sends it.
  129.  
  130.    The implementation MUST NOT automatically respond to the rejection of
  131.    a request by submitting a new request.  As a rule of thumb, new
  132.    requests should be sent either at the beginning of a connection or in
  133.    response to an external stimulus, i.e., input from the human user or
  134.    from the process behind the server.
  135.  
  136.    A TELNET implementation MUST refuse (DONT/WONT) a request to enable
  137.    an option for which it does not comply with the appropriate protocol
  138.    specification.
  139.  
  140.    DISCUSSION:
  141.  
  142.       This is not stated as strongly in RFC 854.  However, any other
  143.       action would be counterproductive.  This rule appears in
  144.       Requirements for Internet Hosts [6, Section 3.2.2]; it appears
  145.       here for completeness.
  146.  
  147. 3. Rule: Remember DONT/WONT requests
  148.  
  149.    A TELNET implementation MUST remember starting a DONT/WONT
  150.    negotiation.
  151.  
  152.    DISCUSSION:
  153.  
  154.       It is not clear from RFC 854 whether or not TELNET must remember
  155.       beginning a DONT/WONT negotiation.  There seem to be no reasons to
  156.       remember starting a DONT/WONT negotiation: 1. The argument for
  157.       remembering a DO/WILL negotiation (viz., the state of negotiating
  158.       for enabling means different things for the data stream than the
  159.       state of having the option enabled) does not apply.  2. There is
  160.       no choice for the other side in responding to a DONT/WONT; the
  161.       option is going to end up disabled.  3. If we simply disable the
  162.       option immediately and forget negotiating, we will ignore the
  163.       WONT/DONT response since the option is disabled.
  164.  
  165.       Unfortunately, that conclusion is wrong.  Consider the following
  166.       TELNET conversation between two parties, "us" and "him".  (The
  167.  
  168.  
  169.  
  170. Bernstein                                                       [Page 3]
  171.  
  172. RFC 1143                        Q Method                   February 1990
  173.  
  174.  
  175.       reader of this RFC may want to sort the steps into chronological
  176.       order for a different view.)
  177.  
  178.       LOOP EXAMPLE 1
  179.  
  180.          Both sides know that the option is on.
  181.  
  182.          On his side:
  183.        1 He decides to disable.  He sends DONT and disables the option.
  184.        2 He decides to reenable.  He sends DO and remembers he is
  185.          negotiating.
  186.        5 He receives WONT and gives up on negotiation.
  187.        6 He decides to try once again to reenable.  He sends DO and
  188.          remembers he is negotiating.
  189.        7 He receives WONT and gives up on negotiation.
  190.          For whatever reason, he decides to agree with future requests.
  191.       10 He receives WILL and agrees. He responds DO and enables the
  192.          option.
  193.       11 He receives WONT and sighs. He responds DONT and disables the
  194.          option.
  195.          (repeat 10 and then 11, forever)
  196.  
  197.          On our side:
  198.        3 We receive DONT and sigh.  We respond WONT and disable the
  199.          option.
  200.        4 We receive DO but disagree.  We respond WONT.
  201.        8 We receive DO and decide to agree.  We respond WILL and enable
  202.          the option.
  203.        9 We decide to disable.  We send WONT and disable the option.
  204.          For whatever reason, we decide to agree with future requests.
  205.       12 We receive DO and agree.  We send WILL and enable the option.
  206.       13 We receive DONT and sigh.  We send WONT and disable the option.
  207.          (repeat 12 and then 13, forever)
  208.  
  209.       Both sides have followed RFC 854; but we end in an option
  210.       negotiation loop, as DONT DO DO and then DO DONT forever travel
  211.       through the network one way, and WONT WONT followed by WILL WONT
  212.       forever travel through the network the other way.  The behavior in
  213.       steps 1 and 9 is responsible for this loop.  Hence this section's
  214.       rule.  In Section 6 below is discussion of whether separate states
  215.       are needed for "negotiate for disable" and "negotiate for enable"
  216.       or whether a single "negotiate" state suffices.
  217.  
  218. 4. Rule: Prohibit new requests before completing old negotiation
  219.  
  220.    A TELNET implementation MUST NOT initiate a new WILL/WONT/DO/DONT
  221.    request about an option that is under negotiation, i.e., for which it
  222.    has already made such a request and not yet received a response.
  223.  
  224.  
  225.  
  226. Bernstein                                                       [Page 4]
  227.  
  228. RFC 1143                        Q Method                   February 1990
  229.  
  230.  
  231.    DISCUSSION:
  232.  
  233.       It is unclear from RFC 854 whether or not a TELNET implementation
  234.       may allow new requests about an option that is currently under
  235.       negotiation; it certainly seems limiting to prohibit "option
  236.       typeahead".  Unfortunately, consider the following:
  237.  
  238.       LOOP EXAMPLE 2
  239.  
  240.          Suppose an option is disabled, and we decide in quick
  241.          succession to enable it, disable it, and reenable it.  We send
  242.          WILL WONT WILL and at the end remember that we are negotiating.
  243.          The other side agrees with DO DONT DO. We receive the first DO,
  244.          enable the option, and forget we have negotiated.  Now DONT DO
  245.          are coming through the network and both sides have forgotten
  246.          they are negotiating; consequently we loop.
  247.  
  248.       (All possible TELNET loops eventually degenerate into the same
  249.       form, where WILL WONT [or WONT WILL, or WILL WONT WILL WONT, etc.]
  250.       go through the network while both sides think negotiation is over;
  251.       the response is DO DONT and we loop forever.  TELNET implementors
  252.       are encouraged to implement any option that can detect such a loop
  253.       and cut it off; e.g., a method of explicitly differentiating
  254.       requests from acknowledgments would be sufficient.  No such option
  255.       exists as of February 1990.)
  256.  
  257.       This particular case is of considerable practical importance: most
  258.       combinations of existing user-server TELNET implementations do
  259.       enter an infinite loop when asked quickly a few times to enable
  260.       and then disable an option.  This has taken on an even greater
  261.       importance with the advent of LINEMODE [4], because LINEMODE is
  262.       the first option that tends to generate such rapidly changing
  263.       requests in the normal course of communication.  It is clear that
  264.       a new rule is needed.
  265.  
  266.       One might try to prevent the several-alternating-requests problem
  267.       by maintaining a more elaborate state than YES/NO/WANTwhatever,
  268.       e.g., a state that records all outstanding requests.  Dave Borman
  269.       has proposed an apparently working scheme [2] that won't blow up
  270.       if both sides initiate several requests at once, and that seems to
  271.       prevent option negotiation loops; complete analysis of his
  272.       solution is somewhat difficult since it means that TELNET can no
  273.       longer be a finite-state automaton.  He has implemented his
  274.       solution in the latest BSD telnet version [5]; as of May 1989, he
  275.       does not intend to publish it for others to use [3].
  276.  
  277.       Here the author decided to preserve TELNET's finite-state
  278.       property, for robustness and because the result can be easily
  279.  
  280.  
  281.  
  282. Bernstein                                                       [Page 5]
  283.  
  284. RFC 1143                        Q Method                   February 1990
  285.  
  286.  
  287.       proven to work.  Hence the above rule.
  288.  
  289.       A more restrictive solution would be to buffer all data and do
  290.       absolutely nothing until the response comes back.  There is no
  291.       apparent reason for this, though some existing TELNET
  292.       implementations do so anyway at the beginning of a connection,
  293.       when most options are negotiated.
  294.  
  295. 5. How to reallow the request queue
  296.  
  297.    DISCUSSION:
  298.  
  299.       The above rule prevents queueing of more than one request through
  300.       the network.  However, it is possible to queue new requests within
  301.       the TELNET implementation, so that "option typeahead" is
  302.       effectively restored.
  303.  
  304.       An obvious possibility is to maintain a list of requests that have
  305.       been made but not yet sent, so that when one negotiation finishes,
  306.       the next can be started immediately.  So while negotiating for a
  307.       WILL, TELNET could buffer the user's requests for WONT, then WILL
  308.       again, then WONT, then WILL, then WONT, as far as desired.
  309.  
  310.       This requires a dynamic and potentially unmanageable buffer.
  311.       However, the restrictions upon possible requests guarantee that
  312.       the list of requests must simply alternate between WONT and WILL.
  313.       It is wasteful to enable an option and then disable it, just to
  314.       enable it again; we might as well just enable it in the first
  315.       place.  The few possible exceptions to this rule do not outweigh
  316.       the immense simplification afforded by remembering only the last
  317.       few entries on the queue.
  318.  
  319.       To be more precise, during a WILL negotiation, the only sensible
  320.       queues are WONT and WONT WILL, and similarly during a WONT
  321.       negotiation.  In the interest of simplicity, the Q method does not
  322.       allow the WONT WILL possibility.
  323.  
  324.       We are now left with a queue consisting of either nothing or the
  325.       opposite of the current negotiation.  When we receive a reply to
  326.       the negotiation, if the queue indicates that the option should be
  327.       changed, we send the opposite request immediately and empty the
  328.       queue.  Note that this does not conflict with the RFC 854 rule
  329.       about automatic regeneration of requests, as these new requests
  330.       are simply the delayed effects of user or process commands.
  331.  
  332.    An implementation SHOULD support the queue, where support is defined
  333.    by the rules following.
  334.  
  335.  
  336.  
  337.  
  338. Bernstein                                                       [Page 6]
  339.  
  340. RFC 1143                        Q Method                   February 1990
  341.  
  342.  
  343.    If it does support the queue, and if an option is currently under
  344.    negotiation, it MUST NOT handle a new request from the user or
  345.    process to switch the state of that option by sending a new request
  346.    through the network.  Instead, it MUST remember internally that the
  347.    new request was made.
  348.  
  349.    If the user or process makes a second new request, for switching back
  350.    again, while the original negotiation is still incomplete, the
  351.    implementation SHOULD handle the request simply by forgetting the
  352.    previous one.  The third request SHOULD be treated like the first,
  353.    etc.  In any case, these further requests MUST NOT generate immediate
  354.    requests through the network.
  355.  
  356.    When the option negotiation completes, if the implementation is
  357.    remembering a request internally, and that request is for the
  358.    opposite state to the result of the completed negotiation, then the
  359.    implementation MUST act as if that request had been made after the
  360.    completion of the negotiation.  It SHOULD thus immediately generate a
  361.    new request through the network.
  362.  
  363.    The implementation MAY provide a method by which support for the
  364.    queue may be turned off and back on.  In this case, it MUST default
  365.    to having the support turned on.  Furthermore, when support is turned
  366.    off, if the implementation is remembering a new request for an
  367.    outstanding negotiation, it SHOULD continue remembering and then deal
  368.    with it at the close of the outstanding negotiation, as if support
  369.    were still turned on through that point.
  370.  
  371.    DISCUSSION:
  372.  
  373.       It is intended (and it is the author's belief) that this queue
  374.       system restores the full functionality of TELNET.  Dave Borman has
  375.       provided some informal analysis of this issue [1]; the most
  376.       important possible problem of note is that certain options which
  377.       may require buffering could be slowed by the queue.  The author
  378.       believes that network delays caused by buffering are independent
  379.       of the implementation method used, and that the Q Method does not
  380.       cause any problems; this is borne out by examples.
  381.  
  382. 6. Rule: Separate WANTNO and WANTYES
  383.  
  384.    Implementations SHOULD separate any states of negotiating WILL/DO
  385.    from any states of negotiating WONT/DONT.
  386.  
  387.    DISCUSSION:
  388.  
  389.       It is possible to maintain a working TELNET implementation if the
  390.       NO/YES/WANTNO/WANTYES states are simplified to NO/YES/WANT.
  391.  
  392.  
  393.  
  394. Bernstein                                                       [Page 7]
  395.  
  396. RFC 1143                        Q Method                   February 1990
  397.  
  398.  
  399.       However, in a hostile environment this is a bad idea, as it means
  400.       that handling a DO/WILL response to a WONT/DONT cannot be done
  401.       correctly.  It does not greatly simplify code; and the simplicity
  402.       gained is lost in the extra complexity needed to maintain the
  403.       queue.
  404.  
  405. 7. Example of Correct Implementation
  406.  
  407.    To ease the task of writing TELNET implementations, the author
  408.    presents here a precise example of the response that a compliant
  409.    TELNET implementation could give in each possible situation.  All
  410.    TELNET implementations compliant with this RFC SHOULD follow the
  411.    procedures shown here.
  412.  
  413.    EXAMPLE STATE MACHINE
  414.    FOR THE Q METHOD OF IMPLEMENTING TELNET OPTION NEGOTIATION
  415.  
  416.       There are two sides, we (us) and he (him).  We keep four
  417.       variables:
  418.  
  419.          us: state of option on our side (NO/WANTNO/WANTYES/YES)
  420.          usq: a queue bit (EMPTY/OPPOSITE) if us is WANTNO or WANTYES
  421.          him: state of option on his side
  422.          himq: a queue bit if him is WANTNO or WANTYES
  423.  
  424.       An option is enabled if and only if its state is YES.  Note that
  425.       us/usq and him/himq could be combined into two six-choice states.
  426.  
  427.       "Error" below means that producing diagnostic information may be a
  428.       good idea, though it isn't required.
  429.  
  430.       Upon receipt of WILL, we choose based upon him and himq:
  431.          NO            If we agree that he should enable, him=YES, send
  432.                        DO; otherwise, send DONT.
  433.          YES           Ignore.
  434.          WANTNO  EMPTY Error: DONT answered by WILL. him=NO.
  435.               OPPOSITE Error: DONT answered by WILL. him=YES*,
  436.                        himq=EMPTY.
  437.          WANTYES EMPTY him=YES.
  438.               OPPOSITE him=WANTNO, himq=EMPTY, send DONT.
  439.  
  440.       * This behavior is debatable; DONT will never be answered by WILL
  441.         over a reliable connection between TELNETs compliant with this
  442.         RFC, so this was chosen (1) not to generate further messages,
  443.         because if we know we're dealing with a noncompliant TELNET we
  444.         shouldn't trust it to be sensible; (2) to empty the queue
  445.         sensibly.
  446.  
  447.  
  448.  
  449.  
  450. Bernstein                                                       [Page 8]
  451.  
  452. RFC 1143                        Q Method                   February 1990
  453.  
  454.  
  455.       Upon receipt of WONT, we choose based upon him and himq:
  456.          NO            Ignore.
  457.          YES           him=NO, send DONT.
  458.          WANTNO  EMPTY him=NO.
  459.               OPPOSITE him=WANTYES, himq=NONE, send DO.
  460.          WANTYES EMPTY him=NO.*
  461.               OPPOSITE him=NO, himq=NONE.**
  462.  
  463.       * Here is the only spot a length-two queue could be useful; after
  464.         a WILL negotiation was refused, a queue of WONT WILL would mean
  465.         to request the option again. This seems of too little utility
  466.         and too much potential waste; there is little chance that the
  467.         other side will change its mind immediately.
  468.  
  469.       ** Here we don't have to generate another request because we've
  470.          been "refused into" the correct state anyway.
  471.  
  472.       If we decide to ask him to enable:
  473.          NO            him=WANTYES, send DO.
  474.          YES           Error: Already enabled.
  475.          WANTNO  EMPTY If we are queueing requests, himq=OPPOSITE;
  476.                        otherwise, Error: Cannot initiate new request
  477.                        in the middle of negotiation.
  478.               OPPOSITE Error: Already queued an enable request.
  479.          WANTYES EMPTY Error: Already negotiating for enable.
  480.               OPPOSITE himq=EMPTY.
  481.  
  482.       If we decide to ask him to disable:
  483.          NO            Error: Already disabled.
  484.          YES           him=WANTNO, send DONT.
  485.          WANTNO  EMPTY Error: Already negotiating for disable.
  486.               OPPOSITE himq=EMPTY.
  487.          WANTYES EMPTY If we are queueing requests, himq=OPPOSITE;
  488.                        otherwise, Error: Cannot initiate new request
  489.                        in the middle of negotiation.
  490.               OPPOSITE Error: Already queued a disable request.
  491.  
  492.       We handle the option on our side by the same procedures, with DO-
  493.       WILL, DONT-WONT, him-us, himq-usq swapped.
  494.  
  495. 8. References
  496.  
  497.    [1] Borman, D., private communication, April 1989.
  498.  
  499.    [2] Borman, D., private communication, May 1989.
  500.  
  501.    [3] Borman, D., private communication, May 1989.
  502.  
  503.  
  504.  
  505.  
  506. Bernstein                                                       [Page 9]
  507.  
  508. RFC 1143                        Q Method                   February 1990
  509.  
  510.  
  511.    [4] Borman, D., Editor, "Telnet Linemode Option", RFC 1116, Cray
  512.        Research, August 1989.
  513.  
  514.    [5] Borman, D., BSD Telnet Source, November 1989.
  515.  
  516.    [6] Braden, R., Editor, "Requirements for Internet Hosts --
  517.        Application and Support", RFC 1123, USC/Information Sciences
  518.        Institute, October 1989.
  519.  
  520.    [7] Postel, J., and J. Reynolds, "Telnet Protocol Specification", RFC
  521.        854, USC/Information Sciences Institute, May 1983.
  522.  
  523. 9. Acknowledgments
  524.  
  525.    Thanks to Dave Borman, dab@opus.cray.com, for his helpful comments.
  526.  
  527. Author's Address
  528.  
  529.    Daniel J. Bernstein
  530.    5 Brewster Lane
  531.    Bellport, NY 11713
  532.  
  533.    Phone:  516-286-1339
  534.  
  535.    Email:  brnstnd@acf10.nyu.edu
  536.  
  537.  
  538.  
  539.  
  540.  
  541.  
  542.  
  543.  
  544.  
  545.  
  546.  
  547.  
  548.  
  549.  
  550.  
  551.  
  552.  
  553.  
  554.  
  555.  
  556.  
  557.  
  558.  
  559.  
  560.  
  561.  
  562. Bernstein                                                      [Page 10]
  563.