Telnet terminal-type option

The cycling-through-types mechanism was introduced to allow a server to present a list of preferred terminal types and select among them, addressing the limitation in prior Telnet mechanisms where multiple names were assumed to be synonyms and the list could only be scanned once.

The specification is deliberately asymmetric: only the server initiates SEND requests and only the client responds with IS. This reflects the assumption that server operating systems and applications cannot change terminal types at arbitrary points in a session, whereas clients (workstations with multiple emulation modes) can.

RFC 930-conformant servers cease sending SEND commands after receiving the same IS response twice, which is compatible with the new cycling behavior. RFC 930-conformant clients will repeat the last type on a third query, so new-style servers must recognize this and stop sending further SEND requests.

There is no negative acknowledgement for an unrecognized terminal type name. However, other options such as BINARY mode may be refused if a valid terminal type name has not been established, creating an indirect dependency.

Clients supporting multiple emulation modes SHOULD allow the user to specify which mode is preferred (sent first) prior to connection establishment. The order of names sent cannot be changed after negotiation begins.

Only the server may send TERMINAL-TYPE SEND requests, and only the client may transmit actual type information via IAC SB TERMINAL-TYPE IS ... IAC SE. The roles are strictly asymmetric.

Servers SHOULD store the current terminal type name and the list of available names in a manner accessible to both the user (via keyboard command) and any applications that need the information, and SHOULD provide a mechanism to request a type change.

Terminal type information MUST NOT be sent spontaneously; it may only be transmitted by the client in response to an explicit IAC SB TERMINAL-TYPE SEND IAC SE request from the server.

Terminal type names SHOULD conform to the list in the Assigned Numbers RFC to minimize confusion from alternative spellings (e.g., "IBM3278-2" vs. "IBM-3278/2"). The authoritative and up-to-date list is maintained in Assigned Numbers.

The type name "UNKNOWN" SHOULD be used if the terminal type is unknown or unlikely to be recognized by the remote party.

When a client supports multiple terminal types that are synonyms, they SHOULD be sent in order from most to least specific, so the server can select the most precise match.

When the client receives a TERMINAL-TYPE SEND, it MUST respond with its next available terminal type name and simultaneously switch emulation mode to match, unless the new type is a synonym of the preceding type or has unmet prerequisites (e.g., BINARY option).

After the server detects end-of-list (same response twice), it may send one additional SEND to request the client wrap around and return to the first (most-preferred) terminal type, effectively cycling through the list.

Default state for both sides is WON'T TERMINAL-TYPE / DON'T TERMINAL-TYPE, meaning terminal type information will not be exchanged unless both parties explicitly negotiate otherwise.

End-of-list is signaled by the client repeating the last terminal type name in response to a subsequent SEND. When the server receives the same IS response two consecutive times, it knows the full list has been exhausted.

Terminal type names are NVT ASCII strings in which upper and lower case are considered equivalent. The maximum length of a terminal type name is 40 characters.

The TERMINAL-TYPE Telnet option is assigned option code 24. It is negotiated via standard Telnet WILL/WON'T/DO/DON'T commands before any subcommand exchange.

The SEND subcommand is encoded as IAC SB TERMINAL-TYPE SEND IAC SE where SEND=1. The IS subcommand is encoded as IAC SB TERMINAL-TYPE IS <name> IAC SE where IS=0 and <name> is an NVT ASCII string.