Normalisation and matching

Below are parts from the latest draft with my changes and comments.
They contain the basic things I cannot accept in current IMAA and
changes the viewpoint more to the international user and the future
(instead of the ASCII view).

   Dan
   


2. Terminology

     >An "internationalized local part" (ILP) is anything that satisfies
     >both of the following conditions: 
         >(1) It conforms to the same
         >syntax as a non-internationalized local part except that non-ASCII
         >Unicode characters are allowed wherever ASCII letters are allowed.
         (2) It is normalised using NFKC and have no forbidden
         characters (see NAMEPREP).
         (3) Maximum length is the same number of characters as
         in legacy ASCII local parts. Though it is recommended that
         the limit to be so large that it will never matter.
     The ToASCII operation must aways succeed on the above.
     (and Punycode cannot not have a 59 character limit)


     >An "internationalized mail address" (IMA) consists of an
     >internationalized local part, an ASCII at-sign, and an internationalized
     >domain name [IDNA], in that order.
     This is the IMA. An IMA is always normalised using NFKC.
     In free form text there may be e-mail addresses using
     wide characters or other unnormalised forms.
     An IMA is NOT case folded. An IMA is required to preserve case.

     Equivalence of local parts is defined in terms of the dequoted form
     (see above) and case-insensitive matching. All character having
     one-to-one character mapping and as well as any character that
     have a one-to-one-with-accents are matched.
     The character SHARP S (es-zet) does not match "ss". That is:
     Lasse do NOT match La<sharp s>e.

     >An "IMA-aware mail address slot" is defined in this document to
     >be a mail address slot explicitly designated for carrying an
     >internationalized mail address as defined in this document. The
     >designation may be static (for example, in the specification of
     >the protocol or interface) or dynamic (for example, as a result of
     >negotiation in an interactive session).
     As an IMA always is normalised the slow will always contain
     a well defined, easy to handle, e-mail address.


3. Requirements and applicability

3.1 Requirements

     IMAA conformance means adherence to the following four requirements:

>      1) In an internationalized mail address, the following characters
>         MUST be recognized as at-signs for separating the local part
>         from the domain name:  U+0040 (commercial at), U+FF20 (fullwidth
>         commercial at).

No! An IMA must be in normalised using NFKC. No wide characters
will be recognised. Only U+0040 may be recognized.
Applications using free text with embedded e-mail addresses or
applications having free form input fields must always follow the
rules of the normalised form (IMA).


>      4) If two mail addresses are equivalent and either one refers to a
>         mailbox, then both MUST refer to the same mailbox, regardless of
>         whether they use the same form of at-sign.

If the IMAs match the mailbox is the same.

>         Discussion:  This implies that non-ASCII local parts cannot be
>         deployed in domains whose mail exchangers are case-sensitive.

IMAs are required to preserve case so it is in principle possible.
But IMAs must be matched using case-insensitive matching so it could
only be used as some internal scheme.