multiple mime-types for the same file?

[Dave Cridland [Home]]

On Mon May 24 15:48:05 2004, David Faure wrote:
> On Monday 24 May 2004 16:20, Dave Cridland [Home] wrote:
> > But that was all shouted down, hence we have a shared mime 
> database > that contains unregistered types, but doesn't contain 
> all registered > ones - including ones that have been registered 
> for KDE by members of > this list, which I find quite ironic.
> Which mimetypes are you referring to?
> 
> 
Most, if not all, the vnd.kde ones weren't there last time I looked.

As of now, I can't find any of them in the current (0.14) download, 
but there are 8 registered at IANA. I'm certainly not criticising you 
for registering them - full kudos to yourself and KDE for doing so.

There are hundreds of other media types unmentioned in the database, 
and I don't really expect them all to be in there anyway, but it 
surprises me enormously that the KDE ones are not.

There are ones listed without the 'x-' prefixed that are not listed 
at IANA, such as 'application/illustrator', 'application/smil', etc. 
I think most of the vendor tree ones are made up 
'application/vnd.corel-draw' is, for instance, but would, I think, be 
registered as 'application/vnd.corel.draw' anyway, unless it became 
an 'image' type, of course. I don't expect to see any of these in the 
database at all, it's ridiculous that they're there.

application/octet-stream has matches. (How do you identify unknown 
data? Easy, just use these matches... Presumably, if it fails all the 
matches, then it's known? How useful, since it's obviously faster to 
run the handful of matches there than to run through all the other 
ones. Lots of good optimization can be made with this truly 
innovative system.)

A shared content/media/mime type database is a fantastic idea, don't 
get me wrong, it's just that there already is one, maintained by IANA.

It's a shame to have to start another one just because there's so 
many x-prefixed types we rely on, and indeed because the IANA one 
doesn't allow for translations nor computer based access, but I can 
live with it, since it seems nobody other than the KDE team is 
willing to go to the arduous effort of actually registering an IANA 
type.

It gets silly to then end up contradicting the IANA one, and 
apparently failing to understand what some of the existing content 
types actually are.

Filling in http://www.iana.org/cgi-bin/mediatypes.pl does not seem 
particularly difficult to me, and apparently you found it possible 
too, but I quite understand that other people have more important 
things to do than bother with standards, which does make me wonder 
what the point of freedesktop.org trying to write any is in the first 
place.


> Note that KDE doesn't use the shared mimetype spec yet, that will 
> be for
> KDE 4 (for obvious compatibility reasons). So of course we will sync
> the mimetypes more in the future - I have started to do that (see 
> the bug
> reports), but more is still to be done.
> 
> 
If there's updates to the CVS version that alter my above statements, 
then I'll cheer them along. If it's any consolation, I've not 
observed any IANA registrations by any other desktop than KDE.


> > It's worth noting that the MIME type usage in the context of the 
> > desktop is essentially distinct from their use in an email 
> client. > Within the desktop, of course, it's fine to assume that 
> each > application agrees what x-foo/x-bar is, but in email, this 
> is not a > safe assumption to make.
> This is exactly why we have the shared mimetype database...
> 
> 
No, I think you've misunderstood, perhaps I phrased that badly:

"Within the desktop, of course, it's fine to assume that each 
application agrees what x-foo/x-bar is, "

Because of the shared mime/media/content type database, indeed.

My use of the term 'desktop' was a bad choice, in retrospect - 
obviously where any applications share a common understanding of a 
particular media type, it's perfectly safe to use this, not just 
within a particular desktop, but between the ones which adhere to the 
database.

Equally, different applications running on the same system may 
disagree, if one uses /etc/mailcap and the other the shared 
media/mime/content type database.

However, stating all that is essentially restating the RFC in any 
case. I'm taking it as read that everyone likely to contribute to 
this thread has read the various specifications involved.

In any case, this is where the shared content/media/mime type 
database fits in. It's there to get at least all the desktop software 
running on the same system using the same set of x-prefixed types.

"but in email, this is not a safe assumption to make."

- Because Microsoft, Apple, or any of the other thousands of email 
vendors (and HTTP server operators, too, for that matter) do not 
adhere to a freedesktop.org specification, nor would anyone expect 
them to.

The purpose of the x-prefix is to denote that the content type is not 
unknown, but unless you've a good reason to behave otherwise, you 
should treat it as such. The shared mime/content/media type database 
provides such a reason, internally within an environment which 
adheres to it.

But unless you can be certain that all incoming email is being sent 
by applications using the same version of that database, then an 
x-prefixed type is equivalent to application/octet stream by 
definition.

I also stated that email (and other network) treatment of content 
types is different from desktop handling.

My original suggestions of actually moving away from a pure 'x-foo' 
towards a 'x-xdg.foo' convention, deprecating the old x-prefixed 
names, were to try to minimize this difference, although I freely 
admit I'd prefer to have seen people register media-types with IANA, 
as you did.

Dave.