RFC 657

RFC 657 ✨ Telnet Output Vertical Tab Disposition Option 🎀

Okay bestie, here's the paperwork: D. Crocker (UCLA-NMC) wrote this one, it's RFC 657, NIC 31160, and it's dated Oct. 25, 1974. The online copy lives at [ISI]<DCROCKER>NAOVTD.TXT. The document doesn't list a category, status, or anything it obsoletes or updates, so there's nothing else to note up here 💅

1. Command name and code 💖

The option is NAOVTD 15, which stands for Negotiate About Output Vertcial Tab Disposition 🦋

2. Command meanings 🌸

Heads up: everything in this section is about a simplex connection, the same kind the NAOL and NAOP Telnet Options specs describe 🫶

• IAC DO NAOVTD: The data sender asks for, or agrees to, negotiating about who handles output vertical tab characters with the data receiver. Once they agree and there are no more subnegotiations, the data receiver is assumed to be the one handling vertical tab considerations 🧚
• IAC DON'T NAOVTD: The data sender says no to negotiating about vertical tab disposition with the data receiver, or wants to go back to the unnegotiated default mode 🙈
• IAC WILL NAOVTD: The data receiver asks for, or agrees to, negotiating about vertical tab disposition with the sender. Once they agree and there are no more subnegotiations, the data receiver alone is assumed to be handling vertical tab considerations ✨
• IAC WON'T NAOVTD: The data receiver says no to negotiating about vertical tab disposition, or wants to go back to the unnegotiated default mode 💀
• IAC SB NAOVTD DS <8-bit value> IAC SE: The data sender uses the 8-bit value to say which party should handle vertical tab characters and how that should go. The code for DS is 1 🔥
• IAC SB NAOVTD DR <8-bit value> IAC SE: The data receiver uses the 8-bit value to say which party should handle vertical tab characters and how that should go. The code for DR is 0 👑

3. Default 🍓

When nobody has negotiated who's handling vertical tab characters (so DON'T NAOVTD or WON'T NAOVTD is in play), neither party is REQUIRED to handle them, and neither party is prohibited from handling them. Still, it's appropriate if at least the data receiver handles vertical tab considerations, even if it's kinda primitive about it 🌈

4. Motivation for the Option 🎀

Go check section 4 of the NAOL and of the NAOVTD Telnet option descriptions for the full backstory 📚

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, and the value means this:

8 bit value   Meaning

0             Command sender suggests that he alone will handle
              vertical tab characters, for the connection.
1 to 250      Command sender suggests that the other party alone
              should handle 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 vertical tabs, but suggests that each
          occurrence of the character be replaced by
          carriage-return/linefeed.
252           Command sender suggests that the other party alone
              handle vertical tabs, but suggests that they be discarded.
253           Command sender suggests that the other party alone
              should handle tab characters, but suggests that
          tabbing be simulated.
254           Command sender suggests that the other party alone
              should handle the output disposition but suggests
          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 the output disposition and suggests
              nothing about how it should be done.

The guiding rules are:

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

The reasoning behind the first rule: if neither side wants the job, the default in the NAOVTD option wins out 🧠. If both want it, the sender is presumed to have special knowledge about the data, so the sender SHOULD be allowed to do it, while taking into account any suggestions from the receiver 💅. Simulation means replacing the character with enough line-feeds (and only line-feeds) to move the paper, or line-pointer, to the next vertical tab stop 📄.

Delays that the data sender controls MUST consist of NUL characters, inserted right after the line-feed character. Why? Network transmissions are asynchronous, so this is the only way to keep things lined up 🫠. Like with every option negotiation, neither party SHOULD suggest a state that's already in effect, unless it's refusing to negotiate. Changes SHOULD be acknowledged, and once something's been refused, the option SHOULD NOT be resuggested until "something changes" (like another process starting) 🔁. At any time, either party can shut down further negotiation by sending the right WON'T NAOVTD or DON'T NAOVTD command 🛑