Re: Newly revised standards-track RFC

fab@fab.md.interlink.com Thu, 07 April 1994 18:14 UTC

Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa10652; 7 Apr 94 14:14 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa10648; 7 Apr 94 14:14 EDT
Received: from list.nih.gov by CNRI.Reston.VA.US id aa20153; 7 Apr 94 14:14 EDT
Received: from LIST.NIH.GOV by LIST.NIH.GOV (IBM VM SMTP V2R2) with BSMTP id 7348; Thu, 07 Apr 94 14:12:16 EDT
Received: from LIST.NIH.GOV by LIST.NIH.GOV (Mailer R2.10 ptf000) with BSMTP id 7347; Thu, 07 Apr 94 13:43:21 EDT
Date: Thu, 7 Apr 1994 13:45:43 EDT
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: fab@fab.md.interlink.com
Subject: Re: Newly revised standards-track RFC
X-To: TN3270E@LIST.NIH.GOV
To: Multiple recipients of list TN3270E <TN3270E@list.nih.gov>
Message-ID: <9404071414.aa20153@CNRI.Reston.VA.US>

> Ok, Telnet commands within a TN3270E data message must be processed,
> but they may be processed either before or after the TN3270E data
> message that contains them (implementation dependent).
>
>                         -David Borman, dab@cray.com
>

I for one do not like this ambiguity.  Here is a hole into which great
interoperability problems may someday fall.  Dave, please argue WHY
the options should be processed EITHER before or after, instead of
just AFTER.

Here is Eddie's reason why it should be AFTER:

>I think it is better to do it after the EOR because there might be more
>TN3270 data than could possibly be buffered up.  It is presumed that the
>TELNET options could more easily be saved until the EOR is rec'd.
>Eddie Renoux   elr@mcdata.com

Fred