Re: changes between imaa-01 and -02

 > >     Should IMAA support case-sensitive mail exchangers?  No.
 > 
 > I thought we made clear that yes. And that you made clear that punnycode 
 > had no problem with it .
 > 
 > Or am I wrong on the meaning. We need [email protected]  to land as 
 > [email protected]. Up to Wanadoo to reduce it if it wants to 
 > [email protected] or to [email protected] or not.

Assuming that the localpart may be internationalized (eg contains
accented characters), we would need to use mixed case annotation in
punycode.  But, as well as adding complexity, it isn't really enough
to solve the problem.

German users will probably be unhappy that their name Strau<es-zet>
gets mapped to strauss which is, essentially, a mis-spelling of their
name.  Mixed-case anotation, as I understand it, can't capture the
distinction between ss, SS and es-zet.

So, I would like to propose an alternative solution: don't attempt to
tackle mixed case anotation at all within IMAA, but create a companion
document to handle e-mail address presentation forms.

Here's how it would work.  An MUA that chooses to implement this
protocol would add a series of headers of the following form:

IMA-Presentation-Form: <ASCII-email-address> <base64-encoded-UTF8-IMA>

one for each IMA in the From/To/Cc headers.  A cooperating receiving
MUA would search each ASCII address (either ACE or traditional)
against the presentation form headers, and if it finds a match, would
select the appropriate IMA as the prefered presentation of that
address (after first performing ToASCII on it and verifying that it
maps to the address you started with).

This allows cooperating MUAs to solve the problem of case, es-zet, and
any other distinctions lost by NFKC or case folding -- if they think
it's important.  It also allows MUAs that don't wish to do this not to
be burdened with any extra complexity.

	-roy