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

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

From: Larry Masinter <masinter@adobe.com>
Date: Mon, 31 Jan 2011 15:56:31 -0800
To: Yves Lafon <ylafon@w3.org>
CC: Noah Mendelsohn <nrm@arcanedomain.com>, "www-tag@w3.org" <www-tag@w3.org>
Message-ID: <C68CB012D9182D408CED7B884F441D4D058EDDD59E@nambxv01a.corp.adobe.com>
Looking forward to the discussion about registries at the
next TAG meeting. 

I think there's some interplay between protocol, process,
organization and authority here that we need to sort out.
Using URIs instead of registered values somehow helps with
a "process" or an organizational bottleneck, but it still
bets the question of who has authority to say what a token
(whether a URI, a registered value, or an unregistered value)
_means_ and how that meaning evolves or doesn't over time,
especially in a world in which in-band version indicators
are eschewed.

Rather than talk about the underlying philosophy again,
though, I'd like to see if we could focus on the procedural
issue of registries, with a focus initially on the MIME
type and charset registries that are covered by the
mime-web-info document, but eventually extending to other
web-related registered values such as HTTP headers, error
codes, extension points, vendor prefixes, microdata tags,
etc. etc.

"Those who cannot remember the past are condemned to repeat it."

I think for our discussion on registries that RFC 2434
should be required reading.


-----Original Message-----
From: Yves Lafon [mailto:ylafon@w3.org] 
Sent: Monday, January 31, 2011 7:00 AM
To: Larry Masinter
Cc: Noah Mendelsohn; www-tag@w3.org
Subject: RE: ACTION-472: New Mime-web-info draft

On Fri, 28 Jan 2011, Larry Masinter wrote:

>> There is a need to document the reality of media type deployment. If a
>> media type is registered at the end of design time, so after basic interop
>> testing, but way before wide deployment, you can expect that there will be
>> unseen issues, so a repository of issues or even errata that might be
>> folded later in the main repository. (In sync with the first line of
>> paragraph 5, bringing the MIME registry and real life closer).
> What's hard is when there are multiple perceptions of "reality".

Well, if the reality is that there are many realities, it ought to be 

> And some of the issues for MIME types are general issues
> for 'registries', and even for standards which the registered
> values point to.
> In general, there is the question of evolution and versioning;
> if a registration is going to be useful, it must point to a
> document which describes what is being registered. But of course,
> registrations are valuable only if the document that everyone
> reads is the same document. And yet, documents and the technologies
> they describe evolve over time.
> I think this is an issue for any registry, and any MIME type,
> whether image/jpeg, application/xml, application/pdf or text/html.
> Technologies evolve, some more rapidly than others; yet there are
> versions of technologies that people agree to call out as stable.
> A MIME type does not itself imply a particular version, but indicates
> any one of a stream of versions.

So the registry, should provide a way to point to the different format 
versions attached to a media type, the stable one(s), and even the 
not-so-stable-but-deployed one, clearly stated as 'informative references'

Baroula que barouleras, au tiéu toujou t'entourneras.

Received on Monday, 31 January 2011 23:57:06 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:33:09 UTC