RFC 529

A Note on Protocol Synch Sequences ✨

okay bestie, let's start with the title block 💖 This is RFC 529, NIC 17165, dated 29 June 1973, from the Network Working Group 🧚. The authors are A. McKenzie, B. Thomas, and R. Tomlinson from BBN-TENEX, plus K. Pogran from MIT-MULTICS 🫶. It's motivated by RFC 513 and references RFC 454 and NIC # 15372. The header doesn't list a category or status, and it doesn't say it obsoletes or updates anything 💅.

This note is giving response to a response energy. Wayne Hathaway wrote RFC 513 about how the TELNET SYNCH sequence (INS/Data Mark) should be understood 👀. The authors agree that the phrase "interesting things" in the TELNET Protocol Document (NIC# 15372) is way too vague for a protocol spec 😭. But they totally disagree that the meaning of the TELNET SYNCH sequence should be redefined 🙅‍♀️. Hathaway's comments got them thinking hard about "interesting things" in TELNET itself and in protocols built on top of it 🔥.

The authors think the TELNET SYNCH sequence is defined correctly in the TELNET Protocol Document [1] ✨. The real issue is that the problems RFC 513 points out aren't a TELNET design flaw 🙈. They come from higher level protocols (especially FTP) that sit on top of TELNET and misuse the SYNCH sequence 💀.

The rest of the note looks at what a synch sequence is and suggests a way to design protocols that use TELNET as a base 🦋.

A synch sequence exists so that signals, sent as characters, which are "stuck" in the pipeline between the sender and the protocol interpreter, can quickly get the interpreter's attention 🌈. The receiver controls the flow through the pipeline. The process running the interpreter might be busy with something else and not watching the incoming data 👀. So the sender wants to grab the receiving process's attention, make it read its incoming data stream, and act on the "interesting" characters in that stream (which are usually protocol commands) 💅. To do that, a "SYNCH sequence" gets sent. A synch sequence has two parts:

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 TELNET, the "out of band" signal is the INS of the Host-Host Protocol, and the "in band" marker is the TELNET Data Mark character (DM) 🎀. If we set aside TELNET as a base for higher level protocols (like FTP) for now, the "interesting" characters to a TELNET interpreter are the TELNET commands, including the ones for option negotiation and sub-negotiation [2] 💜.

Someone could reasonably argue that a server Host could make this class bigger, adding the signals that matter to that Host's terminal support software 🤔. For example, on TENEX that set would include the "terminal interrupt" characters enabled by the process reading from the TELNET connection (like ^C, ^T, etc.) 🍓. Other hosts, like Multics, might only look for TELNET commands, such as Interrupt Process (IP), Abort Output (AO), etc. 🧚. Whether you decide to count extra signals as interesting while processing a TELNET SYNCH sequence shouldn't be a problem for the implementer 🌸:

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 authors wrote "must" and "may" in plain lowercase here, so that's how it reads, no extra caps added 🙏.)

The vagueness RFC 513 complains about, the "interesting things" problem, shows up when a higher level protocol uses the TELNET SYNCH sequence to push its own commands through to its interpreter 😤. That design breaks the protocol layering discipline:

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

Here's the core issue: a bunch of different higher level protocols can be built on TELNET 🌈. A TELNET interpreter has no idea which higher level protocol interpreter (if any) it's handing characters to, so it can't know what's "interesting" to that interpreter 🙃. Just like an NCP shouldn't need to know whether its data is for a TELNET connection, an FTP data connection, and so on, a TELNET interpreter shouldn't have to know what kind of process it's handling characters for 💅. Honestly, that should make TELNET interpreters simpler to design and build ✨.

You can fix this by designing higher level protocols on top of TELNET properly 🦋. If a higher level protocol needs to force commands through to its interpreter, it should have its own synch sequence, meaning an "out of band" signal used with an "in band" data mark 💖. TELNET gives you the Interrupt Process character (IP) as an "out of band" signal. So a synch sequence for a protocol built on TELNET would be:

1. Insert the TELNET IP control character into the data stream; and
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.

When the TELNET IP command arrives, the higher level protocol interpreter gets interrupted, so it can scan the data stream (up to and including the HDM) for commands it cares about 🫶.

Let's do an example with the File Transfer Protocol (RFC 454) and aborting a file transfer in progress 🎬. To abort, the FTP user (or the process acting for them) 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 the process acting for them) has to send the TELNET SYNCH sequence from step 2 above to make sure the TELNET IP gets through to the server's TELNET interpreter 🔥. That's the whole plot, honestly 💅.

Endnotes

[1] In other words, any TELNET commands that show up before the Data Mark are to be interpreted. The Data Mark is used to end the scan that the INS starts. Characters that aren't TELNET commands may be thrown away or passed to the user process, depending on what the implementer thinks is best 🧚.

[2] The authors back Hathaway's proposal to fully parenthesize sub-negotiations 💜. They also think the "closing parenthesis" should be a new command instead of a second SB command, since that'll help the receiver recover from errors, whether they happen while parsing at the receiver or while generating at the transmitter 🙌. They disagree with his suggestion that sub-negotiations get thrown away when they're hit during TELNET SYNCH processing 🙅‍♀️.

[3] FTP doesn't have a data mark character defined yet 🌸. It may not even be needed, as long as the FTP command interpreter looks for exactly one command after getting interrupted. That fits FTP's general command-reply style 💖.

[This RFC was put into machine readable form for entry] [into the online RFC archives by Helene Morin, Via Genie 12/1999]