Re: misconceptions about MIME [long]

Nathaniel Borenstein (nsb@thumper.bellcore.com)
Thu, 22 Oct 1992 09:35:59 -0400 (EDT) 

Message-Id: <cetesz_0M2Yt53sZli@thumper.bellcore.com>
Date: Thu, 22 Oct 1992 09:35:59 -0400 (EDT)
From: Nathaniel Borenstein <nsb@thumper.bellcore.com>
To: gopher@boombox.micro.umn.edu, wais-talk@quake.think.com,
Subject: Re: misconceptions about MIME [long]
Cc: nsb@bellcore.com
In-Reply-To: <9210220109.AA02869@pixel.convex.com>

Dan's comments are right on the money.  As an example of how you can
treat non-mail-oriented data as being in MIME format, I've recently
written a script that makes it trivial to set up a MIME-smart mailserver
daemon for, say, everything in your anonymous ftp directory.  This
script -- which will be part of the next metamail release -- accepts
mail requests that give path names relative to the anonymous ftp root,
e.g. "pub/nsb/BodyFormats.txt" and sends the results back as MIME-format
mail.  The neat thing is that the files themselves don't need to be in
MIME format.  The files are assumed to be plain text unless there is a
".ct" file (e.g. "pub/nsb/BodyFormats.txt.ct") in which case that file
is assumed to contain the Content-type information.  Thus if you have a
gif image in file "foo", you can put the text "image/gif" in the file
"foo.ct" and the mailserver will be ready to send the GIF image as
MIME-format mail.  The script is smart enough, using the metamail tools,
to deal with any necessary encoding for mail transport, even though the
raw data is unencoded.

The point is that, as Dan says, the data doesn't need to be explicitly
in MIME format.  MIME body parts are just (possibly encoded) data in
reasonably standard formats.  If you don't enclose it in a mail-ish
thing with a content-type header field, you need some other
"out-of-band" way of providing the type information, but this can be
done in many ways, e.g. the ".ct" files my mailserver uses.  Viewed this
way, all that MIME is really comes down to three things:

1.  A mechanism for encoding arbitrary data for mail transport.  This is
orthogonal to the other parts and can be largely ignored in non-mail
applications.

2.  A mechanism for combining multiple objects in a "multipart" format
defined by MIME.  This doesn't need to be used by non-mail applications,
but a common way of doing this has obvious value.  Why shouldn't
multi-media objects be shared across email, wais, gopher, and www?

3.  A naming convention and a set of standard names for describing data
types such as "image/gif" and "audio/basic".  The common naming
conventions are perhaps the most valuable aspect of MIME for non-mail
applications, as it is pretty obviously silly to give slightly different
names to the same things in different systems.

Anyway, as a principle author of MIME I know I'm not in a great position
to appear to be objective, but I really don't see any good reasons not
to use MIME in applicaitons such as gopher, wais, or www.  -- Nathaniel