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 -0400
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
- Newly revised standards-track RFC Bill Kelly
- Re: Newly revised standards-track RFC Roger Fajman
- Re: Newly revised standards-track RFC Roger Fajman
- Re: Newly revised standards-track RFC fab
- Re: Newly revised standards-track RFC Bill Kelly
- Re: Newly revised standards-track RFC fab
- Re: Newly revised standards-track RFC David A. Borman
- Re: Newly revised standards-track RFC Bill Kelly
- Re: Newly revised standards-track RFC fab
- Re: Newly revised standards-track RFC David A. Borman
- Re: Newly revised standards-track RFC Robert G. Moskowitz
- Re: Newly revised standards-track RFC Roger Fajman
- Re: Newly revised standards-track RFC Jagan Bearelly
- Re: Newly revised standards-track RFC fab
- Re: Newly revised standards-track RFC David A. Borman
- Re: Newly revised standards-track RFC fab
- Re: Newly revised standards-track RFC Roger Fajman
- Re: Newly revised standards-track RFC David A. Borman
- Re: Newly revised standards-track RFC Robert G. Moskowitz
- Re: Newly revised standards-track RFC Bill Kelly
- Re: Newly revised standards-track RFC Roger Fajman
- Re: Newly revised standards-track RFC Pierre Goyette - The 3270 Man
- Re: Newly revised standards-track RFC Peter DiCamillo