Re: RFCS - Telnet commands mixed with 3270 data

["Robert G. Moskowitz" <[e-mail]>]

I said:

>>Opinions on which way we should go on IACs within a 3270 datastream will
>>be solicited until the end of the week.  I would like to have the last
>>call on IETF issued on this before the Thursday of next week

Eddie Renoux said:

>I like having no TELNET IACs within the TN3270 datastream.  This would make
>the examination of the datastream that the server has to do much easier.
>It would also eliminate the possibility of confusion if a "pseudo" ATTN
>(IP) were found (allowed) in the middle of a TN3270 datastream.
>(I realize the server still has to strip the doubled IACs.)

Let me restate a couple of points.

IAC doubling is the way the TELNET protocol works in 8 bit mode.  There is
no way around it.  There are only two ways for us to avoid it.

#1      Get off port 23.  --  Not likely.

#2      Develop a Finite State Automata that would go into the RFC that
        would definitively explain the logic flow to handle intermixing
        and mix ups of real TELNET and our no IAC doubling.  I called for
        this FSA back in June, I think, and since no one has come forward,
        I do not see us delaying everything even longer to work it out and
        to get a lot of people feeling comfortable that we have covered all
        of the cases.

ERGO, IAC doubling will be an integral part of RFCS.

Next question is will we avoid real IACs between the start of a data block
and the EOR?

It seems like for debugging purposes it would be best to do that (and I have
done a fair amount of TN3270 debugging in the past year). I fail to see what
logic processing it would save the vendors (and thus preformance
improvements) given that they have to scan for IAC doubling and IAC EORs
anyway.  But then I don't write code.

Bob