Telnet Status Option

　　Network Working Group J. Postel

　　Request for Comments: 859 J. Reynolds

　　ISI

　　Obsoletes: RFC651(NIC 31154) May 1983

　　TELNETSTATUS OPTION

　　This RFCspecifies 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　RFC859May 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.

　　RFC859May 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.