Deprecating the "X-" Prefix and Similar Constructs in Application Protocols
RFC 6648
Document | Type |
RFC - Best Current Practice
(June 2012; No errata)
Also known as BCP 178
|
|
---|---|---|---|
Authors | Peter Saint-Andre , Dave Crocker , Mark Nottingham | ||
Last updated | 2015-10-14 | ||
Replaces | draft-saintandre-xdash, draft-saintandre-xdash-considered-harmful | ||
Stream | IETF | ||
Formats | plain text html pdf htmlized bibtex | ||
Reviews | |||
Stream | WG state | Submitted to IESG for Publication | |
Document shepherd | Alexey Melnikov | ||
Shepherd write-up | Show (last changed 2012-02-22) | ||
IESG | IESG state | RFC 6648 (Best Current Practice) | |
Consensus Boilerplate | Unknown | ||
Telechat date | |||
Responsible AD | Pete Resnick | ||
Send notices to | (None) |
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 2012 Copyright 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. As explained more fully under Appendix A, this convention was encouraged for many years in application protocols such as file 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 byShow full document text