< draft-ietf-appsawg-xdash-03.txt   draft-ietf-appsawg-xdash-04.txt >
APPSAWG P. Saint-Andre APPSAWG P. Saint-Andre
Internet-Draft Cisco Systems, Inc. Internet-Draft Cisco Systems, Inc.
Intended status: BCP D. Crocker Intended status: BCP D. Crocker
Expires: August 16, 2012 Brandenburg InternetWorking Expires: September 13, 2012 Brandenburg InternetWorking
M. Nottingham M. Nottingham
Rackspace Rackspace
February 13, 2012 March 12, 2012
Deprecating Use of the "X-" Prefix in Application Protocols Deprecating the X- Prefix and Similar Constructs in Application
draft-ietf-appsawg-xdash-03 Protocols
draft-ietf-appsawg-xdash-04
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 names of "non-standard" parameters with
constructions. In practice, this convention causes more problems the string "X-" or similar constructs. In practice, that convention
than it solves. Therefore, this document deprecates the "X-" causes more problems than it solves. Therefore, this document
convention for textual parameters in application protocols. deprecates the convention for the names of newly-defined textual
parameters in application protocols.
Status of this Memo Status of this Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 August 16, 2012. This Internet-Draft will expire on September 13, 2012.
Copyright Notice Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the Copyright (c) 2012 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. Recommendations for Implementers of Application Protocols . . 3 2. Recommendations for Implementers of Application Protocols . . 3
3. Recommendations for Creators of New Parameters . . . . . . . . 3 3. Recommendations for Creators of New Parameters . . . . . . . . 4
4. Recommendations for Protocol Designers . . . . . . . . . . . . 4 4. Recommendations for Protocol Designers . . . . . . . . . . . . 4
5. Security Considerations . . . . . . . . . . . . . . . . . . . 4 5. Security Considerations . . . . . . . . . . . . . . . . . . . 4
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 5 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 5
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 5 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 5
8.1. Normative References . . . . . . . . . . . . . . . . . . . 5 8.1. Normative References . . . . . . . . . . . . . . . . . . . 5
8.2. Informative References . . . . . . . . . . . . . . . . . . 5 8.2. Informative References . . . . . . . . . . . . . . . . . . 5
Appendix A. Background . . . . . . . . . . . . . . . . . . . . . 7 Appendix A. Background . . . . . . . . . . . . . . . . . . . . . 8
Appendix B. Analysis . . . . . . . . . . . . . . . . . . . . . . 9 Appendix B. Analysis . . . . . . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12
1. Introduction 1. Introduction
Many application protocols use parameters with textual names to Many application protocols use parameters with textual names to
identify data (media types, header fields in Internet mail messages identify data (media types, header fields in Internet mail messages
and HTTP requests, vCard parameters and properties, etc.). and HTTP requests, vCard parameters and properties, etc.).
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 names of "non-standard" parameters with
constructions (e.g., "x."), where the "X" is commonly understood to the string "X-" or similar constructs (e.g., "x."), where the "X" is
stand for "eXperimental" or "eXtension". commonly understood to stand for "eXperimental" or "eXtension". That
is, instead of just identifying the data, the name also embedded the
status of the name as "non-standard" into the name itself.
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 benefits have parameters and non-standard parameters, in practice the benefits have
been outweighed by the costs associated with the leakage of non- been outweighed by the costs associated with the leakage of non-
standard parameters into the standards space. Therefore this standard parameters into the standards space. Therefore this
document deprecates the "X-" convention for named parameters in document deprecates the "X-" convention for named parameters in
application protocols and makes specific recommendations about how to application protocols and makes specific recommendations about how to
proceed in a world without the distinction between standard and non- proceed in a world without the distinction between standard and non-
standard parameters. Note that this document covers only parameters standard parameters. Note that this document covers only parameters
with textual names, not parameters that are expressed as numbers. In with textual names, not parameters that are expressed as numbers. In
addition, this document makes no recommendation as to whether addition, this document does not recommend against the practice of
existing "X-" parameters ought to remain in use or be migrated to a private, local, preliminary, experimental, or implementation-specific
format without the "X-". parameters, only against the use of "X-" and similar constructs in
the names of such parameters. Finally, this document makes no
recommendation as to whether existing "X-" parameters ought to remain
in use or be migrated to a format without the "X-".
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.
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].
2. Recommendations for Implementers of Application Protocols 2. Recommendations for Implementers of Application Protocols
Implementers of application protocols MUST NOT treat the general Implementations of application protocols MUST NOT programatically
categories of "standard" and "non-standard" parameters in discriminate between "standard" and "non-standard" parameters based
programatically different ways within their applications. solely on the names of such parameters (i.e., based solely on whether
the name begins with 'x-' or a similar string of characters).
3. Recommendations for Creators of New Parameters 3. Recommendations for Creators of New Parameters
Creators of new parameters to be used in the context of application Creators of new parameters to be used in the context of application
protocols: protocols:
1. SHOULD assume that all parameters they create might become 1. SHOULD assume that all parameters they create might become
standardized, public, commonly deployed, or used across multiple standardized, public, commonly deployed, or used across multiple
implementations. implementations.
2. SHOULD employ meaningful names that they have reason to believe 2. SHOULD employ meaningful names that they have reason to believe
are currently unused (without the "X-" prefix). are currently unused (without the "X-" prefix or similar
constructs).
Note: If the relevant parameter name space has conventions about Note: If the relevant parameter name space has conventions about
associating parameter names with those who create them, a parameter associating parameter names with those who create them, a parameter
name could incorporate the organization's name or primary domain name name could incorporate the organization's name or primary domain name
(see Appendix B for examples). (see Appendix B for examples).
4. 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 establish registries with potentially unlimited value- 1. SHOULD establish registries with potentially unlimited value-
spaces, if appropriate including both permanent and provisional spaces, if appropriate including both permanent and provisional
registries. registries.
2. SHOULD define simple, clear registration procedures. 2. SHOULD define simple, clear registration procedures.
3. SHOULD mandate registration of all non-private parameters, 3. SHOULD mandate registration of all non-private parameters,
independent of the form of the parameter names. independent of the form of the parameter names.
4. SHOULD identify a convention to allow local or implementation- 4. SHOULD NOT prohibit parameters with the "X-" prefix or similar
specific extensions, and reserve delimeters for such uses as constructs from being registered with the IANA.
needed.
5. SHOULD NOT prohibit parameters with the "X-" prefix from being
registered with the IANA.
6. MUST NOT assume that a parameter with an "X-" prefix is non- 5. MUST NOT assume that a parameter with an "X-" prefix or similar
standard. constructs is non-standard.
7. MUST NOT assume that a parameter without an "X-" prefix is 6. MUST NOT assume that a parameter without an "X-" prefix or
standard. similar constructs is standard.
5. 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 (see Appendix B parameters can result in unnecessary vulnerabilities (see Appendix B
for further discussion). for further discussion).
As a corollary to the recommendation provided under Section 2,
implementations MUST NOT assume that "standard" parameters are
"secure" whereas "non-standard" parameters are "insecure", based
solely on the names of such parameters.
6. 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.
7. 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, Scott Kelly, Scott Kitterman, John Klensin, Graham
Lear, John Levine, Bill McQuillan, Alexey Melnikov, Subramanian Klyne, Murray Kucherawy, Eliot Lear, John Levine, Bill McQuillan,
Moonesamy, Keith Moore, Ben Niven-Jenkins, Zoltan Ordogh, Tim Petch, Alexey Melnikov, Subramanian Moonesamy, Keith Moore, Ben Niven-
Dirk Pranke, Randy Presuhn, Julian Reschke, Doug Royer, Andrew Jenkins, Zoltan Ordogh, Tim Petch, Dirk Pranke, Randy Presuhn, Julian
Sullivan, Martin Thomson, Matthew Wild, Nicolas Williams, Tim Reschke, Doug Royer, Andrew Sullivan, Martin Thomson, Matthew Wild,
Williams, Mykyta Yevstifeyev, and Kurt Zeilenga for their feedback. Nicolas Williams, Tim Williams, Mykyta Yevstifeyev, and Kurt Zeilenga
for their feedback.
8. References 8. References
8.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.
8.2. Informative References 8.2. Informative References
skipping to change at page 9, line 38 skipping to change at page 9, line 46
security issues) because older implementations will support only the security issues) because older implementations will support only the
"X-" name and newer implementations might support only the standard "X-" name and newer implementations might support only the standard
name. To preserve interoperability, newer implementations simply name. To preserve interoperability, newer implementations simply
support the "X-" name forever, which means that the non-standard name support the "X-" name forever, which means that the non-standard name
has become a de facto standard (thus obviating the need for has become a de facto standard (thus obviating the need for
segregation of the name space into "standard" and "non-standard" segregation of the name space into "standard" and "non-standard"
areas in the first place). areas in the first place).
We have already seen this phenomenon at work with regard to FTP in We have already seen this phenomenon at work with regard to FTP in
the quote from [RFC1123] in the previous section. The HTTP community the quote from [RFC1123] in the previous section. The HTTP community
had the same experience with the "x-gzip" and "x-compressed" media had the same experience with the "x-gzip" and "x-compress" media
types, as noted in [RFC2068]: types, as noted in [RFC2068]:
For compatibility with previous implementations of HTTP, For compatibility with previous implementations of HTTP,
applications should consider "x-gzip" and "x-compress" to be applications should consider "x-gzip" and "x-compress" to be
equivalent to "gzip" and "compress" respectively. equivalent to "gzip" and "compress" respectively.
A similar example can be found in [RFC5064], which defined the A similar example can be found in [RFC5064], which defined the
"Archived-At" message header field but also found it necessary to "Archived-At" message header field but also found it necessary to
define and register the "X-Archived-At" field: define and register the "X-Archived-At" field:
skipping to change at page 10, line 25 skipping to change at page 10, line 33
[W]ith the simplified registration procedures described above for [W]ith the simplified registration procedures described above for
vendor and personal trees, it should rarely, if ever, be necessary vendor and personal trees, it should rarely, if ever, be necessary
to use unregistered experimental types. Therefore, use of both to use unregistered experimental types. Therefore, use of both
"x-" and "x." forms is discouraged. "x-" and "x." forms is discouraged.
For some name spaces, another helpful practice has been the For some name spaces, another helpful practice has been the
establishment of separate registries for permanent names and establishment of separate registries for permanent names and
provisional names, as in [RFC4395]. provisional names, as in [RFC4395].
Furthermore, often standardization of a non-standard parameter or Furthermore, often standardization of a non-standard parameter leads
protocol element leads to subtly different behavior (e.g., the to subtly different behavior (e.g., the standard version might have
standard version might have different security properties as a result different security properties as a result of security review provided
of security review provided during the standardization process). If during the standardization process). If implementers treat the old,
implementers treat the old, non-standard parameter and the new, non-standard parameter and the new, standard parameter as equivalent,
standard parameter as equivalent, interoperability and security interoperability and security problems can ensue. Analysis of non-
problems can ensue. standard parameters to detect and correct flaws is in general a good
thing and is not intended to be discouraged by the lack of
distinction in element names. Whenever an originally non-standard
parameter or protocol element is standardized and the new form has
differences which affect interoperability or security properties,
implementations MUST NOT treat the old form as identical to the new
form.
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 parameter 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. In this case implementation-specific and private-
private-use parameters could at least incorporate the use parameters could at least incorporate the organization's name
organization's name (e.g., "ExampleInc-foo" or, consistent with (e.g., "ExampleInc-foo" or, consistent with [RFC4288],
[RFC4288], "VND.ExampleInc.foo") or primary domain name (e.g., "VND.ExampleInc.foo") or primary domain name (e.g.,
"com.example.foo" or a Uniform Resource Identifier [RFC3986] such "com.example.foo" or a Uniform Resource Identifier [RFC3986] such
as "http://example.com/foo"). In rare cases, truly experimental as "http://example.com/foo"). In rare cases, truly experimental
parameters could be given meaningless names such as nonsense parameters could be given meaningless names such as nonsense
words, the output of a hash function, or UUIDs [RFC4122]. words, the output of a hash function, or UUIDs [RFC4122].
2. When parameter names might have significant meaning. However, 2. When parameter names might have significant meaning. This case
this case too is rare, since implementers can almost always find too is rare, since implementers can almost always find a synonym
a synonym for an existing term (e.g., "urgency" instead of for an existing term (e.g., "urgency" instead of "priority") or
"priority") or simply invent a more creative name (e.g., "get-it- simply invent a more creative name (e.g., "get-it-there-fast").
there-fast"). The existence of multiple similarly-named paramaters can be
confusing, but this is true regardless if there is an attempt to
segregate standard and non-standard (e.g., "X-Priority" can be
confused with "Urgency").
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). In this case it can be more efficient to
efficient to assign numbers instead of human-readable names assign numbers instead of human-readable names (e.g., as in
(e.g., as in [RFC2939] for DCHP options) and to leave a certain [RFC2939] for DCHP options) and to leave a certain numeric range
numeric range for implementation-specific extensions or private for implementation-specific extensions or private use (e.g., as
use (e.g., as with the codec numbers used with the Session with the codec numbers used with the Session Description Protocol
Description Protocol [RFC4566]). [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 might mistake one parameter for another parameter
that a parameter is non-standard unless it contains the "X-" that has a similar name; a rigid distinction such as an "X-"
prefix. However, implementers already are quite flexible about prefix can make this clear. However, in practice implementers
using both prefixed and non-prefixed names based on what works in are forced to blur the distinction (e.g., by treating "X-foo" as
the field, so the distinction between de facto names (e.g., a de facto standard) and so it inevitably becomes meaningless.
"X-foo") and de jure names (e.g., "foo") is without force.
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. 23 change blocks. 
67 lines changed or deleted 86 lines changed or added

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