[Docs] [txt|pdf|xml|html] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 draft-ietf-appsawg-xdash

Network Working Group                                     P. Saint-Andre
Internet-Draft                                                     Cisco
Intended status: BCP                                    October 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



Saint-Andre              Expires April 22, 2011                 [Page 1]

Internet-Draft            X- Considered Harmful             October 2010


   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.


Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 3
   2.  Argument  . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
   3.  Security Considerations . . . . . . . . . . . . . . . . . . . . 4
   4.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 4
   5.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . 5
   6.  Informative References  . . . . . . . . . . . . . . . . . . . . 5
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . . . 6






































Saint-Andre              Expires April 22, 2011                 [Page 2]

Internet-Draft            X- Considered Harmful             October 2010


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.


2.  Argument

   The "X-" convention has been in use for email header fields since the
   publication of [RFC822] 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] 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] [RFC2046] [RFC2047], email [RFC2821] [RFC5321], HTTP
   [RFC2068] [RFC2616], 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]:

      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 April 22, 2011                 [Page 3]

Internet-Draft            X- Considered Harmful             October 2010


   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] and
   [RFC4288], as well as separate registries for permanent and
   provisional names.  Indeed, [RFC4288] 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]) 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:

   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 usually cheap, so
      an experimental or implementation-specific name of "foo" does not
      prevent a standards development organization from issuing a
      similarly creative name such as "bar".

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


3.  Security Considerations

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


4.  IANA Considerations

   This document has no actions for the IANA.




Saint-Andre              Expires April 22, 2011                 [Page 4]

Internet-Draft            X- Considered Harmful             October 2010


5.  Acknowledgements

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


6.  Informative References

   [RFC822]   Crocker, D., "Standard for the format of ARPA Internet
              text messages", STD 11, RFC 822, August 1982.

   [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.

   [RFC3864]  Klyne, G., Nottingham, M., and J. Mogul, "Registration
              Procedures for Message Header Fields", BCP 90, RFC 3864,
              September 2004.

   [RFC4288]  Freed, N. and J. Klensin, "Media Type Specifications and
              Registration Procedures", BCP 13, RFC 4288, December 2005.

   [RFC5321]  Klensin, J., "Simple Mail Transfer Protocol", RFC 5321,
              October 2008.




Saint-Andre              Expires April 22, 2011                 [Page 5]

Internet-Draft            X- Considered Harmful             October 2010


   [RFC5646]  Phillips, A. and M. Davis, "Tags for Identifying
              Languages", BCP 47, RFC 5646, September 2009.


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





































Saint-Andre              Expires April 22, 2011                 [Page 6]


Html markup produced by rfcmarkup 1.109, available from https://tools.ietf.org/tools/rfcmarkup/