Re: Newly revised standards-track RFC

fab@fab.md.interlink.com Tue, 29 March 1994 22:53 UTC

Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa08167; 29 Mar 94 17:53 EST
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa08163; 29 Mar 94 17:53 EST
Received: from list.nih.gov by CNRI.Reston.VA.US id aa16066; 29 Mar 94 17:53 EST
Received: from LIST.NIH.GOV by LIST.NIH.GOV (IBM VM SMTP V2R2) with BSMTP id 0203; Tue, 29 Mar 94 17:50:04 EST
Received: from LIST.NIH.GOV by LIST.NIH.GOV (Mailer R2.10 ptf000) with BSMTP id 0200; Tue, 29 Mar 94 17:42:00 EST
Date: Tue, 29 Mar 1994 17:44:18 EST
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: fab@fab.md.interlink.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: <9403291753.aa16066@CNRI.Reston.VA.US>

> > 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...

> > 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?

I like:
 While Telnet commands ordinarily can appear anywhere in the Telnet
 stream, the presence of Telnet commands within a TN3270E data message...


> 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?

Let's write it the way we want, and see...