Re: Newly revised standards-track RFC

Roger Fajman <RAF@cu.nih.gov> Fri, 15 April 1994 00:37 UTC

Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa17625; 14 Apr 94 20:37 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa17621; 14 Apr 94 20:37 EDT
Received: from list.nih.gov by CNRI.Reston.VA.US id aa23386; 14 Apr 94 20:37 EDT
Received: from LIST.NIH.GOV by LIST.NIH.GOV (IBM VM SMTP V2R2) with BSMTP id 7776; Thu, 14 Apr 94 20:35:23 EDT
Received: from LIST.NIH.GOV by LIST.NIH.GOV (Mailer R2.10 ptf000) with BSMTP id 7772; Thu, 14 Apr 94 20:26:40 EDT
Date: Thu, 14 Apr 1994 20:24:13 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: Roger Fajman <RAF@cu.nih.gov>
Subject: Re: Newly revised standards-track RFC
X-To: TN3270E@LIST.NIH.GOV
X-cc: Peter DiCamillo <CMSMAINT%BROWNVM.BITNET@CU.NIH.GOV>
To: Multiple recipients of list TN3270E <TN3270E@list.nih.gov>
Message-ID: <9404142037.aa23386@CNRI.Reston.VA.US>

> Yes, it has been quiet, but I wasn't sure that the issue had been settled.
> Putting in the revised text can be done quickly, but that text first needs
> to be agreed to, and I'm not sure it has yet.
>
> As I see it, there are two proposed methods of handling Telnet commands
> that appear in a tn3270e data block:
>
> - One is to state that such IACs must be processed as if they occurred
>   after the tn3270 data.  This view is supported by the server vendors
>   who have expressed an opinion.
>
> - The other is to leave more flexibility to the implementor - let each
>   vendor decide whether to process these IACs before, "during", or after
>   the tn3270 data.
>
> There are probably valid arguments to be made both for and against
> allowing more flexibility; I'm willing to go with either approach we
> decide on.  In the absence of a vote, consensus, or decree from Bob, I'm
> planning on going with the "require that they be processed after the 3270
> data" approach because, while it is more rigid, it might well also be less
> prone to problems due to varying implementations.  I'm just a
> conservative kind of guy, I guess. :)

I still prefer the second approach, but would like to hear from more
implementors about whether they think it matters.  The two we have
heard from consitute a rather small subset.

Peter, how about your Mac TN3270 implementation?

Roger Fajman                                   Telephone:  +1 301 402 4265
National Institutes of Health                  BITNET:     RAF@NIHCU
Bethesda, Maryland, USA                        Internet:   RAF@CU.NIH.GOV