multiple mime-types for the same file?

[David Faure]

On Monday 24 May 2004 18:39, Dave Cridland [Home] wrote:
> 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.

The only vnd.kde mimetypes I know of, are the KOffice ones, and given
that KOffice is moving towards sharing its file format with OpenOffice.org
(see http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=office),
those mimetypes are going to be deprecated in the long run...
That's why I didn't bother submitting them for the shared mimetype spec.
I'll submit the OASIS ones, once they are registered with the IANA.

> There are ones listed without the 'x-' prefixed that are not listed 
> at IANA, such as 'application/illustrator', 'application/smil', etc. 
Submit bug reports, apparently that's the preferred way.

> 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.
Why? We do need to identify all types of files.

> 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.
Without translations, without icons, without any control from us to quickly add
what we need, and without a whole bunch of mimetypes that we need.
And it's just not as easy as pointing them to our .xml file, you need to
register each and every mimetype separately, with details about what
this file type is about, etc. If you feel like it, feel free to go ahead.

> 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.
I agree - when this happens, it has to be fixed. And simply ranting about it
in general every N months doesn't really fix anything :)

> 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.
As I said, go ahead. If you feel that something should be done, why
not just do it?

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

> 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.
For all particular purposes, though, if you receive e.g. a .java file and
your mailer has no idea what to do with it, what happens? You save it,
and your desktop recognizes the extension (or content) and the file is
meaningful again. What I'm saying here, is that it's not such a big deal
that mimetypes don't match on the environments at two ends of a mail.

But yes, we 'should' register as much as we can with the IANA, to 
solve this, I don't disagree.

> 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.
This, I don't agree with. The point of standardizing which x-foo mimetypes
we use is "how to make the free environments work similarly and make the
transition to that as painless as possible". Renaming everything defeats
that purpose. If we take the effort to rename things, we might as well start
by registering proper mimetypes for things.

-- 
David Faure, faure at kde.org, sponsored by Trolltech to work on KDE,
Konqueror (http://www.konqueror.org), and KOffice (http://www.koffice.org).