doc: Add RFC documents

1 files changed, 563 insertions, 0 deletions

diff --git a/doc/rfc/rfc1143.txt b/doc/rfc/rfc1143.txt
new file mode 100644
index 0000000..fc4d635
--- /dev/null
+++ b/doc/rfc/rfc1143.txt
@@ -0,0 +1,563 @@
+
+
+
+
+
+
+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]
+
+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, dab@opus.cray.com, for his helpful comments.
+
+Author's Address
+
+   Daniel J. Bernstein
+   5 Brewster Lane
+   Bellport, NY 11713
+
+   Phone:  516-286-1339
+
+   Email:  brnstnd@acf10.nyu.edu
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Bernstein                                                      [Page 10]
+
\ No newline at end of file