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 18:21:16 -0800
To: "Eric J. Bowman" <eric@bisonsystems.net>, 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: <C68CB012D9182D408CED7B884F441D4D0476CF37CF@nambxv01a.corp.adobe.com>
> But that's exactly the sort
> of situation the IANA registry is meant to avoid, in the standards tree
> anyway. 

When vendors can and do deploy software which uses non-registered
values in situations where registration is required, the registration
process does not accomplish this intention: the situation it is
meant to avoid is not avoided.

Are there any other situations outside the web and browser vendors
where this happens, or is this unique to the web? 

>  I believe the standards tree serves a valuable purpose,

It is intended to serve a valuable purpose, but it apparently
does not serve that purpose.

>  and
> that it would be a bad thing to let anarchy reign by stating that it
> doesn't matter whether the rules for media types are followed, g'head
> and deploy whatever, and let popular consent override technical
> concerns.

Anarchy does reign. There is no harm, foul, or back-pressure
against deploying unregistered values. There is at least some
amount of perceived benefit (or at least cost-reduction) in 
deploying unregistered values: perhaps the rules are unnecessarily
stringent, the registration requires additional work which has not
been done, or perhaps just advanced notice to competitors of intended
new values or applications. 

The situation is perhaps exacerbated by "displaced monetization",
where deployed software is free, and those sponsoring the deployment of
the software gain value indirectly. E.g., all of the browsers and plugins
are free, with the vendors making the browsers available instead
benefitting from their ability to deploy and/or sell something else:
advertising revenue, tooling, infrastructure, services. In such a
situation, control over extensibility might yield an advantage.

> In none of these cases do I blame the registry for such failures -- the
> rules for registration, and the definition of media types, had been
> around long enough that the failure lies with the WGs who ignored them.

I don't think it's useful to try to find who to "blame". Individuals
and organizations behave in ways that ultimately optimize their
value within the situation established. Adding barriers-to-entry
into a registry, where there is no mechanism of enforcement and
even slight benefit to avoiding the barriers will yield a situation
where unregistered values are widely used. 

> I go to the registry to find media types that have been vetted by
> experts and known to meet some basic requirements.  If the registry
> becomes a list of everything anyone wants to do, whether it meets those
> requirements or not, well, I'd consider that a failure of the registry.

It seems like in most situations, denying entry into the registry
is not a strong deterrent. Perhaps it was at the time the registries
were established -- a world without wikipedia, google search, wikis
or the web, where IANA controlled a rare resource: a reliable method
of publication of information. Back then, denying entry into an
IANA registry meant something. Now, as we see, people just route
around the blockage, go to the Wikipedia article on "URL schemes"
or a search engine to find some spec or another for the token they're
looking for.

> The rules are quite clear -- pending approval, prefix with x. i.e.
> image/x.svg+xml or application/x.rss+xml.  Refusing to follow the
> appropriate syntax *and* ignoring what media types are supposed to do,
> shouldn't be rewarded with registration

registration carries almost no value in today's world, so
withholding it isn't effective.

> -- the IANA registry isn't
> perfect, but destroying its credibility such that nobody has any faith
> in any media types, sounds counterproductive to me, and would be a much
> larger problem than the handful of strings out there which *look* like
> standards-tree media types, but aren't.

I think we need some other way of addressing the problem.

I don't have a proposal I want to make. Here's a draconian, non-workable
example, though: what if the W3C patent policy only applied to implementations
that followed the W3Cspecifications, and W3C specifications required registration
of values used in implementations? I know this isn't really workable,
but perhaps there is some way of getting vendors to avoid unregistered
values by associating a cost with that use?

I'm going to have to boil all of this down into wording to fit
into the mime-web-info document.... any help with that would be
really appreciated. Again, the goal is to (a) describe the situation
and history (b) explain the problems (hopefully in neutral wording 
without getting into 'blame'), and (c) identify the nature of the
possible solutions and where in the process/specifications/documents
those solutions would go.

Received on Wednesday, 10 November 2010 02:21:45 UTC

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