The Q Method of Implementing TELNET Option Negotiation
RFC 1143
|
Document |
Type |
|
RFC - Experimental
(February 1990; No errata)
|
|
Last updated |
|
2013-03-02
|
|
Stream |
|
Legacy
|
|
Formats |
|
plain text
pdf
htmlized
bibtex
|
Stream |
Legacy state
|
|
(None)
|
|
Consensus Boilerplate |
|
Unknown
|
|
RFC Editor Note |
|
(None)
|
IESG |
IESG state |
|
RFC 1143 (Experimental)
|
|
Telechat date |
|
|
|
Responsible AD |
|
(None)
|
|
Send notices to |
|
(None)
|
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
Show full document text