Telnet Option Specifications

　　Network Working Group J. Postel

　　Request for Comments: 855 J. Reynolds

　　ISI

　　Obsoletes: NIC 18640 May 1983

　　TELNETOPTION SPECIFICATIONS

　　This RFCspecifies 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　RFC855May 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.

　　RFC855May 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 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.