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.
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.
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.
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.
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...
24 comments
[ 4.0 ms ] story [ 61.4 ms ] threademploy meaningful but currently unused names
Not pretty for those who like certainty and formality, but very in tune with how things can work with global search.
"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.
e.g. -moz-/-ms-/etc...
[0] http://news.ycombinator.com/item?id=3540150
http://news.ycombinator.com/item?id=3538134
And then found this comment from SomeOtherGuy2 some 3 hours prior:
http://news.ycombinator.com/item?id=3538581
Not that I can really complain; it's good to give these drafts some visibility, but I do wonder a bit about the timing of this post.
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-.
I really wish they'd stop using it!
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...
http://tools.ietf.org/id/draft-ietf-appsawg-xdash-02.xml
Bram writes:
> I used an x- mimetype becaues IANA says that you should do that when your
> protocol isn't approved by them. Of course, they want everyone to get a
> mimetype without the x- approved by them eventually, which involves a
> compatibility breakage. I see no need for that pain, especially since
> collisions in the mimetype namespace never happen; One of the nice effects
> of it being a string rather than a number.