Re: [idn] Document Status?

[Soobok Lee <lsb@postel.co.kr>]

On Thu, Sep 12, 2002 at 09:25:45PM +0000, Adam M. Costello wrote:
> John C Klensin <klensin@jck.com> 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