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

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

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. 


Larry
--
http://larry.masinter.net


-----Original Message-----
From: Yves Lafon [mailto:ylafon@w3.org] 
Sent: Thursday, January 27, 2011 2:17 PM
To: Larry Masinter
Cc: Noah Mendelsohn; www-tag@w3.org
Subject: RE: ACTION-472: New Mime-web-info draft

On Wed, 19 Jan 2011, Larry Masinter wrote:

Here are some comments on 
http://tools.ietf.org/html/draft-masinter-mime-web-info-02

In 4.1 the Windows-1252 / ISO-8859-1 issue should be mentionned, as many 
authored HTML files were done in windows-1252 and server as iso-8859-1, it 
led to considering one for the other.
http://dev.w3.org/html5/spec/Overview.html#determining-the-character-encoding
http://dev.w3.org/html5/spec/Overview.html#character-encodings-0

In 4.3 Additional Use Cases: Polyglot and Multiview

There is also the case of SVG, if served as application/xml is it an XML 
tree or is it an image like when served as images/svg+xml ?

In the case of HTML compatible XHTML documents, the difference is mainly 
on the way the document is parsed, resulting DOM, etc... but for SVG it 
might affect the nature of the document.

I was wondering if in 4.5 it would be good to talk about User-Agent based 
capability sniffing that is often done instead of real HTTP conneg, as 
listing numerous media types in accept would not be efficient.

In 4.6, adding something along the lines of "Active content present in 
some media types, like HTML or SVG, may be able to repurpose the fragment 
identifier in wayw that are not described by the definition of the 
media-type"

In 5.
Should the use of Macintosh File Type Codes be deprecated?
>From http://support.apple.com/kb/TA25699?viewlocale=en_US it is no longer 
used in OSX.

Also it might be good to add a "pre-registry" to indicate the use of a 
media type and a drafty definition, as the place to look when a type is 
seen 'live' and not present in the official IANA registry. (probably part 
of 5.3).

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


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

         ~~Yves

Received on Friday, 28 January 2011 22:39:18 UTC