Connected: An Internet Encyclopedia
RFC 859

Top: Connected: An Internet Encyclopedia
Up: Requests For Comments

Network Working Group
Request for Comments: 859

Obsoletes: RFC 651 (NIC 31154)

J. Postel
J. Reynolds
ISI
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 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.

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.

Original text document

Connected: An Internet Encyclopedia
RFC 859