RFC 513 (rfc513) - Page 1 of 3

Comments on the new Telnet specifications

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,



Hathaway