On 2/3/02 at 9:42 PM -0500, Keith Moore wrote:
If we can come up with a review process to assign such a rating, I'd
be willing to have the registry accept almost everything. But I
still think there would be a need for the review process to be able
to refuse a registration - for instance...
[Abuses listed]
OK, maybe we can close in on an answer here. The current document states:
The IESG MAY appoint a domain expert to control registration if it is
judged that the facility is being abused.
Now, personally I think that most of the abuses you cite won't
actually happen and that there is certainly utility in having easy
registration. However, I certainly accept that such abuses
theoretically possible. Would it be enough if the expert was able to
unregister such fields if they were deemed of this sort? I take it
that having a stupid registration of this sort in the registry for
24-48 hours has limited potential for widespread damage.
I think the expert (if that is the method chosen) should have to
explicitly approve entries. If there were a 24-48 hour deadline,
it would be too easy to miss it. I also think that the document
needs to make clear that the expert has the power to refuse entries
that are considered abusive.
(For the record, I really couldn't care less about the "vanity"
folks. If people want a "vanity" field name, we can deal with that in
the "technically bad" category below.)
I don't care much about this either - unless people flood the
registry with vanity field names.
There's a second class of things that are bad technically -
[...]
In those cases it might be better to document what's bad about the
idea than to just refuse to register it.
Right. In this case, however, I think what we do is shift the "burden
of proof": If you want to register a header field in the
"non-standard" registry, that's all well and good, but the IETF may,
by some consensus process, put a note on your registration that says,
"This is boneheaded; don't use". What we want to do is get the bar
lowered enough so that some benign and widely deployed header field
can be registered and documented without having to wait for consensus
on "the best way to do this".
no, I don't think these things should go in the registry until
there's some consensus on whether it's a good idea.
Just to be clear - I accept that it's useful to have deployed header
fields documented, and that it's useful to have a place where one can
go to find out the syntax and semantics and standardization level and
applicability of a header field. But I don't think it's at all
desirable for new folks to be implementing header fields just because
other folks are implementing them, without a shared understanding of
whether it's a good idea.
The idea that we should make it easier for some (supposedly) "benign
and widely deployed header field" to be even more widely implemented
"without having to wait for consensus" on how to do this strikes
me as essentially a means to bypass the consensus process.
And it's the same process that made such a mess out of HTTP.
But I would still not want for such registrations to automatically
preempt other uses of the same field name.
I don't see any big problem if field names get taken; there are
plenty of words (and combinations thereof) that can be used for a
field name and I find it hard to imagine us running out of ways to
express a particular concept in a field name. However, if there
really is such a problem, would the above unregistration mechanism
solve this?
maybe. But I don't like the idea that the nonstandard field should
get the "obvious" name and the standard field has to get a name
that seems less obvious and more strained. You and I both know
that too many implementors don't read the specifications enough
even when the protocol is standardized and well-documented.
It's too easy for a naive implementor to think that the obvious name
is the one that should be implemented. That doesn't improve
the reliability of Internet mail, and it doesn't make other implementors
work any easier.
Also, I view the idea that anybody can define whatever header fields
they wish, as similar to the idea that anybody can define whatever
top-level domains he wishes.
I don't find the comparison at all apt, and actually I think you are
being hyperbolic. Operationally and socially, large numbers of TLDs
would have a serious effect on the behaviors of lots of people. I
don't see an equivalence in header fields.
I don't think that header fields are as "attractive" a target for
abuse as TLDs. However I do think that making it too easy for people
to define their own header fields also threatens to introduce a
kind of semantic drift. Controlled vocabularies don't work well
without controls.
In any case, what I really want to know is:
- Is it enough to have the IESG set up a policeman only if it turns
out that there are abuses?
- Is it OK that new registrations are "innocent until proven guilty"?
My personal take is "yes" on both.
my personal take is "no" on both.
Keith