Re: Fwd: I-D ACTION:draft-klyne-msghdr-registry-02.txt
2002-02-01 12:08:12
On 1/31/02 at 6:46 PM -0500, Keith Moore wrote:
actually, it doesn't indicate that there is no spec (I've seen a
spec for X-Face)
Where might I find this spec? Certainly not in any registry at IANA
that I know about.
but it is a good first-order indication that the field is not a de
facto standard.
Later on, you write:
2. it is perfectly reasonable to document X- Fields that are
deployed, because it's almost always useful to document existing
practice.
We're talking about protocol here. A "first-order indication" is the
equivalent of an educated guess. It should not take any guessing:
Let's say that down the road an X- field gets used for something
that, at the time, seems very unimportant. In the future, it turns
out that the field is vitally important to interoperation because
bunches of people start using it. Now, the current state of affairs
is that it *cannot* be a standard, by definition. We could, of
course, document it in an Informational RFC. However, an implementor
who comes along and sees this important X- field, having the
"first-order indication" takes an educated guess that this *isn't* a
de facto standard, tries to wing it in his implementation, gets it
wrong, and screws it up royally. (This does occasionally happen with
things that are standards too, but you're pretty much encouraging it
in this case.)
Wouldn't it have been better for all involved to not make any
assumptions about the relative worth of a header field just by
looking at its name, but rather to have a registry which every
implementor can simply look at, check the references for the field,
see what it's syntax and semantics are supposed to be, look at its
relative worth ("most important field since To:" vs. "stupidest idea
anyone ever came up with"), and have a good chance of doing the right
thing?
I think there is too much tendency on the part of many implementors
to try to implement any field that 'looks useful'. We used to call
this creeping featurism, but I've also heard it called 'header
disease'.
If we had a registry, an implementor could quickly and easily look up
a field and see if it really is useful.
If there's a need for a Priority header field perhaps we should
define one (or use the RFC 1327/X.400 one as it seems to be
reasonable) rather than trying to promote an existing field that
seems to have been used differently by different MUAs.
1. If we had a registry at the time, we would have noticed that there
was already an "Importance" field in 1327 and used that. In fact, now
most MUAs send both (because older versions still depend on
X-Priority).
2. Most MUAs get X-Priority correct. If we had the ability to
standardize it, less folks would have screwed it up. If there wasn't
this idea that X- fields were a good thing, we wouldn't have used
X-Priority in the first place and it likely would have been
standardized.
1. we're better off having a visual convention that indicates that a
field wasn't reviewed and/or standardized before use, than not
having such a convention - because this separates the experimental
and private-use fields from standard fields, and in practice the
presence of X- tends to mean that the field isn't well thought-out.
A registry alone would serve the same purpose without causing
implementors to try to guess using the "first-order indications".
however, there's nothing wrong with standardizing a new field and
having that standard recommend UA behavior regarding generating the
X- field that preceeded it.
Maybe we don't belong to the same standards organization:
- In the IETF, deployment traditionally *precedes* standardization.
First we see if something works in the world, then we write down what
does work. Only in more drastic cases (like IPv6) do we reverse that
process. That's what separates us from the ISO and the like.
- In the IETF, we have repeatedly learned that once something is
widely deployed, you are forced to retain backward compatibility in
order to retain interoperability. Standardizing a new field that
obsoletes an X- field fails that test miserably.
In any event, in this discussion, we've had 5 people talking in
addition to one of the 3 authors. I'd like to hear from anyone else
who supports Keith's view here, because if there's noone else, it's
starting to seem like we have rough consensus.
pr
--
Pete Resnick <mailto:presnick(_at_)qualcomm(_dot_)com>
QUALCOMM Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102
|
|