RFC 656

RFC 656: TELNET OUTPUT VERTICAL TABSTOPS OPTION 🎀

okay bestie, this is the RFC that gives Telnet a way to negotiate vertical tabstops for output 🦋 it was written by D. Crocker (UCLA-NMC) and sits under NIC 31159, dated Oct. 25, 1974 🧚 the online copy is [ISI]<DCROCKER>NAOVTS.TXT. the original doesn't list a category, and it doesn't say what it obsoletes or updates, so I'm not guessing 🙈

---

1. Command name and code ✨

the option is NAOVTS 14 💖

NAOVTS 14
   (Negotiate About Vertcial Tabstops)

---

2. Command meanings 🌸

ok so this part is about a simplex connection, which is the one-way kind described in the NAOL and NAOP Telnet Options specs 📡 here's what each command means:

IAC DO NAOVTS
IAC DON'T NAOVTS
IAC WILL NAOVTS
IAC WON'T NAOVTS
IAC SB NAOVTS DS <8-bit value> ... <8-bit value> IAC SE
IAC SB NAOVTS DR <8-bit value> ... <8-bit value> IAC SE

IAC DO NAOVTS is the data sender asking to negotiate about output vertical tabstops with the data receiver, or agreeing to do it 💅 once they agree and nobody sends any more subnegotiations, the data receiver is assumed to be handling the tabstops 🎀

IAC DON'T NAOVTS is the data sender refusing to negotiate, or asking to go back to the unnegotiated default 🙅‍♀️

IAC WILL NAOVTS is the data receiver asking or agreeing to negotiate 🦋 same deal as above, but now the data receiver alone is assumed to be handling the tabstops once it's agreed and there are no more subnegotiations 👑

IAC WON'T NAOVTS is the data receiver refusing to negotiate, or wanting the unnegotiated default back 💀

IAC SB NAOVTS DS <8-bit value> ... <8-bit value> IAC SE is the data sender using those 8-bit values to say who should handle the tabstops and what the stops should be 🍓 the code for DS is 1 ✨

IAC SB NAOVTS DR <8-bit value> ... <8-bit value> IAC SE is the same thing but from the data receiver's side 🫶 the code for DR is 0 🌈

---

3. Default 🧚

this is the vibe when nobody has negotiated yet 🌙

DON'T NAOVTS/WON'T NAOVTS.

so, without any negotiation about who's handling the vertical tabstops, neither side is required to do it and neither side is prohibited from doing it 🫠 but it is appropriate if at least the data receiver handles them, albeit primitively 🥹

---

4. Motivation for the Option 📚

the reasons for this option are explained in section 4 of the NAOL and of the NAOVTS Telnet option descriptions, so go read those if you're curious 🤓

---

5. Description of the Option 💜

okay this is the main event 🔥 the data sender and the data receiver use the 8-bit value(s) along with the DS and DR SB commands. multiple 8-bit values are only allowed if each one is greater than zero and less than 251 ⭐

8-bit value                      Meaning

0            Command sender suggests that he alone will handle
             the vertical tabstops, for the connection.
1 to 250     Command sender suggests that the other party alone
             should handle the stops, but suggests that the
             indicated value(s) be used.  Each value is the line
             number, relative to the top of the printer page or
             terminal screen, that is to be set as a vertical
             tabstop.
251 to 254   Not allowed, in order to be compatible with
             related Telnet options.
255          Command sender suggests that the other party alone
             should handle output vertical tabstops and
             suggests nothing about how it should be done.

now the guiding rules 🎀 they're literally the tiebreakers:

1. if neither the data receiver nor the data sender wants to handle output vertical tabstops, the data receiver must do it, and
2. if both the data receiver and the data sender want to handle output vertical tabstops, the data sender gets to do it.

why rule 1? if nobody wants the job, the default in the NAOVTS option takes over 🧁 why rule 2? the sender is presumed to have special knowledge about the data, so they get to handle it, taking into account any suggestions from the receiver 🧠 this is needed because of the asynchrony of network transmissions 🌊

the same goes for every option negotiation: neither party should suggest a state that's already in effect, except to refuse to negotiate. changes should be acknowledged. and once something's been refused, the option shouldn't be resuggested until "something changes" (e.g., another process starts) 🙈

and at any time, either party can shut down further negotiation by sending the appropriate WON'T NAOVTS or DON'T NAOVTS command 🫶 that's the off switch, periodt 💅