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

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

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

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

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

>> there's no cost analysis for a proposal which would appear to have a 
>> huge cost.
>
> There's no cost analysis for your statement that it appears to have a 
> huge cost.

how hard is it to figure out that this impacts every component of the 
mail system, and that the cost is therefore huge?

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

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

>> whether email addresses are in raw utf-8 or encoded in ascii there is 
>> still a need to define how they are compared, because there will 
>> often be more than one utf-8 representation of an address.
>
> Just to be clear, are you talking about stringprep-based comparison, 
> or some other "utf-8 representation" issue?

stringprep would be one way of doing it.  but it's not sufficient to 
say "all addresses are in utf-8" and be done with that.

Keith