home *** CD-ROM | disk | FTP | other *** search
/ Unix System Administration Handbook 1997 October / usah_oct97.iso / rfc / 600s / rfc651.txt < prev    next >
Text File  |  1992-10-14  |  4KB  |  87 lines
  1. Revised Telnet Status Option
  2. NIC 31154 (25 Oct. 74)
  3. Request for Comments: 651
  4. D. Crocker (UCLA-NMC) 25 Oct. 74
  5. RFC# 651
  6. Online file: <[ISI]<DCROCKER>STATUS-OPTION-REVISION.RNO
  7.  
  8.  
  9.                      Revised Telnet Status Option
  10. 1. Command name and code
  11.    STATUS  5
  12. 2. Command meanings
  13.    As described in the NAOL and NAOP option specifications, this option applies
  14.    to a simplex connection.
  15.       IAC DO STATUS 
  16.          Sender of DO wishes to be able to send requests for status-of-options 
  17.          information, or confirms that he is willing to send such requests.
  18.       IAC WILL STATUS 
  19.          Sender of WILL wishes or agrees to send status information, 
  20.          spontaneously or in response to future requests.
  21.       IAC DON'T STATUS 
  22.          Sender refuses to carry on any further discussion of the current 
  23.          status of options.
  24.       IAC WON'T STATUS 
  25.          Sender refuses to carry on any further discussion of the current 
  26.          status of options.
  27.       IAC SB STATUS SEND IAC SE
  28.          Sender requests receiver to transmit his (the receiver's) perception 
  29.          of the current status of Telnet options. The code for SEND is 1. (See 
  30.          below.)
  31.       IAC SB STATUS IS ... IAC SE 
  32.          Sender is stating his perception of the current status of Telnet 
  33.          options. The code for IS is 0. (See below.)
  34. 3. Default
  35.    DON'T STATUS/WON'T STATUS. That is, the current status of options will not 
  36.    be discussed.
  37. 4. Motivation for the option
  38.    This option allows a user/process to verify the current status of Telnet 
  39.    options (e.g., echoing) as viewed by the person/process on the other end of 
  40.    the Telnet connection. Simply renegotiating options could lead to the 
  41.    nonterminating request loop problem discussed in (NIC #16237). The changes 
  42.    to the option, described in this paper, allow STATUS to fit into the normal 
  43.    structure of Telnet options, by deferring the actual transfer of status 
  44.    information to the SB command. Additionally, the numbers of bytes that must 
  45.    be sent to describe the state of the options has been considerably reduced.
  46. 5. Description of the option
  47.    WILL/DO are now used only to obtain and grant permission for future 
  48.    discussion. The actual exchange of status information occurs within option 
  49.    subcommands (IAC SB STATUS...).
  50.    Once the two hosts have exchanged a WILL and a DO, the sender of the WILL 
  51.    STATUS is free to transmit status information, spontaneously or in response 
  52.    to a request from the sender of the DO. At worst, this may lead to 
  53.    transmitting the information twice. Only the sender of the DO may send 
  54.    requests (IAC SB STATUS SEND IAC SE) and only the sender of the WILL may 
  55.    transmit actual status information (within an IAC SB STATUS IS ... IAC SE 
  56.    command).
  57.    IS has the subcommands WILL, DO and SB. They are used EXACTLY as used during
  58.    the actual negotiation of Telnet options, except that SB is terminated with 
  59.    SE, rather than IAC SE. Transmission of SE, as a regular data byte, is 
  60.    accomplished by doubling the byte (SE SE). Options that are not explicitly 
  61.    described are assumed to be in their default states. A single IAC SB STATUS 
  62.    IS ... IAC SE describes the condition of ALL options.
  63.    The following is an example of use of the option:
  64.       Host1: IAC DO STATUS
  65.       Host2: IAC WILL STATUS
  66.          (Host2 is now free to send status information at any time. 
  67.          Solicitations from Host1 are NOT necessary. This should not produce 
  68.          any dangerous race conditions. At worst, two IS's will be sent.
  69.       Host1 (perhaps): IAC SB STATUS SEND IAC SE
  70.       Host2 (the following stream is broken into multiple lines only for 
  71.       readability. No carriage returns are implied.):
  72.          IAC SB STATUS IS
  73.          WILL ECHO
  74.          DO SUPPRESS-GO-AHEAD
  75.          WILL STATUS
  76.          DO STATUS
  77.          WILL RCTE
  78.          SB RCTE <11><1><24> SE
  79.          DO NAOL
  80.          SB NAOL DS <66> SE
  81.          IAC SE
  82.       Explanation of Host2's perceptions: It is responsible for echoing back 
  83.       the data characters it receives over the Telnet connection; it will not 
  84.       send Go-Ahead signals; it will both issue and request Status information;
  85.       it will send instruction for controlling the other side's terminal 
  86.       printer; it will discuss the line width for data it is sending.
  87.