Appendix A. Background
For many years, the "X-" prefix has been used for experimental or extension parameters in application protocols. Examples include:
File Transfer Protocol (FTP)
The File Transfer Protocol (FTP) [RFC775] includes the concept of "experimental commands", some of which were prefixed with "X" (e.g., "XSEN", "XRSQ", "XRCP"), leading to the convention that experimental FTP commands should use the "X" prefix. This convention was extended to other protocols.
The authors of [RFC691] argued that this convention was insufficient for two reasons:
-
An "X" prefix does not prevent name collisions when two different implementations use the same "X-" name.
-
Parameters with an "X-" prefix might leak into permanent use, at which point removing the prefix would cause interoperability problems.
Despite these problems, the "X-" prefix convention became common practice.
Email Headers
Early specifications for email headers (such as [RFC822]) distinguished between "extension-fields" (which were formally standardized) and "user-defined-fields" (which were not). User-defined fields were required to begin with "X-". This convention continued through [RFC1123] and was codified in [RFC2045], [RFC2046], and [RFC2047] for MIME.
However, [RFC2822] removed the distinction, noting that the "X-" convention "has the unfortunate tendency of making developers assume that [such fields] need never be registered or standardized", which led to significant interoperability problems when "X-" fields became widely deployed.
Similar changes occurred in other email-related protocols. For example, [RFC3864] established a registration mechanism for all email header fields, regardless of whether they have an "X-" prefix.
HTTP Headers
Early HTTP specifications ([RFC2068], later [RFC2616]) did not mandate the "X-" convention for extension headers, but it became common practice. This led to situations where widely-deployed headers like "X-Forwarded-For" could not easily be standardized because removing the "X-" prefix would break compatibility.
vCard and iCalendar
The vCard specification [RFC2426] allowed extension types and properties with an "X-" prefix. Similarly, iCalendar [RFC5545] uses an "x-name" construct for experimental properties and parameters. These specifications continue to allow such names while also providing registration mechanisms for all properties and parameters.
URN Namespaces
The URN namespace definition mechanism [RFC3406] reserves certain namespaces for experimental purposes (NID values starting with "x-"), but also notes that such names should not be used in production systems.
LDAP Field Names
LDAP [RFC4512] allows attribute descriptions beginning with "x-" for private or experimental use, but such attributes can be standardized if needed.
Conclusion
The historical record shows that while the "X-" convention was intended to prevent collisions between standardized and unstandardized parameters, it has often failed to achieve this goal and has created significant migration and interoperability problems when experimental parameters become widely deployed.