Re: rough sketch of a potential solution

> Some immediate concerns with your proposals:
> 
> * Disconnected mail clients?  Mail clients that sit behind a gateway
>   (e.g., UUCP, Enterprise e-mail solutions like Outlook)?

With those, you get the fallback behavior of encoding everything
in IMAA.  Either that or for unsigned messages the lookup can be
deferred until the message is injected into the Internet mail system.

> * Privacy leaks?  I would not want my client to hit the net every to
>   look up a internationalized name for an incoming message, or even
>   the first time. 

The proposal specifically mentions this.  MUAs only look up 
alternatives when composing messages, not when reading them,
and this is one of the reasons.

> * Secure e-mail.  What should MUAs display as the sender address?  The
>   ASCII version or non-ASCII, looked up via the service you propose?

They should show the address in the sender's certificate as the party
who signed the message, which shouldn't have to be the same as the From
address anyway.  The addresses in the message header should be displayed
separately.

Again, MUAs don't do the address mapping lookup when displaying a message.

>   How do you secure the service connection?  

If necessary, TLS should be sufficient.

>   What should be stored in
>   OpenPGP or S/MIME attributes; the ASCII version or non-ASCII
>   version?

This needs more thinking, but I think you want to use either the 
ASCII fallback address or the IMAA form of the "native" address
as the principal name.   If the signature format can support 
multiple names for a principal, any of the alternative addresses
could also be used, provided that all principal names are included in the
sender's certificate.  Naturally the devil is in the details.

> * Internationalization of MTAs?  Having ASCII in MTA configuration
>   files or log files is not sufficient.

MTAs are free to log alternative address forms if they wish.  

Log file format is in any event a locale-specific issue, so it's not clear
that it would be appropriate for an MTA to log an unencoded UTF-8 address to a
log file on a system that used some other charset in its locale.

> Essentially this proposal appear to add a i18n-layer for e-mail, a
> "presentation" layer if you wish, on top of RFC 2822 and SMTP.  While
> this may be preferable for ASCII people, having i18n as an "add-on"
> appear rather fragile to me.  But that's only my initial reaction.

Even if we were designing a new mail system from scratch to handle these
requirements, I think we would need a lookup across the net at the time
that the message is composed (or submitted) in order to handle the case where
at least one recipient can't transcribe the sender's "native" address.  Of
course with careful attention to detail alternative addresses could be 
"cached", say in address books, to avoid live net lookups some of the time.

Keith