Re: [EAI] IDN in Unicode

[John C Klensin <[e-mail]>]

--On Friday, April 24, 2015 19:21 +0000 Shawn Steele
<[e-mail]> wrote:

>> The basic propose is to find solution for IDN domains and
>> email addresses be present in original scripts.  
> 
> That seems like a completely different discussion than "let's
> use UTF-32".  

I think that is the point that Martin, Andrew, myself, and maybe
others have been trying to make.

> Many applications handle domain names natively in either UTF-8
> or UTF-16, either of which are sufficient to describe the
> domains in their original scripts.  
> 
> Punycode is kind of a hack to provide a mechanism to resolve
> domain names using the preexisting infrastructure that is
> limited to the ASCII space.  However many applications, like
> EAI, prefer UTF-8.

I wouldn't characterize either the Punycode algorithm or its
results in quite that way.   It may be that one person's hack is
someone else's elegant solution.   It is also worth noting that
Punycode is part of a fairly complex system of rules for IDNA
that deal with a number of issues other than the
ASCII-compatibility one.  If it were not for those issues, it
might have been plausible to note that the DNS can support
labels containing of a string of arbitrary octets, develop a
convention for identifying such strings as containing UTF-8 when
appropriate, and then simply tell people to wait until the
relevant protocols were upgraded.  There are multiple reasons
why IDNA (and hence the Punycode algorithm) was a better idea
for domain names, with two important ones being the symbolic
importance of claiming to have deployed IDNs and the desire of
some members of the ICANN community to start selling IDN labels
as soon as possible with usability as a secondary consideration.

> Our recommendations provide for IDN to be looked up with
> Punycode only in the resolution phase.  For many apps that is
> transparent to the app and they can just use Unicode with the
> system API set.  Some apps, however may need to recognize
> Punycode domains for whatever reason or additional protocol
> limitations.  However in those cases it is still recommended
> that they prefer Unicode and only use the Punycode when
> absolutely necessary.

That is in essence what RFC 6055 says although there are some
nuances that might be worth attention.   In addition and
independent of when the Punycode algorithm is applies, there are
some significant advantages to applying the tests for U-label
validity as early in the process as possible.  If that is not
done, error reporting is likely to deteriorate into "you lose"
or complaining about strings the user has never seen rather than
being able to report problems to users in and with contexts that
make sense to them.

    john