From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc529.txt | 227 +++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 227 insertions(+) create mode 100644 doc/rfc/rfc529.txt (limited to 'doc/rfc/rfc529.txt') diff --git a/doc/rfc/rfc529.txt b/doc/rfc/rfc529.txt new file mode 100644 index 0000000..58347f7 --- /dev/null +++ b/doc/rfc/rfc529.txt @@ -0,0 +1,227 @@ + + + + + + +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 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. + + The problem stems from the fact that, in general, a (increasing) + number of different higher level protocols can be designed with + TELNET as a base. A TELNET interpreter has no way of knowing the + higher level protocol interpreter (if any) to which it is passing + characters, and therefore, can not tell which things are + "interesting" to the higher level protocol interpreter. That is, + just as an NCP should not have to know whether the data it handles is + + + +McKenzie, et. al. [Page 2] + +RFC 529 A Note on Protocol Synch Sequences 29 June 1973 + + + for a TELNET connection, an FTP data connection, etc., a TELNET + interpreter should not be required to know the kind of process for + which it is handling characters. This should, in fact, result in a + simplification of the design and implementation of TELNET protocol + interpreters. + + This difficulty can be resolved by proper design of protocols that + make use of TELNET as a base. In particular, if in such a higher + level protocol it is important to be able to force commands through + to the protocol interpreter, the higher level protocol should include + its own synch sequence: i.e., an "out of band" signal used with an + "in band" data mark. The TELNET protocol provides the Interrupt + Process character (IP) for use as an "out of band" signal. A synch + sequence for a protocol built upon TELNET would be: + + 1. Insert the TELNET IP control character into the data stream; + + 2. Insert the higher level protocol data mark character (HDM) into + the data stream following whatever higher level protocol + commands are important at the time. + + Receipt of the IP TELNET command causes the higher level protocol + interpreter to be interrupted, enabling it to scan the data stream + (up to and including the HDM) for commands it considers important. + + As an example, consider the case of the File Transfer Protocol (RFC + 454) and the problem of aborting a file transfer in progress. To + accomplish such an abort the FTP user (process) should: + + 1. Send the TELNET IP character; + + 2. Send the TELNET SYNC sequence, that is: + + a. Send the TELNET Data Mark (DM); + + b. Send the Host-Host Protocol INS; + + 3. Send the FTP ABOR command; and + + 4. Send the FTP data mark character [3]. + + The user (or process acting on his behalf) must transmit the TELNET + SYNCH sequence of step 2 above to ensure that the TELNET IP gets + through to the server's TELNET interpreter. + + + + + + + +McKenzie, et. al. [Page 3] + +RFC 529 A Note on Protocol Synch Sequences 29 June 1973 + + +Endnotes + + [1] I.e., any TELNET commands appearing before the Data Mark are to + be interpreted; the Data Mark is to be used to terminate the scan + initiated by the INS; characters that are not TELNET commands may be + discarded or passed to the user process as the implementer sees fit. + + [2] We support Hathaway's proposal to fully parenthesize sub- + negotiations. Further, we believe that the "closing parenthesis" + should be a new command rather than a second SB command; this will + aid the receiver in recovering from errors, either in parsing at the + receiver or in generation at the transmitter. We disagree with his + proposal that sub-negotiations be discarded when encountered during + processing of a TELNET SYNCH. + + [3] For FTP such a data mark character has not yet been defined and, + in fact, may not be necessary under the constraint that the FTP + command interpreter should look for exactly one command after being + interrupted; this is consistent with the general command-reply + orientation of FTP. + + + + [This RFC was put into machine readable form for entry] + [into the online RFC archives by Helene Morin, Via Genie 12/1999] + + + + + + + + + + + + + + + + + + + + + + + + + + +McKenzie, et. al. [Page 4] + -- cgit v1.2.3