draft-ietf-appsawg-xdash-04.txt   draft-ietf-appsawg-xdash-05.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: September 13, 2012 Brandenburg InternetWorking Expires: October 11, 2012 Brandenburg InternetWorking
M. Nottingham M. Nottingham
Rackspace Rackspace
March 12, 2012 April 9, 2012
Deprecating the X- Prefix and Similar Constructs in Application Deprecating the X- Prefix and Similar Constructs in Application
Protocols Protocols
draft-ietf-appsawg-xdash-04 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 "standard" and "non-standard" have often distinguished between standardized and unstandardized
parameters by prefixing the names of "non-standard" 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 the names of newly-defined textual deprecates the convention for newly-defined parameters with textual
parameters 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 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 September 13, 2012. This Internet-Draft will expire on October 11, 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 . . 4
3. Recommendations for Creators of New Parameters . . . . . . . . 4 3. Recommendations for Creators of New Parameters . . . . . . . . 4
4. Recommendations for Protocol Designers . . . . . . . . . . . . 4 4. Recommendations for Protocol Designers . . . . . . . . . . . . 5
5. Security Considerations . . . . . . . . . . . . . . . . . . . 4 5. Security Considerations . . . . . . . . . . . . . . . . . . . 5
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 5 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 5 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6
8.1. Normative References . . . . . . . . . . . . . . . . . . . 5 8.1. Normative References . . . . . . . . . . . . . . . . . . . 6
8.2. Informative References . . . . . . . . . . . . . . . . . . 5 8.2. Informative References . . . . . . . . . . . . . . . . . . 6
Appendix A. Background . . . . . . . . . . . . . . . . . . . . . 8 Appendix A. Background . . . . . . . . . . . . . . . . . . . . . 8
Appendix B. Analysis . . . . . . . . . . . . . . . . . . . . . . 9 Appendix B. Analysis . . . . . . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13
1. Introduction 1. Introduction
Many application protocols use parameters with textual names to Many application protocols use parameters with textual (as opposed to
identify data (media types, header fields in Internet mail messages numerical) names to identify data (media types, header fields in
and HTTP requests, vCard parameters and properties, etc.). Internet mail messages and HTTP requests, vCard parameters and
Historically, designers and implementers of application protocols properties, etc.). Historically, designers and implementers of
have often distinguished between "standard" and "non-standard" application protocols have often distinguished between standardized
parameters by prefixing the names of "non-standard" parameters with and unstandardized parameters by prefixing the names of
the string "X-" or similar constructs (e.g., "x."), where the "X" is unstandardized parameters with the string "X-" or similar constructs
commonly understood to stand for "eXperimental" or "eXtension". That (e.g., "x."), where the "X" is commonly understood to stand for
is, instead of just identifying the data, the name also embedded the "eXperimental" or "eXtension".
status of the name as "non-standard" into the name itself.
Although in theory the "X-" convention was a good way to avoid Under this convention, the name of a parameter not only identified
collisions (and attendant interoperability problems) between standard the data, but also embedded the status of the parameter into the name
parameters and non-standard parameters, in practice the benefits have itself: a parameter defined in a specification produced by a
been outweighed by the costs associated with the leakage of non- recognized standards development organization (or registered
standard parameters into the standards space. Therefore this according to processes defined in such a specification) did not start
document deprecates the "X-" convention for named parameters in with "X-" or similar constructs, whereas a parameter defined outside
application protocols and makes specific recommendations about how to such a specification or process started with "X-" or similar
proceed in a world without the distinction between standard and non- constructs.
standard parameters. Note that this document covers only parameters
with textual names, not parameters that are expressed as numbers. In
addition, this document does not recommend against the practice of
private, local, preliminary, experimental, or implementation-specific
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 As explained more fully under Appendix A, this convention was
"X-" convention, and Appendix B for the reasoning that led to the encouraged for many years in application protocols such as file
recommendations in this document. transfer, email, and the World Wide Web. In particular, it was
codified for email by [RFC822] (via the distinction between
"Extension-fields" and "user-defined-fields"), but then removed by
[RFC2822] based on implementation and deployment experience. A
similar progression occurred for SIP technologies with regard to the
"P-" header, as explained in [RFC5727]. The reasoning behind those
changes is explored under Appendix B.
In short, although in theory the "X-" convention was a good way to
avoid collisions (and attendant interoperability problems) between
standardized parameters and unstandardized parameters, in practice
the benefits have been outweighed by the costs associated with the
leakage of unstandardized parameters into the standards space.
This document generalizes from the experience of the email and SIP
communities by doing the following:
1. Deprecates the "X-" convention for newly-defined parameters in
application protocols, even where that convention was only
implicit instead of being codified in a protocol specification
(as was done for email in [RFC822]).
2. Makes specific recommendations about how to proceed in a world
without the distinction between standardized and unstandardized
parameters (although only for parameters with textual names, not
parameters that are expressed as numbers, which are out of
scope).
3. Does not recommend against the practice of private, local,
preliminary, experimental, or implementation-specific parameters,
only against the use of "X-" and similar constructs in the names
of such parameters.
4. Makes no recommendation as to whether existing "X-" parameters
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
parameters.
5. Does not override existing specifications that legislate the use
of "X-" for particular application protocols (e.g., the "x-name"
token in [RFC5545]); this is a matter for the designers of those
protocols.
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
Implementations of application protocols MUST NOT programatically Implementations of application protocols MUST NOT make any
discriminate between "standard" and "non-standard" parameters based assumptions about the status of a parameter, nor take automatic
solely on the names of such parameters (i.e., based solely on whether action regarding a parameter, based solely on the presence or absence
the name begins with 'x-' or a similar string of characters). 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 used across multiple
implementations. implementations.
2. SHOULD employ meaningful names that they have reason to believe 2. SHOULD employ meaningful parameter names that they have reason to
are currently unused (without the "X-" prefix or similar believe are currently unused.
constructs).
3. SHOULD NOT prefix their parameter names with "X-" 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 defining 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 NOT prohibit parameters with the "X-" prefix or similar 4. SHOULD NOT prohibit parameters with the "X-" prefix or similar
constructs from being registered with the IANA. constructs from being registered.
5. MUST NOT assume that a parameter with an "X-" prefix or similar 5. MUST NOT assume that a parameter with an "X-" prefix or similar
constructs is non-standard. constructs is unstandardized.
6. MUST NOT assume that a parameter without an "X-" prefix or 6. MUST NOT assume that a parameter without an "X-" prefix or
similar constructs is 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, As a corollary to the recommendation provided under Section 2,
implementations MUST NOT assume that "standard" parameters are implementations MUST NOT assume that standardized parameters are
"secure" whereas "non-standard" parameters are "insecure", based "secure" whereas unstandardized parameters are "insecure", based
solely on the names of such parameters. 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, Ralph Droms,
Frank Ellermann, J.D. Falk, Ned Freed, Tony Finch, Randall Gellens, Martin Duerst, Frank Ellermann, J.D. Falk, Ned Freed, Tony Finch,
Tony Hansen, Ted Hardie, Joe Hildebrand, Alfred Hoenes, Paul Hoffman, Randall Gellens, Tony Hansen, Ted Hardie, Joe Hildebrand, Alfred
Eric Johnson, Scott Kelly, Scott Kitterman, John Klensin, Graham Hoenes, Paul Hoffman, Eric Johnson, Scott Kelly, Scott Kitterman,
Klyne, Murray Kucherawy, Eliot Lear, John Levine, Bill McQuillan, John Klensin, Graham Klyne, Murray Kucherawy, Eliot Lear, John
Alexey Melnikov, Subramanian Moonesamy, Keith Moore, Ben Niven- Levine, Bill McQuillan, Alexey Melnikov, Subramanian Moonesamy, Keith
Jenkins, Zoltan Ordogh, Tim Petch, Dirk Pranke, Randy Presuhn, Julian Moore, Ben Niven-Jenkins, Zoltan Ordogh, Tim Petch, Dirk Pranke,
Reschke, Doug Royer, Andrew Sullivan, Martin Thomson, Matthew Wild, Randy Presuhn, Julian Reschke, Dan Romascanu, Doug Royer, Andrew
Nicolas Williams, Tim Williams, Mykyta Yevstifeyev, and Kurt Zeilenga Sullivan, Henry Thompson, Martin Thomson, Matthew Wild, Nicolas
for their feedback. 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 7, line 46 skipping to change at page 8, line 33
[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.
[RFC5451] Kucherawy, M., "Message Header Field for Indicating [RFC5451] Kucherawy, M., "Message Header Field for Indicating
Message Authentication Status", RFC 5451, April 2009. 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 [RFC5646] Phillips, A. and M. Davis, "Tags for Identifying
Languages", BCP 47, RFC 5646, September 2009. Languages", BCP 47, RFC 5646, September 2009.
[RFC5727] Peterson, J., Jennings, C., and R. Sparks, "Change Process [RFC5727] Peterson, J., Jennings, C., and R. Sparks, "Change Process
for the Session Initiation Protocol (SIP) and the Real- for the Session Initiation Protocol (SIP) and the Real-
time Applications and Infrastructure Area", BCP 67, time Applications and Infrastructure Area", BCP 67,
RFC 5727, March 2010. RFC 5727, March 2010.
Appendix A. Background Appendix A. Background
skipping to change at page 9, line 31 skipping to change at page 10, line 23
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 unstandardized
parameters have a tendency to leak 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 standardized parameters, thus introducing the need for migration from
the need for migration from the "X-" name to the standard name. the "X-" name to a standardized name. Migration, in turn, introduces
Migration, in turn, introduces interoperability issues (and sometimes interoperability issues (and sometimes security issues) because older
security issues) because older implementations will support only the implementations will support only the "X-" name and newer
"X-" name and newer implementations might support only the standard implementations might support only the standardized name. To
name. To preserve interoperability, newer implementations simply preserve interoperability, newer implementations simply support the
support the "X-" name forever, which means that the non-standard name "X-" name forever, which means that the unstandardized name has
has become a de facto standard (thus obviating the need for become a de facto standard (thus obviating the need for segregation
segregation of the name space into "standard" and "non-standard" of the name space into standardized and unstandardized areas in the
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 the previous section. The HTTP community
had the same experience with the "x-gzip" and "x-compress" 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:
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 standardized and unstandardized 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 explained in [RFC4288]: [RFC4288]. 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 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 leads Furthermore, often standardization of a unstandardized parameter
to subtly different behavior (e.g., the standard version might have leads to subtly different behavior (e.g., the standardized version
different security properties as a result of security review provided might have different security properties as a result of security
during the standardization process). If implementers treat the old, review provided during the standardization process). If implementers
non-standard parameter and the new, standard parameter as equivalent, treat the old, unstandardized parameter and the new, standardized
interoperability and security problems can ensue. Analysis of non- parameter as equivalent, interoperability and security problems can
standard parameters to detect and correct flaws is in general a good ensue. Analysis of unstandardized parameters to detect and correct
thing and is not intended to be discouraged by the lack of flaws is in general a good thing and is not intended to be
distinction in element names. Whenever an originally non-standard discouraged by the lack of distinction in element names. Whenever an
parameter or protocol element is standardized and the new form has originally unstandardized parameter or protocol element is
differences which affect interoperability or security properties, standardized and the new form has differences which affect
implementations MUST NOT treat the old form as identical to the new interoperability or security properties, implementations MUST NOT
form. 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
skipping to change at page 11, line 21 skipping to change at page 12, line 12
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. 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 paramaters 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 standard and non-standard (e.g., "X-Priority" can be segregate standardized and unstandardized (e.g., "X-Priority" can
confused with "Urgency"). 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 DCHP 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) and 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
standard parameter "foo" and a non-standard parameter "foo" to standardized parameter "foo" and a unstandardized parameter "foo"
exist simultaneously. However, names are almost always cheap, so to exist simultaneously. However, names are almost always cheap,
an experimental, implementation-specific, or private-use name of so an experimental, implementation-specific, or private-use name
"foo" does not prevent a standards development organization from of "foo" does not prevent a standards development organization
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
standard area and a non-standard area has few if any benefits, and standardized area and a unstandardized area has few if any benefits,
has at least one significant cost in terms of interoperability. and 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 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
 End of changes. 28 change blocks. 
102 lines changed or deleted 141 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/