rfc2877.txt

来自「著名的RFC文档,其中有一些文档是已经翻译成中文的的.」· 文本 代码 · 共 1,533 行 · 第 1/5 页

Network Working Group                                     T. Murphy, Jr.
Request for Comments: 2877                                      P. Rieth
Category: Informational                                       J. Stevens
Updates: 1205                                            IBM Corporation
                                                               July 2000


                        5250 Telnet Enhancements

Status of this Memo

   This memo provides information for the Internet community.  It does
   not specify an Internet standard of any kind.  Distribution of this
   memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (2000).  All Rights Reserved.

Abstract

   This memo describes the interface to the IBM 5250 Telnet server that
   allows client Telnet to request a Telnet terminal or printer session
   using a specific device name.  If a requested device name is not
   available, a method to retry the request using a new device name is
   described.  Methods to request specific Telnet session settings and
   auto-signon function are also described.

   By allowing a Telnet client to select the device name, the 5250
   Telnet server opens the door for applications to set and/or extract
   useful information about the Telnet client.  Some possibilities are
   1) selecting a customized device name associated with a particular
   user profile name for National Language Support or subsystem routing,
   2) connecting PC and network printers as clients and 3) auto-signon
   using clear-text or DES-encrypted password exchange.

   Applications may need to use system API's on the AS/400 in order to
   extract Telnet session settings from the device name description.
   Refer to the Retrieve Device Description (QDCRDEVD) API described in
   the AS/400 System API book [3] on how to extract information using
   the DEVD0600 and DEVD1100 templates.

   This memo describes how the IBM 5250 Telnet server supports Work
   Station Function (WSF) printers using 5250 Display Station Pass-
   Through.  A response code is returned by the Telnet server to
   indicate success or failure of the WSF printer session.





Murphy, et al.               Informational                      [Page 1]

RFC 2877                5250 Telnet Enhancements               July 2000


Table of Contents

    1.  Enhancing Telnet Negotiations......................   3
    2.  Standard Telnet Option Negotiation.................   3
    3.  Enhanced Telnet Option Negotiation.................   4
    4.  Enhanced Display Emulation Support.................   7
    5.  Enhanced Display Auto-Signon and Password
        Encryption.........................................   8
        5.1   Password Substitutes Processing..............  12
        5.2   Handling passwords of length 9 and 10........  14
        5.3   Example Password Substitute Calculation......  15
    6.  Device Name Collision Processing...................  15
    7.  Enhanced Printer Emulation Support.................  16
    8.  Telnet Printer Terminal Types......................  18
    9.  Telnet Printer Startup Response Record for Printer
        Emulators..........................................  20
        9.1  Example of a Success Response Record.........   20
        9.2  Example of an Error Response Record..........   21
        9.3  Response Codes...............................   22
   10.  Printer Steady-State Pass-Through Interface........  23
        10.1  Example of a Print Record....................  25
        10.2  Example of a Print Complete Record...........  27
        10.3  Example of a Null Print Record...............  27
   11.  End-to-End Print Example...........................  28
   12.  Authors' Note......................................  33
   13.  References.........................................  33
   14.  Security Considerations............................  35
   15.  Authors' Addresses.................................  35
   16.  Relation to Other RFC's............................  35
   17.  Full Copyright Statement...........................  36

LIST OF FIGURES

   Figure 1.  Example of a success status response
              record.......................................  20
   Figure 2.  Example of an error response record..........  21
   Figure 3.  Layout of the printer pass-through
              header.......................................  23
   Figure 4.  Server sending client data with a print
              record.......................................  26
   Figure 5.  Client sending server a print complete
              record.......................................  27
   Figure 6.  Server sending client a null print
              record.......................................  28







Murphy, et al.               Informational                      [Page 2]

RFC 2877                5250 Telnet Enhancements               July 2000


1. Enhancing Telnet Negotiations

   The 5250 Telnet server enables clients to negotiate both terminal and
   printer device names through Telnet Environment Options Negotiations,
   defined in the Standards Track RFC 1572 [13].

   The purpose of RFC 1572 is to exchange environment information using
   a set of standard or custom variables.  By using a combination of
   both standard VAR's and custom USERVAR's, the 5250 Telnet server
   allows client Telnet to request a pre-defined specific device by
   name.

   If no pre-defined device exists then the device will be created, with
   client Telnet having the option to negotiate device attributes, such
   as the code page, character set, keyboard type, etc.

   Since printers can now be negotiated as a device name, new terminal
   types have been defined to request printers.  For example, you can
   now negotiate "IBM-3812-1" and "IBM-5553-B01" as valid TERMINAL-TYPE
   options [11].

   Finally, the 5250 Telnet server will allow exchange of user profile
   and password information, where the password may be in either clear-
   text or encrypted form.  If a valid combination of profile and
   password is received, then the client is allowed to bypass the sign-
   on panel.  The setting of the QRMTSIGN system value must be either
   *VERIFY or *SAMEPRF for the bypass of the sign-on panel to succeed.

2. Standard Telnet Option Negotiation

   Telnet server option negotiation typically begins with the issuance,
   by the server, of an invitation to engage in terminal type
   negotiation with the Telnet client (DO TERMINAL-TYPE) [11].  The
   client and server then enter into a series of sub-negotiations to
   determine the level of terminal support that will be used.  After the
   terminal type is agreed upon, the client and server will normally
   negotiate a required set of additional options (EOR [12], BINARY
   [10], SGA [15]) that are required to support "transparent mode" or
   full screen 5250/3270 block mode support.  As soon as the required
   options have been negotiated, the server will suspend further
   negotiations, and begin with initializing the actual virtual device
   on the AS/400.  A typical exchange might start like the following:









Murphy, et al.               Informational                      [Page 3]

RFC 2877                5250 Telnet Enhancements               July 2000


   AS/400 Telnet server              Enhanced Telnet client
   --------------------------        -------------------------
   IAC DO TERMINAL-TYPE        -->
                               <--   IAC WILL TERMINAL-TYPE
   IAC SB TERMINAL-TYPE SEND
   IAC SE                      -->
                                     IAC SB TERMINAL-TYPE IS
                               <--   IBM-5555-C01 IAC SE
   IAC DO EOR                  -->
                               <--   IAC WILL EOR
                               <--   IAC DO EOR
   IAC WILL EOR                -->
                                .
                                .
   (other negotiations)         .

   Actual bytes transmitted in the above example are shown in hex below.

   AS/400 Telnet server              Enhanced Telnet client
   --------------------------        -------------------------
   FF FD 18                    -->
                               <--   FF FB 18
   FF FA 18 01 FF F0           -->
                                     FF FA 18 00 49 42 4D 2D
                                     35 35 35 35 2D 43 30 31
                               <--   FF F0
   FF FD 19                    -->
                               <--   FF FB 19
                               <--   FF FD 19
   FF FB 19                    -->
                                .
                                .
   (other negotiations)         .

   Some negotiations are symmetrical between client and server and some
   are negotiated in one direction only.  Also, it is permissible and
   common practice to bundle more than one response or request, or
   combine a request with a response, so the actual exchange may look
   different in practice to what is shown above.

3. Enhanced Telnet Option Negotiation

   In order to accommodate the new environment option negotiations, the
   server will bundle an environment option invitation along with the
   standard terminal type invitation request to the client.






Murphy, et al.               Informational                      [Page 4]

RFC 2877                5250 Telnet Enhancements               July 2000


   A client should either send a negative acknowledgment (WONT NEW-
   ENVIRON), or at some point after completing terminal-type
   negotiations, but before completing the full set of negotiations
   required for 5250 transparent mode, engage in environment option
   sub-negotiation with the server.  A maximum of 1024 bytes of
   environment strings may be sent to the server.  A recommended
   sequence might look like the following:

   AS/400 Telnet server              Enhanced Telnet client
   --------------------------        -------------------------
   IAC DO NEW-ENVIRON
   IAC DO TERMINAL-TYPE        -->
   (2 requests bundled)
                               <--   IAC WILL NEW-ENVIRON
   IAC SB NEW-ENVIRON SEND
   VAR IAC SE                  -->
                                     IAC SB NEW-ENVIRON IS
                                     VAR "USER" VALUE "JONES"
                                     USERVAR "DEVNAME"
                                     VALUE "MYDEVICE07"
                               <--   IAC SE
                               <--   IAC WILL TERMINAL-TYPE
                                     (do the terminal type
                                     sequence first)
   IAC SB TERMINAL-TYPE SEND
   IAC SE                      -->
                                     IAC SB TERMINAL-TYPE IS
                               <--   IBM-5555-C01 IAC SE
                                     (terminal type negotiations
                                     completed)
   IAC DO EOR                  -->
   (server will continue
   with normal transparent
   mode negotiations)
                               <--   IAC WILL EOR
                                .
                                .
     (other negotiations)       .

   Actual bytes transmitted in the above example are shown in hex below.

   AS/400 Telnet server              Enhanced Telnet client
   --------------------------        -------------------------
   FF FD 27
   FF FD 18                    -->
   (2 requests bundled)
                               <--   FF FB 27
   FF FA 27 01 00 FF F0        -->



Murphy, et al.               Informational                      [Page 5]

RFC 2877                5250 Telnet Enhancements               July 2000


                                     FF FA 27 00 00 55 53 45
                                     52 01 4A 4F 4E 45 53 03
                                     44 45 56 4E 41 4D 45 01
                                     4D 59 44 45 56 49 43 45
                               <--   30 37 FF F0
                               <--   FF FB 18
                                     (do the terminal type
                                     sequence first)
   FF FA 18 01 FF F0           -->
                                     FF FA 18 00 49 42 4D 2D
                                     35 35 35 35 2D 43 30 31
                               <--   FF F0
   FF FD 19                    -->
   (server will continue
   with normal transparent
   mode negotiations)
                               <--   FF FB 19
                                .
                                .
   (other negotiations)         .