Re: RFCS - Telnet commands mixed with 3270 data

Roger Fajman <RAF@cu.nih.gov> Wed, 16 March 1994 23:41 UTC

Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa19529; 16 Mar 94 18:41 EST
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa19525; 16 Mar 94 18:41 EST
Received: from list.nih.gov by CNRI.Reston.VA.US id aa25641; 16 Mar 94 18:41 EST
Received: from LIST.NIH.GOV by LIST.NIH.GOV (IBM VM SMTP V2R2) with BSMTP id 6306; Wed, 16 Mar 94 18:39:18 EST
Received: from LIST.NIH.GOV by LIST.NIH.GOV (Mailer R2.10 ptf000) with BSMTP id 6303; Wed, 16 Mar 94 18:39:11 EST
Date: Wed, 16 Mar 1994 18:37:42 -0500
Reply-To: IETF TN3270E Working Group List <TN3270E@list.nih.gov>
X-Orig-Sender: IETF TN3270E Working Group List <TN3270E@list.nih.gov>
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Roger Fajman <RAF@cu.nih.gov>
Subject: Re: RFCS - Telnet commands mixed with 3270 data
X-To: TN3270E@LIST.NIH.GOV
To: Multiple recipients of list TN3270E <TN3270E@list.nih.gov>
Message-ID: <9403161841.aa25641@CNRI.Reston.VA.US>

>                              Given that IAC doubling is a fact of life, and
> given that tn3270 and plain telnet implementations are intimately linked
> together (consider switching between NVT and tn3270 modes), I don't think that
> dealing with IACs embedded in a tn3270 data stream is any big deal. Whether
> or not any IAC sequences other than IAC IAC are supported, my code would
> still have to figure out what kind of IAC sequence it has received. If it
> isn't IAC IAC, chances are the code could just use existing telnet IAC
> processing routines with only minor changes. Also, it is quite useful to be
> able to use certain IAC sequences, like IAC IP, to emulate real 3270 keys
> that don't generate a character code like ATTN (we added this at the request
> of a customer whose tn3270 server worked like this). Even if RFCS were to
> prohibit only those IAC sequences that have to do with telnet option
> negotiation, I'm not convinced that there would be much of an effect on the
> design or implementation of client software. I'm much more worried about
> having to become SNA fluent and implement all those SNAisms if I have to
> implement RFCS. Now that's a lot of work!

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:

(1) Ignore it.
(2) Treat it as if it occurred before the block.
(3) Treat it as if it occurred after the block.

What I don't see is a way to do is to process it as ATTN halfway
through a block of 3270 data.  We could say in RFCS that it should not
be done and the meaning if it is done is left undefined.

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.