Re: Newly revised standards-track RFC
Bill Kelly <kellywh@mail.auburn.edu> Tue, 29 March 1994 22:13 UTC
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa07896; 29 Mar 94 17:13 EST
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa07892; 29 Mar 94 17:13 EST
Received: from list.nih.gov by CNRI.Reston.VA.US id aa15385; 29 Mar 94 17:13 EST
Received: from LIST.NIH.GOV by LIST.NIH.GOV (IBM VM SMTP V2R2) with BSMTP id 0111; Tue, 29 Mar 94 17:12:06 EST
Received: from LIST.NIH.GOV by LIST.NIH.GOV (Mailer R2.10 ptf000) with BSMTP id 0110; Tue, 29 Mar 94 16:58:13 EST
Date: Tue, 29 Mar 1994 15:42:45 -0600
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: 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: <9403291635.AA14510@mail.auburn.edu>
Message-ID: <9403291713.aa15385@CNRI.Reston.VA.US>
Fred writes: > Section 8 has a paragraph that starts: > > Note also that Telnet commands may appear anywhere in the Telnet > > stream. For this reason,... > > This seems to conflict with the paragraph just added: > > > The presence of Telnet commands within a TN3270E data message > > (i.e., between the header and the trailing IAC EOR) is not > > supported; neither clients nor servers should send such data. If a > > TN3270E data message containing an IAC-command sequence (other than > > IAC IAC) is received, the receiver should discard the IAC-command > > sequence and continue processing the TN3270E data message. > > IAC-commands should be sent between TN3270E data messages, with no > > header and no trailing IAC EOR. > > I suggest we delete the first sentence and first phrase. Start that > paragraph with: > > If either side wishes to transmit the decimal value 255... Yeah, this kind of bothered me, too...seems contradictory. Perhaps in addition to your suggestions, I should start the second paragraph like so: While Telnet commands by definition can appear anywhere in the Telnet stream, the presence of Telnet commands within a TN3270E data message... Or does this only serve to muddle the picture? Another thing I've been wondering about is whether or not our summarily throwing away Telnet commands like this is going to ruffle feathers among the "Telnet traditionalists" out there. Any thoughts? 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