ietf-822
[Top] [All Lists]

Re: Fwd: I-D ACTION:draft-klyne-msghdr-registry-02.txt

2002-02-08 10:39:31

On 2/8/02 at 9:46 AM -0500, Keith Moore wrote:

...if the approval process is too onerous then more people will try to bypass the approval process than otherwise. ...if the approval process is too easy then the bad mechanisms *get approved*, and there's less to discourage other vendors from implementing them.
[My emphasis added above]

There's a third choice which you continue to ignore: There is *NO* approval process. Bad mechanisms don't "get approved". They get *registered*.

Now, we may wish to add a process after registration that calls for approval (or disapproval), and the results of that process can attach to any registration. And I don't care how onerous that approval process is. Heck, make it require a standards track RFC for all I care. What I want is for approval to be a completely separate act from registration.

I also think we should be able to document header fields that are observed "in the wild" absent approval - but they should be listed separately, or in such a way that it's very clear that no approval was obtained.

Why separately? Why not just have one list with a marking on each entry which says "Approved", "Not approved", "Actively discouraged", etc.?

What I currently have in mind is something like the following:

1. have a template to request registration of a message header, much like the templates for content-types, charsets, or URN NIDs.

Fine. Heck, put it on the IANA web site as a web form.

the template explains the information that is required in order to register a header field - including the field name, the purpose of the field, abnf syntax, security and privacy considerations, the set of protocols for which the field is intended, etc.

Fine, although putting in "No security considerations" is not a bar to registration, though it may be a bar to the approval process. Registration happens after step one is completed in a syntactically correct way.

2. have a single mailing list for public discussion of all proposed message headers

3. submission of the form causes an announcement to be sent to that list, opening discussion of that header field.

Peachy.

4. initial review takes place for a fixed period of time - say 2 or 4 weeks.

5. at the end of the review period a designated expert makes one of a small number of recommendations:

   - field is believed to be non-disruptive and okay for experimental use, or
   - field is insufficiently documented, or
   - revision based on review feedback is required, or
   - IETF consensus is required before this field can be registered

Nonsense. This makes it so that bad mechanisms will not appear in the registry for months. This will cause damage to the net. For an approval mechanism, this is fine; for a registration mechanism, it is wrong.

6. "in the wild" observations are maintained separately, and perhaps, automatically. these are submitted via an emailed web form. submission of the form causes an automatic reply to the email address that submitted the form; the sender must confirm sending the observation before it will be accepted.

Fine, but again, why separately?

7. there also needs to be a process for commenting on existing header fields and their applicability. this might be as simple as writing a BCP about the header field, but the information in that BCP needs to be reflected in the registry.

Peachy.

pr
--
Pete Resnick <mailto:presnick(_at_)qualcomm(_dot_)com>
QUALCOMM Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102

<Prev in Thread] Current Thread [Next in Thread>