Stop it with the X- Already! (original) (raw)

Wednesday, 18 February 2009

HTTP HTTP APIs

UPDATE: RFC6648 is now the official word on this topic.

Sometimes, it seems like every time somebody has a great idea for a new HTTP header, media type, or pretty much any other protocol element, they do the same thing. Rather than trying to figure out how to fit into how the rest of the world operates, getting adequate review and socialising their proposal, they just stick a bloody X- on the front and ship it.

The IETF has no-one to blame but itself for this situation, of course. X- was a convention designed for experimentation (hence the ‘x’). However, the problem is in transitioning from experimental to production; as soon as your header (or whatever) escapes the lab and has to interoperate with another system, it’s no longer experimental, it’s on the Internet. Oops.

RFC4288 tried to address this situation for media types;

However, with the simplified registration procedures described above for vendor and personal trees, it should rarely, if ever, be necessary to use unregistered experimental types. Therefore, use of both “x-” and “x.” forms is discouraged.

Likewise, RFC3864 makes the same attempt for HTTP and all other message headers, albeit not so explicitly; instead, by setting up a provisional header repository whose procedure consists of sending an e-mail, we hoped that people wouldn’t feel the need to use X-.

Perhaps in vain, unfortunately. Dan points out how Palm has decided to extend HTML;

A widget is declared within your HTML as an empty div with an x-mojo-element attribute.

WTF?

Let’s Make it Easy

Because of this, I think we (the standards community ‘we’) need to over-communicate how formats and protocols should be extended, and under what conditions; indeed, this is one of the explicit goals we wrote into the HTTPbis charter. Only then can we justifiably be angry with people who get it wrong.

In the meantime;

  1. If you’re trying to introduce a new HTTP/SMTP/etc. header, the minimum bar is sending an e-mail to get it into the Provisional Header Repository, as per RFC3864.
  2. If you’re trying to introduce a new media type, have a look at RFC4288 and consider the vnd tree.
  3. If you’re trying to extend HTML, talk to the XHTML, HTML5 and Microformats folks about that.

In none of these cases (or, for that matter, any other case) should an “X-” show its ugly little four-armed, dashed self.

A Few Words on URI-Based Extensibility

As Dan says, the TAG has weighed in on the proper way for formats to enable extensibility, using URIs. This is very relevant to the discussions we’re having about the Link header, since one of the goals is to retrofit URI-based extensibility onto the link relation type identifiers, so that people can ground them in a global namespace.

Atom started this practice, and so far, it’s working reasonably well. There may be a couple of bumps on the road; as DeWitt points out, there are an awful lot of bare-word link relations in use in HTML already. As such, I’m suspecting that we’re going to actually have three kinds of relation type identifiers in reality; absolute URIs for well-identified extension relations, “short” registered identifiers for common well-identified relations, and “short” unregistered relations for ad hoc, locally-scoped and uncoordinated extension relations.

Also, I’d be remiss if I didn’t point out that too much extensibility can be anti-social. Which is why it’s not only necessary how to extend something, but when not to. Otherwise, everyone will be talking past each other using their own proprietary languages.