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

On Sun, Jan 04, 2004 at 05:35:19PM -0000, Charles Lindsey wrote:
> 
> On Sun, 4 Jan 2004 10:59:29 +0100 (CET), Dan Oscarsson 
> <[email protected]> wrote:
> 
> 
> >I prefer not to have a header, only negotiation before transfer of data.
> >If a header is used (there is a problem with a header due to it have to
> >be before all other headers to simplify message handling), the rules 
> >should
> >be the same as fpr SMTP negotiated UTF-8
> 
> You can make negotiation before transfer a REQUIREMENT of some extended 
> SMTP, but SMTP is not the only mail transport protocol around, and you 
> cannot impose such a blanket requirement on _every_ transport protocol, 
> both existing and not yet invented.
> 
> That is why you need both the negotiation (for those protocols which you 
> are in a position to specify) AND a header (for those you can't).

This illustrates that this is not a safe way to extend the mail
protocol.  You cannot just tell the other end that they need to
understand whay you say, eg that this is a 8bit utf-8 header.
The other end may not be prepared to do so. The safest way to extend
the mail protocol - which causes the least interoperability problems
with the current installed conforming base - is to have all headers 
still in 7 bit. 

Thus we need to encode ito 7 bit, and the encoding into 7 bit should be
done at the originating MUA. This is a requirement that is not too
difficult to get working, as this is also where the information on
receiver and sender addresses, with possible non-ascii characters, is done,
and this is also where current MIME encoding of names in comment fields
are done (which are encoded in 7 bit), so the functions are already
available.

Whether the 7 bit encoding should just be what we already have in MIME,
or always some form of 10646 is not fully clear, but I tend to think
that some form of 10646 would be the best, for interoperability.
Maybe punicode could be used, or utf-7 or my mnemonic downgrading from
RFC 1345, if anybody still remembers that, or something new.
It would be nice if the 7-bit encoding was kind of readable in raw form,
and I think it sould be based on 10646, not unicode, for standards
conforming reasons (as the technical differencese are almost
negligeable).

Best regards
keld