Re: [Nmh-workers] When send does not recognize a mime type

[Lyndon Nerenberg]

On 2012-09-11, at 7:59 AM, address@hidden wrote:

> I guess I kinda believe the opposite. For example send won't send a message 
> if it
> doesn't understand any of the addressees. I think that's a good thing. The
> general philosophy of mh was (contrary to the UNIX philosophy) that if 
> anything
> is wrong do nothing.

Not knowing a file's MIME type is not an error.  It can't be, since not every 
type of data has a specific MIME type. 

E.g., what is foo.dot?  foo.xyz? cat.8?

These are all files that exist on my systems.  foo.dot and foo.xyz are text 
files.  The suffixes are local differentiators with meaning only to me.  Adding 
the dot and xyz suffixes to mimetypes with a text/plain attribute is wrong, 
since another .xyz file might contain, say, sample raw data from a random 
number generator.  I.e. there is no recognized conventional type for .xyz 
files.  This is why MIME has fallback rules: text/plain for printable ASCII 
text content, and application/octet-stream for everything else.

What about cat.8?  On my UNIX systems, that's a pre-formatted man page 
(text/plain).  On my Plan 9 systems, it's object code from the 80386 compilers. 
 (Ditto for cat.2, which could be a pre-formatted man page for a system call, 
or object code from the 68020 compilers.)  This is why deriving the MIME type 
from the file name is fatally flawed.

It's not MIME's job to fix your typing mistakes.

--lyndon