On Thu, Sep 12, 2002 at 09:25:45PM +0000, Adam M. Costello wrote: > John C Klensin <[EMAIL PROTECTED]> wrote: > > > > Which protocols are not impacted? Recently you were saying how > > > important it is for DNS update protocols to have distinct return > > > codes for "invalid name" versus "inadmissible name", so this part of > > > the DNS protocol *would* be impacted by per-zone name restrictions. > > > > If the IDNA spec has any impact on any [other] DNS-related protocol, > > it falls outside the WG's scope. > > True, but irrelevant. The impact in question is the impact of > restrictions imposed by zone administrators, not the impact of IDNA.
What if the restrictions imposed by zone admin are to enforce the unifications which were not covererd by NFKC/casefolding of IDNA? For example, purely font-variant char pairs( e.g., some TC/SC ), look-identical-pairs of chars within a script, and thousands of pairs of look-similar chars. Those were not in ASCII names and were introducedd into DNS by IDNA'a nameprep component. Personally, i haven't seen any zone admin who enforces '1' and 'l' equivalence in his ASCII zone. But wrt IDN, i guess most (or all) zone admins will show serious concerns about ununified latin 'i' and cyrillic 'i'. And that is why some folks are working on 'IDN registration tool', as a post portem remedy, which cannot help dynamicly-updated-zones whose admins are trusting the ASCII and inadvertently the ASCII-tunneled IDN as well. I think this impact on DNS-protocols is caused by IDNA, not by zone admins who may not even get noticed of the introduction of IDN space in ASCII. Soobok Lee > Those restrictions are independent of IDNA. IDNA is not creating a new > power for zone administrators, they have always had this power to impose > additional restrictions. > > AMC
