rfc2355.txt

RFC 的详细文档！

   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
   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.











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


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
                           contains only the 3270 data stream.

   SCS-DATA         0x01   The data portion of the message
                           contains SNA Character Stream data.

   RESPONSE         0x02   The data portion of the message
                           constitutes device-status information
                           and the RESPONSE-FLAG field indicates
                           whether this is a positive or negative
                           response (see below).

   BIND-IMAGE       0x03   The data portion of the message is
                           the SNA bind image from the session
                           established between the server and the
                           host application.

   UNBIND           0x04   The data portion of the message is
                           an Unbind reason code.

   NVT-DATA         0x05   The data portion of the message is to
                           be interpreted as NVT data.

   REQUEST          0x06   There is no data portion present in
                           the message.  Only the REQUEST-FLAG
                           field has any meaning.

   SSCP-LU-DATA     0x07   The data portion of the message is
                           data from the SSCP-LU session.




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


   PRINT-EOJ        0x08   There is no data portion present in
                           the message.  This value can be sent
                           only by the server, and only on a
                           printer session.

8.1.2 REQUEST-FLAG Field

   The REQUEST-FLAG field only has meaning when the DATA-TYPE field has
   a value of REQUEST; otherwise, the REQUEST-FLAG field must be ignored
   by the receiver and should be set to 0x00 by the sender.  Possible
   values for the REQUEST-FLAG field are:

   Request-Flag Name   Code                Meaning
   -----------------   ----   ---------------------------------
   ERR-COND-CLEARED    0x00   The client sends this to the server
                              when some previously encountered
                              printer error condition has been
                              cleared.  (See the section entitled
                              "The RESPONSES Function" below.)

8.1.3 RESPONSE-FLAG Field

   The RESPONSE-FLAG field only has meaning for certain values of the
   DATA-TYPE field.  For DATA-TYPE field values of 3270-DATA and SCS-
   DATA, the RESPONSE-FLAG is an indication of whether or not the sender
   of the data expects to receive a response.  In this case the possible
   values of RESPONSE-FLAG are:

   Response-Flag Name  Code                Meaning
   ------------------  ----   ---------------------------------
   NO-RESPONSE         0x00   The sender does not expect the
                              receiver to respond either
                              positively or negatively to this
                              message.  The receiver must
                              therefore not send any response
                              to this data-message.

   ERROR-RESPONSE      0x01   The sender only expects the
                              receiver to respond to this message
                              if some type of error occurred, in
                              which case a negative response must
                              be sent by the receiver.

   ALWAYS-RESPONSE     0x02   The sender expects the receiver to
                              respond negatively if an error
                              occurs, or positively if no errors
                              occur.  One or the other must
                              always be sent by the receiver.



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


   For a DATA-TYPE field value of RESPONSE, the RESPONSE-FLAG is an
   actual response to a previous data message (which must by definition
   have had a DATA-TYPE of either 3270-DATA or SCS-DATA and a RESPONSE-
   FLAG value of either ERROR-RESPONSE or ALWAYS-RESPONSE).  In this
   case the possible values of RESPONSE-FLAG are:

   Response-Flag Name  Code                Meaning
   ------------------  ----   ---------------------------------
   POSITIVE-RESPONSE   0x00   The previous message was received
                              and executed successfully with
                              no errors.

   NEGATIVE-RESPONSE   0x01   The previous message was received
                              but an error(s) occurred while
                              processing it.

   Accompanying status information will be found in the data portion of
   the message.

   For any other values of the DATA-TYPE field, the RESPONSE-FLAG field
   must be ignored by the receiver and should be set to 0x00 by the
   sender.

8.1.4 SEQ-NUMBER Field

   The SEQ-NUMBER field is only used when the RESPONSES function has
   been agreed to.  It contains a 2 byte binary number, and is used to
   correlate positive and negative responses to the data messages for
   which they were intended.  This field must be sent in network byte
   order ("big endian").  If either byte contains a 0xff, it should be
   doubled to 0xffff before sending and stripped back to 0xff upon
   receipt; this is standard IAC escaping.  See the section entitled
   "The RESPONSES Function" for further information on the use of the
   SEQ-NUMBER field.  When the RESPONSES function is not agreed to, this
   field should always be set to 0x0000 by the sender and ignored by the
   receiver.

9.  Basic TN3270E

   As has been stated earlier, whether or not the use of each of the
   TN3270E functions is allowed on a session is negotiated when the
   connection is established.  It is possible that none of the functions
   are agreed to (in this case, the function-list in the FUNCTIONS
   REQUEST and FUNCTIONS IS commands is null).  This mode of operation
   is referred to as "basic TN3270E".  Note that, since neither the
   SCS-CTL-CODES function nor the DATA-STREAM-CTL function is agreed to,
   basic TN3270E refers to terminal sessions only.




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


   Basic TN3270E requires the support of only the following TN3270E
   header values:

             Header field         Value
             ------------         -----
              DATA-TYPE          3270-DATA
              DATA-TYPE          NVT-DATA

   The REQUEST-FLAG, RESPONSE-FLAG and SEQ-NUMBER fields are not used in
   basic TN3270E.

9.1 3270 Mode and NVT Mode

   At any given time, a TN3270E connection can be considered to be
   operating in either "3270 mode" or "NVT mode".  In 3270 mode, each
   party may send data messages with the DATA-TYPE flag set to 3270-
   DATA; sending a DATA-TYPE flag set to NVT-DATA constitutes a request
   to switch modes.  In NVT mode, each party may send data messages with
   the DATA-TYPE flag set to NVT-DATA; sending 3270-DATA is a request to
   switch modes.  The connection is initially in 3270 mode when TN3270E
   operation is successfully negotiated.  When a party receives a
   message with a DATA-TYPE different from the mode it is operating in,
   the mode of operation for the connection is switched.  Switching
   modes results in the client performing the equivalent of a 3270
   Erase/Reset operation, as described in [5], using the default
   partition (screen) size.  The server cannot assume the client
   preserves any attributes of the previous environment across a mode
   switch.

   Note that even when sending NVT-DATA, each side should buffer data
   until an entire message is built (for the client, this would normally
   mean until the user presses Enter).  At that point, a complete
   TN3270E data message should be built to transmit the NVT data.

   Typically, NVT data is used by a server to interact with the user of
   a client.  It allows the server to do this using a simple NVT data
   stream, instead of requiring a 3270 data stream.  An example would be
   a server which displays a list of 3270 applications to which it can
   connect the client.  The server would use NVT data to display the
   list and read the user's choice.  Then the server would connect to
   the application, and begin the exchange of 3270 data between the
   application and the client.









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


10.  Details of Processing TN3270E Functions

   Agreement by both parties to a specific function in the FUNCTIONS
   REQUEST function-list implies agreement by each party to support a
   related set of values in the TN3270E header.  It also implies a
   willingness to adhere to the rules governing the processing of data
   messages with regard to the agreed upon function.  Either party that
   fails to accept header values associated either with agreed upon
   functions or with basic TN3270E, or attempts to use header values
   associated with a function that is not a part of basic TN3270E and
   was not agreed upon, will be considered non-conforming and in
   violation of the protocol.  The following sections detail for each
   TN3270E function the associated header values and processing rules.

10.1 The SCS-CTL-CODES Function

   This function can only be supported on a 3270 printer session.

   Agreement to support this function requires that the party support
   the following TN3270E header values:

             Header field         Value
             ------------         -----
              DATA-TYPE          SCS-DATA
              DATA-TYPE          PRINT-EOJ