Re: Why not use the same decode way for the LocalPart as the way for the Domain Name in the IDN

dongxiaoli <[email protected]> wrote:

> Why not we use the same decode way for the LocalPart as the way for
> the Domain Name in the IDN.  For example in this way my name ??????
> will became xn--1jvp95dgxa, and now I have got some Free mail used
> this name.  One of these is [email protected].  Then I can use my
> Email address in Chinese Laguage: [email protected]

Paul Hoffman / IMC <[email protected]> replied:

> Because you can't *encode* many legitimate email addresses using IDNA.
> IDNA prohibits all ASCII characters other than LDH, so mailbox names
> like "jos=E9.mu=F1oz" could not be encoded.

That's true if UseSTD3ASCIIRules is set, but if we wanted to reuse
IDNA for local parts, we could specify that UseSTD3ASCIIRules is
never set for local parts, in which case ToASCII("jos=E9.mu=F1oz") =3D
"xn--jos.muoz-d1a7f".

I haven't thought about the various issues for a while, but at the
moment the only thing I can think of that prevents us from reusing IDNA
ToASCII for local parts is the problem with structured local parts.  For
example, both humans and computers commonly add and remove prefixes
and suffixes to local parts, like owner- and +tag.  The result will
be different depending on whether you are working with the ASCII form
(which is likely if "you" are legacy software) or the Unicode form
(which is likely if "you" are a human).

Xiaoli, have you seen the IMAA draft (draft-hofmann-imaa-03.txt)?  It
addresses this problem by applying Punycode (and half of Nameprep)
independently to segments of the local part.  It's a different ToASCII
operation, but it reuses the same Punycode and Nameprep algorithms that
IDNA uses.

AMC