Re: Newly revised standards-track RFC
Bill Kelly <kellywh@mail.auburn.edu> Thu, 14 April 1994 19:50 UTC
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa12541; 14 Apr 94 15:50 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa12537; 14 Apr 94 15:50 EDT
Received: from list.nih.gov by CNRI.Reston.VA.US id aa17313; 14 Apr 94 15:50 EDT
Received: from LIST.NIH.GOV by LIST.NIH.GOV (IBM VM SMTP V2R2) with BSMTP id 6941; Thu, 14 Apr 94 15:48:13 EDT
Received: from LIST.NIH.GOV by LIST.NIH.GOV (Mailer R2.10 ptf000) with BSMTP id 6940; Thu, 14 Apr 94 15:30:58 EDT
Date: Thu, 14 Apr 1994 13:39:46 -0500
Reply-To: Bill Kelly <kellywh@mail.auburn.edu>
X-Orig-Sender: IETF TN3270E Working Group List <TN3270E@list.nih.gov>
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Bill Kelly <kellywh@mail.auburn.edu>
Subject: Re: Newly revised standards-track RFC
X-To: IETF TN3270E Working Group List <TN3270E@LIST.NIH.GOV>
To: Multiple recipients of list TN3270E <TN3270E@list.nih.gov>
In-Reply-To: <9404141243.AA08814@mail.auburn.edu>
Message-ID: <9404141550.aa17313@CNRI.Reston.VA.US>
> OK things have been quite for a few days. > > Bill are we ready for one more change and go? 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. :) If I hear no other comments, I'll go ahead and put this in the document over the weekend and post it by Sunday. Thanks, Bill Bill Kelly phone: (205) 844-4512 Auburn University Internet: kellywh@mail.auburn.edu
- 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