RFC 1091 (rfc1091) - Page 3 of 7

Telnet terminal-type option

Alternative Format: Original Text Document
< Previous
Next >
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
< Previous
Next >