rfc1205.txt

著名的RFC文档,其中有一些文档是已经翻译成中文的的.

Network Working Group                                     P. Chmielewski
Request for Comments: 1205                               IBM Corporation
                                                           February 1991


                         5250 Telnet Interface

Status of this Memo

   This RFC is being distributed in order to document the interface to
   the IBM 5250 Telnet implementation.  This information is being
   provided for hosts on the Internet that want to support the 5250 work
   station data stream within the Telnet protocol.  This memo provides
   information for the Internet community.  It does not specify any
   standard.  Distribution of this memo is unlimited.

1.  Introduction

   This RFC describes the interface to the IBM 5250 Telnet
   implementation.  The purpose of this memo is to describe the details
   of the interface so that a person wanting to implement a client
   Telnet which emulates an IBM 5250 work station would be able to do
   so.  This memo does not describe all of the 5250 commands, aid codes,
   and other information specific to the 5250 data stream.  That
   information is contained in the IBM 5250 Information Display System,
   Functions Reference Manual, IBM publication number SA21-9247.
   Corrections and additions to this manual are documented in this RFC
   in section 5.

2.  Telnet Options

   No new Telnet options are defined for 5250 mode of operation.
   However, to enable 5250 mode, both the client and server must agree
   to at least support the Binary, End-Of-Record (EOR), and Terminal-
   Type Telnet options.  The complete list of 5250 terminal types is
   maintained in the Assigned Numbers RFC and includes the following:

     IBM-5555-C01   24 x 80 Double-Byte Character Set color display
     IBM-5555-B01   24 x 80 Double-Byte Character Set (DBCS)
     IBM-3477-FC    27 x 132 color display
     IBM-3477-FG    27 x 132 monochrome display
     IBM-3180-2     27 x 132 monochrome display
     IBM-3179-2     24 x 80 color display
     IBM-3196-A1    24 x 80 monochrome display
     IBM-5292-2     24 x 80 color display
     IBM-5291-1     24 x 80 monochrome display
     IBM-5251-11    24 x 80 monochrome display




Chmielewski                                                     [Page 1]

RFC 1205                 5250 Telnet Interface             February 1991


   An example of a typical negotiation process to establish 5250 mode of
   operation is shown below.  In this example, the server initiates the
   negotiation by sending the DO TERMINAL-TYPE request.

    Server: IAC DO TERMINAL-TYPE
    Client: IAC WILL TERMINAL-TYPE
    Server: IAC SB TERMINAL-TYPE SEND IAC SE
    Client: IAC SB TERMINAL-TYPE IS IBM-5251-11 IAC SE
    (The client has specified its terminal-type is an IBM-5251-11)

    Server: IAC DO END-OF-RECORD
    Client: IAC WILL END-OF-RECORD
    Server: IAC WILL END-OF-RECORD
    Client: IAC DO END-OF-RECORD
    (The server and client have both agreed to transmit EORs)

    Server: IAC DO TRANSMIT-BINARY
    Client: IAC WILL TRANSMIT-BINARY
    Server: IAC WILL TRANSMIT-BINARY
    Client: IAC DO TRANSMIT-BINARY
    (The server and client have both agreed to binary transmission)

3.  Data Stream Format

   The actual data stream that is exchanged between the client and
   server is composed of a header followed by the 5250 work station data
   stream.  For information about the 5250 work station data stream
   refer to the IBM 5250 Information Display System, Functions Reference
   Manual (SA21-9247).  The header which prefixes the 5250 data stream
   was originally designed for the 5250 Display Station Pass-Through
   (DSPT) application.  5250 DSPT is an application similar to Telnet
   which runs on the IBM AS/400, System/36, and System/38 over an SNA
   network.  This header is designed to be variable in length and is
   composed of two parts.  The first, fixed part is always 6 octets long
   and has the following format:

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |     Logical Record Length     |       Record Type             |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |        Reserved               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Logical Record Length:  16 bits

      This field indicates the length, in octets, of this logical record
      including the header length.  The length is calculated BEFORE



Chmielewski                                                     [Page 2]

RFC 1205                 5250 Telnet Interface             February 1991


      doubling any IAC characters in the data stream.  The length does
      not include the <IAC><EOR> that is appended to the end of the data
      stream to mark the end of this logical record.  The length is
      specified with the most significant octet first.  For example, a
      length of 36 (decimal) would be specified as '0024'X.

   Record Type:  16 bits

      This field indicates the SNA record type.  It should always be set
      to '12A0'X to indicate the General Data Stream (GDS) record type.

   Reserved:  16 bits

      This field is currently not used.

   The second part of the header is designed to be variable in length.
   The length of this variable part is specified in the first octet.
   Currently this portion of the header will always be 4 octets long and
   has the following format:

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |               |E|A| | | |S|T|H|               |               |
     | Var Hdr Len   |R|T| | | |R|R|L|               |    Opcode     |
     |               |R|N| | | |Q|Q|P|               |               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Var Hdr Len:  8 bits

      The length, in octets, of the variable portion of the header.
      Currently this is always '04'X.

   Flags:  16 bits

       Bit 0:      ERR     This bit is set to indicate a data stream
                           output error.  The negative response code
                           is sent as data following the opcode field.
       Bit 1:      ATN     This bit is set to indicate that the 5250
                           attention key was pressed.
       Bits 2-4:   *       These bits are reserved (set to zero).
       Bit 5:      SRQ     This bit is set to indicate that the 5250
                           System Request key was pressed.
       Bit 6:      TRQ     This bit is set to indicate that the 5250
                           Test Request key was pressed.
       Bit 7:      HLP     This bit is set to indicate the Help in
                           Error State function.  The error code is
                           sent as data following the header and is



Chmielewski                                                     [Page 3]

RFC 1205                 5250 Telnet Interface             February 1991


                           a four digit packed decimal number.  For
                           example, an error code of '0005'X indicates
                           the operator attempted to type in an area of
                           the display that is not enabled for input.
       Bits 8-15:  *       These bits are reserved (set to zero).

   Opcode:  8 bits

      This field contains the operation code.  It is set to indicate the
      type of operation requested by the sender.  The following are the
      valid values:

         '00'X:  No Operation
         '01'X:  Invite Operation
         '02'X:  Output Only
         '03'X:  Put/Get Operation
         '04'X:  Save Screen Operation
         '05'X:  Restore Screen Operation
         '06'X:  Read Immediate Operation
         '07'X:  Reserved
         '08'X:  Read Screen Operation
         '09'X:  Reserved
         '0A'X:  Cancel Invite Operation
         '0B'X:  Turn On Message Light
         '0C'X:  Turn Off Message Light

   The actual 5250 work station data stream will immediately follow the
   opcode field in the header and will be terminated by the <IAC><EOR>
   pair.  For some operations the header will be immediately followed by
   an <IAC><EOR> without any 5250 work station data stream in between.
   For example, the following request to turn on the message light could
   be sent by the server:

        000A 12A0 0000 0400 000B FFEF
        |    |    |    | |    |  |
        |    |    |    | |    |  End Of Record marker
        |    |    |    | |    |
        |    |    |    | |    Opcode = Turn On Message Light ('0B'X)
        |    |    |    | |
        |    |    |    | Flags = '0000'X
        |    |    |    |
        |    |    |    Variable Header Length = '04'X
        |    |    |
        |    |    Reserved - Set to '0000'X
        |    |
        |    Record Type = General Data Stream ('12A0'X)
        |
        Logical Record Length = '000A'X for this record



Chmielewski                                                     [Page 4]

RFC 1205                 5250 Telnet Interface             February 1991


   In this example the requested operation is indicated by the opcode
   and there is no associated work station data stream.

4.  Data Flow Examples

   The following examples illustrate the flow of data between the client
   and server for some of the more common operations.  These examples
   are intended to show the order in which the logical records are sent
   between the client and server and the content of those records.  The
   hex representation of the records which are exchanged between the
   client and server is shown.  The way in which a client implements the
   various operations will differ between implementations and those
   details are not discussed here.  In these examples, when the value of
   a field is dependent on the length of the screen data for a
   particular logical record, it will be represented as 'LLLL'.

4.1  Query Device Example

   A Query command may be sent by the server system in order to
   determine the attributes of the device it is talking to.  When a
   client receives a Query command, it must send the Query Reply back to
   the server.  See section 5 for a complete description of the format
   for the Query command and Query Reply.

   Server: Sends Write Structured    001112A0 00000400 000304F3 0005D970
           Field Query command.      00FFEF

   Client: Responds with a Query     004712A0 00000400 00000000 88003AD9
           Reply, in this case,      70800600 01030000 00000000 00000000
           for a 3180-2.             00000000 00000001 F3F1F8F0 F0F0F202
                                     00000061 50000100 00000018 11000000
                                     00000000 000000FF EF


4.2  Cancel Invite Example

   The server will send a Cancel Invite when it needs to reverse the
   normal flow direction.  When a client receives a Cancel Invite, it
   should reply with a Cancel Invite and not send any user data until
   the server has once again "invited" the work station.  A work station
   is said to be "invited" when the server has sent a read command to
   the client.  The Cancel Invite flow is as follows:

   Server: Sends header with the     000A12A0 00000400 000AFFEF
           Opcode = Cancel Invite.

   Client: Sends header with the     000A12A0 00000400 000AFFEF
           Opcode = Cancel Invite



Chmielewski                                                     [Page 5]

RFC 1205                 5250 Telnet Interface             February 1991


           to indicate that the
           work station is no
           longer invited.

4.3  System Request Example

   The 5250 System Request operation is invoked when a client wants to
   interrupt the server job to perform some function.  The typical
   scenario would be for a user to press the system request key, or
   whatever key is mapped to a system request key, which would cause the
   client Telnet to initiate the following flow:

   Client: Sends header with the     000A12A0 00000404 0000FFEF
           System Request bit set.

   Note:  It is possible for a client to include user data in this
   record following the header.  This data would be interpreted by the
   server as an option to be selected from the system request menu.  If
   this were the case, the server would not send the system request menu
   and the flow would continue based on the option selected.  For this
   example, the client does not send any user data and the flow would
   continue as follows:

   Server: Sends header with the     000A12A0 00000400 000AFFEF
           Opcode = Cancel Invite.

   Client: Sends header with the     000A12A0 00000400 000AFFEF
           Opcode = Cancel Invite
           to indicate that the
           work station is no
           longer invited.

   Server: Sends Save (Immediate)    000C12A0 00000400 00040402 FFEF
           command with
           Opcode = Save Screen.

   Client: Sends the screen image    LLLL12A0 00000400 00040412
           to be saved.              <Screen Image> FFEF

   Server: Sends System Request      LLLL12A0 00000400 0003
           menu with                 <System Request Menu> FFEF
           Opcode = Put/Get.

   Client: Sends User Input to       LLLL12A0 00000400 0000
           the Sys Req menu.         <User Input> FFEF

   Note: What happens next will depend on the System Request option
   selected by the user.  After any System Request processing has



Chmielewski                                                     [Page 6]