draft-ietf-appsawg-xdash-00.txt   draft-ietf-appsawg-xdash-01.txt 
Network Working Group P. Saint-Andre Network Working Group P. Saint-Andre
Internet-Draft Cisco Systems, Inc. Internet-Draft Cisco Systems, Inc.
Intended status: BCP D. Crocker Intended status: BCP D. Crocker
Expires: March 16, 2012 Brandenburg InternetWorking Expires: April 20, 2012 Brandenburg InternetWorking
M. Nottingham M. Nottingham
September 13, 2011 October 18, 2011
Deprecating Use of the "X-" Prefix in Application Protocols Deprecating Use of the "X-" Prefix in Application Protocols
draft-ietf-appsawg-xdash-00 draft-ietf-appsawg-xdash-01
Abstract Abstract
Historically, designers and implementers of application protocols Historically, designers and implementers of application protocols
have often distinguished between "standard" and "non-standard" have often distinguished between "standard" and "non-standard"
parameters by prefixing the latter with the string "X-" or similar parameters by prefixing the latter with the string "X-" or similar
constructions. In practice, this convention causes more problems constructions. In practice, this convention causes more problems
than it solves. Therefore, this document deprecates the "X-" than it solves. Therefore, this document deprecates the "X-"
convention for most application protocol parameters. convention for most application protocol parameters.
skipping to change at page 1, line 37 skipping to change at page 1, line 37
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on March 16, 2012. This Internet-Draft will expire on April 20, 2012.
Copyright Notice Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Recommendations for Implementers of Application Protocols . . 3
3. Recommendations for Implementers of Application Protocols . . 3 3. Recommendations for Creators of New Parameters . . . . . . . . 3
4. Recommendations for Creators of New Parameters . . . . . . . . 3 4. Recommendations for Protocol Designers . . . . . . . . . . . . 4
5. Recommendations for Protocol Designers . . . . . . . . . . . . 4 5. Security Considerations . . . . . . . . . . . . . . . . . . . 4
6. Security Considerations . . . . . . . . . . . . . . . . . . . 5 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 5
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 5 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 5
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 5 8.1. Normative References . . . . . . . . . . . . . . . . . . . 5
9.1. Normative References . . . . . . . . . . . . . . . . . . . 5 8.2. Informative References . . . . . . . . . . . . . . . . . . 5
9.2. Informative References . . . . . . . . . . . . . . . . . . 5 Appendix A. Background . . . . . . . . . . . . . . . . . . . . . 7
Appendix A. Background . . . . . . . . . . . . . . . . . . . . . 8
Appendix B. Analysis . . . . . . . . . . . . . . . . . . . . . . 9 Appendix B. Analysis . . . . . . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11
1. Introduction 1. Introduction
Many application protocols use named parameters to identify data Many application protocols use named parameters to identify data
(media types, header fields in Internet mail messages and HTTP (media types, header fields in Internet mail messages and HTTP
requests, etc.). Historically, designers and implementers of requests, vCard parameters and properties, etc.). Historically,
application protocols have often distinguished between "standard" and designers and implementers of application protocols have often
"non-standard" parameters by prefixing the latter with the string distinguished between "standard" and "non-standard" parameters by
"X-" or similar constructions (e.g., "x."), where the "X" is commonly prefixing the latter with the string "X-" or similar constructions
understood to stand for "eXperimental" or "eXtension". (e.g., "x."), where the "X" is commonly understood to stand for
"eXperimental" or "eXtension".
Although in theory the "X-" convention was a good way to avoid Although in theory the "X-" convention was a good way to avoid
collisions (and attendant interoperability problems) between standard collisions (and attendant interoperability problems) between standard
parameters and non-standard parameters, in practice the costs parameters and non-standard parameters, in practice the costs
associated with the advancement of non-standard parameters into the associated with the advancement of non-standard parameters into the
standards space have outweighed the benefits. Therefore this standards space have outweighed the benefits. Therefore this
document deprecates the "X-" convention for most application document deprecates the "X-" convention for most application
protocols and makes specific recommendations about how to proceed in protocols and makes specific recommendations about how to proceed in
a world without the distinction between standard and non-standard a world without the distinction between standard and non-standard
parameters. parameters.
See Appendix A for background information about the history of the See Appendix A for background information about the history of the
"X-" convention, and Appendix B for the reasoning that led to the "X-" convention, and Appendix B for the reasoning that led to the
recommendations in this document. recommendations in this document.
2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in "OPTIONAL" in this document are to be interpreted as described in
[RFC2119]. [RFC2119].
3. Recommendations for Implementers of Application Protocols 2. Recommendations for Implementers of Application Protocols
Implementers of application protocols:
1. MUST NOT treat the general categories of "standard" and "non-
standard" parameters in programatically different ways within
their applications.
4. Recommendations for Creators of New Parameters Implementers of application protocols MUST NOT treat the general
categories of "standard" and "non-standard" parameters in
programatically different ways within their applications.
Creators of new parameters to be used in the context of existing 3. Recommendations for Creators of New Parameters
application protocols (e.g., HTTP headers, Internet media types):
1. SHOULD by default assume that all parameters they create have the Creators of new parameters to be used in the context of application
potential to become standardized or widely used. protocols:
2. SHOULD employ meaningful but currently unused names -- without 1. SHOULD assume that all parameters they create might become
the "X-" prefix -- when there is the potential for a parameter to standardized, public, commonly deployed, or used across multiple
become standardized or widely used (e.g., because an extension is implementations.
public or awaiting wider validation).
3. SHOULD follow conventions specific to the relevant parameter name 2. SHOULD employ meaningful but currently unused names (without the
space when creating parameters for use in implementation-specific "X-" prefix).
applications or on private networks. Especially if the parameter
is intended to have meaning to implementers, the name could be a
URI (e.g., "http://example.com/foo") or could incorporate the
organization's name (e.g., "ExampleInc-foo" or, as consistent
with [RFC4288], "VND.ExampleInc.foo") or primary domain name
(e.g., "com.example.foo").
4. SHOULD generate meaningless names for parameters that will not Note: If the relevant parameter name space has conventions about
become standardized or widely used (e.g., because an extension is associating parameter names with those who create them, a parameter
completely private or purely speculative). For instance, the name could incorporate the organization's name or primary domain name
name could be the output of a hash function (e.g., (see Appendix B for examples).
"esuDj6Ssil8kDn4yfvvdwMTRhlU"), a UUID (e.g., "1AB9C36F-1618-
4C1F-855D-96B5BAFC7FB3"), or even a nonsense word (e.g.,
"foobarbazqux") .
5. Recommendations for Protocol Designers 4. Recommendations for Protocol Designers
Designers of new application protocols that allow extensions using Designers of new application protocols that allow extensions using
parameters: parameters:
1. SHOULD provide unlimited registries with well-defined 1. SHOULD provide registries that have potentially unlimited value-
registration procedures. spaces, with well-defined registration procedures.
2. SHOULD mandate registration of all non-private parameters, 2. SHOULD mandate registration of all non-private parameters,
independent of the form of the parameter names. independent of the form of the parameter names.
3. MUST NOT assume that a parameter with an "X-" prefix is non- 3. MUST NOT assume that a parameter with an "X-" prefix is non-
standard. standard.
4. MUST NOT assume that a parameter without an "X-" prefix is 4. MUST NOT assume that a parameter without an "X-" prefix is
standard. standard.
5. SHOULD identify a convention to allow local or implementation- 5. SHOULD identify a convention to allow local or implementation-
specific extensions, and reserve delimeters for such uses as specific extensions, and reserve delimeters for such uses as
needed. needed.
6. SHOULD NOT prohibit parameters with the "X-" prefix from being 6. SHOULD NOT prohibit parameters with the "X-" prefix from being
registered with IANA. registered with the IANA.
6. Security Considerations 5. Security Considerations
Interoperability and migration issues with security-critical Interoperability and migration issues with security-critical
parameters can result in unnecessary vulnerabilities. parameters can result in unnecessary vulnerabilities (see Appendix B
for further discussion).
7. IANA Considerations 6. IANA Considerations
This document does not modify registration procedures currently in This document does not modify registration procedures currently in
force for various application protocols. However, such procedures force for various application protocols. However, such procedures
might be updated in the future to incorporate the best practices might be updated in the future to incorporate the best practices
defined in this document. defined in this document.
8. Acknowledgements 7. Acknowledgements
Thanks to Claudio Allocchio, Adam Barth, Nathaniel Borenstein, Eric Thanks to Claudio Allocchio, Adam Barth, Nathaniel Borenstein, Eric
Burger, Stuart Cheshire, Al Constanzo, Dave Cridland, Martin Duerst, Burger, Stuart Cheshire, Al Constanzo, Dave Cridland, Martin Duerst,
Frank Ellermann, J.D. Falk, Ned Freed, Tony Finch, Randall Gellens, Frank Ellermann, J.D. Falk, Ned Freed, Tony Finch, Randall Gellens,
Tony Hansen, Ted Hardie, Joe Hildebrand, Alfred Hoenes, Paul Hoffman, Tony Hansen, Ted Hardie, Joe Hildebrand, Alfred Hoenes, Paul Hoffman,
Eric Johnson, John Klensin, Graham Klyne, Murray Kucherawy, Eliot Eric Johnson, John Klensin, Graham Klyne, Murray Kucherawy, Eliot
Lear, John Levine, Bill McQuillan, Alexey Melnikov, Subramanian Lear, John Levine, Bill McQuillan, Alexey Melnikov, Subramanian
Moonesamy, Keith Moore, Ben Niven-Jenkins, Dirk Pranke, Randy Moonesamy, Keith Moore, Ben Niven-Jenkins, Dirk Pranke, Randy
Presuhn, Julian Reschke, Doug Royer, Andrew Sullivan, Martin Thomson, Presuhn, Julian Reschke, Doug Royer, Andrew Sullivan, Martin Thomson,
Matthew Wild, Nicolas Williams, Tim Williams, Mykyta Yevstifeyev, and Matthew Wild, Nicolas Williams, Tim Williams, Mykyta Yevstifeyev, and
Kurt Zeilenga for their feedback. Kurt Zeilenga for their feedback.
9. References 8. References
9.1. Normative References 8.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
9.2. Informative References 8.2. Informative References
[BCP9] Bradner, S., "The Internet Standards Process -- Revision [BCP9] Bradner, S., "The Internet Standards Process -- Revision
3", BCP 9, RFC 2026, October 1996. 3", BCP 9, RFC 2026, October 1996.
[BCP26] Narten, T. and H. Alvestrand, "Guidelines for Writing an [BCP26] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226, IANA Considerations Section in RFCs", BCP 26, RFC 5226,
May 2008. May 2008.
[BCP82] Narten, T., "Assigning Experimental and Testing Numbers [BCP82] Narten, T., "Assigning Experimental and Testing Numbers
Considered Useful", BCP 82, RFC 3692, January 2004. Considered Useful", BCP 82, RFC 3692, January 2004.
skipping to change at page 8, line 46 skipping to change at page 8, line 30
That rule was restated by [RFC1154] as follows: That rule was restated by [RFC1154] as follows:
Keywords beginning with "X-" are permanently reserved to Keywords beginning with "X-" are permanently reserved to
implementation-specific use. No standard registered encoding implementation-specific use. No standard registered encoding
keyword will ever begin with "X-". keyword will ever begin with "X-".
This convention continued with various specifications for media types This convention continued with various specifications for media types
([RFC2045], [RFC2046], [RFC2047]), HTTP headers ([RFC2068], ([RFC2045], [RFC2046], [RFC2047]), HTTP headers ([RFC2068],
[RFC2616]), vCard parameters and properties ([RFC2426]), Uniform [RFC2616]), vCard parameters and properties ([RFC2426]), Uniform
Resource Names ([RFC3406]), LDAP field names ([RFC4512]), and other Resource Names ([RFC3406]), LDAP field names ([RFC4512]), and other
technologies. application technologies.
However, use of the "X-" prefix in email headers was effectively However, use of the "X-" prefix in email headers was effectively
deprecated between the publication of [RFC822] in 1982 and the deprecated between the publication of [RFC822] in 1982 and the
publication of [RFC2822] in 2001 by removing the distinction between publication of [RFC2822] in 2001 by removing the distinction between
the "extension-field" construct and the "user-defined-field" the "extension-field" construct and the "user-defined-field"
construct (a similar change happened with regard to Session construct (a similar change happened with regard to Session
Initiation Protocol "P-" headers when [RFC3427] was obsoleted by Initiation Protocol "P-" headers when [RFC3427] was obsoleted by
[RFC5727]). [RFC5727]).
Despite the fact that parameters containing the "X-" string have been Despite the fact that parameters containing the "X-" string have been
effectively deprecated in email headers, they continue to be used in effectively deprecated in email headers, they continue to be used in
a wide variety of application protocols. The two primary situations a wide variety of application protocols. The two primary situations
motivating such use are: motivating such use are:
1. Experiments that are intended to possibly be standardized in the 1. Experiments that are intended to possibly be standardized in the
future, if they are successful. future, if they are successful.
2. Extensions that are intended to never be standardized because 2. Extensions that are intended to never be standardized because
they are intended only for use in implementation-specific they are intended only for implementation-specific use or for
applications or on private networks. local use on private networks.
Use of this naming convention is not mandated by the Internet Use of this naming convention is not mandated by the Internet
Standards Process [BCP9] or IANA registration rules [BCP26]. Rather Standards Process [BCP9] or IANA registration rules [BCP26]. Rather
it is an individual choice by each specification that references the it is an individual choice by each specification that references the
convention or each administrative process that chooses to use it. In convention or each administrative process that chooses to use it. In
particular, some standards track RFCs have interpreted the convention particular, some standards-track RFCs have interpreted the convention
in a normative way (e.g., [RFC822] and [RFC5451]). in a normative way (e.g., [RFC822] and [RFC5451]).
Appendix B. Analysis Appendix B. Analysis
The primary problem with the "X-" convention is that non-standard The primary problem with the "X-" convention is that non-standard
parameters have a tendency to advance into the protected space of parameters have a tendency to advance into the protected space of
standard parameters (whether de jure or de facto), thus introducing standard parameters (whether de jure or de facto), thus introducing
the need for migration from the "X-" name to the standard name. the need for migration from the "X-" name to the standard name.
Migration, in turn, introduces interoperability issues because older Migration, in turn, introduces interoperability issues because older
implementations will support only the "X-" name and newer implementations will support only the "X-" name and newer
skipping to change at page 10, line 34 skipping to change at page 10, line 21
protocol element leads to subtly different behavior (e.g., the protocol element leads to subtly different behavior (e.g., the
standard version might have different security properties as a result standard version might have different security properties as a result
of security review provided during the standardization process). If of security review provided during the standardization process). If
implementers treat the old, non-standard parameter and the new, implementers treat the old, non-standard parameter and the new,
standard parameter as equivalent, interoperability and security standard parameter as equivalent, interoperability and security
problems can ensue. problems can ensue.
For similar considerations with regard to the "P-" convention in the For similar considerations with regard to the "P-" convention in the
Session Initiation Protocol, see [RFC5727]. Session Initiation Protocol, see [RFC5727].
In some situations, segregating the parameters name space used in a In some situations, segregating the parameter name space used in a
given application protocol can be justified: given application protocol can be justified:
1. When it is extremely unlikely that some parameters will ever be 1. When it is extremely unlikely that some parameters will ever be
standardized. However, in this case implementation-specific and standardized. However, in this case implementation-specific and
private-use parameters can be Uniform Resource Identifiers private-use parameters could at least incorporate the
[RFC3986] (e.g., "http://example.com/foo") or can be prepended organization's name (e.g., "ExampleInc-foo" or, consistent with
with a string that is derived from the name or primary domain [RFC4288], "VND.ExampleInc.foo") or primary domain name (e.g.,
name of the organization that has defined the parameter (e.g., "com.example.foo" or a Uniform Resource Identifier [RFC3986] such
"ExampleInc-foo", "VND.ExampleInc.foo", or "com.example.foo"). as "http://example.com/foo"). In rare cases, truly experimental
Similarly, truly experimental parameters can be given meaningless parameters could be given meaningless names such as nonsense
names such as nonsense words, the output of a hash function, or words, the output of a hash function, or UUIDs [RFC4122].
UUIDs [RFC4122].
2. When parameter names might have significant meaning. However, 2. When parameter names might have significant meaning. However,
this case is rare, since implementers can almost always find a this case too is rare, since implementers can almost always find
synonym for an existing term (e.g., "urgency" instead of a synonym for an existing term (e.g., "urgency" instead of
"priority") or simply invent a more creative name (e.g., "get-it- "priority") or simply invent a more creative name (e.g., "get-it-
there-fast"). there-fast").
3. When parameter names need to be very short (e.g., as in [RFC5646] 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 for language tags). However, in this case it can be more
efficient to assign numbers instead of human-readable names efficient to assign numbers instead of human-readable names
(e.g., as in [RFC2939] for DCHP options) and to leave a certain (e.g., as in [RFC2939] for DCHP options) and to leave a certain
numeric range for implementation-specific extensions or private numeric range for implementation-specific extensions or private
use (e.g., as with the codec numbers used with the Session use (e.g., as with the codec numbers used with the Session
Description Protocol [RFC4566]). Description Protocol [RFC4566]).
There are three primary objections to deprecating the "X-" convention There are three primary objections to deprecating the "X-" convention
as a best practice for application protocols: as a best practice for application protocols:
1. Implementers are easily confused and can't be expected to know 1. Implementers are easily confused and can't be expected to know
that a parameter is non-standard unless it contains the "X-" that a parameter is non-standard unless it contains the "X-"
prefix. However, implementers already are quite flexible about prefix. However, implementers already are quite flexible about
using both prefixed and non-prefixed names based on what works in using both prefixed and non-prefixed names based on what works in
the field, so the distinction between de facto names (e.g., the field, so the distinction between de facto names (e.g.,
"X-foo") and de jure names (e.g., "foo") is effectively "X-foo") and de jure names (e.g., "foo") is without force.
meaningless.
2. Collisions are undesirable and it would be bad for both a 2. Collisions are undesirable and it would be bad for both a
standard parameter "foo" and a non-standard parameter "foo" to standard parameter "foo" and a non-standard parameter "foo" to
exist simultaneously. However, names are almost always cheap, so exist simultaneously. However, names are almost always cheap, so
an experimental, implementation-specific, or private-use name of an experimental, implementation-specific, or private-use name of
"foo" does not prevent a standards development organization from "foo" does not prevent a standards development organization from
issuing a similarly creative name such as "bar". issuing a similarly creative name such as "bar".
3. [BCP82] is entitled "Assigning Experimental and Testing Numbers 3. [BCP82] is entitled "Assigning Experimental and Testing Numbers
Considered Useful" and therefore implies that the "X-" prefix is Considered Useful" and therefore implies that the "X-" prefix is
 End of changes. 32 change blocks. 
82 lines changed or deleted 64 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/