On 4/9/00 at 12:39 PM -0800, [EMAIL PROTECTED] wrote:

>[...]the RFC Editor exercises editorial control over the RFC series, 
>but doesn't specify exactly what editorial control means.

Actually, Harald's quote from 2026 does make it pretty clear:

Section 4.2.3:

    The RFC Editor
    is expected to exercise his or her judgment concerning the editorial
    suitability of a document for publication with Experimental or
    Informational status, and may refuse to publish a document which, in
    the expert opinion of the RFC Editor, is unrelated to Internet
    activity or falls below the technical and/or editorial standard for
    RFCs.

>However, the RFC Editor has interpreted its editorial 
>responsibilities as involving review with the distinct possibility 
>of not publishing documents not believed to be worth publishing for 
>at least as long as I've been involved in the IETF.

Absolutely. The question is on what basis that decision is made. 2026 
gives basically two criteria by which the RFC Editor may refuse 
publication:

1. It's unrelated to Internet activity. That's the one Dave and I 
(and others) have been pointing to. Clearly this draft is related to 
Internet activity; it's deployed technology, for better or for worse.

2. It falls below the technical and/or editorial standard for RFCs. 
Now, I think we all agree that the current document *does* fall below 
editorial standards insofar as it plays the "I am a standard" game in 
the text, making itself out to sound like a standard even though it's 
not. The document should be held up until that is fixed. But again, 
that's not Keith's main issue. He's complaining about "technical 
merit" (and sometimes legal or moral merit).

So, here I want to split a hair, but I think it's one worthy of 
splitting: RFC 2026 says "falls below the technical *standard* for 
RFCs". I don't believe what it's referring to here is whether the RFC 
Editor thinks that the document is describing a technically a bad 
idea, but rather whether the technical *quality* of the document 
(e.g., whether it is technically coherent, describes the protocol in 
appropriate detail, doesn't have the classic Gary Larson "...and then 
a miracle occurs..." clause in the middle of equation, etc.) is up to 
snuff. This seems like a good criterion to base publication on, 
whereas the other does not: It is always good to publish what I'm 
likely to have to deal with on the net, whether or not it's a good 
thing that it actually is going on.

It is of course a good thing not to standardize things that are 
technically bad ideas. But standardization is not at issue here. This 
is a question of how the RFC Editor should exercise its editorial 
judgement. 2026 lays out a reasonable guideline. I think Keith's 
request falls outside that (admittedly loose) bound.

pr
-- 
Pete Resnick <mailto:[EMAIL PROTECTED]>
Eudora Engineering - QUALCOMM Incorporated
Ph: (217)337-6377 or (858)651-4478, Fax: (858)651-1102

Reply via email to