BEST CURRENT PRACTICE

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 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 [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, including new parameters for established protocols. This change applies even where the "X-" convention was only implicit, and not explicitly provided, such 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 the scope of this document). 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. Saint-Andre, et al. Best Current Practice [Page 3]

RFC 6648 Deprecating "X-" June 2012 RFC5545]); this is a matter for the designers of those protocols. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 2 . Recommendations for Implementers of Application Protocols 3 . Recommendations for Creators of New Parameters Appendix B for examples). 4 . Recommendations for Protocol Designers Saint-Andre, et al. Best Current Practice [Page 4]

RFC 6648 Deprecating "X-" June 2012 5 . Security Considerations Appendix B for further discussion). As a corollary to the recommendation provided under Section 2, implementations MUST NOT assume that standardized parameters are "secure" whereas unstandardized parameters are "insecure", based solely on the names of such parameters. 6 . IANA Considerations 7 . Acknowledgements Saint-Andre, et al. Best Current Practice [Page 5]

RFC 6648 Deprecating "X-" June 2012 Appendix A . Background RFC691]: Thus, FTP servers which care about the distinction between Telnet print and non-print could implement SRVR N and SRVR T. Ideally the SRVR parameters should be registered with Jon Postel to avoid conflicts, although it is not a disaster if two sites use the same parameter for different things. I suggest that parameters be allowed to be more than one letter, and that an initial letter X be used for really local idiosyncracies [sic]. This "X" prefix was subsequently used in [RFC737], [RFC743], and [RFC775]. This usage was noted in [RFC1123]: FTP allows "experimental" commands, whose names begin with "X". If these commands are subsequently adopted as standards, there may still be existing implementations using the "X" form.... All FTP implementations SHOULD recognize both forms of these commands, by simply equating them with extra entries in the command lookup table. The "X-" convention has been used for email header fields since at least the publication of [RFC822] in 1982, which distinguished between "Extension-fields" and "user-defined-fields" as follows: The prefatory string "X-" will never be used in the names of Extension-fields. This provides user-defined fields with a protected set of names. That rule was restated by [RFC1154] as follows: Keywords beginning with "X-" are permanently reserved to implementation-specific use. No standard registered encoding keyword will ever begin with "X-". This convention continued with various specifications for media types ([RFC2045], [RFC2046], [RFC2047]), HTTP headers ([RFC2068], [RFC2616]), vCard parameters and properties ([RFC2426]), Uniform Resource Names ([RFC3406]), Lightweight Directory Access Protocol (LDAP) field names ([RFC4512]), and other application technologies. However, use of the "X-" prefix in email headers was effectively deprecated between the publication of [RFC822] in 1982 and the publication of [RFC2822] in 2001 by removing the distinction between the "extension-field" construct and the "user-defined-field" Saint-Andre, et al. Best Current Practice [Page 6]

RFC 6648 Deprecating "X-" June 2012 RFC3427] was obsoleted by [RFC5727]). Despite the fact that parameters containing the "X-" string have been effectively deprecated in email headers, they continue to be used in a wide variety of application protocols. The two primary situations motivating such use are: 1. Experiments that are intended to possibly be standardized in the future, if they are successful. 2. Extensions that are intended to never be standardized because they are intended only for implementation-specific use or for local use on private networks. Use of this naming convention is not mandated by the Internet Standards Process [BCP9] or IANA registration rules [BCP26]. Rather, it is an individual choice by each specification that references the convention or each administrative process that chooses to use it. In particular, some Standards Track RFCs have interpreted the convention in a normative way (e.g., [RFC822] and [RFC5451]). Appendix B . Analysis RFC1123] in Appendix A. The HTTP community had the same experience with the "x-gzip" and "x-compress" media types, as noted in [RFC2068]: For compatibility with previous implementations of HTTP, applications should consider "x-gzip" and "x-compress" to be equivalent to "gzip" and "compress" respectively. Saint-Andre, et al. Best Current Practice [Page 7]

RFC 6648 Deprecating "X-" June 2012 RFC5064], which defined the "Archived-At" message header field but also found it necessary to define and register the "X-Archived-At" field: For backwards compatibility, this document also describes the X-Archived-At header field, a precursor of the Archived-At header field. The X-Archived-At header field MAY also be parsed, but SHOULD NOT be generated. One of the original reasons for segregation of name spaces into standardized and unstandardized areas was the perceived difficulty of registering names. However, the solution to that problem has been simpler registration rules, such as those provided by [RFC3864] and [RFC4288]. As explained in [RFC4288]: [W]ith the simplified registration procedures described above for vendor and personal trees, it should rarely, if ever, be necessary to use unregistered experimental types. Therefore, use of both "x-" and "x." forms is discouraged. For some name spaces, another helpful practice has been the establishment of separate registries for permanent names and provisional names, as in [RFC4395]. Furthermore, often standardization of a unstandardized parameter leads to subtly different behavior (e.g., the standardized version might have different security properties as a result of security review provided during the standardization process). If implementers treat the old, unstandardized parameter and the new, standardized parameter as equivalent, interoperability and security problems can ensue. Analysis of unstandardized parameters to detect and correct flaws is, in general, a good thing and is not intended to be discouraged by the lack of distinction in element names. If an originally unstandardized parameter or protocol element is standardized and the new form has differences that affect interoperability or security properties, it would be inappropriate for implementations to treat the old form as identical to the new form. For similar considerations with regard to the "P-" convention in the Session Initiation Protocol, see [RFC5727]. Saint-Andre, et al. Best Current Practice [Page 8]

RFC 6648 Deprecating "X-" June 2012 RFC4288], "VND.ExampleInc.foo") or primary domain name (e.g., "com.example.foo" or a Uniform Resource Identifier [RFC3986] such as "http://example.com/foo"). In rare cases, truly experimental parameters could be given meaningless names such as nonsense words, the output of a hash function, or Universally Unique Identifiers (UUIDs) [RFC4122]. 2. When parameter names might have significant meaning. This case too is rare, since implementers can almost always find a synonym for an existing term (e.g., "urgency" instead of "priority") or simply invent a more creative name (e.g., "get-it-there-fast"). The existence of multiple similarly named parameters can be confusing, but this is true regardless if there is an attempt to segregate standardized and unstandardized parameters (e.g., "X-Priority" can be confused with "Urgency"). 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 assign numbers instead of human-readable names (e.g., as in [RFC2939] for DHCP options) and to leave a certain numeric range for implementation-specific extensions or private use (e.g., as with the codec numbers used with the Session Description Protocol [RFC4566]). There are three primary objections to deprecating the "X-" convention as a best practice for application protocols: 1. Implementers might mistake one parameter for another parameter that has a similar name; a rigid distinction such as an "X-" prefix can make this clear. However, in practice, implementers are forced to blur the distinction (e.g., by treating "X-foo" as a de facto standard), so it inevitably becomes meaningless. 2. Collisions are undesirable, and it would be bad for both a standardized parameter "foo" and a unstandardized parameter "foo" to exist simultaneously. However, names are almost always cheap, so an experimental, implementation-specific, or private-use name of "foo" does not prevent a standards development organization from issuing a similarly creative name such as "bar". Saint-Andre, et al. Best Current Practice [Page 9]

RFC 6648 Deprecating "X-" June 2012 http://bbiw.net Mark Nottingham Rackspace EMail: mnot@mnot.net URI: http://www.mnot.net Saint-Andre, et al. Best Current Practice [Page 13]