doc: Add RFC documents

1 files changed, 284 insertions, 0 deletions

diff --git a/doc/rfc/rfc857.txt b/doc/rfc/rfc857.txt
new file mode 100644
index 0000000..e18adba
--- /dev/null
+++ b/doc/rfc/rfc857.txt
@@ -0,0 +1,284 @@
+
+Network Working Group                                          J. Postel
+Request for Comments: 857                                    J. Reynolds
+                                                                     ISI
+Obsoletes: NIC 15390                                            May 1983
+
+                           TELNET ECHO 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
+
+   ECHO       1
+
+2. Command Meanings
+
+   IAC WILL ECHO
+
+      The sender of this command REQUESTS to begin, or confirms that it
+      will now begin, echoing data characters it receives over the
+      TELNET connection back to the sender of the data characters.
+
+   IAC WON'T ECHO
+
+      The sender of this command DEMANDS to stop, or refuses to start,
+      echoing the data characters it receives over the TELNET connection
+      back to the sender of the data characters.
+
+   IAC DO ECHO
+
+      The sender of this command REQUESTS that the receiver of this
+      command begin echoing, or confirms that the receiver of this
+      command is expected to echo, data characters it receives over the
+      TELNET connection back to the sender.
+
+   IAC DON'T ECHO
+
+      The sender of this command DEMANDS the receiver of this command
+      stop, or not start, echoing data characters it receives over the
+      TELNET connection.
+
+3. Default
+
+   WON'T ECHO
+
+   DON'T ECHO
+
+      No echoing is done over the TELNET connection.
+
+4. Motivation for the Option
+
+
+Postel & Reynolds                                               [Page 1]
+
+
+
+RFC 857                                                         May 1983
+
+
+   The NVT has a printer and a keyboard which are nominally
+   interconnected so that "echoes" need never traverse the network; that
+   is to say, the NVT nominally operates in a mode where characters
+   typed on the keyboard are (by some means) locally turned around and
+   printed on the printer.  In highly interactive situations it is
+   appropriate for the remote process (command language interpreter,
+   etc.) to which the characters are being sent to control the way they
+   are echoed on the printer.  In order to support such interactive
+   situations, it is necessary that there be a TELNET option to allow
+   the parties at the two ends of the TELNET connection to agree that
+   characters typed on an NVT keyboard are to be echoed by the party at
+   the other end of the TELNET connection.
+
+5. Description of the Option
+
+   When the echoing option is in effect, the party at the end performing
+   the echoing is expected to transmit (echo) data characters it
+   receives back to the sender of the data characters.  The option does
+   not require that the characters echoed be exactly the characters
+   received (for example, a number of systems echo the ASCII ESC
+   character with something other than the ESC character).  When the
+   echoing option is not in effect, the receiver of data characters
+   should not echo them back to the sender; this, of course, does not
+   prevent the receiver from responding to data characters received.
+
+   The normal TELNET connection is two way.  That is, data flows in each
+   direction on the connection independently; and neither, either, or
+   both directions may be operating simultaneously in echo mode.  There
+   are five reasonable modes of operation for echoing on a connection
+   pair:
+
+      
+                <----------------
+      
+      Process 1                   Process 2
+                ---------------->
+                 Neither end echoes
+
+      
+                <----------------
+                   \
+      Process 1    /              Process 2
+                ---------------->
+             One end echoes for itself
+
+
+
+
+
+
+Postel & Reynolds                                               [Page 2]
+
+
+
+RFC 857                                                         May 1983
+
+
+      
+                <----------------
+                             \
+      Process 1              /    Process 2
+                ---------------->
+          One end echoes for the other
+
+      
+                <----------------
+                   \         /
+      Process 1    /         \    Process 2
+                ---------------->
+          Both ends echo for themselves
+
+      
+                <----------------
+                   \ /
+      Process 1    / \            Process 2
+                ---------------->
+           One end echoes for both ends
+
+   This option provides the capability to decide on whether or not
+   either end will echo for the other.  It does not, however, provide
+   any control over whether or not an end echoes for itself;  this
+   decision must be left to the sole discretion of the systems at each
+   end (although they may use information regarding the state of
+   "remote" echoing negotiations in making this decision).
+
+   It should be noted that if BOTH hosts enter the mode of echoing
+   characters transmitted by the other host, then any character
+   transmitted in either direction will be "echoed" back and forth
+   indefinitely.  Therefore, care should be taken in each implementation
+   that if one site is echoing, echoing is not permitted to be turned on
+   at the other.
+
+   As discussed in the TELNET Protocol Specification, both parties to a
+   full-duplex TELNET connection initially assume each direction of the
+   connection is being operated in the default mode which is non-echo
+   (non-echo is not using this option, and the same as DON'T ECHO, WON'T
+   ECHO).
+
+   If either party desires himself to echo characters to the other party
+   or for the other party to echo characters to him, that party gives
+   the appropriate command (WILL ECHO or DO ECHO) and waits (and hopes)
+   for acceptance of the option.  If the request to operate the
+   connection in echo mode is refused, then the connection continues to
+   operate in non-echo mode.  If the request to operate the connection
+   in echo mode is accepted, the connection is operated in echo mode.
+
+
+Postel & Reynolds                                               [Page 3]
+
+
+
+RFC 857                                                         May 1983
+
+
+   After a connection has been changed to echo mode, either party may
+   demand that it revert to non-echo mode by giving the appropriate
+   DON'T ECHO or WON'T ECHO command (which the other party must confirm
+   thereby allowing the connection to operate in non-echo mode).  Just
+   as each direction of the TELNET connection may be put in remote
+   echoing mode independently, each direction of the TELNET connection
+   must be removed from remote echoing mode separately.
+
+   Implementations of the echo option, as implementations of all other
+   TELNET options, must follow the loop preventing rules given in the
+   General Considerations section of the TELNET Protocol Specification.
+   Also, so that switches between echo and non-echo mode can be made
+   with minimal confusion (momentary double echoing, etc.), switches in
+   mode of operation should be made at times precisely coordinated with
+   the reception and transmission of echo requests and demands.  For
+   instance, if one party responds to a DO ECHO with a WILL ECHO, all
+   data characters received after the DO ECHO should be echoed and the
+   WILL ECHO should immediately precede the first of the echoed
+   characters.
+
+   The echoing option alone will normally not be sufficient to effect
+   what is commonly understood to be remote computer echoing of
+   characters typed on a terminal keyboard--the SUPPRESS-GO AHEAD option
+   will normally have to be invoked in conjunction with the ECHO option
+   to effect character-at-a-time remote echoing.
+
+6. A Sample Implementation of the Option
+
+   The following is a description of a possible implementation for a
+   simple user system called "UHOST".
+
+   A possible implementation could be that for each user terminal, the
+   UHOST would keep three state bits: whether the terminal echoes for
+   itself (UHOST ECHO always) or not (ECHO mode possible), whether the
+   (human) user prefers to operate in ECHO mode or in non-ECHO mode, and
+   whether the connection from this terminal to the server is in ECHO or
+   non-ECHO mode.  We will call these three bits P(hysical), D(esired),
+   and A(ctual).
+
+   When a terminal dials up the UHOST the P-bit is set appropriately,
+   the D-bit is set equal to it, and the A-bit is set to non-ECHO.  The
+   P-bit and D-bit may be manually reset by direct commands if the user
+   so desires.  For example, a user in Hawaii on a "full-duplex"
+   terminal, would choose not to operate in ECHO mode, regardless of the
+   preference of a mainland server.  He should direct the UHOST to
+   change his D-bit from ECHO to non-ECHO.
+
+   When a connection is opened from the UHOST terminal to a server, the
+
+
+Postel & Reynolds                                               [Page 4]
+
+
+
+RFC 857                                                         May 1983
+
+
+   UHOST would send the server a DO ECHO command if the MIN (with
+   non-ECHO less than ECHO) of the P- and D-bits is different from the
+   A-bit.  If a WON'T ECHO or WILL ECHO arrives from the server, the
+   UHOST will set the A-bit to the MIN of the received request, the
+   P-bit, and the D-bit.  If this changes the state of the A-bit, the
+   UHOST will send off the appropriate acknowledgment; if it does not,
+   then the UHOST will send off the appropriate refusal if not changing
+   meant that it had to deny the request (i.e., the MIN of the P-and
+   D-bits was less than the received A-request).
+
+   If while a connection is open, the UHOST terminal user changes either
+   the P-bit or D-bit, the UHOST will repeat the above tests and send
+   off a DO ECHO or DON'T ECHO, if necessary.  When the connection is
+   closed, the UHOST would reset the A-bit to indicate UHOST echoing.
+
+   While the UHOST's implementation would not involve DO ECHO or DON'T
+   ECHO commands being sent to the server except when the connection is
+   opened or the user explicitly changes his echoing mode, bigger hosts
+   might invoke such mode switches quite frequently.  For instance,
+   while a line-at-a-time system were running, the server might attempt
+   to put the user in local echo mode by sending the WON'T ECHO command
+   to the user; but while a character-at-a-time system were running, the
+   server might attempt to invoke remote echoing for the user by sending
+   the WILL ECHO command to the user.  Furthermore, while the UHOST will
+   never send a WILL ECHO command and will only send a WON'T ECHO to
+   refuse a server sent DO ECHO command, a server host might often send
+   the WILL and WON'T ECHO commands.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Postel & Reynolds                                               [Page 5]
+