

Deprecating Use of the "X-" Prefix in Application Protocols (IETF Draft) - geoffschmidt
http://tools.ietf.org/html/draft-ietf-appsawg-xdash-02

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

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

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

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

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

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

------
leif
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> ?

~~~
tedunangst
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
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
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>

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

------
ketralnis
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
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
It's interesting to consider the parallels between this and CSS vendor
prefixes.

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

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

 _employ meaningful but currently unused names_

~~~
gojomo
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
That is; the same way as before just without the X.

