Re: [idn] Document Status?

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

----- Original Message ----- 
From: "James Seng" <jseng@pobox.org.sg>
To: "Soobok Lee" <lsb@postel.co.kr>; "IETF idn working group" <idn@ops.ietf.org>
Sent: Friday, September 13, 2002 11:09 AM
Subject: Re: [idn] Document Status?


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

Nameprep/stringprep's NFKS/Casefolding introduced the ambiguity into the DNS
and IDNA's ACE concept tunneled "that different beasts" through the trusted or
unsuspected ASCII namespace for which existing dns/application protocols 
have no filtering mechanism, while some of them have builtin filtering machanisums for
non-ASCII 8-bit strings now, like BIND or SENDMAIL.

If this IDNA were introduced in early 1980 or 1990, at that time, many protocols 
authors would have wanted to insert some sphiscatred filtering mechanisms for 
ambiguous IDNs in their drafts.

Soobok Lee

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