MIME, originally designed for SMTP messages only, is used for
message structuration. Extensions define the TYPE of a message
or one of its bodyparts. I insist on the global meaning of TYPE.
TYPE has no capacity at all to define the CONTENT itself directly.
This significant but slight difference can be shown as follows:
* a MIME message contains information about the TYPE
of its bodypart
* the local mailcap file contains information about the
CONTENT of a bodypart given the bodypart's TYPE.
* MIME attributes (charset for instance) can be passed
as an argument to the composing tool
Let's be more precise: if MIME defines two Kanji charsets for
instance, fully compatible without order (I mean: mapping
possible but not immediate), MIME can compose a message containing
a Kanji text written using the first charset and composed using
the second charset. No problem if the mailcap file's entry for
this type contains a filter in its composing command...
Many of us already use a such mechanism for audio postings;
the composing line may be written as follows:
audiorecord | audioconvert -f %t > %s
So what ?
A SGML document, written in a given charset, can easily be sent
through a MIME message in a compound/sgml (Gosh ! What is the
current name of the SGML multipart in last draft ?) if the composing
command ("compose" and "composetyped" lines in mailcap file) runs
through/uses a SGML parser...
A SGML parser is able to extract from an instance its charset and
return it to the UA/Daemon through the "composetyped" entry.
I can't see there any conflict at all between SGML/HTML and MIME.
It is just another point pleading on SGML parsers' integration
behalf...
</Daniel>
PS: such a posting may generate flames from other MIME developers...
but I am sure that it is a defensible position.