Internet Engineering Task Force (IETF) P. Saint-Andre
Request for Comments: 6648 Cisco Systems, Inc.
BCP: 178 D. Crocker
Category: Best Current Practice Brandenburg InternetWorking
ISSN: 2070-1721 M. Nottingham
Rackspace
June 2012
Deprecating the "X-" Prefix and Similar Constructs
in Application Protocols
Abstract
Historically, designers and implementers of application protocols
have often distinguished between standardized and unstandardized
parameters by prefixing the names of unstandardized parameters with
the string "X-" or similar constructs. In practice, that convention
causes more problems than it solves. Therefore, this document
deprecates the convention for newly defined parameters with textual
(as opposed to numerical) names in application protocols.
Status of This Memo
This memo documents an Internet Best Current Practice.
This document is a product of the Internet Engineering Task Force
(IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by the
Internet Engineering Steering Group (IESG). Further information on
BCPs is available in Section 2 of RFC 5741.
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.
Saint-Andre, et al. Best Current Practice [Page 1]RFC 6648 Deprecating "X-" June 2012Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction ....................................................2
2. Recommendations for Implementers of Application Protocols .......4
3. Recommendations for Creators of New Parameters ..................4
4. Recommendations for Protocol Designers ..........................4
5. Security Considerations .........................................5
6. IANA Considerations .............................................5
7. Acknowledgements ................................................5
Appendix A. Background ............................................6
Appendix B. Analysis ..............................................7
References ........................................................10
Normative References ...........................................10
Informative References .........................................10
1. Introduction
Many application protocols use parameters with textual (as opposed to
numerical) names to identify data (media types, header fields in
Internet mail messages and HTTP requests, vCard parameters and
properties, etc.). Historically, designers and implementers of
application protocols have often distinguished between standardized
and unstandardized parameters by prefixing the names of
unstandardized parameters with the string "X-" or similar constructs
(e.g., "x."), where the "X" is commonly understood to stand for
"eXperimental" or "eXtension".
Under this convention, the name of a parameter not only identified
the data, but also embedded the status of the parameter into the name
itself: a parameter defined in a specification produced by a
recognized standards development organization (or registered
according to processes defined in such a specification) did not start
Saint-Andre, et al. Best Current Practice [Page 2]RFC 6648 Deprecating "X-" June 2012
with "X-" or similar constructs, whereas a parameter defined outside
such a specification or process started with "X-" or similar
constructs.
datatracker.ietf.org