Dear Chris, Thank you for your comments. I give some technical comments below: 1. As you and Prof.Zhang have suggested, it might be time to redefine 'variant' for CGP/JGP in order to make a comprehensive rule for 'variant mapping' . 2. P2.2 is designed for code points, not for labels with mixed code points , and only two types - 'allocatable'/'blocked' - are defined for variant code points now. So 'Independent' , as a new type, need to be accepted by LGR ?(to be confirmed) 3. From the example of �o������/�o������, there supposed to be also some relationship like 'variant' in new form and old form( �� / ��) , which may not be recognized by JGP. I wonder how to handle the conflict if �o������/�o������ are applied as tld by different applicants, and the problem is better handled by LGR, not by manual recognition. Regards, Qi Chao �볬 via foxmail �����ˣ� Dillon, Chris ����ʱ�䣺 2014��10��23��(������) ����8:24 �ռ��ˣ� ChineseGP@icann.org ���⣺ [ChineseGP] FW: fortnightly meeting on 23rd Oct, Thursday Dear colleagues, I have some comments about the questions about variant mappings document. I��m sorry if some of them were addressed during the meeting. �� I��m guessing we may need a new definition of variant, as�l f�� ��send�� and� f�� (Taiwanese Mandarin pronunciation f�� ��hair��) both TC variants of SC ��, for example, do not have ��the same pronunciations and the same meanings�� in all of the languages. �� I reckon that code points only have ��independent�� status/type in the Japanese table, but that labels should be generated using the merged LGR rules, not local table rules. �� In Japanese, �� and �� cannot be exchanged in most cases. However, there may be certain names e.g. �o������/�o������ where either form is common. The company seems to prefer the former; people write the latter. I would be interested to know what people do when word-processing. My software suggests the new form first, but then the old form. I wonder what percentage of people type which form. Personally, I would always type the form the company or person concerned preferred, if possible. There is a lot in a name. Regards, Chris. -- Research Associate in Linguistic Computing, Centre for Digital Humanities, UCL, Gower St, London WC1E 6BT Tel +44 20 7679 1599 (int 31599) www.ucl.ac.uk/dis/people/chrisdillon From: chinesegp-bounces@icann.org [mailto:chinesegp-bounces@icann.org] On Behalf Of Wang Wei Sent: 22 October 2014 03:19 To: ChineseGP@icann.org Subject: [ChineseGP] fortnightly meeting on 23rd Oct, Thursday Dear all It��s been couple of weeks since the last fortnightly meeting. Tomorrow, I��d like to share my slides for CDN variant workshop in ICANN 51 And also, I drafted a document to illustrate C, J and K��s understanding about the coordination principles. It seems there are still different views between us and some IP members. I will send the document to IP for their formal feedback after we discuss and reach a consensus. Meeting time: 3PM (Beijing time, UTC+8) Regards Wang Wei

Dear Chris, Agree to you, expect JGP to accept CCP's mapping and conveniently solve the problem of two applicants for '�o������' and '�o������'. Regards, Qichao �볬 via foxmail �����ˣ� Dillon, Chris ����ʱ�䣺 2014��10��24��(������) ����5:44 �ռ��ˣ� �볬; ChineseGP@icann.org ���⣺ RE: [ChineseGP] FW: fortnightly meeting on 23rd Oct, Thursday Dear Qi Chao, Thank you for your email. 1. I��m hoping it will be refining, rather than redefining, the definition of ��variant��. 2. Accepting the concept of universal variant (e.g. TC and SC) and lexical variant (e.g. �o������/�o������) may be easier than having to add the new type/status of Independent. 3. Whatever we do, it must not be possible for different applicants to apply for�o������ and �o������. I think it��s possible for a panel not to define variants in its table, to accept that variant mappings for each character are the same as other languages/panels and for variants to be decided at the LGR level. Cases like the �o������/�o������case would thus be solved (recognized as variants of the same lable) at the LGR level , even though �� and �� are not defined as variants in the Japanese table. Regards, Chris. -- Research Associate in Linguistic Computing, Centre for Digital Humanities, UCL, Gower St, London WC1E 6BT Tel +44 20 7679 1599 (int 31599) www.ucl.ac.uk/dis/people/chrisdillon From: �볬 [mailto:qichao@cnnic.cn] Sent: 24 October 2014 04:07 To: Dillon, Chris; ChineseGP@icann.org Subject: �ظ�: [ChineseGP] FW: fortnightly meeting on 23rd Oct, Thursday Dear Chris, Thank you for your comments. I give some technical comments below: 1. As you and Prof.Zhang have suggested, it might be time to redefine 'variant' for CGP/JGP in order to make a comprehensive rule for 'variant mapping' . 2. P2.2 is designed for code points, not for labels with mixed code points , and only two types - 'allocatable'/'blocked' - are defined for variant code points now. So 'Independent' , as a new type, need to be accepted by LGR ?(to be confirmed) 3. From the example of �o������/�o������, there supposed to be also some relationship like 'variant' in new form and old form( �� / ��) , which may not be recognized by JGP. I wonder how to handle the conflict if �o������/�o������ are applied as tld by different applicants, and the problem is better handled by LGR, not by manual recognition. Regards, Qi Chao �볬 via foxmail �����ˣ� Dillon, Chris ����ʱ�䣺 2014��10��23��(������) ����8:24 �ռ��ˣ� ChineseGP@icann.org ���⣺ [ChineseGP] FW: fortnightly meeting on 23rd Oct, Thursday Dear colleagues, I have some comments about the questions about variant mappings document. I��m sorry if some of them were addressed during the meeting. 1. I��m guessing we may need a new definition of variant, as�l f�� ��send�� and� f�� (Taiwanese Mandarin pronunciation f�� ��hair��) both TC variants of SC ��, for example, do not have ��the same pronunciations and the same meanings�� in all of the languages. 2. I reckon that code points only have ��independent�� status/type in the Japanese table, but that labels should be generated using the merged LGR rules, not local table rules. 3. In Japanese, �� and �� cannot be exchanged in most cases. However, there may be certain names e.g. �o������/�o������ where either form is common. The company seems to prefer the former; people write the latter. I would be interested to know what people do when word-processing. My software suggests the new form first, but then the old form. I wonder what percentage of people type which form. Personally, I would always type the form the company or person concerned preferred, if possible. There is a lot in a name. Regards, Chris. -- Research Associate in Linguistic Computing, Centre for Digital Humanities, UCL, Gower St, London WC1E 6BT Tel +44 20 7679 1599 (int 31599) www.ucl.ac.uk/dis/people/chrisdillon From: chinesegp-bounces@icann.org [mailto:chinesegp-bounces@icann.org] On Behalf Of Wang Wei Sent: 22 October 2014 03:19 To: ChineseGP@icann.org Subject: [ChineseGP] fortnightly meeting on 23rd Oct, Thursday Dear all It��s been couple of weeks since the last fortnightly meeting. Tomorrow, I��d like to share my slides for CDN variant workshop in ICANN 51 And also, I drafted a document to illustrate C, J and K��s understanding about the coordination principles. It seems there are still different views between us and some IP members. I will send the document to IP for their formal feedback after we discuss and reach a consensus. Meeting time: 3PM (Beijing time, UTC+8) Regards Wang Wei

Dear Zhiwei, I think officially variant refers to variant label (I find that hard – I always want to use it to refer to variant characters). According to the LGR Procedure, code points have statuses (either Allocate (which actually means allocatable) or Blocked) which may be different depending on the language. Labels also have statuses, the status of the label being Blocked if any code point in it is Blocked. For a script, the key thing is the LGR level, rather than the language table level, but variant mapping (variant does mean character variant there!) needs to be the same in language tables and the LGR, even if a language table does not include variants. Perhaps we can think of such a table as inheriting mapping from the LGR. Regards, Chris. -- Research Associate in Linguistic Computing, Centre for Digital Humanities, UCL, Gower St, London WC1E 6BT Tel +44 20 7679 1599 (int 31599) www.ucl.ac.uk/dis/people/chrisdillon<http://www.ucl.ac.uk/dis/people/chrisdillon> From: Zhiwei Yan [mailto:yanzhiwei@cnnic.cn] Sent: 24 October 2014 11:52 To: Dillon, Chris Cc: 齐超; ChineseGP@icann.org Subject: Re:Re: [ChineseGP] FW: fortnightly meeting on 23rd Oct, Thursday Dear Chris, Yes, we should differentiate the single character variants and label variants. So is it possible that we only define a loose rule for the single character and the "type" for the label variants should be defined in the later procedure. ＿＿＿＿＿＿＿＿＿＿ Best Regards, From Z.W. Yan 在2014年10月24日 17:44，Dillon, Chris<mailto:c.dillon@ucl.ac.uk>写道： Dear Qi Chao, Thank you for your email. 1. I’m hoping it will be refining, rather than redefining, the definition of “variant”. 2. Accepting the concept of universal variant (e.g. TC and SC) and lexical variant (e.g. 紀伊國屋/紀伊国屋) may be easier than having to add the new type/status of Independent. 3. Whatever we do, it must not be possible for different applicants to apply for紀伊國屋 and 紀伊国屋. I think it’s possible for a panel not to define variants in its table, to accept that variant mappings for each character are the same as other languages/panels and for variants to be decided at the LGR level. Cases like the 紀伊國屋/紀伊国屋case would thus be solved (recognized as variants of the same lable) at the LGR level , even though 國 and 国 are not defined as variants in the Japanese table. Regards, Chris. -- Research Associate in Linguistic Computing, Centre for Digital Humanities, UCL, Gower St, London WC1E 6BT Tel +44 20 7679 1599 (int 31599) www.ucl.ac.uk/dis/people/chrisdillon<http://www.ucl.ac.uk/dis/people/chrisdillon> From: 齐超 [mailto:qichao@cnnic.cn] Sent: 24 October 2014 04:07 To: Dillon, Chris; ChineseGP@icann.org<mailto:ChineseGP@icann.org> Subject: 回复: [ChineseGP] FW: fortnightly meeting on 23rd Oct, Thursday Dear Chris, Thank you for your comments. I give some technical comments below: 1. As you and Prof.Zhang have suggested, it might be time to redefine 'variant' for CGP/JGP in order to make a comprehensive rule for 'variant mapping' . 2. P2.2 is designed for code points, not for labels with mixed code points , and only two types - 'allocatable'/'blocked' - are defined for variant code points now. So 'Independent' , as a new type, need to be accepted by LGR ?(to be confirmed) 3. From the example of 紀伊國屋/紀伊国屋, there supposed to be also some relationship like 'variant' in new form and old form( 国 / 國) , which may not be recognized by JGP. I wonder how to handle the conflict if 紀伊國屋/紀伊国屋 are applied as tld by different applicants, and the problem is better handled by LGR, not by manual recognition. Regards, Qi Chao ________________________________ 齐超 via foxmail 发件人： Dillon, Chris<mailto:c.dillon@ucl.ac.uk> 发送时间： 2014年10月23日(星期四) 下午8:24 收件人： ChineseGP@icann.org<mailto:ChineseGP@icann.org> 主题： [ChineseGP] FW: fortnightly meeting on 23rd Oct, Thursday Dear colleagues, I have some comments about the questions about variant mappings document. I’m sorry if some of them were addressed during the meeting. 1. I’m guessing we may need a new definition of variant, as發 fā “send” and髮 fà (Taiwanese Mandarin pronunciation fǎ “hair”) both TC variants of SC 发, for example, do not have “the same pronunciations and the same meanings” in all of the languages. 2. I reckon that code points only have “independent” status/type in the Japanese table, but that labels should be generated using the merged LGR rules, not local table rules. 3. In Japanese, 国 and 國 cannot be exchanged in most cases. However, there may be certain names e.g. 紀伊國屋/紀伊国屋 where either form is common. The company seems to prefer the former; people write the latter. I would be interested to know what people do when word-processing. My software suggests the new form first, but then the old form. I wonder what percentage of people type which form. Personally, I would always type the form the company or person concerned preferred, if possible. There is a lot in a name. Regards, Chris. -- Research Associate in Linguistic Computing, Centre for Digital Humanities, UCL, Gower St, London WC1E 6BT Tel +44 20 7679 1599 (int 31599) www.ucl.ac.uk/dis/people/chrisdillon<http://www.ucl.ac.uk/dis/people/chrisdillon> From: chinesegp-bounces@icann.org<mailto:chinesegp-bounces@icann.org> [mailto:chinesegp-bounces@icann.org] On Behalf Of Wang Wei Sent: 22 October 2014 03:19 To: ChineseGP@icann.org<mailto:ChineseGP@icann.org> Subject: [ChineseGP] fortnightly meeting on 23rd Oct, Thursday Dear all It’s been couple of weeks since the last fortnightly meeting. Tomorrow, I’d like to share my slides for CDN variant workshop in ICANN 51 And also, I drafted a document to illustrate C, J and K’s understanding about the coordination principles. It seems there are still different views between us and some IP members. I will send the document to IP for their formal feedback after we discuss and reach a consensus. Meeting time: 3PM (Beijing time, UTC+8) Regards Wang Wei