Re: [idn] Document Status?

["James Seng" <jseng@pobox.org.sg>]

First, the point you raise is related to Nameprep/Stringprep, not IDNA.
Please dont confuse the two document.

If the registry choose to do additional mapping which will cause
incompatible with the Nameprep, then two things should happen:

a) The registry should revise its policy to be compatible with Nameprep
   (It is possible. See
    http://www.ietf.org/internet-drafts/draft-jseng-idn-admin-00.txt)

b) If they choose not to, then they choose not to be compatible with
Nameprep. In such case, they shouldnt complain. (Beside, IETF does not
enforce anyone on compatibility)

But lets get back: Nameprep is a client-side normalization. It is not
designed to handle the registry issues . Registry issues should be handled
in other sets of documents.

-James Seng

----- Original Message -----
From: "Soobok Lee" <lsb@postel.co.kr>
To: "IETF idn working group" <idn@ops.ietf.org>
Sent: Friday, September 13, 2002 8:07 AM
Subject: Re: [idn] Document Status?


> 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
>
>