multiple mime-types for the same file?
Dave Cridland [Home]
dave at cridland.net
Mon May 24 17:20:11 EEST 2004
On Mon May 24 13:31:48 2004, gabor wrote:
> my mail client has a simple policy: text/* (and image/* maybe)
> can be displayed in his internal viewer, the rest not.
That's a little simplistic, really.
Firstly, 'application' types are often safe to display, as are many
other top level types. But not all 'text' types are fully safe -
consider 'text/html', which is not safe in its entirety. You never
quite know about text/*+xml, either.
> so i cannot see my python file in the internal viewer....
> because a python script is an application, not a text file ...
Ooooh, no. 'application' does not mean, and has never meant, that
it's an application. It merely means it's application-specific data,
or doesn't fit into the other categories cleanly.
> BUT it IS a text file..
Yes. 'text' means that the data is 'principally textual in nature' -
meaning human readable. I think this should mean that source code
should be 'text', but others disagree, and it's not an argument I can
really be bothered with. It makes more sense in terms of email and
the web than it does in terms of the desktop, anyway.
> (the same applies btw. to shell scripts)
> i think the problem is now clear....
I'm quite concerned that the principle problem appears to be a
failure to read the specifications you are implementing.
> 1. is it possible to assign more mime-types to the same file?
In the context of an email message, no.
In the context of the desktop, then aliases and inheritance apply,
and there is some movement towards having all source code ultimately
inherit from text/plain, as I understand things. text/plain is
defined anyway as the fallback for any text/* which is unknown, where
the charset is known. (Where the charset parameter is unknown, the
fallback is application/octet-stream - in otherwords, unknown)
> 2. are the mime-prefixes (application,text,image) somehow
> what they exactly mean?
Yes, of course, where they are defined in the MIME RFCs. Which of
course you've read, since you're developing an email client. So
therefore you also know that there are more than just those top
levels, and you've familiarized yourself with the way that every MIME
registration carries a Security Considerations section, too.
> 3. if there's no way to have more mime-types for a given file...
> should a program like the mailclient do? special-case all
> known-that-it-is-a-text-file program files?
It needs to have a list of all content types which are considered
safe to inline, of course. Those that aren't in that list get their
disposition forced to attachment.
Moreover, unless you can know that the sender's definition of
application/x-python is the same as yours, which you can't, because
it's 'x-', and by definition unstandardised, then you can't assume
they aren't referring to some completely different 'python', which
might be binary anyway. And no, you can't guess the MIME type based
on the extension, either, since that might be misleading, possibly
even deliberately so, in order to confuse the extension-based
dispatcher of some operating systems.
This is why, many moons past, I suggested that if people didn't want
to have the terrible burden of registering their content types, then
perhaps freedesktop.org could actually do something about providing a
new 'tree' which made things a little easier, giving us a pretty good
idea of whether we were talking about the same content type. I also
argued against using content types as a dispatch method, since
parameters tend to be ignored, and some things don't have a content
type at all.
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.
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.
More information about the xdg