Re: First strawman for UTF-8 headers proposal

Keith Moore <[email protected]> Sun, 30 Nov 2003 20:46:52 -0500
Newsgroups gmane.ietf.imaa
Message-ID <[email protected]>

On Saturday, November 29, 2003, at 09:28  PM, Adam M. Costello wrote:

> POP and IMAP, for example.  They transfer messages from one agent
> to another, like SMTP does.  Therefore, if SMTP needs a negotiation
> mechanism (UTF-8-HEADERS) to verify that the receiving agent can
> handle the new header format, then POP and IMAP will need an analogous
> negotiation mechanism for the same reason.  Maybe NNTP too, though I'm
> not clear on the relationship between news article headers and mail
> headers.  And any other protocol that transfers mail messages from one
> agent to another.

I was going to point that out, but you beat me to it.

Yes, POP and IMAP servers would need to be able to tell whether their 
clients supported UTF-8 headers on a per-session basis (since a lot of 
people use multiple mail clients) and to perform appropriate 
translation.

Then again, a lot of mail transfer protocols don't have any way to do 
negotiation at all.  Batch mail transmission (like UUCP) is still used 
in some places, and there are a lot of UNIX-style filters in use (like 
procmail) where the mail is piped to, or through, a filter, that don't 
provide any good way of doing such negotiation.

This is part of why I claim that if you're going to make that drastic a 
change to the message format, you need to change the format so much 
that it will be obvious to everyone that it's a completely different 
format that has to be handled with a completely different signal path.  
(Personally I'd prefer a regular, binary format that was designed for 
easy processing and extensibility. I'm sure a lot of people would 
prefer XML, which would still require us to encode non-text body parts.)

Again, I really don't think having UTF-8 headers puts us much closer to 
a solution to the problem at hand - which is to allow multiple 
representations of addresses in different languages and scripts.  (to 
which I might add -- without significant disruption of the mail 
system).   At best, providing unencoded UTF-8 headers would be 
orthogonal to a solution to the problem - actually I suspect it would 
impede adoption of a solution.