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

RE: Feedback on Internet Media Types and the Web

From: Larry Masinter <masinter@adobe.com>
Date: Tue, 9 Nov 2010 17:51:37 -0800
To: "nathan@webr3.org" <nathan@webr3.org>, Henri Sivonen <hsivonen@iki.fi>
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: <C68CB012D9182D408CED7B884F441D4D0476CF37C4@nambxv01a.corp.adobe.com>
It seems to me that there's a "problem" with the mechanisms
of registration when a registry that has technical or administrative
criteria for acceptance, but software can get deployed without
registration and then later discovered that the application doesn't
meet the established rules. 

And it seems like the list of deployed MIME types that aren't registered
(and whose registration has been rejected or would be) is reasonably long.

I think an "architectural principle" of avoiding registries in
W3C -- by using URIs instead of registries, for things such as
namespaces -- has also met with some resistance, and there remain
in the web architecture many key namespaces which require some
amount of administration and disagreement about who and how
those namespaces are controlled; controlling the availability and
mapping of names in namespaces is one way in which (distributed)
extensibility is controlled. (Perhaps it is the *primary* way
in which distributed extensibility is controlled.)

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.

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...

* longevity & reliability of the registration information
* process for maintaining technical requirements for registered
* 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


-----Original Message-----
From: Nathan [mailto:nathan@webr3.org] 
Sent: Tuesday, November 09, 2010 4:16 PM
To: Henri Sivonen
Cc: Larry Masinter; julian.reschke@gmx.de; www-tag@w3.org WG; Alexey Melnikov
Subject: Re: Feedback on Internet Media Types and the Web

Henri Sivonen wrote:
> Another case of deployment happening ahead of registration

not to mention the various rss types, and the types for all variations 
of RDF other than rdf+xml, and the media type for things like opensearch 

The question was asked, recently, how one would go about deploying a new 
mediatype, and which type to use whilst being a future web standard, but 
no reply was given [2,3], similarly after many years, the other RDF 
serializations like N3 and Turtle remain unregistered, and likewise re 

To illustrate the effect this has, currently to figure out what the true 
media type is of some returned RDF, one needs to check for the following:

application/rdf+xml, application/xml, text/xml
  -> hopefully rdf+xml

text/turtle, application/x-turtle, application/turtle, text/rdf+n3, 
text/n3, application/n3:
  -> n3 or turtle

text/rdf, text/text, text/plain, text/html, ""
  -> could be anything

and that's only to negotiate between rdf/xml, n3 and turtle.



[1] http://www.opensearch.org/Specifications/OpenSearch/1.1 
(application/opensearchdescription+xml - This type is pending IANA 
registration. - (for a very long time!)
[2] http://www.ietf.org/mail-archive/web/ietf-types/current/msg01103.html
[3] http://www.ietf.org/mail-archive/web/ietf-types/current/msg01102.html
Received on Wednesday, 10 November 2010 01:52:10 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:56:36 UTC