4 ms·

Deprecating Use of the "X-" Prefix in Application Protocols (IETF Draft)

107 points by geoffschmidt 15y ago

lightblade 15y ago
ok..so instead of x- ..what should we be using for none standard header?
- ericwaller 15y ago
  From page 3 (http://tools.ietf.org/html/draft-ietf-appsawg-xdash-02#page-3 http://tools.ietf.org/html/draft-ietf-appsawg-xdash-02#page-...): employ meaningful but currently unused names
  - gojomo 15y ago
    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.
    - nemetroid 15y ago
      That is; the same way as before just without the X.
- Karellen 15y ago
  "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 http://news.ycombinator.com/item?id=3540150
ketralnis 15y ago
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?
- robinhouston 15y ago
  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.
  - pixelcort 15y ago
    It's interesting to consider the parallels between this and CSS vendor prefixes.
billpg 15y ago
I often wondered about the X in "application/x-www-form-urlencoded". I've seen RFCs make explicit references to this format.
deleted 15y ago
[deleted]
teyc 15y ago
I had always thought X- meant extensions. I didn't realize it meant Experimental.
Zancarius 15y ago
I thought this link looked familiar. I glanced through this: http://news.ycombinator.com/item?id=3538134 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 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.
- unreal37 15y ago
  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.
- raldi 15y ago
  Wonder what? Clearly the submitter found it through the comment. So what?
  - Zancarius 15y ago
    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.
rkalla 15y ago
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-.
- kalleboo 15y ago
  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.
  - rkalla 15y ago
    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.
leif 15y ago
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 http://tools.ietf.org/id/draft-ietf-appsawg-xdash-02.html ?
- tedunangst 15y ago
  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.
  - richbradshaw 15y ago
    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!
    - LukeShu 15y ago
      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 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 http://tools.ietf.org/id/draft-ietf-appsawg-xdash-02.xml
  - leif 15y ago
    I am saying exactly "html is a better format today".
kragen 15y ago
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 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.

107 points by geoffschmidt 15y ago

lightblade 15y ago

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

ericwaller 15y ago
From page 3 (http://tools.ietf.org/html/draft-ietf-appsawg-xdash-02#page-3 http://tools.ietf.org/html/draft-ietf-appsawg-xdash-02#page-...): employ meaningful but currently unused names
- gojomo 15y ago
  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.
  - nemetroid 15y ago
    That is; the same way as before just without the X.
Karellen 15y ago
"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 http://news.ycombinator.com/item?id=3540150

ketralnis 15y ago

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?

robinhouston 15y ago
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.
- pixelcort 15y ago
  It's interesting to consider the parallels between this and CSS vendor prefixes.

billpg 15y ago

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

deleted 15y ago

[deleted]

teyc 15y ago

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

Zancarius 15y ago

I thought this link looked familiar. I glanced through this: http://news.ycombinator.com/item?id=3538134 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 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.

unreal37 15y ago
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.
raldi 15y ago
Wonder what? Clearly the submitter found it through the comment. So what?
- Zancarius 15y ago
  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.

rkalla 15y ago

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

kalleboo 15y ago
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.
- rkalla 15y ago
  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.

leif 15y ago

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 http://tools.ietf.org/id/draft-ietf-appsawg-xdash-02.html ?

tedunangst 15y ago
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.
- richbradshaw 15y ago
  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!
  - LukeShu 15y ago
    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 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 http://tools.ietf.org/id/draft-ietf-appsawg-xdash-02.xml
- leif 15y ago
  I am saying exactly "html is a better format today".

kragen 15y ago

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