home *** CD-ROM | disk | FTP | other *** search
/ Unix System Administration Handbook 1997 October / usah_oct97.iso / rfc / 800s / rfc855.txt < prev    next >
Text File  |  1992-04-06  |  6KB  |  170 lines
  1. Network Working Group                                          J. Postel
  2. Request for Comments: 855                                    J. Reynolds
  3.                                                                      ISI
  4. Obsoletes: NIC 18640                                            May 1983
  5.  
  6.                       TELNET OPTION SPECIFICATIONS
  7.  
  8.  
  9. This RFC specifies a standard for the ARPA Internet community.  Hosts on
  10. the ARPA Internet are expected to adopt and implement this standard.
  11.  
  12. The intent of providing for options in the TELNET Protocol is to permit
  13. hosts to obtain more elegant solutions to the problems of communication
  14. between dissimilar devices than is possible within the framework
  15. provided by the Network Virtual Terminal (NVT).  It should be possible
  16. for hosts to invent, test, or discard options at will.  Nevertheless, it
  17. is envisioned that options which prove to be generally useful will
  18. eventually be supported by many hosts; therefore it is desirable that
  19. options should be carefully documented and well publicized.  In
  20. addition, it is necessary to insure that a single option code is not
  21. used for several different options.
  22.  
  23. This document specifies a method of option code assignment and standards
  24. for documentation of options.  The individual responsible for assignment
  25. of option codes may waive the requirement for complete documentation for
  26. some cases of experimentation, but in general documentation will be
  27. required prior to code assignment.  Options will be publicized by
  28. publishing their documentation as RFCs; inventors of options may, of
  29. course, publicize them in other ways as well.
  30.  
  31.    Option codes will be assigned by:
  32.  
  33.       Jonathan B. Postel
  34.       University of Southern California
  35.       Information Sciences Institute (USC-ISI)
  36.       4676 Admiralty Way
  37.       Marina Del Rey, California 90291
  38.       (213) 822-1511
  39.  
  40.       Mailbox = POSTEL@USC-ISIF
  41.  
  42. Documentation of options should contain at least the following sections:
  43.  
  44.    Section 1 - Command Name and Option Code
  45.  
  46.    Section 2 - Command Meanings
  47.  
  48.       The meaning of each possible TELNET command relevant to this
  49.       option should be described.  Note that for complex options, where
  50.  
  51.  
  52.  
  53.  
  54. Postel & Reynolds                                               [Page 1]
  55.  
  56.  
  57.  
  58. RFC 855                                                         May 1983
  59.  
  60.  
  61.       "subnegotiation" is required, there may be a larger number of
  62.       possible commands.  The concept of "subnegotiation" is described
  63.       in more detail below.
  64.  
  65.    Section 3 - Default Specification
  66.  
  67.       The default assumptions for hosts which do not implement, or use,
  68.       the option must be described.
  69.  
  70.    Section 4 - Motivation
  71.  
  72.       A detailed explanation of the motivation for inventing a
  73.       particular option, or for choosing a particular form for the
  74.       option, is extremely helpful to those who are not faced (or don't
  75.       realize that they are faced) by the problem that the option is
  76.       designed to solve.
  77.  
  78.    Section 5 - Description (or Implementation Rules)
  79.  
  80.       Merely defining the command meanings and providing a statement of
  81.       motivation are not always sufficient to insure that two
  82.       implementations of an option will be able to communicate.
  83.       Therefore, a more complete description should be furnished in most
  84.       cases.  This description might take the form of text, a sample
  85.       implementation, hints to implementers, etc.
  86.  
  87. A Note on "Subnegotiation"
  88.  
  89.    Some options will require more information to be passed between hosts
  90.    than a single option code.  For example, any option which requires a
  91.    parameter is such a case.  The strategy to be used consists of two
  92.    steps:  first, both parties agree to "discuss" the parameter(s) and,
  93.    second, the "discussion" takes place.
  94.  
  95.    The first step, agreeing to discuss the parameters, takes place in
  96.    the normal manner; one party proposes use of the option by sending a
  97.    DO (or WILL) followed by the option code, and the other party accepts
  98.    by returning a WILL (or DO) followed by the option code.  Once both
  99.    parties have agreed to use the option, subnegotiation takes place by
  100.    using the command SB, followed by the option code, followed by the
  101.    parameter(s), followed by the command SE.  Each party is presumed to
  102.    be able to parse the parameter(s), since each has indicated that the
  103.    option is supported (via the initial exchange of WILL and DO).  On
  104.    the other hand, the receiver may locate the end of a parameter string
  105.    by searching for the SE command (i.e., the string IAC SE), even if
  106.    the receiver is unable to parse the parameters.  Of course, either
  107.    party may refuse to pursue further subnegotiation at any time by
  108.    sending a WON'T or DON'T to the other party.
  109.  
  110.  
  111. Postel & Reynolds                                               [Page 2]
  112.  
  113.  
  114.  
  115. RFC 855                                                         May 1983
  116.  
  117.  
  118.    Thus, for option "ABC", which requires subnegotiation, the formats of
  119.    the TELNET commands are:
  120.  
  121.       IAC WILL ABC
  122.  
  123.          Offer to use option ABC (or favorable acknowledgment of other
  124.          party's request)
  125.  
  126.       IAC DO ABC
  127.  
  128.          Request for other party to use option ABC (or favorable
  129.          acknowledgment of other party's offer)
  130.  
  131.       IAC SB ABC <parameters> IAC SE
  132.  
  133.          One step of subnegotiation, used by either party.
  134.  
  135.    Designers of options requiring "subnegotiation" must take great care
  136.    to avoid unending loops in the subnegotiation process.  For example,
  137.    if each party can accept any value of a parameter, and both parties
  138.    suggest parameters with different values, then one is likely to have
  139.    an infinite oscillation of "acknowledgments" (where each receiver
  140.    believes it is only acknowledging the new proposals of the other).
  141.    Finally, if parameters in an option "subnegotiation" include a byte
  142.    with a value of 255, it is necessary to double this byte in
  143.    accordance the general TELNET rules.
  144.  
  145.  
  146.  
  147.  
  148.  
  149.  
  150.  
  151.  
  152.  
  153.  
  154.  
  155.  
  156.  
  157.  
  158.  
  159.  
  160.  
  161.  
  162.  
  163.  
  164.  
  165.  
  166.  
  167.  
  168. Postel & Reynolds                                               [Page 3]
  169.  
  170.