actually, it doesn't indicate that there is no spec (I've seen a
spec for X-Face)
Where might I find this spec? Certainly not in any registry at IANA
that I know about.
No, I'm sure it's not there, and it's been probably 15 years since
I've seen it. But I did see something of a specification one time
for the format and how to encode it in a header, included with
some software libraries that could generate faces from other
images and patch exisiting mail programs to display the things.
If you want to find the spec I saw my best guess was that it was
in the faces package in comp.sources.unix - you might find it
in google's usenet archive.
but it is a good first-order indication that the field is not a de
facto standard.
Later on, you write:
2. it is perfectly reasonable to document X- Fields that are
deployed, because it's almost always useful to document existing
practice.
We're talking about protocol here. A "first-order indication" is the
equivalent of an educated guess.
I could quibble about that, but let me take another direction:
Anytime an X- field is widely used, there's inherently a fair amount of
guessing going on. The guy who came up with the field is guessing
that it will work well in a wide variety of environments - most of
which he cannot be experienced with - and that it won't cause harm.
He's also guessing that the same field name isn't used by others.
Other folks who use it are guessing about how the field works and what
it contains, whether there are varying implementations, etc.
I suspect you and I would agree that such guesswork can be dangerous
and detrimental to interoperability. I believe that such guesswork
should be discouraged, and that folks who are generating new header
fields need to get those fields reviewed (and when applicable, their
definitions published) before widely deploying them. Of course if
they do that, then they don't need to use X- fields.
Also, sometimes the designer of the new field specifically intends
the field for private use only - because it's inherently specific
to a particular kind of software or because he/she *knows* it's not
suitable or ready for general use. X- is a useful way to indicate this.
It should not take any guessing:
Let's say that down the road an X- field gets used for something
that, at the time, seems very unimportant. In the future, it turns
out that the field is vitally important to interoperation because
bunches of people start using it.
But those folks are *already* guessing because they're using an X-
field - usually without *any* documentation about what it contains
or how it works. When we've got something that is "important to
interoperation" and undocumented, that's a serious problem, because
there will almost certainly be variation in the way that it's implemented.
Now, the current state of affairs
is that it *cannot* be a standard, by definition. We could, of
course, document it in an Informational RFC. However, an implementor
who comes along and sees this important X- field, having the
"first-order indication" takes an educated guess that this *isn't* a
de facto standard, tries to wing it in his implementation, gets it
wrong, and screws it up royally. (This does occasionally happen with
things that are standards too, but you're pretty much encouraging it
in this case.)
Again, I have no problem with a registry documenting X- fields.
So if the registry existed the implementor could check to see if there
were any documentation on the X- field before trying to "wing it".
In other words, the decision to stop searching for the spec and to
"wing it" wouldn't be based on the presence of "X-", it would be based
on the fact that it wasn't listed in the registry.
But even with the registry documenting the field, the fact that a
field is an X- field should still give the implementor a clue that
the field might have been been widely deployed before it was
documented, that such documentation as is available might not fully
describe variations found in practice, and that the original implementor
might have screwed it up royally, and that perhaps it shouldn't be
propagated at all. Because trying to retroactively document a protocol
is at least as dangerous as trying to "wing" the implementation -
perhaps moreso, since the bugs in the document may propagate more
widely than those in a single protocol implementation.
(I know of at least one attempt to document a protocol in an Informational
RFC that botched the description of that protocol in several ways,
and as a result, has significatly degraded interoperability of that
protocol. (RFC 1179 - LPD))
Now you might argue that the registry could contain bits that say:
"this field was widely deployed without review" or "this field was
widely deployed before it was publicly documented" or "this field
was documented by observing how it worked, not by the guy who
designed it". And those might be good things.
But X- would still be useful, because it's sometimes a good thing
to clearly indicate in the field name "you probably shouldn't be
using this!" And I'd argue that such indication is appropriate
for any field which is deployed without prior review. The guy
who designed the field can't reliably determine by himself whether
his field is going to be good for other people to use, so the
default assumption needs to be that it shouldn't be used by other people.
Wouldn't it have been better for all involved to not make any
assumptions about the relative worth of a header field just by
looking at its name, but rather to have a registry which every
implementor can simply look at, check the references for the field,
see what it's syntax and semantics are supposed to be, look at its
relative worth ("most important field since To:" vs. "stupidest idea
anyone ever came up with"), and have a good chance of doing the right
thing?
Is it any better to make assumptions about the "relative worth" of the
field based on how frequently it appears? As far as I can tell,
X- is indeed a better indicator of "relative worth" than frequency
of appearance. I know of several widely used nonstandard fields that
are either garbage or brain-damaged, but I know of only one or two
X-fields that are even useful for general implementation, and none of
them are of vital importance.
I think it will be difficult for the registry to contain much
information about relative worth. At best we could say one
of three things:
"no consensus" on relative worth
"consensus that it's so bad it should be deleted"
"consensus that it shouldn't be used"
"consensus that it's good"
but there would probably often need to be some caveats even on "good"
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 we had a registry, an implementor could quickly and easily look up
a field and see if it really is useful.
It's not clear - because people will not necessarily agree on the
utility of a field, and getting a clear indication of "usefulness"
would essentially require getting consensus on that - and this
assumes we know how the header is supposed to work. And without
a requirement to reach a consensus on "usefulness", the registry
would provide a means of circumventing the standards process.
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.
1. If we had a registry at the time, we would have noticed that there
was already an "Importance" field in 1327 and used that. In fact, now
most MUAs send both (because older versions still depend on
X-Priority).
2. Most MUAs get X-Priority correct. If we had the ability to
standardize it, less folks would have screwed it up. If there wasn't
this idea that X- fields were a good thing, we wouldn't have used
X-Priority in the first place and it likely would have been
standardized.
I think we're getting too hung up on "X- is good / X- is bad".
We're focusing on what's bad about X- and ignoring the things that
are good about it. I think we can partially fix your problem
with "X-" by allowing those fields to be documented in a registry.
But the only way to fix the real problem - which is that people
deploy protocol extensions without documenting them or getting
review on them - is to get people to document and get review on
protocol extensions *before* they get deployed. I fail to see how
abolishing X- will encourage that.
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.
A registry alone would serve the same purpose without causing
implementors to try to guess using the "first-order indications".
Again, I think it will be very difficult for the registry to provide
a fair indication of quality.
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.
Maybe we don't belong to the same standards organization:
- In the IETF, deployment traditionally *precedes* standardization.
That is a myth. Offhand, I can't think of a single example of a protocol
that was standardized in the same form that it was initially deployed,
and usually for good reasons. There are nearly always serious
problems with the first version of a protocol, because the folks who
designed that version were doing so in a vacuum, and didn't think about
some important aspect of deploying the protocol in the full diversity
of the Internet.
Now a well-designed protocol - especially one designed to be extensible -
might be able to be standardized with very few changes, and/or in a way
such that the standardized protocol interoperates with the pre-standard
version. But this varies a lot from one protocol to another, and it's
hard to predict in advance whether you can do it with any particular
protocol. In general, it's completely unrealistic to design and deploy a
protocol and expect it to be standardized by IETF as-is. That doesn't
stop vendors from trying, but it doesn't work very often.
First we see if something works in the world, then we write down what
does work. Only in more drastic cases (like IPv6) do we reverse that
process. That's what separates us from the ISO and the like.
That's simply not true. Yes, we benefit from prototypes or experience
with an existing protocol whenever we can. And we often use an existing
protocol as a starting point for a standards-track protocol. But the
vast majority of the time we don't standardize the protocol that was
previously deployed - we standardize some variant of it that we think
will work better for the entire Internet than the deployed version.
- In the IETF, we have repeatedly learned that once something is
widely deployed, you are forced to retain backward compatibility in
order to retain interoperability. Standardizing a new field that
obsoletes an X- field fails that test miserably.
The compatibility issues are different for every protocol and every
protocol extension. Sometimes you can get good backward compatibility,
sometiems you can't. But whether the field name begins with an "X-"
or not is pretty much irrelevant to whether you can implement a protocol
extension that is worthy of standardization (meeting the 2026 requirements)
while still retaining compatibility with pre-standard implementations.
In any event, in this discussion, we've had 5 people talking in
addition to one of the 3 authors. I'd like to hear from anyone else
who supports Keith's view here, because if there's noone else, it's
starting to seem like we have rough consensus.
I didn't see any CC's to the list on this message, so I've sent this
reply to you personally. But I can't see how we have rough consensus
when we don't even have a concrete proposal yet, and when it's not
even clear what question is being asked.
And I would far rather we reach consensus by respecting and understanding
each other's concerns than by just trying to isolate me.
If we're just talking about the desirability of a registry, I suspect
we do have rough consensus - I haven't seen anybody say that a
registry is inherently a bad idea or that it shouldn't accept X- fields.
I've expressed some concerns about potential for misuse of the registry,
specifically the need to keep it from being used as a way to "stake a
claim" on a header name or the meaning thereof, or as a way to create
"vanity" header fields. That doesn't preclude having a registry at all,
but it does indicate the need for some care.
As for the desirability of X- fields, we might not have to reach
consensus on this in order to decide what should go into a registry.
Keith