RFC 6648

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

📅 published June 2012, from ietf

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

okay so this is RFC 6648, filed as BCP 178 🎀 (a Best Current Practice, so it's the IETF's official "please do this" guide, not a single protocol). It's from June 2012 with ISSN 2070-1721, and it was written by P. Saint-Andre (Cisco Systems, Inc.), D. Crocker (Brandenburg InternetWorking), and M. Nottingham (Rackspace). It's a product of the IETF. The title block doesn't list anything it obsoletes or updates, so it's not replacing or changing any other RFC 🦋

Abstract ✨

Historically, designers and implementers of application protocols have slapped an X- prefix (or something similar) on parameter names to show they weren't standardized. Honestly? That habit causes more problems than it fixes 😭 So this document deprecates the convention for newly defined parameters with textual (not 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.

Info about the current status of this document, any errata, and how to send feedback on it lives at http://www.rfc-editor.org/info/rfc6648.

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) as in effect on the date of publication. Please read these carefully, because they spell out your rights and restrictions for 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 they're provided without warranty as described in the Simplified BSD License. Bestie, that part is important 🫶

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 ✨

Lots of application protocols use parameters with textual (not numerical) names to label data. Think media types, header fields in Internet mail messages and HTTP requests, vCard parameters and properties, and more 🍓 Historically, designers and implementers told standardized and unstandardized parameters apart by putting X- (or something like x.) in front of the unstandardized names. The "X" was usually understood to mean "eXperimental" or "eXtension" 🌈

Under this convention, the name didn't just identify the data. It also smuggled the parameter's status right into the name 👀 A parameter defined in a spec from a recognized standards development organization (or registered through a process defined in such a spec) didn't start with "X-" or a similar construct. A parameter defined outside such a spec or process did.

Appendix A digs into this more, but the habit was encouraged for years in application protocols like file transfer, email, and the World Wide Web. Email actually codified it in [RFC822] (through the difference between "Extension-fields" and "user-defined-fields"), and then [RFC2822] removed it based on implementation and deployment experience. SIP had a similar glow-up with the "P-" header, as explained in [RFC5727]. Appendix B covers why those changes happened 💅

So, in theory, "X-" was a good way to avoid collisions (and the interoperability problems that come with them) between standardized and unstandardized parameters. In practice, though, the costs outweighed the benefits, because unstandardized parameters kept leaking into the standards space 💀

This document generalizes from what the email and SIP communities learned 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. This is only for parameters with textual names, not parameters 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. It's only against using "X-" and similar constructs in the names of those parameters 🌸
  4. Makes no recommendation about whether existing "X-" parameters should stay in use or be migrated to a format without the "X-". That's a call for the creators or maintainers of those parameters.
  5. Does not override existing specifications that require the use of "X-" for particular application protocols (for example, the x-name token in [RFC5545]). That's a matter for the designers of those protocols.

Quick note on the key words 🔑 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].

Appendix A. Background 🌸

okay so the "X-" convention has a long history, bestie 🧚. It goes all the way back to a suggestion Brian Harvey made in 1975 about FTP parameters [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].

The "X" prefix then showed up in [RFC737], [RFC743], and [RFC775] 💜. [RFC1123] noticed it and wrote:

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-" thing was also in email headers way back in [RFC822] from 1982, which split things into "Extension-fields" and "user-defined-fields" like this:

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.

[RFC1154] restated the rule as:

Keywords beginning with "X-" are permanently reserved to implementation-specific use. No standard registered encoding keyword will ever begin with "X-".

It kept going into all sorts of specs ✨: 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. iconic longevity 👑

Here's the plot twist 😭: the X- prefix in email headers was effectively deprecated between [RFC822] in 1982 and [RFC2822] in 2001, because the distinction between the "extension-field" construct and the "user-defined-field" construct got removed. The same kind of change happened with Session Initiation Protocol "P-" headers when [RFC3427] was obsoleted by [RFC5727] 🙈.

Even though parameters with the "X-" string got deprecated in email headers, they're still everywhere in a wide variety of application protocols 💅. The two main reasons people use them 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 isn't required by the Internet Standards Process [BCP9] or IANA registration rules [BCP26]. It's an individual choice by each specification that references the convention, or each administrative process that chooses to use it 🎀. Some Standards Track RFCs have even treated the convention in a normative way (e.g., [RFC822] and [RFC5451]), which is a whole vibe 🔥.

Appendix B. Analysis 🦋

The big problem with the "X-" convention is that unstandardized parameters have a tendency to leak into the protected space of standardized parameters 😩. That creates the need to migrate from the "X-" name to a standardized name. Migration then causes interoperability issues (and sometimes security issues) because older implementations only support the "X-" name, while newer implementations might only support the standardized name. So to keep things working, newer implementations just support the "X-" name forever 💀. That means the unstandardized name becomes a de facto standard, which kind of makes the whole point of splitting the name space into standardized and unstandardized areas pointless in the first place.

We already saw this happen with FTP in the [RFC1123] quote back in Appendix A. The HTTP crowd had the exact same experience with the "x-gzip" and "x-compress" media types, as [RFC2068] noted:

For compatibility with previous implementations of HTTP, applications should consider "x-gzip" and "x-compress" to be equivalent to "gzip" and "compress" respectively.

Another example is [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 splitting the name space was that registering names felt hard 🍓. The fix turned out to be simpler registration rules, like the ones in [RFC3864] and [RFC4288]. As [RFC4288] explains:

[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 setting up separate registries for permanent names and provisional names, like in [RFC4395] ✨.

Also, standardizing an unstandardized parameter often leads to subtly different behavior 👀. For example, the standardized version might have different security properties because of the security review it got during standardization. If implementers treat the old, unstandardized parameter and the new, standardized parameter as equivalent, interoperability and security problems can happen. Analyzing unstandardized parameters to detect and fix flaws is a good thing in general, and the lack of a distinction in element names isn't meant to discourage it. If an originally unstandardized parameter or protocol element gets 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 about the "P-" convention in the Session Initiation Protocol, see [RFC5727] 🎀.

There are some situations where segregating the parameter name space used in a given application protocol can be justified:

  1. When it is extremely unlikely that some parameters will ever be standardized. In this case, implementation-specific and private-use parameters could at least include the organization's name (e.g., "ExampleInc-foo" or, consistent with [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 is also 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") 🌈. Having multiple similarly named parameters can be confusing, but that's true regardless of whether there's 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 main 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, and 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 an unstandardized parameter "foo" to exist at the same time. 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" ⭐.
  3. [BCP82] is entitled "Assigning Experimental and Testing Numbers Considered Useful" and therefore implies that the "X-" prefix is also useful for experimental parameters. However, BCP 82 addresses the need for protocol numbers when the pool of such numbers is strictly limited (e.g., DHCP options), or when a number is absolutely required even for purely experimental purposes (e.g., the Protocol field of the IP header). In almost all application protocols that make use of protocol parameters (including email headers, media types, HTTP headers, vCard parameters and properties, URNs, and LDAP field names), the name space is not limited or constrained in any way, so there is no need to assign a block of names for private use or experimental purposes (see also [BCP26]) 💅.

So, it appears that segregating the parameter space into a standardized area and an unstandardized area has few, if any, benefits, and has at least one significant cost in terms of interoperability 💖.

References 📚

Normative References

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.

Informative References 📚✨

okay these are the receipts bestie 💅

  • [BCP9] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996.
  • [BCP26] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
  • [BCP82] Narten, T., "Assigning Experimental and Testing Numbers Considered Useful", BCP 82, RFC 3692, January 2004.
  • [RFC691] Harvey, B., "One more try on the FTP", RFC 691, June 1975.
  • [RFC737] Harrenstien, K., "FTP extension: XSEN", RFC 737, October 1977.
  • [RFC743] Harrenstien, K., "FTP extension: XRSQ/XRCP", RFC 743, December 1977.
  • [RFC775] Mankins, D., Franklin, D., and A. Owen, "Directory oriented FTP commands", RFC 775, December 1980.
  • [RFC822] Crocker, D., "Standard for the format of ARPA Internet text messages", STD 11, RFC 822, August 1982.
  • [RFC1123] Braden, R., "Requirements for Internet Hosts - Application and Support", STD 3, RFC 1123, October 1989.
  • [RFC1154] Robinson, D. and R. Ullmann, "Encoding header field for internet messages", RFC 1154, April 1990.
  • [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, November 1996.
  • [RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", RFC 2046, November 1996.
  • [RFC2047] Moore, K., "MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text", RFC 2047, November 1996.
  • [RFC2068] Fielding, R., Gettys, J., Mogul, J., Nielsen, H., and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2068, January 1997.
  • [RFC2426] Dawson, F. and T. Howes, "vCard MIME Directory Profile", RFC 2426, September 1998.
  • [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
  • [RFC2822] Resnick, P., "Internet Message Format", RFC 2822, April 2001.
  • [RFC2939] Droms, R., "Procedures and IANA Guidelines for Definition of New DHCP Options and Message Types", BCP 43, RFC 2939, September 2000.
  • [RFC3406] Daigle, L., van Gulik, D., Iannella, R., and P. Faltstrom, "Uniform Resource Names (URN) Namespace Definition Mechanisms", BCP 66, RFC 3406, October 2002.
  • [RFC3427] Mankin, A., Bradner, S., Mahy, R., Willis, D., Ott, J., and B. Rosen, "Change Process for the Session Initiation Protocol (SIP)", RFC 3427, December 2002.
  • [RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration Procedures for Message Header Fields", BCP 90, RFC 3864, September 2004.
  • [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005.
  • [RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally Unique IDentifier (UUID) URN Namespace", RFC 4122, July 2005.
  • [RFC4288] Freed, N. and J. Klensin, "Media Type Specifications and Registration Procedures", BCP 13, RFC 4288, December 2005.
  • [RFC4395] Hansen, T., Hardie, T., and L. Masinter, "Guidelines and Registration Procedures for New URI Schemes", BCP 35, RFC 4395, February 2006.
  • [RFC4512] Zeilenga, K., "Lightweight Directory Access Protocol (LDAP): Directory Information Models", RFC 4512, June 2006.
  • [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, July 2006.
  • [RFC5064] Duerst, M., "The Archived-At Message Header Field", RFC 5064, December 2007.
  • [RFC5451] Kucherawy, M., "Message Header Field for Indicating Message Authentication Status", RFC 5451, April 2009.
  • [RFC5545] Desruisseaux, B., "Internet Calendaring and Scheduling Core Object Specification (iCalendar)", RFC 5545, September 2009.
  • [RFC5646] Phillips, A. and M. Davis, "Tags for Identifying Languages", BCP 47, RFC 5646, September 2009.
  • [RFC5727] Peterson, J., Jennings, C., and R. Sparks, "Change Process for the Session Initiation Protocol (SIP) and the Real-time Applications and Infrastructure Area", BCP 67, RFC 5727, March 2010.

Authors' Addresses 🫶

Peter Saint-Andre
Cisco Systems, Inc.
1899 Wynkoop Street, Suite 600
Denver, CO  80202
USA

Phone: +1-303-308-3282
EMail: psaintan@cisco.com


Dave Crocker
Brandenburg InternetWorking
675 Spruce Dr.
Sunnyvale, CA
USA

Phone: +1.408.246.8253
EMail: dcrocker@bbiw.net
URI:   http://bbiw.net


Mark Nottingham
Rackspace

EMail: mnot@mnot.net
URI:   http://www.mnot.net
📦 where this page comes from