rfc1576.txt

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

Network Working Group                                          J. Penner
Request for Comments: 1576                                     DCA, Inc.
Category: Informational                                     January 1994


                        TN3270 Current Practices

Status of this Memo

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

Abstract

   This document describes the existing implementation of transferring
   3270 display terminal data using currently available telnet
   capabilities.  The name traditionally associated with this
   implementation is TN3270.

   Information is provided to aid in the implementation of TN3270
   servers as well as client terminal emulators.

   The following areas pertaining to TN3270 implementations are covered
   in this document:

      1. the telnet options negotiated to transition from a NVT ASCII
         state to a TN3270 state ready to process incoming 3270 data
         stream commands

      2. the method for sending and receiving 3270 data

      3. the method of handling some special keys known as SYSREQ and
         ATTN using current available telnet commands

      4. the events that will transition a TN3270 session back to an NVT
         session

Table of Contents

      1.  Motivation  . . . . . . . . . . . . . . . . . . .   2
      2.  Background  . . . . . . . . . . . . . . . . . . .   2
      3.  Telnet Options and Commands Used  . . . . . . . .   4
      4.  Connection Negotiation  . . . . . . . . . . . . .   4
      4.1 3270 Regime Option  . . . . . . . . . . . . . . .   6
      4.2 Suppress Go Ahead Option  . . . . . . . . . . . .   6
      4.3 Echo Option . . . . . . . . . . . . . . . . . . .   6
      4.4 Timing Mark Option  . . . . . . . . . . . . . . .   7



TN3270 Enhancements Working Group                               [Page 1]

RFC 1576                TN3270 Current Practices            January 1994


      5.  Testing for session presence  . . . . . . . . . .   7
      6.  Handling 3270 data  . . . . . . . . . . . . . . .   7
      7.  3270 Structured Fields  . . . . . . . . . . . . .   8
      8.  The 3270 ATTN (Attention) Key . . . . . . . . . .   8
      9.  The 3270 SYSREQ Key . . . . . . . . . . . . . . .   9
      10. Items not addressed by TN3270 . . . . . . . . . .  10
      11. References  . . . . . . . . . . . . . . . . . . .  10
      12. Security Considerations . . . . . . . . . . . . .  11
      13. Author's Note . . . . . . . . . . . . . . . . . .  11
      14. Author's Address  . . . . . . . . . . . . . . . .  12

1. Motivation

   3270 display terminal data differs from traditional display terminal
   data in that it is block mode and uses EBCDIC instead of ASCII
   character representation. These two differences are the primary
   reason for the differentiation of TN3270 from standard Telnet in this
   document.

2. Background

   Existing complex IBM 3270 display terminal networks are not easily
   integrated with the increasing number of multi-platform networking
   environments, specifically TCP/IP. These complex networks include
   terminals attached to a 3270 host using SNA (Systems Network
   Architecture) and non-SNA connections. To address the issue of easily
   connecting display terminals to 3270 hosts using IP networks, several
   vendors have introduced telnet servers that provide TCP/IP users a
   connection to existing IBM mainframes by supporting display terminal
   emulation using a subset of the existing telnet protocol.  Telnet
   servers may exist on the host itself, or be connected to the host
   using SNA or non-SNA methods.

   IBM terminals are generically referred to as 3270's which includes a
   broad range of terminals and devices, not all of which actually begin
   with the numbers 327x.

   3270 terminals in the IBM SNA network environment have two sessions
   with the host computer application. One is used for communicating
   with the host application, the other is used for communicating with
   the SSCP (System Services Control Point) that links the terminal with
   the appropriate host computer.  For the purposes of TN3270, this
   distinction is not apparent or relevant since there is actually only
   a single telnet session with the host computer or server.  On an IBM
   SNA network, the 3270 terminal has a special key that toggles between
   the two sessions (SYSREQ).  A brief discussion on how some telnet
   servers deal with this is included.




TN3270 Enhancements Working Group                               [Page 2]

RFC 1576                TN3270 Current Practices            January 1994


   In an SNA environment, a client session is identified by a Logical
   Unit (LU) name.  In a non-SNA environment, there is not a LU name
   associated with a client session.  The closest thing to a LU name in
   the TN3270 environment is the client's IP address.  Although some
   telnet servers are connected to the host using SNA, TN3270 clients
   using these servers have no defined way to determine the LU name
   associated with the session.

   Telnet servers that exist in non-SNA environments do not have to be
   concerned about providing TN3270 clients with support for the SNA
   functions described in this document.

   TN3270 does not support typical SNA responses and is classified as a
   non-SNA protocol.  A TN3270 emulator is not aware or concerned about
   how the telnet server is connected to a 3270 host application.

   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.

   Some typical "SNA" functions such as the SYSREQ and ATTN keys have
   been mapped to existing telnet commands and are supported by some
   telnet server implementations.

   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].  This negotiation and the resulting data flow will be
   described below.

   RFC 1041 [1] attempted to standardize the method of negotiating 3270
   terminal support by defining the 3270 Regime Telnet Option.
   Historically, very few developers and vendors ever implemented RFC
   1041.

   All references in this document to the 3270 datastream, SNA versus
   non-SNA operation, 3270 datastream commands, orders, structured
   fields and the like rely on [6].

   References to SNA Request and Response Units rely on [7].  References
   to SNA and SSCP rely on [12].










TN3270 Enhancements Working Group                               [Page 3]

RFC 1576                TN3270 Current Practices            January 1994


3. Telnet Options and Commands Used

   TN3270 makes use of existing Telnet options and does not define any
   additional options or commands.

       Telnet option    Value (decimal)
       -------------    ---------------
       BINARY            0
       TERMINAL-TYPE    24
       EOR              25

   Additional options may be used during a TN3270 session and are
   interpreted as per their respective RFCs. These are [1] 3270-REGIME,
   [8] SUPPRESS-GO-AHEAD, [9] ECHO and [10] TIMING-MARK. Other options
   should be rejected unless they are specifically handled by the client
   for NVT mode.

   Commands that may be encountered during a TN3270 session and are
   described in RFC 854 [11] include NOP, BREAK and Interrupt Process.

4. Connection Negotiation

   The following example shows a TN3270-capable server and a TN3270
   client establishing a connection:

   The TCP/IP port used to connect with is 23 (Telnet).

   At any place before and during the TN3270 connection negotiation
   process, other telnet commands and data may be transferred and will
   be interpreted under the existing telnet state. Some existing TN3270
   servers start a client connection using an NVT telnet dialog to
   establish parameters needed to complete the TN3270 connection to the
   desired host.

   The order of negotiating terminal type, EOR and BINARY is not
   significant, this example shows a typical TN3270 connection.

      Server:  IAC DO TERMINAL-TYPE

      Client:  IAC WILL TERMINAL-TYPE

      Server:  IAC SB TERMINAL-TYPE SEND IAC SE

      Client:  IAC SB TERMINAL-TYPE IS <terminal type>IAC SE

      where <terminal type> is a string consisting of terminal model,
      type and support of enhanced attribute bytes; an example is IBM-
      3278-2.  The acceptable values are listed in RFC 1340, Assigned



TN3270 Enhancements Working Group                               [Page 4]

RFC 1576                TN3270 Current Practices            January 1994


      Numbers [5].  Other values are in use that do not exist in [5].

      The -2 following 3278 designates the alternate screen size.  3270
      terminals have the ability to switch between the standard (24x80)
      screen size and an alternate screen size.  Model -2 is 24x80 which
      is the same as the standard size.  Model -3 is 32x80, model -4 is
      43x80 and model -5 is 27x132.

      Appending the two character string "-E" to the end of the terminal
      type signifies that the terminal is capable of handling 3270
      extended data stream. This is interpreted to mean that the
      terminal is able to handle structured fields, which are described
      below.  Some telnet server implementations also interpret this to
      mean that the terminal is capable of handling extended attributes
      (highlighting, field validation, character set, outlining, etc.)
      [6].

      The 3279 series of terminals is capable of extended attributes
      while the 3278 series is not.

      Server:  IAC DO EOR IAC WILL EOR
      Client:  IAC WILL EOR IAC DO EOR
      Server:  IAC DO BINARY IAC WILL BINARY
      Client:  IAC WILL BINARY IAC DO BINARY
      Server:  <3270 data stream> IAC EOR
      Client:  <3270 data stream> IAC EOR
           .            .
           .            .

   To terminate the connection the socket is closed by one of the
   session partners. Typically, when the user logs off of the host, the
   telnet server closes the connection.

   If the telnet server wishes to go back to NVT mode, it may issue the
   following telnet options:

       Server:  IAC WONT BINARY
       Client:  IAC DONT BINARY

           or

       Server:  IAC WONT EOR
       Client:  IAC DONT EOR

   Either one of the above two cases causes the connection to not
   satisfy the requirements for a valid TN3270 session. The telnet
   client would then process data from the server as though it were NVT
   ASCII data.



TN3270 Enhancements Working Group                               [Page 5]

RFC 1576                TN3270 Current Practices            January 1994


   The following examples show how a TN3270 client handles the 3270-
   REGIME, SUPPRESS-GO-AHEAD, ECHO and TM options.

4.1 3270 Regime Option

   Very few servers support the 3270 Regime Telnet Option.  If the
   client does not support this option and responds negatively as shown
   in the following example, the server will proceed on to the more
   typical example shown above.

      Server:  IAC DO 3270-REGIME
      Client:  IAC WONT 3270-REGIME
       Normal negotiation:
      Server:  IAC DO TERMINAL-TYPE
         ...  (see above)

4.2 Suppress Go Ahead Option

   The Suppress Go Ahead option [8] is requested by some servers. The
   Suppress Go Ahead option RFC lists the default as being go aheads are
   transmitted to signal the receiver to begin transmitting.  Since
   TN3270 negotiates binary and end-of-record and is a block mode
   protocol, the telnet go ahead character is not sent.  Most servers do
   not negotiate this option even though they do not use the telnet go
   ahead character.

      Server:  IAC DO SUPPRESS-GO-AHEAD
      Client:  IAC WILL SUPPESS-GO-AHEAD

4.3 Echo Option

   The Echo option [9] is negotiated by those servers that make use of
   the telnet NVT mode to allow the user to enter information prior to
   negotiating the options necessary for TN3270.  This information
   includes but is not limited to user identification, password and
   destination 3270 host.  Some servers accept the default for this
   option which is for the client to not do a local echo of characters
   the user enters at the keyboard. This allows the server to decide if
   it should echo characters back to the client (or not in the case of
   password). Echoing characters back to the client causes slow response
   time since every character is typically echoed individually. Because
   of this, some servers negotiate for the client to do it's own local
   echoing (except for passwords). The following example illustrates
   this case.







TN3270 Enhancements Working Group                               [Page 6]