Subject: Forwarded: [TN3270E Extensions draft]

From: Michael Boe <[email-masked]>
Date: Wed, 15 Jul 1998 09:30:00 -0700 (PDT)

This Gene's first draft of the TN3270E Functional Extensions document. Please
review.  Next draft will go through the usual Internet Draft publication
process.

/msb

------- Begin Forwarded Message -------
TN3270E Working Group                                         G. Pullen
Internet Draft:                                             M. Williams
Updates:  RFC 2355                                  OpenConnect Systems
                                                              June 1998

                     TN3270E Functional Extensions

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 the other groups may also
   distribute working documents as Internet-Drafts.

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

Copyright Notice

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

Table of Contents

   1.    Introduction . . . . . . . . . . . . . . . . . . . . . . .   2
   2.    Negotiated Function Codes  . . . . . . . . . . . . . . . .   2
   3.    Negotiated Function Example  . . . . . . . . . . . . . . .   2
   4.    Contention Resolution Function . . . . . . . . . . . . . .   3
   4.1   Keyboard Restore Problem . . . . . . . . . . . . . . . . .   3
   4.2   Implied Keyboard Restore Problem . . . . . . . . . . . . .   3
   4.3   Bid Problem  . . . . . . . . . . . . . . . . . . . . . . .   3
   4.4   Signal Problem . . . . . . . . . . . . . . . . . . . . . .   4
   4.5   CONTENTION-RESOLUTION Implementation . . . . . . . . . . .   4
   4.5.1 SEND-DATA Indicator (SDI)  . . . . . . . . . . . . . . . .   5
   4.5.2 BID Data Type  . . . . . . . . . . . . . . . . . . . . . .   6
   4.5.3 SIGNAL Indicator . . . . . . . . . . . . . . . . . . . . .   7
   5.    Function Management Header (FMH) Support Function  . . . .   9
   5.1   FMH Overview . . . . . . . . . . . . . . . . . . . . . . .   9
   5.1.1 LU1 FMH1 Support . . . . . . . . . . . . . . . . . . . . .  10
   5.1.2 Usage of DSSEL in FMH1 . . . . . . . . . . . . . . . . . .  10
   5.1.3 Structured Field Data Stream . . . . . . . . . . . . . . .  11
   5.1.4 IPDS Data Stream . . . . . . . . . . . . . . . . . . . . .  11
   5.2   FMH Data Type  . . . . . . . . . . . . . . . . . . . . . .  11
   5.3   Server Implementation  . . . . . . . . . . . . . . . . . .  12
   5.3.1 Bind Processing  . . . . . . . . . . . . . . . . . . . . .  12
   5.3.2 Host/Server Flow . . . . . . . . . . . . . . . . . . . . .  13
   5.3.3 Client/Server Flow . . . . . . . . . . . . . . . . . . . .  13
   5.3.4 FMH Responses  . . . . . . . . . . . . . . . . . . . . . .  14
   5.4   Client Implementation  . . . . . . . . . . . . . . . . . .  15

Pullen & Williams            Internet Draft                    [Page 1]
Internet Draft         TN3270E Functional Extensions          June 1998

   6.    SNA Sense Code Function  . . . . . . . . . . . . . . . . .  16
   7.    TN3270E Header Byte-doubling Suppression Function  . . . .  17
   8.    References . . . . . . . . . . . . . . . . . . . . . . . .  18
   9.    Abbreviations  . . . . . . . . . . . . . . . . . . . . . .  18
   10.   Conventions  . . . . . . . . . . . . . . . . . . . . . . .  18
   11.   Author's Note  . . . . . . . . . . . . . . . . . . . . . .  19
   12.   Author's Address . . . . . . . . . . . . . . . . . . . . .  19

1.  Introduction

   This draft describes functional enhancements to the TN3270E
   protocol.  It addresses issues and implementation problems defined
   and discussed at the TN3270E/TN5250E Interoperability Events.  Among
   the issues to be address by this draft are SNA/TN3270E contention
   state resolution, SNA Sense Code support, Function Management Header
   support, and TN3270E header byte-doubling suppression.

2.  Negotiated Function Codes

   To maintain backward compatibility with clients and servers that do
   not support the extended TN3270E functions all new functionality
   will be negotiated.  The current TN3270E function negotiation rules
   apply.  Either side may request one or more of the extended
   functions by adding them to the function code list during TN3270E
   function negotiations.  Either side may reject the function by
   removing it from the function list.

   The extended TN3270E function negotiation codes are defined as:

      CONTENTION-RESOLUTION            5
      FMH-SUPPORT                      6
      SNA-SENSE                        7
      SUPPRESS-HEADER-BYTE-DOUBLING    8

3.  Negotiated Function Example

   The SNA-SENSE function support is enabled by the negotiation below:

      Server:   IAC DO TN3270E
      Client:   IAC WILL TN3270E
                  . . .
      Client:   IAC SB TN3270E FUNCTIONS REQUEST ... SNA-SENSE IAC SE
      Server:   IAC SB TN3270E FUNCTIONS IS ... SNA-SENSE IAC SE

   Support is disabled by the negotiation below (the server does not
   support the SNA-SENSE function):

      Server:   IAC DO TN3270E
      Client:   IAC WILL TN3270E
                   . . .
      Client:   IAC SB TN3270E FUNCTIONS REQUEST ... SNA-SENSE IAC SE
      Server:   IAC SB TN3270E FUNCTIONS REQUEST ... IAC SE
      Client:   IAC SB TN3270E FUNCTIONS IS ... IAC SE

Pullen & Williams            Internet Draft                    [Page 2]
Internet Draft         TN3270E Functional Extensions          June 1998

4.  Contention Resolution Function

   This function addresses shortcomings in the current TN3270E (RFC
   2355) specification that stem from the fact that SNA is a
   send/receive state oriented protocol, while TN3270E is relatively
   state free.  The following subsections define the problems to be
   addressed and the methods to resolve those issues.

4.1  Keyboard Restore Problem

   The Keyboard Restore problem concerns uncertainty over when the
   client can send data to the TN3270E server.  TN3270E provides for an
   End-Of-Record (EOR) mechanism, which allows the client to determine
   where the boundary is between 3270 data stream commands.  The server
   sends EOR whenever it sends data to the client for which the LIC
   (Last-In-Chain) indicator was set.  Clients have no choice but to
   interpret the presence of EOR as an indication that it is okay to go
   ahead and send data back to the host (providing the 3270 data-stream
   has restored the keyboard).  Since it is not uncommon for the Server
   to receive a LIC from the host with no CDI (Change Direction
   Indicator) set, a serious problem is created where the client will
   send data to the server when it does not own the send state.

   The solution is for the server to provide the client with an
   indication that it may send data.  The Send Data Indicator (SDI)
   mechanism will be discussed later in this document.

4.2  Implied Keyboard Restore Problem

   The Implied Keyboard Restore problem occurs when an application
   never explicitly sets the keyboard restore bit of the WCC byte in
   any of the 3270 data streams during a bracket.  In SNA, EB or CD is
   considered an "implied" keyboard restore in this case.  However,
   since TN clients are not aware of the bracket or direction state the
   client is not aware that it is allowed to send and often hangs in an
   AID inhibit (wait) state.

   The solution for this problem is for the server to detect the
   implied keyboard restore condition and send the SDI flag to inform
   the client that it may send data.

4.3  BID Problem

   In SNA, when a session is in the BETB (Between Bracket) or
   contention state, the Primary LU (PLU), or host, may bid for
   the send state by either sending an explicit or implicit BID.  The
   Secondary LU (SLU), controller or terminal, processes the BID,
   either granting the send state to the host or rejecting the request.
   Having granted the BID request, the SLU must enter the AID (send)
   inhibit state.

Pullen & Williams            Internet Draft                    [Page 3]
Internet Draft         TN3270E Functional Extensions          June 1998

   An implicit BID occurs when the host (PLU) does not hold direction,
   but attempts to send a message to the SLU when the session is in
   Between Bracket state.  No BID actually flows but is implied.  The
   SLU may accept or reject the PLU's attempt to gain direction as if a
   BID had been sent.

   In the TN3270 world, there is no mechanism for including the client
   in the BID process.  The server must process the BID on the client's
   behalf, without the ability to request the client yield the send
   state.  This leads to a variety of problems when the client attempts
   to send data inbound after the server has sent positive response to
   a BID from the host.  These problems include hung or lost sessions,
   lost data, or SNA or host application error messages, depending on
   data flow, timing, and how the server handles the BID process.

   This problem can be addressed by allowing the BID to propagate to
   the client.  When the server receives a valid BID (implicit or
   explicit) from the host (i.e. one that occurs in the BETB state) it
   will forward it to the client.  The client will respond either
   positively or negatively.  Having granted the BID (positive
   response), the client must enter the "input inhibited" state until
   the host has returned the send state to the client.

4.4  Signal Problem

   The Signal problem occurs when the PLU sends a Signal in order to
   force the SLU to yield direction.  For example, when the secondary
   has rejected a BID and the host needs to override it.  The BID
   reject may occur when the user types some data (perhaps an
   unintentional depression of the space bar) and does not press an AID
   key.  The SNA architecture provides that the primary (host) can send
   a Signal.  The secondary should reply with a positive response, send
   a null RU with Change Direction to yield direction (and Begin
   Bracket if appropriate), and enter AID inhibit state.

   With TN3270 there is no way for the server to force the client to
   yield the send state.

4.5  CONTENTION-RESOLUTION Implementation

   This section defines a new negotiated TN3270E function called
   CONTENTION-RESOLUTION.  Support of this function implies that both
   the client and the server is able to handle both the SDI header flag
   and BID data type.

   When the CONTENTION-RESOLUTION function is supported, the
   REQUEST-FLAG header field is interpreted as a bit mask, instead of a
   byte value, to allow the field to be used for Send Data and Signal
   indicators.

Pullen & Williams            Internet Draft                    [Page 4]
Internet Draft         TN3270E Functional Extensions          June 1998

4.5.1  Send Data Indicator (SDI)

   To use the Send Data Indicator the CONTENTION-RESOLUTION function
   must be supported by and agreed upon by both the server and client
   during TN3270E function negotiations.  SDI is only valid on TN3270E
   terminal type sessions and for the 3270-DATA and SSCP-LU-DATA
   message types.  SDI is sent in the REQUEST-FLAG field of the TN3270E
   header.

   The SDI bit mask is:

      SEND-DATA-MASK  0x01

   A bit value of 1 (true) indicates to the client that it holds the
   send state.  A bit value of 0 (false) indicates the server (and host
   by extension) holds the send state.

   In SNA LU-LU session, the server sends SDI when the host
   relinquishes send state with either the CDI or the EBI set in the
   SNA RU header.  In SNA SSCP-LU session and for non-SNA
   implementations (where no EBI or CDI is available) SDI is sent when
   the session enters contention state.

   It is valid for the server to send a null 3270-DATA or SSCP-LU-DATA
   (TN3270E header and EOR, no data) message to indicate the send state
   to the client.  This allows the server to handle a NULL RU
   containing EBI or CDI received from the host.

   The server ignores SDI in messages from the client and processes any
   data as usual depending on data type.

   When SDI is received by the client and the current TN3270E message
   has been processed (upon receipt of EOR) the client may send data to
   the server. If RESPONSES have been negotiated, the client must send
   RESPONSES to the server regardless of the send state.  Upon receipt
   of SDI, the client must send all pending RESPONSE messages before
   sending any keyboard input to the server.

   SDI is not a replacement for the 3270 data stream WCC Keyboard
   Restore bit.  The client must track both the Keyboard Restore flag
   and SDI to determine whether or not it can start sending data to the
   server. If WCC Keyboard restore is received, the keyboard is
   unlocked and the user is free to type.  However, the client cannot
   send data until the SDI is received.

   An SDI received without a WCC Keyboard Restore, is an implied
   keyboard restore.  The client's keyboard is restored and the wait
   indicator is turned off, allowing the user to enter data and the
   client to send data when an AID key is pressed.

Pullen & Williams            Internet Draft                    [Page 5]
Internet Draft         TN3270E Functional Extensions          June 1998

   The client is allowed to send an ATTN key (IAC IP) while waiting
   for SDI (AID inhibit state).  ATTN causes the server to send a
   SIGNAL message to the host requesting Change Direction.  This may
   allow the user to recover from a direction state timing or
   synchronization problem (i.e. server neglected to send SDI).

GP: The 3270 doc I have says " a second or successive Attention prior to
completion of processing of the first is ignored".  I have seen misbehaved
clients that send multiple IAC IP sequences in a single packet.  Its like the
user is leaning on or set a book on the ATTN key. Do we need to say the client
needs to wait for SDI before sending a second ATTN???

   The client may also send SYSREQ (if enabled by TN3270E function
   negotiation) to override the AID inhibit state.  This allows the
   user to switch to SSCP-LU session (possibly to logoff).

   The RESTORE key may be used at the client to unlock the keyboard and
   allow type-ahead.  However, this does NOT allow the client to
   override the send state and forward data to the server.

4.5.2  BID Data Type

   To use the BID data type the CONTENTION-RESOLUTION function must be
   supported by and agreed upon by both the server and client during
   TN3270E function negotiations.  The BID data type message is only
   valid on terminal sessions in 3270-DATA (LU-LU) mode.  The BID data
   type is not valid during SSCP-LU mode, NVT mode, or on printer
   sessions.

   The BID DATA-TYPE code is defined as:

   Data-type Name   Code   Meaning
   --------------   ----   -------------------------------------------
   BID              0x09   The server indicates that the host has sent
                           an implicit or explicit BID by sending this
                           data type to the client.

   The server sends the new TN3270E BID data type to the client upon
   receipt of either an implicit or an explicit BID from the host. The
   server must never send BID to the client when the host already has
   direction (holds send state).

   To send the BID data type the server inserts the BID data type in
   the DATA-TYPE field of the TN3270E header, inserts a null (0x00) in
   the REQUEST-FLAG field, inserts ALWAYS-RESPONSE (0x02) in the
   RESPONSE-FLAG field and fills in an appropriate SEQ-NUMBER.  An
   End-of-Record (EOR) is appended immediately after the TN3270E header
   (there is no data portion for a BID message).

Pullen & Williams            Internet Draft                    [Page 6]
Internet Draft         TN3270E Functional Extensions          June 1998

   The BID data type must always receive a response from the client
   regardless of whether the RESPONSES function is supported on the
   session.  The SEQ-NUMBER is returned by the client in its response,
   to allow the server to coordinate the response with the BID.  If
   RESPONSES has been negotiated the server should use the next number
   in the progression of sequence numbers.  If RESPONSES has not been
   negotiated, the server can use any number it desires.  When the
   server receives a BID response from the client, it is responsible
   for constructing the appropriate SNA response to the host.

   When the client receives a BID message it can accept it by returning
   a positive response, or reject it by returning a negative response.
   The format of a positive response is the same as the positive
   response defined for the TN3270E RESPONSES function (i.e., RESPONSE
   data type, POSITIVE-RESPONSE code in RESPONSE-FLAG field, SEQ-NUMBER
   from BID).  When the client accepts the BID it immediately enters
   AID inhibit state.  The keyboard remains unlocked, but the client
   may not send data until SDI is received from the server.

   If the client already has buffered data to be sent to the host the
   client can reject the BID.  The negative response uses the TN3270E
   RESPONSES format (i.e., RESPONSE data type, NEGATIVE-RESPONSE code
   in RESPONSE-FLAG field, SEQ-NUMBER from BID).  There is no defined
   reason information in the data portion of the negative response.
   The client's send state should remain unchanged upon negatively
   responding to a BID (i.e. if send state is AID inhibited, it stays
   that way). The server rejects the host's BID with a "Receiver in
   Transmit Mode" sense code (0x081B0000).

   A potential race condition exists, where the client sends data at
   the same time the server is sending a BID to the client.  The race
   condition is handled by the server, and is relatively transparent to
   the client.  When the server receives data before the expected
   response to the BID, the data is treated as an implied negative
   response.  The server sends negative response to the host's BID and
   forwards the client's data to the host.  When the client's response
   to the BID is received it is discarded by the server.  The client's
   send state should be AID inhibited, whether it responded positively
   or negatively to the BID, because it has not received SDI for the
   data it sent previously.

4.5.3  SIGNAL Indicator

   To use the SIGNAL indicator the CONTENTION-RESOLUTION function must
   be supported by and agreed upon by both the server and client during
   TN3270E function negotiations.  The SIGNAL indicator is only valid
   on BID data type messages.  The SIGNAL indicator is sent in the
   REQUEST-FLAG field of the TN3270E header.

   The SIGNAL bit mask is:

      SIGNAL-MASK  0x02

Pullen & Williams            Internet Draft                   [Page 7]
Internet Draft         TN3270E Functional Extensions          June 1998

   A bit value of 1 (true) indicates that the BID is "Forced" and the
   client MUST forfeit the send state.

   Upon receipt of Signal from the host, the server determines if the
   host already holds send state.  If so, the server returns positive
   response to the host immediately.  Otherwise, the server sends BID
   to the client with the SIGNAL indicator set.

   The client MUST return a positive response to the server and enter
   AID inhibit mode.  However, the keyboard remains unlocked.

   On receipt of the positive response from the client, the server
   sends a null RU to the host with Change Direction indicator (CDI).
   If the bracket state is between brackets the server must also set
   the Begin Bracket indicator.

   Since the client is unable to negative response a SIGNAL, it must
   discard any buffered (type-ahead) data.  The buffered keyboard input
   may not be valid on the forthcoming screen.  Also, to address the
   race condition described previously, the server should throw away
   data received from the client while awaiting the positive response
   to the Signal BID.

GP:  What if the client -rsps a Signal anyway??  Does server act like it was a
positive rsp and go on?

Pullen & Williams            Internet Draft                    [Page 8]
Internet Draft         TN3270E Functional Extensions          June 1998

5.  Function Management Header (FMH) Support Function

   Function Management Headers are not permitted in LU2 or LU3.
   Initially, they were not used in LU1 either.  Consequently, no
   provision was made for them in TN3270 or TN3270E.  Subsequently,
   support for FMHs over LU1 has been added to SNA based applications
   and devices.  Requirements to support LU1 DBCS (Kanji etc.) and
   IPDS printer applications are driving this effort for TN3270E FMH
   support.

   A de facto standard has arisen for handling Structured Field data
   stream FMHs in both TN3270 and TN3270E.  This de facto standard is
   referred to below as "silent FMH support".  Only FMH1 is supported
   and merely forwarded, in both directions, as data.  The receiver
   must recognize that the FMH is present by inspecting the first few
   bytes of the Telnet record and determining that they do not look
   like valid SCS data.  This is workable because FMH1 is a fixed 6-
   byte string, and it only occurs at the start of a record.

   The TN3270E FMH support function expands on silent FMH support by
   adding a mechanism for transferring arbitrary FMHs through a server.

5.1  FMH Overview

   FMH usage in its simplest terms:

   - There is only one FMH per chain, starting at the beginning of the
     chain.
   - The FMH may be spread over multiple RUs if too long for one.  The
     Format Indicator (FI) is 1 in the BC RU and 0 in the rest.

   At the next level of complexity:

   - There may be multiple FMHs, consecutively, at the start of the
     chain.
   - The presence of an FMH following the current one is indicated by
     the concatenation flag at byte 1, bit 0 of the current.
   - As with a single FMH, these FMHs may continue over several RUs,
     but only the first has the FI flag on.

   Note that an FMH other than the first may be at the start of an RU,
   but the FI flag in that RU would be 0.  The concatenation flag in
   the preceding FMH is sufficient to introduce it.  However, the
   description of FMHs in [2] only requires a (concatenated sequence
   of) FMH to start at the start of an RU, not necessarily at the start
   of a chain.  It states clearly that any RU in the chain may have the
   FI flag on and thus start with an FMH, though the preceding RU ended
   with ordinary data.

Pullen & Williams            Internet Draft                    [Page 9]
Internet Draft         TN3270E Functional Extensions          June 1998

   This would be awkward for TN3270E, since the RU boundaries are not
   visible to the clients. Fortunately, it is awkward for higher-level
   Host applications also, e.g. CICS and IMS applications.  These
   generally do not see RU boundaries either.  Moreover, it is
   contradicted by the description of sense code 400F in [2].  So it is
   not surprising that the 3174 does not support this generality.

5.1.1  LU1 FMH1 Support

   LU1 supports only FMH1.  By default, LU1 sessions use SCS data
   stream.  FMH1 is used to introduce support for an alternate data
   stream.

   The FMH1 format is:

   byte   0  |      1      |      2       |     3     |   4  .. n
      +------------------------------------------------------------
      |length|concat| type |medium|subaddr|flags| DSP | DSSEL
      +------------------------------------------------------------
   bits    8     1      7      4      4      4     4      3

   Where:
      length   FMH length = (n+1)
      concat   Concatenation Flag = (0)
      type     FMH Type (FMH1 = 1)
      medium   (console = 0)
      subaddr  (0)
      flags    Bit 0 - Send/Receive Indicator (SRI: Send=0, Receive=1)
      DSP      Data-stream Profile
               0xB = Structured Field Data Stream
               0xD = IPDS Data Stream
      DSSEL    Destination Selection

5.1.2 Usage of DSSEL in FMH1

   FMH1 describes the data-stream of accompanying data.  The
   accompanying data can be in a single chain (BEDS) or spread over
   multiple chains (BDS ... EDS).  For TN3270E, the client is only able
   to support BEDS for inbound FMHs, because the server will assume CD
   at the end of each chain.

   It is also possible to abort the data-stream (ADS instead of EDS),
   suspend a data-stream (SDS), and resume it later (RDS). In practice
   SDS/RDS are only used to insert console output into a longer
   transfer of data.

   The entire data-stream must be within a bracket.  If EB occurs after
   BDS but before EDS then the data-stream is implicitly aborted.

Pullen & Williams            Internet Draft                   [Page 10]
Internet Draft         TN3270E Functional Extensions          June 1998

5.1.3  Structured Field Data Stream

   This is used by DBCS and IPDS printers so that a Read Partition
   Query exchange can be conducted with an LU1 printer. (See [1].)

   Outbound FMH1: 0x0601000B6000
   Inbound FMH1:  0x0601008B6000  (SRI bit on)

      BC RU
      length = 6
      concat = 0
      DSP = 0xB
      DSSEL = BEDS

   Since the DSSEL = BEDS, the Structured Field data-stream is from the
   end of the FMH to the end of the chain.

   The usage is bi-directional, but always as one from the host
   application and a reply from the secondary.

5.1.4  IPDS Data Stream

   (See [4].)

   Usage: 0x0601300D4000, 0x0601300D2000

      OIC RU
      length = 6
      concat = 0
      DSP = 0xD
      DSSEL = BDS, EDS
      No data following FMH in the same chain.

   Although no ADS is sent, an EB before EDS implicitly aborts the data
   stream.

5.2  FMH Data Type

   To use the FMH data type the CONTENTION-RESOLUTION function must be
   supported by and agreed upon by both the server and client during
   TN3270E function negotiations.  The FMH data type message is only
   valid on LU1 printer sessions in SCS-DATA mode.  The FMH data
   type is not valid during SSCP-LU mode, NVT mode, or on terminal or
   LU3 (DCS) printer sessions.  The FMH DATA-TYPE code is defined as:

   Data-type Name   Code   Meaning
   --------------   ----   -------------------------------------------
   FMH-DATA         0x0A   The sender indicates that the data portion
                           of the message contains one or more Function
                           Management Headers.

   The FMH-DATA data type is bi-directional, meaning both the client
   and server can send this data type.

Pullen & Williams            Internet Draft                   [Page 11]
Internet Draft         TN3270E Functional Extensions          June 1998

5.3  Server Implementation

   If the FMH function has been negotiated, the server forwards the FMH
   data as part of the record, just as for normal data, and sets the
   FMH-DATA type in the TN3270E header.

   If the FMH function was not negotiated the server may send the same
   with the SCS-DATA type.  This maintains backward compatibility for
   servers that invoke silent FMH support.

   There is a trade-off between making many data checks in the server,
   thereby keeping the client interface simple, and minimizing the
   server's knowledge of the data-stream, thereby preserving
   flexibility.  This proposal takes the latter approach.  In
   particular, except for silent FMH support, the server does not know
   which FMH types the client supports.

5.3.1  Bind Processing

   Since TN3270E does not permit the client to reject the Bind, the
   server must police the bind parameters as far as possible.

   If the server receives an LU1 Bind with byte 6 bit 1 set to 1 (FMHs
   will be used), but the client has not negotiated FMH function, then
   the server may choose to reject the Bind with sense 0x08350006.
   This is left optional (perhaps on customer configuration) in order
   to accommodate silent FMH support.  However, when providing such
   support, the server is recommended to perform additional checks on
   the data, as outlined below.

5.3.2  Host/Server Flow

   When the server receives an RU from the host application on an LU1
   session FI = 1 and category = FMD, the server checks that the FMH is
   supported in principle:

      check that                  sense if wrong

      Bind said FMH               400F 0000
      BC = 1                      400F 0000

   If the server is providing silent FMH support to the client, the
   following additional checks, in this order:

      length = 6                  1008 2009 (optional)
      Type = 1                    1008 C000 (optional)
      DSP = 0xB                   1008 6006 (optional)
      FMH is one of a known list, 1008 0000 (optional)

Pullen & Williams            Internet Draft                   [Page 12]
Internet Draft         TN3270E Functional Extensions          June 1998

   Example:

      0x0601000B6000
      0x0601300D4000
      0x0601300D2000

   The server either sends a negative response to the Host application
   or forwards the data to the client.

   Note: If neither the FMH nor the SNA-SENSE functions are negotiated
   then it is recommended that the server only permit a specific list
   of FMHs from the Host.

   The existing function is to send EOJ to the client.  There is no
   change required here.

5.3.3 Client/Server Flow

   When the server receives an FMH-DATA record from the client, it
   forwards the record to the Host application with FI set in the Begin
   Chain RU.

   If the server receives a message FMH-DATA type but the FMH function
   was not negotiated, the server may choose either of two actions:

   - Terminate the LU-LU session.  It is suggested that, if BIND was
     negotiated, the UNBIND should carry a reason code of 0xFE.
     (If some future extension allows for SNA sense codes to flow to
     the client in the unbind image, the code to be used here should
     be 0x400F0000.)

   - Behave, for that message only, as though FMH function was
     negotiated.

   The server is not required to validate FMH-DATA messages received
   from the client.

   If the server has sent a silent FMH (SCS-DATA type) to the client,
   the server must compare the first 6 bytes of the data for being
   0x0601008B6000.  If so, it sets FI in the Begin Chain RU.

Pullen & Williams            Internet Draft                   [Page 13]
Internet Draft         TN3270E Functional Extensions          June 1998

5.3.4  FMH Responses

   There are many SNA sense codes associated with FMH errors.  Most of
   these are at the application level and begin with 0x1008.

   Sense Code     Cause
   ----------     -----
   0x08350006     Bind has byte 6 bit 1 set to 1 (FMHs will be used)
                  but printer does not support FMHs.

   0x1008xxxx     Invalid parameters in FMH.

   0x400F0000     Incorrect use of FI (not BC RU), or Bind error (byte
                  6 bit 1 set to 0).

   The FI flag is not echoed in the SNA response.

   Responses to FMH message: This serves purely to assist in the
   interpretation of negative responses.  Thus, although the flag is
   defined for both negative and positive responses, it is only
   necessary to set the flag when the client is rejecting an FMH
   without providing the SNA sense code.  In particular, if the client
   is rejecting data following the FMH it is not necessary to set this
   flag.

   When the server receives a NEGATIVE-RESPONSE from the client it
   checks the SNA-SENSE-CODE flag (if negotiated).

   If SNA-SENSE-CODE is set then the server takes the first four bytes
   of data following the TN3270E header as an SNA sense code and sends
   these, unchanged and unchecked, in the -rsp to the Host application.

   If SNA-SENSE-CODE is not set or negotiated, and the client returns a
   negative response to a silent FMH (SCS-DATA) or FMH-DATA type, the
   server sends a negative response 0x10080000 Sense code to the host
   application.

   If the server is providing silent FMH support to the clients and
   SNA-SENSE has not been negotiated then the server cannot in general
   tell whether the client is objecting to the FMH or to ensuing data.
   However, of the three currently identified FMHs requiring support,
   only 0x0601000B6000 can have data in the same chain.  Even then, the
   cause of the rejection may well be that this particular client does
   not expect FMHs at all.  Therefore it is recommended to interpret
   the rejection as rejection of the FMH itself.  The server should
   send SNA negative response 0x10080000 to the Host.

Pullen & Williams            Internet Draft                   [Page 14]
Internet Draft         TN3270E Functional Extensions          June 1998

5.4  Client Implementation

   A client that negotiates FMH function takes responsibility for
   validating the FMH-DATA messages.  If an error is found in a
   received FMH, the client must send a NEGATIVE-RESPONSE.

   If SNA-SENSE has been negotiated, the SNA-SENSE is set in the
   Response header field with the appropriate 4-byte SNA sense code in
   data field.  Otherwise, the response field is set to NEGATIVE-
   RESPONSE and the data field contains the one byte Command Reject
   (0x0) status code.

   A client that negotiates the FMH function must set FMH-DATA type on
   all records it sends that start with an FMH.

   If a client receives EOJ after BDS and before EDS then the client
   should infer ADS.

Pullen & Williams            Internet Draft                   [Page 15]
Internet Draft         TN3270E Functional Extensions          June 1998

6.  SNA Sense Code Function

   When the server and client operate in an SNA environment, it is
   impractical to perpetuate the one-byte error code mapping style of
   TN3270E.  Especially, when SNA already provides a table of defined
   Sense codes.  The SNA Sense Code function allows the client to
   return SNA Sense codes to the server, which are in turn forwarded to
   the SNA Host as a negative response.

   The client indicates that the data portion of the response message
   contains a 4-byte SNA sense code by setting the following code in
   the RESPONSE-FLAG field:

      SNA-SENSE-CODE    2

   The SNA-SENSE function may be negotiated on either terminal or
   printer sessions.  When the SNA-SENSE and RESPONSES functions have
   been negotiated, the server is committed to accepting SNA-SENSE-CODE
   responses to 3270-DATA and SCS-DATA (LU1) data type messages.  If
   the BID function is negotiated, BID data types may also receive
   SNA-SENSE-CODE responses.  However, the client retains the option of
   providing specific SNA Sense codes, or letting the server map all
   errors to the appropriate SNA sense codes (perhaps the less
   informative 10080000).

Pullen & Williams            Internet Draft                   [Page 16]
Internet Draft         TN3270E Functional Extensions          June 1998

7.  TN3270E Header Byte-doubling Suppression Function

   A performance bottleneck facing Telnet server and client vendors is,
   any 0xFF within an outbound data stream must be byte-doubled (a
   second 0xFF inserted into the data stream) by the sender in order to
   differentiate actual data from Telnet IAC commands.  The receiver of
   the data stream must then scan through the data stream removing the
   inserted 0xFF bytes.  With header-based protocols, like TN3270E,
   Telnet byte-doubling forces the header to be variable length, to
   allow for any 0xFF bytes that may occur within the header.

   From discussions on the TN3270E list, it was determined that Telnet
   Byte-doubling Suppression would best be handled outside of the
   TN3270E standard as a new Telnet negotiated option.  This will allow
   other block mode protocols (i.e. traditional TN3270, and TN5250) to
   take advantage of the proposed option.

   However, the variable length header issue is within the scope of the
   TN3270E standard.  This draft proposes a method to make the TN3270E
   header fixed length by eliminating byte-doubling of the 5 header
   bytes.  This function will extend the TN3270E standard to address
   this issue.  Although this function is proposed in anticipation of a
   new Suppress Byte-doubling Telnet option, it is intended to be
   independent of whether such a Telnet option is negotiated.

   When the SUPPRESS-HEADER-BYTE-DOUBLING function is enabled the
   TN3270E header will never be byte-doubled in either direction
   (client to server/server to client).  Therefore, the size of the
   TN3270E header will ALWAYS be 5 bytes when the Header Byte-doubling
   function is in effect.

   The sender of a TN3270E message guarantees that the first five
   (header) bytes of the record will not contain any embedded Telnet
   commands.  The sender must byte-double the data portion of the
   TN3270E message.

   The receiver of the message must validate that the message received
   does begin with a valid TN3270E header, to avoid misinterpreting
   asynchronous Telnet command packets between TN3270E records.  The
   receiver must also be cognizant of whether a TN3270E header is
   expected to avoid problems that may occur if bytes in the middle of
   a chain of buffers are not scanned properly.  When the receiver has
   determined that a valid TN3270E header is present it must skip past
   the header to begin scanning for byte-doubled 0xFF characters.

Pullen & Williams            Internet Draft                   [Page 17]
Internet Draft         TN3270E Functional Extensions          June 1998

8. References

   [1] IBM's "3174 Functional Description", Bookshelf book CN7A7003,
       GA23-0218-11.
   [2] IBM's "Systems Network Architecture Formats", GA27-3136-14.
   [3] RFC1647
   [4] IBM's "IPDS and SCS Technical Reference", S544-5312-00.

9. Abbreviations

   -rsp    Negative response
   +rsp    Positive response
   ADS     Abort Destination Selection, value of DSSEL
   BB      Begin Bracket, byte 2 bit 0 of RH of BC RU
   BC      Begin chain, byte 0 bit 6 of RH
   BC RU   An RU with BC = 1
   BDS     Begin Destination Selection, value of DSSEL
   BEDS    Begin and End Destination Selection, value of DSSEL
   DCA     Document Content Architecture
   DSP     Data-stream Profile, byte 3 bits 4-7 of FMH
   DSSEL   Destination Selection, byte 4 bits 0-2 of FMH
   EB      End Bracket, byte 2 bit 1 of RH of BC RU
   EC      End chain, byte 0 bit 7 of RH
   EC RU   An RU with EC = 1
   EDS     End Destination Selection, value of DSSEL
   FI      Format Indicator, byte 0 bit 4 of RH
   FIC     First In Chain - an RU with BC = 1 and EC = 0
   FMD     Function Management Data (user data, not FMH)
   FMH     Function Management Header, a SNA data header
   IPDS    Intelligent Printer Data Stream
   LIC     Last In Chain - an RU with BC = 0 and EC = 1
   LU      Logical Unit
   LUn     Logical Unit Type n, n = 0, 1, 2, etc.
   MIC     Middle In Chain - an RU with BC = 0 and EC = 0
   OIC     Only In Chain - an RU with BC = 1 and EC = 1
   RDS     Resume Destination Selection, value of DSSEL
   RH      Request Header, 3 byte header on SNA RU
   RU      Request Unit, an SNA frame starting with an RH
   SDS     Suspend Destination Selection, value of DSSEL
   SNA     Systems Network Architecture

10.  Conventions

   - Byte order is big-endian, e.g. bit 0 is the most significant bit.

Pullen & Williams             Internet Draft                  [Page 18]
Internet Draft         TN3270E Functional Extensions          June 1998

11.  Author's Note

Portions of this document were drawn from the following sources:

-  Contention Resolution proposal by Rodger Erickson, Wall Data.
-  SNA Sense Code and Function Management Header Support proposal by
   Derek Bolton, Cisco Systems.
-  TN3270E Byte-doubling Suppression proposal by Marty Williams,
   OpenConnect Systems.
-  Discussions on the TN3270E list and at the TN3270E/TN5250E
   Interoperability Events, 1997-1998.

12.  Author's Address

   Gene Pullen
   OpenConnect Systems
   2711 LBJ Freeway
   Dallas, Texas 75234

   Phone: (972) 484-5200
   Email: [email-masked]

Pullen & Williams             Internet Draft                  [Page 19]

-------  End Forwarded Message  -------

---

From: Gene Pullen <[email-masked]>
Date: Wed, 15 Jul 1998 14:26:16 -0500

Actually I have been updating the rough draft to make some corrections
and address some early issues.  Here is the current version.

Gene

TN3270E Working Group                                         G. Pullen
Internet Draft:                                             M. Williams
Extends:  RFC 2355                                  OpenConnect Systems
                                                              June 1998

Status of this Memo

Copyright Notice

Table of Contents

   4.5.2 KEYBOARD-RESTORE Indicator (KRI) . . . . . . . . . . . . .   6
   4.5.3 BID Data Type  . . . . . . . . . . . . . . . . . . . . . .   7
   4.5.4 SIGNAL Indicator . . . . . . . . . . . . . . . . . . . . .   8
   5.    Function Management Header (FMH) Support Function  . . . .  10
   5.1   FMH Overview . . . . . . . . . . . . . . . . . . . . . . .  10

1.  Introduction

      CONTENTION-RESOLUTION            5
      FMH-SUPPORT                      6
      SNA-SENSE                        7

      Server:   IAC DO TN3270E
      Client:   IAC WILL TN3270E
                  . . .

      Server:   IAC DO TN3270E
      Client:   IAC WILL TN3270E
                   . . .

   The Implied Keyboard Restore problem occurs when an application
   never explicitly sets the keyboard restore bit of the WCC byte in
   any of the 3270 data streams during a bracket.  In SNA, EB is
   considered an "implied" keyboard restore in this case.  However,
   since TN clients are not aware of the bracket or direction state the
   client is not aware that it is allowed to send data and often hangs
   in keyboard lock state.

   The solution for this problem is for the server to detect the
   implied keyboard restore condition and send the Keyboard Restore
   Indicator (KRI) flag to inform the client that its keyboard is
   unlocked.

4.3  BID Problem

   Having granted the BID request, the SLU must enter the send inhibit
   state.

4.4  Signal Problem

   Bracket if appropriate), and enter send inhibit state.

   This section defines a new negotiated TN3270E function called
   CONTENTION-RESOLUTION.  Support of this function implies that both
   the client and the server are able to handle the SDI, KRI and Signal
   header flags and the BID data type as defined in this specification.

   When the CONTENTION-RESOLUTION function is supported, the
   REQUEST-FLAG header field is interpreted as a bit mask, instead of a
   byte value, to allow the field to be used for Send Data, Keyboard
   Restore and Signal indicators.

   To use the Send Data Indicator the CONTENTION-RESOLUTION function
   must be supported by and agreed upon by both the server and client
   during TN3270E function negotiations.  SDI is only valid for TN3270E
   terminals in PLU-SLU session (3270-DATA type).  SDI is not used for
   SSCP-LU mode to avoid the overhead of the server having to BID to
   send asynchronous SSCP-LU-DATA records to the client.

   SDI is meaningful only when sent by the server.  It is sent in the
   REQUEST-FLAG field of the TN3270E header.  The SDI bit mask is:

      SEND-DATA-MASK  0x01

   In SNA LU-LU session, the server sends SDI when the host
   relinquishes send state with either the CDI or the EBI set in the
   SNA RU header.  In non-SNA implementations (where no EBI or CDI is
   available) SDI is sent when the session enters contention state.

   It is valid for the server to send a null 3270-DATA message (TN3270E
   header and EOR, no data) to indicate the send state to the client.
   This allows the server and client to handle a NULL RU containing EBI
   or CDI received from the host.

   SDI is not a replacement for the 3270 data stream WCC Keyboard
   Restore bit.  The client must track the 3270 WCC Keyboard Restore
   flag, TN3270E Keyboard Restore Indicator (KRI) and SDI to determine
   whether or not it can start sending data to the server.  If keyboard
   restore (WCC or KRI) is received, the keyboard is unlocked and the
   user is free to type.  However, the client cannot send data until
   the SDI is received.

   The client may send an ATTN key (IAC IP) while waiting for SDI (AID
   inhibit state).  ATTN causes the server to send a SIGNAL message to
   the host requesting Change Direction.  This may allow the user to
   recover from a direction state timing or synchronization problem
   (i.e. server neglected to send SDI).

   The RESET key may be used at the client to unlock the keyboard and
   may purge the type-ahead queue.  However, this does NOT allow the
   client to override the send state and forward data to the server.

4.5.2  Keyboard Restore Indicator (KRI)

   To use the Keyboard Restore Indicator the CONTENTION-RESOLUTION
   Function must be supported by and agreed upon by both the server and
   Client during TN3270E function negotiations.  KRI is only valid for
   TN3270E terminals in PLU-SLU session (3270-DATA type mode).

   KRI is meaningful only when sent by the server. KRI is sent in the
   REQUEST-FLAG field of the TN3270E header.  The KRI bit mask is:

      KEYBOARD-RESTORE-MASK  0x02

   A bit value of 1 (true) indicates to the client that its keyboard
   has been restored.  The client's the wait indicator is turned off,
   allowing the user to enter data.  However, the client may not send
   data to the server until it has also received SDI from the server
   (which may be set in the same REQUEST-FLAG field).

   Logically, the client treats KRI the same as it does the 3270 WCC
   Keyboard Restore bit.  KRI is not a replacement for the 3270 data
   stream WCC Keyboard Restore bit.  The client must still track both
   the KRI and 3270 WCC Keyboard Restore flag to determine the keyboard
   state.  Normally, one or the other will be received.  However, the
   client should not balk if both are received on a 3270-DATA message.

   The server ignores KRI in messages from the client and processes any
   data as usual depending on data type.

   The server sends KRI when it detects an "implied" keyboard restore
   during LU-LU session.  The server must track whether the host
   application has explicitly set the keyboard restore bit of the
   WCC byte in any of the 3270 data streams during a bracket.  If not,
   the server must set KRI in the TN3270E message header when EB is set
   in the SNA header.

   It is valid for the server to send a null 3270-DATA message (TN3270E
   Header and EOR, no data) to indicate the KRI to the client.  This
   allows the server and client to handle a NULL RU containing EBI
   received from the host.

4.5.3  BID Data Type

   When the client receives a BID message it can accept it by returning
   a positive response, or reject it by returning a negative response.
   The format of a positive response is the same as the positive
   response defined for the TN3270E RESPONSES function (i.e., RESPONSE
   data type, POSITIVE-RESPONSE code in RESPONSE-FLAG field, SEQ-NUMBER
   from BID).  When the client accepts the BID it immediately enters
   input inhibited state.  The keyboard is locked, the client displays
   the "Time" (wait) symbol and may not send data until SDI is received
   from the server.

   If the client already has buffered data to be sent to the host the
   client can reject the BID.  The negative response uses the TN3270E
   RESPONSES format (i.e., RESPONSE data type, NEGATIVE-RESPONSE code
   in RESPONSE-FLAG field, SEQ-NUMBER from BID).  Unless the client
   supports the SNA Sense Codes function, there is no defined reason
   information in the data portion of the negative response.  The
   server rejects the host's BID with a "Bracket Bid Reject" sense code
   (0x08130000).  The client's send state should remain unchanged upon
   negatively responding to a BID (i.e. if send state is input
   inhibited, it stays that way).

   If the client supports the SNA Sense Code function, it has the
   option of returning "Receiver in Transmit Mode" (0x081B0000) sense
   code.  This may be returned to reject the Bid when the user has
   started typing data but has not yet pressed an AID key.

   A potential race condition exists, where the client sends data at
   the same time the server is sending a BID to the client.  The race
   condition is handled by the server, and is relatively transparent to
   the client.  When the server receives data before the expected
   response to the BID, the data is treated as an implied negative
   response.  The server sends the Bracket Bid Reject (0x08130000)
   negative response to the host's BID and forwards the client's data
   to the host.  When the client's response to the BID is received it
   is discarded by the server.  The client's send state should be AID
   inhibited, whether it responded positively or negatively to the BID,
   because it has not received SDI for the data it sent previously.

4.5.4  SIGNAL Indicator

   The SIGNAL bit mask is:

      SIGNAL-MASK  0x04

   Upon receipt of Signal from the host, the server determines if the
   host already holds send state.  If so, the server returns positive
   response to the host immediately.  Otherwise, the server sends BID
   to the client with the SIGNAL indicator set to inform the client
   that it no longer holds send state and its keyboard is locked.

   input inhibit state.

   Upon receipt of the positive response from the client, the server
   returns positive response to the Signal. If the client sends
   negative response to a SIGNAL, even though it is not allowed to do
   so, the server ignores it and returns positive response to the
   Signal.

   To address the race condition described previously, the server
   should forward the inbound data to the host before returning
   positive response to the Signal.

   A de facto standard has arisen for handling Structured Field data
   stream FMHs in both TN3270 and TN3270E.  This de facto standard is
   referred to below as "silent FMH support".  Only FMH1 is supported
   and merely forwarded, in both directions, as data.  The receiver
   must recognize that the FMH is present by inspecting the first few
   bytes of the Telnet record and determining that they do not look
   like valid SCS data.  This is workable because FMH1 is a fixed
   6-byte string, and it only occurs at the start of a record.

5.1  FMH Overview

5.1.1  LU1 FMH1 Support

   The FMH1 format is:

   Where:

      BC RU
      length = 6
      concat = 0
      DSP = 0xB
      DSSEL = BEDS

5.1.4  IPDS Data Stream

   (See [4].)

      OIC RU
      length = 6
      concat = 0
      DSP = 0xD
      DSSEL = BDS, EDS

5.2  FMH Data Type

5.3.1  Bind Processing

5.3.2  Host/Server Flow

      Bind said FMH               400F 0000
      BC = 1                      400F 0000

   Example:

      0x0601000B6000
      0x0601300D4000
      0x0601300D2000

5.3.3 Client/Server Flow

5.3.4  FMH Responses

   If SNA-SENSE-CODE is supported the server takes the first four bytes
   of data following the TN3270E header as an SNA sense code and sends
   these, unchanged and unchecked, in the -rsp to the host application.

   If the server is providing silent FMH support to the clients and
   SNA-SENSE has not been negotiated then the server cannot in general
   tell whether the client is objecting to the FMH or to ensuing data.
   However, of the three currently identified FMHs requiring support,
   only 0x0601000B6000 can have data in the same chain.  Even then, the
   cause of the rejection may well be that this particular client does
   not expect FMHs at all.  Therefore it is recommended to interpret
   the negative response as rejection of the FMH itself.  The server
   should send SNA negative response 0x10080000 to the Host.

-rsp   Sense Code   Cause
   ----   ----------   -----

          0x08350006   Bind has byte 6 bit 1 set to 1 (FMHs will be
                       used) but printer does not support FMHs.

          0x400F0000   Incorrect use of FI (not BC RU), or Bind error
                       (byte 6 bit 1 set to 0).

   Note: The FI flag is not echoed in the SNA response.

      SNA-SENSE-CODE    2

   The SNA-SENSE function may be negotiated on either terminal or
   printer sessions.  When the SNA-SENSE and RESPONSES functions have
   been negotiated, the server is committed to accepting SNA-SENSE-CODE
   responses to 3270-DATA, SCS-DATA (LU1), BID and FMH-DATA data type
   messages.

   The client retains the option of providing specific SNA Sense codes,
   or letting the server map all errors to the appropriate SNA sense
   codes.

8. References

   [3] RFC 2355

9. Abbreviations

   -rsp    Negative response
   +rsp    Positive response

10.  Conventions

11.  Author's Note

12.  Author's Address

   Gene Pullen
   OpenConnect Systems
   2711 LBJ Freeway
   Dallas, Texas 75234

   Phone: (972) 484-5200

---

From: "Derek W. Bolton" <[email-masked]>
Date: Thu, 16 Jul 1998 11:02:58 +1000 (EST)

>    documents of the Internet Engineering Task Force (IETF), its
>    areas, and its working groups.  Note that the other groups may
>    also distribute working documents as Internet-Drafts.

>    documents at any time.  It is inappropriate to use
>    Internet-Drafts as reference material or to cite them other than
>    as "work in progress."

>    protocol.  It addresses issues and implementation problems
>    defined and discussed at the TN3270E/TN5250E Interoperability
>    Events.  Among the issues to be address by this draft are
>    SNA/TN3270E contention state resolution, SNA Sense Code support,
>    Function Management Header support, and TN3270E header
>    byte-doubling suppression.

>    To maintain backward compatibility with clients and servers that
>    do not support the extended TN3270E functions all new
>    functionality will be negotiated.  The current TN3270E function
>    negotiation rules apply.  Either side may request one or more of
>    the extended functions by adding them to the function code list
>    during TN3270E function negotiations.  Either side may reject the
>    function by removing it from the function list.

>    client can send data to the TN3270E server.  TN3270E provides for
>    an End-Of-Record (EOR) mechanism, which allows the client to
>    determine where the boundary is between 3270 data stream
>    commands.  The server sends EOR whenever it sends data to the
>    client for which the LIC (Last-In-Chain) indicator was set.
>    Clients have no choice but to interpret the presence of EOR as an
>    indication that it is okay to go ahead and send data back to the
>    host (providing the 3270 data-stream has restored the keyboard).
>    Since it is not uncommon for the Server to receive a LIC from the
>    host with no CDI (Change Direction Indicator) set, a serious
>    problem is created where the client will send data to the server
>    when it does not own the send state.

>    since TN clients are not aware of the bracket or direction state
>    the client is not aware that it is allowed to send data and often
>    hangs in keyboard lock state.

>    contention state, the Primary LU (PLU), or host, may bid for the
>    send state by either sending an explicit or implicit BID.  The
>    either granting the send state to the host or rejecting the
>    request.  Having granted the BID request, the SLU must enter the
>    send inhibit state.

>    An implicit BID occurs when the host (PLU) does not hold
>    direction, but attempts to send a message to the SLU when the
>    session is in Between Bracket state.  No BID actually flows but
>    is implied.  The SLU may accept or reject the PLU's attempt to
>    gain direction as if a BID had been sent.

>    In the TN3270 world, there is no mechanism for including the
>    client in the BID process.  The server must process the BID on
>    the client's behalf, without the ability to request the client
>    yield the send state.  This leads to a variety of problems when
>    the client attempts to send data inbound after the server has
>    sent positive response to a BID from the host.  These problems
>    include hung or lost sessions, lost data, or SNA or host
>    application error messages, depending on data flow, timing, and
>    how the server handles the BID process.

>    explicit) from the host (i.e. one that occurs in the BETB state)
>    it will forward it to the client.  The client will respond either
>    response), the client must enter the "input inhibited" state
>    until the host has returned the send state to the client.

>    force the SLU to yield direction.  For example, when the
>    secondary has rejected a BID and the host needs to override it.
>    The BID reject may occur when the user types some data (perhaps
>    an unintentional depression of the space bar) and does not press
>    an AID key.  The SNA architecture provides that the primary
>    (host) can send a Signal.  The secondary should reply with a
>    positive response, send a null RU with Change Direction to yield
>    direction (and Begin Bracket if appropriate), and enter send
>    inhibit state.

>    CONTENTION-RESOLUTION.  Support of this function implies that
>    both the client and the server are able to handle the SDI, KRI
>    and Signal header flags and the BID data type as defined in this
>    specification.

>    REQUEST-FLAG header field is interpreted as a bit mask, instead
>    of a byte value, to allow the field to be used for Send Data,
>    Keyboard Restore and Signal indicators.

>    must be supported by and agreed upon by both the server and
>    client during TN3270E function negotiations.  SDI is only valid
>    for TN3270E terminals in PLU-SLU session (3270-DATA type).  SDI
>    is not used for SSCP-LU mode to avoid the overhead of the server
>    having to BID to send asynchronous SSCP-LU-DATA records to the
>    client.

>    SDI is meaningful only when sent by the server.  It is sent in
>    the REQUEST-FLAG field of the TN3270E header.  The SDI bit mask
>    is:

>    send state.  A bit value of 0 (false) indicates the server (and
>    host by extension) holds the send state.

>    SNA RU header.  In non-SNA implementations (where no EBI or CDI
>    is available) SDI is sent when the session enters contention
>    state.

>    It is valid for the server to send a null 3270-DATA message
>    (TN3270E header and EOR, no data) to indicate the send state to
>    the client.  This allows the server and client to handle a NULL
>    RU containing EBI or CDI received from the host.

>    The server ignores SDI in messages from the client and processes
>    any data as usual depending on data type.

>    When SDI is received by the client and the current TN3270E
>    message has been processed (upon receipt of EOR) the client may
>    send data to the server. If RESPONSES have been negotiated, the
>    client must send RESPONSES to the server regardless of the send
>    state.  Upon receipt of SDI, the client must send all pending
>    RESPONSE messages before sending any keyboard input to the
>    server.

>    flag, TN3270E Keyboard Restore Indicator (KRI) and SDI to
>    determine whether or not it can start sending data to the server.
>    If keyboard restore (WCC or KRI) is received, the keyboard is
>    unlocked and the user is free to type.  However, the client
>    cannot send data until the SDI is received.

>    The client may send an ATTN key (IAC IP) while waiting for SDI
>    (AID inhibit state).  ATTN causes the server to send a SIGNAL
>    message to the host requesting Change Direction.  This may allow
>    the user to recover from a direction state timing or

>    The RESET key may be used at the client to unlock the keyboard
>    and may purge the type-ahead queue.  However, this does NOT allow
>    the client to override the send state and forward data to the
>    server.

>    Function must be supported by and agreed upon by both the server
>    and Client during TN3270E function negotiations.  KRI is only
>    valid for TN3270E terminals in PLU-SLU session (3270-DATA type
>    mode).

>    has been restored.  The client's the wait indicator is turned
>    off, allowing the user to enter data.  However, the client may
>    not send data to the server until it has also received SDI from
>    the server (which may be set in the same REQUEST-FLAG field).

>    stream WCC Keyboard Restore bit.  The client must still track
>    both the KRI and 3270 WCC Keyboard Restore flag to determine the
>    keyboard state.  Normally, one or the other will be received.
>    However, the client should not balk if both are received on a
>    3270-DATA message.

>    The server ignores KRI in messages from the client and processes
>    any data as usual depending on data type.

>    The server sends KRI when it detects an "implied" keyboard
>    restore during LU-LU session.  The server must track whether the
>    host application has explicitly set the keyboard restore bit of
>    the WCC byte in any of the 3270 data streams during a bracket.
>    If not, the server must set KRI in the TN3270E message header
>    when EB is set in the SNA header.

>    It is valid for the server to send a null 3270-DATA message
>    (TN3270E Header and EOR, no data) to indicate the KRI to the
>    client.  This allows the server and client to handle a NULL RU
>    containing EBI received from the host.

>    To use the BID data type the CONTENTION-RESOLUTION function must
>    be supported by and agreed upon by both the server and client
>    during TN3270E function negotiations.  The BID data type message
>    is only valid on terminal sessions in 3270-DATA (LU-LU) mode.
>    The BID data type is not valid during SSCP-LU mode, NVT mode, or
>    on printer sessions.

>    receipt of either an implicit or an explicit BID from the
>    host. The server must never send BID to the client when the host
>    already has direction (holds send state).

>    the DATA-TYPE field of the TN3270E header, inserts a null (0x00)
>    in the REQUEST-FLAG field, inserts ALWAYS-RESPONSE (0x02) in the
>    End-of-Record (EOR) is appended immediately after the TN3270E
>    header (there is no data portion for a BID message).

>    session.  The SEQ-NUMBER is returned by the client in its
>    response, to allow the server to coordinate the response with the
>    BID.  If RESPONSES has been negotiated the server should use the
>    next number in the progression of sequence numbers.  If RESPONSES
>    has not been negotiated, the server can use any number it
>    desires.  When the server receives a BID response from the
>    client, it is responsible for constructing the appropriate SNA
>    response to the host.

>    When the client receives a BID message it can accept it by
>    returning a positive response, or reject it by returning a
>    negative response.  The format of a positive response is the same
>    as the positive response defined for the TN3270E RESPONSES
>    function (i.e., RESPONSE data type, POSITIVE-RESPONSE code in
>    RESPONSE-FLAG field, SEQ-NUMBER from BID).  When the client
>    accepts the BID it immediately enters input inhibited state.  The
>    keyboard is locked, the client displays the "Time" (wait) symbol
>    and may not send data until SDI is received from the server.

>    If the client already has buffered data to be sent to the host
>    the client can reject the BID.  The negative response uses the
>    TN3270E RESPONSES format (i.e., RESPONSE data type,
>    NEGATIVE-RESPONSE code in RESPONSE-FLAG field, SEQ-NUMBER from
>    BID).  Unless the client supports the SNA Sense Codes function,
>    there is no defined reason information in the data portion of the
>    negative response.  The server rejects the host's BID with a
>    "Bracket Bid Reject" sense code (0x08130000).  The client's send
>    state should remain unchanged upon negatively responding to a BID
>    (i.e. if send state is input inhibited, it stays that way).

>    option of returning "Receiver in Transmit Mode" (0x081B0000)
>    sense code.  This may be returned to reject the Bid when the user
>    has started typing data but has not yet pressed an AID key.

>    the same time the server is sending a BID to the client.  The
>    race condition is handled by the server, and is relatively
>    transparent to the client.  When the server receives data before
>    the expected response to the BID, the data is treated as an
>    implied negative response.  The server sends the Bracket Bid
>    Reject (0x08130000) negative response to the host's BID and
>    forwards the client's data to the host.  When the client's
>    response to the BID is received it is discarded by the server.
>    The client's send state should be AID inhibited, whether it
>    responded positively or negatively to the BID, because it has not
>    received SDI for the data it sent previously.

>    To use the SIGNAL indicator the CONTENTION-RESOLUTION function
>    must be supported by and agreed upon by both the server and
>    client during TN3270E function negotiations.  The SIGNAL
>    indicator is only valid on BID data type messages.  The SIGNAL
>    indicator is sent in the REQUEST-FLAG field of the TN3270E
>    header.

>    A bit value of 1 (true) indicates that the BID is "Forced" and
>    the client MUST forfeit the send state.

>    Upon receipt of Signal from the host, the server determines if
>    the host already holds send state.  If so, the server returns
>    positive response to the host immediately.  Otherwise, the server
>    sends BID to the client with the SIGNAL indicator set to inform
>    the client that it no longer holds send state and its keyboard is
>    locked.

@DB:

There isn't any significance in when the server returns the +rsp
to the Signal.  The only advantage in waiting for the response from
the client is that it prohibits the appl from sending a second signal,
but it isn't likely to do that anyway.

The important thing is that the server sends null RU CD to the
appl when the client responds - unless it has forwarded data to
the Host in the meantime.  I don't see this mentioned anywhere.

The full algorithm is:

 send +rsp to signal
 if host already has direction, or in contention state,
   nothing more to do
 else
   /* client has direction */
   send forced bid to client
   if receive data first
     forward data to host as normal (will carry CD)
   else
     /* rsp first */
     send null RU CD to Host

Regards,
  Derek
(I'll look at the FMH stuff later.)

>    The client MUST return a positive response to the server and
>    enter input inhibit state.

>    negative response to a SIGNAL, even though it is not allowed to
>    do so, the server ignores it and returns positive response to the
>    Signal.