Network Working Group P. Saint-Andre
Internet-Draft Cisco Systems, Inc.
Intended status: BCP July 2, 2010
Expires: January 3, 2011
"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
Saint-Andre Expires January 3, 2011 [Page 1]
Internet-Draft X- Considered Harmful July 2010
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Argument . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Security Considerations . . . . . . . . . . . . . . . . . . . . 4
3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 4
4. Informative References . . . . . . . . . . . . . . . . . . . . 4
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 5
Saint-Andre Expires January 3, 2011 [Page 2]
Internet-Draft X- Considered Harmful July 2010
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] 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] [RFC2046] [RFC2047], email [RFC2821] [RFC5321], HTTP
[RFC2068] [RFC2616], and other technologies.
The primary objections to discarding the "X-" convention are:
o 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.
o 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]:
For compatibility with previous implementations of HTTP,
applications should consider "x-gzip" and "x-compress" to be
equivalent to "gzip" and "compress" respectively.
Saint-Andre Expires January 3, 2011 [Page 3]
Internet-Draft X- Considered Harmful July 2010
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
[RFC1154] Robinson, D. and R. Ullmann, "Encoding header field for
internet messages", RFC 1154, April 1990.
[RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part One: Format of Internet Message
Bodies", RFC 2045, November 1996.
[RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part Two: Media Types", RFC 2046,
November 1996.
[RFC2047] Moore, K., "MIME (Multipurpose Internet Mail Extensions)
Part Three: Message Header Extensions for Non-ASCII Text",
RFC 2047, November 1996.
[RFC2068] Fielding, R., Gettys, J., Mogul, J., Nielsen, H., and T.
Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1",
RFC 2068, 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", RFC 2616, June 1999.
[RFC2821] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821,
April 2001.
[RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321,
October 2008.
Saint-Andre Expires January 3, 2011 [Page 4]
Internet-Draft X- Considered Harmful July 2010
Author's Address
Peter Saint-Andre
Cisco Systems, Inc.
1899 Wyknoop Street, Suite 600
Denver, CO 80202
USA
Phone: +1-303-308-3282
Email: psaintan@cisco.com
Saint-Andre Expires January 3, 2011 [Page 5]