home *** CD-ROM | disk | FTP | other *** search
/ Handbook of Infosec Terms 2.0 / Handbook_of_Infosec_Terms_Version_2.0_ISSO.iso / text / rfcs / rfc0859.txt < prev    next >
Text File  |  1996-05-07  |  4KB  |  127 lines
  1.  Network Working Group                                          J. Postel Request for Comments: 859                                    J. Reynolds                                                                      ISI Obsoletes: RFC 651 (NIC 31154)                                  May 1983 
  2.  
  3.                           TELNET STATUS OPTION 
  4.  
  5.  This RFC specifies a standard for the ARPA Internet community.  Hosts on the ARPA Internet are expected to adopt and implement this standard. 
  6.  
  7. 1. Command Name and Code 
  8.  
  9.    STATUS 5 
  10.  
  11. 2. Command Meanings 
  12.  
  13.    This option applies separately to each direction of data flow. 
  14.  
  15.    IAC DON'T STATUS 
  16.  
  17.       Sender refuses to carry on any further discussion of the current       status of options. 
  18.  
  19.    IAC WON'T STATUS 
  20.  
  21.       Sender refuses to carry on any further discussion of the current       status of options. 
  22.  
  23.    IAC SB STATUS SEND IAC SE 
  24.  
  25.       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.) 
  26.  
  27.    IAC SB STATUS IS ... IAC SE 
  28.  
  29.       Sender is stating his perception of the current status of Telnet       options. The code for IS is 0. (See below.) 
  30.  
  31. 3. Default 
  32.  
  33.    DON'T STATUS, WON'T STATUS 
  34.  
  35.       The current status of options will not be discussed. 
  36.  
  37. 4. Motivation for the Option 
  38.  
  39.    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 
  40.  
  41.  Postel & Reynolds                                               [Page 1] 
  42.  
  43.  
  44.  RFC 859                                                         May 1983 
  45.  
  46.     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. 
  47.  
  48. 5. Description of the Option 
  49.  
  50.    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...). 
  51.  
  52.    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). 
  53.  
  54.    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. 
  55.  
  56.  
  57.  
  58.  
  59.  
  60.  
  61.  
  62.  
  63.  
  64.  
  65.  
  66.  
  67.  
  68.  
  69.  
  70.  
  71.  
  72.  
  73.  
  74.  
  75.  
  76.  
  77.  
  78.  Postel & Reynolds                                               [Page 2] 
  79.  
  80.  
  81.  RFC 859                                                         May 1983 
  82.  
  83.     The following is an example of use of the option: 
  84.  
  85.       Host1: IAC DO STATUS 
  86.  
  87.       Host2: IAC WILL STATUS 
  88.  
  89.          (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.) 
  90.  
  91.       Host1 (perhaps): IAC SB STATUS SEND IAC SE 
  92.  
  93.       Host2 (the following stream is broken into multiple lines only for       readability. No carriage returns are implied.): 
  94.  
  95.          IAC SB STATUS IS 
  96.  
  97.          WILL ECHO 
  98.  
  99.          DO SUPPRESS-GO-AHEAD 
  100.  
  101.          WILL STATUS 
  102.  
  103.          DO STATUS 
  104.  
  105.          IAC SE 
  106.  
  107.       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. 
  108.  
  109.  
  110.  
  111.  
  112.  
  113.  
  114.  
  115.  
  116.  
  117.  
  118.  
  119.  
  120.  
  121.  
  122.  
  123.  
  124.  
  125.  Postel & Reynolds                                               [Page 3] 
  126.  
  127.