Message-Id: <200002051938.OAA09001@astro.cs.utk.edu>
From: Keith Moore <moore@cs.utk.edu>
To: Pete Resnick <presnick@qualcomm.com>
cc: Sam Roberts <sroberts@uniserve.com>, DRUMS <drums@cs.utk.edu>
Subject: Re: RFC822's Appendix D, and X- fields 
In-reply-to: Your message of "Sat, 05 Feb 2000 11:50:37 CST."
             <a04301402b4c2109c2b2e@[63.250.90.99]> 
Date: Sat, 05 Feb 2000 14:38:36 -0500
Sender: moore@cs.utk.edu

> 3. X- fields cause known interoperability problems. This is simply 
> because X- fields show up, people other than their creator try to 
> parse them, sometimes use them without sticking to the semantics and 
> syntax originally intended (because they by definition cannot be 
> documented), etc. A name starting with X- doesn't do anything to help 
> you experiment with a field if it leaks onto the net at large. Better 
> to choose a field name you like, and once you get it out there, 
> register it.

there are folks who strongly disagree with this idea.

the problem isn't with the X- convention, it is with the idea that
you can create a new field in isolation and not cause interoperability
problems.  this problem exists whether or not you use the X- convention
for your new field name.  the X- convention cannot solve the problem,
but it can serve as a warning to others - don't expect this field 
to be used consistently from one implementation to another.

nor can you solve the problem by registering the field after you've
already deployed it.  

there's a large body of experience that indicates that defining
data models, in a way that allows large-scale interoperation, is 
quite difficult and doing it successfully requires cooperation
of many people with diverse experience.  this is no less true 
just because the data model is one that describes attributes of an 
email message.  

Keith

p.s. I can see the bumper sticker now:

"X- fields do not cause interoperability problems,
people gratuitously adding extensions cause interoperability problems"