New draft, new idea

[Paul Hoffman / IMC]

Greetings again. Based on an idea originally proposed here by Keith
Moore, I have created yet another proposal. See
<http://www.imc.org/ietf-imaa/hoffman-iea-headermap-00.txt>, at least
until the Internet Drafts directory gets it published.

This proposal starts were Adam and I did with IMAA (be client-only),
but goes even further in making it unobtrusive. Basically, there is
an optional map in the headers which tell an MUA how to display
mailbox names in headers. Mailbox names remain the same: they just
get displayed differently.

Comments welcome.

--Paul Hoffman, Director
--Internet Mail Consortium

[John Cowan]

Post by Paul Hoffman / IMC
This proposal starts were Adam and I did with IMAA (be client-only),
but goes even further in making it unobtrusive. Basically, there is
an optional map in the headers which tell an MUA how to display
mailbox names in headers. Mailbox names remain the same: they just
get displayed differently.

I think this is the best idea yet. It will need some enhancement to
specify the legal character set (presumably the same as in IDNA)
in the displayedLHS.

The only downside I see is that users will have to publish two
email addresses in places like business cards (the hard copy kind),
and people who naively enter the wrong one into their down-level
clients will get bounces or other bad results. In addition,
if an email-address-assigner screws up and hands out the same displayedLHS
twice, we may have two mailboxes that appear to have the same address
at the MUA level.

[Paul Hoffman / IMC]

Post by John Cowan
In addition,
if an email-address-assigner screws up and hands out the same displayedLHS
twice, we may have two mailboxes that appear to have the same address
at the MUA level.

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
"José". The display is local to the MUA reading the message.

--Paul Hoffman, Director
--Internet Mail Consortium

[j***@reutershealth.com]

Post by Paul Hoffman / IMC
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
"José". The display is local to the MUA reading the message.

Ah, I didn't understand this. Then why not handle it as a fullname comment,
rather than something masquerading as a mailbox name? All that would be
required is some escaping convention for RFC 2822 comments.

[Martin Duerst]

Post by Paul Hoffman / IMC

Post by John Cowan
In addition,
if an email-address-assigner screws up and hands out the same displayedLHS
twice, we may have two mailboxes that appear to have the same address
at the MUA level.

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

Neither alternative sounds good to me at all.


Regards, Martin.

[Steve Hole]

Post by Paul Hoffman / IMC
This proposal starts were Adam and I did with IMAA (be client-only),
but goes even further in making it unobtrusive. Basically, there is
an optional map in the headers which tell an MUA how to display
mailbox names in headers. Mailbox names remain the same: they just
get displayed differently.
Comments welcome.

I like this idea *very* much. Simple in concept, simple to implement,
easy to deploy. The only real downside to is the maintenance of the
"canonical" ascii-only address which I'm sure that some people will have a
problem with just on principle.

This would work and could be made to work quite quickly. At the very
least it would be a good intermediate measure that might decide to stay
for the long run.

Cheers.

---
Steve Hole
Chief Technology Officer - Billing and Payment Systems
ACI Worldwide
<mailto:***@ACIWorldwide.com>
Phone: [phone]

[Arnt Gulbrandsen]

Post by Steve Hole
I like this idea *very* much. Simple in concept, simple to
implement, easy to deploy. The only real downside to is the
maintenance of the "canonical" ascii-only address which I'm sure that
some people will have a problem with just on principle.

Business card designers are sure to grrrrumble... but I suppose a simple
lookup protocol will do. After all, the lookup is only necessary when
someone is copying a unicode address from a business card or other
written source and the MUA needs the ascii-only one. I call that
O(acceptable).

Arnt

[Grant Baillie]

Post by Paul Hoffman / IMC
Greetings again. Based on an idea originally proposed here by Keith
Moore, I have created yet another proposal. See
<http://www.imc.org/ietf-imaa/hoffman-iea-headermap-00.txt>, at least
until the Internet Drafts directory gets it published.
This proposal starts were Adam and I did with IMAA (be client-only),
but goes even further in making it unobtrusive. Basically, there is an
optional map in the headers which tell an MUA how to display mailbox
names in headers. Mailbox names remain the same: they just get
displayed differently.

I'm new to the discussion, but here are some issues I see:

(1) What's to stop me from sending you a mail from some email address,
using address-map: to change its display value to
"***@your-bank.com", and asking you to reply with your credit card
#? It seems that there's a potential for a new kind of social
engineering attack here, unless MUAs are quite careful about how mapped
addresses are displayed.

Post by Paul Hoffman / IMC
Clearly, users of enhanced MUAs will expect to be able to enter mailbox
names in the native scripts. Therefore, MUAs that follow this
specification SHOULD keep mappings in their address book function.
Similarly, MUAs that follow this specification MUST be able to add
Address-map headers to outgoing mail messages.

I think there's more to it than just maintaining a mapping in the
client's local address book: Formats like vcard (and LDAP, I think)
would need to have some kind of standardized "display email address"
field to remain interoperable.

(3) There are implications for IMAP clients that fetch the ENVELOPE
message attribute to show message summary information: They wouldn't be
able to display addresses properly without issuing an extra header
fetch.

--------------------
Grant Baillie
Mac OS X Mail
Apple Computer, Inc.
--------------------

[Paul Hoffman / IMC]

Post by Grant Baillie
(1) What's to stop me from sending you a mail from some email
address, using address-map: to change its display value to
card #? It seems that there's a potential for a new kind of social
engineering attack here, unless MUAs are quite careful about how
mapped addresses are displayed.

The display name is only for the mailbox, so you have to already be
able to receive mail at the same domain name in order to spoof. In
your example, the sender has to be able to receive mail at
your-bank.com in order for this ruse to work.

Post by Grant Baillie
I think there's more to it than just maintaining a mapping in the
client's local address book: Formats like vcard (and LDAP, I think)
would need to have some kind of standardized "display email address"
field to remain interoperable.

Why a "display email address" field? Why not just a second email
address that has internationalized characters in the mailbox part?

Post by Grant Baillie
(3) There are implications for IMAP clients that fetch the ENVELOPE
message attribute to show message summary information: They wouldn't
be able to display addresses properly without issuing an extra
header fetch.

Good point.

--Paul Hoffman, Director
--Internet Mail Consortium

[Grant Baillie]

Post by Paul Hoffman / IMC

Post by Grant Baillie
(1) What's to stop me from sending you a mail from some email
address, using address-map: to change its display value to
card #? It seems that there's a potential for a new kind of social
engineering attack here, unless MUAs are quite careful about how
mapped addresses are displayed.

The display name is only for the mailbox, so you have to already be
able to receive mail at the same domain name in order to spoof. In
your example, the sender has to be able to receive mail at
your-bank.com in order for this ruse to work.

Oh, right. Still, I think there are possibilities for abuse (eg,
spoofing upper management inside a company, or other users in large
domains).

Post by Paul Hoffman / IMC

Post by Grant Baillie
I think there's more to it than just maintaining a mapping in the
client's local address book: Formats like vcard (and LDAP, I think)
would need to have some kind of standardized "display email address"
field to remain interoperable.

Why a "display email address" field? Why not just a second email
address that has internationalized characters in the mailbox part?

Hmmm.... I guess that would work. MUAs would just have to be careful
about using the (a?) non-internationalized address in the envelope /
headers.

--Grant

[Martin Duerst]

Hello Paul,

Overall, I'm glad you wrote up this proposal, even if I think
the main thing it does is show what we should not do.

Greetings again. Based on an idea originally proposed here by Keith Moore,
I have created yet another proposal. See
<http://www.imc.org/ietf-imaa/hoffman-iea-headermap-00.txt>, at least
until the Internet Drafts directory gets it published.
This proposal starts were Adam and I did with IMAA (be client-only), but
goes even further in making it unobtrusive. Basically, there is an
optional map in the headers which tell an MUA how to display mailbox names
in headers. Mailbox names remain the same: they just get displayed differently.

I have looked at this draft. I currently fail to see any serious functionality
that this is really adding. We already have display names that can be in
any language/script we want. 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 display names travel much
closer to the actual address, so the chance that the association gets
lost is clearly lower.

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.
I can also not see how the 'alternate' (internationalized) addresses
could get used in other places such as URIs/IRIs,...

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.

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.


Regards, Martin.

[Paul Hoffman / IMC]

Post by Martin Duerst
We already have display names that can be in
any language/script we want.

Display names are *not* mailbox names. Further, there is no
interoperability between display names unless all MUAs looking at the
message can display characters from the named character set.

Post by Martin Duerst
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. :-) 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.

Post by Martin Duerst
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.

Post by Martin Duerst
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.

Post by Martin Duerst
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. :-)
There is no effect on URIs: they remain as they are now. This spec is
for MUAs displaying names only.

Post by Martin Duerst
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?

Post by Martin Duerst
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?

Post by Martin Duerst

Post by Paul Hoffman / IMC
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.

Post by Martin Duerst
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,
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

[Martin Duerst]

Post by Paul Hoffman / IMC

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

Post by Paul Hoffman / IMC
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?

Post by Paul Hoffman / IMC

Post by Martin Duerst
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?

Post by Paul Hoffman / IMC
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 ***@example.com (or ***@EXAMPLE.COM)
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.

Post by Paul Hoffman / IMC

Post by Martin Duerst
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.

Post by Paul Hoffman / IMC

Post by Martin Duerst
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.

Post by Martin Duerst
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.

Post by Paul Hoffman / IMC
There is no effect on URIs: they remain as they are now. This spec is for
MUAs displaying names only.

Post by Martin Duerst
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.

Post by Paul Hoffman / IMC

Post by Martin Duerst
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.

Post by Paul Hoffman / IMC

Post by Martin Duerst

Post by Paul Hoffman / IMC
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.

Post by Martin Duerst
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,
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

[Paul Hoffman / IMC]

Post by Martin Duerst

Post by Paul Hoffman / IMC
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.

Post by Martin Duerst
(using upper-case for non-ascii)
Currently, I can't tell a user (e.g. in Mexico) to send a mail to

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

Post by Martin Duerst

Post by Paul Hoffman / IMC
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".

Post by Martin Duerst
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.

Post by Martin Duerst
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.

Post by Martin Duerst

Post by Paul Hoffman / IMC

Post by Martin Duerst
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.

Post by Martin Duerst

Post by Paul Hoffman / IMC
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.

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.

Post by Martin Duerst

Post by Paul Hoffman / IMC

Post by Martin Duerst
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.

Post by Martin Duerst

Post by Paul Hoffman / IMC
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.

Post by Martin Duerst
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

[Grant Baillie]

Post by Paul Hoffman / IMC

Post by Martin Duerst

Post by Paul Hoffman / IMC
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.

Post by Martin Duerst
(using upper-case for non-ascii)
Currently, I can't tell a user (e.g. in Mexico) to send a mail to

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

I think that by "(using upper-case for non-ascii)" Martin meant he was
using uppercase to represent arbitrary non-ascii characters in the
email addresses in his example.

--Grant

--------------------
Grant Baillie
Mac OS X Mail
Apple Computer, Inc.
--------------------

[Martin Duerst]

Hello Paul,

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

Post by Martin Duerst

Post by Paul Hoffman / IMC
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.

Post by Martin Duerst

Post by Paul Hoffman / IMC
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.

Post by Martin Duerst
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?

Post by Martin Duerst
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).

Post by Martin Duerst

Post by Paul Hoffman / IMC

Post by Martin Duerst
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.

[Adam M. Costello]

Post by Paul Hoffman / IMC
<http://www.imc.org/ietf-imaa/hoffman-iea-headermap-00.txt>

Like a few others, I have a hard time seeing what this would provide
beyond what we already have with display names.

*************************************************************
In the following examples, ALLCAPS stands for non-ASCII text.
*************************************************************

With the address-map approach, I could send mail to several recipients
with

From: FULLNAME <***@DOMAIN>
Address-Map: ***@DOMAIN,USER

where FULLNAME would be encoded as a MIME encoded-word, DOMAIN would be
encoded as an IDN ACE (in both places), and USER would be encoded using
UTF-8 & base64.

Recipients would see FULLNAME or its raw encoding depending on whether
they have MIME support. Recipients would see DOMAIN or its ACE
depending on whether they have IDN support. Recipients would see USER
or user depending on whether they have address-map support.

If I can already see FULLNAME and DOMAIN, how much added benefit do I
get from seeing USER instead of user?

If my MUA allows me to recall address book entries by typing in FULLNAME
(or part of it), how much benefit do I get from also being able to
recall them by typing in ***@DOMAIN?

Any decent implementation of address-map support is going to have to
take care to keep the maps in the address book, deal with collisions
(multiple entries with the same ***@DOMAIN), deal with inconsistencies
(one entry with multiple USER mappings), and allow searching by USER.

The same care could instead be used to keep display-names in the
address book, deal with collisions (multiple entries with the same
display-name), deal with inconsistencies (one entry with multiple
display-names), and allow searching by display-name.

There is no need to define any new structured syntax for display-names.
They don't need to look like email addresses or local parts in order to
provide essentially the same utility as address-map.

What display-names don't do is create the illusion of non-ASCII local
parts. But with address-map, it would indeed just be an illusion.
Users would see what appears to be an email address with non-ASCII
characters before the at-sign, but you can't send mail to it if you see
it on paper, and you can't put it into any other protocol that carries a
mail address in a protocol field (like mailto: URIs).

I fail to see what would be gained by deploying address-map.

IMAA, on the other hand, would actually provide some new functionality.
You could see an email address on paper with non-ASCII before the
at-sign, type it in, and it would work. And you could use that address
in *any* protocol that carries mail addresses.

Note that the address-map proposal assumes that IDN is used for
the domain part of mail addresses. If we're willing to accept the
limitation of the ACE approach after the at-sign (garbage-like display
in old end-user applications), we might as well accept the same
limitation before the at-sign. And if we expect clients to support IDN,
which entails Punycode and Nameprep and hooks for ToASCII/ToUnicode
conversions, then there's very little additional cost in supporting
IMAA.

AMC