I like seeing an attempt at cleaning up the X-abuse, but the recommendation of using standard-looking extensions so that if they ever leak into the standard space you aren't left with a "Standard" that is named "x-something-something" -- makes me wonder if you are CLEARLY writing application-specific extensions (e.g. "x-aws-ec2-hourly-rate") is it then OK (by the logic of the spec) to continue using X-?
I understand the motivation when working on something general that might eventually get formalized, but for app-locked params it still feels right to me to continue using X-.
Well in your example there's really no point in having an "X-" there, "aws-" itself is kind of a vendor prefix, there's no chance of that ever conflicting with a real standard header. Adding "X-" would just be wasting bandwidth.
Oh, nothing terribly important. I sometimes wonder if these posts are made either because the submitter found the comment interesting or because they wanted the karma. Both possibilities seem plausible, hence my off-handed remark.
The internet predates html by quite a bit. Perhaps html is a better format today, but the internet is not the same as the web, so it's silly to assume the default web format would be the default internet format.
On the other hand, nowadays everyone has a html parser/rendered installed on their computer, + raw HTML is easier to read than the format they are using.
Though they do finalize to a plain .txt form, these days most of the IDs and RFCs are created in an XML format that the xml2rfc tool take and converts into the classic .txt, pdf, html, nroff, epub...
So because people are occasionally confused by parameters with X- names, we fix this by effectively doubling the number of permutations of names they have to try?
I wonder where you got the idea that the rationale for this proposal is “because people are occasionally confused”. The actual rationale is much more reasonable:
The primary problem with the "X-" convention is that non-standard
parameters have a tendency to leak into the protected space of
standard parameters (whether de jure or de facto), thus introducing
the need for migration from the "X-" name to the standard 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 standard
name. To preserve interoperability, newer implementations simply
support the "X-" name forever, which means that the non-standard name
has become a de facto standard (thus obviating the need for
segregation of the name space into "standard" and "non-standard"
areas in the first place).
Also there is nothing in this proposal that would “effectively [double] the number of permutations of names they have to try”. Look at the Recommendations for Protocol Designers in section 4.
My interpretation: Google for your intended usage; if it seems novel, good. Make sure you document so the next person who Googles for it sees you're already semantic-squatting on that name in context.
Not pretty for those who like certainty and formality, but very in tune with how things can work with global search.
"Note: If the relevant parameter name space has conventions about associating parameter names with those who create them, a parameter name could incorporate the organization's name or primary domain name"
"4. SHOULD identify a convention to allow local or implementation-specific extensions, and reserve delimeters for such uses as needed."
As has been mentioned by another commenter[0] these parts invite the drawing of parallels to CSS vendor prefixes.
I understand the motivation when working on something general that might eventually get formalized, but for app-locked params it still feels right to me to continue using X-.