Re: Stds track RFC Internet Draft

Fred Bohle <fab@md.interlink.com> Wed, 21 July 1993 15:10 UTC

Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa04085; 21 Jul 93 11:10 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa04080; 21 Jul 93 11:10 EDT
Received: from list.nih.gov by CNRI.Reston.VA.US id aa12678; 21 Jul 93 11:10 EDT
Received: from LIST.NIH.GOV by LIST.NIH.GOV (IBM VM SMTP V2R2) with BSMTP id 5818; Wed, 21 Jul 93 11:09:32 EDT
Received: from LIST.NIH.GOV by LIST.NIH.GOV (Mailer R2.10 ptf000) with BSMTP id 5811; Wed, 21 Jul 93 11:08:52 EDT
Date: Wed, 21 Jul 1993 11:07:38 EDT
Reply-To: IETF TN3270E Working Group List <TN3270E@list.nih.gov>
X-Orig-Sender: IETF TN3270E Working Group List <TN3270E@list.nih.gov>
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Fred Bohle <fab@md.interlink.com>
Subject: Re: Stds track RFC Internet Draft
X-To: TN3270E@LIST.NIH.GOV
To: Multiple recipients of list TN3270E <TN3270E@list.nih.gov>
Message-ID: <9307211110.aa12678@CNRI.Reston.VA.US>

> Here are my comments about the draft.  They start with a >.

TN3270 Enhancements Working Group                             B. Kelly
Internet Draft                                       Auburn University
                                                             July 1993


                        TN3270 Enhancements


Status of this Memo

   This document is an Internet Draft.  Internet Drafts are working
   documents of the Internet Engineering Task Force (IETF), its Areas,
   and its Working Groups.  Note that other groups may also distribute
   working documents as Internet Drafts.

   Internet Drafts are draft documents valid for a maximum of six
   months.  Internet Drafts may be updated, replaced, or obsoleted by
   other documents at any time.  It is not appropriate to use Internet
   Drafts as reference material or to cite them other than as a
   "working draft" or "work in progress."

   Please check the 1id-abstracts.txt listing contained in the
   internet-drafts Shadow Directories on ds.internic.net,
   nic.nordu.net, ftp.nisc.sri.com, or munnari.oz.au to learn the
   current status of any Internet Draft.

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
















B. Kelly                 Expires January 1994                 [Page 1]


Internet Draft           TN3270 Enhancements                 July 1993


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 .................................................  6
   7.  IMPLEMENTATION RULES .......................................  6
      7.1  DEVICE-TYPE Negotiation ................................  7
      7.2  FUNCTIONS Negotiation .................................. 11
   8.  TN3270E DATA MESSAGES ...................................... 13
      8.1  The TN3270E Message Header ............................. 13
          8.1.1 DATA-TYPE Field ................................... 14
          8.1.2 REQUEST-FLAG Field ................................ 14
          8.1.3 RESPONSE-FLAG Field ............................... 15
   9.  BASIC TN3270E .............................................. 16
   10. DETAILS OF PROCESSING TN3270E FUNCTIONS .................... 16
      10.1 The SNA-CHAR-STREAM Function ........................... 16
      10.2 The DATA-STEAM-CTL Function ............................ 17
      10.3 The BIND-IMAGE Function ................................ 17
      10.4 The RESPONSE Function .................................. 18
   11. THE 3270 ATTN KEY .......................................... 21
   12. THE 3270 SYSREQ KEY ........................................ 21
   13. 3270 STRUCTURED FIELDS ..................................... 22
   14. EXAMPLES ................................................... 23
   15. REFERENCES ................................................. 25
   16. AUTHOR'S NOTE .............................................. 26
   17. AUTHOR'S ADDRESS ........................................... 26


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.  Unfortunately, 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 datastream 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.

   All references in this document to the 3270 datastream, SNA versus
   non-SNA operation, 3270 datastream commands, orders, structured

B. Kelly                 Expires January 1994                 [Page 2]


Internet Draft           TN3270 Enhancements                 July 1993


   fields and the like rely on [6].  References to SNA Request and
   Response Units 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 at the client
      while processing the previously received data; this could be
      caused by the host application building a 3270 datastream 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.

    - It is not clear whether clients should support 3270 structured
      fields.


2.  TN3270E Overview

   In order to address these issues, this document proposes a new
   Telnet Option - TN3270E (option number has yet to be assigned).
   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 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.

B. Kelly                 Expires January 1994                 [Page 3]


Internet Draft           TN3270 Enhancements                 July 1993


   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 datastream type (3270 datastream 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 datastream 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 datastream, SNA Character Stream, or device status
   information).


3.  Command Names and Codes

       TN3270E        (to be assigned)
         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
         UNSUPPORTED-REQ    07

       Function Names
         BIND-IMAGE         00
         DATA-STREAM-CTL    01
         RESPONSES          02
         SNA-CHAR-STREAM    03


B. Kelly                 Expires January 1994                 [Page 4]


Internet Draft           TN3270 Enhancements                 July 1993


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
      another device-type after the server has sent a DEVICE-TYPE
      REJECT command (see below).  This command requests emulation of
      a specific 3270 device type and model.  The REQUEST command may
      optionally include either the CONNECT or the ASSOCIATE command
      (but not both).  If present, CONNECT and ASSOCIATE must both be
      followed by <device-name>.  (See the section enentitled
      "Implementation Rules" for more detailed information.)

   IAC SB TN3270E DEVICE-TYPE IS <device-type> CONNECT
          <device-name> IAC SE

      Only the server may send this command.  This command is used to
      accept a client's DEVICE-TYPE REQUEST command.

B. Kelly                 Expires January 1994                 [Page 5]


Internet Draft           TN3270 Enhancements                 July 1993


   IAC SB TN3270E DEVICE-TYPE REJECT REASON <reason-code> IAC SE

      Only the server may send this command.  This command is used to
      reject a client's DEVICE-TYPE REQUEST command.

   IAC SB TN3270E FUNCTIONS REQUEST <function-list> IAC SE

      Either side may send this command.  This command is used to
      suggest a set of 3270 functions that will be supported on this
      session.  It is also sent as an implicit rejection of a previous
      FUNCTIONS REQUEST command sent by the other side (see the
      section entitled "Implementation Rules" for more information).
      Note that when used to reject a FUNCTIONS REQUEST command, the
      function-list must not be identical to that received in the
      previous REQUEST command.

   IAC SB TN3270E FUNCTIONS IS <function-list> IAC SE

      Either side may send this command.  This command is sent as a
      response to a FUNCTIONS REQUEST command and implies acceptance
      of the set of functions sent to it in the REQUEST command.  Note
      that the list of functions in the FUNCTIONS IS command must
      match the list that was received in the previous FUNCTIONS
      REQUEST command.

>
> Is there a need to separate the negotiations into two parts?  Can't they
> be combined?  Just delimit the two lists by DEVICE-TYPE and FUNCTIONS and
> end with IAC SE.
>

5.  Default Specification

   WON'T TN3270E

   DON'T TN3270E

   i.e., TN3270E will not be used.


6.  Motivation

   See the section entitled "Introduction."


7.  Implementation Rules

   All TN3270E commands and parameters are NVT ASCII strings in which
   upper and lower case are considered equivalent.

   Once it has been agreed that TN3270E will be supported, the first
   sub-negotiation must concern the DEVICE-TYPE (and possibly
   DEVICE-NAME) information.  Only after that has been successfully
   negotiated can the client and server exchange FUNCTIONS
   information.  Only after both DEVICE-TYPE and FUNCTIONS have been
   successfully negotiated can 3270 datastream transmission occur.


B. Kelly                 Expires January 1994                 [Page 6]


Internet Draft           TN3270 Enhancements                 July 1993


   7.1 DEVICE-TYPE Negotiation

      Device-type (and device-name) negotiation begins when the server
      transmits the DEVICE-TYPE SEND command to the client.  The client
      responds with the DEVICE-TYPE REQUEST command, which must include
      a device-type and may include a device-name request.

      Valid device-types are those defined in the "Assigned Numbers"
      RFC [5] in the section entitled "Telnet Terminal Names",
      restricted to the subset of names that represent IBM 3270
      terminals, plus the following:

          IBM-3287-1
>
>  Let's list them all.  Copy the list from Assigned Numbers.
>  And shouldn't we only list the ones with the -E suffix, since
>  we are requiring the support of Query?  We said before that
>  the -E suffix really meant support of Query.
>

      The above list specifies the names of 3270 printer devices.

      An explanation of the CONNECT and ASSOCIATE commands first
      requires a discussion of the organization of terminal and
      printer device pools that the server maintains and from which it
      selects device-names to assign to session requests.  (The terms
      "device-name", "LU name" and "network name" can be considered
      interchangeable in this document.)  Also, for the purposes of
      this discussion, the term "generic session request" will be used
      to describe a request for a session from a Telnet client (either
      traditional or TN3270E) that does not include a request for a
      specific device-name.  The term "specific session request" will
      be used to describe a request for a session from a TN3270E
      client that includes a request for a specific device-name
      (either via CONNECT or ASSOCIATE).

      As is the case with traditional tn3270, the TN3270E server must
      maintain a set of terminal device-names.  A generic request for
      a terminal session would result in the server selecting any
      availabe device-name from this pool.  The server, however, may
      also maintain a separate pool of terminal device-names which can
      only be used to satisfy specific terminal session requests.
      This is to ensure that a terminal device that has some
      significance to host applications (and is therefore likely to be
      the target of a specific session request) is not "accidentally"
      assigned to a generic request and winds up associated with a
      client that has no use for it.  Note that the reverse situation
      is allowed.  That is, a specific terminal session request could
      ask for a device-name that happens to be in the "generic
      terminal pool."  The nature of the host applications would
      probably mean that such a request has no real use, but it does
      no harm to allow the connection to be established.

>
>  Steve D'angona asked me to support Reconnect by sending certain
>  status codes when we disconnect.  Allowing the user to select a
>  specific terminal from the generic pool would allow support of
>  Reconnect.  By the way Steve, if you are listening, what are the
>  status codes you want us to send?
>

      For each terminal device (in both the "generic" and the
      "specific" pools), the TN3270E server could also have defined a
      "partner" or "paired" printer device.  There should be a unique,
      one-to-one mapping between a terminal and its associated


B. Kelly                 Expires January 1994                 [Page 7]


Internet Draft           TN3270 Enhancements                 July 1993


      printer.  The reasoning behind such a configuration is to allow
      for those host applications that produce printed output bound
      for a printer whose device-name is determined by the device-name
      of the terminal that initiated the print request.  These printer
      devices can only be assigned to specific printer session
      requests that use the ASSOCIATE command (see below).

      In addition, the TN3270E server may also maintain a pool of
      printer device-names that are not associated with any terminal.
      These printer devices can only be assigned to specific printer
      session requests that use the CONNECT command (see below).  This
      allows for those host applications that generate printed output
      bound for a printer whose device-name is determined by something
      other than the device-name of the terminal that initiated the
      print request (for example, when the userid of the person signed
      on to a terminal determines the print destination).

      Finally, it is possible that a pool of printer device-names
      could be maintained and used only to satisfy generic requests
      for printers.

      CONNECT is used by the client to request that the server
      associate a specific device-name with this Telnet session; it
      may be used when requesting either a terminal or a printer
      session.  The specified device-name must not conflict with the
      device-type; e.g., if the client requests DEVICE-TYPE IBM-3287-1
      (a printer) and specifies CONNECT T1000001, but T1000001 is
      defined at the host as a terminal, then the server should deny
      the request.  Further, if the requested device-name is already
      associated with some other Telnet session, or if it is not
      defined to the server, the server should deny the request.

      ASSOCIATE can be used by the client only when requesting a
      DEVICE-TYPE that represents a printer. The ASSOCIATE command
      requests that this session be assigned the device-name of the
      printer that is paired with the terminal named in the request.
      If the device-type does not represent a printer, or if the
      device-name is not that of a terminal, then the server should
      deny the request.  It is anticipated that the device-name
      specified in this request would be one returned by the server
      when accepting a previous terminal session request (see the IS
      command below).  Since no means of authentication has been
      provided for, it is possible that the printer paired with the
      terminal specified in the ASSOCIATE command has already been
      assigned to some other Telnet session; in this case, the server
      should deny the request.

      To summarize, assume a TN3270E server has the following device
      pools defined to it (device-names that begin with a "T" are
      terminal devices; those that begin with a "P" are printers):



B. Kelly                 Expires January 1994                 [Page 8]


Internet Draft           TN3270 Enhancements                 July 1993


       Generic Terminal Pool              Specific Terminal Pool
       ---------------------              ----------------------
       TG000001 <--> PTG00001             TS000001 <--> PTS00001
       TG000002 <--> PTG00002             TS000001 <--> PTS00002
       TG000003 <--> PTG00003             TS000001 <--> PTS00003

       Generic Printer Pool               Specific Printer Pool
       --------------------               ----------------------
            PG000001                            PS000001
            PG000002                            PS000002
            PG000003                            PS000003

      Note that the only pool that absolutely must be defined to the
      server is the generic terminal pool.  The absence of other pools
      (or of partner printers for a terminal pool) simply means that
      the server is unable to satisfy as wide a variety of requests as
      would be possible if all pools were defined to it.

      Given the above configuration, the following rules apply:

      - a generic terminal request can only be satisfied from the
        generic terminal pool (device-names TG000001 - TG000003).

      - a specific terminal request (allowable only via the CONNECT
        command) can be satisfied from either the generic or the
        specific terminal pool, although it is anticipated that the
        majority of such requests would ask for terminals in the
        specific terminal pool (TS000001 - TS000003).

      - a generic printer request can only be satisfied from the
        generic printer pool (device-names PG000001 - PG000003).

      - a specific printer request may come in one of two forms:

        via ASSOCIATE: the request can only be satisfied using the
                       partner of the specified terminal, which
                       may be in the generic or the specific
                       terminal pool; therefore, devices in the
                       ranges PTG00001 - PTG00003 and PTS00001 -
                       PTS00003 can be used to satisfy the request.

        via CONNECT:   the request can be satisfied either from
                       the generic or the specific printer pools
                       (although, as with specific terminal requests,
                       it is likely that most such requests will name
                       printers in the specific printer pool); this
                       request cannot be satisfied with the partner
                       printer of a terminal in either the specific or
                       the generic terminal pools.




B. Kelly                 Expires January 1994                 [Page 9]


Internet Draft           TN3270 Enhancements                 July 1993


      The server must accept the client's request or deny it as a
      whole - it cannot, for example, accept the DEVICE-TYPE request
      but deny the CONNECT portion.

      If the server wishes to accept the request, it sends back the
      DEVICE-TYPE IS command confirming the requested device-type and
      the CONNECT command specifying the device-name of the terminal
      or printer assigned to this Telnet session.  This device-name
      may be the one directly requested (via CONNECT) by the client,
      the one indirectly requested (via ASSOCIATE) by the client, or
      one assigned by the server if the client specified neither
      CONNECT nor ASSOCIATE.

      If the server wishes to deny the request, it sends back the
      DEVICE-TYPE REJECT command with one of the following
      reason-codes:

         Reason code name         Explanation
         ----------------         -----------------------------------
         INV-DEVICE-TYPE          The server does not support the
                                  requested device-type

         INV-DEVICE-NAME          The device-name specified in the
                                  CONNECT or ASSOCIATE command is
                                  not known to the server

         DEVICE-IN-USE            The requested device-name is
                                  already associated with another
                                  Telnet session

         TYPE-NAME-ERROR          The requested device-name is
                                  incompatible with the requested
                                  device-type (such as terminal/
                                  printer mismatch)

         UNSUPPORTED-REQ          The server is unable to satisfy
                                  the type of request sent by the
                                  client; e.g., a specific terminal
                                  or printer was requested but the
                                  server does not have such a pool of
                                  device-names defined to it, or the
                                  ASSOCIATE command was used but no
                                  partner printers are defined to the
                                  server

         INV-ASSOCIATE            The client used the ASSOCIATE
                                  command and either the device-type
                                  is not a printer or the device-name
                                  is not a terminal




B. Kelly                 Expires January 1994                [Page 10]


Internet Draft           TN3270 Enhancements                 July 1993


         CONN-PARTNER             The client used the CONNECT command
                                  to request a specific printer but
                                  the device-name requested is the
                                  partner to some terminal

         UNKNOWN-ERROR            Any other error in device type or
                                  name processing has occurred

      The process of negotiating a device-type and device-name that
      are acceptable to both client and server may entail several
      iterations of DEVICE-TYPE REQUEST and DEVICE-TYPE REJECT
      commands.  The client should make use of the reason-code
      specified by the server in any DEVICE-TYPE REJECT command(s) to
      minimize the amount of negotiation necessary.  For example, if
      the client initially requests that it be assigned a specific
      terminal device-name via the CONNECT command, and the server
      rejects the request with a reason-code of UNSUPPORTED-REQ, the
      client should make no further specific terminal requests in the
      negotiations.  If at any point in the process either side wishes
      to "bail out," it can simply send a WON'T (or DON'T) TN3270E
      command to the other side.  At this point both sides are free to
      negotiate other Telnet options (including traditional tn3270).


   7.2 FUNCTIONS Negotiation

      Once the DEVICE-TYPE negotiation has successfully completed
      (i.e, when the client receives the DEVICE-TYPE IS command), the
      client should initiate the FUNCTIONS negotiation by sending the
      FUNCTIONS REQUEST command to the server.  After this initial
      REQUEST command, both sides are free to transmit FUNCTIONS
      REQUEST and FUNCTIONS IS commands as needed.

      The FUNCTIONS REQUEST command contains a list of the 3270
      functions that the sender would like to see supported on this
      session.  All functions not in the list are to be considered
      unsupported.  The function-list consists of a string of 2-byte
      entries separated from one another by a single space character.
      The list is terminated by the IAC code that precedes the SE
      command.  Functions may appear in any order in the list.

      Upon receipt of a FUNCTIONS REQUEST command, the recipient has
      two choices:

       - it may respond in the positive (meaning it agrees to support
         all functions in the list, and not to transmit any data
         related to functions not in the list).  To do this, it sends
         the FUNCTIONS IS command with the function-list exactly as it
         was received.  At this point, FUNCTIONS negotiation has
         successfully completed.



B. Kelly                 Expires January 1994                [Page 11]


Internet Draft           TN3270 Enhancements                 July 1993


       - it may respond in the negative by sending a FUNCTIONS
         REQUEST command in which the function-list differs from the
         one it received (and not simply in the order of appearance
         of functions in the list; at least one function must have
         been added to, or removed from, the list).

      To avoid endlessly looping, neither party should add to the
      function-list it receives any function that it has previously
      added and that the other side has removed.

      The process of sending FUNCTIONS REQUEST commands back and forth
      continues until one side receives a function-list it is willing
      to live with.  It uses the FUNCTIONS IS command to accept the
      list, and, once this command is received by the other side, all
      necessary negotiation has been completed.  At this point, 3270
      datastream transmission can begin.

      Note that it is possible that the function-list agreed to is
      null; this is referred to as "basic TN3270E."  See the section
      entitled "Basic TN3270E" for more information.

      The following list briefly describes the 3270 functions that may
      be negotiated in the function-list:

          Function Name       Description
          -------------       -----------
         SNA-CHAR-STREAM     (Printer sessions only).  Allows the use
                             of the SNA Character Stream (SCS) on the
                             session.  SCS is used with LU type 1 SNA
                             sessions.

         DATA-STREAM-CTL     (Printer sessions only).  Allows the use
                             of the standard 3270 datastream.  This
                             corresponds to LU type 3 SNA sessions.
                             DATA-STREAM-CTL is mutually exclusive
                             with SNA-CHAR-STREAM (only one of these
                             should appear in a function-list).

         RESPONSES           Provides support for positive and
                             negative response handling.  Allows the
                             server to reflect to the client any and
                             all definite, exception, and no response
                             requests sent by the host application.

         BIND-IMAGE          Allows the server to send (upon request)
                             the SNA BIND image to the client.

      See the section entitled "Details of Processing TN3270E
      Functions" for a more detailed explanation of the meaning and
      use of these functions.



B. Kelly                 Expires January 1994                [Page 12]


Internet Draft           TN3270 Enhancements                 July 1993


8.  TN3270E Data Messages

   3270 device communications are generally understood to be block
   oriented in nature.  That is, each partner buffers data until an
   entire "message" has been built, at which point the data is sent to
   the other side.  The "message" consists of a series of 3270
   commands, buffer orders, buffer addresses, and data.  The end of a
   message is understood to be the last byte transmitted (note that
   this discussion disregards SNA chaining).  The Telnet EOR command
   is used to delimit these natural 3270 blocks of data within the
   Telnet data stream.

   In TN3270E, each 3270 message must be prefixed with a TN3270E
   header, which consists of four bytes and whose format is defined
   below (see the section entitled "The TN3270E Message Header").

   A "data message" in TN3270E therefore has the following
   construction:

          <TN3270E Header><data><IAC EOR>

   It should be noted that it is possible that, for certain message
   types, there is no data portion present.  In this case, the TN3270E
   data message consists of:

          <TN3270E Header><IAC EOR>

   Note also that Telnet commands may appear anywhere in the Telnet
   stream.  For this reason, if either side wishes to transmit the
   decimal value 255 and have it interpreted as data, it must "double"
   this byte.  In other words, a single occurance of decimal 255 will
   be interpreted by the other side as an IAC, while two successive
   bytes containing decimal 255 will be treated as one data byte with
   a value of decimal 255.


   8.1 The TN3270E Message Header

      As stated earlier, each data message in TN3270E must be prefixed
      by a header, which consists of four bytes and is formatted as
      follows:

          ------------------------------------------------
          |   DATA-TYPE   | REQUEST-FLAG | RESPONSE-FLAG |
          ------------------------------------------------
               2 bytes         1 byte         1 byte







B. Kelly                 Expires January 1994                [Page 13]


Internet Draft           TN3270 Enhancements                 July 1993


     8.1.1 DATA-TYPE field

      The DATA-TYPE field indicates how the data portion of the
      message is to be interpreted by the receiever.  Possible values
      for the DATA-TYPE field are:

        Data-type Name   Code                Meaning
        --------------   ----   ---------------------------------
        3270-DATA         00    The data portion of the message
                                contains only the 3270 datastream.
                                Note that this is the only DATA-TYPE
                                value that all TN3270E clients and
                                servers must support, since it must
                                be used to identify 3270 terminal
                                datastreams.

        SCS-DATA          01    The data portion of the message
                                contains SNA Character Stream data.

        RESPONSE          02    The data portion of the message
                                constitutes device-status information
                                and the RESPONSE-FLAG field indicates
                                whether this is a postive or negative
                                response (see below).

        BIND-IMAGE        03    The data portion of the message is
                                the SNA bind image from the session
                                established between the server and the
                                host application.

        NVT-DATA          04    The data portion of the message is to
                                be interpreted as NVT data.

        REQUEST           05    There is no data portion present in
                                the message.  Only the REQUEST-FLAG
                                field has any meaning.


     8.1.2 REQUEST-FLAG field

      The REQUEST-FLAG field only has meaning when the DATA-TYPE field
      has a value of REQUEST; otherwise, the REQUEST-FLAG field must
      be ignored by the receiver and should be set to 0x00 by the
      sender.  Possible values for the REQUEST-FLAG field are:

        Request-Flag Name   Code                Meaning
        -----------------   ----   ---------------------------------
        SEND-BIND             0    The client wishes the server to send
                                   a copy of the SNA bind image used
                                   to establish a session between the
                                   host application and the server.


B. Kelly                 Expires January 1994                [Page 14]


Internet Draft           TN3270 Enhancements                 July 1993


        ERR-COND-CLEARED      1    The client sends this to the server
                                   when some previously encountered
                                   printer error condition has been
                                   cleared.  (See the section entitled
                                   "The RESPONSE Function" below.)


     8.1.3 RESPONSE-FLAG field

      The RESPONSE-FLAG field only has meaning for certain values of
      the DATA-TYPE field.  For DATA-TYPE field values of 3270-DATA
      and SCS-DATA, the RESPONSE-FLAG is an indication of whether or
      not the sender of the data expects to receive a response.  In
      this case the possible values of RESPONSE FLAG are:

        Response-Flag Name  Code                Meaning
        ------------------  ----   ---------------------------------
        NO-RESPONSE           0    The sender does not expect the
                                   receiver to respond either
                                   positively or negatively to this
                                   message.

        ERROR-RESPONSE        1    The sender only expects the
                                   receiver to respond to this message
                                   if some type of error occurred, in
                                   which case a negative response is
                                   expected.

        ALWAYS-RESPONSE       2    The sender expects the receiver
                                   to respond negatively if an error
                                   occurs, or positively if no errors
                                   occur.

      For a DATA-TYPE field value of RESPONSE, the RESPONSE-FLAG is an
      actual response to the previous data message (which must by
      definition have had a DATA-TYPE of either 3270-DATA or SCS-DATA
      and a RESPONSE-FLAG value of either ERROR-RESPONSE or
      ALWAYS-RESPONSE).  In this case the possible values of
      RESPONSE-FLAG are:

        Response-Flag Name  Code                Meaning
        ------------------  ----   ---------------------------------
        POSITIVE-RESPONSE     0    The previous message was received
                                   and executed successfully with
                                   no errors.

        NEGATIVE-RESPONSE     1    The previous message was received
                                   but an error(s) occurred while
                                   processing it.

      Accompanying device status information will be found in the data
      portion of the message.

>
>  The TN3278 doc specifies device status in detail.  Perhaps we should
>  too.  You could just copy in the text here from that doc.
>

B. Kelly                 Expires January 1994                [Page 15]


Internet Draft           TN3270 Enhancements                 July 1993


      For any other values of the DATA-TYPE field, the RESPONSE-FLAG
      field must be ignored by the receiver and should be set to 0x00
      by the sender.


9. Basic TN3270E

   As has been stated earlier, whether or not the use each of the
   TN3270E functions is allowed on a session is negotiated when the
   connection is established.  It is possible that none of the
   functions are agreed to (in this case, the function-list in the
   FUNCTIONS REQUEST and FUNCTIONS IS commands is null).  This
   mode of operation is referred to as "basic TN3270E."

   Basic TN3270E requires the support of only the following TN3270E
   header values:

          Header field         Value
          ------------         -----
           DATA-TYPE          3270-DATA
           DATA-TYPE          NVT-DATA

   When basic TN3270E is in effect, each party must set the DATA-TYPE
   field to either 3270-DATA when the data portion of the message
   contains 3270 datastream, or to NVT-DATA when the data portion is
   to be interpreted is NVT data.

   The REQUEST-FLAG and RESPONSE-FLAG fields are not used in basic
   TN3270E.


10. Details of Processing TN3270E Functions

   Agreement by both parties to a specific function in the FUNCTIONS
   REQUEST function-list implies agreement by each party to support a
   related set of values in the TN3270E header.  It also implies a
   willingness to adhere to the rules governing the processing of data
>
>  Let's define this better.  Use such words as "violation of the
>  protocol",  "will be considered non-conforming".
>
   messages as regards the agreed upon function.  The following
   sections detail for each TN3270E function the associated header
   values and processing rules.


   10.1 The SNA-CHAR-STREAM Function

      This function can only be supported on a 3270 printer session.
      If either party receives this function in a FUNCTIONS REQUEST
      function-list when the previously negotiated device-type
      represents a terminal, it must remove the SNA-CHAR-STREAM
      function from the list before responding with a FUNCTIONS
      REQUEST of its own.



B. Kelly                 Expires January 1994                [Page 16]


Internet Draft           TN3270 Enhancements                 July 1993


      Agreement to support this function requires that the party
      support the following TN3270E header values:

          Header field         Value
          ------------         -----
           DATA-TYPE          SCS-DATA

      When SNA-CHAR-STREAM is in effect, neither side should send a
      data message with a DATA-TYPE of 3270-DATA.


   10.2 The DATA-STREAM-CTL Function

      This function can only be supported on a 3270 printer session.
      If either party receives this function in a FUNCTIONS REQUEST
      function-list when the previously negotiated device-type
      represents a terminal, it must remove the DATA-STREAM-CTL
      function from the list before responding with a FUNCTIONS
      REQUEST of its own.

      Agreement to support this function requires that the party
      support the following TN3270E header values:

          Header field         Value
          ------------         -----
           DATA-TYPE          3270-DATA

      When DATA-STREAM-CTL is in effect, neither side should send a
      data message with a DATA-TYPE of SCS-DATA.


   10.3 The BIND-IMAGE Function

      This function can only be supported when the TN3270E server
      represents SNA 3270 devices.
>
>  Why?  Wouldn't printer supporters like to see the bind?
>

      Agreement to support this function requires that the party
      support the following TN3270E header values:

          Header field         Value
          ------------         -----
           DATA-TYPE          BIND-IMAGE
           DATA-TYPE          REQUEST
           REQUEST-FLAG       SEND-BIND

      At any point after support of the BIND-IMAGE function has been
      agreed upon, the client may send a data message to the server in
      which the header DATA-TYPE field is set to REQUEST, and the
      header REQUEST-FLAG is set to SEND-BIND.  There is no data
      portion in this message.  The server must respond with a data
      message in which the header DATA-TYPE field is set to BIND-IMAGE


B. Kelly                 Expires January 1994                [Page 17]


Internet Draft           TN3270 Enhancements                 July 1993


      and the data portion of the message consists solely of the exact
      image of the SNA bind that was used to establish the session
      between the server and the host application on behalf of this
      client.


   10.4 The RESPONSE Function

      This function can be supported for both terminal and printer
      sessions connected to both SNA and non-SNA servers.

      Agreement to support this function requires that the party
      support the following TN3270E header values:

          Header field         Value
          ------------         -----
           DATA-TYPE          RESPONSE
           DATA-TYPE          REQUEST
           RESPONSE-FLAG      -all values-
           REQUEST-FLAG       ERR-COND-CLEARED

      When the RESPONSE function is in effect, each party must adhere
      to the following rules:

       - Whenever a data message is sent with a DATA-TYPE of either
         SCS-DATA or 3270-DATA, the sender must set the RESPONSE-FLAG
         field to either NO-RESPONSE, ERROR-RESPONSE, or
         ALWAYS-RESPONSE.  It is anticipated that the client side will
         normally set RESPONSE-FLAG to NO-RESPONSE.  The server, if it
         represents an SNA device, should set RESPONSE-FLAG to reflect
>
>  Are we using the Host Requirements convention of MUST/SHOULD/MAY/MUST NOT?
>  It seems to me that there are Vtam applications that set DR when it is
>  not truly needed, and that TN3270 gets a performance boost by not waiting
>  for a round trip time before it sends Vtam a DR.  I suggest that this
>  decision be made by the Client, or Server based on local information,
>  like configuration or local decisions by the person at the Client.  If
>  we let the Client decide this,  we need to put it into this protocol
>  somewhere.
>
>
         the response value set in the RH of the RU that generated
         this data message - Definite Response resulting in a
         RESPONSE-FLAG value of ALWAYS-RESPONSE, Exception Response
         resulting in ERROR-RESPONSE being set, and No Response
         causing a setting of NO-RESPONSE.  A non-SNA server should
         set RESPONSE-FLAG to ERROR-RESPONSE.

       - Whenever a data message with a DATA-TYPE of either SCS-DATA
         or 3270-DATA is received, the receiver must attempt to
         process the data in the data portion of the message, then
         determine whether or not it should send a data message with a
         DATA-TYPE of RESPONSE.  If the data message it has just
         processed had a RESPONSE-FLAG value of NO-RESPONSE, or if it
         had a value of ERROR-RESPONSE and there were no errors
         encountered while processing the data, then no RESPONSE type
         message should be sent.  Otherwise, a data message should be
         sent in which the header DATA-TYPE field is set to RESPONSE.
         The RESPONSE-FLAG field in this header must have a value of
         either POSITIVE-RESPONSE or NEGATIVE-RESPONSE.  A
         POSITIVE-RESPONSE should be sent if the previously processed
         message's header specified ALWAYS-RESPONSE and no errors


B. Kelly                 Expires January 1994                [Page 18]


Internet Draft           TN3270 Enhancements                 July 1993


         were encountered in processing the data.  A NEGATIVE-RESPONSE
         should be sent when

          1) the previously processed message specified ERROR-RESPONSE
             or ALWAYS-RESPONSE and

          2) some kind of error occurred while processing the data.

         Please keep in mind that it is normally only the client that
         will be constructing and sending these RESPONSE messages.  A
         negative response sent by the client to the server is the
         equivalent of a Unit Check Status [8].  All references to
         device status and sense codes in this section rely on [8].

         The data portion of this RESPONSE message must consist of one
         byte of binary data.  The value of this byte gives a more
         detailed account of the results of having processed the
         previously received data message.  The possible values for
         this byte are:

           For a RESPONSE-FLAG value of POSITIVE-RESPONSE -

             Value            Meaning
             -----            -------
             0x00      Successful completion (equivalent to "Device
                       End").

           For a RESPONSE-FLAG value of NEGATIVE-RESPONSE -

             Value            Meaning
             -----            -------
             0x00      An invalid 3270 command was received
                       (equivalent to "Command Reject").

             0x01      Printer is not ready (equivalent to
                       "Intervention Required").

             0x02      An illegal 3270 buffer address or order
                       sequence was received (equivalent to
                       "Operation Check").

             0x03      Printer is powered off or not connected
                       (equivalent to "Component Disconnected").

         When the server receives any of the above responses, it
         should pass along the appropriate information to the host
         application.  The appopriate information is determined by
         whether the server represents an SNA or a non-SNA device.

         An SNA server should pass along a POSITIVE-RESPONSE from the
         client as a positive SNA Response Unit to the host


B. Kelly                 Expires January 1994                [Page 19]


Internet Draft           TN3270 Enhancements                 July 1993


         application.  It should translate a NEGATIVE-RESPONSE from
         the client into an SNA negative Response Unit in which the
         Sense Data Indicator bit is on and which contains one of
         the following sense codes:

             RESPONSE-FLAG        Equivalent        SNA Sense Code
             -------------        ----------        --------------
                 0x00           Command Reject        0x10030000

                 0x01        Intervention Required    0x08020000

                 0x02           Operation Check       0x10050000

                 0x03        Component Disconnected   0x08310000

         A non-SNA server should pass along a POSITIVE-RESPONSE from
         the client by setting the Device End Status bit on.  It
         should reflect a NEGATIVE-RESPONSE from the client by setting
         the Unit Check Status Bit on, and setting either the Command
         Reject, Intervention Required, or Operation Check Sense bit
         on when responding to the Sense command.

         In the case of Intervention Required or Component Disconnected
         being passed by the server to the host application, the host
         would normally refrain from sending any further data to the
         printer.  If and when the error condition at the client has
         been resolved, the client must send to the server a data
         message whose header DATA-TYPE field is set to REQUEST, and
         whose REQUEST-FLAG is set to ERR-COND-CLEARED.  Note that
         this message has no data portion.  Upon receipt of this
         message, the server should pass along the appropriate
         information to the host application so that it may resume
         sending printer output.  Again, the form of this information
         depends on whether the server represents an SNA or a
         non-SNA device.

         An SNA server should reflect an ERR-COND-CLEARED to the host
         application by sending an SNA LUSTAT RU with one of the
         following sense codes:

          - if the previous error condition was an Intervention
            Required, the server should send sense code 0x00010000

          - if the previous error condition was Component
            Disconnected, the server should send sense code 0x082B0000

         A non-SNA server should set the corresponding bits in the
         Ending Status and Sense Condition bytes.





B. Kelly                 Expires January 1994                [Page 20]


Internet Draft           TN3270 Enhancements                 July 1993


11. The 3270 ATTN Key

   The 3270 ATTN key is interpreted by many host applications in an
   SNA environment as an indication that the user wishes to interrupt
   the execution of the current process.  The Telnet Interrupt Process
   (IP) command was defined expressly for such a purpose, so it seems
   logical to use IP to implement support for the 3270 ATTN key.  This
   requires two things:

    - TN3270E clients should provide as part of their keyboard
      mapping a single key or a combination of keys that map to
      the 3270 ATTN key.  When the user presses this key(s), the
      client should transmit a Telnet IP command to the server.

    - TN3270E servers should translate the IP command received from
      a TN3270E client into the appropriate form and pass it along
      to the host application as an ATTN key.  In other words, the
      server representing an SLU in an SNA session should send
      a SIGNAL RU to the host application.

   The ATTN key is not supported in a non-SNA environment; therefore,
   a TN3270E server representing non-SNA 3270 devices should ignore
   any Telnet IP commands it receives from a client.

12. The 3270 SYSREQ Key

   The 3270 SYSREQ key is useful in an SNA environment when the ATTN
   key is not sufficient to terminate a process.  While there are
   other uses for the SYSREQ key, and while its function is more
   complicated than what is dealt with in this document, it seems
   reasonable to implement a subset of the SYSREQ key support that
   would be beneficial to a large number of users.  This subset would
   be limited to support for the sequence of pressing SYSREQ and
   typing LOGOFF that many users employ to immediately terminate an
>
>  On a real 3270, you usually hit Clear, type LOGOFF and press SYSREQ.
>  On a TN3270E session, I guess you see the SYSREQ followed by LOGOFF.
>
   SNA session.  It is recognized that in the case of host-resident
   TN3270E servers, essentially the same thing can be accomplished by
   the user unilaterally closing the Telnet connection, but in the
   case of servers that do not reside on the host (for example, the
   commercial TCP-to-SNA gateways) users may wish to terminate the SNA
   session without closing the Telnet connection.

   The Telnet Abort Output (AO) command seems the appropriate
   mechanism for implementing this limited SYSREQ key support, given
   that in a real SNA session, once the user presses the SYSREQ key,
   the host application is prevented from sending any more output to
   the terminal (unless the user presses SYSREQ a second time), but
   the user's process continues to execute.

   In order to implement SYSREQ key support, TN3270E clients should
   provide a key (or combination of keys) that is identified as



B. Kelly                 Expires January 1994                [Page 21]


Internet Draft           TN3270 Enhancements                 July 1993


   mapping to the 3270 SYSREQ key.  When the user presses this key(s),
   the client should transmit a Telnet AO command to the server.

   Upon receipt of the AO command, the TN3270E server should enter
   what will be loosely termed "suspended mode" for the connection.
   Any attempt by the host application to send data to the client
   while the connection is "suspended" should be responded to by the
   server with a negative response, sense code 0x082D, indicating
   an "LU Busy" condition.  The server should not transmit anything to
   the client on behalf of the host application.

   At this point, there are two possible courses of action on the part
   of the user:

    - transmit the string LOGOFF (upper or lower case), which will
      result in the server terminating the SNA session with the host
      application.  In the case of host-based servers, this will also
      have the effect of closing the Telnet connection.

    - press the "SYSREQ" key again, which will result in the
      transmission of another AO to the server.  The server should
      then send to the host application an LUSTAT RU with a value of
      0x082B indicating "presentation space integrity lost."  The
      server will then "un-suspend" the Telnet connection to the
      client, meaning it will allow the host application to once
      again send data to the client.

   If, while the Telnet connection is "suspended," the user transmits
   anything other than the above, the server should respond with the
   string "COMMAND UNRECOGNIZED" to the client.  The server should not
   send anything to the host application on behalf of the client.

   The SYSREQ key is not supported in a non-SNA environment; in fact,
   use of this key on a non-SNA 3270 terminal generally gets the user
   into difficulties.  Therefore, TN3270E servers representing non-SNA
   3270 terminals should ignore any Telnet AO commands they receive
   from a client.


13. 3270 Structured Fields

   3270 structured fields provide a much wider range of features than
   "old-style" 3270 data, such as support for graphics, partitions and
   IPDS printer datastreams.  It would be unreasonable to expect all
   TN3270E clients to support all possible structured field functions,
   yet there must be a mechanism by which those clients that are
   capable of supporting some or all structured field functions can
   indicate their wishes.

   The design of 3270 structured fields provides a convenient means to
   convey the level of support (including no support) for the various


B. Kelly                 Expires January 1994                [Page 22]


Internet Draft           TN3270 Enhancements                 July 1993


   structured field functions.  This mechanism is the Read Partition
   Query command, which is sent from the host application to the
   device.  The device responds with a Query Reply(s), listing which,
   if any, structured field functions it supports.

   Therefore, all TN3270E clients must be able to respond to a Read
   Partition Query command, even if only to indicate that it supports
   no structured field functions.  Note that clients must support both
   the Read Partition Query (Type 02), and all forms of the Read
   Partition Query List (Type 03).


14. Examples

   The following example shows a TN3270E-capable server and a
   traditional tn3270 client establishing a connection:

      Server:  IAC DO TN3270E
      Client:  IAC WON'T TN3270E
      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-3278-2 IAC SE
      Server:  IAC DO EOR
      Client:  IAC WILL EOR
>
>  DO BINARY / WILL BINARY ???
>  Let's be complete here.
>
           .            .
           .            .
         (traditional tn3270 negotiation continues)

   The following example shows a TN3270E-capable server and a
   TN3270E-capable client establishing a generic terminal session:

      Server:  IAC DO TN3270E
      Client:  IAC WILL TN3270E
      Server:  IAC SB TN3270E SEND DEVICE-TYPE IAC SE
      Client:  IAC SB TN3270E DEVICE-TYPE REQUEST IBM-3278-2 IAC SE
      Server:  IAC SB TN3270E DEVICE-TYPE IS IBM-3278-2 CONNECT
                      anyterm IAC SE
      Client:  IAC SB TN3270E FUNCTIONS REQUEST RESPONSES IAC SE
      Server:  IAC SB TN3270E FUNCTIONS IS RESPONSES IAC SE
         (3270 datastream is exchanged)

   The following example shows a TN3270E-capable server and a
   TN3270E-capable client establishing a terminal session where the
   client requests a specific device-name:

      Server:  IAC DO TN3270E
      Client:  IAC WILL TN3270E
      Server:  IAC SB TN3270E SEND DEVICE-TYPE IAC SE
      Client:  IAC SB TN3270E DEVICE-TYPE REQUEST IBM-3278-5
                      CONNECT myterm IAC SE


B. Kelly                 Expires January 1994                [Page 23]


Internet Draft           TN3270 Enhancements                 July 1993


      Server:  IAC SB TN3270E DEVICE-TYPE IS IBM-3278-5 CONNECT
                      myterm IAC SE
      Client:  IAC SB TN3270E FUNCTIONS REQUEST RESPONSES IAC SE
      Server:  IAC SB TN3270E FUNCTIONS IS RESPONSES IAC SE
         (3270 datastream is exchanged)

   The following example shows a TN3270E-capable server and a
   TN3270E-capable client attempting to establish a terminal session;
   multiple attempts are necessary because the device-name initially
   requested by the client is already in use:

      Server:  IAC DO TN3270E
      Client:  IAC WILL TN3270E
      Server:  IAC SB TN3270E SEND DEVICE-TYPE IAC SE
      Client:  IAC SB TN3270E DEVICE-TYPE REQUEST IBM-3278-5
                      CONNECT myterm IAC SE
      Server:  IAC SB TN3270E DEVICE-TYPE REJECT REASON
                      DEVICE-IN-USE IAC SE
      Client:  IAC SB TN3270E DEVICE-TYPE REQUEST IBM-3278-2
                      CONNECT herterm IAC SE
      Server:  IAC SB TN3270E DEVICE-TYPE IS IBM-3278-2 CONNECT
                      herterm IAC SE
      Client:  IAC SB TN3270E FUNCTIONS REQUEST RESPONSES IAC SE
      Server:  IAC SB TN3270E FUNCTIONS IS RESPONSES IAC SE
         (3270 datastream is exchanged)

   The following example shows a TN3270E-capable server and a
   TN3270E-capable client establishing a printer session where the
   client requests a specific device-name, and where some amount
   of 3270 function negotiation is required before an agreement is
   reached:

      Server:  IAC DO TN3270E
      Client:  IAC WILL TN3270E
      Server:  IAC SB TN3270E SEND DEVICE-TYPE IAC SE
      Client:  IAC SB TN3270E DEVICE-TYPE REQUEST IBM-3287-1 CONNECT
                      myprt IAC SE
      Server:  IAC SB TN3270E DEVICE-TYPE IS IBM-3287-1 CONNECT
                      myprt IAC SE
      Client:  IAC SB TN3270E FUNCTIONS REQUEST DATA-STREAM-CTL IAC SE
      Server:  IAC SB TN3270E FUNCTIONS REQUEST DATA-STREAM-CTL
                      RESPONSES IAC SE
      Client:  IAC SB TN3270E FUNCTIONS REQUEST DATA-STREAM-CTL IAC SE
      Server:  IAC SB TN3270E FUNCTIONS IS DATA-STREAM-CTL IAC SE
         (3270 datastream is exchanged)

   The following example shows a TN3270E-capable server and a
   TN3270E-capable client establishing first a generic terminal
   session, then a printer session where the "partner" printer for
   the assigned terminal is requested:



B. Kelly                 Expires January 1994                [Page 24]


Internet Draft           TN3270 Enhancements                 July 1993


      Server:  IAC DO TN3270E
      Client:  IAC WILL TN3270E
      Server:  IAC SB TN3270E SEND DEVICE-TYPE IAC SE
      Client:  IAC SB TN3270E DEVICE-TYPE REQUEST IBM-3278-2 IAC SE
      Server:  IAC SB TN3270E DEVICE-TYPE IS IBM-3278-2 CONNECT
                      termXYZ IAC SE
      Client:  IAC SB TN3270E FUNCTIONS REQUEST RESPONSES IAC SE
      Server:  IAC SB TN3270E FUNCTIONS IS RESPONSES IAC SE
         (3270 datastream is exchanged)
           .            .
           .            .
         (user decides to request a printer session,
          so client again connects to Telnet port on server)
      Server:  IAC DO TN3270E
      Client:  IAC WILL TN3270E
      Server:  IAC SB TN3270E SEND DEVICE-TYPE IAC SE
      Client:  IAC SB TN3270E DEVICE-TYPE REQUEST IBM-3287-1
                      ASSOCIATE termXYZ IAC SE
      Server:  IAC SB TN3270E DEVICE-TYPE IS IBM-3287-1 CONNECT
                      termXYZ's-prt IAC SE
      Client:  IAC SB TN3270E FUNCTIONS REQUEST SNA-CHAR-STREAM
                      RESPONSES IAC SE
      Server:  IAC SB TN3270E FUNCTIONS IS SNA-CHAR-STREAM RESPONSES
                      IAC SE
         (3270 datastream is exchanged)


15. References

[1] Rekhter, J., "Telnet 3270 Regime Option", RFC 1041, IBM
    Corporation, January 1988.

[2] VanBokkelen, J., "Telnet Terminal-Type Option", RFC 1091,
    FTP Software, Inc., February 1989.

[3] Postel, J., and J. Reynolds, "Telnet Binary Transmission",
    RFC 856, USC/Information Sciences Institute, May 1983.

[4] Postel, J., "Telnet End of Record Option", RFC 885, USC/
    Information Sciences Institute, December 1983.

[5] Reynolds, J., and J. Postel, "Assigned Numbers", RFC 1340,
    USC/Information Sciences Institute, July 1992.

[6] "3270 Information Display System - Data Stream Programmer's
    Reference", publication number GA24-0059, IBM Corporation.

[7] "Systems Network Architecture - Network Product Formats",
    publication number LY43-0081, IBM Corporation.




B. Kelly                 Expires January 1994                [Page 25]


Internet Draft           TN3270 Enhancements                 July 1993


[8] "3174 Establishment Controller Functional Description",
    publication number GA23-0218, IBM Corporation.


16. Author's Note

   Portions of this document were drawn from the following sources:

    - A White Paper written by Owen Reddecliffe, WRQ Corporation,
      October 1991.

    - Experimental work on the part of Cleve Graves and Michelle
      Angel, OpenConnect Systems, 1992 - 1993.

    - Discussions at the March 1993 IETF meeting.

    - Discussions on the "TN3270E" list, Spring 1993.


17. Author's Address

   Bill Kelly
   Division of University Computing
   144 Parker Hall
   Auburn, AL  36849

   Phone: (205) 844-4512

   Email: kellywh@mail.auburn.edu























B. Kelly                 Expires January 1994                [Page 26]



Bill Kelly               phone: (205) 844-4512
Auburn University     Internet: kellywh@mail.auburn.edu

>
>  Thanks for the effort Bill.  I hope we can converge on agreement soon.
>
------------------------------------------------------------------------
Fred Bohle                      EMAIL: fab@interlink.com
Interlink Computer Sciences     AT&T : 301-317-6600
9145 Guilford Road, Suite 175
Columbia, MD 21046
------------------------------------------------------------------------