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