- 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>
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... 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 Larry -- http://larry.masinter.net -----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 [1]. 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 opensearch. 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. Best, Nathan [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