X-Dash Reference

[barryleiba@…]

One particular comment about Section 3.2.1:

As a result, the notion of "X-" headers was removed from the Internet
Message Format standard when it was updated in 2001 [RFC2822].
Similarly, within SIP, [RFC5727] Section 4 deprecated the guidance
provided in [RFC3427] on the creation of "P-" headers:

This was written, I'm sure, before the approval of appsawg-xdash (
​http://datatracker.ietf.org/doc/draft-ietf-appsawg-xdash/ ), which is
now in the RFC Editor queue. I think it's important to cite
appsawg-xdash here, because it goes into more detail about the
problems and recommendations.

[bernard_aboba@…]

Proposed change to Section 3.2.1:

One approach to solving this problem has been to reserve parts of an
identifier namespace for "limited applicability" or "site-specific"
use, such as "X-" headers in email messages [RFC0822] or "P-" headers
in SIP [RFC3427]. However, as noted in "Deprecating the X- Prefix
and Similar Constructs in Application Protocols" Appendix B [XDASH]:

The primary problem with the "X-" convention is that
unstandardized parameters have a tendency to leak into the
protected space of standardized parameters, thus introducing the
need for migration from the "X-" name to a standardized name.
Migration, in turn, introduces interoperability issues (and
sometimes security issues) because older implementations will
support only the "X-" name and newer implementations might support
only the standardized name. To preserve interoperability, newer
implementations simply support the "X-" name forever, which means
that the unstandardized name has become a de facto standard (thus
obviating the need for segregation of the name space into
standardized and unstandardized areas in the first place).

As a result, the notion of "X-" headers was removed from the Internet
Message Format standard when it was updated in 2001 [RFC2822] and
within SIP, [RFC5727] Section 4 deprecated the guidance provided in
[RFC3427] on the creation of "P-" headers. More generally, as noted
in [XDASH] Section 1:

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, even where that convention was only implicit instead of being codified in a protocol specification (as was done for email in [RFC822]).

Also, the following text has been added to Section 3.2.2:

However, as noted in [XDASH] Appendix B, assigning a parameter block
for experimental use is only necessary when the parameter pool is
limited:

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

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.

[bernard_aboba@…]

Also, the following text has been added to Appendix A.2:

as discussed in "RADIUS Design Guidelines" BCP 158 [RFC6158] Section
2.4:

RADIUS attributes can often be developed within the vendor space
without loss (and possibly even with gain) in functionality. As a
result, translation of RADIUS attributes developed within the
vendor space into the standard space may provide only modest
benefits, while accelerating the exhaustion of the standard space.
We do not expect that all RADIUS attribute specifications
requiring interoperability will be developed within the IETF, and
allocated from the standard space. A more scalable approach is to
recognize the flexibility of the vendor space, while working
toward improvements in the quality and availability of RADIUS
attribute specifications, regardless of where they are developed.

It is therefore NOT RECOMMENDED that specifications intended
solely for use by a vendor or SDO be translated into the standard
space.