rfc1647.txt

中、英文RFC文档大全打包下载完全版 .

                          may be in the generic or the specific
                          terminal pool; therefore, devices in the
                          ranges PTG00001 - PTG00003 and PTS00001 -
                          PTS00003 can be used to satisfy the request.

           via CONNECT:   the request can be satisfied either from
                          the generic or the specific printer pools
                          (although, as with specific terminal requests,
                          it is likely that most such requests will name
                          printers in the specific printer pool); this
                          request cannot be satisfied with the partner
                          printer of a terminal in either the specific or
                          the generic terminal pools.

      7.1.5 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 Telnet session.  This device-name
         may be the one directly requested (via CONNECT) by the client,
         the one indirectly requested (via ASSOCIATE) by the client, or
         one chosen by the server if the client specified neither
         CONNECT nor ASSOCIATE.







Kelly                                                          [Page 11]

RFC 1647                  TN3270 Enhancements                  July 1994


      7.1.6 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-DEVICE-NAME          The 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
                                  Telnet session.

         TYPE-NAME-ERROR          The requested device-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
                                  server does not have such a pool 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.





Kelly                                                          [Page 12]

RFC 1647                  TN3270 Enhancements                  July 1994


         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 should 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 should 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 the DEVICE-TYPE IS command), the client
      should 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 3270
         functions that the sender would like to see supported on this
         session.  All functions not in the list are to be considered
         unsupported.  The function-list consists of a string of 2-byte
         entries separated from one another by a single space character.
         The list is terminated by the IAC code that precedes 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



Kelly                                                          [Page 13]

RFC 1647                  TN3270 Enhancements                  July 1994


         of functions in the list; at least one function must have
         been added to, or removed from, the list).

         To avoid endlessly looping, neither party should 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.

      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.



Kelly                                                          [Page 14]

RFC 1647                  TN3270 Enhancements                  July 1994


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

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
   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
   IAC) is received, it is implementation dependent when the IAC-command
   sequence will be processed, but it must be processed.  The receiver
   may process it immediately, which in effect causes it to be processed



Kelly                                                          [Page 15]

RFC 1647                  TN3270 Enhancements                  July 1994


   as if it had been received before the current TN3270E data message,
   or the processing may be deferred until after the current TN3270E
   data message has been processed.  It is because of this ambiguity
   that the presence of Telnet commands within a TN3270E data message
   (i.e., between the header and the trailing IAC EOR) is not
   recommended; neither clients nor servers should send such data.

   8.1 The TN3270E Message Header

      As stated earlier, each data message in TN3270E must be prefixed
      by a header, which consists of five bytes and is formatted as
      follows:

      -----------------------------------------------------------
      | DATA-TYPE | REQUEST-FLAG | RESPONSE-FLAG |  SEQ-NUMBER  |
      -----------------------------------------------------------
         1 byte        1 byte         1 byte         2 bytes

      8.1.1 DATA-TYPE Field

         The DATA-TYPE field indicates how the data portion of the
         message is to be interpreted by the receiver.  Possible values
         for the DATA-TYPE field are:

         Data-type Name   Code                Meaning
         --------------   ----   ---------------------------------
         3270-DATA        0x00   The data portion of the message