July 2014 - ChineseGP - lists.icann.org

CGP Fortnightly Meeting
by Han Chuan Lee July 22, 2014

July 22, 2014

Hi all, This is a regular fortnightly meeting for the CGP to meet and discuss. Adobeconnect: icann.adobeconnect.com/CGP Adigo Bridge ID: 35105106

1 0

Discussion on CGP Proposal between ICANN and CGP members
by Han Chuan Lee July 9, 2014

July 9, 2014

When: Thursday, July 10, 2014 4:00 PM-5:00 PM. Malay Peninsula Standard Time Where: Adigo Conference ID: 35105106 *~*~*~*~*~*~*~*~*~* Hi, The IDN team would like to go through the proposal submitted by the CGP. This will be conducted over teleconference (Adigo conference ID: 35108106) and Adobeconnect (http://icann.adobeconnect.com/CGP) Dial in number for Adigo: http://www.adigo.com/icann Regards Han Chuan, Lee

1 0

[Ques] 76 Chinese gTLD applications: 32 vs. 44
by KIM Kyongsok July 2, 2014

July 2, 2014

Dear everybody: I am reading "CGP Proposal Draft 23 June 2014" and encountered the following statement: *CDNC put forwards its guiding rules for Chinese domain name registration:* *- The IDL and its Variant Labels SHOULD belong to the same registrant.* *- The Simplified Chinese form and Traditional Chinese form of the applied-for IDL SHOULD be resolvable simultaneously or non-resolvable at all.[1] <file:///A:/$00_0_0_ICANN50_LHR_20140622_27/CGP_proposal/CGP%20Proposal%20Draft%2023%20June%202014.docx#_ftn1>* *In 2013, among 76 Chinese new gTLD applications, 32 applications abide by the CDNC Character Set and guiding rules.* 1) I would like to get more detailed information regarding 32 gTLD applications which abided by the CDNC rules and 44 which did not; 2) Furthermore, out of 32 gTLDs, how many (and what) gTLDs were approved and how many (and what) were not. 3) In addition, out of 44 gTLDs, how many (and what) gTLDs were approved and how many (and what) were not. Thanks in advance. Rgds, KIM, K.

1 0

Re: [ChineseGP] Issues raised in the CJK meeting today
by 齐超 July 1, 2014

July 1, 2014

Hello Asmus, I appreciate your elaborate explanation. From your mail and document of variant rules, the XML model can contain all variants from RFC3743, also can define the variant rules (registration rules), which make it look like a little more complicated than plain text. As for the overlaps from those scripts, there ought to be one rule of variant mapping for a certain code point, like 'U+4E7E;U+....', but several variant rules for it from hani, kanji or hanja in root zone LGR. According to the experience of registration for second level tld, variant mapping and variant rules applied in '.ASIA', '.CN' or '.JP'. The LGR would be fulfilled soon if the variant mapping is fully accepted . I think it is more difficult to extend the root LGR mappings and rules to second level tld, which may modify the regular registration practice now. Thanks. 齐超 via foxmail 发件人： Asmus Freytag 发送时间： 2014年7月1日(星期二) 上午2:29 收件人：齐超抄送： chinesegp-bounces; integrationpanel 主题： Re: Issues raised in the CJK meeting today On 6/30/2014 10:16 AM, 齐超 wrote: Hello, Asmus and CGP Members, I am qichao from CNNIC and my job is registration support for Chinese Domain Name based on RFC 3743. I was not in ICANN London, and I wonder what are the issues between LGR XML and RFC 3743, because there is an appendix B in http://tools.ietf.org/html/draft-davies-idntables-07#appendix-B on how to translate RFC 3743 to XML, So the issue maybe not a technical problem, but a question from different scripts, I guess. Dear Qichao, I would be interested in confirming that the method in appendix B is correct. Just to make sure that we do not have a technical issue. About the scripts question: For example, the appendix list a code from .ASIA in draft: U+4E7E;U+4E7E,U+5E72;U+4E7E;U+4E81,U+5E72,U+6F27,U+5E79,U+69A6 U+4E81;U+5E72;U+4E7E;U+5E72,U+6F27,U+5E79,U+69A6 and the U+4E7E/U+4E81 from CDNC are basically same: U+4E7E(0);U+4E7E(86),U+5E72(86),U+4E7E(886);U+4E7E(0),U+4E81(0),U+5E72(0),U+5E79(0),U+69A6(0),U+6F27(0); U+4E81(0);U+5E72(86),U+4E7E(886);U+4E7E(0),U+4E81(0),U+5E72(0),U+5E79(0),U+69A6(0),U+6F27(0); but in JPRS' script, U+4E7E has no variants and even no U+4E81 exists: 4E7E(2,3);4E7E(2,3); # 20-05, CJK UNIFIED IDEOGRAPH-4E7E The code points can be defined in multiple scripts for many second level Tld, but only one is required in root. There are several definitions of "script", which can make things confusing. One definition is that used by Unicode (and many linguists). With that definition, Japanese uses three scripts, even four if you count the use of Latin letters and digits. Another definition is that of ISO 15294. In that system, there is a single code for Japanese (Jpan). The LGR Root Zone project uses the second definition of script (as defined in the "Procedure" document). Because of that, the root will have an overlap between the LGRs for "und-Hani", "und-Jpan" and potentially "und-Kore". Each of these LGRs will need to be integrated for use with the root. So I think the definition of a code's variants and its mapping for root is a 'necessary' constraints, some unnecessary difference of variant rule will appear after that. Because the root is a shared resource, if Hani defines an allocatable (a) variant X a->Y and Jpan defines a code point X, but either doesn't define Y or doesn't define any variant relation, then the Integration Panel would have to create the blocked (x) variant X x-> Y for use in registering labels that are tagged with "Jpan". The reason is that an application for XXX (whether tagged as Jpan or Hani) must prevent labels XXY, XYY, XYX, YYX and YYY from being delegated to a different applicant. This situation does not exist on the second level, unless the second level also supports both Hani and Jpan. The SSAC has recommended to use the root zone LGR for the second level. This cannot be understood as a strict requirement, because there are real differences between the levels. My personal understanding of this recommendation is that what is intended is to reduce the differences as much as practical. Just to give one example: the root, for non IDN labels, does not allow hyphen or digits. So, there is a difference from the second and lower levels already. I don't think, SSAC intended to say that the second level should stop supporting hyphens and digits. Many of the rules in IDNA 2008 are automatically satisfied in the root, because digits, hyphens, and mixing with latin letters are not supported, for example the bidi rules, or the rules about mixing the two types of Arabic digits. Again, we see that the second level and the root cannot be identical. So, as a result, there needs to be a discussion about what features of the root zone LGR can be usefully extended to the second level, to make the second level more predictable. A./ I am not a professional of CJK languages but I hope I can give some clues. Thanks. Qichao ------------------ 原始邮件 ------------------ >From: Asmus Freytag <asmusf(a)ix.netcom.com> >Reply-To: >To: LGR Mailing List <lgr(a)icann.org> >Subject: [ChineseGP] [lgr] Issues raised in the CJK meeting today >Date: Tue, 24 Jun 2014 10:09:10 -0700 > All, Following up on issues raised in the CJK meeting in London today. XML format and RFC 3743. The XML format should allow to express some policies that are going beyond the root policies that are assumed in the "Procedure". Therefore, the format should be able to capture the full RFC 3743. I would appreciate if someone knowledgeable in RFC 3743 could look over the latest spec as well as the "Variant Rules" document in the LGR project wiki to let me know if there are any limitations of the XML format. Variant Rules https://community.icann.org/download/attachments/43989034/Variant%20Rules.p… Latest XML spec: http://tools.ietf.org/html/draft-davies-idntables-07 A separate issue related to the question of possible inconsistencies between 2nd level and root. The root is a shared resource, which leads to some constraints not relevant for the second level. Such constraints might be called "necessary". What I would be interested in is examples (even hypothetical/imaginary ones) of "unnecessary" or "random" differences between the levels. A./

3 2

follow up to London meeting
by Wang Wei July 1, 2014

July 1, 2014

Dear all In London meeting, Kenny and I joined the coordination meeting and workshop, discussed with IP and representatives from K and J. Here are some conclusions and tasks for the next step: 1) Except for the coordination reason, the CGP Initial Character set will keep EXACTLY the same with CDNC table, to eliminate the unnecessary question of consistency and inconsistency from IP or other communities. In other words, though there is no clear compulsory requirement for consistency between TLD and SLD, different experts expressed different opinions on the issue, the change to current SLD repertoire should be carried out restrainedly and conservatively. If some modification request is ignorable, a safer way would be modifying CDNC table first. 2) Adding expert from Malaysia and some other area. 3) Kenny will ask Japan community and Korea community to confirm if they agree or disagree with the coordination rules described in Asmus's slide (attached pdf 1) and ICANN document (attached pdf 2, appendix F) Especially on the setting of "variant mapping" and "variant type" CGP is fine with the proposed solution from ICANN, personally I hope it's OK with J and K too. But if J or K doesn't accept that rule, we probably need a formal joint statement for IP, then we need to propose a new feasible alternative for IP, and of course, more negotiation with IP since they already published the attached PDF2 and went through public comments. 4) Our target is to finish the job before next ICANN meeting (October), it is not changed. But it depends on the coordination rules for repertoire and variants. Once the joint repertoire were made, I would be optimistic about instituting generation rules in a short time. Otherwise, if we can't reach an agreement with J and K, we won't move a single step toward the generation rules. Please voice your opinions as fully as possible~ Regards Wang Wei

4 3