Embedded-IACs

Jon Penner <jjp@bscs.com> Sat, 16 April 1994 08:28 UTC

Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa00735; 16 Apr 94 4:28 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id ab00724; 16 Apr 94 4:28 EDT
Received: from list.nih.gov by CNRI.Reston.VA.US id aa01057; 16 Apr 94 2:41 EDT
Received: from LIST.NIH.GOV by LIST.NIH.GOV (IBM VM SMTP V2R2) with BSMTP id 1986; Sat, 16 Apr 94 02:39:52 EDT
Received: from LIST.NIH.GOV by LIST.NIH.GOV (Mailer R2.10 ptf000) with BSMTP id 1983; Sat, 16 Apr 94 02:36:27 EDT
Date: Fri, 15 Apr 1994 14:41:41 -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: Jon Penner <jjp@bscs.com>
Subject: Embedded-IACs
X-To: TN3270E@list.nih.gov
To: Multiple recipients of list TN3270E <TN3270E@list.nih.gov>
Message-ID: <9404160241.aa01057@CNRI.Reston.VA.US>

Just got back in town and made it through all the e-mails.

Imbedded IAC <foos>:
Let's kind of step back and analyze where these might happen.
In a strict 3270 sense, there are only 2 cases where a client vendor might
send an imbedded IAC command. SYSREQ and ATTN.

The user hit ENTER and sent a screen to the host. The client s/w is sending
the screen data as fast as the TCP/IP stack will allow. The user has
no knowledge of any stack blockage and is just waiting for the x-clock to
go away. User presses SYSREQ or ATTN. Depending on the client architecture,
it might send the IAC command for SYSREQ or ATTN immediately, or queue it.
In any case the user has assumed that the previous screen he sent made it
to the host. This is one reason that the server should defer processing of the
SYSREQ or ATTN until the end of the current 3270 record. If it was processed
immediately, the 3270 story would fall apart. The server should process these
following the IAC EOR.

There is one problem that can occur that warrants the standard recommending
that imbedded IAC's not be used:
  If the client s/w indiscriminately sends the IAC ATTN or SYSREQ in the middle
  of screen data, see what might occur:

  ...screen data with IAC [imbedded IAC SYSREQ] IAC sequence...
                       ^-------------------------^

  Uh Oh.... Interpret this: IAC IAC SYSREQ IAC [whatever is next
                                                in data stream]

  Bummer, we trashed the data stream and the intended SYSREQ.

Other than the SYSREQ and ATTN IAC's there is no other reason for the
client to interrupt the 3270 datastream with anything having to do with 3270.

In a true Telnet sense, we do need to be able to handle other IAC's anytime
since we have agreed to being "binary".  Whether they are responded to
immediately or after the complete 3270 record has been received is of little
consequence as long as they are indeed handled. Since we are in "3270" mode
as opposed to NVT or any other mode as defined by the header most of the
other standard Telnet IACs don't make sense anyway.
The IACs that might be encountered mid-stream include Timing Mark and NOP.
Timing Mark is the only one I can think of that might be responded to before
processing the 3270 data; there are possibly others that also don't really have
anything to do with the timing or processing of 3270 data that could be
handled at the client's convenience.

-------
Other comments-
Pierre Goyette writes:
...
>  I would also encourage vendors to send certain IAC sequences in the
>same block. i.e. A particular vendor I won't name sends the IAC SB
>in two or three parts: the FF FA is sent alone, then the next packet
>contains 18 01, then the final packet FF F0. ...
No matter how the host sends commands, the definition of TCP/IP states that
routers, bridges, etc may break the data up into however large of pieces
it desires. There is never any guarantee that a piece of client s/w will
ever get the complete command sequence in a single packet and must always
be able to parse partial packets.

>  A number of vendors also send some negotiations twice, for example,
>I'll receive a DO BIN at the beginning and after some other
>negotiations, I'll get another DO BIN. I hope the RFC makes it crystal
>clear that options are negotiated ONCE ONLY.

We are Telnet, and can't impose this type of restriction. True it would be
weird for a server to send something like this, but you must be able to
parse it.
---------------
Eddie Renoux writes:
>I think that no other TELNET sequence has this problem and can be replied
>to immediately.  Thus could we in the section on SYS-REQ and ATTN specify
>that they will be processed after the TN3270 data EOR and leave it at that?
Which echo's my thoughts.
----------
David A. Borman writes:
...
>The goal is to encourage the spirit of not having arbitrary Telnet
>command sequences within the TN3270E data message, while making sure
>that if they do happen, that implementations will be robust enough
>to deal with them and that the protocol processing will remain
>deterministic.
I agree.
-------
Fred writes:
>Roger,   Have you also reviewed my suggestion to implement the commands
>AFTER the EOR is found?  I think this is safer.
Yep, in the cases I stated above.
------------------
David A. Borman also wrote:
>   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 an 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 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.
With the addition that in the event that SYSREQ or ATTN IACs are encountered
mid-stream, they should be handled by the server after the IAC EOR so all
of our implementations will cause the screen image at the host to be updated
similarly.

Eddie Renoux's reply seemed to indicate a similar feeling.
---------
Roger Fajman writes:
....
>As for a SYSREQ or ATTN in the middle of a 3270 block, you should be
>free to ignore such a request.
NOT! Customers get upset when things get ignored.
------------
David A. Borman writes:
>I contend that what you do will depend on which Telnet command has
>been received.  Therefore you either list all the Telnet commands
>and how they should be processed (uggh..) or you leave it as
>implementation dependent.
I think that if we state a rule for at least SYSREQ and ATTN, how implementors
do it for non-3270 IACs is not important as long as they ARE handled.
---------
That's all...
Jon Penner