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

Versions: 00 01 02 03 draft-ietf-appsawg-xdash

Network Working Group                                     P. Saint-Andre
Internet-Draft                                                     Cisco
Intended status: BCP                                        July 5, 2011
Expires: January 6, 2012


            Use of the "X-" Prefix in Application Protocols
                       draft-saintandre-xdash-01

Abstract

   Many application protocols use named parameters to identify data.
   Historically, protocol designers and implementers distinguished
   between "standard" and "non-standard" parameters by prefixing the
   latter with the string "X-" or similar constructions.  On balance,
   this "X-" convention has more costs than benefits, although it can be
   appropriate in certain circumstances.

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 6, 2012.

Copyright Notice

   Copyright (c) 2011 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



Saint-Andre              Expires January 6, 2012                [Page 1]


Internet-Draft                The X- Prefix                    July 2011


   described in the Simplified BSD License.


Table of Contents

   1.  Background  . . . . . . . . . . . . . . . . . . . . . . . . . . 3
   2.  Analysis  . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
   3.  Recommendations . . . . . . . . . . . . . . . . . . . . . . . . 6
   4.  Security Considerations . . . . . . . . . . . . . . . . . . . . 6
   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6
   6.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . 7
   7.  Informative References  . . . . . . . . . . . . . . . . . . . . 7
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . . . 9






































Saint-Andre              Expires January 6, 2012                [Page 2]


Internet-Draft                The X- Prefix                    July 2011


1.  Background

   Many application protocols use named parameters to identify data
   (media types, header fields in Internet mail messages and HTTP
   requests, etc.).  Historically, protocol designers and implementers
   have often distinguished between "standard" and "non-standard"
   parameters by prefixing the latter with the string "X-" or similar
   constructions (e.g., "x."), where the "X" is commonly understood to
   stand for "eXperimental" or "eXtension".

   Although this usage is purely conventional and is not mandated by the
   Internet Standards Process [BCP9] or IANA registration rules [BCP26],
   some implementers, and even some RFCs, have interpreted the
   convention in a more normative way (e.g., [RFC5451] states that
   "result codes not beginning with 'x-' MUST be registered with the
   Internet Assigned Numbers Authority (IANA) and published in an RFC").

   The "X-" convention has been used for email header fields since at
   least 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 (and subsequently
   reinforced by [RFC2821] and [RFC5321]):

      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 media types
   ([RFC2045], [RFC2046], [RFC2047]), HTTP headers ([RFC2068],
   [RFC2616]), vCard parameters and properties ([RFC2426]), Uniform
   Resource Names ([RFC3406]), LDAP field names ([RFC4512]), Session
   Initiation Protocol "P-" headers ([RFC3427], obsoleted by [RFC5727]),
   and other technologies.

   Parameters prefaced with the "X-" string are currently used in
   application protocols for two different purposes:

   o  Experiments that might be standardized in the future, if they are
      successful.

   o  Extensions that will probably not be standardized because they are
      intended only for use in implementation-specific applications or
      on private networks.



Saint-Andre              Expires January 6, 2012                [Page 3]


Internet-Draft                The X- Prefix                    July 2011


   The remainder of this document analyzes the benefits and costs of the
   "X-" convention and specifies when it is appropriate to apply the
   convention in application protocols.


2.  Analysis

   The primary problem with the "X-" convention is that non-standard
   parameters have a tendency to leak into the protected space of
   standardized parameters (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 non-standard name has
   become a de facto standard (thus obviating the need for segregation
   of the name space into "standard" and "non-standard" in the first
   place).  As one example, we can see this phenomenon at work in
   [RFC2068] (a similar example can be found in [RFC5064]):

      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 non-standard 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, as explained in xref target='RFC4288'/>:

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

   Furthermore, often standarization of a non-standard parameter or
   protocol element leads to subtly different behavior (e.g., the
   standardized version might have different security properties as a
   result of security review provided during the standardization
   process).  If implementers treat the old, non-standard parameter and
   the new, standard parameter as equivalent, interoperability and
   security problems can ensue.

   For similar considerations with regard to the "P-" convention in the
   Session Initiation Protocol, see [RFC5727].




Saint-Andre              Expires January 6, 2012                [Page 4]


Internet-Draft                The X- Prefix                    July 2011


   In some situations, segregating the name space of parameters used in
   a given application protocol can be justified:

   1.  When it is extremely unlikely that some parameters will ever be
       standardized.  However, in this case implementation-specific and
       private-use parameters can be Uniform Resource Identifiers
       [RFC3986] (e.g., "http://example.com/foo") or can be prepended
       with a string that is derived from the name or primary domain
       name of the organization that has defined the parameter (e.g.,
       "Example-foo", "com.example.foo", or "VND.example.com.foo").
       Similarly, truly experimental parameters can be given meaningless
       names such as UUIDs [RFC4122].

   2.  When parameter names might have significant meaning.  However,
       this case is rare, since implementers can almost always find a
       synonym for an existing term (e.g., "urgency" instead of
       "priority") or simply invent a more creative name (e.g., "get-it-
       there-fast").

   3.  When parameter names need to be very short (e.g., as in [RFC5646]
       for language tags).  However, in this case it can be more
       efficient to assign numbers instead of human-readable names
       (e.g., as in [RFC2939] for DCHP options) and to leave a certain
       numeric range for implementation-specific extensions or private
       use (e.g., as with the codec numbers used with the Session
       Description Protocol [RFC4566]).

   There are two primary objections to deprecating the "X-" convention
   as a best practice for application protocols:

   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
      effectively meaningless.

   o  Collisions are undesirable.  However, names are almost always
      cheap, so an experimental, implementation-specific, or private-use
      name of "foo" does not prevent a standards development
      organization from issuing a similarly creative name such as "bar".

   Furthermore, the existence of [BCP82] ("Assigning Experimental and
   Testing Numbers Considered Useful") might appear to provide an
   argument against deprecating the "X-" convention.  However, BCP 82
   addresses the need for protocol numbers when the pool of such numbers
   is strictly limited (e.g., DHCP options) or when a number is
   absolutely required even for purely experimental purposes (e.g., the
   Protocol field of the IP header).  In almost all application



Saint-Andre              Expires January 6, 2012                [Page 5]


Internet-Draft                The X- Prefix                    July 2011


   protocols that make use of protocol parameters (including email
   headers, media types, HTTP headers, vCard parameters and properties,
   URNs, and LDAP field names), the name space is not limited or
   constrained in any way, so there is no need to assign a block of
   names for private use or experimental purposes (see also [BCP26]).

   Therefore it appears that segregating non-standard parameters into an
   "X-" ghetto has few if any benefits, and has at least one significant
   cost in terms of interoperability.


3.  Recommendations

   Based on the foregoing considerations, this document makes the
   following recommendations:

   1.  Authors of application protocol specifications are discouraged
       from imputing special meaning to parameters with the "X-" prefix.

   2.  Authors of application protocol specifications are discouraged
       from mandating that all parameters without the "X-" prefix need
       to be registered with the IANA.

   3.  Implementers wishing to experiment with parameters that have the
       potential to be standardized are encouraged to generate names
       without the "X-" prefix.

   4.  Implementers wishing to experiment with parameters that are
       unlikely to be standardized are encouraged to generate
       meaningless names such as UUIDs or the output of a hash function.

   5.  Implementers wishing to create parameters for use in
       implementation-specific applications or on private networks are
       encouraged to mint URIs or generate names that incorporate the
       relevant organization's name or primary domain name.


4.  Security Considerations

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


5.  IANA Considerations

   This document requests no action by the IANA.





Saint-Andre              Expires January 6, 2012                [Page 6]


Internet-Draft                The X- Prefix                    July 2011


6.  Acknowledgements

   Thanks to Claudio Allocchio, Adam Barth, Nathaniel Borenstein, Eric
   Burger, Al Constanzo, Dave Cridland, Dave Crocker, Martin Duerst,
   Frank Ellermann, J.D. Falk, Tony Finch, Tony Hansen, Ted Hardie, Joe
   Hildebrand, Alfred Hoenes, Paul Hoffman, Eric Johnson, John Klensin,
   Graham Klyne, Murray Kucherawy, Eliot Lear, John Levine, Bill
   McQuillan, Alexey Melnikov, Subramanian Moonesamy, Keith Moore, Ben
   Niven-Jenkins, Mark Nottingham, Dirk Pranke, Randy Presuhn, Julian
   Reschke, Doug Royer, Andrew Sullivan, Martin Thomson, Nicolas
   Williams, and Kurt Zeilenga for their feedback.


7.  Informative References

   [BCP9]     Bradner, S., "The Internet Standards Process -- Revision
              3", BCP 9, RFC 2026, October 1996.

   [BCP26]    Narten, T. and H. Alvestrand, "Guidelines for Writing an
              IANA Considerations Section in RFCs", BCP 26, RFC 5226,
              May 2008.

   [BCP82]    Narten, T., "Assigning Experimental and Testing Numbers
              Considered Useful", BCP 82, RFC 3692, January 2004.

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

   [RFC2426]  Dawson, F. and T. Howes, "vCard MIME Directory Profile",



Saint-Andre              Expires January 6, 2012                [Page 7]


Internet-Draft                The X- Prefix                    July 2011


              RFC 2426, September 1998.

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

   [RFC2939]  Droms, R., "Procedures and IANA Guidelines for Definition
              of New DHCP Options and Message Types", BCP 43, RFC 2939,
              September 2000.

   [RFC3406]  Daigle, L., van Gulik, D., Iannella, R., and P. Faltstrom,
              "Uniform Resource Names (URN) Namespace Definition
              Mechanisms", BCP 66, RFC 3406, October 2002.

   [RFC3427]  Mankin, A., Bradner, S., Mahy, R., Willis, D., Ott, J.,
              and B. Rosen, "Change Process for the Session Initiation
              Protocol (SIP)", RFC 3427, December 2002.

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

   [RFC3986]  Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
              Resource Identifier (URI): Generic Syntax", STD 66,
              RFC 3986, January 2005.

   [RFC4122]  Leach, P., Mealling, M., and R. Salz, "A Universally
              Unique IDentifier (UUID) URN Namespace", RFC 4122,
              July 2005.

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

   [RFC4512]  Zeilenga, K., "Lightweight Directory Access Protocol
              (LDAP): Directory Information Models", RFC 4512,
              June 2006.

   [RFC4566]  Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
              Description Protocol", RFC 4566, July 2006.

   [RFC5064]  Duerst, M., "The Archived-At Message Header Field",
              RFC 5064, December 2007.

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



Saint-Andre              Expires January 6, 2012                [Page 8]


Internet-Draft                The X- Prefix                    July 2011


   [RFC5451]  Kucherawy, M., "Message Header Field for Indicating
              Message Authentication Status", RFC 5451, April 2009.

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

   [RFC5727]  Peterson, J., Jennings, C., and R. Sparks, "Change Process
              for the Session Initiation Protocol (SIP) and the Real-
              time Applications and Infrastructure Area", BCP 67,
              RFC 5727, March 2010.


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 January 6, 2012                [Page 9]


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