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? 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? 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 ? looking forward to your answer. Best Regards Wang wei
Dear IP members, First of all, I appreciate Wang Wei san for asking those questions.
1) Terminology for “variant subtype”
From today's meeting, my understanding about the difference between variant type and variant subtype is that variant type is one of (allocatable|blocked|out-of-repertoire-var), and variant subtype is variant type with some limitation. If this is correct, I'd like to reword preliminary terminology text like following.
Before: (4) Variant type, variant subtype Variant type is an attribute of a variant, which indicates the treatment of the variant in WLE. Variant type is one of (a) allocatable, (b) blocked and (c) out of repertoire var. The “allocatable” variant type can have subtype (variant subtype). The variant subtype can be defined by each GP. 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. After: (4) Variant type, variant subtype Variant type is an attribute of a variant, which indicates the treatment of the variant in WLE. Variant type is one of (a) allocatable, (b) blocked and (c) out of repertoire var. Variant subtype is a variation of variant type with certain limitation. For example, in Chinese script, variant type "allocatable" are substituted by "simp" (stands for simplified), "trad" (stands for "traditional") and "both" (stands for both simplified and traditional) subtypes. The variant subtype can be defined by each GP. Each variant type and variant subtype has to have one or more corresponding <action> element in WLE. Please give your comment, or reword text if possible.
2) The variant type of “out-of-repertoire”
I found following document which explained out-of-repertoire-var. https://community.icann.org/download/attachments/43989034/Packaging-MSR-LGR.... Any way, I support Wang Wei san's suggestion.
3) suggestion about a new variant type and action type
I think this is possible option. I'd like to hear IP's opinion about this. Regards, -- Yoshiro YONEYA <yoshiro.yoneya@jprs.co.jp> On Fri, 15 May 2015 20:47:02 +0800 王伟 <wangwei@cnic.cn> wrote:
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?
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?
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 ?
looking forward to your answer.
Best Regards
Wang wei
Dear colleagues in CGP/JGP/KGP, Below I send you my homework (action item 2) which is "writing on the number of allocatable variants" issue. I divided it into 2 sub-issues as below. 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 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. ==
participants (3)
-
HiroHOTTA -
Yoshiro YONEYA -
王伟