Re: New draft, new idea

Hello Paul,

I think overall, Adam has expressed very well what I tried
to express in my first mail on this subject.

At 16:28 04/02/05 -0800, Paul Hoffman / IMC wrote:

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

Address-Map: headers and the additional display capabilities they
provide have nothing to do with mail transmission. The email gets
to exactly the same address totally independently of what's in
the Address-Map: header, or if there is one or not.

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

Ok. In practice, I don't think this is such a big problem,
as I think we can guess that a MUA that supports IDNs will
also support UTF-8 display strings, and MUAs used in certain
regions also support the popular charsets in that region.

The reason we need UTF-8 for addresses, rather than e.g.
iso-8859-1 or just an undefined string of bytes, is that
we need to be able to match addresses.


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

I agree that there has been almost no convergence to date
(if we look at actual emails sent, this is definitely the case,
and if we look at products supporting UTF-8, the situation is
not much better, although some products supporting UTF-8 are
very widely used).

The question is whether this proposal will be helping
convergence to UTF-8 or not. In particular, how much
faster would convergence be with this proposal as opposed
to no solution at all? How much faster would convergence
be with this proposal as opposed to IMAA? As opposed to
your and John's drafts moving to UTF-8 in headers?



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

By new protocol element, I meant the Address-Map: header,
and the non-ASCII LHS (which is something totally different,
except in the display of some MUAs, from the LHS of the
actual mailbox name).


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

Ok. It is sometimes possible to fix implementation problems
with a new spec. But why do you think it's the case here?


Regards,   Martin.