Re: RFCS - Telnet commands mixed with 3270 data

[Bill Kelly <[e-mail]>]

Hi,

Thanks to all for pointing out this ambiguity in RFCS.

It appears to me that we agree on a couple of things:

- IAC doubling must be allowed in order to support a 0x255 being
  interpreted as data.

- there's not much meaning (in terms of tn3270e) in allowing real
  IAC-command sequences in the middle of a tn3270e block (i.e., between
  the tn3270e header and the IAC-EOR).

RFCS mentions only three IAC-command sequences as having meaning in terms
of tn3270e - IAC IP to emulate the ATTN key, IAC AO to emulate the SYSREQ
key, and IAC NOP as an optional implementation of a keep-alive mechanism.
Only two of these can be sent because of some action on the part of the
user - IP and AO (NOP would be sent "behind-the-scenes" without the user
having done anything).  In both of these cases, it makes no sense to have
the IP/AO imbedded in 3270 data - this can't happen for either ATTN or
SYSREQ in an SNA environment.  I'd say that if either of these is received
in the middle of a tn3270e data message, it's the 3270 data that should be
thrown away - from the tn3270e header right through the IAC-EOR.  Only the
emulated ATTN or SYSREQ key should be processed.

Couldn't we extend this to cover all IAC-command sequences?  What do you
think about changing the draft to say that IAC-command sequences should be
sent outside of a tn3270e data message, and should not include the
header/EOR stuff?  That any IAC-command sequence (excluding, of course,
IAC-IAC) found inside a tn3270e data message (between a header and an
IAC-EOR) should result in that 3270 message being scanned only for
additional IAC-command sequences, then discarded?

Thanks,
Bill

Bill Kelly               phone: [phone]
Auburn University     Internet: [e-mail]