It certainly is an indication that the field is not standardized,
that it doesn't have a specification that has received community
review and consensus before use.
It certainly indicates that there is no spec, but it doesn't at all
mean that the field is not a de-facto standard.
actually, it doesn't indicate that there is no spec (I've seen a
spec for X-Face) but it is a good first-order indication that the
field is not a de facto standard.
In fact, it may have
received a sufficient level of community review (e.g., X-Mailer and
X-Face didn't need a whole lot of discussion pre-deployment).
and it's always possible that the designer got the field "right"
the first time without any external review. but it's a rare occurance.
And for that reason it really is a fairly good first-order
indication about whether it's a good idea to implement the field.
But of course, that isn't how it's viewed. What implementors instead
take it to mean is "You'll never find documentation on this field, so
if it looks useful to you, either examine the field itself or look at
the source code of some MUA that uses it and then wing it." And that
is a much more likely recipe for bad things to happen.
I don't know how much we can control how X- fields are 'viewed' by
people who don't read the RFCs to see what X- was intended to mean.
The most we could do is write new RFCs that alter or clarify the
meaning of X-. But if people didn't read the old RFCs, will they
read the new one?
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 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.
-----------------------------------------------------------------------
Summary of my position on X- fields:
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.
(yes, there are a couple of exceptions, but they're rare)
2. it is perfectly reasonable to document X- Fields that are deployed,
because it's almost always useful to document existing practice.
3. it is unlikely that an X- field is worthy of standardization as-is.
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.
Keith