Re: I-D ACTION:draft-hoffman-utf8headers-00.txt

At 9:46 PM -0500 1/2/04, Keith Moore wrote:
>>>having a single flag to say that fields are in utf-8 is ridiculous 
>>>- first because the fields aren't all generated at the same place, 
>>>and second because (as you point out) you potentially have to scan 
>>>the whole header anyway to find the new header field.
>>
>>Neither of those arguments seems that relevant.
>>
>>- It doesn't matter if all are generated in the same place, just 
>>that they are all generated the same way. Non-updated MUAs and MTAs 
>>generate headers in UTF-8 (that is, in ASCII, a proper subset of 
>>UTF-8),
>
>actually, they generate headers in a variety of charsets.

I'm not sure what you mean. All headers are in the ASCII character 
set currently.

>>>but as far as I'm concerned putting utf-8 in headers is a 
>>>nonstarter anyway.  there's simply no justification for  it.
>>
>>The justification is that the only proposal that doesn't involve 
>>non-ASCII in the headers, draft-hoffman-imaa-03.txt, has two fairly 
>>significant side-effects, namely that senders who have not updated 
>>their MUAs will not sanely be able to initiate mail to non-ASCII 
>>mailboxes
>>and that recipients who have not updated their MUAs will see gibberish.
>
>both of those side-effects also exist for your utf-8 header proposal.

That is false on both counts. Please show examples.

>>At 1:06 AM -0500 1/1/04, Keith Moore wrote:
>>
>>>there's no justification given for utf-8 headers.  the desired 
>>>functionality can be accomplished by the address-map fields and 
>>>encoding the fields in ascii.
>>
>>Maybe I'm being dense, but I don't see how. Are you saying that 
>>	this would be an MUA-only type protocol (like IMAA), except 
>>that the sender would use an "upgrade" address in the address map?
>
>more-or-less, yes.

OK, this is an interesting proposal. Lemme think about it more. (Feel 
free to post relevant protocol stuff for it, but I think I see where 
you are going.)

>>>there's no explanation as to where the address-map information 
>>>would be obtained.
>>
>>I'll make that clearer. They would be bootstrapped from incoming 
>>address-map headers. That is, your downgrade map would be in your 
>>outgoing mail, and receiving MUAs would be able to build a cache 
>>it. Of course, you can also simply tell people your downgrade 
>>address.
>
>I suspect that we will still need the address mapping lookup server, 
>but that's a separate issue.

If you can show that need, I would certainly have to deal with it in 
this draft. But I don't see the need, just the desire.

>>>even accepting that it's a good idea to allow email addresses in 
>>>raw utf-8 (and this is a stretch) many fields should remain ascii 
>>>so that they can be read anywhere.  it will often make more sense 
>>>to put ascii-encoded addresses, message-ids, etc. into log files 
>>>than to put raw utf-8 there.
>>
>>There is nothing in the protocol that prevents that, of course. The 
>>thing that writes into the log file can convert from UTF-8 to its 
>>desired encoding.
>
>then the logs are meaningless.  there's no reason for message-ids to 
>be in utf-8.

You're the second one to say this, so I'm happy to have Message-ID: 
remain ASCII, like Date:.

>>>there are too many mail transport boundaries that don't use SMTP 
>>>and thus may have no way to negotiate utf-8.
>>
>>What you are saying is that the 2822 format is locked into stone 
>>because different protocols that use 2822 do not talk. Others would 
>>disagree with that assessment.
>
>no, I'm saying that SMTP is the wrong place to try to negotiate a 
>change in message format (massive leakage of 8bit MIME into 
>non-8-bit SMTP demonstrates this), that expecting SMTP to handle the 
>conversion is moving complexity in the wrong direction (and bouncing 
>is a nonstarter), and trying to cram utf-8 into a format designed 
>for ASCII (and pretending that this is a minor change) is a much 
>worse idea than designing a format that is obviously distinct (and 
>which can actually result in a simplification, unlike 2822 with 
>utf-8 header fields).

OK, that's much clearer than what you said before. Don't do 
"pretty-much-like-2822", do "really new header format".

--Paul Hoffman, Director
--Internet Mail Consortium