rfc-859

Telnet Status Option

J. Postel, J. Reynolds
date1983-05 streamLegacy statusINTERNET STANDARD pages3 canonicalhttps://www.rfc-editor.org/rfc/rfc859 doi10.17487/RFC0859
This Telnet Option provides a way to determine the other Telnet module's view of the status of options. This RFC specifies a standard for the ARPA Internet community. Hosts on the ARPA Internet are expected to adopt and implement this standard. Obsoletes RFC 651 (NIC 31154).

obsoletes

also

Extracted elements (14)

design-rationale §4

The STATUS option was introduced because simply renegotiating options to verify their state could produce nonterminating request loops as described in the General Considerations section of the Telnet specification. This option allows verification without triggering renegotiation.

design-rationale §5

WILL and DO commands are used only to obtain and grant permission for future status discussion. Actual status information is deferred to SB subcommands, fitting STATUS into the normal Telnet option structure.

interoperability-note §5

Because the WILL sender may transmit status spontaneously and also in response to a SEND request, a race condition exists where status information may be transmitted twice. Implementations must tolerate receiving multiple IS responses.

normative-requirement §5 MAY

Once WILL and DO have been exchanged, the WILL sender is free to transmit status information spontaneously or in response to a SEND request. No solicitation is required before sending status.

normative-requirement §5 MUST

Only the sender of DO STATUS may send solicitation requests (IAC SB STATUS SEND IAC SE). Only the sender of WILL STATUS may transmit actual status information (IAC SB STATUS IS ... IAC SE).

normative-requirement §5 MUST

Options not explicitly described in an IS subnegotiation are assumed to be in their default states. A single IAC SB STATUS IS ... IAC SE describes the condition of ALL options.

normative-requirement §3 SHOULD

The default state is DON'T STATUS / WON'T STATUS, meaning the current status of options will not be discussed unless the option is explicitly negotiated.

normative-requirement §5 MUST

Within a STATUS IS subnegotiation, transmission of an SE data byte must be accomplished by doubling it (SE SE), following standard Telnet subnegotiation escaping rules.

protocol-element §5

An example exchange shows Host1 sending IAC DO STATUS, Host2 responding IAC WILL STATUS, followed by a SEND request and an IS response reporting WILL ECHO, DO SUPPRESS-GO-AHEAD, WILL STATUS, and DO STATUS as the perceived active options.

protocol-element §5

The IS subnegotiation payload uses WILL, DO, and SB subcommands in exactly the same form as used during actual Telnet option negotiation, except that nested SB is terminated with SE (not IAC SE).

registry §1

The STATUS Telnet option is assigned option code 5. This option enables negotiation of status reporting capability between Telnet endpoints.

registry

wire-format §2

IAC DON'T STATUS and IAC WON'T STATUS are used to refuse further discussion of current option status. Both commands use the standard Telnet option negotiation encoding (3 bytes: IAC, command, option-code 5).

wire-format §2

IAC SB STATUS IS ... IAC SE (subnegotiation with IS code=0) carries the sender's perception of all current Telnet option states. The payload uses WILL, DO, and SB subcommands mirroring actual negotiation syntax.

wire-format §2

IAC SB STATUS SEND IAC SE (subnegotiation with SEND code=1) is sent by the DO side to request that the peer transmit its perception of the current option status.