Minor pitfall in the Telnet Protocol
A warning about Telnet option interaction with the sync sequence.
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.
AI ELI5
On this page
§1The Sync Sequence Problem
RFC 728 warns designers of Telnet options about a subtle interaction with the Telnet sync sequence. The sync sequence is a recovery mechanism that discards all data from the stream until a data mark is encountered, allowing a receiver to resynchronize after errors. Telnet control functions and option negotiation are not affected by the sync sequence.
Telnet has a way to clean up when things go wrong: it throws away data until it finds a special marker.
§2The Interaction Pitfall
A problem could arise if a future Telnet option subnegotiation affects the data that follows it in the stream (for example, instructing the terminal to display subsequent text in a special font or with special formatting). If a sync sequence is sent after such a subnegotiation but before that subnegotiation's intended data is processed, the subnegotiation's effect could be applied to the wrong data—the data that remains after the sync sequence discards everything up to the data mark.
Imagine a command to change the terminal to a special mode, then a clean-up sequence that throws away data. The mode change might affect the wrong text.
§3Proposed Solutions
Two solutions are identified. The first is to include the data to be affected as a parameter of the subnegotiation itself, before the subnegotiation ends. The disadvantage is that this violates Telnet design philosophy and would be confusing if a sync happened midway through—the user would see unexpected data loss and formatting changes. The second solution is for option designers to define a recovery subnegotiation that follows immediately after a data mark to nullify any effects of subnegotiations that were lost or misapplied. The exact mechanism would be specific to each option.
Either send the data to protect as part of the mode command itself, or define a way to undo accidental mode changes after recovery.