doc: Add RFC documents

1 files changed, 170 insertions, 0 deletions

diff --git a/doc/rfc/rfc859.txt b/doc/rfc/rfc859.txt
new file mode 100644
index 0000000..068572e
--- /dev/null
+++ b/doc/rfc/rfc859.txt
@@ -0,0 +1,170 @@
+
+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]
+