either personally abusive, or misleading field names that say
one thing but mean another (like the titles of bills in the
US Congress), or frivolous proposals.
Personally abusive field names are unlikely to have any interest or
relevance for other implementers, but that is not the case for field
names that some of us may find "frivolous" or misleading. For example,
the fact that the field name misrepresents the use of the field doesn't
mean that a deployed instance of that field is not out there;
If the instance of the field is "out there" (i.e. in wide deployment)
then I agree that it's useful to document it. However I don't think
many implementors would propagate an abusive or frivolous or misleading
field anyway. My reason for the expert being able to exclude
abusive/misleading/frivolous fields is mostly to keep completely useless
garbage out of the registry, and to keep people from having to review it.
IMO, misrepresented fields are even *more*
important to have in a registry so that the rest of us can know what's
going on.
For a field that was widely deployed, I'd agree with you. But again,
I think there are somewhat conflicting goals here - one being to
document things that are already deployed so that implementors will
know about them, and the other being to encourage documentation
and review of new proposals. For the abusive/frivolous/misleading
field, I'm thinking in terms of the "review new proposals" process,
not the "document widely-deployed practice" process, and I think these
are best treated as separate cases.
Except for personally abusive names, I think that opinions of
the field should only be noted in the registry and should not enter into
whether the decision as to whether the field gets registered.
Well, I think the category probably needs to be broader than just
personally abusive names, but I won't try to nail it down precisely.
Personally, I'm willing to trust the designated expert to make such
a determination, with an appeals process to keep the expert honest.
well, I've suggested that registrations could be marked with a
"waiting for review" placeholder before review, so they would
appear in the registry - just as long as we get a prompt review.
I agree that one of the keyword/status values should be "unreviewed", so
that the indeterminate usefulness of the field is emphasized. However I
think the next step for a bad field idea should be either "in revision"
or "don't implement", not deregistration of the field.
I think it's perfectly reasonable to "de-register" a field that is proposed
but doesn't get any significant deployment. Lots of internet-drafts get
written that never amount to anything - because they don't attract enugh
support or people find a better way to do the same thing. I assume that
lots of extension header fields will get proposed that don't amount to
anything either. Why clutter the registry with them?
I just think that putting
a field in a registry without getting prompt review will do
more harm than good.
I agree that prompt review is a good thing. I disagree that a
non-reviewed field is a problem - it should simply be marked as
non-reviewed.
I don't mind "non-reviewed" status as long as the time during which
it can appear is no more than a few weeks. After that the status needs
to change to something more meaningful.
Keith