Comments on the new Telnet specifications
RFC 513

Document Type RFC - Unknown (May 1973; No errata)
Last updated 2013-03-02
Stream Legacy
Formats plain text pdf html bibtex
Stream Legacy state (None)
Consensus Boilerplate Unknown
RFC Editor Note (None)
IESG IESG state RFC 513 (Unknown)
Telechat date
Responsible AD (None)
Send notices to (None)
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                                                        [Page 1]
RFC 513        COMMENTS ON THE NEW TELNET SPECIFICATIONS        May 1973

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, contain only the DM
command itself.  The TELNET "synch" would thus be defined as "discard
all input up to and including the next DM command."  This change should
cause no problems with user-generated "interesting" things if they are
sent after the "synch" (as specified in the proposed new File Transfer
Protocol Specifications).  System-generated signals (such as option
requests) could be discarded, however, so some additional discussion is
in order.  If the recommendation that requests not be sent except when
something changes is followed, the spontaneous generation of
"interesting" things by TELNET itself (whatever that implies) would seem
to be rare, especially at the same time that users are generating
"synch's".  A more positive solution could be had by defining a "synch
response" (SR) TELNET command.  The SR command would be sent when the
INS and DM had both been processed (ie, when the "synch" had been
completely received).  If a process should ever receive an SR when it
has an option request outstanding, the request has been discarded and
must be repeated.  User processes which carry on option negotiations
would be the generators of any "synch's" so they can handle discarded
option requests as desired.  Note that this assumes that the TELNET
process itself will never generate a spontaneous "synch"; comments are
solicited on this.  Another possible solution would be to define a
"TIMING-MARK" TELNET command (see "TELNET Timing Mark Option", NIC #
16238), which would be sent immediately following the DM of a "synch".
The response to the TIMING-MARK (also to be defined) would mean the same
as the proposed SR command.

The final non-editorial comment concerns the need for some means of
specifying horizontal tab positions and use.  This is quite a nuisance
when dealing with systems which normally handle tabs for local
Show full document text