Revised Telnet status option
A 1974 revision of the Telnet STATUS option, which lets each side ask how the other sees its options.
Crocker, D., "Revised Telnet status option", RFC 651, DOI 10.17487/RFC0651, October 1974, <https://www.rfc-editor.org/info/rfc651>.
@misc{rfc651,
series = {Request for Comments},
number = 651,
howpublished = {RFC 651},
publisher = {RFC Editor},
doi = {10.17487/RFC0651},
url = {https://www.rfc-editor.org/info/rfc651},
author = {D. Crocker},
title = {{Revised Telnet status option}},
pagetotal = 2,
year = 1974,
month = oct,
} RFC text
Revised Telnet Status Option
NIC 31154 (25 Oct. 74)
Request for Comments: 651
D. Crocker (UCLA-NMC) 25 Oct. 74
RFC# 651
Online file: <[ISI]<DCROCKER>STATUS-OPTION-REVISION.RNO
Revised Telnet Status Option
1. Command name and code
STATUS 5
2. Command meanings
As described in the NAOL and NAOP option specifications, this option applies
to a simplex connection.
IAC DO STATUS
Sender of DO wishes to be able to send requests for status-of-options
information, or confirms that he is willing to send such requests.
IAC WILL STATUS
Sender of WILL wishes or agrees to send status information,
spontaneously or in response to future requests.
IAC DON'T STATUS
Sender refuses to carry on any further discussion of the current
status of options.
IAC WON'T STATUS
Sender refuses to carry on any further discussion of the current
status of options.
IAC SB STATUS SEND IAC SE
Sender requests receiver to transmit his (the receiver's) perception
of the current status of Telnet options. The code for SEND is 1. (See
below.)
IAC SB STATUS IS ... IAC SE
Sender is stating his perception of the current status of Telnet
options. The code for IS is 0. (See below.)
3. Default
DON'T STATUS/WON'T STATUS. That is, the current status of options will not
be discussed.
4. Motivation for the option
This option allows a user/process to verify the current status of Telnet
options (e.g., echoing) as viewed by the person/process on the other end of
the Telnet connection. Simply renegotiating options could lead to the
nonterminating request loop problem discussed in (NIC #16237). The changes
to the option, described in this paper, allow STATUS to fit into the normal
structure of Telnet options, by deferring the actual transfer of status
information to the SB command. Additionally, the numbers of bytes that must
be sent to describe the state of the options has been considerably reduced.
5. Description of the option
WILL/DO are now used only to obtain and grant permission for future
discussion. The actual exchange of status information occurs within option
subcommands (IAC SB STATUS...).
Once the two hosts have exchanged a WILL and a DO, the sender of the WILL
STATUS is free to transmit status information, spontaneously or in response
to a request from the sender of the DO. At worst, this may lead to
transmitting the information twice. Only the sender of the DO may send
requests (IAC SB STATUS SEND IAC SE) and only the sender of the WILL may
transmit actual status information (within an IAC SB STATUS IS ... IAC SE
command).
IS has the subcommands WILL, DO and SB. They are used EXACTLY as used during
the actual negotiation of Telnet options, except that SB is terminated with
SE, rather than IAC SE. Transmission of SE, as a regular data byte, is
accomplished by doubling the byte (SE SE). Options that are not explicitly
described are assumed to be in their default states. A single IAC SB STATUS
IS ... IAC SE describes the condition of ALL options.
The following is an example of use of the option:
Host1: IAC DO STATUS
Host2: IAC WILL STATUS
(Host2 is now free to send status information at any time.
Solicitations from Host1 are NOT necessary. This should not produce
any dangerous race conditions. At worst, two IS's will be sent.
Host1 (perhaps): IAC SB STATUS SEND IAC SE
Host2 (the following stream is broken into multiple lines only for
readability. No carriage returns are implied.):
IAC SB STATUS IS
WILL ECHO
DO SUPPRESS-GO-AHEAD
WILL STATUS
DO STATUS
WILL RCTE
SB RCTE <11><1><24> SE
DO NAOL
SB NAOL DS <66> SE
IAC SE
Explanation of Host2's perceptions: It is responsible for echoing back
the data characters it receives over the Telnet connection; it will not
send Go-Ahead signals; it will both issue and request Status information;
it will send instruction for controlling the other side's terminal
printer; it will discuss the line width for data it is sending.
AI ELI5
On this page
§1The STATUS Option
The Telnet STATUS option has code 5. It lets a user or process verify the current status of Telnet options (for example echoing) as the other end sees them. Its default is DON'T STATUS / WON'T STATUS, meaning status is not discussed.
The revision lets STATUS fit the normal structure of Telnet options by deferring the transfer of status to the SB command, and it greatly reduces the bytes needed to describe option state.
It is a way to ask the other computer, "what settings do you think we are using?", without starting an argument about them.
§2Negotiating and Requesting
WILL and DO now only obtain and grant permission for future discussion. After they are exchanged, the sender of WILL STATUS may send status spontaneously or when asked.
Only the sender of DO may send IAC SB STATUS SEND IAC SE (SEND is code 1). Only the sender of WILL may send IAC SB STATUS IS ... IAC SE (IS is code 0). At worst, the information may be sent twice.
First both sides agree it is okay to talk about settings. Then one side can ask, and only the other side answers.
- IAC DO STATUSHost1 wants to send status requests.
- IAC WILL STATUSHost2 may now send status at any time.
- IAC SB STATUS SEND IAC SEOptional request; perhaps.
- IAC SB STATUS IS ... IAC SEHost2 lists its option states.
§3The IS Report
Inside IS, the subcommands WILL, DO and SB are used exactly as in normal option negotiation, except that SB is ended by SE rather than IAC SE. A literal SE data byte is sent doubled (SE SE).
Options not mentioned are assumed to be in their default states, so a single IS report describes the condition of all options. The RFC's example shows a host reporting that it will echo, will not send Go-Ahead, and will both issue and request status.
The answer is a short list of the settings that are switched on. Anything not on the list is assumed to be at its usual setting.