RFC0884: Telnet terminal type option

Download in PDF format Download in text format

Obsoleted By:  RFC0930

Network Working Group                                     Marvin Solomon
Request for Comments: 884                                 Edward Wimmers
                                       University of Wisconsin - Madison
                                                           December 1983

                      TELNET TERMINAL TYPE OPTION


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

1. Command Name and Code

   TERMINAL-TYPE    24

2. Command Meanings

   IAC WILL TERMINAL-TYPE

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

   IAC DO TERMINAL-TYPE

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

   IAC DON'T TERMINAL-TYPE

      Sender refuses to accept terminal type information

   IAC WON'T TERMINAL-TYPE

      Sender refuses to send terminal type information

   IAC SB TERMINAL-TYPE SEND IAC SE

      Sender requests receiver to transmit his (the receiver's) terminal
      type. The code for SEND is 1. (See below.)

   IAC SB TERMINAL-TYPE IS ... IAC SE

      Sender is stating the name of his terminal type. The code for IS
      is 0. (See below.)








Solomon & Wimmers                                               [Page 1]



RFC 884                                                    December 1983


3. Default

   DON'T TERMINAL-TYPE

   WON'T TERMINAL-TYPE

   Terminal type information will not be exchanged.

4. Motivation for the Option

   This option allows a telnet server to determine the type of terminal
   connected to a user telnet program.  The transmission of such
   information does not immediately imply any 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 such special functions as cursor
   addressing, multiple colors, etc., not included in the Network
   Virtual Terminal specification.  This option fits into the normal
   structure of TELNET options by deferring the actual transfer of
   status information to the SB command.

5. Description of the Option

   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
   WILL TERMINAL-TYPE is free to transmit type information, spontan-
   eously or in response to a request from the sender of the DO.  At
   worst, this may lead to transmitting the information twice. Only the
   sender of the DO may send requests (IAC SB TERMINAL-TYPE SEND IAC SE)
   and only the sender of the WILL may transmit actual type information
   (within an IAC SB TERMINAL-TYPE IS ... IAC SE command).

   The terminal type information is an NVT ASCII string.  Within this
   string, upper and lower case are considered equivalent.  A few
   terminal type names useful in the context of IBM systems are listed
   below.  It is anticipated that additional names will be added in the
   future.  The complete list of valid terminal types will be found in
   the latest "Assigned Numbers" RFC.





Solomon & Wimmers                                               [Page 2]



RFC 884                                                    December 1983


   The following is an example of use of the option:

      Host1: IAC DO TERMINAL-TYPE

      Host2: IAC WILL TERMINAL-TYPE

         (Host2 is now free to send status information at any time.
         Solicitations from Host1 are NOT necessary. This should not
         produce any dangerous race conditions. At worst, two IS's will
         be sent.)

      Host1 (perhaps): IAC SB TERMINAL-TYPE SEND IAC SE

      Host2:

         IAC SB TERMINAL-TYPE IS IBM-3278-2 IAC SE

6.  Implementation Suggestions

   The "terminal type" information may be any NVT ASCII string meaning-
   ful to both ends of the negotiation.  The list of suggestions below
   is intended to minimize confusion caused by alternative "spellings"
   of the terminal type.  For example, confusion would arise if one
   party were to call a terminal "IBM3278-2" while the other called it
   "IBM-3278/2".  There is no negative acknowledgement for a terminal
   type that is not understood, but certain other options (such as
   switching to BINARY mode) may be refused if a valid terminal type
   name has not been specified.  In some cases, a particular terminal
   may be known by more than one name, for example a specific type and a
   more generic type.  In such cases, the sender of the TERMINAL-TYPE IS
   command should reply to successive TERMINAL-TYPE SEND commands with
   the various names, from most to least specific.  In this way, a
   telnet server that does not understand the first response can prompt
   for alternatives.  However, it should cease sending TERMINAL-TYPE
   SEND commands after receiving the same response two consecutive
   times.  Similarly, a sender should indicate it has sent all available
   names by repeating the last one sent.

   Here are a few terminal types useful in the IBM environment:

      IBM-3275-2
      IBM-3276-2
      IBM-3276-3
      IBM-3276-4
      IBM-3277-2
      IBM-3278-2
      IBM-3278-3
      IBM-3278-4


Solomon & Wimmers                                               [Page 3]



RFC 884                                                    December 1983


      IBM-3278-5
      IBM-3279-2
      IBM-3279-3

   Here are a few terminal types useful in the TOPS20 environment:

      ANN-ARBOR-AMBASSADOR
      CONCEPT-100
      DATAMEDIA-2500
      DEC-LA30
      DEC-VT100
      DEC-VT52
      EXECUPORT-4000
      HAZELTINE-1500
      HP-2621
      HP-2640
      HP-2645A
      HP-2649
      NETWORK-VIRTUAL-TERMINAL
      TEKTRONIX-4025
      TELERAY-1061
      TELETYPE-33
      TELETYPE-37
      TELEVIDEO-950
      TERMINET-300
      TI-700
      ZENITH-H19

   Here are a few terminal types used in the Unix environment:

      ADDS-CONSUL-980
      ADDS-REGENT-200
      ANDERSON-JACOBSON-832
      ANN-ARBOR-AMBASSADOR
      BITGRAPH
      CDI-1203
      COMPUCOLOR-II
      CONCEPT-100
      DATA-GENERAL-6053
      DATAGRAPHIX-132A
      DATAMEDIA-3045A
      DATAPOINT-3360
      DEC-DECWRITER-II
      DEC-GT40
      DEC-VT52
      DELTA-DATA-5000
      DIABLO-1620
      EXECUPORT-4000


Solomon & Wimmers                                               [Page 4]



RFC 884                                                    December 1983


      GENERAL-TERMINAL-100A
      HAZELTINE-1500
      HAZELTINE-2000
      HP-2621
      HP-2640A
      HP-2645
      HP-2649A
      IBM-3101
      INFOTON-100
      LSI-ADM-3
      MICROTERM-ACT-V
      MICROTERM-MIME-2
      NETWORK-VIRTUAL-TERMINAL
      PERKIN-ELMER-1100
      PLASMA-PANEL
      SUPERBEE-III-M
      TEKTRONIX-4014
      TELERAY-3700
      TELETYPE-33
      TELETYPE-37
      TELEVIDEO-912
      TERMINET-300
      TI-700
      TI-733
      TI-745
      VISUAL-200
      XEROX-1720
      ZENITH-H19
      ZENTEC-30

   The type "UNKNOWN" should be used if the type of the terminal is
   unknown or unlikely to be recognized by the other party.

   The complete and up-to-date list will be maintained in the "Assigned
   Numbers".















Solomon & Wimmers                                               [Page 5]