rfc1647.txt

RFC 的详细文档！

Network Working Group                                          B. Kelly
Request for Comments: 1647                            Auburn University
Category: Standards Track                                     July 1994


                          TN3270 Enhancements

Status of this Memo

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.

Abstract

   This document describes a protocol that more fully supports 3270
   devices than do the existing tn3270 practices.  Specifically, it
   defines a method of emulating both the terminal and printer members
   of the 3270 family of devices via Telnet; it provides for the ability
   of a Telnet client to request that it be assigned a specific device-
   name (also referred to as "LU name" or "network name"); finally, it
   adds support for a variety of functions such as the ATTN key, the
   SYSREQ key, and SNA response handling.

   This protocol would be negotiated and implemented under a new Telnet
   Option and would be unrelated to the Telnet 3270 Regime Option as
   defined in RFC 1041 [1].

TABLE OF CONTENTS

   1.  Introduction ...............................................  2
   2.  TN3270E OVERVIEW ...........................................  3
   3.  COMMAND NAMES AND CODES ....................................  4
   4.  COMMAND MEANINGS ...........................................  5
   5.  DEFAULT SPECIFICATION ......................................  6
   6.  MOTIVATION .................................................  7
   7.  TN3270E SUB-NEGOTIATION RULES ..............................  7
      7.1  DEVICE-TYPE Negotiation ................................  7
          7.1.1 Device Pools ......................................  8
          7.1.2 CONNECT Command ...................................  9
          7.1.3 ASSOCIATE Command ................................. 10
          7.1.4 Device Selection Rules ............................ 10
          7.1.5 Accepting a Request ............................... 11
          7.1.6 REJECT Command .................................... 12
      7.2  FUNCTIONS Negotiation .................................. 13
          7.2.1 Commands .......................................... 13



Kelly                                                           [Page 1]

RFC 1647                  TN3270 Enhancements                  July 1994


          7.2.2 List of TN3270E Functions ......................... 14
   8.  TN3270E DATA MESSAGES ...................................... 15
      8.1  The TN3270E Message Header ............................. 16
          8.1.1 DATA-TYPE Field ................................... 16
          8.1.2 REQUEST-FLAG Field ................................ 17
          8.1.3 RESPONSE-FLAG Field ............................... 17
          8.1.4 SEQ-NUMBER Field .................................. 18
   9.  BASIC TN3270E .............................................. 18
      9.1  3270 Mode and NVT Mode ................................. 19
   10. DETAILS OF PROCESSING TN3270E FUNCTIONS .................... 20
      10.1 The SCS-CTL-CODES Function ............................. 20
      10.2 The DATA-STREAM-CTL Function ........................... 20
      10.3 The BIND-IMAGE Function ................................ 21
      10.4 The RESPONSES Function ................................. 22
         10.4.1 Response Messages ................................. 23
      10.5 The SYSREQ Function .................................... 26
         10.5.1 Background ........................................ 26
         10.5.2 TN3270E Implementation of SYSREQ .................. 27
   11. THE 3270 ATTN KEY .......................................... 28
   12. 3270 STRUCTURED FIELDS ..................................... 29
   13. IMPLEMENTATION GUIDELINES .................................. 29
      13.1 3270 Data Stream Notes ................................. 29
      13.2 Negotiation of the TN3270E Telnet Option ............... 30
      13.3 A "Keep-alive" Mechanism ............................... 30
      13.4 Examples ............................................... 31
   14. SECURITY CONSIDERATIONS .................................... 33
   15. REFERENCES ................................................. 33
   16. AUTHOR'S NOTE .............................................. 34
   17. AUTHOR'S ADDRESS ........................................... 34

1.  Introduction

   Currently, support for 3270 terminal emulation over Telnet is
   accomplished by the de facto standard of negotiating three separate
   Telnet Options - Terminal-Type [2], Binary Transmission [3], and End
   of Record [4].  Note that there is no RFC that specifies this
   negotiation as a standard.  RFC 1041 attempted to standardize the
   method of negotiating 3270 terminal support by defining the 3270
   Regime Telnet Option.  Very few developers and vendors ever
   implemented RFC 1041.

   This document will refer to the existing practice of negotiating
   these three Telnet Options before exchanging the 3270 data stream as
   "traditional tn3270".

   NOTE: Except where otherwise stated, this document does not
   distinguish between Telnet servers that represent SNA devices and
   those that represent non-SNA 3270 devices.



Kelly                                                           [Page 2]

RFC 1647                  TN3270 Enhancements                  July 1994


   All references in this document to the 3270 data stream, 3270 data
   stream commands, orders, structured fields and the like rely on [5].
   References to SNA Request and Response Units rely on [6].  References
   to SNA versus non-SNA operation rely on [7].

   There are several shortcomings in traditional tn3270; among them are
   the following:

    - It provides no capability for Telnet clients to emulate the 328x
      class of printers.

    - There is no mechanism by which a Telnet client can request that
      a connection be associated with a given 3270 device-name.  This
      can be of importance when a terminal session is being
      established, since many host applications behave differently
      depending on the network name of the terminal.  In the case of
      printer emulation, this capability is an absolute necessity
      because a large number of host applications have some method of
      pre-defining printer destinations.

    - The 3270 ATTN and SYSREQ keys are not universally supported.

    - There is no support for the SNA positive/negative response
      process.  This is particularly important if printer emulation is
      to function properly, but is also useful for some terminal
      applications.  A positive response is used to indicate that
      the previously received data has been successfully processed.
      A negative response indicates some sort of error has occurred
      while processing the previously received data; this could be
      caused by the host application building a 3270 data stream that
      contains an invalid command, or by a mechanical error at the
      client side, among other things.

    - There is no mechanism by which the client can access the SNA
      Bind information.  The Bind image contains a detailed
      description of the session between the Telnet server and the
      host application.

    - There is no mechanism by which the server can determine whether
      a client supports 3270 structured fields, or a client can
      request that it receive them.

2.  TN3270E Overview

   In order to address these issues, this document proposes a new Telnet
   Option - TN3270E.  Telnet clients and servers would be free to
   negotiate support of the TN3270E option or not. If either side does
   not support TN3270E, traditional tn3270 can be used; otherwise, a



Kelly                                                           [Page 3]

RFC 1647                  TN3270 Enhancements                  July 1994


   sub-negotiation will occur to determine what subset of TN3270E will
   be used on the session.  It is anticipated that a client or server
   capable of both types of 3270 emulation would attempt to negotiate
   TN3270E first, and only negotiate traditional tn3270 if the other
   side refuses TN3270E.

   Once a client and server have agreed to use TN3270E, negotiation of
   the TN3270E suboptions can begin.  The two major elements of TN3270E
   sub-negotiation are:

    - a device-type negotiation that is similar to, but somewhat
      more complicated than, the existing Telnet Terminal-Type Option.

    - the negotiation of a set of supported 3270 functions, such as
      printer data stream type (3270 data stream or SNA Character
      Stream), positive/negative response exchanges, device status
      information, and the passing of BIND information from server to
      client.

   Successful negotiation of these two suboptions signals the beginning
   of 3270 data stream transmission. In order to support several of the
   new functions in TN3270E, each data message must be prefixed by a
   header.  This header will contain flags and indicators that convey
   such things as positive and negative responses and what type of data
   follows the header (for example, 3270 data stream, SNA Character
   Stream, or device status information).

3.  Command Names and Codes

       TN3270E            40
         ASSOCIATE          00
         CONNECT            01
         DEVICE-TYPE        02
         FUNCTIONS          03
         IS                 04
         REASON             05
         REJECT             06
         REQUEST            07
         SEND               08

       Reason-codes
         CONN-PARTNER       00
         DEVICE-IN-USE      01
         INV-ASSOCIATE      02
         INV-DEVICE-NAME    03
         INV-DEVICE-TYPE    04
         TYPE-NAME-ERROR    05
         UNKNOWN-ERROR      06



Kelly                                                           [Page 4]

RFC 1647                  TN3270 Enhancements                  July 1994


         UNSUPPORTED-REQ    07

       Function Names
         BIND-IMAGE         00
         DATA-STREAM-CTL    01
         RESPONSES          02
         SCS-CTL-CODES      03
         SYSREQ             04

4.  Command Meanings

   IAC WILL TN3270E

      The sender of this command is willing to send TN3270E
      information in subsequent sub-negotiations.

   IAC WON'T TN3270E

      The sender of this command refuses to send TN3270E information.

   IAC DO TN3270E

      The sender of this command is willing to receive TN3270E
      information in subsequent sub-negotiations.

   IAC DON'T TN3270E

      The sender of this command refuses to receive TN3270E
      information.

   Note that while they are not explicitly negotiated, the equivalent of
   the Telnet Binary Transmission Option [3] and the Telnet End of
   Record Option [4] is implied in the negotiation of the TN3270E
   Option.  That is, a party to the negotiation that agrees to support
   TN3270E is automatically required to support bi-directional binary
   and EOR transmissions.

   IAC SB TN3270E SEND DEVICE-TYPE IAC SE

      Only the server may send this command.  This command is used to
      request that the client transmit a device-type and, optionally,
      device-name information.

   IAC SB TN3270E DEVICE-TYPE REQUEST <device-type>
          [CONNECT | ASSOCIATE <device-name>] IAC SE

      Only the client may send this command.  It is used in response
      to the server's SEND DEVICE-TYPE command, as well as to suggest



Kelly                                                           [Page 5]

RFC 1647                  TN3270 Enhancements                  July 1994