RFC 651 UNKNOWN TELNET · OPTIONS

Revised Telnet status option

A revision of the Telnet STATUS option for asking about current option settings.

On rfc-editor.org ↗
PUBLISHED
October 1974
AUTHORS
D. Crocker
STREAM
Legacy
OBSOLETED BY
RFC 859 — Telnet Status
STATUS OPTION CODE
5
SEND SUBCOMMAND
1
IS SUBCOMMAND
0
DOI
10.17487/RFC0651

RFC text

Original text · RFC Editor View on rfc-editor.org ↗
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.

ISO Plain Language

On this page
PROBLEMSimply renegotiating Telnet options to learn their state could lead to nonterminating request loops.
MECHANISMThe STATUS option uses DO and WILL to permit discussion, then SEND and IS subcommands to request and report option state.
STATUS TODAYRFC 651 was obsoleted by RFC 859.

§1The Telnet STATUS Option

STATUS is Telnet option 5. It lets a user or process verify the current status of options, such as echoing, as seen by the other end. By default, each side uses DON'T STATUS or WON'T STATUS, so the option status is not discussed.

The revision places the actual status exchange in subnegotiation, which fits the normal structure of Telnet options and avoids using option renegotiation just to inspect current state.

STATUS lets one end ask what settings the other end currently believes are in effect. The default is not to exchange this information.

§2Permission and Status Requests

DO STATUS means the sender wants to send status requests or confirms it is willing to send them. WILL STATUS means the sender agrees to provide status, either spontaneously or in response to a request. These commands grant permission for later discussion; the actual status information is sent in subcommands.

Only the sender of DO may send IAC SB STATUS SEND IAC SE, where SEND is code 1. Only the sender of WILL may send IAC SB STATUS IS ... IAC SE, where IS is code 0. The WILL side may send status without a request, so a request can result in duplicate reports at worst.

First the endpoints agree that status information may be exchanged. The DO side can request a report, and the WILL side sends the report.

STATUS PERMISSION AND REPORT EXCHANGE
Host 1Host 2
  1. IAC DO STATUS
  2. IAC WILL STATUS
  3. IAC SB STATUS SEND IAC SEOptional request for a status report.
  4. IAC SB STATUS IS ... IAC SEReports current option states.

§3Reading an IS Report

An IS report uses WILL, DO, and SB entries in the same way as ordinary Telnet option negotiation. In this report, SB is terminated by SE rather than IAC SE. To send an SE byte as ordinary data, the byte is doubled.

Options not explicitly described in the report are assumed to be in their default states, so one IS subcommand describes the condition of all options.

The IS report lists options that are not in their default state. Any option it leaves out is assumed to be at its default setting.