Re: [idn] Prohibit CDN code points

[=?utf-8?B?dHNlbmdsbUDoqIjntrLkuK3lv4Mu5Lit5aSnLnR3?= <tsenglm@cc.ncu.edu.tw>]

----- Original Message -----
From: "Patrik Fältström" <paf@cisco.com>
To: "Masahiro Sekiguchi" <seki@jp.fujitsu.com>; "IETF-IDN"
<idn@ops.ietf.org>
Sent: Tuesday, January 22, 2002 2:59 PM
Subject: Re: [idn] Prohibit CDN code points


> --On 2002-01-22 09.37 +0900 Masahiro Sekiguchi <seki@jp.fujitsu.com>
wrote:
>
> >     For example, .cn domain can say "SC/TC mapping must be
> >     enabled for .cn" if it considers that decision serves the
> >     .cn domain name users best.  If another domain, say .us,
> >     finds contrary, it can say "SC/TC must be disabled for .us".
>
> This will not work because _all_ DNS servers in the world need to be able
> to fulfil matchings according to the rules the .cn TLD decides. That in
> turn means that all DNS servers need to have matching rules which is the
> sum of _all_ rules _all_ TLD's define (and subdomains to TLDs etc, because
> of course I want a special matching rule for my subdomain of .com!).
>
        I  think  "the matching rule of server" and "the SC/TC mapping must
be enable foe .cn " in client 's side before IDNA/nameprep  is different
approach.
        The switch in client based on ccTLD is the similar function of
nameprep( mapping , normalization and prohibit).
TC/SC character equivalence mapping is similar to  the mapping of  UNICODE
Alphabet  map  it to its counterpart of ASCII  alpnabet .  The switch will
control the TC/SC equivalence mapping is enabled and the result can be
passed and processed by  nameprep then send to Punny code encoder or not.
       If  TC/SC script should be indicated which one of  it correctly in
the .cn Domain , a  signal information per script can be associated with the
equivalence mapped code and they are passed to Punny code encoder to encode
it with case anotation for non-basic-code-point  part.
       The LDH DNS server still use one simple matching rule for any domain.
> This in turn leads by definition to one to me very complex matching
> algorithm which is context dependent and not one for each domain in the
> world.
>
> Noone have come up with such an algorithm.
>
> And, one thing DNS likes is when one label have the same matching
algorithm
> regardless of what "neighbour" labels are in the DNS packet. Leaving this
> strategy and have different matching rules for the same octets depending
on
> context is a _very_ big change to all existing DNS implementations.
>
> Don't go there.
>
>    paf
>
>