rfc2355.txt

RFC 的详细文档！

      client.

   Successful negotiation of these two suboptions signals the beginning
   of 3270 data stream transmission. In order to support several of the
   new functions in TN3270E, each data message must be prefixed by a
   header.  This header will contain flags and indicators that convey
   such things as positive and negative responses and what type of data
   follows the header (for example, 3270 data stream, SNA Character
   Stream, or device status information).

3.  Command Names and Codes

   Please note that all numeric literals in this document specify
   decimal values, unless they are preceded by "0x", in which case a
   hexadecimal value is represented.

       TN3270E            40
         ASSOCIATE          00
         CONNECT            01
         DEVICE-TYPE        02
         FUNCTIONS          03
         IS                 04
         REASON             05
         REJECT             06
         REQUEST            07
         SEND               08

       Reason-codes
         CONN-PARTNER       00
         DEVICE-IN-USE      01
         INV-ASSOCIATE      02
         INV-NAME           03



Kelly                       Standards Track                     [Page 6]

RFC 2355                  TN3270 Enhancements                  June 1998


         INV-DEVICE-TYPE    04
         TYPE-NAME-ERROR    05
         UNKNOWN-ERROR      06
         UNSUPPORTED-REQ    07

       Function Names
         BIND-IMAGE         00
         DATA-STREAM-CTL    01
         RESPONSES          02
         SCS-CTL-CODES      03
         SYSREQ             04

4.  Command Meanings

   Refer to the Telnet Protocol Specification [8] for the meaning of
   IAC, DO, WILL, etc.

   IAC WILL TN3270E

      The sender of this command is willing to send TN3270E information
      in subsequent sub-negotiations.

   IAC WON'T TN3270E

      The sender of this command refuses to send TN3270E information.

   IAC DO TN3270E

      The sender of this command is willing to receive TN3270E
      information in subsequent sub-negotiations.

   IAC DON'T TN3270E

      The sender of this command refuses to receive TN3270E information.

   Note that while they are not explicitly negotiated, the equivalent of
   the Telnet Binary Transmission Option [3] and the Telnet End of
   Record Option [4] is implied in the negotiation of the TN3270E
   Option.  That is, a party to the negotiation that agrees to support
   TN3270E is automatically required to support bi-directional binary
   and EOR transmissions.

   IAC SB TN3270E SEND DEVICE-TYPE IAC SE

      Only the server may send this command.  This command is used to
      request that the client transmit a device-type and, optionally,
      device-name information.




Kelly                       Standards Track                     [Page 7]

RFC 2355                  TN3270 Enhancements                  June 1998


   IAC SB TN3270E DEVICE-TYPE REQUEST <device-type>
       [ [CONNECT <resource-name>] | [ASSOCIATE <device-name>] ] IAC SE

      Only the client may send this command.  It is used in response to
      the server's SEND DEVICE-TYPE command, as well as to suggest
      another device-type after the server has sent a DEVICE-TYPE REJECT
      command (see below).  This command requests emulation of a
      specific 3270 device type and model.  The REQUEST command may
      optionally include either the CONNECT or the ASSOCIATE command
      (but not both).  If present, CONNECT must be followed by
      <resource-name> and ASSOCIATE must be followed by <device-name>.
      (See the section entitled "DEVICE-TYPE Negotiation" for more
      detailed information.)

   IAC SB TN3270E DEVICE-TYPE IS <device-type> CONNECT
       <device-name> IAC SE

      Only the server may send this command.  This command is used to
      accept a client's DEVICE-TYPE REQUEST command and to return the
      server-defined device-name.

   IAC SB TN3270E DEVICE-TYPE REJECT REASON <reason-code> IAC SE

      Only the server may send this command.  This command is used to
      reject a client's DEVICE-TYPE REQUEST command.

   IAC SB TN3270E FUNCTIONS REQUEST <function-list> IAC SE

      Either side may send this command.  This command is used to
      suggest a set of 3270 functions that will be supported on this
      session.  It is also sent as an implicit rejection of a previous
      FUNCTIONS REQUEST command sent by the other side (see the section
      entitled "FUNCTIONS Negotiation" for more information).  Note that
      when used to reject a FUNCTIONS REQUEST command, the function-list
      must not be identical to that received in the previous REQUEST
      command.

   IAC SB TN3270E FUNCTIONS IS <function-list> IAC SE

      Either side may send this command.  This command is sent as a
      response to a FUNCTIONS REQUEST command and implies acceptance of
      the set of functions sent to it in the REQUEST command.  Note that
      the list of functions in the FUNCTIONS IS command must match the
      list that was received in the previous FUNCTIONS REQUEST command.







Kelly                       Standards Track                     [Page 8]

RFC 2355                  TN3270 Enhancements                  June 1998


5.  Default Specification

   WON'T TN3270E

   DON'T TN3270E

   i.e., TN3270E will not be used.

6.  Motivation

   See the section entitled "Introduction".

7.  TN3270E Sub-negotiation Rules

   Once it has been agreed that TN3270E will be supported, the first
   sub-negotiation must concern the DEVICE-TYPE (and possibly device-
   name) information.  Only after that has been successfully negotiated
   can the client and server exchange FUNCTIONS information.  Only after
   both DEVICE-TYPE and FUNCTIONS have been successfully negotiated can
   3270 data stream transmission occur.

7.1 DEVICE-TYPE Negotiation

   Device-type names are NVT ASCII strings, all upper case.

   Device-type (and device-name) negotiation begins when the server
   transmits the DEVICE-TYPE SEND command to the client.  The client
   responds with the DEVICE-TYPE REQUEST command, which must include a
   device-type and may include a resource-name or device-name request.

   Valid device-types are:

     erminals: IBM-3278-2  IBM-3278-2-E  (24 row x 80 col display)
               IBM-3278-3  IBM-3278-3-E  (32 row x 80 col display)
               IBM-3278-4  IBM-3278-4-E  (43 row x 80 col display)
               IBM-3278-5  IBM-3278-5-E  (27 row x 132 col display)
               IBM-DYNAMIC            (no pre-defined display size)

     printers: IBM-3287-1

   Note that the use of '3278' and '3287' is NOT intended to exclude any
   particular device capabilities; they are used here only because they
   are commonly known designations for a terminal and a printer member
   of the 3270 family of devices.  The intention is to simplify the
   device-type negotiation (in comparison to traditional tn3270) by
   minimizing the number of possible device-types, and by breaking the
   association of a specific piece of IBM hardware with a related set of
   data stream capabilities.  For example, negotiation of device-type



Kelly                       Standards Track                     [Page 9]

RFC 2355                  TN3270 Enhancements                  June 1998


   IBM-3278-2-E does NOT in and of itself preclude the use of any of the
   functions associated with a physical 3279 model S2B.  A client's
   ability to support the more advanced functions of the 3270 data
   stream will be indicated not by negotiation of an IBM device type and
   model number, but rather by the combination of Read Partition Query
   and Query Reply.

   All of the terminal device-types support a "primary" display size of
   24 rows by 80 columns.  The "-3", "-4" and "-5" types each support an
   "alternate" display size as noted in the above list.  The IBM-DYNAMIC
   device-type implies no pre-defined alternate display size; this value
   will be passed from the client to host applications as part of the
   Query Reply structured field, and it can represent any display size
   the client and the host application can support.

   Terminal device-types with the "-E" suffix should only be negotiated
   by clients that are willing to support some subset of the 3270
   "extended data stream".  This usually includes at a minimum support
   for extended colors and highlighting, but may also include a number
   of other functions, such as graphics capability, alternate character
   sets, and partitions.

   Clients that negotiate a terminal device-type with the "-E" suffix or
   the DYNAMIC type, as well as those that negotiate a printer device-
   type, must be able to accept and respond to a Read Partition Query
   command (see the section entitled "3270 Structured Fields").  This
   allows the client to indicate to host applications which subsets of
   the 3270 extended data stream the client is willing to support.

   In a VTAM/SNA environment, negotiation of IBM-DYNAMIC as the device-
   type should result in a Bind in which the Presentation Services Usage
   screen field (the eleventh byte in the logmode's PSERVIC field) is
   set to 0x03, indicating that the alternate screen size will be
   determined by the Query Reply (Usable Area).

7.1.1 Device Pools

   An explanation of the CONNECT and ASSOCIATE commands first requires a
   discussion of the organization of terminal and printer device pools
   that the server maintains and from which it selects device-names to
   assign to session requests.  Definition of a few terms is also in
   order.

   The terms "device-name", "LU name" and "network name" can be
   considered interchangeable in this document.  They refer to a
   specific terminal or printer device.





Kelly                       Standards Track                    [Page 10]

RFC 2355                  TN3270 Enhancements                  June 1998


   The term "resource-name" is less specific; it may refer to a device-
   name, but it may also be the name of a pool of printer or terminal
   devices.  Such a named pool could serve to group devices with similar
   operational or administrative characteristics.  In fact, this
   document places no restrictions on how a server makes use of
   resource-names, so long as the server can take a resource-name
   specified by the client and use it to come up with a device-name to
   assign to the session.  Note, however, that servers must avoid
   allowing ambiguity; for example, they must not allow the definition
   of a device-name with the same name as that of a pool of devices.

   Device-names and resource-names are specified as NVT ASCII strings in
   which upper and lower case are considered equivalent.  The length of
   device-names and resource-names should not exceed 8 bytes.

   A "generic session request" is one which includes neither the CONNECT
   nor the ASSOCIATE command, while a "specific session request" is one
   that includes either the CONNECT or the ASSOCIATE command.

   If a TN3270E server wishes to support traditional tn3270 clients, it
   must maintain a set of terminal device-names that can be used to
   satisfy requests from such clients for terminal sessions.  This same
   pool could be used to satisfy generic requests for terminal sessions
   from TN3270E clients.

   The server may also maintain any number of other pools of device-
   names.  For example, there could be a pool of terminal device-names
   reserved for a specific department within the organization, or a pool
   of terminal device-names that have access to certain applications on
   the host.

   For any of these terminal device pools, the TN3270E server may also
   have defined a "partner" or "paired" printer device for each terminal
   in the pool.  There should be a unique, one-to-one mapping between a
   terminal and its associated printer.  The reasoning behind such a
   configuration is to allow for those host applications that produce
   printed output bound for a printer whose device-name is determined by
   the device-name of the terminal that initiated the print request.