Re: [idn] Document Status?

["James Seng" <[e-mail]>]

Change topic again? How typical :-)

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.

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.

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