Re: RFCS - Telnet commands mixed with 3270 data

[Scott Sminkey - Sustaining Eng Group <[e-mail]>]

[e-mail] (Eddie Renoux) wrote a good description of
problems in handling telnet commands embedded in a 3270 data stream,
bringing up these good points:
>...I am unsure how all possible TELNET options should
>be handled "correctly" inside the 3270 data...
>...I do not see the reason for wanting to put real IACs in the
>datastream...
>To allow imbedded TELNET commands opens a can of worms that will make
>each vendor's implementation different and inhibit interoperability
>unless each possible condition is carefully spelled out (IMHO).

and [e-mail] (Roger Fajman) wrote:
>The reason I mentioned IACs inside 3270 blocks was not to raise again
>the issue of IAC doubling.  Rather I think that the RFC should
>explicitly state the meaning of something like IAC IP (which RFCS
>defines to be ATTN) in the middle of a 3270 data block.  I see 3
>possibilities for handling it in a piece of code...
>What we have here is an ambiguity in the spec.  I don't think we should
>knowingly put out specs with ambiguities.  It shouldn't be a difficult
>thing to fix.

Of course, I agree that *how* to interpret telnet IAC sequences inside a
3270 data stream is not clear and it must be made unambiguous in RFCS.
The point if my posting, which I didn't make clear, is that client code
will have to deal with IAC sequences in a 3270 datastream regardless of
whether or not they can legally be there. Perhaps the simplest case is
that the presence of any IAC is reason to abort the session. (I mention
this to make a point, not to suggest that this is the way to proceed.)
Maybe IAC IAC would be legal and IAC followed by anything else would cause
the session to be aborted. Maybe certain IAC sequences would be legal and
require certain action and others would be ignored and still others would
cause a session to be aborted. Whatever should be done must be spelled out
in RFCS, and once that is done, implementation ought to be straightforward.
I suggest that the complexity of handling IAC sequences isn't really an
issue because IACs have to be handled somehow in any case. The much more
difficult issue is to agree on what each IAC sequence should mean if it
appears in a 3270 data stream. I think we can take Eddie's and Roger's
advice and minimize the number of IAC sequences that will be legal inside
a 3270 data stream simply because it's too hard to figure out what each
one ought to do.

- Scott
=========
Scott Sminkey                           email: [e-mail]
Software Sustaining Engineering         voice: 508 952-4792
Xyplex, Inc.                            fax: [phone]
295 Foster St.                          (Opinions, comments, etc. are mine,
Littleton, MA 01460                                     not Xyplex's...)