Re: [idn] Document Status?

[John C Klensin <klensin@jck.com>]

--On Friday, 13 September, 2002 09:07 +0900 Soobok Lee
<lsb@postel.co.kr> wrote:

> 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.

Normally, what the term "restriction" would refer to would be
rules that say "you cannot use that character at all" or "we
won't register any of the strings on this list as labels".
Precisely the case that is being excluded is one in which the
zone admin attempts to say "we are adding the following mapping
to those specified by nameprep" or "we are using the following
mapping instead of those specified by nameprep".   Mapping rules
-- rules that force one code point (or sequence of code points)
to be transformed into another to to be treated as equivalent to
another are not possibilities for local (or zone) variations.

If two code point sequences are different after nameprep is
applied, then the only way in which they can be made
"equivalent" in a given zone is by multiple registrations that
are connected by having identical targets (e.g., one is a DNS
CNAME pointing to the other or one has exactly the same RRs and
data as the other) or by mechanisms external to the DNS and
IDNA(e.g., if all URLs containing one of the FQDNs involve
protocols that can do redirects and that cause such redirects to
sites/ locations that have content for URLs with the other FQDN
substituted.

If the revised language doesn't make this clear enough, then
someone should propose other language.

> 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'.

That is probably not the best of examples, but, ignoring that,
any zone admin who has those concerns and wants to do something
about them is permitted only the following choices:

(i) Ban any registrations that contain latin 'i'

(ii) Ban any registrations that contain cyrillic 'i'

(iii) Ban both characters

(iv) Ban all IDN/ ACE-based registrations (of course, (iii) is a
special case of this.

(v) Insist, or automate a rule in which every registration of a
string containing latin 'i' be matched to one containing
cyrillic 'i' and vice versa.

> 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.

I don't understand this comment and its relevancy to the IDN WG.

     john