multiple mime-types for the same file?
Dave Cridland [Home]
dave at cridland.net
Mon May 24 19:39:37 EEST 2004
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
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
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
> 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
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
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
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.
More information about the xdg