Tech-invite3GPPspaceIETFspace
96959493929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 0728

Minor pitfall in the Telnet Protocol

Pages: 1
Unclassified

ToP   noToC   RFC0728 - Page 1
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.