Telnet Option Specifications (RFC0855)
Original Publication Date: 1983-May-01
Included in the Prior Art Database: 2000-Sep-13
Internet Society Requests For Comment (RFCs)
J. Postel: AUTHOR [+2]
This RFC specifies a standard for the ARPA Internet community. Hosts on the ARPA Internet are expected to adopt and implement this standard.
Network Working Group J. Postel
Request for Comments: 855 J. Reynolds
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
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
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 t...