The ability is still there, albeit in another form, though I'm not 100%
certain it is rigorously enough defined. Quoting from the Internet
Draft version:
Additionally, all the character set subtypes of text are defined as
subtypes of "message." If a character set subtype is given, it applies
to the bodies, though not the names, of each of the encapsulated
message's header fields except the Content-XXX header fields, which must
be entirely in US-ASCII. Thus it can be used to represent address and
subject information in non-ASCII character sets. The character set
subtype does NOT apply to the body of the encapsulated message. Thus,
to encapsulate a message with non-ASCII characters in both the header
fields and in the body, you would need something like the following:
From: <ASCII form>
Subject: <ASCII form>
Content-type: message/iso-8859-2
From: <iso-8859-2-form>
Subject: <iso-8859-2-form>
Content-type: text/iso-8859-2
Message body in iso-8859-2 character set.
Am I right in thinking that this gives you what you need? Any UA that
is smart enough to handle mixed character sets in the fashion of the
earlier proposal can easily be made smart enough to dig out these
"second-level" headers.
It turned out there were lots of very nasty problems with putting any
non-ASCII material in the top-level headers, which is why the solution
was transformed to the one given above. -- Nathaniel