Browse Prior Art Database

The Q Method of Implementing TELNET Option Negotiation (RFC1143)

IP.com Disclosure Number: IPCOM000001954D
Original Publication Date: 1990-Feb-01
Included in the Prior Art Database: 2000-Sep-12
Document File: 9 page(s) / 21K

Publishing Venue

Internet Society Requests For Comment (RFCs)

Related People

D.J. Bernstein: AUTHOR

Abstract

This RFC amplifies, supplements, and extends the RFC 854 [7] option negotiation rules and guidelines, which are insufficient to prevent all option negotiation loops. This RFC also presents an example of correct implementation.

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

Network Working Group D. Bernstein

Request for Comments: 1143 NYU

February 1990

The Q Method of Implementing TELNET Option Negotiation

Status of This Memo

This is RFC discusses an implementation approach to option

negotiation in the Telnet protocol (RFC 854). It does not propose

any changes to the TELNET protocol. Rather, it discusses the

implementation of the protocol of one feature, only. This is not a

protocol specification. This is an experimental method of

implementing a protocol. This memo is not a recommendation of the

Telnet Working Group of the Internet Engineering Task Force (IETF).

This RFC is Copyright 1990, Daniel J. Bernstein. However,

distribution of this memo in original form is unlimited.

1. Introduction

This RFC amplifies, supplements, and extends the RFC 854 [7] option

negotiation rules and guidelines, which are insufficient to prevent

all option negotiation loops. This RFC also presents an example of

correct implementation.

DISCUSSION:

The two items in this RFC of the most interest to implementors are

1. the examples of option negotiation loops given below; and 2. the

example of a TELNET state machine preventing loops.

1. Implementors of TELNET should read the examples of option

negotiation loops and beware that preventing such loops is a

nontrivial task.

2. Section 7 of this RFC shows by example a working method

of avoiding loops. It prescribes the state information that

you must keep about each side of each option; it shows what

to do in each state when you receive WILL/WONT/DO/DONT from

the network, and when the user or process requests that an

option be enabled or disabled. An implementor who uses the

procedures given in that example need not worry about

compliance with this RFC or with a large chunk of RFC 854.

In short, all implementors should be familiar with TELNET loops, and

some implementors may wish to use the pre-written example here in

writing a new TELNET implementation.

NOTE: Reading This Document

A TELNET implementation is not compliant with this RFC if it fails

to satisfy all rules marked MUST. It is compliant if it satisfies

all rules marked MUST. If it is compliant, it is unconditionally

compliant if it also satisfies all rules marked SHOULD and

conditionally compliant otherwise. Rules marked MAY are optional.

Options are in almost all cases negotiated separately for each

side of the connection. The option on one side is separate from

the option on the other side. In this document, "the" option

referred to by a DONT/WONT or DO/WILL is really two options,

combined only for semantic convenience. Each sentence could be

split into two, one with the words before the slash and one wit...