[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[no subject]
<idn@ops.ietf.org>
Subject: Re: [idn] Chinese Domain Name Consortium (CDNC) Declaration
References: <3C5A6DAE.9040905@twnic.net.tw>
<178475239.1012596275@localhost>
Content-Type: multipart/alternative;
boundary="------------050900070403070603010302"
Sender: owner-idn@ops.ietf.org
Precedence: bulk
--------------050900070403070603010302
Content-Type: text/plain; charset=Big5
Content-Transfer-Encoding: 7bit
[Note: header field too long; To & Cc field have been snapped - JS]
Dear John,
John C Klensin wrote:
>Erin,
>
>Let me follow up Vint's note with some thoughts of my own,
>with the understanding that they are mine personally and may
>not reflect positions I would feel obligated to take as
>technical advisor to the IDN WG or as a member of the IAB; the
>WG or the IAB might well disagree with what I'm about to say.
>
I hope every one would try to rethinking about some contention.
>I believe it has been fairly well demonstrated by this point
>that there are _many_ problems that the protocols specified in
>the IDN WG core documents will not solve. Many of these
>problems involve Chinese Domain Names, many others do not. At
>the root of most of both types of problems lies a distinction
>between "identifiers" -- character strings used in narrow
>contexts and to which many restrictive rules can be applied--
>and "user-visible names". The latter must obey the rules of
>the languages in which they are constructed and written. If
>they do not, confusion and astonishment results.
>
I agree with you. Some requirement MUST be solved in Layer1 if it is
essentially define
identifiers. But some requirement SHOULD be solve in upper Layer if it
is not essentially
define identifiers.
>But, while some issues can be addressed with sufficient
>ingenuity, the DNS cannot, in general, solve user-visible name
>problems within the current design and basic DNS protocols.
>Again, this raises especially difficult problems for Chinese
>names, but there are problems of one sort or another with most
>languages. The solutions for those user-visible name
>problems, as we discussed in Minneapolis, lie in non-DNS
>mechanisms, protocols, and database, not in the DNS or the IDN
>WG's effort to fit some extra characters into the DNS.
>
It's nice to have chance to discuss with you in SLC(I know you mean
SLC).
>As we look at the IDN WG's efforts, it is important to
>remember, first, that Unicode (ISO 10646) is a tool. It is a
>tool that is better suited to some purposes than to others and
>it is one that was designed in the context of very complex
>tradeoffs. The WG chose to use that tool, largely because,
>given _their_ constraints, there were no plausible
>alternatives.
>
I agree with the IDN WG to use the well-defined part of Unicode. But
about equivalent TC/SC
is unwell-defined in the Unicode and it is also not the goal of Unicode
Consortium.
How can IDN stilll refer to the unwell-defined parts?
>Similarly, we should view the IDN WG's outputs --if, indeed,
>IDNA/ NAMEPREP/ STRINGPREP/ PUNYCODE turn out to be the
>outputs-- to be tools. They are not a perfect tool. It is
>easy to find problems they don't solve, and problems with
>characters that have equivalent meanings and different
>appearances and code points (as in TC<->SC mapping) and
>characters that have similar or identical appearances but
>belong to different scripts and have different code points (as
>in matching characters in Latin, Greek, and Cyrillic scripts)
>are high on that list of unsolved problems. But, again, they
>are a tool, and, while it quite drastic, I suggest that there
>is a registration-based solution if that tool is
>inappropriate.
>
Dear John, I'm afraid only the registgration-based solution still could
not overcome.
Even if there is a proper and well-defined registration policy(including
how to manage
the DNS zone file) but lack of corresponding technical solution to do
the police, the zone file
manager still can decide obey the policy or not. That will still cause
inconsistent DNS resolving.
As a identifier, the DNS would not be trusted.
>The IDN WG also has the constraints, ultimately imposed by the
>DNS architecture, that it cannot make a decision that solves a
>problem for Greek at the expense of Cyrillic, nor can it make
>one that solves a Chinese problem at the expense of making
>Japanese or Korean unusable. Perhaps the more subtle matching
>and
>equivalence problems are sufficient to make the whole notion
>unusable, at least for user-visible names. While I suspect
>that might be true, the argument has not been convincingly
>made.
>
>This suggests some actions you might consider:
>
>(i) Your colleagues argued quite persuasively in Minneapolis
>that the difficulties imposed by the IDN WG approach on
>Chinese-Language Domain names would cause serious consumer
>confusion and disruption and could be expected to provide an
>unreasonably good opportunity for fraudulent behavior. I
>believe that I understand that argument, but many of the
>people to whom your statement was addressed probably do not.
>I would strongly suggest that you try to produce a document
>that explains the problems, in a tutorial style, and at a
>level adequate to educate someone with no knowledge of Chinese
>and, perhaps no working knowledge of any script other than his
>or her own.
>
Yes, it is important to let others understand the problems.
>(ii) If registrations of CDNs are dangerous, prohibit them in
>your own ccTLDs and, with the document mentioned above as a
>tool, recommend to ICANN and directly to other domain
>administrators (top-level and otherwise) that these codes not
>be registered. That advice will, I fear inevitably, be
>ignored in some places. But, if the explanation of the
>consumer risks is clear enough, governments, regulators, and
>injured parties will have solid grounds for holding registrars
>who promote the use of such names responsible for any problems
>they cause.
>
Once the IDN become a standard without adopt CDN requirements or other
script requirements
you'v mentioned, the serious problem would have occored. User can not
wait during the gap
untill the another, later, better,complete solution, such as non-DNS
solutions.
We have to separate the problem and solution is proper to deal with in
DNS level or not. Some
requirements are belonging to DNS level must still solved in the DNS
level. Some requirements
are beloning to non-DNS level should develop non-DNS solutions.
As you mentioned above "identifiers" -- character strings used in narrow
contexts is belonging
to DNS level. Then "user-visible names" is belonging to non-DNS level.
As for TC/SC 1 to 1 mapping, fit in with the definition of "identifiers"
-- character strings used in
narrow contexts. So it MUST solve in DNS level.
And move the other rest of complexity TC/SC mapping ( 1 to n, n to 1, n
to n , context ) to the
upper Layer which is non-DNS solution.
>(iii) Please continue to work with me and with others to
>develop non-DNS solutions for user-visible names that do meet
>your needs by accomodating matching that uses language and
>other information in ways that the DNS cannot.
>
Yes, there are many complexity or user oriented requirements should be
developed by
non-DNS solutions. But, because it is non-DNS solution, so it could not
substitute DNS
resolving. Unless, close the DNS resolving and substitute by the non-DNS
solution.
>thanks and regards,
> john
>
Erin Chen
>
>--On Friday, 01 February, 2002 18:27 +0800 Erin Chen
><erin@twnic.net.tw> wrote:
>
>>--------------------------------------------------------------
>>----------- Chinese Domain Name Consortium (CDNC)
>>Declaration
>>--------------------------------------------------------------
>>-----------
>>
>>Based on current status of Internationalized Domain Name, CDNC
>>makes following declaration:
>>
>>1. Currently, IETF IDN WG begins Last Call for the WG core
>>documents (IDNA, NAMEPREP, STRINGPREP, and PUNYCODE).
>>
>>But, the architecture of IDN defined in above four documents
>>does not solve the traditional and simplified Chinese
>>character variant problem. That will cause serious delegation
>>problem in the application of Chinese Domain Name. This
>>technical flaw can't be compensated by registration policy;
>>it'll prevent Chinese Domain Name from being used widely. All
>>the future Internet applications based on Chinese Domain Name
>>hierarchy will fail and ultimately Chinese Domain Name
>>technology will result in failure.
>>
>>2. Under the commercial and social pressure, IETF IDN WG
>>issues Last Call hastily without presenting a proper Chinese
>>Domain Name technical solution. It will be detrimental to the
>>ethnic-Chinese Internet community.
>>
>>3. IETF IDN WG does not solve Chinese Domain Name technical
>>problem, but it is IETF IDN WG's responsibility to sincerely
>>consider the consequences from adopting these drafts. Under
>>the current condition, if IETF approves these IDN drafts,
>>registrars will open Chinese Domain Name registration without
>>considering the requirement of Chinese Domain Name and
>>Chinese Domain Name will fall into confusion. This will damage
>>Chinese Internet community seriously.
>>
>>4. IDN would be flawed by not adopting CDN requirements.
>>
>>Chinese Domain Name Consortium
>>CDNC Founding members: CNNIC, TWNIC, HKNIC/HKDNR, MONIC
>>Co-chair of CDNC: Qian Hualin, Professor
>>Co-chair of CDNC: Shian-Shyong Tseng, Professor
>>2002.2.1
>>--------------------------------------------------------------
>>-------------
>>
>>
>>
>>
>>
>>
>>
>>
>
--------------050900070403070603010302
Content-Type: text/html; charset=Big5
Content-Transfer-Encoding: 7bit
<html>
<head>
</head>
<body>
Dear John,<br>
<br>
John C Klensin wrote:<br>
<blockquote type="cite" cite="178475239.1012596275@localhost"">mid:178475239.1012596275@localhost";>
<pre wrap="">Erin,<br><br>Let me follow up Vint's note with some
thoughts of my own,<br>with the understanding that they are mine
personally and may<br>not reflect positions I would feel obligated to
take as<br>technical advisor to the IDN WG or as a member of the IAB;
the<br>WG or the IAB might well disagree with what I'm about to
say.</pre>
</blockquote>
I hope every one would try to rethinking about some contention.<br>
<blockquote type="cite" cite="178475239.1012596275@localhost"">mid:178475239.1012596275@localhost";>
<pre wrap="">I believe it has been fairly well demonstrated by this
point<br>that there are _many_ problems that the protocols specified
in<br>the IDN WG core documents will not solve. Many of
these<br>problems involve Chinese Domain Names, many others do not.
At<br>the root of most of both types of problems lies a
distinction<br>between "identifiers" -- character strings used in
narrow<br>contexts and to which many restrictive rules can be
applied--<br>and "user-visible names". The latter must obey the rules
of<br>the languages in which they are constructed and written.
If<br>they do not, confusion and astonishment results.</pre>
</blockquote>
I agree with you. Some requirement MUST be solved in Layer1 if it is
essentially
define<br>
identifiers. But some requirement SHOULD be solve in upper Layer if it
is
not essentially <br>
define identifiers.<br>
<blockquote type="cite" cite="178475239.1012596275@localhost"">mid:178475239.1012596275@localhost";>
<pre wrap="">But, while some issues can be addressed with
sufficient<br>ingenuity, the DNS cannot, in general, solve user-visible
name<br>problems within the current design and basic DNS
protocols.<br>Again, this raises especially difficult problems for
Chinese<br>names, but there are problems of one sort or another with
most<br>languages. The solutions for those user-visible
name<br>problems, as we discussed in Minneapolis, lie in
non-DNS<br>mechanisms, protocols, and database, not in the DNS or the
IDN<br>WG's effort to fit some extra characters into the DNS.</pre>
</blockquote>
It's nice to have chance to discuss with you in SLC(I know you mean
SLC).
<br>
<blockquote type="cite" cite="178475239.1012596275@localhost"">mid:178475239.1012596275@localhost";>
<pre wrap="">As we look at the IDN WG's efforts, it is important
to<br>remember, first, that Unicode (ISO 10646) is a tool. It is
a<br>tool that is better suited to some purposes than to others
and<br>it is one that was designed in the context of very
complex<br>tradeoffs. The WG chose to use that tool, largely
because,<br>given _their_ constraints, there were no
plausible<br>alternatives.</pre>
</blockquote>
I agree with the IDN WG to use the well-defined part of Unicode. But
about
equivalent TC/SC<br>
is unwell-defined in the Unicode and it is also not the goal of Unicode
Consortium.<br>
<br>
How can IDN stilll refer to the unwell-defined parts?<br>
<blockquote type="cite"
cite="178475239.1012596275@localhost"">mid:178475239.1012596275@localhost";>
<pre wrap="">Similarly, we should view the IDN WG's
outputs --if, indeed,<br>IDNA/ NAMEPREP/ STRINGPREP/ PUNYCODE turn out
to be the<br>outputs-- to be tools. They are not a perfect tool. It
is<br>easy to find problems they don't solve, and problems
with<br>characters that have equivalent meanings and
different<br>appearances and code points (as in TC<->SC mapping)
and<br>characters that have similar or identical appearances
but<br>belong to different scripts and have different code points
(as<br>in matching characters in Latin, Greek, and Cyrillic
scripts)<br>are high on that list of unsolved problems. But, again,
they<br>are a tool, and, while it quite drastic, I suggest that
there<br>is a registration-based solution if that tool
is<br>inappropriate.</pre>
</blockquote>
Dear John, I'm afraid only the registgration-based solution still could
not
overcome. <br>
Even if there is a proper and well-defined registration policy(including
how to manage <br>
the DNS zone file) but lack of corresponding technical solution to do
the
police, the zone file <br>
manager still can decide obey the policy or not. That will still cause
inconsistent
DNS resolving.<br>
As a identifier, the DNS would not be trusted.<br>
<pre wrap=""></pre>
<blockquote type="cite"
cite="178475239.1012596275@localhost"">mid:178475239.1012596275@localhost";>
<pre wrap="">The IDN WG also has the constraints, ultimately
imposed by the<br>DNS architecture, that it cannot make a decision that
solves a<br>problem for Greek at the expense of Cyrillic, nor can it
make<br>one that solves a Chinese problem at the expense of
making<br>Japanese or Korean unusable. Perhaps the more subtle
matching<br>and<br>equivalence problems are sufficient to make the whole
notion<br>unusable, at least for user-visible names. While I
suspect<br>that might be true, the argument has not been
convincingly<br>made.<br><br>This suggests some actions you might
consider:<br><br>(i) Your colleagues argued quite persuasively in
Minneapolis<br>that the difficulties imposed by the IDN WG approach
on<br>Chinese-Language Domain names would cause serious
consumer<br>confusion and disruption and could be expected to provide
an<br>unreasonably good opportunity for fraudulent behavior.
I<br>believe that I understand that argument, but many of the<br>people
to whom your statement was addressed probably do not.<br>I would
strongly suggest that you try to produce a document<br>that explains the
problems, in a tutorial style, and at a<br>level adequate to educate
someone with no knowledge of Chinese<br>and, perhaps no working
knowledge of any script other than his<br>or her own.</pre>
</blockquote>
Yes, it is important to let others understand the problems. <br>
<blockquote type="cite"
cite="178475239.1012596275@localhost"">mid:178475239.1012596275@localhost";>
<pre wrap="">(ii) If registrations of CDNs are dangerous,
prohibit them in<br>your own ccTLDs and, with the document mentioned
above as a<br>tool, recommend to ICANN and directly to other
domain<br>administrators (top-level and otherwise) that these codes
not<br>be registered. That advice will, I fear inevitably,
be<br>ignored in some places. But, if the explanation of
the<br>consumer risks is clear enough, governments, regulators,
and<br>injured parties will have solid grounds for holding
registrars<br>who promote the use of such names responsible for any
problems<br>they cause.</pre>
</blockquote>
Once the IDN become a standard without adopt CDN requirements or other
script
requirements<br>
you'v mentioned, the serious problem would have occored. User can not
wait
during the gap <br>
untill the another, later, better,complete solution, such as non-DNS
solutions.<br>
<br>
We have to separate the problem and solution is proper to deal
with in DNS
level or not. Some<br>
requirements are belonging to DNS level must still solved in the DNS
level.
Some requirements<br>
are beloning to non-DNS level should develop non-DNS solutions.<br>
<br>
As you mentioned above "identifiers" -- character strings used in narrow
contexts is belonging<br>
to DNS level. Then "user-visible names" is belonging to non-DNS
level.<br>
<br>
As for TC/SC 1 to 1 mapping, fit in with the definition of
"identifiers"
-- character strings used in<br>
narrow contexts. So it MUST solve in DNS level.<br>
<br>
And move the other rest of complexity TC/SC mapping ( 1 to n, n to 1, n
to
n , context ) to the<br>
upper Layer which is non-DNS solution.<br>
<br>
<blockquote type="cite"
cite="178475239.1012596275@localhost"">mid:178475239.1012596275@localhost";>
<pre wrap="">(iii) Please continue to work with me and
with others to<br>develop non-DNS solutions for user-visible names that
do meet<br>your needs by accomodating matching that uses language
and<br>other information in ways that the DNS cannot.</pre>
</blockquote>
Yes, there are many complexity or user oriented requirements
should be developed
by <br>
non-DNS solutions. But, because it is non-DNS solution, so it
could not
substitute DNS<br>
resolving. Unless, close the DNS resolving and substitute by the non-DNS
solution.<br>
<blockquote type="cite"
cite="178475239.1012596275@localhost"">mid:178475239.1012596275@localhost";>
<pre wrap="">thanks and regards,<br> john</pre>
</blockquote>
<br>
Erin Chen<br>
<blockquote type="cite"
cite="178475239.1012596275@localhost"">mid:178475239.1012596275@localhost";>
<pre wrap=""><br>--On Friday, 01 February, 2002
18:27 +0800 Erin Chen<br><a class="moz-txt-link-rfc2396E"
href="mailto:erin@twnic.net.tw";><erin@twnic.net.tw></a>
wrote:<br><br></pre>
<blockquote type="cite">
<pre
wrap="">--------------------------------------------------------------<b
r>----------- Chinese Domain Name Consortium
(CDNC)<br>Declaration
<br>--------------------------------------------------------------<br>--
---------<br><br>Based on current status of Internationalized Domain
Name, CDNC<br>makes following declaration:<br><br>1. Currently, IETF
IDN WG begins Last Call for the WG core<br>documents (IDNA, NAMEPREP,
STRINGPREP, and PUNYCODE).<br><br>But, the architecture of IDN defined
in above four documents<br>does not solve the traditional and simplified
Chinese<br>character variant problem. That will cause serious
delegation<br>problem in the application of Chinese Domain Name.
This<br>technical flaw can't be compensated by registration
policy;<br>it'll prevent Chinese Domain Name from being used widely.
All<br>the future Internet applications based on Chinese Domain
Name<br>hierarchy will fail and ultimately Chinese Domain Name<br>t
echnology will result in failure.<br><br>2. Under the commercial and
social pressure, IETF IDN WG<br>issues Last Call hastily without
presenting a proper Chinese<br>Domain Name technical solution. It will
be detrimental to the<br>ethnic-Chinese Internet community.<br><br>3.
IETF IDN WG does not solve Chinese Domain Name technical<br>problem,
but it is IETF IDN WG's responsibility to sincerely<br>consider the
consequences from adopting these drafts. Under<br>the current condition,
if IETF approves these IDN drafts,<br>registrars will open Chinese
Domain Name registration without<br>considering the requirement of
Chinese Domain Name and<br>Chinese Domain Name will fall into
confusion. This will damage <br>Chinese Internet community seriously.
<br><br>4. IDN would be flawed by not adopting CDN
requirements.<br><br>Chinese Domain Name Consortium <br>CDNC Founding
members: CNNIC, TWNIC, HKNIC/HKDNR, MONIC<br>Co-chair of CDNC: Qian
Hualin, Professor<br>Co-chair of CDNC: Shian
-Shyong Tseng,
Professor<br>2002.2.1<br>-----------------------------------------------
---------------<br>-------------<br><br><br><br><br><br><br> <br></pre>
</blockquote>
<pre wrap=""><!----><br></pre>
</blockquote>
<br>
</body>
</html>
--------------050900070403070603010302--