rfc2355.txt

<VC++网络游戏建摸与实现>源代码

Network Working Group                                           B. Kelly
Request for Comments: 2355                             Auburn University
Obsoletes: 1647                                                June 1998
Category: Standards Track


                          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.

Copyright Notice

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

Abstract

   This document describes a protocol that more fully supports 3270
   devices than do traditional 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 is negotiated under the TN3270E Telnet Option, and is
   unrelated to the Telnet 3270 Regime Option as defined in RFC 1041
   [1].

TABLE OF CONTENTS

   1.  Introduction ...............................................  2
      1.1  Changes to RFC 1647 ....................................  4
   2.  TN3270E OVERVIEW ...........................................  5
   3.  COMMAND NAMES AND CODES ....................................  6
   4.  COMMAND MEANINGS ...........................................  7
   5.  DEFAULT SPECIFICATION ......................................  9
   6.  MOTIVATION .................................................  9
   7.  TN3270E SUB-NEGOTIATION RULES ..............................  9
      7.1  DEVICE-TYPE Negotiation ................................  9
          7.1.1 Device Pools ...................................... 10
          7.1.2 CONNECT Command ................................... 12



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


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

1.  Introduction

   Traditionally, support for 3270 terminal emulation over Telnet has
   been 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.





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


   This document will refer to the existing practice of negotiating
   these three Telnet Options before exchanging the 3270 data stream as
   "traditional tn3270".  Traditional tn3270 is documented in [10].

   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.

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

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119.

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

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

    - There was no mechanism by which a Telnet client could 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 were not universally supported.

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






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


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

    - There was no mechanism by which the server could determine whether
      a client supported 3270 structured fields, or a client could
      request that it receive them.

1.1 Changes to RFC 1647

   This document replaces RFC 1647; the following is a summary of the
   changes that have been incorporated:

   - Reworded the Introduction to refer to traditional tn3270 in the
     past tense.

     Affected sections: 1.

   - Added this section documenting changes to RFC 1647

     Affected sections: 1.1

   - Clarified the specification of numeric literals contained in the
     document.

     Affected sections: 3. (first paragraph)

   - Extensively revised several sections to

     1) clarify the motivation behind and use of the ASSOCIATE
        command
     2) remove restrictive wording regarding the organization
        and use of server maintained device pools
     3) distinguish between device-names and resource-names in the
        TN3270E device-type negotiation, and define a maximum length for
        device-names and resource-names

     Affected sections: 4. (DEVICE-TYPE REQUEST command) and 7.1.1
                            through 7.1.6

   - Corrected the erroneous specification of the format of the
     function-list sent during TN3270E functions negotiation.

     Affected sections: 7.2.1 (first paragraph)







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


   - Added a statement addressing what a client or server should do
     if an impasse is reached during TN3270E functions negotiation.

     Affected sections: 7.2.1 (last paragraph)

   - Added a DATA-TYPE of PRINT-EOJ with a value of 0x08 to support
     the end-of-job indication for printers.

     Affected sections: 8.1.1, 10.1, 10.2

   - Clarified the description of the SEQ-NUMBER Field to state that

     1) the field should be sent in network byte order (big endian)
     2) either byte that contains a 0xff must be doubled to 0xffff
        before sending, and stripped back to 0xff after receipt.

     Affected sections: 8.1.4

   - Defined the format and maximum length of the Bind image.

     Affected sections: 10.3 (fourth paragraph)

   - Clarified the misleading wording regarding allowable DATA-TYPEs
     when BIND-IMAGE has been negotiated and a BIND has been sent.

     Affected sections: 10.3 (last paragraph)

   - Clarified the use of the SEQ-NUMBER field in regards to when it
     should be reset to zero.

     Affected sections: 10.4 (last paragraph)

   - Clarified the format of the data when the DATA-TYPE field is
     SSCP-LU-DATA.

     Affected sections: 10.5.2 (fourth paragraph)

   - Reworded the Security section to refer to Kerberos.

     Affected sections: 14.

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
   sub-negotiation will occur to determine what subset of TN3270E will



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


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