The Q Method of Implementing TELNET Option Negotiation (RFC1143)
Original Publication Date: 1990-Feb-01
Included in the Prior Art Database: 2019-Feb-11
Internet Society Requests For Comment (RFCs)
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.
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.
This RFC amplifies, supplements, and extends the RFC 854  option negotiation rules and guidelines, which are insufficient to prevent all option negotiation loops. This RFC also presents an example of correct implementation.
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 ...