Distributed configuration of "private" IDNA (Re: IDNA and getnameinfo() and getaddrinfo())

Shawn Steele Shawn.Steele at microsoft.com
Fri Jun 18 22:00:20 CEST 2010

> This is because programmers think they are working with ascii, 
> and comparison algorithm with ascii is so simple. It is not for 
> "unicode stuff". It is for U-labels, but not for unicode strings in 
> general.

Well, yea, people don't handle Unicode very well, which is why it's a good idea to used globalized comparison APIs from whatever OS you're using to compare strings, so you don't have to rebuild it yourselves.  (Though you do need to know what flags to use and what APIs to call when :) 

If an app needs to compare domain names, they should call the domain name SDK's "CompareNames()" function.  Then that can ensure they're in canonical form or whatnot and do the right thing.  Of course that requires that someone make such a method for apps to call.

Abstraction is important.  Any app that's validating the IDNA2003 bidi rules by themselves now has to change because the bidi rules changed for IDNA2008.  Nothing about that app's space changed, only the rules for DNS it depends on.

All I'm trying to get at is that the abstraction is important.  People shouldn't embed detailed knowledge in layers where it doesn't belong.  Suppose people embed ACE and then "we (the WG/IETF)" decide that we'll allow UTF-8 DNS after all.  What happens then?  If they just embed Unicode and call "IsValidDomainName()", "CompareDomainName()", "MakeCanonicalDomainName()" or whatever's necessary, then it doesn't matter what happens to IDN in the future, when their library gets updated with any updated behavior, they'll still work.


More information about the Idna-update mailing list