[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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
JOSE@xxxxxxxxxxxx With the new proposal, I will still not be able to
tell somebody to send a mail to JOSE@xxxxxxxxxxxx In both cases, I
need to give jose@xxxxxxxxxxxx
Also, currently, I can have jose@xxxxxxxxxxx replaced (for users
with newer MUAs) with something like "JOSE RAMIREZ", or even
most probably "JOSE@xxxxxxxxxxx". (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 JOSE@xxxxxxxxxxx (or JOSE@xxxxxxxxxxx)
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