Re: if you really want utf-8 headers...

--On Friday, 02 January, 2004 18:18 +0100 Thomas Roessler 
<[email protected]> wrote:

> On 2004-01-01 12:40:59 -0500, John C Klensin wrote:
>
>> 	1.2 We invent message/rfcNNNN, where "rfcNNNN" basically
>> 	says "just like RFC2822, but all header fields are
>> 	defined as being in UTF-8, not ASCII".
>> 	
>> 	1.3 The gateway converts all envelope addresses to IMAA
>> 	form and encapsulates the original message using
>> 	message/rfcNNNN, so we have a MIME body of...
>>
>> 	   From: "1342/2047 PersonalName"
>> 	       <IMAA-local-part@IDNA-domain>
>> 		To: "1342/2047 PersonalName2"
>> 	       <IMAA-local-part2@IDNA-domain2>
>> 	   Date: RFC2822-date
>> 	   MIME-Version: 1.0
>> 	   content-type: message/rfcNNNN
>> 	   content-type-encoding: <as needed>
>> 	
>> 	   <original message, with original headers, in original
>> 	form>
>>
>> 	I hope we can avoid it, but a charset parameter for
>> 	message/rfcNNNN would certainly not be rocket science to
>> 	define.
>
>> 	1.4 Clever receiving systems notice "message/rfcNNN" and
>> 	unwind the situation in some appropriate way, with no
>> 	information loss.   And note that the model above is
>> 	pure, unextended, MIME and hence causes no Received or
>> 	Return-path issues at all.  Non-clever receiving systems
>> 	are going to make users unhappy.
>
> Wouldn't that construction violate MIME's "no nested encodings"
> rule when transferred in a 7bit environment?

I didn't think so, but I'm not an adequate expert on the 
convolutions of that rule.   If it did, moving to something like

    multipart/used-to-be-utf8-headers; boundary = "--foo"
        --foo
        message/utf-8-headers
>       content-transfer-encoding: ...

        <header text>
        --foo
        message/ ???

        <message text, possibly encoded>
        --foo--

would seem to work, although it would unquestionably be less 
attractive.

     john