> MIME has thought about all these issues and come up with
> *practical* approaches to them. WWW should use MIME whenever possible,
> even when other approaches are "better" from some points of view.
> MIME has a lot of experience behind it in Andrew, which had
> lots of hypertextish (www-ish) aspects. And the internet future
> is MIME.
> It should not be hard to find an extensible way to embed MIME
> in HTML and HTML in MIME. Notice MIME documents can already
> have anchor-names in them (Content-Id:), references to
> external documents, etc.
Some things are being confused here, I think. MIME does not define a
document format, or reflect the experience with the Andrew Toolkit's
(then, ATK; now called AUIS) support for `embedding' in data formats,
particularly in their text format. Some of us on the MIME list thought
about using MIME and mail headers to form a document format, and it
never came to much. What MIME provides is a stylized, uniform way of
indicating the format of a mail message; this may also be useful for
specifying the format of a document. Yes, the multipart has
"Content-Id", but so do many things. Compound document formats
typically require more powerful infrastructure.
ATK had very little in the form of hypertextish objects; just the
"link", so far as I can remember. A lot of multimedia aspects, though.
Embedding HTML in MIME should be easy, sure, as it amounts to just putting
Content-Type: application/html
in a header, before the actual HTML document. But embedding MIME in
HTML sounds like a type mismatch. You might be able to use the MIME
registered types in some fashion in HTML; perhaps that's what you meant.
Bill