ietf-822
[Top] [All Lists]

Re: X-* header fields

2004-01-22 11:52:54

I don't quite understand why the X- headers or other similar X-
stuff must be successful.

Think for a moment about what you're saying. You're saying that it
doesn't matter if a particular feature of a specification has caused
interoperability problems in other contexts and is known to have
caused severe interoperability problems in the present context.

Misuse of any protocol feature can cause interoperability problems.
That is at least as true for X- fields (which IMHO should never have
been put in shipping products except perhaps as write-only fields) as
for non X- fields (which should never be in shipping products without
public vetting).

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.

Another, similar, case is the X-uuencode CTE. (And before you say that the
right answer is to use base64 and not uuencode, the choice in many cases isn't
between base64 or uuencode, but between embedding uuencode material in text and
calling it out in the MIME structure. In such cases I'll take the latter every
time.)

The burden for those who want X- fields to be treated just as any other
field is to convincingly argue that there would be greater overall
interoperability by doing that.  Making it easier for people to follow
the rules doesn't help if those rules don't encourage interoperability.

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.

Less is usually more as far as standards go.

I'm sorry, but the entire point of this exercise is to produce
interoperable standards. The question was whether or not X- fields
have succeeded in not causing interoperability issues in other
contexts. And the answer is that in the cases where they have seen
active use they have NOT succeeded in this regard.

A better question is whether treating X- fields differently (in that
they cannot be registered) has improved the overall level of
interoperability over what it would have been to not have them treated
differently.  I don't think we can answer this with a great deal of
confidence, since we don't have a control.

True enough. However, the question that started this thread was how well the
use of X- fields have worked in other contexts. And although it is far from
clear the results elsewhere are relevant, the fact is that such usage has not
turned out well.

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.

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.

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.

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.

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

Which further dilutes the need for X- IMO.

So I have a hard time understanding how writing new RFCs that change the
rules for X- helps interoperability, when the real issue is the failure
to define the fields in a way that allows them to interoperate.   More
generally, when the problem is due to the failure to read existing RFCs,
I fail to see how writing new RFCs is going to help.

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

(Granted, it's easier to get people to follow rules that say "anything
goes", because they don't have to know the rules to follow them.  But
while "anything goes" might result in more widespread compliance, it
doesn't necessarily result in greater interoperability.)

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

Aren't these simply meant for 'private', experimental
and test use? If I want to test out a new idea, if I want _my_
mailing system A and _my_ mailing system B and _my friends_ mailing
system C to do something special, if I want to flag certain messages
for special handling in _my_ environment, then I'll use X- headers.
All this may be highly successful for me, but not for the world at
large.

The problem is that often as not such experiments do not stay
confined, and instead deploy more widely.

But at least they're labelled as experimental.  (or more precisely,
they're labelled as "user-defined" fields that cannot be registered.)

But there's often no truth in that label. This is why having a provisional
registry is a better answer.

Even though I believe X- fields should not be used in shipping products,
labelling an unvetted field with X- seems to be at least slightly more
responsible than not labelling it in that way.

I'm sorry, but this simply isn't a realistic approach for vendors to take.

You're
expecting people to play by the rules when the rules require them to
behave in seriously inconvenient ways. We have ample evidence this is
not how things play out. The trick is to write rules that people will
actually follow.

Indeed.  It seems that there's no getting around these two things:

1. You don't tend to get widespread interoperability without careful
design that takes into account a wide range of input (because conditions
vary widely and no single person or group appreciates the breadth of
conditions).

2. Getting that wide range of input (typically by public review and
vetting) is "seriously inconvenient" - at least, in comparison to
how much effort it takes to type

    printf ("field-name: ...\r\n");

Frankly I don't think we're going to improve interoperability without
somehow encouraging more people to do things that are inherently
"seriously inconvenient".  Maybe we can make them more convenient, but
it will never be anywhere nearly as easy as typing printf.

This is precisely the problem the registry proposal is trying to address. It
also tries to address the related problem that it is far better to know what
the intent of a given field usage is, even when that intent is flawed in some
way, than it is to be forced to guess. (Again I will point out that simply
ignoring these things is just not an option for vendors -- if they adopt this
attitude their customers will simply go elsewhere for their messaging
products.)

I really think that the X- debate is a red herring.  The reason we
seem to always be at an impasse on the X- debate is that we're
dancing around the real problem, which really has not much at all
to do with X- .  The problem, I suspect, is something like this:

It certainly is red herring in regards to the topic you're now pursuing.

In the marketplace, vendors distinguish between each other on features,
and some features require protocol extensions.   Standardizing those
protocol extensions before deployment defeats the vendor's purpose for
deploying those extensions, which was to gain some (however limited in
time) edge over a competitor.  So it's not going to happen very often.
But when such features are deployed they may not interoperate well with
other vendors' products because of inadequate design and/or lack of a
well-written published specification, and they may actually degrade
interoperability of the email service in general.

This is probably true in some cases. However, I can also think of many cases
where a vendor would have had no problem with specification of a field prior to
or coincident with deployment, but was thwarted by the daunting process of
publishing an RFC. (There have even been cases where drafts were published but
then languished because the necessary energy for pushing the document through
the process just wasn't there.) Heck, I've done this myself on several
occasions, and if I opted for this approach, what does this say about someone
who knows nothing about IETF processes?

So the question for those who want to promote interoperability is:

How do we encourage experimentation with, and deployment of, new
features in email without degrading interoperability?

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.

                                Ned


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