RFC 653 HISTORIC TELNET · FORMATTING

Telnet output horizontal tabstops option

Negotiating horizontal tab stops on a Telnet connection.

On rfc-editor.org ↗
PUBLISHED
October 1974
AUTHORS
D. Crocker
STREAM
Legacy
OPTION CODE
11
SUBNEGOTIATION CODES
DS = 1 (sender), DR = 0 (receiver)
TAB STOP VALUE RANGE
1 to 250 (column numbers)
DOI
10.17487/RFC0653

RFC text

Contents
Original text · RFC Editor View on rfc-editor.org ↗
TELNET OUTPUT HORIZONTAL TABSTOPS OPTION
RFC 653, NIC 31156 (Oct. 25, 1974)
D. Crocker (UCLA-NMC)
Online file: [ISI]<DCROCKER>NAOHTS.TXT

               TELNET OUTPUT HORIZONTAL TABSTOPS OPTION

1. Command name and code
   NAOHTS 11 (Negotiate About Output Horizontal Tabstops)

2. Command meanings
   In the following, we are discussing a simplex connection, as described in
   the NAOL and NAOP Telnet options.
      IAC DO NAOHTS
         The data sender requests or agrees to negotiate about output
         horizontal tabstops with the data receiver.  In the case where
         agreement has been reached and in the absence of further
         subnegotiations, the data receiver is assumed to be handling output
         horizontal tabstops.
      IAC DON'T NAOHTS
         The data sender refuses to negotiate about output horizontal tabstops
         with the data receiver, or demands a return to the unnegotiated
         default mode.
      IAC WILL NAOHTS
         The data receiver requests or agrees to negotiate about output
         horizontal tabstops with the sender.  In the case where agreement has
         been reached and in the absence of 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.
      IAC SB NAOHTS DS <8-bit value> ... <8-bit value> IAC SE
         The data sender specifies, with the 8-bit value(s), 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 specifies, with the 8-bit value(s), which party
         should handle output horizontal tabstop considerations and what the
         stops should be.  The code for DR is 0.

3. Default
   DON'T NAOHTS/WON'T NAOHTS.
      In the default absence of negotiations concerning which party, data
      sender or data receiver, is handling output horizontal tabstops, neither
      party is required to handle them and neither party is prohibited from
      handling them; but it is appropriate if at least the data receiver
      handles horizontal tabstops, albeit primitively.

4. Motivation for the Option
   Please refer to section 4 of the NAOL and of the NAOP Telnet option
   descriptions.

5. Description of the Option
   The data sender and the data receiver use the 8-bit value(s) along with the
   DS and DR SB subcommands as follows (multiple 8-bit values are allowed only
   if each 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.

   The guiding rules are that:
      (1) if neither data receiver nor data sender wants to handle output
      horizontal tabstops, the data receiver must do it, and
      (2) if both data receiver and data sender want to handle output
      horizontal tabstops, the data sender gets to do it.
   The reasoning for the former rule is that if neither wants to do it, then
   the default in the NAOHTS option dominates. If both want to do it, the
   sender, who is presumed to have special knowledge about the data, should be
   allowed to do it, taking into account any suggestions the receiver may make.
   As with all option negotiations, neither party should suggest a state
   already in effect except to refuse to negotiate; changes should be
   acknowledged; and once refused, an option should not be resuggested until
   "something changes" (e.g., another process starts).
   At any time, either party can disable further negotiation by giving the
   appropriate WON'T NAOHTS or DON'T NAOHTS command.

AI ELI5

On this page
PROBLEMWhen a remote system sends text over Telnet with tab characters, the two sides need to agree on where the tab stops are (the column positions where a tab should land).
MECHANISMThis option defines commands that let the sender and receiver negotiate: either party can propose who should handle tabs and what the stop positions should be. They exchange messages with stop position values and reach agreement.
HISTORICBoth sides know which party controls tab stops and where they are set. The RFC is Historic and no longer used; modern systems use fixed tab widths or ignore tabs.

§1The Telnet Tab Stop Negotiation Option

RFC 653 defines the NAOHTS option (Negotiate About Output Horizontal Tabstops), a Telnet option for handling tab stops on output. Telnet is a protocol for remote terminal access where one computer sends text to another. When that text contains a tab character (a control character that jumps the cursor), both computers need to know where the tab stops are—the column numbers where the cursor lands.

Before this option was negotiated, systems had no standard way to agree on tab positions. This RFC solves that by letting the two sides exchange messages about which party controls tab stops and what positions to use.

Old terminals jump the cursor to set columns when they see a Tab. This option lets two computers agree on which columns those are.

§2How the Negotiation Works

The negotiation uses the standard Telnet option protocol. One side sends IAC DO NAOHTS (asking to negotiate), and the other replies with IAC WILL NAOHTS (agreeing) or IAC WON'T NAOHTS (refusing). After agreement, the sides use IAC SB (subnegotiation) messages to exchange details. The data sender uses DS (code 1) and the data receiver uses DR (code 0) to specify what it wants: zero means "I will handle it"; values 1 to 250 specify tab stop column numbers; 255 means "you handle it and decide the stops yourself."

The guiding rule is simple: if both sides want to handle tabs, the sender wins (because the sender knows the data format). If neither wants to, the receiver must do it.

The two computers say "do you want to handle this?" "Yes." Then they say "here are the stop positions" with numbers. They pick who handles it by a simple rule: if both want to, the sender wins.

§3Using the Option

Once negotiated, the chosen party (sender or receiver) understands where the tab stops are on the other end. When a tab character arrives, the receiver applies it correctly: the cursor jumps to the next column in the list of stops provided during negotiation. The two sides can also propose different arrangements at any time, allowing them to adapt if terminal settings change or a new process starts.

After agreement, when a Tab arrives, the receiver jumps the cursor to the right column. Either side can change the agreement later if something changes.

§4References