- From: Anne van Kesteren <annevk@opera.com>
- Date: Wed, 10 Nov 2010 12:12:15 +0100
- To: "nathan@webr3.org" <nathan@webr3.org>, "Henri Sivonen" <hsivonen@iki.fi>, "Larry Masinter" <masinter@adobe.com>
- Cc: "julian.reschke@gmx.de" <julian.reschke@gmx.de>, "www-tag@w3.org WG" <www-tag@w3.org>, "Alexey Melnikov" <alexey.melnikov@isode.com>
On Wed, 10 Nov 2010 02:51:37 +0100, Larry Masinter <masinter@adobe.com> wrote: > We're now seeing a struggle in the HTML5/IETF/IANA space over > the registry for link relations, and whether the link relations > are registered by IANA, W3C, a wiki, or some other process. This is only a symptom of the problems some set of people (myself included) see with the current IETF/IANA registries. That is, it is one that we might be able to tackle now, but the arguments provided mostly apply to the other registries, such as HTTP headers or MIME types, as well. > I'm wondering if a broader look at the role of registries > in the web architecture, in the face of various deployment > models, might give us some better insights about how to address > the problems: > > registered namespaces: URI schemes, HTTP headers, link > relations, xpointer tokens, MIME types > standards-track-only namespaces: element & attribute names > in any particular HTML/XML language, HTTP error codes... > > Requirements: > * longevity & reliability of the registration information > * process for maintaining technical requirements for registered > values > * ease of registering new values, even when they don't > meet technical requirements > * technical, social, security review of registered entries > * avoiding registration spam, drift of control > * avoiding incompatible use of registered values in > different contexts > * dealing with trademarks I think this would be a very valuable exercise. MIME types are not being minted because it is too hard and we eventually end up with more sniffing. Most recently this happened to fonts. The MIME type registry itself is also not useful with regards to what is in deployment. Apparently the difficulty of minting a MIME type for an idea caused a plurality of MIME types for RDF and somehow also for JavaScript. (Henri went into some of the other issues.) New ideas that require a HTTP header end up being widely deployed with an X prefix. X-Frame-Options is a recent example. The URL scheme registry does not match reality. Strictly speaking it would allow for someone to register about and give it a wildly different meaning from how about has been deployed so far. Wikipedia gives much better information here with regards to what is in use and what likely cannot be registered. The language tag registry on the other hand has worked out surprisingly well. I would say the same is true for HTML elements/attributes, or CSS properties. I thought I had is that this is maybe because there is a community behind these that feels responsible for maintaining those specifications/namespaces. Whereas media types, URLs, and HTTP headers are more open-ended and distributed. Nobody is really responsible for the whole set. Of course the dividing line is not that strict, and there are certainly people that feel HTML/CSS should be less centrally managed, but the majority of HTML/CSS is much more local and tied to each other than something as generic as a MIME type. -- Anne van Kesteren http://annevankesteren.nl/
Received on Wednesday, 10 November 2010 11:13:03 UTC