Fwd: Re: draft-ietf-tn3270e-luname-print-02.txt

"Robert G. Moskowitz" <0003858921@mcimail.com> Thu, 24 February 1994 00:24 UTC

Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa14671; 23 Feb 94 19:24 EST
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa14667; 23 Feb 94 19:24 EST
Received: from list.nih.gov by CNRI.Reston.VA.US id aa23402; 23 Feb 94 19:24 EST
Received: from LIST.NIH.GOV by LIST.NIH.GOV (IBM VM SMTP V2R2) with BSMTP id 9817; Wed, 23 Feb 94 19:21:44 EST
Received: from LIST.NIH.GOV by LIST.NIH.GOV (Mailer R2.10 ptf000) with BSMTP id 9815; Wed, 23 Feb 94 19:13:30 EST
Date: Wed, 23 Feb 1994 13:09:00 -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: "Robert G. Moskowitz" <0003858921@mcimail.com>
Subject: Fwd: Re: draft-ietf-tn3270e-luname-print-02.txt
X-To: IETF TN3270E Working Group List <TN3270E@list.nih.gov>
To: Multiple recipients of list TN3270E <TN3270E@list.nih.gov>
Message-ID: <9402231924.aa23402@CNRI.Reston.VA.US>

Here is John's response.

Seems to me that we really need a new RFC classification.  'back level' or
some sort.

Lets sort this out in the next couple of days?

Bob

-----------------
Forwarded Message

Date:     Mon Feb 21, 1994  2:23 pm  EST
Source-Date: Mon, 21 Feb 1994 13:39:54 -0500 (EST)
From:     John C Klensin
          EMS: INTERNET / MCI ID: 376-5414
          MBX: klensin@infoods.unu.edu

TO:     * Robert G. Moskowitz / MCI ID: 385-8921
CC:       John C Klensin
          EMS: INTERNET / MCI ID: 376-5414
          MBX: KLENSIN@infoods.unu.edu
CC:       Erik Huizer
          EMS: INTERNET / MCI ID: 376-5414
          MBX: Erik.Huizer@surfnet.nl
Subject:  Re: draft-ietf-tn3270e-luname-print-02.txt
Message-Id: 60940221192306/0003765414NA5EM
Source-Msg-Id: <01H95DVEJ92Q8WW21S@psc.plymouth.edu>


Bob,

I can be talked out of it, but I harbor a prejudice against publishing
protocol documents as "informational".   The problem is that we've had
too many people, too often, and whether accidentally or deliberately,
confuse "RFC" with "standard".    So, at the moment, the categories--as
far as I'm concerned--for things that describe protocol details are:

(1) Informational, used only to describe current practice or some piece
of protocol history that is of value to the community.  This category,
IMO, should never be used for something that is a not-yet-deployed
proposal.

(2) Experimental: Any other protocol spec, especially one that
describes something that isn't in the practice yet, that is judged not
ready for prime time (i.e., Proposed Standard status).

(3) Proposed standard.  (otherwise).

Now, if the WG is saying that this isn't part of the current practice
*and* isn't anything you want in a standard, then it is, IMO, a dead
document unless there is approval to publish it as experimental.   In
that theory of the world, there are only two other courses of action:
to make it into an appendix to the "extensions" doc or to hold it up
until the extensions doc goes into Proposed Standard processing and
then process this as an informational "path not taken" document.

If Erik agrees with this analysis and you, or the WG, don't, I'm happy
to raise it with the full IESG.  But any information you can provide
before I do that on why the WG doesn't think "experimental" would be
appropriate would be helpful.

    john