Thank you for sharing the background on the CDNC IDN Table used the Chinese community! If there is any additional information you could share regarding harmonization practice, if any, would welcome your contribution to facilitate the group’s discussion. Best Regards, Ariel From: Zhang Zuan <zuanzhangpetergreen@hotmail.com> Date: Wednesday, May 10, 2023 at 2:30 AM To: Ariel Liang <ariel.liang@icann.org> Cc: "gnso-epdp-idn-team@icann.org" <gnso-epdp-idn-team@icann.org> Subject: 回复: [Ext] Re: IDN Table Presentation - 11 May Hi Ariel and all, Apology for the belated response. The Chinese community uses CDNC table, which was developed by CDNC, i.e. the Chinese Domain Name Consortium, an independent non-profit organization, jointly founded in May 2000 by CNNIC, HKIRC, MONIC and TWNIC, the four NICs of China’s Mainland, Hong Kong, Macau and Taiwan. Before the CDNC was founded, there were organizations and companies who conducted research on Chinese domain name solutions and used different tables. The aim and mission of CDNC is to coordinate and develop a consistent Chinese table based on RFCs related to Chinese domain names. The CDNC table includes Simplified Chinese, Traditional Chinese and variants (of Simplified and Traditional Chinese). The table uses the RFC 3743-defined format, and is in compliance with the ICANN Guidelines for IDN registration and for publication in the IANA. Only the code points in the table can be open for registration. To update the CDNC table, any CDNC member is required to submit an application to the CDNC Secretary first. The CDNC Secretary refers it to an Expert Panel to evaluate the application. If approved, the CDNC Secretary would solicit comments of CDNC members. Finally, the Board of CDNC shall have a review of the application. If all is approved, the application shall be effective and the CDNC table would be updated. Hope the above information is of any help. Best Zuan ________________________________ 发件人: Ariel Liang <ariel.liang@icann.org> 发送时间: 2023年5月10日 7:43 收件人: Michael Bauland <Michael.Bauland@knipp.de>; Tan Tanaka, Dennis <dtantanaka@verisign.com>; m.alzoba@gmail.com <m.alzoba@gmail.com>; zuanzhangpetergreen@hotmail.com <zuanzhangpetergreen@hotmail.com> 抄送: Steve Chan <steve.chan@icann.org>; Emily Barabas <emily.barabas@icann.org> 主题: Re: [Ext] Re: IDN Table Presentation - 11 May Hello all (and particularly Michael and Dennis), As promised, welcome your input for the proposed slide deck ahead of the call, if possible. I understand time is rather limited, but if there is any blatant inaccuracy, especially on slide 8, I would appreciate your comment! https://docs.google.com/presentation/d/1WhHBPGuxEsHU2hPN3HuQaa14rJCNMywwSG4W... [docs.google.com]<https://urldefense.com/v3/__https:/docs.google.com/presentation/d/1WhHBPGuxE...> Thank you, Ariel On 5/9/23, 2:55 PM, "Ariel Liang" <ariel.liang@icann.org> wrote: Thanks for the information you shared, Michael. I think I understand more now, and will definitely appreciate that you share the harmonization practice you are familiar with, so the group can gain better understanding when deliberating on the questions. I will work on a slide that lists the gist, and will welcome your input! Best Regards, Ariel On 5/8/23, 6:02 AM, "Michael Bauland" <Michael.Bauland@knipp.de> wrote: Hi Ariel, On 05.05.2023 19:58, Ariel Liang wrote: > Hello Michael, > > Thanks for the explanation. So basically the "canonical form" is not exactly "primary", but an arbitrary designation by the registries based on the code point of the variant label? You mentioned that the canonical code point may not be allowed in a IDN table, what does it mean? This just means that the canonical code point may be a code point that is not among the list of code points for that IDN table. Take for example a Cyrillic IDN table that of course does not allow any Latin characters. That table then has the allowed code point U+0430 (CYRILLIC SMALL LETTER A) The canonical code point would be U+0061 (LATIN SMALL LETTER A). So the canonical code point for U+0430 is a code point that is not allowed according to its IDN table. It's nevertheless used to calculate the canonical form of a label (which can even become a mixed-script label, but that's no problem, because it's only an internal representation used for variant checks). > > I think this is the type of information that Donna/Justine hope you and others from registries and registrars could share with the EPDP Team, with regard to how IDN tables are used when someone attempts to register an IDN label at the second-level. We recall you offered to do a small presentation of how Tango (?) implements IDNs at the second-level. Would this presentation that you offered to do be relevant to our discussion of the IDN table harmonization and format? As I mentioned last week, I found a problem in our internal harmonisation process. With our current tables it's just a theoretical problem, but still it's there. Therefore I'm not sure if it's helpful, that I present how we are dealing with harmonisation, if it's not working in all cases. If you still think it's helpful, I can say a few words of what we're doing. Cheers, Michael -- ____________________________________________________________________ | | | knipp | Knipp Medien und Kommunikation GmbH ------- Technologiepark Martin-Schmeisser-Weg 9 44227 Dortmund Germany Dipl.-Informatiker Fon: +49 231 9703-0 Fax: +49 231 9703-200 Dr. Michael Bauland SIP: Michael.Bauland@knipp.de Software Development E-mail: Michael.Bauland@knipp.de Register Court: Amtsgericht Dortmund, HRB 13728 Chief Executive Officers: Dietmar Knipp, Elmar Knipp