W3C home > Mailing lists > Public > www-tag@w3.org > January 2011

Re: ACTION-472: New Mime-web-info draft

From: Nathan <nathan@webr3.org>
Date: Mon, 31 Jan 2011 22:52:52 +0000
Message-ID: <4D473D44.4040006@webr3.org>
To: Larry Masinter <masinter@adobe.com>
CC: "www-tag@w3.org" <www-tag@w3.org>
Larry Masinter wrote:
> I don't see how using a URI instead of media type name of the
> form  x/y (text/html or image/svg+xml or whatever) helps solve
> any problem at all.
> 
> How is the world any different if everyone uses
> 
> http://media-type-registry.w3.org/text/html
> 
> instead of 
> 
> text/html
> 
> except that web protocols need to send more bytes around?

Ideally they wouldn't, they'd use "text/html" as normal, and to find 
the related RFC/spec (rather than googling) they'd simply lookup 
http://media-type-registry.w3.org/text/html which would redirect 
through to the relevant specification. Similarly users with custom / 
vendor / experimental media types could simply use the full uri in the 
token instead, to say http://example.org/specs/opensearch.

where:
   http://media-type-registry.w3.org/ is the registry
   http://media-type-registry.w3.org/text is the text tree
   http://media-type-registry.w3.org/text/html is a media type 
identifier that redirects to the spec when dereferenced.
   "text/html" is a valid media type token because when appended to 
the registry uri, it redirects rather than 404s (and because it's 
registered as per how things are now)

That was the initial thought anyway.. not ideal for types like +xml 
though, and as Eric pointed out, it would (potentially) promote 
exponential increase in domain specific / app specific mediatypes 
rather than generality and reuse.

Best,

Nathan
Received on Monday, 31 January 2011 22:54:41 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 26 April 2012 12:48:30 GMT