Telnet terminal type option

　　Network Working Group Marvin Solomon

　　Request for Comments: 930 Edward Wimmers

　　Supersedes: RFC884University of Wisconsin - Madison

　　January 1985

　　TELNETTERMINAL TYPE OPTION

　　Status of This Memo

　　This RFCspecifies 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 RFC884. 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.)

　　Solomon &Wimmers [Page 1]

　　RFC930January 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

　　Solomon &Wimmers [Page 2]

　　RFC930January 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.

　　Solomon &Wimmers [Page 3]

　　RFC930January 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.