RFC 653

Telnet output horizontal tabstops option

πŸ“… published October 1974, from ietf

TELNET OUTPUT HORIZONTAL TABSTOPS OPTION πŸŽ€

okay bestie, this is RFC 653 (NIC 31156), dated Oct. 25, 1974, written by D. Crocker (UCLA-NMC) πŸ’– It's a Telnet option all about who handles output horizontal tabstops, and the online copy lives at [ISI]<DCROCKER>NAOHTS.TXT πŸ¦‹

1. Command name and code ✨

the option is NAOHTS 11 (Negotiate About Output Horizontal Tabstops) πŸ’… that's the whole ID, no cap 🌸

2. Command meanings πŸ’œ

okay so first, we're talking about a simplex connection, the same setup the NAOL and NAOP Telnet options describe 🫢 here's what each command means:

  • IAC DO NAOHTS πŸ”₯ the data sender asks to negotiate about output horizontal tabstops with the data receiver, or says yes to negotiating. if they actually agree and nobody sends more subnegotiations, the data receiver is assumed to be handling output horizontal tabstops. literally iconic πŸ‘‘
  • IAC DON'T NAOHTS πŸ™ˆ the data sender refuses to negotiate about output horizontal tabstops with the data receiver, or it demands a return to the unnegotiated default mode. not me being rejected πŸ’€
  • IAC WILL NAOHTS ✨ the data receiver asks to negotiate, or agrees to. if they agree and there are no further subnegotiations, the data receiver alone is assumed to be handling output horizontal tabstops 🧚
  • IAC WON'T NAOHTS 😭 the data receiver refuses to negotiate about output horizontal tabstops, or demands a return to the unnegotiated default mode. periodt πŸ’…
  • IAC SB NAOHTS DS <8-bit value> ... <8-bit value> IAC SE 🌈 the data sender uses the 8-bit value(s) to say which party should handle output horizontal tabstop considerations and what the stops should be. the code for DS is 1 πŸ“
  • IAC SB NAOHTS DR <8-bit value> ... <8-bit value> IAC SE πŸ¦‹ the data receiver uses the 8-bit value(s) to say which party should handle output horizontal tabstop considerations and what the stops should be. the code for DR is 0 πŸ’–

3. Default 🌸

the default is DON'T NAOHTS/WON'T NAOHTS πŸŽ€ so if nobody's negotiated who's handling output horizontal tabstops, neither party is required to handle them, and neither party is prohibited from handling them. but it's appropriate if at least the data receiver handles horizontal tabstops, even if it's primitive about it 🫢

4. Motivation for the Option 🧚

for the why, check out section 4 of the NAOL and NAOP Telnet option descriptions πŸ“š the reasoning is over there, bestie πŸ’œ

5. Description of the Option πŸ‘‘

the data sender and data receiver use the 8-bit value(s) together with the DS and DR SB subcommands like this. 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
             tabstops, for the connection.
1 to 250     Command sender suggests that the other party alone
             should handle tabstop considerations, but suggests
             that the indicated value(s) be used. The value(s)
             are the column numbers, relative to the physical
             left side of the printer page or terminal screen,
             that are to be set.
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 tabstops and suggests nothing
             about how it should be done.

okay the guiding rules are:

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

the reasoning for rule (1) is that if neither wants to do it, the default in the NAOHTS option wins πŸ™„ and for rule (2), the sender is presumed to have special knowledge about the data, so they should be allowed to do it, while still taking into account any suggestions the receiver makes 🫢

same as with all option negotiations: 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 suggested again until "something changes" (for example, another process starts) πŸ’…

and at any time, either party can turn off further negotiation by sending the appropriate WON'T NAOHTS or DON'T NAOHTS command 🌈 that's the tea, bestie ✨

πŸ“¦ where this page comes from