diff options
Diffstat (limited to 'doc/rfc/rfc1143.txt')
| -rw-r--r-- | doc/rfc/rfc1143.txt | 563 |
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 |