< draft-ietf-appsawg-xdash-02.txt   draft-ietf-appsawg-xdash-03.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: April 26, 2012 Brandenburg InternetWorking Expires: August 16, 2012 Brandenburg InternetWorking
M. Nottingham M. Nottingham
Rackspace Rackspace
October 24, 2011 February 13, 2012
Deprecating Use of the "X-" Prefix in Application Protocols Deprecating Use of the "X-" Prefix in Application Protocols
draft-ietf-appsawg-xdash-02 draft-ietf-appsawg-xdash-03
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 textual parameters in application protocols.
Status of this Memo Status of this Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on April 26, 2012. This Internet-Draft will expire on August 16, 2012.
Copyright Notice Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the Copyright (c) 2012 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Recommendations for Implementers of Application Protocols . . 3 2. Recommendations for Implementers of Application Protocols . . 3
3. Recommendations for Creators of New Parameters . . . . . . . . 3 3. Recommendations for Creators of New Parameters . . . . . . . . 3
4. Recommendations for Protocol Designers . . . . . . . . . . . . 4 4. Recommendations for Protocol Designers . . . . . . . . . . . . 4
5. Security Considerations . . . . . . . . . . . . . . . . . . . 4 5. Security Considerations . . . . . . . . . . . . . . . . . . . 4
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 5 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 5
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 5 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 5
8.1. Normative References . . . . . . . . . . . . . . . . . . . 5 8.1. Normative References . . . . . . . . . . . . . . . . . . . 5
8.2. Informative References . . . . . . . . . . . . . . . . . . 5 8.2. Informative References . . . . . . . . . . . . . . . . . . 5
Appendix A. Background . . . . . . . . . . . . . . . . . . . . . 7 Appendix A. Background . . . . . . . . . . . . . . . . . . . . . 7
Appendix B. Analysis . . . . . . . . . . . . . . . . . . . . . . 9 Appendix B. Analysis . . . . . . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11
1. Introduction 1. Introduction
Many application protocols use named parameters to identify data Many application protocols use parameters with textual names to
(media types, header fields in Internet mail messages and HTTP identify data (media types, header fields in Internet mail messages
requests, vCard parameters and properties, etc.). Historically, and HTTP requests, vCard parameters and properties, etc.).
designers and implementers of application protocols have often Historically, designers and implementers of application protocols
distinguished between "standard" and "non-standard" parameters by have often distinguished between "standard" and "non-standard"
prefixing the latter with the string "X-" or similar constructions parameters by prefixing the latter with the string "X-" or similar
(e.g., "x."), where the "X" is commonly understood to stand for constructions (e.g., "x."), where the "X" is commonly understood to
"eXperimental" or "eXtension". stand for "eXperimental" or "eXtension".
Although in theory the "X-" convention was a good way to avoid Although in theory the "X-" convention was a good way to avoid
collisions (and attendant interoperability problems) between standard collisions (and attendant interoperability problems) between standard
parameters and non-standard parameters, in practice the benefits have parameters and non-standard parameters, in practice the benefits have
been outweighed by the costs associated with the leakage of non- been outweighed by the costs associated with the leakage of non-
standard parameters into the standards space. Therefore this standard parameters into the standards space. Therefore this
document deprecates the "X-" convention for most application document deprecates the "X-" convention for named parameters in
protocols and makes specific recommendations about how to proceed in application protocols and makes specific recommendations about how to
a world without the distinction between standard and non-standard proceed in a world without the distinction between standard and non-
parameters. standard parameters. Note that this document covers only parameters
with textual names, not parameters that are expressed as numbers. In
addition, this document makes no recommendation as to whether
existing "X-" parameters ought to remain in use or be migrated to a
format without the "X-".
See Appendix A for background information about the history of the See Appendix A for background information about the history of the
"X-" convention, and Appendix B for the reasoning that led to the "X-" convention, and Appendix B for the reasoning that led to the
recommendations in this document. recommendations in this document.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in "OPTIONAL" in this document are to be interpreted as described in
[RFC2119]. [RFC2119].
skipping to change at page 4, line 5 skipping to change at page 4, line 9
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 but currently unused names (without the 2. SHOULD employ meaningful names that they have reason to believe
"X-" prefix). are currently unused (without the "X-" prefix).
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:
skipping to change at page 5, line 15 skipping to change at page 5, line 20
defined in this document. defined in this document.
7. Acknowledgements 7. Acknowledgements
Thanks to Claudio Allocchio, Adam Barth, Nathaniel Borenstein, Eric Thanks to Claudio Allocchio, Adam Barth, Nathaniel Borenstein, Eric
Burger, Stuart Cheshire, Al Constanzo, Dave Cridland, Martin Duerst, Burger, Stuart Cheshire, Al Constanzo, Dave Cridland, Martin Duerst,
Frank Ellermann, J.D. Falk, Ned Freed, Tony Finch, Randall Gellens, Frank Ellermann, J.D. Falk, Ned Freed, Tony Finch, Randall Gellens,
Tony Hansen, Ted Hardie, Joe Hildebrand, Alfred Hoenes, Paul Hoffman, Tony Hansen, Ted Hardie, Joe Hildebrand, Alfred Hoenes, Paul Hoffman,
Eric Johnson, John Klensin, Graham Klyne, Murray Kucherawy, Eliot Eric Johnson, John Klensin, Graham Klyne, Murray Kucherawy, Eliot
Lear, John Levine, Bill McQuillan, Alexey Melnikov, Subramanian Lear, John Levine, Bill McQuillan, Alexey Melnikov, Subramanian
Moonesamy, Keith Moore, Ben Niven-Jenkins, Dirk Pranke, Randy Moonesamy, Keith Moore, Ben Niven-Jenkins, Zoltan Ordogh, Tim Petch,
Presuhn, Julian Reschke, Doug Royer, Andrew Sullivan, Martin Thomson, Dirk Pranke, Randy Presuhn, Julian Reschke, Doug Royer, Andrew
Matthew Wild, Nicolas Williams, Tim Williams, Mykyta Yevstifeyev, and Sullivan, Martin Thomson, Matthew Wild, Nicolas Williams, Tim
Kurt Zeilenga for their feedback. 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
 End of changes. 11 change blocks. 
25 lines changed or deleted 29 lines changed or added

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