Skip to main content

Appendix B. Analysis

Problems with the "X-" Convention​

The primary problem with the "X-" convention is that unstandardized parameters have a tendency to leak into the protected space of standardized parameters, thus causing interoperability problems.

Consider the example of email header fields. Originally, [RFC822] distinguished between standardized "Extension-fields" and unstandardized "user-defined-fields", with the latter required to use the "X-" prefix. However, as noted in [RFC2822], this distinction was removed because:

  1. Many "X-" fields became so widely deployed that they became de facto standards (e.g., "X-Mailer").

  2. The "X-" prefix discouraged developers from properly registering their fields.

  3. When developers wanted to standardize an "X-" field, they faced a dilemma: keep the "X-" prefix (which incorrectly suggests it's unstandardized) or remove it (which breaks compatibility with existing implementations).

  4. Some implementers mistakenly believed that any field without an "X-" prefix was formally standardized, leading to interoperability problems.

Similar problems occurred in other protocols:

  • HTTP: Headers like "X-Forwarded-For" became widely deployed but difficult to standardize due to the prefix.

  • SIP: The "P-" prefix for private headers (intended for closed networks) leaked into the broader Internet, as documented in [RFC5727].

  • Media Types: The "x-" prefix for experimental media types led to the same problems, as documented in [RFC4288].

When Segregation Might Be Justified​

In some situations, 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 incorporate 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 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]).

Objections to Deprecating the "X-" Convention​

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".

  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]).

Conclusion​

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

Last updated on