Re: Question: full-width at

Roy> Question: is full-width-at the only character that contains the
Roy> at-sign in its compatibility decomposition?

John> No, there is also U+FE6B, the SMALL COMMERCIAL AT.

Roy> If not, should we perhaps consider converting the entire e-mail
Roy> address to NFKC before splitting at at-sign?

Roy> And I won't even ask what happens if you try and follow the at-sign
Roy> with a combining accent.

Roy> Actually, I will ask: assuming we just split at the at sign, the
Roy> domain name will begin with a combining accent.  How will IDNA treat
Roy> this?

These issues were considered for IDNA.  There are many characters that
decompose to dot (like U+FE52 small full stop, U+2024 one dot leader) or
decompose to strings containing dots (like U+2488 digit one full stop,
U+33C2 square AM).  Therefore, if a whole domain name is normalized
before being scanned for dots, it might result in a different number of
labels than if it had not been normalized.  We discussed whether IDNA
should require this pre-normalization.  Ultimately we decided that that
was getting too far into user interface issues.  IDNA instead focuses
almost entirely on individual labels, not whole domain names.  The
one exception is to require that three particular dot-like non-ASCII
characters be recognized as dots, just the three that we had reason to
believe would be likely to be input by users trying to type dots.

The IMAA draft follows this example.  It says as little as possible
about entire mail addresses, and focuses on the local part.  The
one exception is to require one particular at-like character to be
recognized as an at-sign, the one that we have reason to believe is
likely to be input by users trying to type at-signs.

As for initial combining characters, the same question arose with IDNA.
If a label begins with a combining character, will it combine with the
preceeding dot?  This was considered a user-interface issue that IDNA
should not address.

AMC