<178475239.1012596275@localhost> Content-Type: multipart/alternative; boundary="------------050900070403070603010302" Sender: [EMAIL PROTECTED] 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 ><[EMAIL PROTECTED]> 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="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="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="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="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="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="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="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="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="mid:178475239.1012596275@localhost";> <pre wrap="">thanks and regards,<br> john</pre> </blockquote> <br> Erin Chen<br> <blockquote type="cite" cite="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:[EMAIL PROTECTED]";><[EMAIL PROTECTED]></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--
