[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: attachment names and "Message Not Available"



On Sun, 6 Sep 1998, Marcos A. Souza wrote:

> Is there a way to make mhonarc parsing attachments not based in the
> content-type, but in the file extension?!?

We probably shouldn't get into this sort of argument that I am
about to bring us into, but ...

The MIME standards are the way they are for a very good reason.  Until
recently, most documents on the internet with the extension .doc were
formatated ASCII text files.  Different systems have different conventions
about extensions and files names.  The internet is about getting different
systems to work together.

The MIME header standard is well designed.  It splits the responsibility
of dealing with different sorts of files in a correct way.

The sender of the document (or the software working on the sender's
behalf) such as an email client or a webserver has the responsibility of
saying what the content type of the document is.  Only the sender has
that information.  Whether that information comes from file extentions
or by magic (that is a technical term) is up to the sending system.  We
want this to work not just for the systems that exist today, but for
systems that we haven't dreamt of which may not even have file names
at all.  The sending system has the responsibility to tell me the content
type, and not just pass me the name.  If you get a .doc file from me, it
is probably a text/plain.

The other side is that the recipient decides what to do with a file.
The sender might correctly tell me that a document is application/pdf,
but it is up to me (or agents acting on my behalf) to decide whether
I want to run ghostview, xpdf, or acrobat or whatever to process that
file.
 
Transmitting file names is an extra little add-on for MIME.  It should
never be the mechanism for transmitting Content-type.  (Actually, in
the case of application/octet-steam, one might make a case for
recipient clients guessing based on extenstion, but that should
NEVER be relayed on, or assumed by sending systems.)

-j

--
Jeffrey Goldberg                +44 (0)1234 750 111 x 2826
 Cranfield Computer Centre      FAX         751 814
 J.Goldberg@Cranfield.ac.uk     http://WWW.Cranfield.ac.uk/public/cc/cc047/
Relativism is the triumph of authority over truth, convention over justice.



MIME(1)                                                   MIME(1)


NNAAMMEE
       MIME - Multipurpose Internet Mail Extensions

SSYYNNOOPPSSIISS
       Not  a command -- see the SEE ALSO section for usable com-
       mands.

DDEESSCCRRIIPPTTIIOONN
       _M_I_M_E is the official proposed standard format for extended
       Internet  electronic  mail.  The MIME format permits email
       to include enhanced text, graphics, audio, and more, in  a
       standardized  and  interoperable  manner.  If you send and
       receive mail with a MIME-compliant mail system,  you  will
       be able to send and receive far more than ASCII text.

       Various  different  people  and companies are implementing
       MIME-compliant software.  This man page was  provided,  by
       user  request,  as part of the freely-available "metamail"
       distribution from Bellcore.  Metamail provides a  complete
       MIME  implementation, but there may well be others at your
       site, too.  The "SEE ALSO"  section  only  refers  to  the
       tools that came as part of the metamail distribution.

SSEEEE AALLSSOO
       metamail(1),  mailto(1),  metasend(1),  mmencode(1), rich-
       text(1), splitmail(1), mailto-hebrew(1)

CCOOPPYYRRIIGGHHTT
       Copyright (c)  1991  Bell  Communications  Research,  Inc.
       (Bellcore)

       Permission to use, copy, modify, and distribute this mate-
       rial for any purpose and without fee  is  hereby  granted,
       provided  that the above copyright notice and this permis-
       sion notice appear in all copies, and  that  the  name  of
       Bellcore  not be used in advertising or publicity pertain-
       ing to this material without the specific,  prior  written
       permission  of  an  authorized representative of Bellcore.
       BELLCORE MAKES NO REPRESENTATIONS ABOUT  THE  ACCURACY  OR
       SUITABILITY  OF THIS MATERIAL FOR ANY PURPOSE.  IT IS PRO-
       VIDED "AS IS", WITHOUT ANY EXPRESS OR IMPLIED  WARRANTIES.

AAUUTTHHOORR
       Nathaniel S. Borenstein, Bellcore













                            Release 1                           1