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

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

From: Bob Ferris <zazi@elbklang.net>
Date: Mon, 31 Jan 2011 12:45:31 +0100
Message-ID: <4D46A0DB.3070309@elbklang.net>
To: www-tag@w3.org
Am 31.01.2011 12:28, schrieb Nathan:
> media types could be defined in such a way to support both registries
> and extensible URIs.
>
> For example, a registry could be setup whereby registered and
> standardized types could be passed as tokens of the current format
> 'text/foo', which would relate to an identifier by concatenating that
> value to a base uri, such that:
>
> 'text/foo' is concatenated to
> 'http://www.iana.org/assignments/media-types/' to create the URI
> 'http://www.iana.org/assignments/media-types/text/foo', where an HTTP
> GET on this URI would redirect to the relevant standard, if a 404 is
> received then the type is not registered.
>
> This would allow for a registry to be kept, and located at
> http://www.iana.org/assignments/media-types/ with lists for specific
> trees at the existing URIs, like
> http://www.iana.org/assignments/media-types/text/.
>
> Further, it would allow URIs to be used for unregistered types, thus
> making for an extensible, unconstrained web.
>
> Thus, a media type would always be identified by a URI, and when
> referring to a media type one could use the token for registered types,
> and full URI for unregistered.

+1

This can also enable a better discovery (if wanted by the client) of new 
media types that are previously unknown to the client, that tries to 
consume the delivered response. Analogue the HTTP Upgrade header field 
for HTTP version protocol upgrades and the generally of evolvability 
(allow the extension of client functionality).
Furthermore, it nicely aligns then with the good feature of 
decentralization that the Web gave us.

Cheers,


Bob
Received on Monday, 31 January 2011 11:46:06 GMT

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