home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / rfc / rfc1091 < prev    next >
Text File  |  1991-04-21  |  13KB  |  395 lines
  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7. Network Working Group                                  J. VanBokkelen
  8. Request for Comments: 1091                         FTP Software, Inc.
  9. Obsoletes: RFC 930                                      February 1989
  10.  
  11.  
  12.                       Telnet Terminal-Type Option
  13.  
  14. Status of This Memo
  15.  
  16.    This RFC specifies a standard for the Internet community.  Hosts on
  17.    the Internet that exchange terminal type information within the
  18.    Telnet protocol are expected to adopt and implement this standard.
  19.  
  20.    This standard supersedes RFC 930.  A change is made to permit cycling
  21.    through a list of possible terminal types and selecting the most
  22.    appropriate.
  23.  
  24.    Distribution of this memo is unlimited.
  25.  
  26. 1. Command Name and Code
  27.  
  28.       TERMINAL-TYPE   24
  29.  
  30. 2. Command Meanings
  31.  
  32.       IAC WILL TERMINAL-TYPE
  33.  
  34.          Sender is willing to send terminal type information in a
  35.          subsequent sub-negotiation.
  36.  
  37.       IAC WON'T TERMINAL-TYPE
  38.  
  39.          Sender refuses to send terminal type information.
  40.  
  41.       IAC DO TERMINAL-TYPE
  42.  
  43.          Sender is willing to receive terminal type information in a
  44.          subsequent sub-negotiation.
  45.  
  46.       IAC DON'T TERMINAL-TYPE
  47.  
  48.          Sender refuses to accept terminal type information.
  49.  
  50.  
  51.  
  52.  
  53.  
  54.  
  55.  
  56.  
  57.  
  58. VanBokkelen                                                     [Page 1]
  59.  
  60. RFC 1091              Telnet Terminal-Type Option          February 1989
  61.  
  62.  
  63.       IAC SB TERMINAL-TYPE SEND IAC SE
  64.  
  65.          Server requests client to transmit his (the client's) next
  66.          terminal type, and switch emulation modes (if more than one
  67.          terminal type is supported).  The code for SEND is 1. (See
  68.          below.)
  69.  
  70.       IAC SB TERMINAL-TYPE IS ... IAC SE
  71.  
  72.          Client is stating the name of his current (or only) terminal
  73.          type.  The code for IS is 0.  (See below.)
  74.  
  75. 3. Default
  76.  
  77.       WON'T TERMINAL-TYPE
  78.  
  79.          Terminal type information will not be exchanged.
  80.  
  81.       DON'T TERMINAL-TYPE
  82.  
  83.          Terminal type information will not be exchanged.
  84.  
  85. 4. Motivation for the Option
  86.  
  87.    On most machines with bit-mapped displays (e.g., PCs and graphics
  88.    workstations) a client terminal emulation program is used to simulate
  89.    a conventional ASCII terminal.  Most of these programs have multiple
  90.    emulation modes, frequently with widely varying characteristics.
  91.    Likewise, modern host system software and applications can deal with
  92.    a variety of terminal types.  What is needed is a means for the
  93.    client to present a list of available terminal emulation modes to the
  94.    server, from which the server can select the one it prefers (for
  95.    arbitrary reasons).  There is also need for a mechanism to change
  96.    emulation modes during the course of a session, perhaps according to
  97.    the needs of applications programs.
  98.  
  99.    Existing terminal-type passing mechanisms within Telnet were not
  100.    designed with multiple emulation modes in mind.  While multiple names
  101.    are allowed, they are assumed to be synonyms.  Emulation mode changes
  102.    are not defined, and the list of modes can only be scanned once.
  103.  
  104.    This document defines a simple extension to the existing mechanisms,
  105.    which meets both of the above criteria.  It makes one assumption
  106.    about the behaviour of implementations coded to the previous standard
  107.    in order to obtain full backwards-compatibility.
  108.  
  109.  
  110.  
  111.  
  112.  
  113.  
  114. VanBokkelen                                                     [Page 2]
  115.  
  116. RFC 1091              Telnet Terminal-Type Option          February 1989
  117.  
  118.  
  119. 5. Description of the Option
  120.  
  121.    Willingness to exchange terminal-type information is agreed upon via
  122.    conventional Telnet option negotiation.  WILL and DO are used only to
  123.    obtain and grant permission for future discussion.  The actual
  124.    exchange of status information occurs within option subcommands (IAC
  125.    SB TERMINAL-TYPE...).
  126.  
  127.    Once the two hosts have exchanged a WILL and a DO, the sender of the
  128.    DO TERMINAL-TYPE (the server) is free to request type information.
  129.    Only the server may send requests (IAC SB TERMINAL-TYPE SEND IAC SE)
  130.    and only the client may transmit actual type information (within an
  131.    IAC SB TERMINAL-TYPE IS ... IAC SE command).  Terminal type
  132.    information may not be sent spontaneously, but only in response to a
  133.    request.
  134.  
  135.    The terminal type information is an NVT ASCII string.  Within this
  136.    string, upper and lower case are considered equivalent.  The complete
  137.    list of valid terminal type names can be found in the latest
  138.    "Assigned Numbers" RFC [4].
  139.  
  140.    The transmission of terminal type information by the Telnet client in
  141.    response to a query from the Telnet server implies that the client
  142.    must simultaneously change emulation mode, unless the terminal type
  143.    sent is a synonym of the preceding terminal type, or there are other
  144.    prerequisites for entering the new regime (e.g., having agreed upon
  145.    the Telnet binary option).  The receipt of such information by the
  146.    Telnet server does not imply any immediate change of processing.
  147.    However, the information may be passed to a process, which may alter
  148.    the data it sends to suit the particular characteristics of the
  149.    terminal.  For example, some operating systems have a terminal driver
  150.    that accepts a code indicating the type of terminal being driven.
  151.    Using the TERMINAL TYPE and BINARY options, a telnet server program
  152.    on such a system could arrange to have terminals driven as if they
  153.    were directly connected, including special functions not available to
  154.    a standard Network Virtual Terminal.
  155.  
  156.    Note that this specification is deliberately asymmetric.  It is
  157.    assumed that server operating systems and applications in general
  158.    cannot change terminal types at arbitrary points in a session.  Thus,
  159.    the client may only send a new type (and potentially change emulation
  160.    modes) when the server requests that it do so.
  161.  
  162. 6.  Implementation Issues
  163.  
  164.    The "terminal type" information may be any NVT ASCII string
  165.    meaningful to both ends of the negotiation.  The list of terminal
  166.    type names in "Assigned Numbers" is intended to minimize confusion
  167.  
  168.  
  169.  
  170. VanBokkelen                                                     [Page 3]
  171.  
  172. RFC 1091              Telnet Terminal-Type Option          February 1989
  173.  
  174.  
  175.    caused by alternative "spellings" of the terminal type.  For example,
  176.    confusion would arise if one party were to call a terminal "IBM3278-
  177.    2" while the other called it "IBM-3278/2".  There is no negative
  178.    acknowledgement for a terminal type that is not understood, but
  179.    certain other options (such as switching to BINARY mode) may be
  180.    refused if a valid terminal type name has not been specified.
  181.  
  182.    In some cases, either a particular terminal may be known by more than
  183.    one name, for example a specific type and a more generic type, or the
  184.    client may be a workstation with integrated display capable of
  185.    emulating more than one kind of terminal.  In such cases, the sender
  186.    of the TERMINAL-TYPE IS command should reply to successive TERMINAL-
  187.    TYPE SEND commands with the various names.  In this way, a telnet
  188.    server that does not understand the first response can prompt for
  189.    alternatives.  If different terminal emulations are supported by the
  190.    client, the mode of the emulator must be changed to match the last
  191.    type sent, unless the particular emulation has other Telnet options
  192.    (e.g., BINARY) as prerequisites (in which case, the emulation will
  193.    switch to the last type sent when the prerequisite is fulfilled).
  194.    When types are synonyms, they should be sent in order from most to
  195.    least specific.
  196.  
  197.    When the server (the receiver of the TERMINAL-TYPE IS) receives the
  198.    same response two consecutive times, this indicates the end of the
  199.    list of available types.  Similarly, the client should indicate it
  200.    has sent all available names by repeating the last one sent.  If an
  201.    additional request is received, this indicates that the server (the
  202.    sender of the IS) wishes to return to the top of the list of
  203.    available types (probably to select the least of N evils).
  204.  
  205.    Server implementations conforming to the previous standard will cease
  206.    sending TERMINAL-TYPE SEND commands after receiving the same response
  207.    two consecutive times, which will work according to the old standard.
  208.    It is assumed that client implementations conforming to the previous
  209.    standard will send the last type on the list in response to a third
  210.    query (as well as the second).  New-style servers must recognize this
  211.    and not send more queries.
  212.  
  213.    The type "UNKNOWN" should be used if the type of the terminal is
  214.    unknown or unlikely to be recognized by the other party.
  215.  
  216.    The complete and up-to-date list of terminal type names will be
  217.    maintained in the "Assigned Numbers".  The maximum length of a
  218.    terminal type name is 40 characters.
  219.  
  220. 7. User Interfaces
  221.  
  222.    Telnet clients and servers conforming to this specification should
  223.  
  224.  
  225.  
  226. VanBokkelen                                                     [Page 4]
  227.  
  228. RFC 1091              Telnet Terminal-Type Option          February 1989
  229.  
  230.  
  231.    provide the following functions in their user interfaces:
  232.  
  233.    Clients supporting multiple emulation modes should allow the user to
  234.    specify which of the modes is preferred (which name is sent first),
  235.    prior to connection establishment.  The order of the names sent
  236.    cannot be changed after the negotiation has begun.  This initial mode
  237.    will also become the default with servers which do not support
  238.    TERMINAL TYPE.
  239.  
  240.    Servers should store the current terminal type name and the list of
  241.    available names in a manner such that they are accessible to both the
  242.    user (via a keyboard command) and any applications which need the
  243.    information.  In addition, there should be a corresponding mechanism
  244.    to request a change of terminal types, by initiating a series of
  245.    SEND/IS sub-negotiations.
  246.  
  247. 8. Examples
  248.  
  249.    In this example, the server finds the first type acceptable.
  250.  
  251.       Server: IAC DO TERMINAL-TYPE
  252.  
  253.       Client: IAC WILL TERMINAL-TYPE
  254.  
  255.          (Server may now request a terminal type at any time.)
  256.  
  257.       Server: IAC SB TERMINAL-TYPE SEND IAC SE
  258.  
  259.       Client: IAC SB TERMINAL-TYPE IS IBM-3278-2 IAC SE
  260.  
  261.    In this example, the server requests additional terminal types, and
  262.    accepts the second (and last on the client's list) type sent (RFC 930
  263.    compatible):
  264.  
  265.       Server: IAC DO TERMINAL-TYPE
  266.  
  267.       Client: IAC WILL TERMINAL-TYPE
  268.  
  269.          (Server may now request a terminal type at any time.)
  270.  
  271.       Server: IAC SB TERMINAL-TYPE SEND IAC SE
  272.  
  273.       Client: IAC SB TERMINAL-TYPE IS ZENITH-H19 IAC SE
  274.  
  275.       Server: IAC SB TERMINAL-TYPE SEND IAC SE
  276.  
  277.       Client: IAC SB TERMINAL-TYPE IS UNKNOWN IAC SE
  278.  
  279.  
  280.  
  281.  
  282. VanBokkelen                                                     [Page 5]
  283.  
  284. RFC 1091              Telnet Terminal-Type Option          February 1989
  285.  
  286.  
  287.       Server: IAC SB TERMINAL-TYPE SEND IAC SE
  288.  
  289.       Client: IAC SB TERMINAL-TYPE IS UNKNOWN IAC SE
  290.  
  291.    In this example, the server requests additional terminal types, and
  292.    proceeds beyond the end-of-list, to select the first type offered by
  293.    the client (new-type client and server):
  294.  
  295.       Server: IAC DO TERMINAL-TYPE
  296.  
  297.       Client: IAC WILL TERMINAL-TYPE
  298.  
  299.          (Server may now request a terminal type at any time.)
  300.  
  301.       Server: IAC SB TERMINAL-TYPE SEND IAC SE
  302.  
  303.       Client: IAC SB TERMINAL-TYPE IS DEC-VT220 IAC SE
  304.  
  305.       Server: IAC SB TERMINAL-TYPE SEND IAC SE
  306.  
  307.       Client: IAC SB TERMINAL-TYPE IS DEC-VT100 IAC SE
  308.  
  309.       Server: IAC SB TERMINAL-TYPE SEND IAC SE
  310.  
  311.       Client: IAC SB TERMINAL-TYPE IS DEC-VT52 IAC SE
  312.  
  313.       Server: IAC SB TERMINAL-TYPE SEND IAC SE
  314.  
  315.       Client: IAC SB TERMINAL-TYPE IS DEC-VT52 IAC SE
  316.  
  317.       Server: IAC SB TERMINAL-TYPE SEND IAC SE
  318.  
  319.       Client: IAC SB TERMINAL-TYPE IS DEC-VT220 IAC SE
  320.  
  321. 9. References:
  322.  
  323.      [1]  Postel, J., and J. Reynolds, "Telnet Protocol Specification",
  324.           RFC 854, USC Information Sciences Institute, May 1983.
  325.  
  326.      [2]  Postel, J., and J. Reynolds, "Telnet Option Specification",
  327.           RFC 855, USC Information Sciences Institute, May 1983.
  328.  
  329.      [3]  Solomon, M., and E. Wimmers, "Telnet Terminal Type Option",
  330.           RFC 930, University of Wisconsin - Madison, January 1985.
  331.  
  332.      [4]  Reynolds, J., and J. Postel, "Assigned Numbers", RFC 1010,
  333.           USC Information Sciences Institute, May 1987.
  334.  
  335.  
  336.  
  337.  
  338. VanBokkelen                                                     [Page 6]
  339.  
  340. RFC 1091              Telnet Terminal-Type Option          February 1989
  341.  
  342.  
  343. Reviser's note:
  344.  
  345.    I owe much of this text to RFCs 884 and 930, by Marvin Solomon and
  346.    Edward Wimmers of the University of Wisconsin - Madison, and I owe
  347.    the idea of the extension to discussions on the "tn3270" mailing list
  348.    in the Summer of 1987.
  349.  
  350. Author's Address
  351.  
  352.    James VanBokkelen
  353.    FTP Software, Inc.
  354.    26 Princess Street
  355.    Wakefield, MA 01880-3004
  356.  
  357.    Phone: (617) 246-0900
  358.  
  359.    Email: jbvb@ftp.com
  360.  
  361.  
  362.  
  363.  
  364.  
  365.  
  366.  
  367.  
  368.  
  369.  
  370.  
  371.  
  372.  
  373.  
  374.  
  375.  
  376.  
  377.  
  378.  
  379.  
  380.  
  381.  
  382.  
  383.  
  384.  
  385.  
  386.  
  387.  
  388.  
  389.  
  390.  
  391.  
  392.  
  393.  
  394. VanBokkelen                                                     [Page 7]
  395.