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.