Re: Last Call: TN3270 Extensions for LUname and Printer Selection

Roger Fajman <RAF@cu.nih.gov> Fri, 18 February 1994 03:10 UTC

Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa22262; 17 Feb 94 22:10 EST
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa22258; 17 Feb 94 22:10 EST
Received: from list.nih.gov by CNRI.Reston.VA.US id aa27089; 17 Feb 94 22:10 EST
Received: from LIST.NIH.GOV by LIST.NIH.GOV (IBM VM SMTP V2R2) with BSMTP id 4520; Thu, 17 Feb 94 22:08:42 EST
Received: from LIST.NIH.GOV by LIST.NIH.GOV (Mailer R2.10 ptf000) with BSMTP id 4518; Thu, 17 Feb 94 22:08:34 EST
Date: Thu, 17 Feb 1994 22:08:16 -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: Roger Fajman <RAF@cu.nih.gov>
Subject: Re: Last Call: TN3270 Extensions for LUname and Printer Selection
X-To: TN3270E@LIST.NIH.GOV
To: Multiple recipients of list TN3270E <TN3270E@list.nih.gov>
Message-ID: <9402172210.aa27089@CNRI.Reston.VA.US>

> On Thu, 17 Feb 1994, IESG Secretary wrote:
>
> > The IESG has received a request from the Telnet TN3270 Enhancements
> > Working Group to consider <draft-ietf-tn3270e-luname-print-02.txt>
> > "TN3270 Extensions for LUname and Printer Selection" for the status of
> > Proposed Standard.
> >
> > The IESG plans to make a decision in the next few weeks, and solicits
> > final comments on this action.  Please send any comments to the
> > iesg@cnri.reston.va.us, or ietf@cnri.reston.va.us mailing lists by
> > March 3, 1994.
> >
>
> Hmmm...maybe it's just a misunderstanding on my part, but this announcement
> confuses the heck out of me.  This is a standards-track RFC??  I was
> under the impression it was to be either an experimental or an
> informational RFC.  If we're putting out two standards track RFCs, it
> seems to me that it will be awfully confusing - which one are developers
> supposed to adhere to?  Both??  Take your pick??  They certainly aren't
> interoperable.  What gives?

It confuses me too.  I distinctly remember agreement in Houston that
this would be an informational RFC, since it didn't fit the definition
of an experimental RFC.  We agreed that there would be only one
standards-track RFC:  the one Bill is working on.  I've seen no
agreement on this list to change any of this.  I still feel strongly
that there should not be two standards-track RFCs.

Roger Fajman                                   Telephone:  +1 301 402 4265
National Institutes of Health                  BITNET:     RAF@NIHCU
Bethesda, Maryland, USA                        Internet:   RAF@CU.NIH.GOV