RFC 513 (rfc513) - Page 2 of 3

Comments on the new Telnet specifications

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
terminals.  Perhaps this issue can be best handled with an appropriate
option; comments are solicited.

The only editorial comments are on the TELNET Protocol document, which I
reference below by page number.

On page 8 the parenthetical comment "(i.e., when a process at one end of
a TELNET connection is 'blocked on input')" should either be removed or
rewritten to avoid the (to me) incomprehensible phrase "blocked on
input."  If additional discussion is felt to be necessary, I would
propose "i.e., when a process at one end of a TELNET connection cannot
proceed without additional input)."  If examples are felt necessary, I
would propose "(e.g., in the state characterized by the Multics term
'blocked on input')."  The parallel could also be drawn between the GA
and the concept of a "read command" being issued to request more input.




Hathaway