Browse Prior Art Database

Minor pitfall in the Telnet Protocol (RFC0728)

IP.com Disclosure Number: IPCOM000003774D
Original Publication Date: 1977-Apr-27
Included in the Prior Art Database: 2000-Sep-13
Document File: 1 page(s) / 2K

Publishing Venue

Internet Society Requests For Comment (RFCs)

Related People

J.D. Day: AUTHOR

Abstract

Designers of Telnet options should be aware of the following possible case in the Telnet protocol which may generate unexpected behavior on either end of the connection. Although at present none of the existing options are susceptible to this problem, it could arise in the future.

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

Network Working Group John Day

Request for Comments: 728 Apr 1977

NIC #40036

A Minor Pitfall in the Telnet Protocol

Designers of Telnet options should be aware of the following possible

case in the Telnet protocol which may generate unexpected behavior on

either end of the connection. Although at present none of the existing

options are susceptible to this problem, it could arise in the future.

The Telnet sync sequence causes all data to be deleted from the data

stream until a data mark is encountered. Telnet control functions are

not affected by the sync sequence (see page 9 of the protocol

specification). A Telnet option subnegotiation could be defined such

that it had an affect on the data following it in the data stream. For

example, a subnegotiation might be used to indicate the terminal was to

display the following data in a particular font or should receive other

special treatment by the terminal. A Telnet sync sequence sent after

such a subnegotiation and its data and before the subnegotiation had

been processed could resuit in the subnegotiation having its affect on

data other than that intended.

Two possible solutions come to mind at once. First, the data to be

affected could be included as a parameter of the subnegotiation. in

other words, the data is inserted in the data stream before the IAC SE

that terminates the subnegotiation. The disadvantages of this solution

are both theoretical and practical. Theoretically, it is improper and

not really in the spirit of the Telnet protocol design to send data as

subnegotiation parameters. Practically, in a situation where this case

would arise it would be equally unexpected behavior (and perhaps

confusing if a human was affected) if all data except that affected by

the subnegotiation was flushed.

The second solution would be for designers of options which have such

subnegotiations define a subnegotiation or other mechanism that would

follow immediately after the Data Mark and nullify the affects of any

offending subnegotiation. The exact semantics of such a subnegotiation

would probably be very specific to the option.