Summary

  • Postel and Reynolds's May 1983 RFC 860 specified TELNET's Timing Mark option, code 6. A requester sent DO TIMING-MARK; a willing peer returned WILL TIMING-MARK at a meaningful point in its data stream after the mark had crossed the intervening buffers. The requester could then separate older buffered traffic from later input.
  • The sharp example was a malformed command followed by type-ahead. The server could discard input arriving after the error until the returned mark showed where keystrokes entered after the user saw the error. The system that requested the mark did the discarding, using the boundary supplied by its peer.

Picture a user typing a command, then carrying on before the computer has answered. The server finally discovers a mistake in the first command. It can print a question mark, but the keyboard has already sent its next opinion. Those later characters may be sitting in the terminal host, a network buffer or the server's own input queue. If the server blithely reads them as fresh instructions, one typo can recruit the next line as an accomplice. RFC 860 asked a wonderfully practical question: where, exactly, should the server stop throwing those characters away?

The answer was a mark that travelled through the conversation rather than a clock reading. The server sent IAC DO TIMING-MARK. The other end, if it agreed, placed IAC WILL TIMING-MARK in its returning stream at the appropriate point. The RFC's model made that placement physical in the logic of the connection: the mark passed through the remote end's outgoing buffer toward the terminal, then back through its incoming buffer toward the server. A willing answer told the requester that earlier traffic had crossed the turnaround point. The two hosts now had a line in the stream on which to hang a decision.

In the type-ahead example, the server first sent carriage return, line feed and a question mark, then the timing request and an error message. It read and discarded incoming characters until WILL TIMING-MARK arrived. Input after that mark could be interpreted again. The intended dividing line was the first character typed after the user saw the question mark. A terminal user who had been happily entering a second command before seeing the error would lose those premature characters; a correction typed after seeing it would survive. That is a more human definition of “new input” than whatever happened to be in the server's queue at the moment it noticed the typo.

The marker was a position in the stream. The RFC listed round-trip delay measurement as one possible use; the type-ahead problem required ordering. It let one party find out where the other party's buffered work had reached. DO requested placement, WILL assured it, and WON'T refused that assurance while confirming reception of preceding data. DON'T had a narrower bookkeeping role: it told a peer that an earlier WILL had been ignored. The default connection ran without explicit synchronization.

The wastebasket also had a named owner. RFC 860 put responsibility for discarding unwanted characters on the system sending DO TIMING-MARK. The peer provided a trustworthy dividing point when it could, then sent the mark back. The requester applied that boundary to its own queue. The same option could work in reverse. A terminal side tired of obsolete server output could request a mark, throw away output until WILL came back, and resume displaying output generated after its new command had reached the server. Either end could ask for a boundary; the asker decided what to drop.

Postel and Reynolds even allowed for an impatient typist who anticipated the server's request. The terminal side could send a WILL at a point chosen by the user, then start typing ahead again; its software would later have to swallow the arriving timing request and related response correctly. That special case shows how carefully the design treated the person's view of the exchange. “After the error” had a place in a two-way stream.

The broader TELNET specification provided the two-way connection, and the option rules provided the language of offers and refusals. RFC 860 gave one option a concrete job: rescuing a conversation whose buffered past was threatening to become its next command. The server could apologize for a typo. Timing Mark told it when the keyboard had actually heard the apology.