RFC 860

RFC 860: TELNET TIMING MARK OPTION 🎀

Network Working Group 💅 Request for Comments: 860

Okay bestie, this one is from May 1983 🍓. It was written by J. Postel and J. Reynolds at ISI 🧚. It obsoletes NIC 16238 and doesn't list any updates. The whole thing specifies a standard for the ARPA community, and hosts on the ARPA Internet are expected to adopt and implement it ✨.

---

1. Command Name and Code 🦋

The command is called TIMING-MARK, and its code is 6 💖.

TIMING-MARK          6

---

2. Command Meanings 🌸

IAC DO TIMING-MARK 💌

The sender is basically asking the receiver to send back a WILL TIMING-MARK in the data stream at the "appropriate place" (we'll get to that in section 4, obsessed 🙈).

IAC WILL TIMING-MARK 🫶

This one is the sender promising the receiver that the mark gets inserted in the data stream at the "appropriate place," so the two sides stay in sync with a DO TIMING-MARK that the receiver sent. Iconic commitment 👑.

IAC WON'T TIMING-MARK 🙅‍♀️

The sender REFUSES to make sure this mark gets inserted in the data stream at the "appropriate place" for synchronization. Not me, not doing that 💀.

IAC DON'T TIMING-MARK 🌈

The sender is letting the receiver know that a WILL TIMING-MARK, which the receiver sent earlier, has been IGNORED 😭.

---

3. Default 💜

The default is WON'T TIMING-MARK, DON'T TIMING-MARK. Basically, nobody is making any explicit attempt to sync up what's happening at the two ends of the TELNET connection ✨.

---

4. Motivation for the Option 🧚

Sometimes it's super useful for a user or process on one end of a TELNET connection to know that the data they already sent has been totally processed, printed, discarded, or otherwise dealt with. This option is the mechanism for that 💅. Even if the DO TIMING-MARK request gets turned down with WON'T TIMING-MARK, the requester at least knows the refuser has received (even if not processed) all the previous data 🫶.

Here's a juicy example 🔥. Picture a TELNET connection between a physically full duplex terminal and a "full duplex" server system that lets the user "type ahead" while the server is still processing earlier input. Both sides agreed to Suppress Go Ahead, and the server agreed to provide echoes. Then the server finds a command it can't parse, maybe because of a typo 🙈. It wants to toss all of the user's "type-ahead," since one failed command could lead to wrong results if the later ones run, send the user an error message, and then pick back up with the commands the user typed after seeing that error message. If the user were local, the system could just discard the buffered input. But input can be buffered in the user's host or somewhere else, so the server might send a DO TIMING-MARK and hope to get a WILL TIMING-MARK back from the user at the "appropriate place" in the data stream 💖.

So, with no other info, the "appropriate place" is clearly right before the first character the user typed after seeing the error message. It should look like the timing mark was "printed" on the user's terminal, and the user responded by typing an answering timing mark 🌸.

Now say the user from that example realized they misspelled a command, figured out the server would send a DO TIMING-MARK, and wanted to start "typing ahead" again without waiting. They could tell their own system to send a WILL TIMING-MARK to the server and then keep typing ahead ✨. (Implementers should remember that the user's own system must remember it sent the WILL TIMING-MARK, so it can discard the DO/DON'T TIMING-MARK when that finally shows up 🧚.) In this case, the "appropriate place" for the WILL TIMING-MARK is the place the user defined 👑.

Also, in both examples, the system that sends the DO TIMING-MARK is the one responsible for discarding any unwanted characters. The WILL TIMING-MARK just helps decide which characters count as "unwanted" 💅.

---

5. Description of the Option 🦋

Say Process A in Figure 1 wants to sync up with B. A sends the DO TIMING-MARK to B. B can refuse by replying WON'T TIMING-MARK, or agree by letting the timing mark flow through its "outgoing" buffer, BUF2. Then, instead of delivering it to the terminal, B puts the mark into its "incoming" buffer, BUF1, so it flows back toward A. Once the mark has moved through B's incoming buffer, B sends WILL TIMING-MARK back to A over the TELNET connection 🌈.

PROCESS A    TELNETconnection    PROCESS B           Terminal
+-----------+                +---------------+ Timing+-------+
|           |WILL TIMING MARK|     BUF 1     |  Mark |       |
|           |<---------------|--|-|-|-|-|-|--|<------|       |
|           |                |  |-|-|-|-|-|  |   ^   |       |
|           |                |     BUF 2     |   ^   |       |
|           |--------------->|--|-|-|-|-|-|--|------>|       |
|           | DO TIMING MARK |  |-|-|-|-|-|  |       |       |
+-----------+                +---------------+       +-------+
                             (NVT process).ME;
                 Figure 1

When A gets the WILL TIMING-MARK, it knows that everything it sent to B before the timing mark has been delivered, and that everything B sent to A before the mark turned around has been delivered too 🫶.

Here are three typical applications 🎀:

A. Measure round-trip delay between a process and a terminal or another process. ⏱️

B. Resynchronizing an interaction, like we talked about in section 4 above 🔥. A is a process interpreting commands that B forwards from a terminal. When A sees an illegal command, it:

• i. Sends <carriage return>, <line feed>, <question mark>.
• ii. Sends DO TIMING-MARK.
• iii. Sends an error message.
• iv. Starts reading input and throwing it away until it receives a WILL TIMING-MARK.
• v. Resumes interpretation of input.

This flushes all the "type ahead" after the erroneous command, up to the point where the user actually saw the question mark 💖.

C. The dual of B above, where the terminal user wants to throw away unwanted output from A 💅.

• i. B sends DO TIMING-MARK, followed by some new command.
• ii. B starts reading output from A and throwing it away until it receives WILL TIMING-MARK.
• iii. B resumes forwarding A's output to the terminal.

This flushes all of A's output up to the point where A saw the timing mark, but not the output generated in response to the following command 🌸✨.