Re: Newly revised standards-track RFC

"David A. Borman" <> Fri, 08 April 1994 16:52 UTC

Received: from by IETF.CNRI.Reston.VA.US id aa09180; 8 Apr 94 12:52 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa09176; 8 Apr 94 12:52 EDT
Received: from by CNRI.Reston.VA.US id aa12084; 8 Apr 94 12:52 EDT
Received: from LIST.NIH.GOV by LIST.NIH.GOV (IBM VM SMTP V2R2) with BSMTP id 1523; Fri, 08 Apr 94 12:50:52 EDT
Received: from LIST.NIH.GOV by LIST.NIH.GOV (Mailer R2.10 ptf000) with BSMTP id 1521; Fri, 08 Apr 94 12:50:46 EDT
Date: Fri, 08 Apr 1994 11:49:51 -0500
Reply-To: IETF TN3270E Working Group List <>
X-Orig-Sender: IETF TN3270E Working Group List <>
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: "David A. Borman" <>
Subject: Re: Newly revised standards-track RFC
To: Multiple recipients of list TN3270E <>
Message-ID: <9404081252.aa12084@CNRI.Reston.VA.US>

First, if it isn't already clear, I am not a 3270 developer, or 3270
user.  I'm in this discussion from the viewpoint of a longtime
Telnet developer/implementor.  Any 3270 specific stuff I defer to
those that know about it.

My goal: Ensure that if Telnet commands are received within a
        TN3270E data message, despite strong recommendations that
        this should not be done, that the Telnet command will be
        processed in a reasonable manner.

Having said that, you get 3 options:
        1) Process the command immediatly when it is encountered.
           If the TN3270E data message is being buffered up before
           it is processed, then processing the Telnet Command
           immediatly is the same as if the Telnet Command had
           been received before the TN3270E data message.
        2) Ignore the Telnet command.
        3) Save the Telnet command for later processing, after
           the entire TN3270E data message has been received
           and processed.

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.

For example, if you get:
this will have no effect on the TN3270E data message.  You can
process this command right away, or process it later.  It shouldn't
matter.  But my point is you have to process and reply to it with
IAC WILL/WONT TIMING-MARK.  You can't just ignore it.  But if you
        IAC IP
which is translated into an ATTN, Roger indicated the right
thing to do is to just ignore it, which is easy enough to do.

As Roger said:

> We are talking here about how to handle something here that is never
> supposed to be done.  So it seems to me that we should allow
> flexibility for the implementor to handle the case in the manner that
> is most convenient for them, rather than making them write extra code
> to handle this case in some particular way.

I don't care whether the spec says you always process the commands
immediatly, or always defer processing until after the data message,
or leave it up to the implementor whether to process them immediatly
or later.  All I care about is that the spec should say that you have
to process them.  It doesn't bother to me that in some cases the
correct action is to ignore it or to respond differently than if it
had been received between data messages.  I just don't like the
line that says:

        If a TN3270E data message containing an IAC-command sequence
        (other than IAC IAC) is received, the receiver should discard
        the IAC-command sequence and continue processing the TN3270E
        data message.

                        -David Borman,