Re: X-* header fields (Was: Getting 2822 to Draft)
Pete Resnick <presnick@qualcomm.com> Sun, 04 January 2004 18:12 UTC
Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i04ICGib066131 for <ietf-822-bks@above.proper.com>; Sun, 4 Jan 2004 10:12:17 -0800 (PST) (envelope-from owner-ietf-822@mail.imc.org)
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id i04ICFBK066110 for ietf-822-bks; Sun, 4 Jan 2004 10:12:15 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-822@mail.imc.org using -f
Received: from episteme-software.com (216-43-25-66.ip.mcleodusa.net [216.43.25.66]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i04ICCib066077 for <ietf-822@imc.org>; Sun, 4 Jan 2004 10:12:13 -0800 (PST) (envelope-from presnick@qualcomm.com)
Received: from [216.43.25.67] (216.43.25.67) by episteme-software.com with ESMTP (Eudora Internet Mail Server X 3.2.3b3) for <ietf-822@imc.org>; Sun, 4 Jan 2004 12:12:09 -0600
Mime-Version: 1.0
X-Sender: resnick@resnick1.qualcomm.com
Message-Id: <p06100706bc1df9aad4f6@[216.43.25.67]>
In-Reply-To: <3FF7C6B5.40108@verizon.net>
References: <p06100723bc1aa0f50ab0@[10.0.2.4]> <iluvfnufs0c.fsf@latte.josefsson.org> <48D74098-3D35-11D8-93B4-000393DB5366@cs.utk.edu> <iluk74afinu.fsf@latte.josefsson.org> <20040102111448.028fa46f.moore@cs.utk.edu> <p0610072cbc1b85cbacba@[10.0.2.4]> <00ef01c3d212$ac907b20$6401a8c0@akc.com> <p06100736bc1ca63e47d7@[10.0.2.4]> <3FF7C6B5.40108@verizon.net>
X-Mailer: Eudora [Macintosh version 6.1a7]
Date: Sun, 04 Jan 2004 12:12:07 -0600
To: ietf-822@imc.org
From: Pete Resnick <presnick@qualcomm.com>
Subject: Re: X-* header fields (Was: Getting 2822 to Draft)
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Sender: owner-ietf-822@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-822/mail-archive/>
List-ID: <ietf-822.imc.org>
List-Unsubscribe: <mailto:ietf-822-request@imc.org?body=unsubscribe>
On 1/4/04 at 2:54 AM -0500, Bruce Lilly wrote: >Pete Resnick wrote: > >>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. But *why* would an implementation care about the publication guidelines for the field? That's the *only* thing "X-" tells you. >"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). Again, what use is there in making that distinction? Do you think the fact that "X-Priority" and "X-Face" start with "X-" means that you shouldn't support them in your implementation or they don't have well-defined syntax? What about "X-Sender"? Is "List-ID" a non-defined field if your implementation doesn't recognize it? What useful purpose is there in differentiating fields which start with "X-"? >In order to be at all useful to implementors, registration would >have to be contingent upon the existence of a stable, formal, public >definition of the proposed field's syntax (with ABNF) and semantics. Nonsense. It is useful to an implementation (especially an implementation that generates fields) to know that a field exists for a particular purpose even if its syntax and semantics have not undergone extensive review and comment or are still under development. It is by implementation that fields get stable and then they can be documented as standards. >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. First of all, the "Status" field of DSN is not defined to appear in a top-level header of a [2]822 message, so there is no "incompatibility" between the two. But let's talk about the leakage: Yes, the "Status" field leaks. Now, what can be done about that? Well, it could be documented in an RFC so that everyone could know what it means. And if turned out useful, it could be a standardized top-level header field. But what if mailx's author had instead used "X-Status"? In that case, it's DOA, because by definition it could not be documented in a standard way. So there is no way for an implementor to figure out what "X-Status" means other than by word of mouth. That invites incompatibility. So what exactly would that "X-" have gained you? >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 No it doesn't. Some "X-" field names are now just as formal as some non-"X-" field names. And I can come up with a list of non-"X-" field names for which it would be *much* safer to have two incompatible implemenations than some "X-" field names. The only thing the "X-" guarantees you is long, ongoing conflicts. Using a non-"X-" field name means that you can document one use as *the* standard way to do something. >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. But what about generators? Because there will be parsers out there that will only interpret the "X-" form of the field, the generators must continue to send the "X-" form. Furthermore, updating some parsers is non-trivial. pr -- Pete Resnick <http://www.qualcomm.com/~presnick/> QUALCOMM Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102
- Re: X-* header fields Lyndon Nerenberg
- Re: X-* header fields Lyndon Nerenberg
- Re: X-* header fields ned+ietf-822
- Re: X-* header fields ned+ietf-822
- Re: X-* header fields ned+ietf-822
- Re: X-* header fields Charles Lindsey
- Re: X-* header fields Bruce Lilly
- Re: X-* header fields Paul Smith
- Re: X-* header fields Bruce Lilly
- Re: X-* header fields Bruce Lilly
- Re: X-* header fields Paul Smith
- Re: X-* header fields Paul Smith
- Re: X-* header fields Paul Smith
- Re: X-* header fields Keith Moore
- Re: X-* header fields ned+ietf-822
- Re: X-* header fields Keith Moore
- Re: X-* header fields Al Costanzo
- Re: X-* header fields ned+ietf-822
- Re: X-* header fields Dave Crocker
- Re: X-* header fields ned+ietf-822
- Re: X-* header fields Keith Moore
- Re: X-* header fields ned+ietf-822
- Re: X-* header fields pbdlists
- Re: X-* header fields ned+ietf-822
- Re: X-* header fields Bruce Lilly
- Re: Getting 2822 to Draft Arnt Gulbrandsen
- Re: Getting 2822 to Draft Charles Lindsey
- Re: Getting 2822 to Draft Pete Resnick
- Re: X-* header fields Russ Allbery
- Re: X-* header fields ned+ietf-822
- Re: X-* header fields Charles Lindsey
- Re: X-* header fields Keith Moore
- Re: X-* header fields Russ Allbery
- Re: Getting 2822 to Draft John C Klensin
- Re: Getting 2822 to Draft Bruce Lilly
- Re: X-* header fields Keith Moore
- Re: X-* header fields (Was: Getting 2822 to Draft) Arnt Gulbrandsen
- Re: X-* header fields (Was: Getting 2822 to Draft) Paul Smith
- Re: X-* header fields Kai Henningsen
- Re: X-* header fields Bruce Lilly
- Re: X-* header fields (Was: Getting 2822 to Draft) Bruce Lilly
- Re: X-* header fields Bruce Lilly
- Re: X-* header fields (Was: Getting 2822 to Draft) Keith Moore
- Re: X-* header fields (Was: Getting 2822 to Draft) ned+ietf-822
- Re: X-* header fields (Was: Getting 2822 to Draft) Charles Lindsey
- Re: Getting 2822 to Draft Charles Lindsey
- Re: X-* header fields (Was: Getting 2822 to Draft) Keith Moore
- Re: X-* header fields (Was: Getting 2822 to Draft) Adam M. Costello
- Re: X-* header fields Kai Henningsen
- Re: X-* header fields (Was: Getting 2822 to Draft) Pete Resnick
- Re: X-* header fields (Was: Getting 2822 to Draft) Bruce Lilly
- Re: Getting 2822 to Draft Bruce Lilly
- Re: X-* header fields (Was: Getting 2822 to Draft) ned+ietf-822
- Re: X-* header fields (Was: Getting 2822 to Draft) Arnt Gulbrandsen
- X-* header fields (Was: Getting 2822 to Draft) Pete Resnick
- Re: Re: Getting 2822 to Draft Dave Crocker
- Re: Getting 2822 to Draft Pete Resnick
- Re: Getting 2822 to Draft Keith Moore
- Re: Getting 2822 to Draft Al Costanzo
- Re: Getting 2822 to Draft Kurt Keller
- Re: Getting 2822 to Draft Keith Moore
- Re: Getting 2822 to Draft Pete Resnick
- Re: Getting 2822 to Draft Keith Moore
- Re: Getting 2822 to Draft Pete Resnick
- Re: Getting 2822 to Draft Pete Resnick
- Re: Getting 2822 to Draft Keith Moore
- Re: Getting 2822 to Draft WJCarpenter
- Re: Getting 2822 to Draft Arnt Gulbrandsen
- Re: Getting 2822 to Draft Keith Moore
- Re: Getting 2822 to Draft Simon Josefsson
- Re: Getting 2822 to Draft Al Costanzo
- Re: Getting 2822 to Draft Keith Moore
- Re: Getting 2822 to Draft Keith Moore
- Re: Getting 2822 to Draft Simon Josefsson
- Getting 2822 to Draft Pete Resnick
- X- fields (Re: Getting 2822 to Draft) Bruce Lilly