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
- Fwd: draft-ietf-tn3270e-luname-print-02.txt Robert G. Moskowitz
- Re: Fwd: draft-ietf-tn3270e-luname-print-02.txt Roger Fajman
- Fwd: Re: draft-ietf-tn3270e-luname-print-02.txt Robert G. Moskowitz
- Re: Fwd: Re: draft-ietf-tn3270e-luname-print-02.t… Bill Kelly
- Re: Fwd: Re: draft-ietf-tn3270e-luname-print-02.t… Roger Fajman
- Re: Fwd: Re: draft-ietf-tn3270e-luname-print-02.t… Eddie Renoux
- Re: Fwd: Re: draft-ietf-tn3270e-luname-print-02.t… Roger Fajman