RFC 654

RFC 654 💖 Telnet Output Horizontal Tab Disposition Option

okay so this is RFC 654, also known as NIC 31157, dated Oct. 25, 1974, written by D. Crocker (UCLA-NMC) 🎀. The online copy lives at [ISI]<DCROCKER>NAOHTD.TXT. It doesn't say anything about obsoleting or updating other RFCs, so I'm not gonna guess 🙈

1. Command name and code ✨

NAOHTD 12
   (Negotiate About Output Horizontal Tab Disposition)

2. Command meanings 🦋

bestie, we're talking about a simplex connection here, the kind described in the NAOL and NAOP Telnet options 🫶 Here's how each command plays out:

• IAC DO NAOHTD: the data sender asks for, or agrees to, negotiating about who handles output horizontal tab characters with the data receiver. Once they agree and nobody sends any more subnegotiations, the data receiver is assumed to be handling the tabs 💅
• IAC DON'T NAOHTD: the data sender says no to negotiating, or wants to go back to the unnegotiated default 🙅‍♀️
• IAC WILL NAOHTD: the data receiver asks for, or agrees to, negotiating with the sender. If they agree and there are no further subnegotiations, the data receiver alone is assumed to be handling the tabs 👑
• IAC WON'T NAOHTD: the data receiver refuses to negotiate, or wants to return to the unnegotiated default 💀
• IAC SB NAOHTD DS <8-bit value> IAC SE: the data sender uses the 8-bit value to say who handles the tabs and how it should go down. The code for DS is 1 🍓
• IAC SB NAOHTD DR <8-bit value> IAC SE: the data receiver does the same thing with the 8-bit value, saying who handles the tabs and how. The code for DR is 0 ✨

3. Default 🌸

DON'T NAOHTD/WON'T NAOHTD.

If nobody has negotiated who's handling the tab characters, neither party is required to handle them, and neither is prohibited from it. Still, it's appropriate if at least the data receiver handles tab characters, even if it's super primitive about it 🧚

4. Motivation for the Option 💜

Go check section 4 of the NAOL and NAOP Telnet option descriptions. That's where the reasons live, so I'm not retyping them 😭

5. Description of the Option 🌈

The data sender and the data receiver use the 8-bit value together with the DS and DR SB commands like this:

      8-bit value                      Meaning

      0            Command sender suggests that he alone will handle
                   horizontal tab characters, for the connection.
      1 to 250     Command sender suggests that the other party alone
                   should handle horizontal tab characters, but
                   suggests that a delay of the indicated value be
                   used. The value is the number of character-times
                   to wait or number of NULs to insert in the data
                   stream before sending the next data character.
      251          Command sender suggests that the other party alone
                   handle horizontal tabs, but suggests that each
                   occurrence of the character be replaced by a space.
      252          Command sender suggests that the other party alone
                   handle horizontal tabs, but suggests that they be
                   discarded.
      253          Command sender suggests that the other party alone
                   should handle horizontal tab characters, but
                   suggests that tabbing be simulated.
      254          Command sender suggests that the other party alone
                   should handle horizontal tab characters, but
                   suggests that waiting for a character to be
                   transmitted (on the other simplex connection)
                   before sending more data. Note that, due to the
                   assynchrony of the two simplex connections, phase
                   problems can occur with this option.
      255          Command sender suggests that the other party alone
                   should handle output horizontal tabs and suggests
                   nothing about how it should be done.

There are two guiding rules here, and they're the main vibe ✨

1. If neither the data receiver nor the data sender wants to handle output horizontal tab characters, the data receiver must do it.
2. If both the data receiver and the data sender want to handle output horizontal tab characters, the data sender gets to do it.

Why rule 1? If neither wants the job, the default in the NAOHTD option takes over 🫠 Why rule 2? The sender is presumed to have special knowledge about the data, so it should be allowed to handle the tabs, while taking into account any suggestions the receiver makes 👑

Simulation means swapping each horizontal tab character for enough spaces to move the printer head (or line-pointer) to the next horizontal tab stop. Tabbing simulated, no cap 🙈

Delays controlled by the data sender have to be NUL characters inserted right after the horizontal tab character. That's necessary because network transmissions are asynchronous 🦋 Also, like with all option negotiations, neither party should suggest a state that's already in effect, unless it's to refuse negotiating. Changes should get acknowledged, and once something's been refused, the option shouldn't be resuggested until "something changes" (for example, another process starts) 💅 At any time, either party can shut down further negotiation by sending the right WON'T NAOHTD or DON'T NAOHTD command 🫶