RFC 764 (rfc764) - Page 2 of 15
Telnet Protocol specification
Alternative Format: Original Text Document
June 1980 RFC 764, IEN 148
Telnet Protocol Specification
2. The principle of negotiated options takes cognizance of the fact
that many sites will wish to provide additional services over and
above those available within an NVT, and many users will have
sophisticated terminals and would like to have elegant, rather than
minimal, services. Independent of, but structured within, the TELNET
Protocol various "options" will be sanctioned which can be used with
the "DO, DON'T, WILL, WON'T" structure (discussed below) to allow a
user and server to agree to use a more elaborate (or perhaps just
different) set of conventions for their TELNET connection. Such
options could include changing the character set, the echo mode, the
line width, the page length, etc.
The basic strategy for setting up the use of options is to have
either party (or both) initiate a request that some option take
effect. The other party may then either accept or reject the
request. If the request is accepted the option immediately takes
effect; if it is rejected the associated aspect of the connection
remains as specified for an NVT. Clearly, a party may always refuse
a request to enable, and must never refuse a request to disable, some
option since all parties must be prepared to support the NVT.
The syntax of option negotiation has been set up so that if both
parties request an option simultaneously, each will see the other's
request as the positive acknowledgment of its own.
3. The symmetry of the negotiation syntax can potentially lead to
nonterminating acknowledgment loops -- each party seeing the incoming
commands not as acknowledgments but as new requests which must be
acknowledged. To prevent such loops, the following rules prevail:
a. Parties may only request a change in option status; i.e., a
party may not send out a "request" merely to announce what
mode it is in.
b. If a party receives what appears to be a request to enter some
mode it is already in, the request should not be acknowledged.
c. Whenever one party sends an option command to a second party,
whether as a request or an acknowledgment, and use of the
option will have any effect on the processing of the data
being sent from the first party to the second, then the
command must be inserted in the data stream at the point where
it is desired that it take effect. (It should be noted that
some time will elapse between the transmission of a request
and the receipt of an acknowledgment, which may be negative.
Thus, a site may wish to buffer data, after requesting an