Subject: RE: Keyboard Restore Bid Proposal II

From: [email-masked]
Date: Tue, 9 Dec 1997 06:43:29 -0800

Derek,

        Thanks for your detailed response.  I will preface my response
by saying that there was some interest in removing SNA terminology as
much as possible from the wire protocol.  That's why the wire protocol
deals with terms like CTS and RTS rather than BID.  Do others have
strong opinions about the semantics?  I'm not wedded to either approach
- I was merely reacting to feedback that I had received.  I'd be
interested in hearing from other group members about their feelings on
this...

See my responses below (they start with "**")...

        -----Original Message-----
        From:   Derek W. Bolton [SMTP:[email-masked]]
        Sent:   Monday, December 08, 1997 10:52 PM
        To:     [email-masked]
        Cc:     [email-masked]
        Subject:        Re: Keyboard Restore Bid Proposal II

        Rodger,

        >         After further review of my original proposal and
        > conversations with some of the working group members I have a
new
        > proposal for how I believe that we should implement this (with
        > special thanks to Khang Le of Eicon for his input).

        >         It has been pointed out (by Khang Le in particular)
that my
        > original proposal stopped just sort of saying that we need a
way to
        > force TN3270E into half-duplex mode and that by acknowledging
that
        > we were, in fact, making it half duplex could lead to a
simpler
        > solution.  How about the following:

        > Negotiate HALF-DUPLEX FUNCTION:

        >                 Add a new TN3270E FUNCTION called HALF-DUPLEX
        > (function number 0x05).  Its purpose is to force TN3270E to
operate
        > in what is effectively half-duplex mode.  Since SNA is half
duplex,
        > it can be argued that TN3270E should also be half-duplex
(especially
        > when being full-duplex leaves holes in the protocol like the
ones
        > related to Keyboard Restore and BID).  Even though this
function
        > will make use of things like REQUEST-FLAG and RESPONSE-FLAG,
        > negotiation of the RESPONSES function is not required.  This
is
        > because I expect there will be customers that want this new
        > functionality without necessarily paying the performance
penalty
        > often associated with full-blown RESPONSES.  [If there is
        > disagreement on this point we can certainly go ahead and make
        > RESPONSES a prerequisite of HALF_DUPLEX].

        Well, SNA 3270 is not strictly half duplex.  After the Host
sends
        EB (and gets a response if nec.) the session is in contention.
        The key question is who resolves contention.  Your previous
        proposal, and this one, have the client as contention resolver.

        So I'd prefer to name this differently.  CONTENTION RESOLUTION
        FUNCTION is rather a mouthful.  How about ... BID function :-)?

**You're correct about this.  I just think that terms like CONTENTION
RESOLUTION and BID are too SNAish.  I was shooting for something more
generic.

        What LU types would this be negotiated for?  I've assumed it's
        only LUT2.  Is there any need for it on LUT1/3?  It might be
        nontrivial to extend it to printers.  E.g. an RTS framed as
        a null record might trigger a blank page.

**Good point.  I think that this should only be for LU Type2

        > Server sends CTS (Clear To Send - RS232 Lives!)

        This is not *strictly* necessary.  For a start, it's not quite
the
        right terminology.  Since the client is the contention resolver,
the
        server does not need to give the client permission to send.
Really
        this is an end-of-output marker for output that consists of
multiple
        chains.  Its true function is to replace the keyboard restore
flag
        (as, indeed, EB/CD do replace the keyboard restore flag in SNA).
Even
        as that it is not essential.  The server can (and the CIP server
does
        today) dicker with the keyboard restore flag in the Host output
so as
        to make it reflect the SNA state.  But that's a messy operation,
        particularly with WSFs, and it does make sense to map EB/CD more
        directly to something in the TN3270 datastream.

**Again, I don't want to get bogged down in the SNAness involved.
Servers care about this but clients do not.  Thus we should try and
avoid it in the wire protocol between server and client.  You're right
that it is an end of input marker, but isn't that the same thing as
saying "I'm done for now - your turn?"  Your point about dickering with
the WCC is well taken.  That would be another way of doing it.  Some
server vendors take that approach today but I didn't feel right about
making that the official proposal.

        So in a sense this is a separate issue from whether BID function
        is negotiated.  It is the 'end of output' function.  But I
        don't want to proliferate functions to be negotiated either,
        so I'm happy that it comes as part of the package.

        The corollary is that if BID function is negotiated then the
client
        must ignore the keyboard restore flag in the WCC.

**I'm not sure that I agree with this.  Just as I'm trying to avoid
having the servers dicker with the 3270 datastream, I want the clients
to be able to deal with it cleanly as well.  Could you explain why the
client should ignore the keyboard restore flag in the WCC?

As for the name, it seems to me that LAST would be more natural.  Or
        we could make the two names more consistent: FIRST (instead of
        BID/RTS) and LAST (instead of CTS).  Then the negotiated
function
        could be OUTPUT BRACKETTING or FIRST/LAST or START/STOP or
BEGIN/END
        or .....

**Again, this is a terminology difference.  Does anyone else have a
preference about the direction we should go in?  Toward SNA?  Away from
it?

        >         To address the Keyboard Restore problem, the server
must
        > indicate when it is done sending to the client (thus it is
okay for
        > the client to start sending data up to the server).  It does
this by
        > sending a CTS (REQUEST-FLAG set to 0x01).  Here are the three
cases
        > for when CTS should be sent by the server:

        > 1) If the TN3270E RESPONSES function has been negotiated and
DRI
        > (Definite Response Indicator) is set, as soon as it *receives*
a
        > response from the Client for a data chain that had the CDI or
EBI
        > (End Bracket Indicator) set.

        This seems like an unnecessary extra exchange.  Why can't I set
        CTS/LAST in the REQUEST-FLAG of the TN3270E header of the final
chain
        of data to the client?  The client should know not to act on the
LAST
        until it has sent the response.  Why do I need to send another
request
        after the client has sent the resp?  Am I missing something?

**What you say makes sense.  I think I had forgotten that the client
must send back the RESPONSE before sending any data.

        > 2) If the TN3270E RESPONSES function has been negotiated and
DRI is
        > *NOT* set, as soon as it *sends* a chain to the Client that
has
        > either the CDI or EBI set.

        > 3) If the TN3270E RESPONSES function has *NOT* been
negotiated, as
        > soon as it *sends* a chain to the Client that has either the
CDI or
        > EBI set.

        >                 Some might argue that overloading the
REQUEST-FLAG
        > is a bad idea.  However, it is currently only used for when
the
        > client wants to indicate that a printer error condition has
been
        > cleared. Here are four reasons as to why we shouldn't worry
about
        > overloading the RESPONSE-FLAG for this (and possibly other)
        > commands:

        > 1) This is such a rare thing
        > 2) adding an additional byte to the header would be wasteful
        > 3) embedding new Telnet commands within the datastream would
be even
        > worse
        > 4) the server never sends the REQUEST command so there's never
any
        > question as to how that flag should be interpreted.

        >                 Note that since the flag is set to 0x01 this
leaves
        > room for other bits to be used.  Implementors should expect
that
        > these bits will find other uses in the future (e.g. see the
next
        > section).

        > Server sends RTS (Request To Send - RS232 Lives!)

        >                 Whenever the server receives a BID or an
implied BID
        > from the host and the client owns the send state, the server
should
        > send an RTS to the client.  Hey, why not use another bit in
the
        > REQUEST-FLAG to accomplish this!  Let's say that a
REQUEST-FLAG with
        > a value of 0x02 implies an RTS when sent by the server to the
        > client.  This command should be sent in a TN3270 message with
the
        > valid data-type for the session (e.g. 3270-DATA, SCS-DATA).
My
        > current thinking is that this should otherwise be a NULL RU.

        You mean a null record, yes?  Could this be awkward for some
clients?
        How about, for LUT2, there is at least a Write cmd and a WCC?

**You're correct, I meant a NULL TN3270E record (i.e. TN Header plus
EOR).

        > However, if this is an implied BID, there may be some
performance
        > reasons (i.e. fewer round trips) to sending along the
associated
        > data [need further feedback on this point].

        That seems to be a server implementation choice.

        >                 If the client wants to grant the RTS, it sends
back
        > a positive response (RESPONSE command with RESPONSE-FLAG of
        > POSITIVE-RESPONSE).  If it wants to reject the RTS it sends
back a
        > negative response (RESPONSE command with RESPONSE-FLAG of
        > NEGATIVE-RESPONSE).  No reason code should be given for the
        > NEGATIVE-RESPONSE.  Note that the RESPONSE command and the
        > RESPONSE-FLAG are used regardless of whether or not the
RESPONSES
        > function was negotiated.  Again, this is because some
        > implementations may want the performance benefits of disabling
        > RESPONSES but yet have the proper functionality provided by
        > HALF-DUPLEX.

        ... and if the client sends -rsp with no reason code then the
server
        should send 081B to the Host.

        There is an awkward situation that can arise.  What if the user
        has started typing but has not yet pressed enter?  The client
        will naturally send a -rsp.  But now the user thinks better of
        it and wants to cancel the input (in fact, a key might have
        been depressed by accident).  Assuming the client has some
        way to decide that it wants to grant RTS after all, how does it
        tell the server and how would the server tell the Host?
        I don't know how real 3270s handle this.  It ought to be by
        using RTR, but as I understand it that's only used for printers.
        Anyone?

        >                 Any kind of packet received by the server from
the
        > client between the time the server sends the RTS and receives
a
        > RESPONSE, should be interpreted as a negative response.  This
deals
        > with the race case where the client sends data to the server
before
        > receiving the RTS.

        ... and the server should send -rsp 0813 to the Host.  This can
        be done before or after forwarding the data.

        > The client must still send the explicit response once it sees
the
        > RTS.  However, the server should ignore this response (because
if
        > the response is negative then it's redundant and if it's
positive
        > it's too late because the intervening RU was interpreted as a
        > negative response - thus either way it's useless information
to the
        > server).

        I assume that the server must not send RTS unnecessarily, for
        otherwise the client can not tell that the RTS lost the race.
        So after the client sends in data, if it receives RTS before
        data then it must judge that the RTS has failed.  There is
        therefore no point in sending a +rsp to this RTS.  I believe
        the client should send -rsp here to avoid any confusion.
**You're right that this is a sticky point.  To make things better the
server should certainly NOT send RTS unnecessarily.  As long as there
will always be a response from the server forthcoming everytime the
client sends 3270 data, then the client will be able to detect the race
and should know to send a -rsp to the RTS.  Is there ever a case where
the host won't send back data to something coming from the client?  If
there is (and I can't think of one), then the client won't be able to
detect the race and the server should treat either response as negative.

        >                 If RESPONSES is negotiated, then the client
response
        > must contain the proper matching sequence number that
accompanied
        > the RTS.  If RESPONSES are disabled, then the SEQ-NUM field
should
        > be set to 0 by the client and ignored by the server.

        >                 [NOTE: Some have suggested that CTS should be
used
        > by the client to indicate a positive response to RTS from the
        > server.  I believe that this creates too much ambiguity since
each
        > RU sent by the client is implicitly a CTS.  Thus, there could
easily
        > be confusion about whether a particular command is a positive
        > response or a negative response to a CTS.  If we force the
client to
        > always set CTS when it's okay for the server to send and clear
it
        > when it isn't, there could still be some race conditions where
the
        > server inadvertently interprets something as a positive
response
        > when it isn't.  Using a separate (already fairly well-defined)
        > mechanism for the client responses should make it cleaner for
the
        > server to interpret.  If RESPONSES have been negotiated then
the
        > client includes the SEQ-NUM of the RTS so the server knows for
sure
        > that this is the response.  If RESPONSES are not used then it
will
        > know by the RESPONSE command that it receives that it can only
be a
        > response to an RTS].

        > I hope that others will find this to be a cleaner approach to
        > solving the Keyboard Restore/BID problems.  I believe that
this
        > solution is an improvement over the previous one because it:

        > 1)      is easier to implement
        > 2)      has cleaner and more consistent semantics
        > 3)      does a better job of making this look like a single
problem
        > rather than two probems.

        >                 As always, feedback is appreciated

        >                 Rodger Erickson
        >                 Wall Data

        The interaction with ATTN and SYSREQ needs to be defined.  The
client
        must be allowed to send these even though it has granted RTS to
the
        server.  I think the server can just send ATTN on (as signal) to
the
        Host.  I don't see any need to check the send/receive/bracket
state.

**I think you're correct.  ATTN and SYSREQ will work exactly the same as
before.

        Regards,
          Derek

---

From: Michael Boe <[email-masked]>
Date: Tue, 09 Dec 1997 19:04:17 -0600

My preference is to base the terminology on the SNA. RTS & CTS remind me
of modems,
and that can't be good.  At least with the SNA terminology, a user can
go look up those terms in some SNA books and gain some understanding of
the problems involved.  They've got no hope if they go consult modem
manuals :-).

/msb

[email-masked] wrote:
>   ------------------------------------------------------------------------
>
>    Part 1.2       Type: application/ms-tnef
>               Encoding: base64