[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [idn] Prohibit CDN code points
Dear John, Dave and all:
There are some basic different points in this thread , If
we can classify them then we may lead to the same conclusions.
1. TC/SC is not a global issue and not only a local issue. That is say,
TC/SC is related to chinese language locally but the TC/SC characters in
UNICODE is related to CJK area. There are two additional attributes, (
TC/SC-name, lang, area).
2.The requirement of preserving of TC/SC scripts information in DNS zone
file and client's display for manager and users is necessary, but it do not
necessary to preserve in the level 1 lookup and comparing phase of LDH-DNS
query. That is say , the basic DNS capability and anotationalized Puny Code
encoder/decoder of IDNA are enough.
3.The searching/mapping from (TC/SC-name,lang,area) --->
string-with-some-signalized-UNICODE--character --->
anotational-Puny-coded-ACE-string can be a client side solution with
multi-layer-module or alternative-class approach . But a client side
solution to do this mapping from (TC/SC-name, lang,area) -->
string-with-signalized-UNICODE-character is just like the issue in IRNSS.
From multiple attributed record mapping to a signalized-UNICODE-string can
be describe by the rule : If (TLD == area && source-native-language
==lang) then f1 else f2. The rule is in the higher level , it is a
localization or area related issue. It is not operated on LDH-DNS server.
4. Now, we need to know does it is possible and existed some interface to do
nameprep of IDNA to let the mapping can do correctly :
string-with-signalized-UNICODE-character --->
anotational-Puny-coded-ACE-string
5. A lower/upper case mixed LDH-domain name never change and increase burden
to current LDH-DNS.
6. At the time to define how to process of multiple attributed record
mapping into a string-of-signalized-UNICODE-characters , we need to know the
interface existed and TC/SC IDN will not be mis-used in current IDNA
architecture.
L.M.Tseng
----- Original Message -----
From: "John C Klensin" <klensin@jck.com>
To: "Dave Crocker" <dhc@dcrocker.net>
Cc: "IETF-IDN" <idn@ops.ietf.org>
Sent: Wednesday, January 23, 2002 7:00 AM
Subject: Re: [idn] Prohibit CDN code points
> --On Tuesday, 22 January, 2002 08:06 -0800 Dave Crocker
> <dhc@dcrocker.net> wrote:
>
> > In general, threads like the current one are examples of a
> > failure to appreciate the complexity of creating special
> > conditions and rules for Internet protocols. Such
> > idiosyncrasies in protocols make them much more difficult to
> > implement correctly and usually destroy their ability to scale
> > well.
>
> Now it is my turn. While Dave and I have a history of
> disagreeing about many things, I appreciate his kind words about
> my analysis of the equivalency problem. And the above
> summarizes, much better than I have been able to do, one of the
> key problems we face in trying to make language-specific,
> country-specific, or script-specific rules.
>
> The DNS, especially as represented by contemporary
> implementations, is a fairly complex bit of protocol work.
> Given that complexity, the code base, and some history of
> fragile or incorrect setup of various domains, it is a
> testimonial to the quality of the design that it works at all,
> and does so without frequent major disruptions. It is very hard
> to imagine that we could change the protocols and implementation
> to support a potentially-large collection of "if TLD isthe X,
> isrules Y and then..." and "if the TLD the SLD is Z" while
> preserving the current level of robustness. And, while adding
> a Class would help isolate the current DNS from the problems
> this would cause, it wouldn't make the ultimate complexity, or
> risk, any lower.
>
> We've heard a number of suggestions on this list by people who
> have preceeded their remarks with words like "I am not an
> implementor, but...". This is the point --and the robustness
> and scaling issues that Dave identifies are the key-- at which
> looking at the problem and not at the protocol infrastructure
> becomes a problem. And so, I would strongly encourage those who
> are suggesting "equivalence", or language-specific, or
> script-specific systems to be sure they have recently read and
> understood the basic DNS protocol standards and, preferably,
> taken a careful look at the code for BIND or some equivalent
> implementation.
>
> john
>
>