multiple mime-types for the same file?

[Dave Cridland [Home]]

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.


> so...
> 
> 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 
> described..
> 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... 
> what
> 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.

Dave.