I re-read the text regarding this in the current MIME draft, and
I honestly don't see what the problem is. The text reads:
| Default RFC 822 messages without a MIME Content-Type header
| are taken by this protocol to be plain text in the US-ASCII
| character set, which can be explicitly specified as:
|
| Content-type: text/plain; charset=us-ascii
|
| This default is assumed if no Content-Type is specified. In
| the presence of a MIME-Version header field, a receiving User
| Agent can also assume that plain US-ASCII text was the
| sender's intent. Plain US-ASCII text must still be assumed in
| the absence of a MIME-Version specification, but the sender's
| intent might have been otherwise.
|
| RATIONALE: In the absence of any Content-Type header field or
| MIME-Version header field, it is impossible to be certain that
| a message is actually text in the US-ASCII character set,
| since it might well be a message that, using some set of
| nonstandard conventions that predate this document, includes
| text in another character set or non-textual data in a manner
| that cannot be automatically recognized (e.g., a uuencoded
| compressed UNIX tar file). Although there is no fully
| acceptable alternative to treating such untyped messages as
| "text/plain; charset=us-ascii", implementors should remain
| aware that if a message lacks both the MIME-Version and the
| Content-Type header fields, it may in practice contain almost
| anything.
I interpret this as follows:
1. If a message is a MIME message (i.e. has a MIME-Version header),
any body part lacking a content-type header is to be interpreted
as if it had the content-type "text/plain; charset=us-ascii".
2. The interpretation of non-MIME messages (i.e. messages lacking
a MIME-Version header) is not bound by rule #1 (or by MIME at all)
So there is no requirement that a MIME user agent treat non-MIME
messages as if they were ASCII.
Keith