[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: lynx-dev Lynx vs. metamail
From: |
Larry W. Virden |
Subject: |
Re: lynx-dev Lynx vs. metamail |
Date: |
Sun, 9 Aug 1998 07:15:33 -0400 |
From: Philip Webb <address@hidden>
> what is metamail? what is the .mailcap file, ie what does it do?
Many years ago (in fact, before the Web!), the only basic standards for
email had to do with the headers of the messages. The contents could be
any format. This caused a lot of grief when trying to figure out what
was inside the message. Numerous folk tried attachment type formats.
But no one had documented it. Then a gentleman whose name I seem to
recall was Nathaniel Berstein or something close to that conceived of
a project in which one would actually send attachments which would _do_
something. For instance, one might send email along which included a
survey. One would take that survey, then press a button, and a return
email would go out, with the answers you supplied.
However NB was concerned about a few things - how to convey to the
mailer the type of attached info that was present, and how to do all of
this safely. He and others worked together to create something called
Safe Tcl. This was the basis of his work. He also created a series
of mail headers later to be known as MIME, to convey that attachments
were present, what type of application was needed for them, what type
of character sets were necessary, etc. This information that makes up
MIME doesn't apply to the contents of the mail msg directly - it doesn't
relate to what you are saying to Grandma, or to the purpose of the survey.
Instead, it is considered _metadata_ - that is to say, information about
the format and interpretation behind the real purpose of the mail msg.
NB created a series of RFCs detailing MIME. These include things such
as new message headers, attachment formats, encoding formats, data
types for the attachments, etc. He also created and released a sample
implementation of how to create and read mail msgs encoded in mime.
Because his software concerned itself more with the metadata than the
contents of the msg itself, he called the package 'metamail'. The two
primary files metamail uses to interpret a mime message are:
mime.types - a file that creates a correspondance between attachment
name extensions (the part of a message attachment file name after
the period in the name) and a data type. In other words, mapping
misc.gif to a graphics content called GIF, or an attachment name
ending in .au to a particular audio file format. There is no
guarantees that this mapping is correct - thus it is critical
that one is careful here; if a data type isn't provided along
with a message attachment, then this mapping is applied to create
a default.
mailcap - a file that maps a series of data types to external programs
which know how to process the data type. Thus, someone might
define:
image/gif; xli -quiet %s;
which says that if a program needs to display an attachment typed as
image/gif, an application called xli will be invoked by the
mime processing code, passed a flag called -quiet and a file name
(plugged in where the %s is) to process the attachment.
The MIME standard defines lots of other parameters for a MIME
mailcap definition - descriptics of what type of file format this
is, how to create such an attachment, etc. I just chose a simple
one to make life easier.
Once the web was started, it became obvious to us all that this MIME
concept could extend from mail to other protocols, so that for instance in
HTTP, one could pass along a type with the file and that browsers then could
either display the file inline (based on the mime type) or invoke the
MIME helper application (or some other application, based on mailcap or
a similar file).
--
Larry W. Virden INET: address@hidden
<URL:http://www.teraform.com/%7Elvirden/> <*> O- "We are all Kosh."
Unless explicitly stated to the contrary, nothing in this posting should
be construed as representing my employer's opinions.