blilly(_at_)verizon(_dot_)net (Bruce Lilly) wrote on 04.01.04 in
<3FF7C6B5(_dot_)40108(_at_)verizon(_dot_)net>:
Pete Resnick wrote:
X-* fields are perfectly legal in 2822 (they fall under
"optional-field"); they simply are not given the special treatment of
822, that they won't ever be official published extensions to the
standard. The only difference then between 822 and 2822 in this
respect is that 822 gives publication guidelines for extensions where
2822 does not. This has absolutely *no* effect on implementations of
the protocol.
There is a minor effect. A user-defined field (per 822 definition) can
be recognized as such by examining the
first two octets of the field name, which is quite efficient. While
there exist efficient methods of identifying
fields (e.g. http://www.gnu.org/directory/gperf.html), they are not
quite *as* efficient as a two-octet (case-
insensitive) comparison.
This seems an incredibly silly reason to be for or against the concept.
Moreover, "X-" serves to differentiate
user-defined fields from non-defined
fields (i.e. those field names for which there is no IETF published
definition or which the implementation
does not recognize).
And this looks like a distinction in search of a difference.
It's difficult to see how such problems are either unique to X- or are
more of a hindrance to
interoperability than for other fields. As an example, consider "Status"
which was in "private" use
(I believe) by BSD "mailx" decades ago, and which is currently in use by
several other MUAs,
and which *does* leak out; there is also a formal definition of a
"Status" field -- incompatible
with the private usage -- defined as one of the delivery status
notification fields (RFC 3464).
So neither leakage nor incompatibility seem to be unique to X- fields.
Note that if BSD mailx'
author(s) had used X-Status for private use, there would be no conflict
with the formal DSN
Status field.
I would have thought the proper solution to this were obvious. I've
certainly see it used by various *other* MUAs.
That is, you use fieldnames of "<yourmuaname>-<tag>:" (or similar).
In this case, mailx could easily have used "Mailx-Status:" and been safe
from this particular trap. (ISTR Pegasus calls this "PM-Flags:" or
something like that. XP (the DOS MUA I'm using right now) has various
"XP<something>:" headers.
Note that this actually works *better* than X-headers, in that someone
else with the same idea won't reuse the same field name with a slightly
different semantic.
There is one very good reason to use X- for private or experimental use,
viz. interoperability.
Use of X- as a field name prefix for private or experimental use
guarantees that there will be
no conflict with a formal field name. Use of other names can lead to
conflicts, as in the case
of "Status", the damage in that case fortunately being limited by the
fact that in that case, DSN
fields are significant only in one part of a specific type of MIME
multipart message and the
private use occurs only in the top-level message header.
Note that the above convention does this even better.
An issue not mentioned above is migration of X- fields to a formal
definition following
successful experimental use. That obviously entails a name change.
However name changes
are not uncommon, e.g. refer to the MIXER RFCs, which define a number of
fields whose
names have changed. That merely means that parsers need to recognize
one name as a
synonym for another.
Or in other words, it means that interoperation with the installed base is
broken. Presumably that installed base is nontrivial, or else there would
have been no need to standardize. ("merely"?!)
MfG Kai