ietf-822
[Top] [All Lists]

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

2002-02-03 19:42:44

Would it not be better to register everything, but to tag each
entry with its degree of support.

no, I don't think so.   I think we should tag each entry with its
degree of support, but that doesn't mean we should register
everything.

What is the harm in registering everything so long as it is labeled
as "Came from God's mouth" or "Stupidest idea since square wheels; do
not implement" or "No current consensus on what the heck this thing
is"? 

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

- because the person was registering the name in an attempt to 
  prevent someone else from using it, 
- because the field name was misleading, performing a different
  function than it claimed,
- because the proposer wanted a header name registered for 
  no other purpose than to say he had one (vanity names),
- because the proposer was using the process for the sole purpose 
  of wasting people's time,

It might sound silly that people would do such things, but I've 
seen all of these things done or attempted with other registries.


There's a second class of things that are bad technically -
for instance

- things that belong in the envelope rather than the header,
- things that would cause security or privacy violations,
- things that would impair the functionality of the mail system,
- things that would cause mail loops or sorcerer's apprentice
  syndrome

In those cases it might be better to document what's bad about 
the idea than to just refuse to register it.   A lot depends
on the nature of the review process and the way that the 
information is presented to those who look for it.  But I would 
still not want for such registrations to automatically 
preempt other uses of the same field name.

I've seen repeated historical harm in not doing so (i.e.,
headers which are widely used for which no one has the token). Is
there any evidence of harm in the future?

When we first set up the charset registry, someone registered a huge
number of charsets without any review.  Some of those definitions were 
wrong, and I seem to recall it being argued that having that many 
charsets registered was confusing - people didn't know which ones to use,
and it degraded interoperabliity.  So now we have a review process
in place for charset definitions.


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.  A few extra fields (or TLDs) that nobody
uses might not cause much problem, but if there is too much variation
in UA behavior (or the behavior of pseudo-root servers) then mail 
(or DNS) doesn't work well anymore.  I think it would be beneficial 
for everyone if there were more uniformity in behavior of mail 
processing software.  Since more options means less uniformity, I want 
to discourage the header-field-of-the-month club.

I do recognize that some of the existing fields are useful, that
UA vendors compete on features, and that customers demand 
features (sometimes whether they make sense or not).  But I think
we'll get both better functionality and a more manageable mail
system if we define new features by getting consensus on them than 
if we define new features by letting one vendor register a feature
and having everyone else implement it (with or without documentation).  
That's essentially how HTTP got to be such a mess.

Keith