Re: New draft, new idea

At 13:19 04/02/05 -0800, Paul Hoffman / IMC wrote:

>At 2:45 PM -0500 2/5/04, Martin Duerst wrote:
>>We already have display names that can be in
>>any language/script we want.
>
>Display names are *not* mailbox names.

Yes. But from an end-user's perspective, where exactly is the difference?
(using upper-case for non-ascii)
Currently, I can't tell a user (e.g. in Mexico) to send a mail to
[email protected]. With the new proposal, I will still not be able to
tell somebody to send a mail to [email protected]. In both cases, I
need to give [email protected].
Also, currently, I can have [email protected] replaced (for users
with newer MUAs) with something like "JOSE RAMIREZ", or even
most probably "[email protected]". (Never tried to put somethnig
that looks like an internationalized email address into a display
name; my guess is that according to standards, this should work,
but it may fail because of sloppy implementations.)


>Further, there is no interoperability between display names unless all 
>MUAs looking at the message can display characters from the named 
>character set.

Are you speaking about the fonts/glyphs needed for display?
Even with the new proposal, there is always the possibility
that your MUA doesn't have glyphs available to display a script
recently added to Unicode.

Or are you speaking about the fact that RFC 2047 allows different
charsets, and each MUA will only be able to deal with a subset of
them? Clearly this could be improved (e.g. by converging towards
UTF-8), but do we need a new protocol element for this?


>>  There are user agents that when they find a
>>display name, they almost completely isolate the user from the actual address
>>(MS Outlook Express is the one I know).
>
>And look how well that works. :-)

Is that a problem of the implementation, or of the spec?


>Seriously, that functionality is one of the major causes of mail sent to 
>the wrong people, because someone picked out an email "name" from their 
>address book.

Okay, so you are saying that [email protected] (or [email protected])
is better than JOSE RAMIREZ, because it is unambiguous. That's
a valid point, but I still could do the former with display
names, or get display names and nicknames better organized.


>>  And display names travel much
>>closer to the actual address, so the chance that the association gets
>>lost is clearly lower.
>
>That would only be true if the display names were universally displayable. 
>They're not. In fact, it is the small minority that are encoded with 
>UTF-anything.

I would definitely like to see more data in UTF-8 and more mailers
supporting UTF-8 (mine currently doesn't). But I don't see this
proposal as a big-enough gain for people to create enough pressure
on the developers to fix the problem.


>>With this proposal, people in China or Japan or India,... will still
>>have to use ASCII addresses on their business cards, letterheads,...
>>even for language-internal communication. In that sense, the proposal
>>provides significantly less functionality even than the IMAA draft.
>
>True. It has less functionality, and fewer problems. This group needs to 
>determine where on those axes we want to be.
>
>>I can also not see how the 'alternate' (internationalized) addresses
>>could get used in other places such as URIs/IRIs,...
>
>If the IRI spec ever got finished, we might be able to tell. :-)

Well, currently I'm waiting for RFC2396bis, because in San Francisco,
I got told that that would be done much earlier. If we went back
to base the syntax on the old version of RFC 2396, we would be
done quite quickly.


>There is no effect on URIs: they remain as they are now. This spec is for 
>MUAs displaying names only.
>
>>Although by using base64, code can be reused, the raw base64 means
>>that for 'middleware' that analyses/filters/... mails, new code
>>may have to be written.
>
>Could you elaborate? The Base64 appears in a new header. Why would 
>middleware care about it?

Ok, sorry for not being clear. What I meant was that if you used
=?utf-8?B?.....?=, it would be more generic and would be easier
to handle, because it is one less special case.


>>Security issues should not just mention digital signatures, but
>>should also say that unless such certificates are checked every
>>time the email address is used, it can lead to problems because
>>an email address will look like something but may actually be
>>something completely different.
>
>The Security Considerations section talks only about certificates, not 
>about signatures. I don't see the effect on digital signatures; could you 
>elaborate?

Sorry, the first line should have said certificates, not signatures.
What I meant was that point (1) in Grant's original mail should be
mentioned (limited to the same domain, as you have explained).

Regards,   Martin.


>At 2:57 PM -0500 2/5/04, Martin Duerst wrote:
>>>Not at all. The display name has no connection to the mailbox name 
>>>anywhere other than in the MUA. Therefore, two people at ccil.org could 
>>>say the display name for their two different mailboxes is "Jose'". The 
>>>display is local to the MUA reading the message.
>>
>>Well, in theory, this is true. However, as far as I understand, the
>>Address-map headers and therefore these mappings travel from one
>>MUA to another.
>
>Correct.
>
>>  So conflicts would inevitably arise, either by having
>>the MUA keep two mappings with the same display LHS but different
>>ascii addresses (which would sooner or later have the wrong thing
>>sent to the wrong mailbox because the user cannot distinguish
>>these two), or by the MUA saying "You've got mail. By the way,
>>there is an Address-map header for =Jose'@example.com= different
>>from the one I already have, should I overwrite the mapping?".
>
>Also correct. IMAA had definitive, one-to-one mappings. This proposal has 
>non-definitive, make-them-up-as-you-go mappings.
>
>--Paul Hoffman, Director
>--Internet Mail Consortium