ietf-822
[Top] [All Lists]

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

2002-02-11 10:39:34

-----Original Message-----
From: Keith Moore [mailto:moore(_at_)cs(_dot_)utk(_dot_)edu] 
Sent: Monday, February 11, 2002 6:16 AM

But I don't think a registry is likely to decrease the use
of bad fields unless review happens before registration
(else, how do we determine that they are bad?).

I disagree.  If we throw up barriers to registration of a field, people
will simply go off and deploy the field on their own (as is evidenced by
looking at the headers in virtually any message).  If someone else sees
the field, thinks it's useful, and wants to interoperate with that UA,
they'll then try and implement it themselves, perhaps botching the
reverse-engineering of an already ill-advised field.  Nobody has input,
nobody has responsibility, nobody has a spec - what we have is a mess.

On the other hand, if we allow light-weight registration (requiring a
minimal spec and a discussion forum), we might find out early on when
someone is intending to deploy a new field.  We now have input (on the
discussion forum), responsibility (the person who submitted the
registration), and a (perhaps minimal) spec.  The community's power of
persuasion can now be brought to bear, working with the submitter to
either modify or scrap the field.  If the community consensus is that
the field is a bad idea and the submitter cannot be persuaded to either
modify or remove the registration, the headers is marked in the registry
as "discouraged".  In that case, there is at least an explanation of the
field for anyone encountering it and and explanation of why the
community discourages its deployment.

Think of the registry as similar to the "honey-pots" used to detect
hackers - it gives you a heads-up, and the opportunity to deal with the
issue before you're blind-sided.

-- jeff