Re: UUCP, etc., and SMTP/822/MIME mail (was: Re: I-D ACTION:draft-hoffman-utf8headers-00.txt)

At 23:58 04/01/01 -0500, Keith Moore wrote:

>Of course not, but nobody has really suggested that we do so.  At the same 
>time there are some things about email that were true then that remain 
>true now - one of which is that different pieces of the message header are 
>generated at different places by different agents, which won't all use the 
>same native character encoding and won't all get upgraded to utf-8 at the 
>same time.

This is a valid point, and it seems to lead to an interesting question
that I haven't seen discussed yet: For the SMPT extension proposed in
Paul's draft, and for Charles' header, what's the policy with respect
to stuff encoded with RFC 2047? In detail:

- Is a message tagged with Charles' header allowed to contain RFC 2047 stuff?
   (I would propose we say: MAY contain RFC 2047-encoded stuff)
- Is a message passed over SMTP with UTF-8-HEADERS allowed to contain
   RFC 2047 stuff? The way I understand SMTP extensions (experts on this
   list, please correct me if I'm wrong), this is a somewhat moot question,
   because it's the server that says what extensions it supports; the client
   doesn't say which extensions it uses (unless through the use of
   parameters in commands, but there are none for UTF-8-HEADERS).
   So my understanding is that RFC 2047-encoded headers are not disallowed.
- Does 'upgrade' include conversion from RFC 2047-encoded headers to
   raw UTF-8 (even if the RFC 2047 encoding doesn't use UTF-8)?
   I didn't find this in Paul's current draft; there is at the moment
   not yet much about upgrading overall. I would propose we say
   "upgrading MUST convert RFC 2047-encoded text to UTF-8 if the charset
   used in the RFC 2047-encoding is UTF-8, and SHOULD (or MAY?) convert
   RFC 2047-encoded text to UTF-8 if the charset used in the
   RFC 2047-encoding is not UTF-8.

So overall, it seems to me that there is neither a need nor an intention
to forbid cases where headers are added in different encodings, although
of course streamlining the encoding is highly advantageous.

Regards,   Martin.