IT. Expert System.

RFC (standard status)

Telnet Status Option. J. Postel, J. Reynolds. May 1983. RFC859. (Format: TXT=4273 bytes) (Obsoletes RFC651) (Also STD0030) (Status: INTERNET STANDARD) (DOI: 10.17487 / RFC859)


 Network Working Group                                          J. Postel
Request for Comments: 859                                    J. Reynolds
                                                                     ISI
Obsoletes: RFC 651 (NIC 31154)                                  May 1983
                          TELNET STATUS OPTION
This RFC specifies a standard for the ARPA Internet community.  Hosts on
the ARPA Internet are expected to adopt and implement this standard.
1. Command Name and Code
   STATUS 5
2. 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 options
Postel & 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] 


Content

Android Reference

Java basics

Java Enterprise Edition (EE)

Java Standard Edition (SE)

SQL

HTML

PHP

CSS

Java Script

MYSQL

JQUERY

VBS

REGEX

C

C++

C#

Design patterns

RFC (standard status)

RFC (proposed standard status)

RFC (draft standard status)

RFC (informational status)

RFC (experimental status)

RFC (best current practice status)

RFC (historic status)

RFC (unknown status)

IT dictionary

License.
All information of this service is derived from the free sources and is provided solely in the form of quotations. This service provides information and interfaces solely for the familiarization (not ownership) and under the "as is" condition.
Copyright 2016 © ELTASK.COM. All rights reserved.
Site is optimized for mobile devices.
Downloads: 1015 / 159176123. Delta: 0.04539 с