Re: [idn] Document Status?

["Soobok Lee" <[e-mail]>]

----- Original Message ----- 
From: "Soobok Lee" <[e-mail]>
To: "James Seng" <[e-mail]>; "IETF idn working group" <[e-mail]>
Sent: Friday, September 13, 2002 11:50 AM
Subject: Re: [idn] Document Status?


> 
> ----- Original Message ----- 
> From: "James Seng" <[e-mail]>
> To: "Soobok Lee" <[e-mail]>; "IETF idn working group" <[e-mail]>
> 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

Sorry. s/some of them/ some implementations of those protocols /

> 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 

Sorry.  s/sphiscatred/sophisticated/.

Lee

> 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" <[e-mail]>
> > To: "IETF idn working group" <[e-mail]>
> > 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 <[e-mail]> 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
> > >
> > >
> > 
>