March 2016 - Koreangp - lists.icann.org

CJK Joint meeting record and homework
by 王伟 April 24, 2016

April 24, 2016

Dear All Please find the attached documents of meeting agenda & record, and the action item (homework) Thanks everyone who join the meeting in the two days. We will keep working on it. Regards WANG Wei -----邮件原件----- 发件人: chinesegp-bounces(a)icann.org [mailto:chinesegp-bounces@icann.org] 代表 HiroHOTTA 发送时间: 2016年3月21日 8:53 收件人: ChineseGP(a)icann.org; JapaneseGP(a)icann.org; KoreanGP(a)icann.org 主题: [ChineseGP] how 'blocked' can help us (During 4 hours struggle with the letters without significant output ...) A question has come to my mind and won't disappear... What are the future of "allocatable labels"? Let's assume the case where registrant-X applied for label-A, and label-B is marked as 'allocatable' by LGR, then, label-A is delegated to registrant-X. As far as I understand, the above means "only registrant-X has the right to apply for label-B in the future." If registrant-X wants label-B to be delegated, he/she needs to make a separate application to ICANN. And ICANN will evaluate the label-B by a human panel (maybe supported by some automatic mechanism). Then, what's the difference between (1) all variants are allocatable (2) some variants are allocatable and the others are blocked (or invalid) I understand (2) can make the applicant know that the application for some strings (that are blocked/invalid) will definitely be rejected in any case. However, this does not reduce the number of TLD delegations significantly because the applicant does want only a few variant TLDs in reality, for money-wise reason or usage-wise reason. then,,,,, why is (1) so evil? Hiro _______________________________________________ ChineseGP mailing list ChineseGP(a)icann.org https://mm.icann.org/mailman/listinfo/chinesegp

3 6

[KGP] changes in variant groups from K_LGR_v0.3 to v0.4.
by KIM Kyongsok March 24, 2016

March 24, 2016

Dear everybody: 1) Enclosed you will find K-LGR v0.4 file with one more sheet. The last sheet shows changes in variant groups from K_LGR_v0.3 to v0.4. Hope it helps. 2) I also made some editorial changes so that you can read Hanja glyphs easily. Thanks. Rgds, -- 김 경석 KIM, Kyongsok

1 1

Re: [Koreangp] CJK Joint meeting record and homework
by 박민정 March 23, 2016

March 23, 2016

1 0

CGP LGR in XML and EXCEL format
by 王伟 March 21, 2016

March 21, 2016

Dear all I am sending the latest version of CGP LGR in both XML and EXCEL format. Please find the attached documents of them. Regards WANG Ｗei

2 1

Agenda for 21st afternoon
by 王伟 March 20, 2016

March 20, 2016

14:00 - 14:05 (5m) Roll call and Review of the 1st day meeting 14:05�C 15:15 (75m) Discussion on letters to IP and ICANN 15:20�C 15:30(10m) Tea Break 15:30�C 16:30 (60m) Discussion on C&K conflicting variant statistics and disposition proposal 16:30�C 16:40 (10m) Tea Break 16:40�C 17:00 (20m) Discussions on action items for the coming future

1 0

(revised) Two letters from CJK GPs to ICANN and IP
by HiroHOTTA March 20, 2016

March 20, 2016

19 March, 2016 (revised) 21 March, 2016 JGP Two letters from CJK GPs to ICANN and IP 1. Confirmation of the purpose/content of the letters Description is given below about the intention and framework of the letters we are supposed to formally send to IP and ICANN. The purpose of the letters is to ask IP and ICANN to bridge a gap between the application procedure (including LGR) and CJK's demand. If the below is confirmed by all of CJK GPs, draft letters will be crafted in full and reviewed by all CJK GP members. Then, they will be sent to IP and ICANN. 2. Result of Marrakech Meeting and Beijing Meeting Day1 CJK met on Sunday 6 and Thursday 10 March 2016, and concluded that CJK will send the following two (2) formal letters, (letter-a) to IP requesting the rationale of IP's request to reduce allocatable variants (letter-b) to ICANN requesting enhancement of TLD application process to enable more than one applied-for labels in a variant label group to be allocated, even if LGR blocks some of them when one label is input to LGR During Sunday 20 March Beijing Meeting, CJK GPs had an in-depth discussion about the purpose and content of the letters based on Hiro's material. There, CJK GPs agreed that - CJK will jointly send letter-a to IP - CJK will consider more about the content of the letter based on each GP's situation, although the joint statement empowers the message - C and J will jointly send a letter first - C and J will wait for K's decision to jon C and J - C / J / K will send a separate letter when each think appropriate (no letter is also an option for each GP) As an action item from Sunday 20 March Beijing Meeting, JGP was tasked to elaborate more on the letters by reflecting the comments given in the meeting. The below is the latest draft - with reflections of the comments as far as possible. 3. proposed letters 3.1 letter-a to IP This is a simple letter asking for their rationale in writing. Such rationale may be essential for all the GPs to determine the allocatability in some of the language/script LGRs. So far, IP seems - to accept the limited number (typically less than 10) of Chinese labels that are variants of each other - such labels are : * applied for label * all traditional label(s) * all simplified label(s) - to reject some of the Japanese labels that are variants of each other even if every variant label (imported from CGP) is EQUALY VALID as a Japanese word * A member of IP sent a mail to a member of JGP stating IP's following position - Any allocatable variant must be individually justified. The aim is to sufficiently reduce the number of allocatable labels. We need to know the clear rationale and criteria for acceptance and rejection determined by the LGR. [Hiro believes this demand is shared by all GPs, even outside CJK. Especially, KGP will have just the same demand as the following JGP example. The following Japanese example should go into Appendices, because examples of just a single GP may make the readers feel that this letter is intended to push a single GDP's demand, although which is not the case] For example, Japanese characters are all independent and no restriction rule exists regarding combination of the characters in a word. Thus, JGP demands all characters to be independent (i.e., with no variants) as a Japanese rule. However, JGP understands and respects the necessity of CGP variants at TLD level and has intention to import the definition of CGP variants. This makes pseudo variant label groups for JGP, so to say. Even in such a case, however, JGP demands all character combinations to be allocatable by necessity. 慶応義塾大学, 慶應義塾大学, 慶応義塾大學, 慶應義塾大學 constitute a pseudo variant label group when CGP variant definition is imported to JGP. All these four domain labels were applied for and delegated to the same registrant (Keio University) as SLD of .jp and have been used since then. This means the registrant wants to use all these four strings as their domain labels. Note that if CGP's rule (no mixture of traditional and simplified) is applied, two of them will be marked as 'blocked' despite the registrant wants all four. As shown above, since all the characters are equally independent in Japanese context, reducing allocatable labels within a pseudo variant label group cannot be done automatically. If JGP is obliged to reduce the number of allocatable labels, it's almost the same as "random pick-up". [what else should be written here - from empirical study and statistics] 3.2 letter-b to ICANN [where does the example of 台湾 fit?] This is a letter requesting ICANN to incorporate our request to be included in the future TLD application procedure. ICANN says that once a label is decided to be blocked by the LGR, such a label cannot be definitely allocated at the moment of the application and also in the future. However there exist following cases (1) when allocatable labels set by LGR are limited despite of the language community demand, there are cases where applied-for label-A (which is marked 'allocatable') and its variant label-B (which is marked 'blocked') are both wished to be delegated. In some cases, additional blocked labels (label-C, D, ...) may also be wished to be delegated. e.g., 慶応義塾大学, 慶應義塾大学, 慶応義塾大學, 慶應義塾大學 are Japanese variant labels when CGP variant definition is imported to JGP. All these four domain labels were applied for and delegated to the same registrant (Keio University) as SLD of .jp. Note that if CGP's rule (no mixture of traditional and simplified) is applied, two of them will be marked as 'blocked' despite the registrant wants all four. (2) label-B, which is marked as 'blocked' when label-A is applied for LGR, is (or will be) wished to be delegated, in the case where applicant did not know that label-B is one of the blocked variant labels of label-A or label-B will be needed to be delegated in the future. In some cases, additional blocked labels (label-C, D, ...) may also be wished to be delegated. [Is the latter case (satisfying unknown future demand) too demanding? ] (1) can be implemented if the application procedure can accept a primary label (label-A) and additional variant labels (label-B, C, D, ...) that the applicant wants at the time of application, and the application procedure can give a green light to all applied-for labels (label-A, B, C, D, ...). This can be implemented by complement procedure for LGR, which wraps multiple application of LGR. the maximum number of applied-for labels can be limited to a reasonably-small concrete number (such as 4) by the complement procedure. This is an automatic algorithmic solution to (1). [first diagram of complement procedure will be inserted here] (2) can be implemented if the application procedure can notify the applicant about the blocked labels and allow the applicant to ask for giving 'allocatable' to some of blocked variant labels. This can be a solution to (2) through human-intervention in the application evaluation panel both for IDN ccTLD fast track and for new gTLD application. [second diagram of complement procedure will be inserted here] /END

1 0

how 'blocked' can help us
by HiroHOTTA March 20, 2016

March 20, 2016

(During 4 hours struggle with the letters without significant output ...) A question has come to my mind and won't disappear... What are the future of "allocatable labels"? Let's assume the case where registrant-X applied for label-A, and label-B is marked as 'allocatable' by LGR, then, label-A is delegated to registrant-X. As far as I understand, the above means "only registrant-X has the right to apply for label-B in the future." If registrant-X wants label-B to be delegated, he/she needs to make a separate application to ICANN. And ICANN will evaluate the label-B by a human panel (maybe supported by some automatic mechanism). Then, what's the difference between (1) all variants are allocatable (2) some variants are allocatable and the others are blocked (or invalid) I understand (2) can make the applicant know that the application for some strings (that are blocked/invalid) will definitely be rejected in any case. However, this does not reduce the number of TLD delegations significantly because the applicant does want only a few variant TLDs in reality, for money-wise reason or usage-wise reason. then,,,,, why is (1) so evil? Hiro

1 0

CJK Han coordination scenario considerations
by Edmon Chung March 19, 2016

March 19, 2016

Attached ppt I just used at the meeting for your reference. Edmon

1 0

ToDo : draft letters to IP and ICANN
by HiroHOTTA March 19, 2016

March 19, 2016

19 March, 2016 Hiro Hotta, JGP Two letters from CJK GPs to ICANN and IP 1. Confirmation of the purpose/content of the letters I described below about the intention and brief content of the letters we are supposed to formally send to IP and ICANN. If the below is confirmed in CJK coordination meeting, draft of the letters will be crafted and reviewed by all CJK GP members. 2. result of Marrakech Meeting CJK met on Sunday 6 and Thursday 10 March 2016 and concluded that CJK will send the two (2) formal letters, (letter-a) to IP requesting for the rationale of IP's request to reduce allocatable variants (letter-b) to ICANN requesting for the enhancement of TLD application process to enable more than one applied-for labels to be allocated, even if LGR blocks one of them when another of them is input to LGR 3. proposed letters 3.1 letter-a to IP This is a simple letter asking for their rationale in writing. Such rationale may be essential for all the GPs to determine the allocatability in some of the LGR. So far, IP seems - to accept the following three Chinese labels that are variants of each other * applied for * all traditional * all all simplified - to reject the Japanese labels that are variants of each other even if every variant label is EQUALY VALID as a Japanese word We need to know the clear criteria for acceptance and rejection. 3.2 letter-b to ICANN This is a letter requesting ICANN to incorporate our request to be included in the future TLD application procedure. ICANN says that once a label is decided to be blocked by the LGR, such a label cannot be definitely allocated at the moment of the application and also in the future. However there are cases where (x) blocked label-A and its variant label-B are equally needed to be allocated at the time of application in the case even if LGR does not implement the demand of the language community (y) blocked label-B will be needed to be allocated even if the applicant did not know that label-B is one of the blocked variant of label-A or label-B will be needed to become allocatable in the future (x) can be implemented if the application procedure can review more than one label as input at the same time and give both of them a green light. (y) can be implemented if the application procedure can notify the applicant about the blocked labels and allow the applicant to ask for giving 'allocatable' to some of blocked variant labels. /END Hiro

1 0

[klgp190_21q] KR comments RE: C var. groups (meaning in English)
by KIM Kyongsok March 18, 2016

March 18, 2016

Dear Mr. Wang Wei and others: Enclosed you will find KR's comments RE: C var. groups. Meanings of Hanja chars in Unacceptable C var. groups are translated into English. Please let me know if there is a problem. Thanks. -- 김 경석 KIM, Kyongsok

2 2