- ChineseGP - lists.icann.org

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

Re: [ChineseGP] [lgr] Issues raised in the CJK meeting today
by 齐超 June 30, 2014

June 30, 2014

Hello, Asmus and CGP Members, I am qichao from CNNIC and my job is registration 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. 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 may not be a technical problem, but a question from different scripts, I guess. 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. 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. 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./

1 0

[lgr] Email Address Internationalization (EAI) and Gmail
by Fahd Batayneh June 26, 2014

June 26, 2014

Friends and Colleagues, During the Public Forum at ICANN 50 in London, Jordyn Buchanan from Google confirmed that Gmail will support EAI on their platform by the end of this month. . by the end of this month gmail is going to be the first major mail platform with full EAI support, so you'll be able to email back and forth with gmail users at least . You can find the scribe at http://www.streamtext.net/player/carttranscript?event=SANDRINGHAM-26Jun2014. A good step forward for Universal Acceptance of IDNs. Thank you, Fahd Batayneh ICANN _______________________________________________ lgr mailing list lgr(a)icann.org https://mm.icann.org/mailman/listinfo/lgr

1 0

[lgr] IDN Root Zone LGR Generation Panels Workshop
by Fahd Batayneh June 25, 2014

June 25, 2014

Friends and Colleagues, Sorry for sending this out on such a late notice, but the IDN Root Zone LGR Generation Panels Workshop in London is taking place right now. You can join remotely using the information provided at http://london50.icann.org/en/schedule/wed-lgr. Thank you, Fahd Batayneh ICANN _______________________________________________ lgr mailing list lgr(a)icann.org https://mm.icann.org/mailman/listinfo/lgr

1 0

[lgr] Issues raised in the CJK meeting today
by Asmus Freytag June 24, 2014

June 24, 2014

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./ _______________________________________________ lgr mailing list lgr(a)icann.org https://mm.icann.org/mailman/listinfo/lgr

1 0

Re: [ChineseGP] 答复: Chinese Generation Proposal
by Naela Sarras June 23, 2014

June 23, 2014

Dear Mr. Wang Wei, Thank you for the updated proposal document. The IDN team will review the proposal and provide you with feedback shortly. Best regards, Naela Sarras ICANN From: Wang Wei <wangwei(a)cnic.cn<mailto:wangwei@cnic.cn>> Date: Monday, June 23, 2014 at 8:04 AM To: Naela Sarras <naela.sarras(a)icann.org<mailto:naela.sarras@icann.org>> Cc: Han Chuan Lee <hanchuan.lee(a)icann.org<mailto:hanchuan.lee@icann.org>>, "'P2.2 team'" <p2vip(a)icann.org<mailto:p2vip@icann.org>>, "idnvarianttlds(a)icann.org<mailto:idnvarianttlds@icann.org>" <idnvarianttlds(a)icann.org<mailto:idnvarianttlds@icann.org>>, Sarmad Hussain <sarmad.hussain(a)icann.org<mailto:sarmad.hussain@icann.org>>, "ChineseGP(a)icann.org<mailto:ChineseGP@icann.org>" <ChineseGP(a)icann.org<mailto:ChineseGP@icann.org>> Subject: 答复: Chinese Generation Proposal Dear Naela Sarras CGP has revised the proposal document in accordance with the comments for the last version. Please check the attached file and please feel free to give further instructions. Regards Wang Wei 发件人: Naela Sarras [mailto:naela.sarras@icann.org] 发送时间: 2014年5月3日 8:05 收件人: Wang Wei; idnvarianttlds(a)icann.org<mailto:idnvarianttlds@icann.org> 抄送: Han Chuan Lee; P2.2 team 主题: Re: Chinese Generation Proposal Dear Mr. Wang Wei, Please find attached our feedback to the Generation Panel Proposal for the Chinese Script Label Generation Ruleset for the Root Zone. Please let us know if you have any questions or comments about the attached feedback. Best regards, Naela Sarras Manager, IDNs ICANN From: Wang Wei <wangwei(a)cnic.cn<mailto:wangwei@cnic.cn>> Date: Wednesday, April 2, 2014 at 6:10 AM To: "idnvarianttlds(a)icann.org<mailto:idnvarianttlds@icann.org>" <idnvarianttlds(a)icann.org<mailto:idnvarianttlds@icann.org>> Cc: Han Chuan Lee <hanchuan.lee(a)icann.org<mailto:hanchuan.lee@icann.org>> Subject: Chinese Generation Proposal Dear Sir/Madam On 14th March, CGP held the joint meeting with CDNC, elected chair and drafted the outline of proposal. Now we have finished the CGP proposal and submit it for review and approval. We noticed that there are still volunteers applying to join the panel, we will update the information in Chapter 2 synchronously with ICANN . Please feel free to inform us of your suggestions and comments on the proposal. Regards Wang Wei

1 0

答复: Chinese Generation Proposal
by Wang Wei June 23, 2014

June 23, 2014

Dear Naela Sarras CGP has revised the proposal document in accordance with the comments for the last version. Please check the attached file and please feel free to give further instructions. Regards Wang Wei 发件人: Naela Sarras [mailto:naela.sarras@icann.org] 发送时间: 2014年5月3日 8:05 收件人: Wang Wei; idnvarianttlds(a)icann.org 抄送: Han Chuan Lee; P2.2 team 主题: Re: Chinese Generation Proposal Dear Mr. Wang Wei, Please find attached our feedback to the Generation Panel Proposal for the Chinese Script Label Generation Ruleset for the Root Zone. Please let us know if you have any questions or comments about the attached feedback. Best regards, Naela Sarras Manager, IDNs ICANN From: Wang Wei <wangwei(a)cnic.cn> Date: Wednesday, April 2, 2014 at 6:10 AM To: "idnvarianttlds(a)icann.org" <idnvarianttlds(a)icann.org> Cc: Han Chuan Lee <hanchuan.lee(a)icann.org> Subject: Chinese Generation Proposal Dear Sir/Madam On 14th March, CGP held the joint meeting with CDNC, elected chair and drafted the outline of proposal. Now we have finished the CGP proposal and submit it for review and approval. We noticed that there are still volunteers applying to join the panel, we will update the information in Chapter 2 synchronously with ICANN . Please feel free to inform us of your suggestions and comments on the proposal. Regards Wang Wei

1 0