Telnet Status Option
RFC 859 also known as STD 30

Network Working Group J. Postel
Request for Comments: 859 J. Reynolds
 ISI
Obsoletes: RFC 651 (NIC 31154) May 1983

 TELNET STATUS OPTION

This RFC specifies a standard for the ARPA Internet community. Hosts on
the ARPA Internet are expected to adopt and implement this standard.

1. Command Name and Code

 STATUS 5

2. Command Meanings

 This option applies separately to each direction of data flow.

 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

 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

Postel & Reynolds [Page 1]



RFC 859 May 1983

 could lead to the nonterminating request loop problem discussed in
 the General Consideration section of the TELNET Specification. This
 option fits into the normal structure of TELNET options by deferring
 the actual transfer of status information to the SB command.

5. Description of the Option

 WILL and DO are 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.

Postel & Reynolds [Page 2]



RFC 859 May 1983

 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

 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.

Postel & Reynolds [Page 3]