W3C home > Mailing lists > Public > www-tag@w3.org > November 2010

Re: Feedback on Internet Media Types and the Web

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>
Message-ID: <op.vlyb2ppy64w2qv@anne-van-kesterens-macbook-pro.local>
On Wed, 10 Nov 2010 02:51:37 +0100, Larry Masinter <masinter@adobe.com>  
> 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  

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
Received on Wednesday, 10 November 2010 11:13:03 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:33:08 UTC