Dismiss
The IQ application will be briefly unavailable on Sunday, March 31st, starting at 10:00am ET. Access will be restored as quickly as possible.
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: 2019-Feb-11
Document File: 10 page(s) / 14K

Publishing Venue

Internet Society Requests For Comment (RFCs)

Related People

D.J. Bernstein: AUTHOR

Related Documents

10.17487/RFC1143: DOI

Abstract

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 text was extracted from a PDF file.
This is the abbreviated version, containing approximately 16% 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

Bernstein [Page 1]

RFC 1143 Q Method February 1990

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 with the words after the slash.

An implementor should be able to determine whether or not an implementation complies with this RFC without reading any text marked DISCUSSION. An implementor should be able to implement option negotiation machinery compliant with both this RFC and RFC ...

Processing...
Loading...