Movatterモバイル変換

Network Working Group                                          J. PostelRequest for Comments: 855                                    J. Reynolds                                                                     ISIObsoletes: NIC 18640                                            May 1983TELNET OPTION SPECIFICATIONSThis RFC specifies a standard for the ARPA Internet community.  Hosts onthe ARPA Internet are expected to adopt and implement this standard.The intent of providing for options in the TELNET Protocol is to permithosts to obtain more elegant solutions to the problems of communicationbetween dissimilar devices than is possible within the frameworkprovided by the Network Virtual Terminal (NVT).  It should be possiblefor hosts to invent, test, or discard options at will.  Nevertheless, itis envisioned that options which prove to be generally useful willeventually be supported by many hosts; therefore it is desirable thatoptions should be carefully documented and well publicized.  Inaddition, it is necessary to insure that a single option code is notused for several different options.This document specifies a method of option code assignment and standardsfor documentation of options.  The individual responsible for assignmentof option codes may waive the requirement for complete documentation forsome cases of experimentation, but in general documentation will berequired prior to code assignment.  Options will be publicized bypublishing their documentation as RFCs; inventors of options may, ofcourse, 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-ISIFDocumentation of options should contain at least the following sections:Section 1 - Command Name and Option CodeSection 2 - Command Meanings      The meaning of each possible TELNET command relevant to this      option should be described.  Note that for complex options, wherePostel & 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]