TOC 
Network Working GroupP. Saint-Andre
Internet-DraftCisco
Intended status: BCPOctober 19, 2010
Expires: April 22, 2011 


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

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 "standard" and "experimental" parameters by prefixing experimental 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 April 22, 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.  Introduction
2.  Argument
3.  Security Considerations
4.  IANA Considerations
5.  Acknowledgements
6.  Informative References
§  Author's Address




 TOC 

1.  Introduction

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 "standard" and "experimental" parameters by prefixing experimental parameters with the string "X-", where the "X" stands for "eXperimental". This document argues that on balance the "X-" convention has more costs than benefits.



 TOC 

2.  Argument

The "X-" convention has been in use for email header fields since the publication of [RFC822] (Crocker, D., “Standard for the format of ARPA Internet text messages,” August 1982.) in 1982, which distinguished between Extension-fields and user-defined-fields as follows:

The prefatory string "X-" will never be used in the names of Extension-fields. This provides user-defined fields with a protected set of names.

That rule was restated by [RFC1154] (Robinson, D. and R. Ullmann, “Encoding header field for internet messages,” April 1990.) as follows:

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 problem with the "X-" convention is that experimental or implementation-specific parameters have a tendency to become standardized (whether de jure or de facto), thus 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 experimental name becomes a de facto standard (thus obviating the need for segregation of the name spaces in the first place). 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.

One of the original reasons for segregation of name spaces into standard and experimental areas was the perceived difficulty of registering names. However, the solution to that problem has been simpler registration rules, such as those provided by [RFC3864] (Klyne, G., Nottingham, M., and J. Mogul, “Registration Procedures for Message Header Fields,” September 2004.) and [RFC4288] (Freed, N. and J. Klensin, “Media Type Specifications and Registration Procedures,” December 2005.), as well as separate registries for permanent and provisional names. Indeed, [RFC4288] (Freed, N. and J. Klensin, “Media Type Specifications and Registration Procedures,” December 2005.) explicitly calls out the implications for experimental names:

[W]ith the simplified registration procedures described above for vendor and personal trees, it should rarely, if ever, be necessary to use unregistered experimental types. Therefore, use of both "x-" and "x." forms is discouraged.

In some limited situations, segregating a name space can be justified; for example, when the names need to be very small (as in [RFC5646] (Phillips, A. and M. Davis, “Tags for Identifying Languages,” September 2009.)) or when the names have significant meaning. However, in general, segregating experimental or implementation-specific parameters into an "X-" ghetto has few if any benefits, and has at least one significant interoperability cost. The practice is at best useless and at worst harmful.

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

Therefore, this document recommends against the creation of new names with the special "X-" prefix in IETF protocols.



 TOC 

3.  Security Considerations

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



 TOC 

4.  IANA Considerations

This document has no actions for the IANA.



 TOC 

5.  Acknowledgements

Thanks to Adam Barth, Dave Crocker, Martin Duerst, Paul Hoffman, Graham Klyne, Alexey Melnikov, Mark Nottingham, and Randy Presuhn for feedback.



 TOC 

6. Informative References

[RFC822] Crocker, D., “Standard for the format of ARPA Internet text messages,” STD 11, RFC 822, August 1982 (TXT).
[RFC1154] Robinson, D. and R. Ullmann, “Encoding header field for internet messages,” RFC 1154, April 1990 (TXT).
[RFC2045] Freed, N. and N. Borenstein, “Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies,” RFC 2045, November 1996 (TXT).
[RFC2046] Freed, N. and N. Borenstein, “Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types,” RFC 2046, November 1996 (TXT).
[RFC2047] Moore, K., “MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text,” RFC 2047, November 1996 (TXT, HTML, XML).
[RFC2068] Fielding, R., Gettys, J., Mogul, J., Nielsen, H., and T. Berners-Lee, “Hypertext Transfer Protocol -- HTTP/1.1,” RFC 2068, January 1997 (TXT).
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, “Hypertext Transfer Protocol -- HTTP/1.1,” RFC 2616, June 1999 (TXT, PS, PDF, HTML, XML).
[RFC2821] Klensin, J., “Simple Mail Transfer Protocol,” RFC 2821, April 2001 (TXT).
[RFC3864] Klyne, G., Nottingham, M., and J. Mogul, “Registration Procedures for Message Header Fields,” BCP 90, RFC 3864, September 2004 (TXT).
[RFC4288] Freed, N. and J. Klensin, “Media Type Specifications and Registration Procedures,” BCP 13, RFC 4288, December 2005 (TXT).
[RFC5321] Klensin, J., “Simple Mail Transfer Protocol,” RFC 5321, October 2008 (TXT).
[RFC5646] Phillips, A. and M. Davis, “Tags for Identifying Languages,” BCP 47, RFC 5646, September 2009 (TXT).


 TOC 

Author's Address

  Peter Saint-Andre
  Cisco
  1899 Wyknoop Street, Suite 600
  Denver, CO 80202
  USA
Phone:  +1-303-308-3282
Email:  psaintan@cisco.com