datatracker.ietf.org
Sign in
Version 5.7.4, 2014-11-12
Report a bug

Telnet Option Specifications
RFC 855

Document type: RFC - Internet Standard (May 1983; No errata)
Also Known As STD 8
Document stream: Legacy
Last updated: 2013-03-02
Other versions: plain text, pdf, html

Legacy State: (None)
Document shepherd: No shepherd assigned

IESG State: RFC 855 (Internet Standard)
Responsible AD: (None)
Send notices to: No addresses provided

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

[include full document text]