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