home *** CD-ROM | disk | FTP | other *** search
/ Unix System Administration Handbook 1997 October / usah_oct97.iso / rfc / 800s / rfc859.txt < prev    next >
Text File  |  1991-10-16  |  4KB  |  171 lines
  1.  
  2. Network Working Group                                          J. Postel
  3. Request for Comments: 859                                    J. Reynolds
  4.                                                                      ISI
  5. Obsoletes: RFC 651 (NIC 31154)                                  May 1983
  6.  
  7.                           TELNET STATUS OPTION
  8.  
  9.  
  10. This RFC specifies a standard for the ARPA Internet community.  Hosts on
  11. the ARPA Internet are expected to adopt and implement this standard.
  12.  
  13. 1. Command Name and Code
  14.  
  15.    STATUS 5
  16.  
  17. 2. Command Meanings
  18.  
  19.    This option applies separately to each direction of data flow.
  20.  
  21.    IAC DON'T STATUS
  22.  
  23.       Sender refuses to carry on any further discussion of the current
  24.       status of options.
  25.  
  26.    IAC WON'T STATUS
  27.  
  28.       Sender refuses to carry on any further discussion of the current
  29.       status of options.
  30.  
  31.    IAC SB STATUS SEND IAC SE
  32.  
  33.       Sender requests receiver to transmit his (the receiver's)
  34.       perception of the current status of Telnet options. The code for
  35.       SEND is 1. (See below.)
  36.  
  37.    IAC SB STATUS IS ... IAC SE
  38.  
  39.       Sender is stating his perception of the current status of Telnet
  40.       options. The code for IS is 0. (See below.)
  41.  
  42. 3. Default
  43.  
  44.    DON'T STATUS, WON'T STATUS
  45.  
  46.       The current status of options will not be discussed.
  47.  
  48. 4. Motivation for the Option
  49.  
  50.    This option allows a user/process to verify the current status of
  51.    TELNET options (e.g., echoing) as viewed by the person/process on the
  52.    other end of the TELNET connection. Simply renegotiating options
  53.  
  54.  
  55. Postel & Reynolds                                               [Page 1]
  56.  
  57.  
  58.  
  59. RFC 859                                                         May 1983
  60.  
  61.  
  62.    could lead to the nonterminating request loop problem discussed in
  63.    the General Consideration section of the TELNET Specification.  This
  64.    option fits into the normal structure of TELNET options by deferring
  65.    the actual transfer of status information to the SB command.
  66.  
  67. 5. Description of the Option
  68.  
  69.    WILL and DO are used only to obtain and grant permission for future
  70.    discussion. The actual exchange of status information occurs within
  71.    option subcommands (IAC SB STATUS...).
  72.  
  73.    Once the two hosts have exchanged a WILL and a DO, the sender of the
  74.    WILL STATUS is free to transmit status information, spontaneously or
  75.    in response to a request from the sender of the DO. At worst, this
  76.    may lead to transmitting the information twice. Only the sender of
  77.    the DO may send requests (IAC SB STATUS SEND IAC SE) and only the
  78.    sender of the WILL may transmit actual status information (within an
  79.    IAC SB STATUS IS ... IAC SE command).
  80.  
  81.    IS has the subcommands WILL, DO and SB. They are used EXACTLY as used
  82.    during the actual negotiation of TELNET options, except that SB is
  83.    terminated with SE, rather than IAC SE. Transmission of SE, as a
  84.    regular data byte, is accomplished by doubling the byte (SE SE).
  85.    Options that are not explicitly described are assumed to be in their
  86.    default states. A single IAC SB STATUS IS ... IAC SE describes the
  87.    condition of ALL options.
  88.  
  89.  
  90.  
  91.  
  92.  
  93.  
  94.  
  95.  
  96.  
  97.  
  98.  
  99.  
  100.  
  101.  
  102.  
  103.  
  104.  
  105.  
  106.  
  107.  
  108.  
  109.  
  110.  
  111.  
  112. Postel & Reynolds                                               [Page 2]
  113.  
  114.  
  115.  
  116. RFC 859                                                         May 1983
  117.  
  118.  
  119.    The following is an example of use of the option:
  120.  
  121.       Host1: IAC DO STATUS
  122.  
  123.       Host2: IAC WILL STATUS
  124.  
  125.          (Host2 is now free to send status information at any time.
  126.          Solicitations from Host1 are NOT necessary. This should not
  127.          produce any dangerous race conditions. At worst, two IS's will
  128.          be sent.)
  129.  
  130.       Host1 (perhaps): IAC SB STATUS SEND IAC SE
  131.  
  132.       Host2 (the following stream is broken into multiple lines only for
  133.       readability. No carriage returns are implied.):
  134.  
  135.          IAC SB STATUS IS
  136.  
  137.          WILL ECHO
  138.  
  139.          DO SUPPRESS-GO-AHEAD
  140.  
  141.          WILL STATUS
  142.  
  143.          DO STATUS
  144.  
  145.          IAC SE
  146.  
  147.       Explanation of Host2's perceptions: It is responsible for echoing
  148.       back the data characters it receives over the TELNET connection;
  149.       it will not send Go-Ahead signals; it will both issue and request
  150.       Status information.
  151.  
  152.  
  153.  
  154.  
  155.  
  156.  
  157.  
  158.  
  159.  
  160.  
  161.  
  162.  
  163.  
  164.  
  165.  
  166.  
  167.  
  168.  
  169. Postel & Reynolds                                               [Page 3]
  170.  
  171.