RFC INDEX PAGE
Google
 

 
Network Working Group                                     Marvin Solomon
Request for Comments: 930                                 Edward Wimmers
Supersedes: RFC 884                    University of Wisconsin - Madison
                                                            January 1985
 
                      TELNET TERMINAL TYPE OPTION
 
 
Status of This Memo
 
   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.  Distribution of this memo is unlimited.
 
   This standard supersedes RFC 884.  The only change is to specify that
   the TERMINAL-TYPE IS sub-negotiation should be sent only in response
   to the TERMINAL-TYPE SEND sub-negotiation.  See below for further
   explanation.
 
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 WON'T TERMINAL-TYPE
 
      Sender refuses to send terminal type information
 
   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 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.)
 
 
 
 
 

RFC 930 January 1985 Telnet Terminal Type Option IAC SB TERMINAL-TYPE IS ... IAC SE Sender is stating the name of his terminal type. The code for IS is 0. (See below.) 3. Default WON'T TERMINAL-TYPE Terminal type information will not be exchanged. DON'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 DO TERMINAL-TYPE is free to request type information. 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). 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
RFC 930 January 1985 Telnet Terminal Type Option 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. The following is an example of use of the option: Host1: IAC DO TERMINAL-TYPE Host2: IAC WILL TERMINAL-TYPE (Host1 is now free to request status information at any time.) Host1: 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 meaningful to both ends of the negotiation. The list of terminal type names in "Assigned Numbers" 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. Note that TERMINAL-TYPE IS must only be sent in response to a request (TERMINAL-TYPE SEND), because a host that sent TERMINAL-TYPE IS and then received TERMINAL-TYPE SEND couldn't determine whether the other host was requesting a second option or the TERMINAL-TYPE SEND and the TERMINAL-TYPE IS crossed in midstream. The type "UNKNOWN" should be used if the type of the terminal is unknown or unlikely to be recognized by the other party.
RFC 930 January 1985 Telnet Terminal Type Option The complete and up-to-date list of terminal type names will be maintained in the "Assigned Numbers". The maximum length of a terminal type name is 40 characters.

The HTML presentation of this document is copyrighted by Grafman Productions.
Copyright © 1997 - Grafman Productions - ALL RIGHTS RESERVED
Grafman Productions