rough sketch of a potential solution

This is intended to be a rough sketch of something which I'm wondering
might be a solution.  

Obviously there are a lot of details to work out, but offhand I think this
basic approach looks workable.  I'd appreciate it if initial comments on this
were about the feasability of the basic approach that could make or break
it, rather than about protocol or implementation details.  IMHO, IETF WGs
often slow themselves down by expecting fully-worked-out specifications for
initial proposals. So comments about such details should wait for a detailed
specification.  Please use your best judgement about whether such comments are
appropriate at this stage.

--

In a nutshell, there are two parts of the problem:

1. a sender wants to be able to type in a recipient address that is easy
to remember and/or transcribe (from paper or sounds)

2. a recipient wants to be able to remember or transcribe a recipient
address (to paper or sounds) in such a way that it can be used later,
or given to another potential sender

Note that the sender and recipient may not share the ability to use
language/script in which an address was supplied by the sender.

-- 

Parts of a potential solution:

1. Define a way to list zero or more equivalent addresses (in various 
languages and/or scripts) for each address in a semder or recipient
message header

- Every address in a message header would have a distinguished,
  "fallback" address expressed in (hopefully transcribable) ASCII.  
  These addresses would go in the normal From/Reply-To/To/CC/Bcc etc.
  fields.

- Each of those addresses could optionally have zero or more equivalent
  local-parts listed, which could be expressed in various languages/scripts.

  (I say equivalent local-parts instead of equivalent addresses, because
  it minimizes the potential for problems.  For instance, it prevents 
  unscrupulous address mappers from using this as a mechanism to 
  transparently forward mail for certain addresses to sites that haven't 
  agreed to accept it - it also avoids synchronization errors of a
  similar nature that could occur by accident.)

- There could optionally a signature on the mapping, so that it could be 
  verified

This would provide a way by which a recipient (with an upgraded MUA)
could see the address for each sender and recipient of the message
(i.e. those listed in the message header) which was the most readable/
transcribable/memorable TO THAT RECIPIENT of those available.  Recipients 
without upgraded MUAs would see only the fallback addresses.

2. Define an "address mapping service" which could, given an address
typed by the sender, produce a list of alternative forms of that
address in various languages and scripts.

- The server would be reached by converting the typed domain into an
  IDN, and looking up a SRV record for the address mapping service
  at that domain.

  (alternatively: the service could be implement using SMTP and the
   mapping service provided by the primary MX.  this has some
   advantages - it makes it easy for the primary MX to stay in sync
   with the mappings, but also some disadvantages - increasing load
   on the SMTP server and being problematic for domains whose
   advertised primary MXes are only relays and do not have authorititave
   information about address mappings)

- The addresses returned would be as follows:
  1 distinguished fallback address in ASCII
  0 or more alternative local-parts, along with language and script
  indicators.  each of these local-parts would be in the same domain 
  as the original.

- There could optionally bea signature on the mapping, so that it 
  could be verified

This would allow the sender's upgraded MUA to accept a single typed-in
address from the sender (in any language/script supported by the
mapping service) and obtain a list of alternative forms of that address,
along with the ASCII fallback address.

The address mapping service could potentially also minimize problems
due to multiple ways of representing the same or similar characters
in some languages.

3. The IMAA address encoding mechanism, or a similar mechanism for
encoding addresses into legal 822-style ASCII addresses


Here's how I see these being used by an upgraded MUA:

Display - An upgraded MUA will display each address in the form that
best suits the recipient's preferences.  If no such form is available,
the ASCII fallback will be displayed.  An MUA doing display of a 
message WOULD NOT use the address mapping service - both to minimize
load on the mapping service and to prevent the mapping service being
used as a means to know when the recipient is reading the message.

Compose - For each address supplied by the sender, the sender's MUA would
attempt to lookup alternative forms of the address.  If alternative forms are
found, the fallback form would be used in the from/reply-to/To/cc/bcc/etc 
fields, whereas the alternative forms would be encoded in "equivalent-address"
fields.  Otherwse (e.g. if the server were not reachable, were not supported,
or returned an error), the IMAA encoding of the typed-in address would be used
in the  from/reply-to/to/cc/bcc/etc field.

(alternatively: the sender's mail submission server would do the lookup.
this would let the lookup be done in "batch mode" rather than delaying
the submission of a message, but it would also prevent sender-signed 
messages.)

Replies - Like Compose, except that the fallback and alternative addresses 
would be obtained from the message header of the message being replied to. 
Any newly typed-in addresses would be obtained as in Compose.  If the reply
were to a message that did not contain alternative addresses, the replying
MUA could look up the alternatives using the address mapping service.

Submission - In all cases, the fallback form (whether obtained from the
mapping service or IMAA-encoded) would be used in the envelope of mail
submission and relay protocols.   Since the fallback addresses would be used
in  legacy-format sender and recipient message headers also, this would
produce the least-surprising behavior for legacy mail handling software.

(alternatively: The format of each addreses used in the envelope would be
the IMAA-encoded version of the address which was either (a) the one typed
by the message sender, or if the address was obtained from the header
of another message,  the alternative that is in the language and script
preferred by the message sender.  that way, any DSNs that were returned
would reflect the addresses most meaningful to the sender)

Legacy MUAs would display, and reply to, the fallback address forms that
were stored in the traditional places in the message header.  Replies
from legacy MUAs would not contain alternative address forms, but any
replies to those replies from upgraded MUAs would contain alternative
address forms if they were available.)

MTAs do not have to change except that they would somehow need to know about
alternative addresses .  No matter which alternative is used the message needs
to end up at the same mailbox. 


--


Notes

- There's really no need for substantial changes in the existing ASCII-based
header format - as moving to UTF-8 headers still wouldn't provide a means of
listing alternatives, and this seems to be a necessary feature.

- The address mapping service would appear to most benefit sites that had a
large portion of usernames in languages using ideographic scripts or using
alphabetic scripts that were based on other than the Latin alphabet, and
especially sites for which addresses would be difficult to transcribe
precisely due to different ways of representing the same or similar
characters.   Sites have the option of installing an address mapping service
or not doing so depending on the benefit they perceive from doing so.  In the
absence of the address mapping service, IMAA-encoded addresses would be used. 
The address mapping service basically permits less "ugly" addresses than
IMAA-encoded addresses to be substituted when they are available.