ned+ietf-822(_at_)mrochek(_dot_)com wrote:
But it is far from clear that the cases where X- field use is causing interop
problems actually constitute "misuse". For example, there have been cases
where
two parties opted to use the same X- mail header field for their own private,
but sematically different, purposes. (X-Sender is the example that comes to
mind.) The specification of X- in RFC 822 doesn't give you much leverage to
argue that either of them were "misusing" the field.
Would the situation have been any better if some other name (i.e. not
beginning with X-) had been used w/o registration?
Quite possibly. The problem with X- is that it is easy and encourages
unilateral action. Had there been (a) No X- and (b) A simple registration
scheme it is entirely possible that the first user of such a field would have
registered it and subsequent users would have picked up the registration.
And there is precedent for this. When media types were first defined
registration, although possible, was too onerous. This led to a lot of ad-hoc
use. Subsequent revisions to the process have given us a significant rise in
the registration rate. But to the extent X- types were or are still used, they
now constitue a problem rather than a solution.
If there is a conflict in use of an X-
field, the responsible parties can a) work out the issue and come to common
usage or agree to change one or more of the names, or b) the conflict can
continue.
This assumes that the responsible parties are willing able to get together and
work
such things out after the fact. This almost never happens in my
experience.
With other field names and with current procedures, there is
another option, viz. one of the parties can issue an RFC registering the name.
There have been attempts to do this in the past. The degree of pushback
experienced killed almost all of them.
There's no
guarantee that the IETF will be aware of the other use, and it may well
be the
case that a more useful (unregistered) field is ignored. Moreover,
there's no
guarantee that use of the same name will not continue for the unregistered
purpose (and no official means of enforcement). And as has been noted by
others in this discussion, registration without vetting is likely to make
matters
worse, e.g. by polluting the non X- namespace with items of questionable (or
worse) value.
The incredible number of unregistered non-X- fields in wide use discredits this
assertion rather completely, I think. And again, I would much rather know how
something was designed to be used, warts and all, than have to guess.
I see it the other way around. Given that interop problems are known
to exist the burden should instead be on the proponents of X- to
make a case for the continued inclusion of the feature being worth it.
Let's keep things in perspective. Have the interoperability problems
with X- header fields been minor annoyances, or have they caused massive
disruptions?
They have on occasion caused massive disruptions. X-PMrpc is an example of a
field that caused serious operational problems at one point; there are others
as well.
Would things have been any better without X- given the current
realities (e.g. no registration procedure other than publication of an RFC, no
means of enforcement) and given similar circumstances (i.e. use of the same
field name for different purposes)?
This is soon not to be the current reality. A registration proposal is in front
of the IESG now. And it changes things substantially. Without it I see little
point in worrying about X-. But once it is in place I think X- becomes actively
harmful and I don't want to see it reintroduced.
I really didn't intend to be drawn into this whole debate; my only purpose in
posting my initial message was to answer your request for citations of X-
experience in other areas (which we have seen does not exactly constitute a
ringing endorsement of the concept). So I'm cutting this off now and it is
unlikely I will post additional messages on this topic.
Ned