Re: Newly revised standards-track RFC (EOR/IAC)

Eddie Renoux <> Thu, 07 April 1994 19:30 UTC

Received: from by IETF.CNRI.Reston.VA.US id aa11930; 7 Apr 94 15:30 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa11926; 7 Apr 94 15:30 EDT
Received: from by CNRI.Reston.VA.US id aa22444; 7 Apr 94 15:30 EDT
Received: from LIST.NIH.GOV by LIST.NIH.GOV (IBM VM SMTP V2R2) with BSMTP id 7690; Thu, 07 Apr 94 15:25:04 EDT
Received: from LIST.NIH.GOV by LIST.NIH.GOV (Mailer R2.10 ptf000) with BSMTP id 7688; Thu, 07 Apr 94 14:49:36 EDT
Date: Thu, 07 Apr 1994 12:47:28 -0600
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: Eddie Renoux <>
Subject: Re: Newly revised standards-track RFC (EOR/IAC)
To: Multiple recipients of list TN3270E <>
In-Reply-To: <> from "David A. Borman" at Apr 7, 94 11:05:18 am
Message-ID: <9404071530.aa22444@CNRI.Reston.VA.US>

Proposed by David:
>    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 immediatly, which in effect causes it
>    to processed as if it had been received before the current TN3270E
>    data message, or the processing may be defered 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.
>                         -David Borman,
I disagree that processing immediatly is tha same as processing TELNET
sequences before the TN3270 data.  If a SYS-REQ is rec'd in the middle
of PLU-SLU data then the rest of the TN3270 data is invalid thus all TN3270
data following the SYS-REQ would be rejected and all TN3270 data preceeding
the SYS-REQ would be sent to the host.  This seems bad to me -- I cannot
see how to reject half of a message.  I cannot see how the preceeding data
can be recalled from the host if it has already been sent.  I feel the
only practical solution is to process the TELNET sequences after the EOR
(but I would really rather see them banned outright).  Any loopholes in
the protocol are bad and will eventually cause problems.
Eddie Renoux