ietf-822
[Top] [All Lists]

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

2002-02-03 22:24:38

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