On Sun, Jan 18, 2004 at 08:49:42AM -0800, ned+ietf-822(_at_)mrochek(_dot_)com
wrote:
Bruce Lilly wrote:
X- is used as an indicator for experimental or private-use tags in
many places
in Internet message protocols other than field names. For example:
[...]
[...]
The bottom line is that the success of x- fields in other places has
anywhere
from disasterous at worst to mixed at best. And to a large extent the lack
of
harm in many spaces has come from lack of use. So if you're looking for
support
for keeping the X- distinction from the successful use of X- in other
contexts,
I'm afraid it is not forthcoming.
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.
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.
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.
If some header-based feature or interoperation should work on a large
scale, not just in the environment I control, then I will need to define
and describe a non-X- header for it.
Which doesn't happen in practice.
The X- prefix only gives me
assurance that my experimental or internal stuff is not clashing with
any currently defined, widely used header, now or in the future. The X-
header will not even guarantee that it will work through externally
controlled gateways, even though most of the time it will.
No such guarantee is present in practice, since any number of
X- fields are now in wide use.
Anybody who uses X- headers or tags and expects large scale
interoperation is simply naive. I can easily make a rule that in my huge
private garden cars are to drive backwards. If I want them to do the
same on public roads, well, good luck.
On the contrary, the person who is being naive here is you. 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.
I like the comparison between X- and 192.168.0.x. I can create a huge
internal network with 192.168.0.x IP addresses, I can even tunnel the
network over the public internet. This can all work perfectly well. But
I can not expect it to work outside of my private network, neither is it
accessible from the internet as is, nor is it guaranteed that it can
work with another private network using the same address range.
First, its not a valid comparison since such addresses are unroutable and hence
are unusable on a wide scale. No such restrictions apply to X- fields; message
transfer agents do not drop them.
Second, the fact of the matter is that private use addresses of this sort
routinely leak outside of local networks and cause all sorts of problems when
they do. In particular, the number of UDP packets that arrrive at various
destinctions on the Internet with these sorts of IP addresses in the sender
field is enormous, as is the amount of bandwidth that they waste.
Ned