The Q Method of Implementing TELNET Option Negotiation (RFC1143)
Original Publication Date: 1990-Feb-01
Included in the Prior Art Database: 2000-Sep-12
Internet Society Requests For Comment (RFCs)
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.
Network Working Group D. Bernstein
Request for Comments: 1143 NYU
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
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
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
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 wit...