Dismiss
InnovationQ/InnovationQ Plus content will be updated on Sunday, June 25, 10am ET, with new patent and non-patent literature collections. Click here to learn more.
Browse Prior Art Database

Comments on the new Telnet specifications (RFC0513)

IP.com Disclosure Number: IPCOM000003641D
Original Publication Date: 1973-May-30
Included in the Prior Art Database: 2000-Sep-13
Document File: 3 page(s) / 8K

Publishing Venue

Internet Society Requests For Comment (RFCs)

Related People

W. Hathaway: AUTHOR

Abstract

I would like to make the following comments on the proposed new TELNET Protocol Specification (NIC # 15372) and TELNET Option Specification (NIC 15373). In general I feel the new TELNET protocol is far superior to the previous version. There are, however, a few items of substance which I feel should be changed, as well as some recommended editorial changes.

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

Network Working Group Wayne Hathaway

RFC # 513 AMES-67

NIC # 16444 30 May 1973

COMMENTS ON THE NEW TELNET SPECIFICATIONS

I would like to make the following comments on the proposed new TELNET

Protocol Specification (NIC # 15372) and TELNET Option Specification

(NIC 15373). In general I feel the new TELNET protocol is far superior

to the previous version. There are, however, a few items of substance

which I feel should be changed, as well as some recommended editorial

changes.

I feel the most significant error concerns the "Note on 'Sub-

negotiations'" section of the Option Specification (page 2). The

problem stems from the statements "Each party is presumed to be able to

parse the parameter(s)" and "Finally, if parameters in an option

'subnegotiation' include a byte with a value of 255, it is not necessary

to double this byte in accordance with the general TELNET IAC." These

two statements make the completely unwarranted but all too prevalent

assumption that there is only one "Telnet Interpreter" and that all

TELNET functions are carried out by it. In particular, problems arise

when a TELNET "synch" is received, and the receiving NCP is required to

scan the input looking for "interesting" things. If the subnegotiation

was in fact being carried out by a user process (and not the "TELNET

interpreter") then that user process is probably the only one that knows

how to interpret the SB parameters; the NCP itself would have no way of

parsing them. As a solution to this problem I propose that all

subnegotiation parameters be delimited at the end (perhaps with the same

TELNET command SB) and that they be required to obey all TELNET rules,

including doubling of IAC's. It may be argued that the user process

interpreting the SB itself should do the scanning for "interesting"

things, but I do not feel that this burden should be place on all user

processes.

The solution to the above problem is in fact fairly simple to define and

implement. The general problem, however, is one of not taking proper

cognizance of what I called "user processes" (processes which are not

network standards, but which are simply programs attempting to do work

using the network). I feel we must be more careful to shape all future

network standards with these very real user processes in mind if in fact

the network will ever be as useful as is possible.

The second item I object to is the incredibly loose definition of

"interesting" things (an aside: words which are so imprecise as to

require quotation marks should never appear in protocol specifications).

The specifications do define some of these "interesting" things (eg,

most TELNET commands) but they then include "and perhaps other

characters or character strings as well". To eliminate the difficulty

of implementing an undefined set of "interesting" things, I would

propose that the set of "interesting" things, cont...