RFC 1091 (rfc1091) - Page 3 of 7
Telnet terminal-type option
Alternative Format: Original Text Document
RFC 1091 Telnet Terminal-Type Option February 1989
5. Description of the Option
Willingness to exchange terminal-type information is agreed upon via
conventional Telnet option negotiation. WILL and DO are used only to
obtain and grant permission for future discussion. The actual
exchange of status information occurs within option subcommands (IAC
SB TERMINAL-TYPE...).
Once the two hosts have exchanged a WILL and a DO, the sender of the
DO TERMINAL-TYPE (the server) is free to request type information.
Only the server may send requests (IAC SB TERMINAL-TYPE SEND IAC SE)
and only the client may transmit actual type information (within an
IAC SB TERMINAL-TYPE IS ... IAC SE command). Terminal type
information may not be sent spontaneously, but only in response to a
request.
The terminal type information is an NVT ASCII string. Within this
string, upper and lower case are considered equivalent. The complete
list of valid terminal type names can be found in the latest
"Assigned Numbers" RFC [4].
The transmission of terminal type information by the Telnet client in
response to a query from the Telnet server implies that the client
must simultaneously change emulation mode, unless the terminal type
sent is a synonym of the preceding terminal type, or there are other
prerequisites for entering the new regime (e.g., having agreed upon
the Telnet binary option). The receipt of such information by the
Telnet server does not imply any immediate change of processing.
However, the information may be passed to a process, which may alter
the data it sends to suit the particular characteristics of the
terminal. For example, some operating systems have a terminal driver
that accepts a code indicating the type of terminal being driven.
Using the TERMINAL TYPE and BINARY options, a telnet server program
on such a system could arrange to have terminals driven as if they
were directly connected, including special functions not available to
a standard Network Virtual Terminal.
Note that this specification is deliberately asymmetric. It is
assumed that server operating systems and applications in general
cannot change terminal types at arbitrary points in a session. Thus,
the client may only send a new type (and potentially change emulation
modes) when the server requests that it do so.
6. Implementation Issues
The "terminal type" information may be any NVT ASCII string
meaningful to both ends of the negotiation. The list of terminal
type names in "Assigned Numbers" is intended to minimize confusion
VanBokkelen