Re: Newly revised standards-track RFC Wed, 06 April 1994 15:54 UTC

Received: from by IETF.CNRI.Reston.VA.US id aa06179; 6 Apr 94 11:54 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa06175; 6 Apr 94 11:54 EDT
Received: from by CNRI.Reston.VA.US id aa14961; 6 Apr 94 11:54 EDT
Received: from LIST.NIH.GOV by LIST.NIH.GOV (IBM VM SMTP V2R2) with BSMTP id 2141; Wed, 06 Apr 94 11:51:49 EDT
Received: from LIST.NIH.GOV by LIST.NIH.GOV (Mailer R2.10 ptf000) with BSMTP id 2138; Wed, 06 Apr 94 11:07:41 EDT
Date: Wed, 06 Apr 1994 11:10:09 -0400
Reply-To: IETF TN3270E Working Group List <>
X-Orig-Sender: IETF TN3270E Working Group List <>
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
Subject: Re: Newly revised standards-track RFC
To: Multiple recipients of list TN3270E <>
Message-ID: <9404061154.aa14961@CNRI.Reston.VA.US>

> On Thu, 31 Mar 1994, David A. Borman wrote:
> > > Another thing I've been wondering about is whether or not our summarily
> > > throwing away Telnet commands like this is going to ruffle feathers among
> > > the "Telnet traditionalists" out there...
> >         2) Some telnet commands imply a point in the data stream
> >            that something is to be done, that may be ambiguous or
> >            not make sense within a TN3270E data message.
> ...I think #2 is the main problem...
> Yes.  The fact that we are still requiring scanning for IACs (even if it
> were only to find IAC-IAC) irks some of the vendors, I think.  But given
> the requirement for that scanning, I see little additional overhead in
> looking for the "<foo>"s.
> > ...If some implementation actually does insert Telnet
> > commands into the TN3270E data message, either intentionally or
> > accidently, it can lead to problems.  If the client sent "IAC DO FOO"
> > within the data message, and the server just ignored it, the client
> > will hang if it is waiting for the "IAC WILL FOO" or "IAC WONT FOO"
> > response.
> Again, I agree.
> > I have no problem with trying to discourage Telnet commands from being
> > sent within a TN3270E data message, but to mandate that any any Telnet
> > commands within a TN3270E data message other than IAC-IAC will be
> > ignored seems to be wrong.  It would be much better to recommend that
> > Telnet commands not be sent within the TN3270E data message, along with
> > a short description of why (e.g., ambiguity and performance).
> >
> > How about something like:
> >
> >    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.
> >    IAC-commands 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 how the IAC-command sequence will be
> >    processed; the processing may be defered until after the current
> >    TN3270E data message has processed.  (Any IAC-command sequence that
> >    is received within a TN3270E data message that would normally require
> >    response must be responded to at some point to avoid the potential
> >    for deadlocks. Any IAC-command that does not require a response
> >    may just be ignored.)
> >
> > 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.

This language is not strong enough and precise enough for me.  How about
saying that IAC sequences (other than IAC-IAC) WILL be handled as if they
appeared AFTER the IAC EOR if they appear inside a TN3270E frame.
For this reason, they SHOULD be sent outside a TN3270E frame.