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