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 12:02 PM
Subject: Re: [idn] Document Status?


> Change topic again? How typical :-)

What change ? Track the history of ambiguity and zone admin problems in
this list.

> 
> Lets get back: There is two topic here.
> 
> 1. registry vs Nameprep
> 
> I have already answered you the Nameprep is okay. You have not make a case
> registry mapping is going to be a problem.

I and others already listed the case in this list.
the mapping won't be reflected in protocols and application comparisons
unlike that caseinsensitive matching of ASCII names.

> 
> 2. "ambiguity" of Nameprep/IDNA
> 
> You have only stated your opinion it is ambigous. You have absolute right to
> do so.
> But you have not stated any technical reasons why.

You keep on insisting that IDN introduces no new security problem than that of
'0' and 'o' in ASCII names. But that is not correct. IDN introduce the problem
of look-exactly-identical chars. That was not in ASCII names.

Soobok Lee

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