Re: New draft, new idea

At 6:04 PM -0500 2/5/04, Martin Duerst wrote:
>>Display names are *not* mailbox names.
>
>Yes. But from an end-user's perspective, where exactly is the difference?

The difference exactly is that the display name can be changed or 
omitted when entering an email address and the mail still gets to the 
correct destination. Display names are optional and have nothing to 
do with mail transmission.

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

Huh? In what program? Mailbox names are case-sensitive. Some 
terminating SMTP servers will change case, but that's not part of the 
protocol.

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

Yes, exactly. That's why I said "character set".

>  Clearly this could be improved (e.g. by converging towards
>UTF-8),

Those of us who have researched this know that there has been almost 
no convergence to date.

>  but do we need a new protocol element for this?

You seem to have gotten confused. The proposal at hand is for the 
mailbox name, and you keep talking about the display name. Again: 
they're completely different protocol elements.

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

The implementation.

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

If you feel that this is important, please write a protocol proposal 
that says how to use display names for this purpose. I believe that 
when you do so, you will find that you cannot have it work with 
current MUAs which change and sometimes destroy display names.

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

The proposal here explicitly says that the MUA can display the 
internationalized mailbox name in any character set. Nothing in the 
proposal is trying to get MUAs to adopt UTF-8 in headers any faster 
than they are now.

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

That was a year ago. Maybe this should be kicked upstairs to see of 
some leadership can get the two documents out faster.

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

All the secure mail standards already talk about how to check 
certificates. I cannot see the value of saying "check certificates 
just like you have been". What am I missing here?

--Paul Hoffman, Director
--Internet Mail Consortium