Re: Newly revised standards-track RFC
"David A. Borman" <dab@berserkly.cray.com> Fri, 08 April 1994 16:52 UTC
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa09180; 8 Apr 94 12:52 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa09176; 8 Apr 94 12:52 EDT
Received: from list.nih.gov by CNRI.Reston.VA.US id aa12084; 8 Apr 94 12:52 EDT
Received: from LIST.NIH.GOV by LIST.NIH.GOV (IBM VM SMTP V2R2) with BSMTP id 1523; Fri, 08 Apr 94 12:50:52 EDT
Received: from LIST.NIH.GOV by LIST.NIH.GOV (Mailer R2.10 ptf000) with BSMTP id 1521; Fri, 08 Apr 94 12:50:46 EDT
Date: Fri, 08 Apr 1994 11:49:51 -0500
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: "David A. Borman" <dab@berserkly.cray.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: <9404081252.aa12084@CNRI.Reston.VA.US>
First, if it isn't already clear, I am not a 3270 developer, or 3270 user. I'm in this discussion from the viewpoint of a longtime Telnet developer/implementor. Any 3270 specific stuff I defer to those that know about it. My goal: Ensure that if Telnet commands are received within a TN3270E data message, despite strong recommendations that this should not be done, that the Telnet command will be processed in a reasonable manner. Having said that, you get 3 options: 1) Process the command immediatly when it is encountered. If the TN3270E data message is being buffered up before it is processed, then processing the Telnet Command immediatly is the same as if the Telnet Command had been received before the TN3270E data message. 2) Ignore the Telnet command. 3) Save the Telnet command for later processing, after the entire TN3270E data message has been received and processed. I contend that what you do will depend on which Telnet command has been received. Therefore you either list all the Telnet commands and how they should be processed (uggh..) or you leave it as implementation dependent. For example, if you get: IAC DO TIMING-MARK this will have no effect on the TN3270E data message. You can process this command right away, or process it later. It shouldn't matter. But my point is you have to process and reply to it with IAC WILL/WONT TIMING-MARK. You can't just ignore it. But if you get: IAC IP which is translated into an ATTN, Roger indicated the right thing to do is to just ignore it, which is easy enough to do. As Roger said: > We are talking here about how to handle something here that is never > supposed to be done. So it seems to me that we should allow > flexibility for the implementor to handle the case in the manner that > is most convenient for them, rather than making them write extra code > to handle this case in some particular way. I don't care whether the spec says you always process the commands immediatly, or always defer processing until after the data message, or leave it up to the implementor whether to process them immediatly or later. All I care about is that the spec should say that you have to process them. It doesn't bother to me that in some cases the correct action is to ignore it or to respond differently than if it had been received between data messages. I just don't like the line that says: 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. -David Borman, dab@cray.com
- 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