Telnet terminal-type option
RFC 1091

Document Type RFC - Proposed Standard (February 1989; No errata)
Obsoletes RFC 930
Last updated 2013-03-02
Stream Legacy
Formats plain text html pdf htmlized bibtex
Stream Legacy state (None)
Consensus Boilerplate Unknown
RFC Editor Note (None)
IESG IESG state RFC 1091 (Proposed Standard)
Telechat date
Responsible AD (None)
Send notices to (None)
Network Working Group                                  J. VanBokkelen
Request for Comments: 1091                         FTP Software, Inc.
Obsoletes: RFC 930                                      February 1989

                      Telnet Terminal-Type Option

Status of This Memo

   This RFC specifies a standard for the Internet community.  Hosts on
   the Internet that exchange terminal type information within the
   Telnet protocol are expected to adopt and implement this standard.

   This standard supersedes RFC 930.  A change is made to permit cycling
   through a list of possible terminal types and selecting the most

   Distribution of this memo is unlimited.

1. Command Name and Code

      TERMINAL-TYPE   24

2. Command Meanings


         Sender is willing to send terminal type information in a
         subsequent sub-negotiation.


         Sender refuses to send terminal type information.


         Sender is willing to receive terminal type information in a
         subsequent sub-negotiation.


         Sender refuses to accept terminal type information.

VanBokkelen                                                     [Page 1]
RFC 1091              Telnet Terminal-Type Option          February 1989


         Server requests client to transmit his (the client's) next
         terminal type, and switch emulation modes (if more than one
         terminal type is supported).  The code for SEND is 1. (See


         Client is stating the name of his current (or only) terminal
         type.  The code for IS is 0.  (See below.)

3. Default


         Terminal type information will not be exchanged.


         Terminal type information will not be exchanged.

4. Motivation for the Option

   On most machines with bit-mapped displays (e.g., PCs and graphics
   workstations) a client terminal emulation program is used to simulate
   a conventional ASCII terminal.  Most of these programs have multiple
   emulation modes, frequently with widely varying characteristics.
   Likewise, modern host system software and applications can deal with
   a variety of terminal types.  What is needed is a means for the
   client to present a list of available terminal emulation modes to the
   server, from which the server can select the one it prefers (for
   arbitrary reasons).  There is also need for a mechanism to change
   emulation modes during the course of a session, perhaps according to
   the needs of applications programs.

   Existing terminal-type passing mechanisms within Telnet were not
   designed with multiple emulation modes in mind.  While multiple names
   are allowed, they are assumed to be synonyms.  Emulation mode changes
   are not defined, and the list of modes can only be scanned once.

   This document defines a simple extension to the existing mechanisms,
   which meets both of the above criteria.  It makes one assumption
   about the behaviour of implementations coded to the previous standard
   in order to obtain full backwards-compatibility.

VanBokkelen                                                     [Page 2]
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

   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

   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
Show full document text