Subject: Re: tn3270e header

From: Bimal Shah <[email-masked]>
Date: Tue, 14 Jul 1998 17:01:19 -0400

Thanks for the clarification. That's how I was looking at it too.
But, just wanted to see there is nothing hidden that I'm missing.

One question though.
What if client receives some NON-bind image data after it
receives TN3270E-BIND header? I think, the client will assume
it's a "bind-image data" and it will try to process it accordingly.
Right?

-  Bimal Shah (Pcom - IBM)

"On whatever trails you walk, there are no strangers only friends not yet met"

---

From: Michael Boe <[email-masked]>
Date: Tue, 14 Jul 1998 14:35:16 -0700 (PDT)

> it's a "bind-image data" and it will try to process it accordingly.

Well....that gets on some pretty shaky ground, at least as far as
implementations go.  Let me see if I understood you correctly:

  Server sends:  TN3270E(Bind)
  Server sends:  TN3270E(SSCP-LU)[data] or TN3270E(LU-LU)[data] <IAC><EOR>
  Server sends:  [bind-image data]<IAC><EOR>

In this case (and all cases for TN3270E), the client knows enough to
successfully parse the datastream. It can do this by "recursing" the
parse-stream to handle the TN3270(SSCP/LU-LU) record before returning to the
TN3270E(Bind) record.  That's the first piece.

The ordering of the parsed messages is the headache.  If the rule is "first
started, first applied," then the BIND-image gets processed first then the
SSCP/LU-LU data gets processed. Of course, the rule might instead be "first
ended, first applied," in which case the SSCP/LU-LU data would be dealt with
first.  Either one is allowed by the spec (page 16 of RFC2355):

   It is strongly recommended that Telnet commands (other than IAC IAC)
   should be sent between TN3270E data messages, with no header and no
   trailing IAC EOR.  If a TN3270E data message containing either IAC IP
   (to be interpreted as 3270 Attention) or IAC AO (to be interpreted as
   SYSREQ) is received, the receiver should defer processing the command
   until the 3270 data has been processed (see the appropriate sections
   for discussion of 3270 Attention and SYSREQ).  If a TN3270E data
   message containing any other IAC-command sequence (other than IAC
   IAC) is received, it is implementation dependent when the IAC-command
   sequence will be processed, but it must be processed.  The receiver
   may process it immediately, which in effect causes it to be processed
   as if it had been received before the current TN3270E data message,
   or the processing may be deferred until after the current TN3270E
   data message has been processed.  It is because of this ambiguity
   that the presence of Telnet commands within a TN3270E data message
   (i.e., between the header and the trailing IAC EOR) is not
   recommended; neither clients nor servers should send such data.

The last sentence is the most important :-).

btw, there *are* server implementations that send this sequence:
    [...data]<IAC><DO><TIMEMARK><IAC><EOR>

This is because some clients blew up when faced with the more acceptable
    [...data]<IAC><EOR><IAC><DO><TIMEMARK>

yet behaved well with the more bizarre syntax.  Don't ask me why. As a client,
try hard to cope with state-independent Telnet commands like DO TIMEMARK or
NOP--they could get sent anytime except just after an FF.  And the servers
should (through years of experience :-) be able to cope with whatever order you
choose to process them in.  And oh yes, the TN3270E RT MIB would suggest that
client not respond to the TIMEMARK until after the data has been processed.

/msb

---

From: Michael Boe <[email-masked]>
Date: Tue, 14 Jul 1998 16:00:48 -0700 (PDT)

On 14-Jul-98 at 17:58, Michael Boe ([email-masked]) wrote:
> parse-stream to handle the TN3270(SSCP/LU-LU) record before returning to
> the TN3270E(Bind) record.  That's the first piece.

Ah....Derek reminded me that the TN3270E header isn't introduced by an IAC
(which I conveniently forgot). So such a recursive parse scheme is impossible,
since there's no way to signal the point at which to start the recursion.
Therefore, it's impossible to nest TN3270E messages. Not that I've seen anybody
actually attempt such a thing.

The IAC command stuff still stands.

/msb

> ended, first applied," in which case the SSCP/LU-LU data would be dealt
> with first.  Either one is allowed by the spec (page 16 of RFC2355):
>
> yet behaved well with the more bizarre syntax.  Don't ask me why. As a
> client, try hard to cope with state-independent Telnet commands like DO
> TIMEMARK or NOP--they could get sent anytime except just after an FF.  And
> the servers should (through years of experience :-) be able to cope with
> whatever order you choose to process them in.  And oh yes, the TN3270E RT
> MIB would suggest that client not respond to the TIMEMARK until after the
> data has been processed.
>
> /msb