Minor pitfall in the Telnet Protocol
A warning that Telnet synchronization can discard data needed by an option.
Day, J.D., "Minor pitfall in the Telnet Protocol", RFC 728, DOI 10.17487/RFC0728, April 1977, <https://www.rfc-editor.org/info/rfc728>.
@misc{rfc728,
series = {Request for Comments},
number = 728,
howpublished = {RFC 728},
publisher = {RFC Editor},
doi = {10.17487/RFC0728},
url = {https://www.rfc-editor.org/info/rfc728},
author = {J.D. Day},
title = {{Minor pitfall in the Telnet Protocol}},
pagetotal = 1,
year = 1977,
month = apr,
} RFC text
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.
ISO Plain Language
On this page
§1What Synchronization Discards
The Telnet sync sequence deletes data from the stream until a data mark is encountered. Telnet control functions are not affected by this sequence.
The memo says no existing Telnet options are susceptible at the time of writing, but a future option could have an effect on data that follows its subnegotiation.
During sync, Telnet discards data up to a special mark, but it keeps control functions. A future option might therefore remain active after its related data is discarded.
§2How an Option Could Affect the Wrong Data
If an option subnegotiation changes how following data is handled, and a sync discards that data before the subnegotiation is processed, the option's effect could apply to later data instead.
The memo gives an example of a subnegotiation requesting that later terminal text use a particular font or receive other special treatment.
An option could set a mode for data that sync then removes. The mode might remain and affect data that was not meant to use it.
§3Two Possible Design Responses
One possibility is to include the affected data as a parameter inside the subnegotiation. The RFC notes that this does not fit the Telnet design approach and could still cause confusing behavior if a sync occurs.
Another possibility is for an option to define a subnegotiation or other mechanism immediately after a data mark that cancels effects from an earlier subnegotiation. The exact behavior would depend on the option.
An option can carry its affected data inside its control message, or define a way to undo its effect after a data mark. Each option would need its own recovery behavior.