draft-ietf-appsawg-xdash-05.txt   rfc6648.txt 
APPSAWG P. Saint-Andre Internet Engineering Task Force (IETF) P. Saint-Andre
Internet-Draft Cisco Systems, Inc. Request for Comments: 6648 Cisco Systems, Inc.
Intended status: BCP D. Crocker BCP: 178 D. Crocker
Expires: October 11, 2012 Brandenburg InternetWorking Category: Best Current Practice Brandenburg InternetWorking
M. Nottingham ISSN: 2070-1721 M. Nottingham
Rackspace Rackspace
April 9, 2012 June 2012
Deprecating the X- Prefix and Similar Constructs in Application Deprecating the "X-" Prefix and Similar Constructs
Protocols in Application Protocols
draft-ietf-appsawg-xdash-05
Abstract Abstract
Historically, designers and implementers of application protocols Historically, designers and implementers of application protocols
have often distinguished between standardized and unstandardized have often distinguished between standardized and unstandardized
parameters by prefixing the names of unstandardized parameters with parameters by prefixing the names of unstandardized parameters with
the string "X-" or similar constructs. In practice, that convention the string "X-" or similar constructs. In practice, that convention
causes more problems than it solves. Therefore, this document causes more problems than it solves. Therefore, this document
deprecates the convention for newly-defined parameters with textual deprecates the convention for newly defined parameters with textual
(as opposed to numerical) names in application protocols. (as opposed to numerical) names in application protocols.
Status of this Memo 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 This memo documents an Internet Best Current Practice.
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 This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Further information on
BCPs is available in Section 2 of RFC 5741.
This Internet-Draft will expire on October 11, 2012. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc6648.
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 ....................................................2
2. Recommendations for Implementers of Application Protocols . . 4 2. Recommendations for Implementers of Application Protocols .......4
3. Recommendations for Creators of New Parameters . . . . . . . . 4 3. Recommendations for Creators of New Parameters ..................4
4. Recommendations for Protocol Designers . . . . . . . . . . . . 5 4. Recommendations for Protocol Designers ..........................4
5. Security Considerations . . . . . . . . . . . . . . . . . . . 5 5. Security Considerations .........................................5
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 6. IANA Considerations .............................................5
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6 7. Acknowledgements ................................................5
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 Appendix A. Background ............................................6
8.1. Normative References . . . . . . . . . . . . . . . . . . . 6 Appendix B. Analysis ..............................................7
8.2. Informative References . . . . . . . . . . . . . . . . . . 6 References ........................................................10
Appendix A. Background . . . . . . . . . . . . . . . . . . . . . 8 Normative References ...........................................10
Appendix B. Analysis . . . . . . . . . . . . . . . . . . . . . . 10 Informative References .........................................10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13
1. Introduction 1. Introduction
Many application protocols use parameters with textual (as opposed to Many application protocols use parameters with textual (as opposed to
numerical) names to identify data (media types, header fields in numerical) names to identify data (media types, header fields in
Internet mail messages and HTTP requests, vCard parameters and Internet mail messages and HTTP requests, vCard parameters and
properties, etc.). Historically, designers and implementers of properties, etc.). Historically, designers and implementers of
application protocols have often distinguished between standardized application protocols have often distinguished between standardized
and unstandardized parameters by prefixing the names of and unstandardized parameters by prefixing the names of
unstandardized parameters with the string "X-" or similar constructs unstandardized parameters with the string "X-" or similar constructs
skipping to change at page 3, line 28 skipping to change at page 3, line 10
the data, but also embedded the status of the parameter into the name the data, but also embedded the status of the parameter into the name
itself: a parameter defined in a specification produced by a itself: a parameter defined in a specification produced by a
recognized standards development organization (or registered recognized standards development organization (or registered
according to processes defined in such a specification) did not start according to processes defined in such a specification) did not start
with "X-" or similar constructs, whereas a parameter defined outside with "X-" or similar constructs, whereas a parameter defined outside
such a specification or process started with "X-" or similar such a specification or process started with "X-" or similar
constructs. constructs.
As explained more fully under Appendix A, this convention was As explained more fully under Appendix A, this convention was
encouraged for many years in application protocols such as file encouraged for many years in application protocols such as file
transfer, email, and the World Wide Web. In particular, it was transfer, email, and the World Wide Web. In particular, it was
codified for email by [RFC822] (via the distinction between codified for email by [RFC822] (via the distinction between
"Extension-fields" and "user-defined-fields"), but then removed by "Extension-fields" and "user-defined-fields"), but then removed by
[RFC2822] based on implementation and deployment experience. A [RFC2822] based on implementation and deployment experience. A
similar progression occurred for SIP technologies with regard to the similar progression occurred for SIP technologies with regard to the
"P-" header, as explained in [RFC5727]. The reasoning behind those "P-" header, as explained in [RFC5727]. The reasoning behind those
changes is explored under Appendix B. changes is explored under Appendix B.
In short, although in theory the "X-" convention was a good way to In short, although in theory the "X-" convention was a good way to
avoid collisions (and attendant interoperability problems) between avoid collisions (and attendant interoperability problems) between
standardized parameters and unstandardized parameters, in practice standardized parameters and unstandardized parameters, in practice
the benefits have been outweighed by the costs associated with the the benefits have been outweighed by the costs associated with the
leakage of unstandardized parameters into the standards space. leakage of unstandardized parameters into the standards space.
This document generalizes from the experience of the email and SIP This document generalizes from the experience of the email and SIP
communities by doing the following: communities by doing the following:
1. Deprecates the "X-" convention for newly-defined parameters in 1. Deprecates the "X-" convention for newly defined parameters in
application protocols, even where that convention was only application protocols, including new parameters for established
implicit instead of being codified in a protocol specification protocols. This change applies even where the "X-" convention
(as was done for email in [RFC822]). was only implicit, and not explicitly provided, such as was done
for email in [RFC822].
2. Makes specific recommendations about how to proceed in a world 2. Makes specific recommendations about how to proceed in a world
without the distinction between standardized and unstandardized without the distinction between standardized and unstandardized
parameters (although only for parameters with textual names, not parameters (although only for parameters with textual names, not
parameters that are expressed as numbers, which are out of parameters that are expressed as numbers, which are out of the
scope). scope of this document).
3. Does not recommend against the practice of private, local, 3. Does not recommend against the practice of private, local,
preliminary, experimental, or implementation-specific parameters, preliminary, experimental, or implementation-specific parameters,
only against the use of "X-" and similar constructs in the names only against the use of "X-" and similar constructs in the names
of such parameters. of such parameters.
4. Makes no recommendation as to whether existing "X-" parameters 4. Makes no recommendation as to whether existing "X-" parameters
ought to remain in use or be migrated to a format without the ought to remain in use or be migrated to a format without the
"X-"; this is a matter for the creators or maintainers of those "X-"; this is a matter for the creators or maintainers of those
parameters. parameters.
skipping to change at page 4, line 40 skipping to change at page 4, line 28
assumptions about the status of a parameter, nor take automatic assumptions about the status of a parameter, nor take automatic
action regarding a parameter, based solely on the presence or absence action regarding a parameter, based solely on the presence or absence
of "X-" or a similar construct in the parameter's name. of "X-" or a similar construct in the parameter's name.
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 usable across
implementations. multiple implementations.
2. SHOULD employ meaningful parameter names that they have reason to 2. SHOULD employ meaningful parameter names that they have reason to
believe are currently unused. believe are currently unused.
3. SHOULD NOT prefix their parameter names with "X-" or similar 3. SHOULD NOT prefix their parameter names with "X-" or similar
constructs. 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 defining both permanent and provisional spaces, defining both permanent and provisional registries if
registries. appropriate.
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 NOT prohibit parameters with the "X-" prefix or similar 4. SHOULD NOT prohibit parameters with an "X-" prefix or similar
constructs from being registered. constructs from being registered.
5. MUST NOT assume that a parameter with an "X-" prefix or similar 5. MUST NOT stipulate that a parameter with an "X-" prefix or
constructs is unstandardized. similar constructs needs to be understood as unstandardized.
6. MUST NOT assume that a parameter without an "X-" prefix or 6. MUST NOT stipulate that a parameter without an "X-" prefix or
similar constructs is standard. similar constructs needs to be understood as standardized.
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, As a corollary to the recommendation provided under Section 2,
implementations MUST NOT assume that standardized parameters are implementations MUST NOT assume that standardized parameters are
"secure" whereas unstandardized parameters are "insecure", based "secure" whereas unstandardized parameters are "insecure", based
skipping to change at page 6, line 20 skipping to change at page 6, line 5
Randall Gellens, Tony Hansen, Ted Hardie, Joe Hildebrand, Alfred Randall Gellens, Tony Hansen, Ted Hardie, Joe Hildebrand, Alfred
Hoenes, Paul Hoffman, Eric Johnson, Scott Kelly, Scott Kitterman, Hoenes, Paul Hoffman, Eric Johnson, Scott Kelly, Scott Kitterman,
John Klensin, Graham Klyne, Murray Kucherawy, Eliot Lear, John John Klensin, Graham Klyne, Murray Kucherawy, Eliot Lear, John
Levine, Bill McQuillan, Alexey Melnikov, Subramanian Moonesamy, Keith Levine, Bill McQuillan, Alexey Melnikov, Subramanian Moonesamy, Keith
Moore, Ben Niven-Jenkins, Zoltan Ordogh, Tim Petch, Dirk Pranke, Moore, Ben Niven-Jenkins, Zoltan Ordogh, Tim Petch, Dirk Pranke,
Randy Presuhn, Julian Reschke, Dan Romascanu, Doug Royer, Andrew Randy Presuhn, Julian Reschke, Dan Romascanu, Doug Royer, Andrew
Sullivan, Henry Thompson, Martin Thomson, Matthew Wild, Nicolas Sullivan, Henry Thompson, Martin Thomson, Matthew Wild, Nicolas
Williams, Tim Williams, Mykyta Yevstifeyev, and Kurt Zeilenga for Williams, Tim Williams, Mykyta Yevstifeyev, and Kurt Zeilenga for
their feedback. their feedback.
8. References
8.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
8.2. 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.
[RFC691] Harvey, B., "One more try on the FTP", RFC 691, June 1975.
[RFC737] Harrenstien, K., "FTP extension: XSEN", RFC 737,
October 1977.
[RFC743] Harrenstien, K., "FTP extension: XRSQ/XRCP", RFC 743,
December 1977.
[RFC775] Mankins, D., Franklin, D., and A. Owen, "Directory
oriented FTP commands", RFC 775, December 1980.
[RFC822] Crocker, D., "Standard for the format of ARPA Internet
text messages", STD 11, RFC 822, August 1982.
[RFC1123] Braden, R., "Requirements for Internet Hosts - Application
and Support", STD 3, RFC 1123, October 1989.
[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",
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.
[RFC2822] Resnick, P., "Internet Message Format", RFC 2822,
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.
[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
(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.
[RFC5451] Kucherawy, M., "Message Header Field for Indicating
Message Authentication Status", RFC 5451, April 2009.
[RFC5545] Desruisseaux, B., "Internet Calendaring and Scheduling
Core Object Specification (iCalendar)", RFC 5545,
September 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.
Appendix A. Background Appendix A. Background
The beginnings of the "X-" convention can be found in a suggestion The beginnings of the "X-" convention can be found in a suggestion
made by Brian Harvey in 1975 with regard to FTP parameters [RFC691]: made by Brian Harvey in 1975 with regard to FTP parameters [RFC691]:
Thus, FTP servers which care about the distinction between Telnet Thus, FTP servers which care about the distinction between Telnet
print and non-print could implement SRVR N and SRVR T. Ideally the print and non-print could implement SRVR N and SRVR T. Ideally
SRVR parameters should be registered with Jon Postel to avoid the SRVR parameters should be registered with Jon Postel to avoid
conflicts, although it is not a disaster if two sites use the same conflicts, although it is not a disaster if two sites use the same
parameter for different things. I suggest that parameters be parameter for different things. I suggest that parameters be
allowed to be more than one letter, and that an initial letter X allowed to be more than one letter, and that an initial letter X
be used for really local idiosyncracies. be used for really local idiosyncracies [sic].
This "X" prefix was subsequently used in [RFC737], [RFC743], and This "X" prefix was subsequently used in [RFC737], [RFC743], and
[RFC775]. This usage was noted in [RFC1123]: [RFC775]. This usage was noted in [RFC1123]:
FTP allows "experimental" commands, whose names begin with "X". FTP allows "experimental" commands, whose names begin with "X".
If these commands are subsequently adopted as standards, there may If these commands are subsequently adopted as standards, there may
still be existing implementations using the "X" form.... All FTP still be existing implementations using the "X" form.... All FTP
implementations SHOULD recognize both forms of these commands, by implementations SHOULD recognize both forms of these commands, by
simply equating them with extra entries in the command lookup simply equating them with extra entries in the command lookup
table. table.
skipping to change at page 9, line 40 skipping to change at page 6, line 45
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]), Lightweight Directory Access Protocol
application technologies. (LDAP) field names ([RFC4512]), and other 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
skipping to change at page 10, line 15 skipping to change at page 7, line 21
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 implementation-specific use or for they are intended only for implementation-specific use or for
local use 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 unstandardized The primary problem with the "X-" convention is that unstandardized
parameters have a tendency to leak into the protected space of parameters have a tendency to leak into the protected space of
standardized parameters, thus introducing the need for migration from standardized parameters, thus introducing the need for migration from
the "X-" name to a standardized name. Migration, in turn, introduces the "X-" name to a standardized name. Migration, in turn, introduces
interoperability issues (and sometimes security issues) because older interoperability issues (and sometimes security issues) because older
implementations will support only the "X-" name and newer implementations will support only the "X-" name and newer
implementations might support only the standardized name. To implementations might support only the standardized name. To
preserve interoperability, newer implementations simply support the preserve interoperability, newer implementations simply support the
"X-" name forever, which means that the unstandardized name has "X-" name forever, which means that the unstandardized name has
become a de facto standard (thus obviating the need for segregation become a de facto standard (thus obviating the need for segregation
of the name space into standardized and unstandardized areas in the of the name space into standardized and unstandardized areas in the
first place). 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 Appendix A. The HTTP community had the
had the same experience with the "x-gzip" and "x-compress" media same experience with the "x-gzip" and "x-compress" media types, as
types, as noted in [RFC2068]: 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:
For backwards compatibility, this document also describes the For backwards compatibility, this document also describes the
skipping to change at page 11, line 32 skipping to change at page 8, line 36
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 unstandardized parameter Furthermore, often standardization of a unstandardized parameter
leads to subtly different behavior (e.g., the standardized version leads to subtly different behavior (e.g., the standardized version
might have different security properties as a result of security might have different security properties as a result of security
review provided during the standardization process). If implementers review provided during the standardization process). If implementers
treat the old, unstandardized parameter and the new, standardized treat the old, unstandardized parameter and the new, standardized
parameter as equivalent, interoperability and security problems can parameter as equivalent, interoperability and security problems can
ensue. Analysis of unstandardized parameters to detect and correct ensue. Analysis of unstandardized parameters to detect and correct
flaws is in general a good thing and is not intended to be flaws is, in general, a good thing and is not intended to be
discouraged by the lack of distinction in element names. Whenever an discouraged by the lack of distinction in element names. If an
originally unstandardized parameter or protocol element is originally unstandardized parameter or protocol element is
standardized and the new form has differences which affect standardized and the new form has differences that affect
interoperability or security properties, implementations MUST NOT interoperability or security properties, it would be inappropriate
treat the old form as identical to the new form. for implementations to 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. In this case implementation-specific and private- standardized. In this case, implementation-specific and private-
use parameters could at least incorporate the organization's name use parameters could at least incorporate the organization's name
(e.g., "ExampleInc-foo" or, consistent with [RFC4288], (e.g., "ExampleInc-foo" or, consistent with [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 Universally Unique
Identifiers (UUIDs) [RFC4122].
2. When parameter names might have significant meaning. This case 2. When parameter names might have significant meaning. This case
too is rare, since implementers can almost always find a synonym too is rare, since implementers can almost always find a synonym
for an existing term (e.g., "urgency" instead of "priority") or for an existing term (e.g., "urgency" instead of "priority") or
simply invent a more creative name (e.g., "get-it-there-fast"). simply invent a more creative name (e.g., "get-it-there-fast").
The existence of multiple similarly-named paramaters can be The existence of multiple similarly named parameters can be
confusing, but this is true regardless if there is an attempt to confusing, but this is true regardless if there is an attempt to
segregate standardized and unstandardized (e.g., "X-Priority" can segregate standardized and unstandardized parameters (e.g.,
be confused with "Urgency"). "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). In this case it can be more efficient to for language tags). In this case, it can be more efficient to
assign numbers instead of human-readable names (e.g., as in assign numbers instead of human-readable names (e.g., as in
[RFC2939] for DCHP options) and to leave a certain numeric range [RFC2939] for DHCP options) and to leave a certain numeric range
for implementation-specific extensions or private use (e.g., as for implementation-specific extensions or private use (e.g., as
with the codec numbers used with the Session Description Protocol with the codec numbers used with the Session 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 might mistake one parameter for another parameter 1. Implementers might mistake one parameter for another parameter
that has a similar name; a rigid distinction such as an "X-" that has a similar name; a rigid distinction such as an "X-"
prefix can make this clear. However, in practice implementers prefix can make this clear. However, in practice, implementers
are forced to blur the distinction (e.g., by treating "X-foo" as are forced to blur the distinction (e.g., by treating "X-foo" as
a de facto standard) and so it inevitably becomes meaningless. a de facto standard), so it inevitably becomes 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
standardized parameter "foo" and a unstandardized parameter "foo" standardized parameter "foo" and a unstandardized parameter "foo"
to exist simultaneously. However, names are almost always cheap, to exist simultaneously. However, names are almost always cheap,
so an experimental, implementation-specific, or private-use name so an experimental, implementation-specific, or private-use name
of "foo" does not prevent a standards development organization of "foo" does not prevent a standards development organization
from issuing a similarly creative name such as "bar". from 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
also useful for experimental parameters. However, BCP 82 also useful for experimental parameters. However, BCP 82
addresses the need for protocol numbers when the pool of such addresses the need for protocol numbers when the pool of such
numbers is strictly limited (e.g., DHCP options) or when a number numbers is strictly limited (e.g., DHCP options) or when a number
is absolutely required even for purely experimental purposes is absolutely required even for purely experimental purposes
(e.g., the Protocol field of the IP header). In almost all (e.g., the Protocol field of the IP header). In almost all
application protocols that make use of protocol parameters application protocols that make use of protocol parameters
(including email headers, media types, HTTP headers, vCard (including email headers, media types, HTTP headers, vCard
parameters and properties, URNs, and LDAP field names), the name parameters and properties, URNs, and LDAP field names), the name
space is not limited or constrained in any way, so there is no 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 need to assign a block of names for private use or experimental
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
standardized area and a unstandardized area has few if any benefits, standardized area and a unstandardized area has few, if any, benefits
and has at least one significant cost in terms of interoperability. and has at least one significant cost in terms of interoperability.
References
Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
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.
[RFC691] Harvey, B., "One more try on the FTP", RFC 691, June 1975.
[RFC737] Harrenstien, K., "FTP extension: XSEN", RFC 737,
October 1977.
[RFC743] Harrenstien, K., "FTP extension: XRSQ/XRCP", RFC 743,
December 1977.
[RFC775] Mankins, D., Franklin, D., and A. Owen, "Directory
oriented FTP commands", RFC 775, December 1980.
[RFC822] Crocker, D., "Standard for the format of ARPA Internet
text messages", STD 11, RFC 822, August 1982.
[RFC1123] Braden, R., "Requirements for Internet Hosts - Application
and Support", STD 3, RFC 1123, October 1989.
[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",
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.
[RFC2822] Resnick, P., "Internet Message Format", RFC 2822,
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.
[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
(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.
[RFC5451] Kucherawy, M., "Message Header Field for Indicating
Message Authentication Status", RFC 5451, April 2009.
[RFC5545] Desruisseaux, B., "Internet Calendaring and Scheduling
Core Object Specification (iCalendar)", RFC 5545,
September 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.
Authors' Addresses Authors' Addresses
Peter Saint-Andre Peter Saint-Andre
Cisco Systems, Inc. Cisco Systems, Inc.
1899 Wynkoop 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 Dave Crocker
Brandenburg InternetWorking Brandenburg InternetWorking
675 Spruce Dr. 675 Spruce Dr.
Sunnyvale Sunnyvale, CA
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 Rackspace
Email: mnot@mnot.net EMail: mnot@mnot.net
URI: http://www.mnot.net URI: http://www.mnot.net
 End of changes. 42 change blocks. 
205 lines changed or deleted 203 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/