May 2015 - ChineseGP - lists.icann.org

minutes of the coordination meeting
by HiroHOTTA May 17, 2015

May 17, 2015

Dear Minjee Kim and Zhiwei Yan, I wish you, as notes-and-minutes takers, could draft the minutes of the CJK coordination meeting and share it with all GPs. It will be reviewed by all the participants (and will be discussed to fix if needed). It is necessary to make it as formal as possible for us to further proceed steadily. Regards, Hiro

1 0

Subject: CJK Coordination meeting future plan documents(May16th)
by 김민지 May 16, 2015

May 16, 2015

2 1

Pseudo code based on Yoneya's algorithm
by Kenny Huang, Ph.D. May 16, 2015

May 16, 2015

Pseudo code based on Yoneya's algorithm. FYI Kenny

1 0

questions to be asked about the number of allocatable variants
by HiroHOTTA May 16, 2015

May 16, 2015

Dear IP/CGP/JGP/KGP, Following are among the questions to be asked to IP and intended to be discussed in the session held at 13:00 KST (4:00 UTC) today. Hiro ============= issues regarding "the number of allocatable variants" ============= proposal by IP: the number of allocatable variant strings should be small, e.g., at most 3, as the result of RootLGR issue-1 "what kinds of variant strings are preferred to be applied for" cannot be predicted and should not be assumed in RootLGR (at least in Japanese case, for example) <reasoning> In Japanese case, all the characters are considered to be independent. Namely, all the strings of any combination of any characters in the repertoire are designed to be allocatable by different TLD applicants. However, JGP knows that CGP wants to define variants in RootLGR, and JGP currently intends to compromise by basically importing variant definitions from CGP. This means that such strings that have variants in C will be packaged also in J, although they are originally intended to be independent. From Japanese point of view, as all the characters are considered to be originally independent, all the strings in the package should be allocatable even if they can be delegated to the same applicant. Moreover, the probability of some applicant's intention to apply for a specific string in the package is equal for all the strings in the package. issue-2 If limitation of the number of delegated variant strings is intended to be implemented, it should be done in application phase or application evaluation phase - not by RootLGR <reasoning> As discussed in (1), the probability of "which string is preferred" depends on the specific string that is applied for or that is accessed by the users. Namely, it depends on how much the specific string is well-known to the users. This means it's not possible for us to define WLE before asking each applicant about which variant strings they want to apply for. In that case, if we want to limit the number of delegated strings or to assess whether it is appropriate for the applied-for string picked up from the package, we need to engage measures after application(s) of specific string(s) is(are) made. ==

1 0

IP's feedback to proposed integration algorithm (ToDo-5)
by Yoshiro YONEYA May 15, 2015

May 15, 2015

Dear CGP/JGP/KGP members, > [[Integration Algorithm]] > ToDo-5 <expected> J gets IP's feedback on Yoneya's algorithm IP gave us feedback to proposed integration algorithm in advance. Please find attached the document with IP's annotation. And please prepare for the meeting. If you have any questions/comments, please let us know. This ToDo is related to following ToDos. > [[Premise]] > ToDo-2 <must> Each participant understands Yoneya's algorithm > that was already sent to CGP/JGP/KGP by Yoneya and > also agreed by C and J in Dallas, which is attached > to this mail as well > > ToDo-4 <expected> Participants agree on Yoneya's algorithm as a > framework and also agree on partial usage of MSS > to accelerate our discussion ("partial" means > "J doesn't need to be considered to be incorporated > into MSS") This is expected to be discussed and > finalized online before our meeting Regards, -- Yoshiro YONEYA <yoshiro.yoneya(a)jprs.co.jp>

3 2

Re: [ChineseGP] [Integrationpanel] FW: Examples of complicated domainname
by Asmus Freytag May 15, 2015

May 15, 2015

Dear Yoneya-san, I appreciate these examples and I was able to verify that they do lead to the same domains. It would appear that there is a practice by some Japanese applicants to treat certain combinations of old and new Kanji as variants. And I think you have made your case that the selection of which variants to treat that way depends on the applicant (and presumably the meaning of the label) and therefore is not easily captured by a mechanical rule. I would appreciate if the JGP could include this analysis (and examples) in their LGR proposal as part of the rationale for their choice of assigning variant types. I expect it will influence the review by the Integration panel. Now, separately, there was the question raised "what about variants introduced by integration that are not 'semantic' variants in Japanese?". Are there cases of delegated labels where the variants are from that subset? It would appear that unlike the old vs. new Kanji variants they must be really rare (or non-existant), because they would be unrelated in Japanese. So it would be meaningless for an applicant to have a) registered both and b) directed them to the same domain. A./ > -----Original Message----- > From: chinesegp-bounces(a)icann.org [mailto:chinesegp-bounces@icann.org] On Behalf Of Yoshiro YONEYA > Sent: Friday, May 15, 2015 6:57 PM > To: IntegrationPanel(a)icann.org > Cc: KoreanGP(a)icann.org; ChineseGP(a)icann.org; JapaneseGP(a)icann.org > Subject: [ChineseGP] Examples of complicated domain name > > Dear IP members, > > For Japanese language, we have concept of variants. But it is different from Chinese language's. In Japanese language, variants are used simultaneously by intention of the person who uses them. > > Followings are examples of such usage in Japanese .JP domain names. > > 慶応大学.jp > 慶應大学.jp > > Those are name of Keio university and registered by the university. > 応 and 應 are considered as variants in new form Kanji and old form Kanji. > 学 has variant 學 in that sense, but Keio university does not have > 慶應大學.jp which is consist of both old form Kanji. > > Followings are another examples. > > 国学院大学.jp > 國學院大學.jp > > Those are name of Kokugakuin university and registered by the university. > 国 and 國 are new form Kanji and old form Kanji respectively. Unlike Keio university, Kokugakuin university does not have 國學院大学.jp. > > These cases are unpredictable, and very much depends on applicant's intention. > > The interesting thing is, a subsidiary of Kokugakuin university has following domain name. > > 学校法人國學院大學栃木学園.jp > > Here, 学 and 學 are used simultaneously, and it doesn't have > 学校法人国学院大学栃木学園.jp. > > This is reality of Japanese language. > > Regards, > > -- > Yoshiro YONEYA <yoshiro.yoneya(a)jprs.co.jp> > > _______________________________________________ > ChineseGP mailing list > ChineseGP(a)icann.org > https://mm.icann.org/mailman/listinfo/chinesegp > > > _______________________________________________ > Integrationpanel mailing list > Integrationpanel(a)icann.org > https://mm.icann.org/mailman/listinfo/integrationpanel

2 1

Re: [ChineseGP] some questions for IP on CJK coordination
by Asmus Freytag May 15, 2015

May 15, 2015

> >> *From:*王伟[mailto:wangwei@cnic.cn] >> *Sent:* Friday, May 15, 2015 5:47 PM >> *To:* integrationPanel(a)icann.org >> *Cc:* Sarmad Hussain; chineseGP(a)icann.org; japaneseGP(a)icann.org; >> koreanGP(a)icann.org >> *Subject:* some questions for IP on CJK coordinaton >> >> Dear IP members >> >> During the discussion in CJK coordination meeting this afternoon, I >> checked the draft of “Representing Label Generation Rulesets using >> XML” (https://www.ietf.org/id/draft-davies-idntables-09.txt) again. >> >> Here are some questions about the terminology and label disposition >> rule in the draft. >> >> 1)Terminology for “variant subtype” >> >> Besides the variant type like “allocatable” and “blocked”, some >> other attributes like “trad” “simp” “both” are given in the draft as >> follows: >> >> ------------------------------------------------------------------------------------------------------------------- >> >> Assuming an LGR where all variants have been given suitable "type" >> >> attributes of "block", "simplified", "traditional", or "both", >> >> similar to the ones discussed in Appendix B. Given such an LGR, the >> >> following example actions evaluate the disposition for the variant >> >> label: >> >> <action disp="block" any-variant="block" /> >> >> <action disp="allocate" only-variants="simplified both" /> >> >> <action disp="allocate" only-variants="traditional both" /> >> >> <action disp="block" all-variants="simplified traditional " /> >> >> <action disp="allocate" /> >> >> The first action matches any variant label for which at least one of >> >> the code point variants is of type "block". The second matches any >> >> variant label for which all of the code point variants are of type >> >> "simplified" or "both", in other words an all-simplified label. The >> >> third matches any label for which all variants are of type >> >> "traditional" or "both", that is all traditional. These two actions >> >> are not triggered by any variant labels containing some original code >> >> points, unless each of those code points has a variant defined with a >> >> reflexive mapping (Section 4.2.4). >> >> ---------------------------------------------------------------------------------------------------------------- >> >> Yoneya san suggested that we define them (“simp”“trad””both”…) as >> “variant subtype” >> >> If it is not appropriate to call that, is there any other terminology >> you might prefer? >> > There seems to be a desire among the CJK-GP to stick with the term > "... subtype", based on the idea (perhaps) that only CPs with the > variant type "allocatable" will in practice have any of these > attributes. But this is misleading. The generalization rather is that > these are attributes invented by the GP, which can then be > transformed, though application of rules, ultimately to either > "allocatable" or "blocked" variant types. > > The revealing terminology would therefore be "GP-defined type", which > also high-lights the fact that the there is no closed list of these > attributes, even if [simple], [traditional], [both] are our favourite > examples. I am fine with thinking of these are GP-defined types, but in some of the IP documents we use the term subtype, so we should be aware that these two terms mean the same thing. >> >> 2)The variant type of “out-of-repertoire” >> >> In a work email last year, Asmus mentioned >> >> “The MSR already contains a default action <action >> disposition="invalid" any-variant="out-of-repertoire-var" >> comment="any variant label with a code point out of repertoire is >> invalid"/>” >> >> However, I didn’t find the definition of “out-of-repertoire” and the >> corresponding action in draft-davies-idntables-09 >> >> Will this part be added in the next version? >> > Can't comment on this. But no doubt Asmus or Wil can. I'm currently revising the draft-davies-idntables and will see whether this is appropriate to mention it there. The key thing is to remember that from the XML formalism, one is free to use any "type" values whatsoever, and any "disposition" values whatsoever -- because the XML format is intended for ALL types of domains, not just the root. For the Root Zone LGR project, the IP has defined the type "out-of-repertoire-var" and provided a default WLE <action> to resolve it. That definition was made in the MSR. Several of the documents that the IP created, including "Packaging the MSR and LGR" (see the LGR Root Zone Project wiki) describe how to use it. (Somebody had a link for that yesterday). >> >> 3) suggestion about a new variant type and action type >> >> JGP-LGR-1 doesn’t have variants, but many CGP variants will be added >> into JGP-LGR-2,which means, JGP will adopt many Chinese variants to >> reach a CJK consensus, >> >> The meaning of most those variants are same, however, there are some >> specific code points mean totally different things in Japanese >> language environment, while the exchangeable variants in Chinese. >> >> Like 机/機，both mean machine in Chinese, but mean machine and table >> separately in Japanese. >> >> Though JGP will set them as variants and both “allocatable”, I wonder >> if it is possible to create a new type of “allocatable-reserved” to >> help tell the difference in WLE. >> >> The corresponding action will go like <action >> disposition="allocatable-reserved" any-variant="allocatable-reserved"> >> >> Which means, when机上is applied, 機上will be generated and >> allocatable, but a special process is needed before the real >> delegation/activation of “機上” >> >> Because unlike the common allocatable variant label, the activation >> of these “allocatable-reserved” label might bring domain name >> disputes or abuse. >> >> does the new type suggestion make sense? Do you think it is practical ? >> In general, the Root Zone process only allows the two dispositions "allocatable" and "blocked" for variant labels (as well as "invalid" for labels that are not valid at all). And dispositions for the labels are not redefinable. I understand from Yoneya-san's examples that there is a common practice of multiple labels treated as variant labels by their applicant in the .jp domain (and that the choice is not predictable by any rule). These examples are good evidence that there is a rational basis for allowing at least some of the CGP variants to be considered "allocatable" in the JGP LGR. This suggestion of an "allocatable-reserved" disposition would indicate, there may be some other CGP variants for which considering them "allocatable" in the JGP LGR is not as motivated. In other words, there are some facts, which would make certain combinations of variants very unlikely -- perhaps so unlikely that they do not need to be supported in the root. If that is the case, we need to understand how unlikely such combinations are. Would an "exception" be needed rarely, but still relatively often? Or is the desire to allow an exception mostly to prevent even the risk of disallowing a single label? The reason I am asking these questions is, that for the root zone, we are requested to be conservative. Because of that, if some rule leads to the prevention of a few possible labels (that are unusual to begin with), it is more acceptable to not support such labels in the root, than to make complicated additions to the system. Therefore, the investigation by the JGP has to be whether it isn't acceptable to treat these labels (where CGP variants are not semantically related) as "blocked" instead of "allocatable-reserved". If the result is that a small percentage of exceptional variant labels that might have been allowed under the second level cannot be allowed under the root, it would likely be better to live with such a restriction. This would be in the spirit of "conservatism". So, whether or not the Root Zone LGR process can actually create a disposition like the proposed "alloctable-reserved" (and our hands may be tied by the procedure) it would be important to have examples of actual cases and an understanding on whether simply making these "blocked" would be unduly restrictive in practice (and not just in theory). In other words, it would be important to have the same kind of use cases as Yoneya-san sent for the semantically related (old-vs.-new ideograph) variants. A./

1 0

Re: [ChineseGP] some questions for IP on CJK coordination
by Asmus Freytag (t) May 15, 2015

May 15, 2015

> >> *From:*王伟[mailto:wangwei@cnic.cn] >> *Sent:* Friday, May 15, 2015 5:47 PM >> *To:* integrationPanel(a)icann.org >> *Cc:* Sarmad Hussain; chineseGP(a)icann.org; japaneseGP(a)icann.org; >> koreanGP(a)icann.org >> *Subject:* some questions for IP on CJK coordinaton >> >> Dear IP members >> >> During the discussion in CJK coordination meeting this afternoon, I >> checked the draft of “Representing Label Generation Rulesets using >> XML” (https://www.ietf.org/id/draft-davies-idntables-09.txt) again. >> >> Here are some questions about the terminology and label disposition >> rule in the draft. >> >> 1)Terminology for “variant subtype” >> >> Besides the variant type like “allocatable” and “blocked”, some >> other attributes like “trad” “simp” “both” are given in the draft as >> follows: >> >> ------------------------------------------------------------------------------------------------------------------- >> >> Assuming an LGR where all variants have been given suitable "type" >> >> attributes of "block", "simplified", "traditional", or "both", >> >> similar to the ones discussed in Appendix B. Given such an LGR, the >> >> following example actions evaluate the disposition for the variant >> >> label: >> >> <action disp="block" any-variant="block" /> >> >> <action disp="allocate" only-variants="simplified both" /> >> >> <action disp="allocate" only-variants="traditional both" /> >> >> <action disp="block" all-variants="simplified traditional " /> >> >> <action disp="allocate" /> >> >> The first action matches any variant label for which at least one of >> >> the code point variants is of type "block". The second matches any >> >> variant label for which all of the code point variants are of type >> >> "simplified" or "both", in other words an all-simplified label. The >> >> third matches any label for which all variants are of type >> >> "traditional" or "both", that is all traditional. These two actions >> >> are not triggered by any variant labels containing some original code >> >> points, unless each of those code points has a variant defined with a >> >> reflexive mapping (Section 4.2.4). >> >> ---------------------------------------------------------------------------------------------------------------- >> >> Yoneya san suggested that we define them (“simp”“trad””both”…) as >> “variant subtype” >> >> If it is not appropriate to call that, is there any other terminology >> you might prefer? >> > There seems to be a desire among the CJK-GP to stick with the term > "... subtype", based on the idea (perhaps) that only CPs with the > variant type "allocatable" will in practice have any of these > attributes. But this is misleading. The generalization rather is that > these are attributes invented by the GP, which can then be > transformed, though application of rules, ultimately to either > "allocatable" or "blocked" variant types. > > The revealing terminology would therefore be "GP-defined type", which > also high-lights the fact that the there is no closed list of these > attributes, even if [simple], [traditional], [both] are our favourite > examples. I am fine with thinking of these are GP-defined types, but in some of the IP documents we use the term subtype, so we should be aware that these two terms mean the same thing. >> >> 2)The variant type of “out-of-repertoire” >> >> In a work email last year, Asmus mentioned >> >> “The MSR already contains a default action <action >> disposition="invalid" any-variant="out-of-repertoire-var" >> comment="any variant label with a code point out of repertoire is >> invalid"/>” >> >> However, I didn’t find the definition of “out-of-repertoire” and the >> corresponding action in draft-davies-idntables-09 >> >> Will this part be added in the next version? >> > Can't comment on this. But no doubt Asmus or Wil can. I'm currently revising the draft-davies-idntables and will see whether this is appropriate to mention it there. The key thing is to remember that from the XML formalism, one is free to use any "type" values whatsoever, and any "disposition" values whatsoever -- because the XML format is intended for ALL types of domains, not just the root. For the Root Zone LGR project, the IP has defined the type "out-of-repertoire-var" and provided a default WLE <action> to resolve it. That definition was made in the MSR. Several of the documents that the IP created, including "Packaging the MSR and LGR" (see the LGR Root Zone Project wiki) describe how to use it. (Somebody had a link for that yesterday). >> >> 3) suggestion about a new variant type and action type >> >> JGP-LGR-1 doesn’t have variants, but many CGP variants will be added >> into JGP-LGR-2,which means, JGP will adopt many Chinese variants to >> reach a CJK consensus, >> >> The meaning of most those variants are same, however, there are some >> specific code points mean totally different things in Japanese >> language environment, while the exchangeable variants in Chinese. >> >> Like 机/機，both mean machine in Chinese, but mean machine and table >> separately in Japanese. >> >> Though JGP will set them as variants and both “allocatable”, I wonder >> if it is possible to create a new type of “allocatable-reserved” to >> help tell the difference in WLE. >> >> The corresponding action will go like <action >> disposition="allocatable-reserved" any-variant="allocatable-reserved"> >> >> Which means, when机上is applied, 機上will be generated and >> allocatable, but a special process is needed before the real >> delegation/activation of “機上” >> >> Because unlike the common allocatable variant label, the activation >> of these “allocatable-reserved” label might bring domain name >> disputes or abuse. >> >> does the new type suggestion make sense? Do you think it is practical ? >> In general, the Root Zone process only allows the two dispositions "allocatable" and "blocked" for variant labels (as well as "invalid" for labels that are not valid at all). And dispositions for the labels are not redefinable. I understand from Yoneya-san's examples that there is a common practice of multiple labels treated as variant labels by their applicant in the .jp domain (and that the choice is not predictable by any rule). These examples are good evidence that there is a rational basis for allowing at least some of the CGP variants to be considered "allocatable" in the JGP LGR. This suggestion of an "allocatable-reserved" disposition would indicate, there may be some other CGP variants for which considering them "allocatable" in the JGP LGR is not as motivated. In other words, there are some facts, which would make certain combinations of variants very unlikely -- perhaps so unlikely that they do not need to be supported in the root. If that is the case, we need to understand how unlikely such combinations are. Would an "exception" be needed rarely, but still relatively often? Or is the desire to allow an exception mostly to prevent even the risk of disallowing a single label? The reason I am asking these questions is, that for the root zone, we are requested to be conservative. Because of that, if some rule leads to the prevention of a few possible labels (that are unusual to begin with), it is more acceptable to not support such labels in the root, than to make complicated additions to the system. Therefore, the investigation by the JGP has to be whether it isn't acceptable to treat these labels (where CGP variants are not semantically related) as "blocked" instead of "allocatable-reserved". If the result is that a small percentage of exceptional variant labels that might have been allowed under the second level cannot be allowed under the root, it would likely be better to live with such a restriction. This would be in the spirit of "conservatism". So, whether or not the Root Zone LGR process can actually create a disposition like the proposed "alloctable-reserved" (and our hands may be tied by the procedure) it would be important to have examples of actual cases and an understanding on whether simply making these "blocked" would be unduly restrictive in practice (and not just in theory). In other words, it would be important to have the same kind of use cases as Yoneya-san sent for the semantically related (old-vs.-new ideograph) variants. A./

1 0

Re: [ChineseGP] FW: [Integrationpanel] FW: [Japanesegp] some questions for IP on CJK coordinaton
by Asmus Freytag May 15, 2015

May 15, 2015

On 5/15/2015 10:01 AM, Yoshiro Yoneaya wrote: > - > > -----Original Message----- > From:integrationpanel-bounces@icann.org [mailto:integrationpanel-bounces@icann.org] On Behalf Of Yoshiro YONEYA > Sent: Friday, May 15, 2015 6:35 PM > To:integrationPanel@icann.org > Cc:chineseGP@icann.org;japaneseGP@icann.org;koreanGP@icann.org > Subject: Re: [Integrationpanel] [Japanesegp] some questions for IP on CJK coordinaton > > Dear IP members, > > First of all, I appreciate Wang Wei san for asking those questions. All, here is my take on this, you will see that it agrees in the essentials with what Wil and Nicholas have been saying. >> 1) Terminology for “variant subtype” > (4) Variant type, variant subtype > Variant type is an attribute of a variant, which indicates the treatment > of the variant in WLE. There are three _default_ variant types. These are > (a) allocatable, (b) blocked and (c) out of repertoire var. Each GP may decide to define and use a set of types that is more differentiated than the default types, so that fewer combinations of these types lead to an allocatable label. Such GP-defined types have been called "subtypes" in the existing documentation, not because of a hierarchical relation to types, or any limitations, but because in the most common scenario they would be used _instead_ of the default type of "allocatable". > > For example, CGP defines (i) simp, (ii) trad and (iii) both variant subtypes. > Each variant subtype has to have one or more corresponding <action> element > in WLE. The outcome of each <action> is the disposition for the label, and can have the three values: allocatable, blocked and invalid. GPs cannot define any other values for the label disposition. A./

1 0

Re: [ChineseGP] FW: [Integrationpanel] FW: [Japanesegp] some questions for IP on CJK coordinaton
by Asmus Freytag (t) May 15, 2015

May 15, 2015

On 5/15/2015 10:01 AM, Yoshiro Yoneaya wrote: > > - > > -----Original Message----- > From: integrationpanel-bounces(a)icann.org [mailto:integrationpanel-bounces@icann.org] On Behalf Of Yoshiro YONEYA > Sent: Friday, May 15, 2015 6:35 PM > To: integrationPanel(a)icann.org > Cc: chineseGP(a)icann.org; japaneseGP(a)icann.org; koreanGP(a)icann.org > Subject: Re: [Integrationpanel] [Japanesegp] some questions for IP on CJK coordinaton > > Dear IP members, > > First of all, I appreciate Wang Wei san for asking those questions. All, here is my take on this, you will see that it agrees in the essentials with what Wil and Nicholas have been saying. > >> 1) Terminology for “variant subtype” > > (4) Variant type, variant subtype > Variant type is an attribute of a variant, which indicates the treatment > of the variant in WLE. There are three _default_ variant types. These are > (a) allocatable, (b) blocked and (c) out of repertoire var. Each GP may decide to define and use a set of types that is more differentiated than the default types, so that fewer combinations of these types lead to an allocatable label. Such GP-defined types have been called "subtypes" in the existing documentation, not because of a hierarchical relation to types, or any limitations, but because in the most common scenario they would be used _instead_ of the default type of "allocatable". > > For example, CGP defines (i) simp, (ii) trad and (iii) both variant subtypes. > Each variant subtype has to have one or more corresponding <action> element > in WLE. The outcome of each <action> is the disposition for the label, and can have the three values: allocatable, blocked and invalid. GPs cannot define any other values for the label disposition. A./

1 0