Re: Newly revised standards-track RFC (IAC/EOR)
Roger Fajman <RAF@cu.nih.gov> Fri, 15 April 1994 22:52 UTC
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa13893; 15 Apr 94 18:52 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa13889; 15 Apr 94 18:52 EDT
Received: from list.nih.gov by CNRI.Reston.VA.US id aa21615; 15 Apr 94 18:52 EDT
Received: from LIST.NIH.GOV by LIST.NIH.GOV (IBM VM SMTP V2R2) with BSMTP id 1229; Fri, 15 Apr 94 18:50:54 EDT
Received: from LIST.NIH.GOV by LIST.NIH.GOV (Mailer R2.10 ptf000) with BSMTP id 1228; Fri, 15 Apr 94 18:47:44 EDT
Date: Fri, 15 Apr 1994 18:45:32 -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 (IAC/EOR)
X-To: TN3270E@LIST.NIH.GOV
To: Multiple recipients of list TN3270E <TN3270E@list.nih.gov>
Message-ID: <9404151852.aa21615@CNRI.Reston.VA.US>
A clarification: we are talking about the definition of TN3270E protocol, not TN3270. TN3270 is what it is and we are not trying to fix it. We are defining a new protocol. The current draft says that Telnet options ought not to be sent in the middle of 3270 data blocks. So we are talking here about what to do in the case that someone does something that the standard says is not proper. Of course, the draft could be changed to allow such behavior, but I don't think that's a good idea. There are some weird cases when Telnet options can appear in the middle of a 3270 block. Suppose a request to exit TN3270E mode appears in the middle of a 3270 block. Well, I guess such a request should be denied, while it probably would be accepted between blocks. I suppose that a request to exit binary mode while in TN3270E mode would always be denied, since TN3270E mode implies binary without it being explicitly negotiated. Telnet and, by extension, TN3270E say nothing about what bytes must appear together in what TCP packets. Each byte could be in a separate packet if an implementation (foolishly) wanted to do it that way. Anyway, I'm off Sunday on a week's vacation, so you've probably heard the last from me on this. Roger Fajman Telephone: +1 301 402 4265 National Institutes of Health BITNET: RAF@NIHCU Bethesda, Maryland, USA Internet: RAF@CU.NIH.GOV
- Re: Newly revised standards-track RFC (IAC/EOR) Eddie Renoux
- Re: Newly revised standards-track RFC (IAC/EOR) Eddie Renoux
- Re: Newly revised standards-track RFC (term negot… Eddie Renoux
- Re: Newly revised standards-track RFC (IAC/EOR) Roger Fajman