ietf-822
[Top] [All Lists]

Re: X-* header fields

2004-01-23 07:54:24

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?  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. 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'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.

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?  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)?

Less is usually more as far as standards go.
 

True, but changing horses in mid-stream is usually a bad idea as well,
in standards
as well as in other endeavors.

At one time it was widely
believed that providing a special, reserved space of protocol fields
would discourage pollution of the normal space.   Personally I'm glad
that we encouraged people to use X- because I think that if those fields
didn't use X- there would be a lot more bogus and poorly-defined
fields out there and it would be more difficult to distinguish those
fields from fields that should be implemented than it is now.  Which is
not to say that there aren't bogus non-X- fields out there, just that
X- helps identify _some_ of the bogus fields.
   


First, since there are huge numbers of bogus header fields (I have 587 on my
personal list of such things, about evenly split in their use or non-use of X-)
both with and without X-, I don't buy the argument that X- has helped in any
material way.
 

Well you really have two lists of about equal size, according to the RFC
822 rules;
one is a list of bogus (unregistered) fields and the other is a list of
experimental or
private-use (unregisterable) fields.  And only one of those lists has
names that could
(under RFC 822 rules) potentially conflict with future registered names.

Second, the existance of X- has led to the use of well-defined fields in the X-
space that now cannot be standardized because of the X- rule. The best example
of this I know of is X-Accept-Language but I'm sure there are others.
 

Such well-defined fields, if also widely used, would constitute
successful experiments.
Accept-Language has been standardized (RFC 3282).  If it's useful and
widely used
(I'm not convinced of either) those who were sufficiently motivated to
participate in
the experiment are also sufficiently motivated to use the official
field. If so, supporting
that change is not materially different (for parties who elected to
support the X-
experiment) from registered header fields whose names have changed
(e.g. Obsoletes -> Supersedes).  For others (who have ignored the
experiment) it's
simply another new header field.  And in the specific case of
X-Accept-Language, lest
you look in this message's header and find it there; the transition
gives some time
for broken implementations (such as Mozilla's) to be repaired in the
process.

I've also seen cases of fields where the contents are reasonably well defined
but the field names vary, to the detriment of interoperabilty. For example, it
is often useful for different gateways to the same type of non-Internet mail
system to cooperate in their specification of a fields used to carry
information useful to the non-Internet system they gateway to. (X-VMSMail-To:
is one example of this, there are many others.) Although there tend to be
scoping issues associated with the use of such information, the fact remains
that it would be very useful for vendors of different gateways to the same
system to be able to agree on a single field name. But the use of X- fields for
this sort of stuff (which does seem like an obvious choice) has precluded
specification of such field names in these cases.
 

I don't get your point. If X-Accept-Language has been sufficiently
successful to result
in a standardized version with a registered name, how do the RFC 822
provisions
preclude a similar thing from happening for gateways?  Moreover, there is a
counterexample of sorts; the MIXER RFCs do standardize such things for
gateways
between two specific mail environments.

Most of the X- fields that have been deployed shouldn't have been
deployed in shipping product with or without the X-.
   


Agreed, but this doesn't make the cases where something was improperly
deployed with X- go away.

 

True, but is does prevent them from clashing with registered field
names, past,
present, and future.

Furthermore,
there has never been a prohibition on defining new fields without X-.
   


Which further dilutes the need for X- IMO.

 

There are some important distinctions to be made here. Of course there's
no prohibition against
registering new field names -- indeed that is explicitly part of the
extension process
provided for by RFC 822.  While there is no official means of
enforcement preventing use
of unregistered field names, RFC 822 explicitly cautions that the
implementor who does
so is crawling out onto a limb that may be officially cut off behind
him. And it provides
a guarantee that that will not happen with an X- field.

Perhaps there should have been a prohibition against use of unregistered
non-X- field
names.  But such a prohibition would be meaningless in practice without an
enforcement mechanism.

Sure this is a problem but this isn't the problem getting rid of X- is intended
to solve.
 

Exactly which problem is it intended to solve, and how is it proposed
that it will
do so?  Especially given that X- header fields have been around for more
than two
decades, will not magically disappear from "old" stored messages, and
lacking an
effective enforcement mechanism will never disappear from new messages.

This is why we're trying the provisional registry approach.
 

[...]

The best tack we've been able to come with is what's in the registry
specification. Of course it remains to be seen if it will actually help.
But I agree that the X- issue is small beer in this larger context.
 

Wouldn't it be preferable to retain X- while that approach is tried;
that way if the
provisional registry is a disaster or fails to achieve it's purported
goals, we'll still
have an established fallback.  If X- is somehow abolished and the
provisional registry
fails, then what?


<Prev in Thread] Current Thread [Next in Thread>