"X-" Considered Harmful
draft-saintandre-xdash-considered-harmful-00

Abstract

Many application protocols use named parameters to represent data (for example, header fields in Internet mail messages and HTTP requests). Historically, protocol designers and implementers have often differentiated between "official" and "unofficial" parameters by prefixing unofficial parameters with the string "X-". This document argues that on balance the "X-" convention has more costs than benefits.

Status of this Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at http://datatracker.ietf.org/drafts/current/.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as “work in progress.”

This Internet-Draft will expire on January 3, 2011.

Copyright Notice

Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

Table of Contents

1.  Argument
2.  Security Considerations
3.  IANA Considerations
4.  Informative References
§  Author's Address

1.  Argument

Many application protocols use named parameters to represent data (for example, header fields in Internet mail messages and HTTP requests). Historically, protocol designers and implementers have often differentiated between "official" and "unofficial" parameters by prefixing unofficial parameters with the string "X-" (often pronounced "ex dash"). This document argues that on balance the "X-" convention has more costs than benefits.

The "X-" prefix has been in use since at least the publication of [RFC1154] (Robinson, D. and R. Ullmann, “Encoding header field for internet messages,” April 1990.) in 1990, which set forth the following rule:

Keywords beginning with "X-" are permanently reserved to implementation-specific use. No standard registered encoding keyword will ever begin with "X-".

This convention continued with various specifications for MIME [RFC2045] (Freed, N. and N. Borenstein, “Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies,” November 1996.) [RFC2046] (Freed, N. and N. Borenstein, “Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types,” November 1996.) [RFC2047] (Moore, K., “MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text,” November 1996.), email [RFC2821] (Klensin, J., “Simple Mail Transfer Protocol,” April 2001.) [RFC5321] (Klensin, J., “Simple Mail Transfer Protocol,” October 2008.), HTTP [RFC2068] (Fielding, R., Gettys, J., Mogul, J., Nielsen, H., and T. Berners-Lee, “Hypertext Transfer Protocol -- HTTP/1.1,” January 1997.) [RFC2616] (Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, “Hypertext Transfer Protocol -- HTTP/1.1,” June 1999.), and other technologies.

The primary objections to discarding the "X-" convention are:

• Implementers are easily confused. However, implementers already are quite flexible about using both prefixed and non-prefixed names based on what works in the field, so the distinction between de facto names (e.g., "X-foo") and de jure names (e.g., "foo") is meaningless to them.
  
  
• Collisions are undesirable. However, names are cheap, so an implementation-specific name of "foo" does not prevent a standards development organization from issuing a similarly creative name such as "bar".

The primary problem with the "X-" convention is that implementation-specific parameters have a tendency to seep into the standardization space, introducing the need for migration from the "X-" name to the standardized name. Migration, in turn, introduces interoperability issues because older implementations will support only the "X-" name and newer implementations might support only the standardized name. To preserve interoperability, newer implementations simply support the "X-" name forever, which means that the unofficial name is a standard de facto (if not de jure). We can see this phenomenon at work in [RFC2068] (Fielding, R., Gettys, J., Mogul, J., Nielsen, H., and T. Berners-Lee, “Hypertext Transfer Protocol -- HTTP/1.1,” January 1997.):

For compatibility with previous implementations of HTTP, applications should consider "x-gzip" and "x-compress" to be equivalent to "gzip" and "compress" respectively.

Therefore, segregating implementation-specific parameters into an "X-" ghetto has few if any benefits and at least one significant interoperability cost. The practice is at best useless and at worst harmful.

2.  Security Considerations

Interoperability and migration issues with security-critical paramaters can result in unnecessary vulnerabilities.

3.  IANA Considerations

This document has no actions for the IANA.

4. Informative References

Author's Address