Note on protocol synch sequences
RFC 529

Document Type RFC - Unknown (June 1973; No errata)
Last updated 2013-03-02
Stream Legacy
Formats plain text html pdf htmlized bibtex
Stream Legacy state (None)
Consensus Boilerplate Unknown
RFC Editor Note (None)
IESG IESG state RFC 529 (Unknown)
Telechat date
Responsible AD (None)
Send notices to (None)
Network Working Group                                        A. McKenzie
Request for Comments: 529                                      B. Thomas
NIC: 17165                                                  R. Tomlinson
References: RFCs 454, 513,                                     BBN-TENEX
            NIC # 15372                                        K. Pogran
                                                            29 June 1973

                   A Note on Protocol Synch Sequences

   This note is motivated by Wayne Hathaway's RFC 513 which comments on
   the interpretation of the TELNET SYNCH sequence (INS/Data Mark).  We
   agree with Wayne's observation that the phrase "interesting things",
   as it appears and is explained in the TELNET Protocol Document (NIC#
   15372), is much too imprecise to appear in a protocol specification.
   However, we disagree with his proposal that the interpretation of the
   TELNET SYNCH sequence should be redefined.  Hathaway's comments led
   us to examine the notion of "interesting things" with respect both to
   TELNET protocol and to protocols built upon it.

   We feel that the definition of the TELNET SYNCH sequence in the
   TELNET Protocol Document is the proper one [1].  More important, we
   feel that the (potential) difficulties with respect to the TELNET
   SYNCH sequence noted in RFC 513 are not the reflection of a TELNET
   design flaw but rather reflect misuse of the TELNET SYNCH sequence by
   "higher level" protocols (in particular FTP) that are based on

   The remainder of this note examines the notion of a synch sequence
   and suggests an approach to the design of protocols which are to use
   the TELNET protocol as a basis.

   The reason for defining a synch sequence for a protocol is to provide
   a mechanism by which signals, represented as characters, that for one
   reason or another are "stuck" in the pipeline between the sender and
   the protocol interpreter, can promptly be brought to the attention of
   the interpreter.  Flow through the pipeline is, of course, controlled
   by the receiver; the process operating the interpreter may be doing
   something else at the moment, and may not be paying attention to the
   incoming data stream.  The sender would like to get the attention of
   the receiving process, to have it read its incoming data stream and
   take action as directed by the "interesting" characters in that
   stream, which will, in general, be protocol commands.  To accomplish
   this, a "SYNCH sequence" is transmitted.  A synch sequence consists

McKenzie, et. al.                                               [Page 1]
RFC 529            A Note on Protocol Synch Sequences       29 June 1973

      1. An "out of band" signal which serves to get the attention of
         the protocol interpreter; and

      2. An "in band" marker which serves to mark how much of the data
         stream is to be processed by the protocol interpreter in
         response to the "out of band" signal.

   For the TELNET protocol the "out of band" signal is the INS of Host-
   Host Protocol and the "in band" marker is the TELNET Data Mark
   character (DM).  Ignoring for the moment the use of TELNET as a basis
   for higher level protocols (such as FTP), the class of characters
   "interesting" to a TELNET interpreter is the set of TELNET commands
   (including the commands for option negotiation and sub-negotiation

   One might reasonably argue that this class could be enlarged by a
   server Host to include the set of signals of interest to the terminal
   support software of that particular Host.  For example, in case of
   TENEX such a set would include the "terminal interrupt" characters
   enabled by the process reading from the TELNET connection (e.g., ^C,
   ^T, etc.).  Other hosts, such as Multics, might look only for the
   TELNET commands, such as Interrupt Process (IP), Abort Output (AO),
   etc.  Whether or not one chooses to consider additional signals as
   interesting during the processing of a TELNET SYNCH sequence should
   cause the implementer no problem:

      He must treat all TELNET commands as interesting by interpreting
      them.  He may choose either to ignore such additional signals or
      to pass them on to the process; in either case there is no
      vagueness since the implementer knows which characters his
      terminal support software considers interesting.

   The difficulty noted in RFC 513 concerning the vagueness of
   "interesting things" occurs when a higher level protocol makes use of
   the TELNET SYNCH sequence to force commands of interest to it through
   to its interpreter.  A higher level protocol designed in such a way
   represents a violation of the protocol layering discipline:

      The TELNET SYNCH mechanism is being misused by attempting to give
      it meaning at two different levels of protocol.
Show full document text