Re: Newly revised standards-track RFC
"David A. Borman" <dab@berserkly.cray.com> Thu, 31 March 1994 16:50 UTC
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa02615; 31 Mar 94 11:50 EST
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa02611; 31 Mar 94 11:50 EST
Received: from list.nih.gov by CNRI.Reston.VA.US id aa08835; 31 Mar 94 11:50 EST
Received: from LIST.NIH.GOV by LIST.NIH.GOV (IBM VM SMTP V2R2) with BSMTP id 4468; Thu, 31 Mar 94 11:47:23 EST
Received: from LIST.NIH.GOV by LIST.NIH.GOV (Mailer R2.10 ptf000) with BSMTP id 4465; Thu, 31 Mar 94 11:47:11 EST
Date: Thu, 31 Mar 1994 10:47:03 -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: "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: <9403311150.aa08835@CNRI.Reston.VA.US>
I've been loosely following the discussion of Telnet commands in the TN3270E data message, and its probably overdue that I comment... > 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? It'll ruffle my feathers... First, this is the Telnet protocol. That means that you always have to scan for the IAC in the entire data stream, the sender has to double any 255 data bytes, and the receiver has to turn any IAC IAC back into a 255 data byte. It is my understanding that the current spec continues to do this within the TN3270E data message, and that the issue is what about other Telnet commands in the data stream? I only see two issues. 1) Avoiding Telnet commands within a TN3270E data message will allow for faster processing of that data segement. 2) Some telnet commands imply a point in the data stream that something is to be done, that may be ambiguous or not make sense within a TN3270E data message. Are there others? These can be addressed by stating that it is strongly recommeneded that Telnet command sequences (other than IAC-IAC) should not be sent within a TN3270E data message. If they are, it is undefined (i.e., implementation dependent) how they may be processed (e.g, processing may be defered until after the TN3270E data message has been processed, requests to enable options may be denied). Since, you have to look for the IAC-IAC anyway, recognizing IAC-<foo> should only introduce extra overhead when an IAC-<foo> is received. To just state that any Telnet commands other than IAC-IAC within the TN3270E data message will be ignored encourages less than robust implementations. If some implementation actually does insert Telnet commands into the TN3270E data message, either intentionally or accidently, it can lead to problems. If the client sent "IAC DO FOO" within the data message, and the server just ignored it, the client will hang if it is waiting for the "IAC WILL FOO" or "IAC WONT FOO" response. And who knows, there may be some future Telnet option that does make sense within a TN3270E data message... I have no problem with trying to discourage Telnet commands from being sent within a TN3270E data message, but to mandate that any any Telnet commands within a TN3270E data message other than IAC-IAC will be ignored seems to be wrong. It would be much better to recommend that Telnet commands not be sent within the TN3270E data message, along with a short description of why (e.g., ambiguity and performance). Instead of: > 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. How about something like: The presence of Telnet commands within a TN3270E data message (i.e., between the header and the trailing IAC EOR) is not recommended; neither clients nor servers should send such data. IAC-commands should be sent between TN3270E data messages, with no header and no trailing IAC EOR. If a TN3270E data message containing an IAC-command sequence (other than IAC IAC) is received, it is implementation dependent how the IAC-command sequence will be processed; the processing may be defered until after the current TN3270E data message has processed. (Any IAC-command sequence that is received within a TN3270E data message that would normally require response must be responded to at some point to avoid the potential for deadlocks. Any IAC-command that does not require a response may just be ignored.) The goal is to encourage the spirit of not having arbitrary Telnet command sequences within the TN3270E data message, while making sure that if they do happen, that implementations will be robust enough to deal with them and that the protocol processing will remain deterministic. -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