1 files changed, 169 insertions, 0 deletions
diff --git a/doc/rfc/rfc855.txt b/doc/rfc/rfc855.txt
new file mode 100644
index 0000000..31f7959
--- /dev/null
+++ b/doc/rfc/rfc855.txt
@@ -0,0 +1,169 @@
+Network Working Group                                          J. Postel
+Request for Comments: 855                                    J. Reynolds
+                                                                     ISI
+Obsoletes: NIC 18640                                            May 1983
+
+                      TELNET OPTION SPECIFICATIONS
+
+
+This RFC specifies a standard for the ARPA Internet community.  Hosts on
+the ARPA Internet are expected to adopt and implement this standard.
+
+The intent of providing for options in the TELNET Protocol is to permit
+hosts to obtain more elegant solutions to the problems of communication
+between dissimilar devices than is possible within the framework
+provided by the Network Virtual Terminal (NVT).  It should be possible
+for hosts to invent, test, or discard options at will.  Nevertheless, it
+is envisioned that options which prove to be generally useful will
+eventually be supported by many hosts; therefore it is desirable that
+options should be carefully documented and well publicized.  In
+addition, it is necessary to insure that a single option code is not
+used for several different options.
+
+This document specifies a method of option code assignment and standards
+for documentation of options.  The individual responsible for assignment
+of option codes may waive the requirement for complete documentation for
+some cases of experimentation, but in general documentation will be
+required prior to code assignment.  Options will be publicized by
+publishing their documentation as RFCs; inventors of options may, of
+course, publicize them in other ways as well.
+
+   Option codes will be assigned by:
+
+      Jonathan B. Postel
+      University of Southern California
+      Information Sciences Institute (USC-ISI)
+      4676 Admiralty Way
+      Marina Del Rey, California 90291
+      (213) 822-1511
+
+      Mailbox = POSTEL@USC-ISIF
+
+Documentation of options should contain at least the following sections:
+
+   Section 1 - Command Name and Option Code
+
+   Section 2 - Command Meanings
+
+      The meaning of each possible TELNET command relevant to this
+      option should be described.  Note that for complex options, where
+
+
+
+
+Postel & Reynolds                                               [Page 1]
+
+
+
+RFC 855                                                         May 1983
+
+
+      "subnegotiation" is required, there may be a larger number of
+      possible commands.  The concept of "subnegotiation" is described
+      in more detail below.
+
+   Section 3 - Default Specification
+
+      The default assumptions for hosts which do not implement, or use,
+      the option must be described.
+
+   Section 4 - Motivation
+
+      A detailed explanation of the motivation for inventing a
+      particular option, or for choosing a particular form for the
+      option, is extremely helpful to those who are not faced (or don't
+      realize that they are faced) by the problem that the option is
+      designed to solve.
+
+   Section 5 - Description (or Implementation Rules)
+
+      Merely defining the command meanings and providing a statement of
+      motivation are not always sufficient to insure that two
+      implementations of an option will be able to communicate.
+      Therefore, a more complete description should be furnished in most
+      cases.  This description might take the form of text, a sample
+      implementation, hints to implementers, etc.
+
+A Note on "Subnegotiation"
+
+   Some options will require more information to be passed between hosts
+   than a single option code.  For example, any option which requires a
+   parameter is such a case.  The strategy to be used consists of two
+   steps:  first, both parties agree to "discuss" the parameter(s) and,
+   second, the "discussion" takes place.
+
+   The first step, agreeing to discuss the parameters, takes place in
+   the normal manner; one party proposes use of the option by sending a
+   DO (or WILL) followed by the option code, and the other party accepts
+   by returning a WILL (or DO) followed by the option code.  Once both
+   parties have agreed to use the option, subnegotiation takes place by
+   using the command SB, followed by the option code, followed by the
+   parameter(s), followed by the command SE.  Each party is presumed to
+   be able to parse the parameter(s), since each has indicated that the
+   option is supported (via the initial exchange of WILL and DO).  On
+   the other hand, the receiver may locate the end of a parameter string
+   by searching for the SE command (i.e., the string IAC SE), even if
+   the receiver is unable to parse the parameters.  Of course, either
+   party may refuse to pursue further subnegotiation at any time by
+   sending a WON'T or DON'T to the other party.
+
+
+Postel & Reynolds                                               [Page 2]
+
+
+
+RFC 855                                                         May 1983
+
+
+   Thus, for option "ABC", which requires subnegotiation, the formats of
+   the TELNET commands are:
+
+      IAC WILL ABC
+
+         Offer to use option ABC (or favorable acknowledgment of other
+         party's request)
+
+      IAC DO ABC
+
+         Request for other party to use option ABC (or favorable
+         acknowledgment of other party's offer)
+
+      IAC SB ABC <parameters> IAC SE
+
+         One step of subnegotiation, used by either party.
+
+   Designers of options requiring "subnegotiation" must take great care
+   to avoid unending loops in the subnegotiation process.  For example,
+   if each party can accept any value of a parameter, and both parties
+   suggest parameters with different values, then one is likely to have
+   an infinite oscillation of "acknowledgments" (where each receiver
+   believes it is only acknowledging the new proposals of the other).
+   Finally, if parameters in an option "subnegotiation" include a byte
+   with a value of 255, it is necessary to double this byte in
+   accordance the general TELNET rules.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Postel & Reynolds                                               [Page 3]
+