Re: Newly revised standards-track RFC (IAC/EOR)

[Eddie Renoux <[e-mail]>]

It seems we are still a ways from consensus on imbedded TELNET commands in
the TN3270 data block.  McDATA currently tries to process the TELNET commands
immediately.  I think this is a mistake and could cause real problems if a
client were unkind enough to send pseudo ATTN or SYS-REQ keys in the middle
of TN3270 data.  The basic problem is that the protocol is set up to send
3270 packets between the client and the server.  The protocol has an exception
which is the processing of SYS-REQ and ATTN keystrokes.  They are not
3270 data as such and the protocol definition will be deficient if it is not
specified how these keystrokes should be handled when they are in the middle
of TN3270 data.  The clients have no similar problem (quite) since the
server will only send TN3270 data to the client (except perhaps for
NOP keep alive sequences) once the data block is started.

I can understand the need of the clients to put SYS-REQ and ATTN keys in
the middle of the TN3270 due to their layered architecture (the keystroke
parser at the higher level sends it to the lower level which is in the middle
of sending data to the server).  To properly handle these at the server
we need to know what to do with the data that follows these keystrokes if
they are to be processed immediately.  My best guess is that the client
probably meant for the keystrokes to have NO affect on the TN3270 data that
that follows them (up to the EOR).  In this case, they could/should be held
till the end of the block and then processed.

I think that no other TELNET sequence has this problem and can be replied
to immediately.  Thus could we in the section on SYS-REQ and ATTN specify
that they will be processed after the TN3270 data EOR and leave it at that?
I cannot see that this would adversely impact the client vendors.  It would
allow the inclusion of these keystrokes in the datastream when they occurred
thus making it easier for the clients.  It would be somewhat harder for the
server to store them up till the end of the data but that IMHO would be
better than leaving it up to each vendor how to handle this anomaly.  My
opinion is that the only alternatives are to have an incomplete definition
of how TN3270E should work (which means that not all clients will work with
all vendor's implementation of the RFC) or very specifically detail exactly
how to handle the data following the SYS-REQ or ATTN.

Eddie Renoux   [e-mail]