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

At 12:15 AM -0500 1/1/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), and updated MUAs and MTAs generate headers in UTF-8. 
Non-compliant MUAs and MTAs will mess up whatever we do.

- What's the problem with having to scan the whole header? Why is 
this onerous for a terminal MTA? (It is already done by the MUA.)

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

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?

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

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

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

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

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

>nit: the document repeatedly says that non-ASCII text is encoded in 
>quoted-printable; this is incorrect.  RFC 2047 allows either a 
>variant of quoted-printable ("Q" encoding, which isn't quite the 
>same thing) or base64 ("B" encoding).

Right, I realized that after I sent it in. I'll be much more careful 
on the next version.

--Paul Hoffman, Director
--Internet Mail Consortium