Dismiss
IP.com applications will be updated on Sunday, March 5, from 11 am to 2 pm ET, to add new functionality and content. You may experience brief service interruptions during this period. We apologize for any inconvenience.
Browse Prior Art Database

Note on protocol synch sequences (RFC0529)

IP.com Disclosure Number: IPCOM000005391D
Original Publication Date: 1973-Jun-29
Included in the Prior Art Database: 2001-Sep-21
Document File: 5 page(s) / 9K

Publishing Venue

Internet Society Requests For Comment (RFCs)

Related People

A.M. McKenzie: AUTHOR [+4]

Abstract

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.

This text was extracted from a ASCII Text document.
This is the abbreviated version, containing approximately 38% of the total text.

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. [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 [2]).

One might reasonably argue that this class could be enlarged ...