Deprecating the "X-" Prefix and Similar Constructs in Application Protocols
RFC 6648

• Status
• IESG evaluation record
• IESG writeups
• Email expansions
• History

• Versions
• 03
• 04
• 05

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 by