...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.
I'm not ignoring it. I'm categorically stating that:
- I think it will do harm to the interoperability of Internet
mail, by making it too easy to legitimize bad ideas and effectively
bypassing the standards process,
- I think it optimizes for the extremely rare case of a header field
that really is worthy of widely deployment despite not having been
reviewed by the community and revised on the basis of that review
before deployment
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.?
Because observing a header field in use and documenting the specification
for a header field along with its applicability are fundamentally
different things, and I think it's too confusing to try to combine them.
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.
No, correct syntax alone isn't sufficient. The proposal must at least
appear to be sound and not harmful, and failure to address
security/privacy considerations is a frequent source of harm.
(cookies in HTTP, various frobs to request an automatic response in email)
I can see not requiring security/privacy considerations as part of
the form - let other people fill that in. But those things need to
be considered before the field is registered.
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.
Fine. Give the submitter of the proposal two options in response
to an unfavorable review by the expert:
1. withdraw the proposal
2. list the field in the registry, along with the review
But also make it explicit in the registry that implementation of a proposal
that gets an unfavorable review is not recommended - or if the field is
believed to cause harm, the registry can contain an indication that the
field should be ignored or even deleted by message handling software.
And still give the expert reviewer the right to categorically reject
applications for fields that are misleading, vanity fields, etc.
Give the submitter the right of appeal to IESG, IAB, etc. if necessary.
The main point is, that things don't go into the registry at all without
some documentation and without being accompanied by some community review.
Keith