Subject: Re: [idn] Document Status?

From: "Adam M. Costello" <[email-masked]>
Date: Wed, 04 Sep 2002 08:13:34 -0700

In case my recent exchange with JFC has left anyone with the impression
that IDNA is complex, here is IDNA in a nutshell:

  * Every ASCII domain label is an internationalized label, but some
    internationalized labels are not ASCII.

  * Some ASCII labels are unsuitable for display to users.  They are
    called ACE labels.

  * For every internationalized label X, there is an equivalent
    ASCII label ToASCII(X), and there is an equivalent non-ACE label
    ToUnicode(X).  When you need the ASCII form (for using protocols
    that expect ASCII) you can use ToASCII to obtain it.  When you need
    the non-ACE form (for display to users) you can use ToUnicode to
    obtain it.

  * Two internationalized labels X and Y are defined to be equivalent
    iff ToASCII(X) and ToASCII(Y) match case-insensitively.

That is the essence of IDNA.  That much can be understood without any
need to know what ToASCII, ToUnicode, and ACE really are.

By the way, I made a slight error in my previous message:

> Notice that ToUnicode(ToASCII(X)) is not always X, it is Nameprep(X)
> (which is equivalent to X).

For any internationalized label X, ToUnicode(ToASCII(X)) is indeed
equivalent to X, but it's not necessarily Nameprep(X).  It is
Nameprep(X) if X is non-ASCII.

AMC

---

From: Erik Nordmark <[email-masked]>
Date: Mon, 9 Sep 2002 12:41:17 +0200 (CEST)

> Our interpretation is correct.

s/Our/Your/

  Erik

---

From: Erik Nordmark <[email-masked]>
Date: Mon, 9 Sep 2002 12:40:56 +0200 (CEST)

I need to get better at proof-reading my own email :-(
Sorry for 

> I have to vested interest in the IDNA specification but I'm merely

s/to/no/

> rough consensus documents is to point out specific issues and suggested
> text from clarifying things, since I have a hard time understanding how

It would read better with:
"... and suggest text that clarify things"

  Erik

---

From: "Soobok Lee" <[email-masked]>
Date: Fri, 13 Sep 2002 11:54:03 +0900

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

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