RFC 529 (rfc529) - Page 1 of 4


Note on protocol synch sequences



Alternative Format: Original Text Document



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
                                                             MIT-MULTICS
                                                            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
   TELNET.

   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
   of:





McKenzie, et. al.