draft-ietf-appsawg-xdash-01.txt   draft-ietf-appsawg-xdash-02.txt 
Network Working Group 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: April 20, 2012 Brandenburg InternetWorking Expires: April 26, 2012 Brandenburg InternetWorking
M. Nottingham M. Nottingham
October 18, 2011 Rackspace
October 24, 2011
Deprecating Use of the "X-" Prefix in Application Protocols Deprecating Use of the "X-" Prefix in Application Protocols
draft-ietf-appsawg-xdash-01 draft-ietf-appsawg-xdash-02
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 38
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 April 20, 2012. This Internet-Draft will expire on April 26, 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
skipping to change at page 3, line 18 skipping to change at page 3, line 18
(media types, header fields in Internet mail messages and HTTP (media types, header fields in Internet mail messages and HTTP
requests, vCard parameters and properties, etc.). Historically, requests, vCard parameters and properties, etc.). Historically,
designers and implementers of application protocols have often designers and implementers of application protocols have often
distinguished between "standard" and "non-standard" parameters by distinguished between "standard" and "non-standard" parameters by
prefixing the latter with the string "X-" or similar constructions prefixing the latter with the string "X-" or similar constructions
(e.g., "x."), where the "X" is commonly understood to stand for (e.g., "x."), where the "X" is commonly understood to stand for
"eXperimental" or "eXtension". "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 benefits have
associated with the advancement of non-standard parameters into the been outweighed by the costs associated with the leakage of non-
standards space have outweighed the benefits. Therefore this standard parameters into the standards space. 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.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
skipping to change at page 4, line 18 skipping to change at page 4, line 18
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 provide registries that have potentially unlimited value- 1. SHOULD establish registries with potentially unlimited value-
spaces, with well-defined registration procedures. spaces, if appropriate including both permanent and provisional
registries.
2. SHOULD mandate registration of all non-private parameters,
independent of the form of the parameter names.
3. MUST NOT assume that a parameter with an "X-" prefix is non- 2. SHOULD define simple, clear registration procedures.
standard.
4. MUST NOT assume that a parameter without an "X-" prefix is 3. SHOULD mandate registration of all non-private parameters,
standard. independent of the form of the parameter names.
5. SHOULD identify a convention to allow local or implementation- 4. 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 5. SHOULD NOT prohibit parameters with the "X-" prefix from being
registered with the IANA. registered with the IANA.
6. MUST NOT assume that a parameter with an "X-" prefix is non-
standard.
7. MUST NOT assume that a parameter without an "X-" prefix 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).
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
skipping to change at page 7, line 14 skipping to change at page 7, line 18
Resource Identifier (URI): Generic Syntax", STD 66, Resource Identifier (URI): Generic Syntax", STD 66,
RFC 3986, January 2005. RFC 3986, January 2005.
[RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally [RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally
Unique IDentifier (UUID) URN Namespace", RFC 4122, Unique IDentifier (UUID) URN Namespace", RFC 4122,
July 2005. July 2005.
[RFC4288] Freed, N. and J. Klensin, "Media Type Specifications and [RFC4288] Freed, N. and J. Klensin, "Media Type Specifications and
Registration Procedures", BCP 13, RFC 4288, December 2005. Registration Procedures", BCP 13, RFC 4288, December 2005.
[RFC4395] Hansen, T., Hardie, T., and L. Masinter, "Guidelines and
Registration Procedures for New URI Schemes", BCP 35,
RFC 4395, February 2006.
[RFC4512] Zeilenga, K., "Lightweight Directory Access Protocol [RFC4512] Zeilenga, K., "Lightweight Directory Access Protocol
(LDAP): Directory Information Models", RFC 4512, (LDAP): Directory Information Models", RFC 4512,
June 2006. June 2006.
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
Description Protocol", RFC 4566, July 2006. Description Protocol", RFC 4566, July 2006.
[RFC5064] Duerst, M., "The Archived-At Message Header Field", [RFC5064] Duerst, M., "The Archived-At Message Header Field",
RFC 5064, December 2007. RFC 5064, December 2007.
skipping to change at page 9, line 13 skipping to change at page 9, line 22
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 leak 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 (and sometimes
implementations will support only the "X-" name and newer security issues) because older implementations will support only the
implementations might support only the standard name. To preserve "X-" name and newer implementations might support only the standard
interoperability, newer implementations simply support the "X-" name name. To preserve interoperability, newer implementations simply
forever, which means that the non-standard name has become a de facto support the "X-" name forever, which means that the non-standard name
standard (thus obviating the need for segregation of the name space has become a de facto standard (thus obviating the need for
into "standard" and "non-standard" areas in the first place). segregation of the name space into "standard" and "non-standard"
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-compressed" 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.
skipping to change at page 9, line 46 skipping to change at page 10, line 9
For backwards compatibility, this document also describes the For backwards compatibility, this document also describes the
X-Archived-At header field, a precursor of the Archived-At header X-Archived-At header field, a precursor of the Archived-At header
field. The X-Archived-At header field MAY also be parsed, but field. The X-Archived-At header field MAY also be parsed, but
SHOULD NOT be generated. SHOULD NOT be generated.
One of the original reasons for segregation of name spaces into One of the original reasons for segregation of name spaces into
standard and non-standard areas was the perceived difficulty of standard and non-standard areas was the perceived difficulty of
registering names. However, the solution to that problem has been registering names. However, the solution to that problem has been
simpler registration rules, such as those provided by [RFC3864] and simpler registration rules, such as those provided by [RFC3864] and
[RFC4288], as well as separate registries for permanent and [RFC4288]. As explained in [RFC4288]:
provisional names, as explained in [RFC4288]:
[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
establishment of separate registries for permanent names and
provisional names, as in [RFC4395].
Furthermore, often standardization of a non-standard parameter or Furthermore, often standardization of a non-standard parameter or
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].
skipping to change at page 11, line 41 skipping to change at page 12, line 9
purposes (see also [BCP26]). purposes (see also [BCP26]).
Therefore it appears that segregating the parameter space into a Therefore it appears that segregating the parameter space into a
standard area and a non-standard area has few if any benefits, and standard area and a non-standard area has few if any benefits, and
has at least one significant cost in terms of interoperability. has at least one significant cost in terms of interoperability.
Authors' Addresses Authors' Addresses
Peter Saint-Andre Peter Saint-Andre
Cisco Systems, Inc. Cisco Systems, Inc.
1899 Wyknoop Street, Suite 600 1899 Wynkoop Street, Suite 600
Denver, CO 80202 Denver, CO 80202
USA USA
Phone: +1-303-308-3282 Phone: +1-303-308-3282
Email: psaintan@cisco.com Email: psaintan@cisco.com
D. Crocker D. Crocker
Brandenburg InternetWorking Brandenburg InternetWorking
675 Spruce Dr. 675 Spruce Dr.
Sunnyvale Sunnyvale
USA USA
Phone: +1.408.246.8253 Phone: +1.408.246.8253
Email: dcrocker@bbiw.net Email: dcrocker@bbiw.net
URI: http://bbiw.net URI: http://bbiw.net
skipping to change at page 12, line 15 skipping to change at page 12, line 27
Brandenburg InternetWorking Brandenburg InternetWorking
675 Spruce Dr. 675 Spruce Dr.
Sunnyvale Sunnyvale
USA USA
Phone: +1.408.246.8253 Phone: +1.408.246.8253
Email: dcrocker@bbiw.net Email: dcrocker@bbiw.net
URI: http://bbiw.net URI: http://bbiw.net
Mark Nottingham Mark Nottingham
Rackspace
Email: mnot@mnot.net Email: mnot@mnot.net
URI: http://www.mnot.net URI: http://www.mnot.net
 End of changes. 20 change blocks. 
30 lines changed or deleted 44 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/