Movatterモバイル変換

Network Working Group                                          J. PostelRequest for Comments: 859                                    J. Reynolds                                                                     ISIObsoletes: RFC651 (NIC 31154)                                  May 1983TELNET STATUS OPTIONThis RFC specifies a standard for the ARPA Internet community.  Hosts onthe ARPA Internet are expected to adopt and implement this standard.1. Command Name and Code   STATUS 52. 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 optionsPostel & Reynolds                                               [Page 1]

RFC 859                                                         May 1983   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.Postel & Reynolds                                               [Page 2]

RFC 859                                                         May 1983   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.Postel & Reynolds                                               [Page 3]