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.

Ahh, that's a good point, my example wasn't a great one. It seems an app-specific prefix is the way to go WRT my question.

I often wondered about the X in "application/x-www-form-urlencoded". I've seen RFCs make explicit references to this format.

An example of the problems with "x-", specifically in the BitTorrent MIME type, can be found at https://issues.apache.org/bugzilla/show_bug.cgi?id=20440.

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.

I thought this link looked familiar. I glanced through this:

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.

Clearly this post is a response to the Bad RESTful API post earlier. Every so often, a good link comes out of a comment and becomes a post on its own.

Wonder what? Clearly the submitter found it through the comment. So what?

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.

Is anyone else struck by the antiquated nature of the (what is that, a roff?) format? Why, for an "internet draft" is this page not the default format: http://tools.ietf.org/id/draft-ietf-appsawg-xdash-02.html ?

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.

I am saying exactly "html is a better format today".

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.

I really wish they'd stop using it!

At the top of the page is "[txt|pdf|html]", if you click the "html", your wish is granted: http://tools.ietf.org/id/draft-ietf-appsawg-xdash-02.html

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

I had always thought X- meant extensions. I didn't realize it meant Experimental.

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.

It's interesting to consider the parallels between this and CSS vendor prefixes.

ok..so instead of x- ..what should we be using for none standard header?

From page 3 (http://tools.ietf.org/html/draft-ietf-appsawg-xdash-02#page-...):

employ meaningful but currently unused names

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.

That is; the same way as before just without the X.

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

e.g. -moz-/-ms-/etc...

[0] http://news.ycombinator.com/item?id=3540150