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

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

according to the standards, yes.  that's not entirely true in the real 
world.
>
>>>> 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.

existing MUAs can't sanely initiate mail to non-ASCII mailboxes.  
they're not set up to accept UTF-8 input.  they're not set up to look 
up IDNs.  they're not set up to stringprep local parts or to encode 
them in a way that's compatible with either SMTP or other MUAs.

existing MUAs can't display non-ASCII mailboxes as anything but 
gibberish.  if they're in utf-8 form, they look like gibberish unless 
the output device happens to display utf-8.  if they're in ACE form, 
they still look like gibberish, but for a different reason.

this is going to be true regardless of whether the revised message 
format ends up representing addresses in raw utf-8 or encoded in ASCII. 
  the on-the-wire encoding is completely orthogonal to these issues.

>> 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.

I don't know how much "need" there is either.  Maybe we need market 
research.

though I would want to think about the security implications of caching 
address maps from previous messages.  getting them from an oracle 
associated with the recipient's domain seems much safer.