rfc2355.txt

<VC++网络游戏建摸与实现>源代码

   example, when the userid of the person signed on to a terminal
   determines the print destination).  It is also possible that a pool
   of printer device-names could be maintained to satisfy generic
   requests for printers (i.e., those that specify neither CONNECT nor
   ASSOCIATE).

7.1.2 CONNECT Command

   CONNECT can be used by the client in two ways: if the resource-name
   it specifies is a device-name, then the client is requesting a
   specific device-name.  If the specified resource-name is not a
   device-name, then the client is requesting any one of the device-
   names associated with the resource-name.

   In either case, the resource indicated by the specified resource-name
   must not conflict with the device-type; e.g., if the client requests
   DEVICE-TYPE IBM-3287-1 (a printer) and specifies CONNECT T1000001,
   but T1000001 is a device-name defined at the host as a terminal, then
   the server must deny the request.  Further, if the requested
   resource-name is a device-name already associated with some other
   Telnet session, or if it is not defined to the server, the server
   must deny the request.

7.1.3 ASSOCIATE Command

   ASSOCIATE can be used by the client only when requesting a DEVICE-
   TYPE that represents a printer, and the specified device-name must be
   that of a terminal that was returned by the server in a previous
   DEVICE-TYPE IS <device-type> CONNECT <device-name> command.

   The ASSOCIATE command requests that this session be assigned the
   device-name of the printer that is paired with the terminal named in
   the request.  If the device-type does not represent a printer, or if
   the device-name is not that of a terminal, then the server must deny
   the request.  Also, if the server does not have defined a partner
   printer for the specified terminal, it must deny the request.

   The use of the ASSOCIATE command is to be as follows:  A client first
   connects and requests a terminal from one of the terminal pools; it
   then uses the terminal device-name returned by the server (see
   "Accepting a Request", section 7.1.4 below) in a second session
   request, this time asking for the printer that is paired with the
   terminal session it just established.  This allows clients to
   associate a printer session with a terminal rather than having to
   have prior knowledge of a printer device-name.






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


7.1.4 Accepting a Request

   The server must accept the client's request or deny it as a whole -
   it cannot, for example, accept the DEVICE-TYPE request but deny the
   CONNECT portion.

   If the server wishes to accept the request, it sends back the
   DEVICE-TYPE IS command confirming the requested device-type and the
   CONNECT command specifying the device-name of the terminal or printer
   assigned to this session.

   Normally, the client should accept any DEVICE-TYPE IS <device-type>
   CONNECT <device-name> sent by the server.  An exception to this would
   be if the client must (e.g., to satisfy local-site policy) be
   connected to a specific LU name and is presented with a device-name
   which does not match the one requested by the client (this could
   happen, for example, if the client requested what it thought was a
   device-name, but what was defined at the server as the name of a pool
   of devices).  In this case, the client should reject the DEVICE-TYPE
   IS command by terminating TN3270E negotiations.

7.1.5 REJECT Command

   If the server wishes to deny the request, it sends back the DEVICE-
   TYPE REJECT command with one of the following reason-codes:

   Reason code name         Explanation
   ----------------         -----------------------------------
   INV-DEVICE-TYPE          The server does not support the
                            requested device-type.

   INV-NAME                 The resource-name or device-name
                            specified in the CONNECT or ASSOCIATE
                            command is not known to the server.

   DEVICE-IN-USE            The requested device-name is
                            already associated with another
                            session.

   TYPE-NAME-ERROR          The requested device-name or
                            resource-name is incompatible
                            with the requested device-type
                            (such as terminal/printer mismatch).

   UNSUPPORTED-REQ          The server is unable to satisfy
                            the type of request sent by the
                            client; e.g., a specific terminal
                            or printer was requested but the



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


                            server does not have any such pools of
                            device-names defined to it, or the
                            ASSOCIATE command was used but no
                            partner printers are defined to the
                            server.

   INV-ASSOCIATE            The client used the ASSOCIATE
                            command and either the device-type
                            is not a printer or the device-name
                            is not a terminal.

   CONN-PARTNER             The client used the CONNECT command
                            to request a specific printer but
                            the device-name requested is the
                            partner to some terminal.

   UNKNOWN-ERROR            Any other error in device type or
                            name processing has occurred.

   The process of negotiating a device-type and device-name that are
   acceptable to both client and server may entail several iterations of
   DEVICE-TYPE REQUEST and DEVICE-TYPE REJECT commands.  The client must
   make use of the reason-code specified by the server in any DEVICE-
   TYPE REJECT command(s) to minimize the amount of negotiation
   necessary.  For example, if the client initially requests that it be
   assigned a specific terminal device-name via the CONNECT command, and
   the server rejects the request with a reason-code of UNSUPPORTED-REQ,
   the client must make no further specific terminal requests in the
   negotiations.  If at any point in the process either side wishes to
   "bail out," it can simply send a WON'T (or DON'T) TN3270E command to
   the other side.  At this point both sides are free to negotiate other
   Telnet options (including traditional tn3270).

7.2 FUNCTIONS Negotiation

   Once the DEVICE-TYPE negotiation has successfully completed (i.e,
   when the client receives a DEVICE-TYPE IS command that is
   acceptable), the client must initiate the FUNCTIONS negotiation by
   sending the FUNCTIONS REQUEST command to the server.  After this
   initial REQUEST command, both sides are free to transmit FUNCTIONS
   REQUEST and FUNCTIONS IS commands as needed.

7.2.1 Commands

   The FUNCTIONS REQUEST command contains a list of the TN3270E
   functions that the sender would like to see supported on this
   session.  All functions not in the list are to be considered
   unsupported.  The list is terminated by the IAC code that precedes



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


   the SE command.  Functions may appear in any order in the list.

   Upon receipt of a FUNCTIONS REQUEST command, the recipient has two
   choices:

   - it may respond in the positive (meaning it agrees to support
     all functions in the list, and not to transmit any data related to
     functions not in the list).  To do this, it sends the FUNCTIONS IS
     command with the function-list exactly as it was received.  At this
     point, FUNCTIONS negotiation has successfully completed.

   - it may respond in the negative by sending a FUNCTIONS
     REQUEST command in which the function-list differs from the one it
     received (and not simply in the order of appearance of functions in
     the list; at least one function must have been added to, or removed
     from, the list).

     To avoid endlessly looping, both parties must not add to the
     function-list it receives any function that it has previously added
     and that the other side has removed.

     The process of sending FUNCTIONS REQUEST commands back and forth
     continues until one side receives a function-list it is willing to
     live with.  It uses the FUNCTIONS IS command to accept the list,
     and, once this command is received by the other side, all necessary
     negotiation has been completed.  At this point, 3270 data stream
     transmission can begin.

     Note that it is possible that the function-list agreed to is null;
     this is referred to as "basic TN3270E".  See the section entitled
     "Basic TN3270E" for more information.

     If an impasse is reached during FUNCTIONS negotiation (for example,
     if a client requested and was granted a DEVICE-TYPE representing a
     printer, but refuses to accept either the SCS-CTL-CODES or DATA-
     STREAM-CTL function), then the "offended" party should terminate
     the negotiation by sending an IAC DON'T (or WON'T) TN3270E.














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


7.2.2 List of TN3270E Functions

   The following list briefly describes the 3270 functions that may be
   negotiated in the function-list:

   Function Name       Description
   -------------       -----------
   SCS-CTL-CODES       (Printer sessions only).  Allows the use
                       of the SNA Character Stream (SCS) and SCS
                       control codes on the session.  SCS is
                       used with LU type 1 SNA sessions.

   DATA-STREAM-CTL     (Printer sessions only).  Allows the use
                       of the standard 3270 data stream.  This
                       corresponds to LU type 3 SNA sessions.

   RESPONSES           Provides support for positive and
                       negative response handling.  Allows the
                       server to reflect to the client any and
                       all definite, exception, and no response
                       requests sent by the host application.

   BIND-IMAGE          Allows the server to send the SNA Bind
                       image and Unbind notification to the
                       client.

   SYSREQ              Allows the client and server to emulate
                       some (or all, depending on the server) of
                       the functions of the SYSREQ key in an SNA
                       environment.

   See the section entitled "Details of Processing TN3270E Functions"
   for a more detailed explanation of the meaning and use of these
   functions.

   If in the process of functions negotiation an unrecognized function
   code is recieved, the recipient should simply remove that function
   code from the list and continue normal functions negotiation.

8.  TN3270E Data Messages

   3270 device communications are generally understood to be block
   oriented in nature.  That is, each partner buffers data until an
   entire "message" has been built, at which point the data is sent to
   the other side.  The "outbound message" (from host to device)
   consists of a 3270 command and a series of buffer orders, buffer
   addresses, and data, while the "inbound message" contains only buffer
   orders, addresses and data.  The end of a message is understood to be



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


   the last byte transmitted (note that this discussion disregards SNA
   chaining).  The Telnet EOR command is used to delimit these natural
   blocks of 3270 data within the Telnet data stream.

   In TN3270E, each 3270 message must be prefixed with a TN3270E header,
   which consists of five bytes and whose format is defined below (see
   the section entitled "The TN3270E Message Header").  A "data message"
   in TN3270E therefore has the following construction:

          <TN3270E Header><data><IAC EOR>

   It should be noted that it is possible that, for certain message
   types, there is no data portion present.  In this case, the TN3270E
   data message consists of:

          <TN3270E Header><IAC EOR>

   If either side wishes to transmit the decimal value 255 and have it
   interpreted as data, it must "double" this byte.  In other words, a
   single occurrence of decimal 255 will be interpreted by the other
   side as an IAC, while two successive bytes containing decimal 255
   will be treated as one data byte with a value of decimal 255.

   It is strongly recommended that Telnet commands (other than IAC IAC)
   should be sent between TN3270E data messages, with no header and no
   trailing IAC EOR.  If a TN3270E data message containing either IAC IP
   (to be interpreted as 3270 Attention) or IAC AO (to be interpreted as
   SYSREQ) is received, the receiver should defer processing the command
   until the 3270 data has been processed (see the appropriate sections
   for discussion of 3270 Attention and SYSREQ).  If a TN3270E data
   message containing any other IAC-command sequence (other than IAC