Dear Wang Wei, You raise an important question. Let me attempt to give you my best understanding. The central prescription on the disposition of variant labels based on the definition of the variants appears to be that the final outcome is that every variant *label *is either "allocatable" or "blocked" and that that disposition (for the same label) may be different by script tag. Your suggested scheme appears to satisfy that prescription while allowing a reduction of allocatable labels as mandated in section A.3.3 of the procedure. To consider this in detail: The development of the LGR for the root zone is covered by the Procedure; section B.1.2 describes the output elements. To answer your question we need to look at items 3 and 4. "3. Assignment of one or more “tags” to each code point in the repertoire, and, by extension, to each disposition of a variant in (4). For the same label, different dispositions may exist for the same variant label, as long as the variant labels do not share common tag values." This tells us that variant labels for "und-Jpan" and "und-Hani" do not have to have the same disposition, because the script tags are different. "4. The *disposition of the labels* resulting from the application of the rules in (2). For a given code point in the repertoire, this element specifies whether a resulting variant label is blocked or allocatable, /*depending on how the variant label was generated*/. The same code point under different tags (see 3) might generate an allocatable variant label in one case, and a blocked variant label in another." (emphasis added) This tells us that what matters is the ultimate disposition of the variant *label *and not primarily the type value associated with variant code point mapping in the XML format. Section B.3.1 states that whole label evaluation rules can be used to further restrict allocatable labels and section A.3.3 calls for the LGR "to minimize the number of allocatable variants." I personally believe that reducing the number or allocatable variants is indeed worthwhile, and the discussion that followed the release of the procedure as well as the user experience report, ultimately leading to the risk study and the SSAC recommendations bear me out on this. I further believe, that not addressing the problem of unnecessary allocatable variants may well violate one or more of the Principles that are set forth in the procedure, not least the Conservatism Principle. This makes it essential to look for a solution. Accordingly, it seems to me that your suggestion to divide allocatable variant mappings by using the distinct type values of "trad", "simp" and "both" together with the necessary actions will allow a way to create dispositions for variant *labels *that are either "allocatable" or "blocked" as specified in the procedure, but with the benefit of *sharply reducing* the set of "allocatable" variant labels. Thus your suggested method would fulfill the mandate in the procedure "to minimize the number of allocatable variants". The mechanism you propose can be characterized as a way to assign disposition of variant labels "depending on how the label was generated". This is because the type values are *associated with the variant mappings*, not with the code points. Because of that, they would fall under item 4, including the fact that the disposition of variants may differ by script-tag. Ordinary WLE rules, on the other hand, those that act on the code points, are restricted: "if a *code point is associated* with some whole-label evaluation rules, those whole-label evaluation rules must be the same no matter what the tag." Now, the XML Syntax was finalized only after the procedure was written, so we cannot expect that the procedure (and the examples in it) will make reference to specific syntax elements, but it may be possible to examine these syntax elements in light of the procedure to determine where they fit. In the XML, <action> elements that use "match" and "not-match" are associated with <rule> elements that *act on code points*. This clearly makes them equivalent to that the procedure calls whole label evaluation rules associated with code points and by the procedure such code point-dependent rules would be required to be independent of script tag. In contrast, <action> elements that use "any-variant", "only-variants" etc. *act on variant mappings* and not on code points. Therefore, they "depend on how the variant is generated", as defined in item (4). That would make it possible for the latter type of <action> to be specific to the script-tag. Because the disposition of variant labels is specific to the script tag, I can no reason why the JGP couldn't use its own type values. (That assumes, that there was an interest in the JGP to allow allocatable variant labels for the und-Jpan tag.) You asked:
Finally, do that mean IP accept the solution...
As a general policy, the Integration Panel never pre-approves any feature of any LGR proposal. However, the Integration Panel or its members are happy to point out any known areas of concern ahead of time, to give Generation Panels the chance to address those issues prior to formal submission. A./ On 11/8/2014 11:10 PM, Wang Wei wrote:
Procedure to Develop and Maintain the Label Generation Rules for the Root Zone in Respect of IDNA Labels
Dear Asmus
Thanks for your detailed expatiation in the last mail.
here is some other questions about language-tag and variant types we countered when we make whole label rules in XML format.
In the draft of “Representing Label Generation Rulesets using XML”, Appendix B <https://tools.ietf.org/html/draft-davies-idntables-08>. How to Translate RFC 3743 <https://tools.ietf.org/html/rfc3743> based Tables into the XML Format
We have an example as follows:
<data> …
<char cp="9FA0" tag="sc:Hani">
<var cp="9FA0" type="both" comment="identity" />
</char>
<char cp="9FA2" tag="sc:Hani">
<var cp="548C" type="simp" />
<var cp="924C" type="block" />
<var cp="9FA2" type="trad" comment="identity" />
</char>….
<data>
……
<rules> <!-- RFC 3743 rules, draft-davies-idntables-08#section-6.2.2 -->
<action disp="block" any-variant="block" />
<action disp="allocate" only-variants="simp both" />
<action disp="allocate" only-variants="trad both" />
<action disp="block" any-variant="simp trad" />
<action disp="allocate" comment="catch-all" />
</rules>
Does that mean, for the “allocatable” variants, we are allowed to define sub-variant-types for them?
In the above example, sub-variant-types include trad, simp and both.
Moreover, is JGP allowed to do the similar thing, like define “old”, “new”, “both” under allocatable variants?
then JGP will generate its own whole label rule in accordance with its sub-variant-types.
Finally, do that mean IP accept the solution that for the same variant-mapping-cluster, different language tag will introduce different whole label generation rule?
Looking forward to your reply.
Regards
Wang Wei
*发件人:*Asmus Freytag [mailto:asmusf@ix.netcom.com] *发送时间:*2014年10月28日12:33 *收件人:*Sarmad Hussain; Wang Wei *抄送:*hotta@jprs.co.jp; 'KIM Kyongsok'; LGR@icann.org *主题:*Re: [lgr] Question about coordination principles for C J and K
*From:*Wang Wei [mailto:wangwei@cnnic.cn] *Sent:* Tuesday, October 28, 2014 7:31 AM *To:* Sarmad Hussain; 'KIM Kyongsok'; hotta@jprs.co.jp <mailto:hotta@jprs.co.jp> *Cc:* ChineseGP@icann.org <mailto:ChineseGP@icann.org>; LGR@icann.org <mailto:LGR@icann.org> *Subject:* Question about coordination principles for C J and K
Dear Sarmad
During the recent discussion in ICANN 51 and CGP fortnightly meeting, we realized that there is different understandings about the coordination principles proposed by IP.
CGP discussed this issue with J and K, then we drafted a document (as the attached file) including two different solutions based on two different understandings.
Could you please tell us which solution complies the original intention of the coordination principles?
Regards
Wang Wei
Dear Wang Wei,
the way variants are defined for the integrated root zone LGR matches the second understanding - they are what you call "tightly coupled" in your document and it is not possible to have the und-Jpan LGR treat them as independent while the und-Hani LGR treats them as variants.
2)Opposite to the case 1, the other understanding is that “Variant mappings” is a tight coupled relationship which applies in all LGRs, and “Variant Type” must be ”allocatable” or “blocked”, illustrated by the following example:
*Code Point*
*Allocatable Variant*
*Blocked Variant*
*Tag*
一(U+4E00)
--
壱(U+58F1)
壹(U+58F9)
弌(U+5F0C)
und-hani
壹(U+58F9)
--
一(U+4E00)
壱(U+58F1)
弌(U+5F0C)
und-hani
弌(U+5F0C)
一(U+4E00)
壹(U+58F9)
壱(U+58F1)
und-hani
壱(U+58F1)
壹(U+58F9)
一(U+4E00)
弌(U+5F0C)
und-hani
一(U+4E00)
--
壹(U+58F9)
弌(U+5F0C)
壱(U+58F1)
und-Jpan
壹(U+58F9)
--
一(U+4E00)
弌(U+5F0C)
壱(U+58F1)
und-jpan
弌(U+5F0C)
--
一(U+4E00)
壹(U+58F9)
壱(U+58F1)
und-jpan
壱(U+58F1)
--
一(U+4E00)
壹(U+58F9)
弌(U+5F0C)
und-jpan
In this table, no matter what language tag was set, for any given code point in a variant mapping cluster, its variants must be configured to either “allocatable” or “blocked”, its variants cannot stay as an INDEPENDENT code point, regardless of the fact that in Japanese language environmentthey are treated as different OLD form and NEW form.
It means that if anybody registers the label .一一for the first time under the und-Jpan tag, then nobody can register the label .弌弌under any tag. If they had first registered the label .弌弌under the und-Hani tag, then the same applicant can request to register the label.一一as well (but whether that request is granted, and how, is outside the scope of the LGR).
Moreover, only the allocatable code points can be used to generate valid whole label package, and this whole label package will go (be allocated) to the SAME applicant, which means, the co-existence of old form label registrant and new form label registrant will not happen at Root level.
if it is felt desirable to allow somebody to register the old form and the new form under the "und-Jpan" tag, then the only way to do that is to declare these as "allocatable" variants under the und-Jpan tag.
Because the root is a shared resource, variants must be tightly coupled. A./