ietf-822
[Top] [All Lists]

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