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:
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.
This is only half of the needed info. While I now know in which
character set to interpret this line, I cannot send it!
Subject: <iso-8859-2-form>
This is a 8 bit text entity in the headers of the message part, the
headers of the body part need to be encoded in quoted printable, which
is prohibited.
Rewritten to make this more clear....
From: <ASCII form>
Subject: <ASCII form>
Content-type: message/iso-8859-2
From: <iso-8859-2-form> * Untransportable
Subject: <iso-8859-2-form> * Untransportable
Content-type: text/iso-8859-2
Content-Encoding: Quoted-Printable
Message body in iso-8859-2 character set.
Where the Content-encoding really is intended to apply to the
headers as well as the body of the part. Problem is, how to read the
headers to find the encoding if they are encoded!
A possible solution is to consider the ISO8859-2 headers to be another
bodypart so the document looks like
From: <ASCII form>
Subject: <ASCII form>
Content-type: multipart; 1-S; fooboundary
-- fooboundary
Content-type: message/partial/iso-8859-2
Content-encoding: quoted-printable
Content-comment: These are the headers smashed for transport
From: <iso-8859-2-form>
Subject: <iso-8859-2-form>
-- fooboundary
Content-type: message/partial/iso-8859-2
Content-encoding: quoted-printable
Content-comment: This is the body
Message body in iso-8859-2 character set.
-- fooboundary
This is now a legal message. I may even propose a message/headers
subtype if this is the prefered mechanism, but it really seems like a
kludge.
Greg V.