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