Re: X-* header fields (Was: Getting 2822 to Draft)
Bruce Lilly <blilly@verizon.net> Sun, 04 January 2004 07:55 UTC
Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i047tZib006337 for <ietf-822-bks@above.proper.com>; Sat, 3 Jan 2004 23:55:35 -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 i047tZ2N006336 for ietf-822-bks; Sat, 3 Jan 2004 23:55:35 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-822@mail.imc.org using -f
Received: from ns1.townisp.com (ns1.townisp.com [216.195.0.133]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i047tYib006327 for <ietf-822@imc.org>; Sat, 3 Jan 2004 23:55:35 -0800 (PST) (envelope-from blilly@verizon.net)
Received: by ns1.townisp.com (Postfix, from userid 102) id 988A38806; Sun, 4 Jan 2004 02:55:34 -0500 (EST)
Received: from verizon.net (dhcp-0-8-a1-c-fa-f7.cpe.townisp.com [216.195.29.143]) by ns1.townisp.com (Postfix) with ESMTP id 251748805; Sun, 4 Jan 2004 02:55:33 -0500 (EST)
Message-ID: <3FF7C6B5.40108@verizon.net>
Date: Sun, 04 Jan 2004 02:54:29 -0500
From: Bruce Lilly <blilly@verizon.net>
Reply-To: ietf-822@imc.org
Organization: Bruce Lilly
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6b) Gecko/20031208
X-Accept-Language: en-us
MIME-Version: 1.0
To: Pete Resnick <presnick@qualcomm.com>
Cc: ietf-822@imc.org
Subject: Re: X-* header fields (Was: Getting 2822 to Draft)
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]>
In-Reply-To: <p06100736bc1ca63e47d7@[10.0.2.4]>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Spam-Status: No, hits=-1.1 required=8.0 tests=EMAIL_ATTRIBUTION, IN_REP_TO, ITS_LEGAL, QUOTED_EMAIL_TEXT, REFERENCES, REPLY_WITH_QUOTES, USER_AGENT_MOZILLA_UA, X_ACCEPT_LANG version=2.55
X-Spam-Level:
X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp)
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>
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. 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). > Now, let me use this opportunity to explain *why* I don't think X-* > fields should be in the standard in the first place: > > The idea behind X-* fields (what 822 called user-defined fields) was > so that folks could use new field names without worrying that they > would interfere with the standard fields. That way, you didn't have to > go through the trouble of publishing an RFC just to use a field that > was only going to be internal to your particular system. The downside > was that someone else could come along and potentially use the same > field name in a completely incompatible way, but that was the risk > that you took. > > But since then, two things have made it clear that such user-defined > fields are unnecessary and problematic: > > 1. Unnecessary: We now have IANA registration services. We could very > simply create an IANA registry of e-mail field names. Then, if you > wanted to create a new field, you just fill out the registration form > and you're not only guaranteed that you won't interfere with published > standard fields, you're also guaranteed that nobody else would use the > field you chose in an incompatible way. And you wouldn't have to have > a name that started with "X-". Yes, but we don't yet have such a field name registry (and obviously we didn't have one in 2001 when 2822 was published). 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. That differs from publication via RFC regarding review and comment; and I'm not convinced that foregoing such review and comment would be a good thing. > 2. Problematic: Some folks thought it was nice to have "X-*" fields > for completely private use. But history teaches us that inevitably > "X-*" fields *will* leak out onto the rest of the Internet. As several > people in this thread have pointed out, we now have some "X-*" fields > that are in widespread use. Sometimes, people use them very > interoperably and they have served a fabulous purpose. Sometimes, they > don't get used interoperably. It would be great if we could publish > some standards to make sure that they do get used interoperably. But > guess what: We can't! It is forbidden by RFC 822 to publish any > standard for a field name that beings with "X-". No matter how > widespread the use, no matter how useful the field is, it can not be > standardized *by definition*. That decreases interoperability on the > Internet. 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. > Now, personally, I would love the document to say, "There is no good > reason to use fields that begin with 'X-' as defined by RFC 822; any > name that does not interfere with a currently registered or published > field name is fine, and using an 'X-' field is discouraged because > they can't ever be standardized." But there was widespread > non-consensus in the DRUMS Working Group when this was discussed. 2822 > does say "Extension header fields no longer specifically called out." > In 2822bis, I think it would be fine to clarify that and say > "User-defined header fields (those starting with 'X-') no longer > specifically discussed", and even have an informational reference to a > document (or 2) on why it was pulled. But I see absolutely no reason > that this should stop 2822bis from moving to full Standard and > obsoleting 822. 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. 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. I don't see the X- issue as any reason to keep 2822 from progressing; from a practical point of view (as noted by others), parsers will need to be able to handle the X- fields already in use, reading "old" messages still requires parsers to be able to handle RFC 822 syntax -- and that will continue to be the case even after 822 is eventually obsoleted regardless of what 2822 et succ. have to say about the matter, just as it is now necessary to support at least some RFC 733 and 724 constructs to be able to read really "old" messages even though those RFCs have been formally obsolete for decades.
- 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