Re: Feedback on Internet Media Types and the Web

Hi Larry,

I'd agree that there is definitely a "problem", however it may not be as 
big or as complex as one may first believe.

Media types could be bracketed in to four classes:

(1) vendor/application specific
(2) personal types
(3) web standards, deployed or deploying.
(4) generic web scale media types, deployed or deploying.

The existing process for (1) and (2) works just fine, a few of us 
recently discussed the need for, benefits and process around the IANA 
registry in great depth in the REST community, part of those discussions 
involved somebody registering a vnd. type to see how easy the process 
was, and it worked swimmingly well. prs is the same.

(3) and (4) was where the problems arise.

As for (3) web standards seem to go through without a problem, however 
the non unicode friendly-ness of the text/* media type registry is what 
prevents types like n3 and turtle going through, however they could be 
pushed in as application/* types (why this hasn't happened I'm unsure?). 
However still-deploying (or in development) standards have a problem, as 
follows..

(4) is where the real problem lies, there are web scale media types in 
very common use which do need registered, but they are not web 
standards, and whilst being developed these could be considered 
experimental, just as with in-development web standards from (3).

So, I would suggest that the "problem" can be refined down to the 
handling of "experimental" types, and the recognition of those types 
which are web-generic (like opensearch).

I believe, other than a failure to recognise 
non-standards-but-web-scale, that this problem could be fixed easily, 
and comes down to the "x-" types. I'd suggest that the "x-" types 
approach is wrong, because it classifies non experimental types as 
experimental, and requires a migration from x- prefixed to non prefixed.

To resolve this, the approach could be taken of _clearly_ marking 
in-development/"experimental" types as just that in the registry, rather 
than in the media/type string, along with a change to the RFC(s) which 
says that in-development types "may be" recognised by things such as 
apache httpd, but are not required to be.

If this were complimented by an initial "is this web-generic or 
application specific" review, and then later followed up with a "has 
this reached web scale deployment and is it stable" review process, (to 
be requested by those responsible for a media type), then it would 
provide a clear path for non-standards to become fully registered and 
non-experimental, whilst ensure that only those which are generic to the 
web get non prs/vnd types.


change-of-topic: Link Relations Registry

Thankfully anybody can already use a full URI in a rel/rev, so one issue 
is moot here, however there is still the core registry problem, and 
moreover the problem that the same terms, are defined by different specs 
or have multiple URIs they can resolve to.

For example, you'll find a "next" in HTML4 and 
http://www.w3.org/1999/xhtml/vocab/# and the iana link-relations 
registry, so although it's the same term, it can resolve to 3 different 
URIs. Meanwhile some HTML5 people would like that wiki of relations, yet 
another URI to resolve to.

I'd suggest though, that the problem isn't much of a problem on the 
dumbed down real web, where if a rel is "next" it means next or if a 
link is "stylesheet" then it's a stylesheet, but more in the realms of 
those techs which do term resolution and need to know that:
http://www.w3.org/1999/xhtml/vocab/#next
equals
http://www.iana.org/assignments/link-relations/edit
or is it
http://www.iana.org/assignments/link-relations/link-relations#edit
or even
http://www.iana.org/assignments/link-relations/link-relations.xhtml#edit

XHTML is deployed long since and resolves to the xhtml vocab namespace, 
so really it just comes down to techs like grddl and rdf(a), and we 
could easily create a profile in a namespace which asserts that these 
terms are also known as x & y other URIs, such as in the default RDFa 
profile - then encourage the communities where it matters to use this 
namespace/profile. This would also prove to be interoperable with any 
approach either IANA/IETF or whatwg took, as we can simply assert the 
equivalence.

Anyway, I've rambled enough!

Best,

Nathan

Larry Masinter wrote:
> 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 11:35:23 UTC