Browse Prior Art Database

Telnet Option Specifications (RFC0855)

IP.com Disclosure Number: IPCOM000003902D
Original Publication Date: 1983-May-01
Included in the Prior Art Database: 2000-Sep-13
Document File: 3 page(s) / 6K

Publishing Venue

Internet Society Requests For Comment (RFCs)

Related People

J. Postel: AUTHOR [+2]

Abstract

This RFC specifies a standard for the ARPA Internet community. Hosts on the ARPA Internet are expected to adopt and implement this standard.

This text was extracted from a ASCII Text document.
This is the abbreviated version, containing approximately 51% of the total text.

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

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