- ChineseGP - lists.icann.org

Revised version of CJK coordination presentation ppt tomorrow
by HiroHOTTA June 24, 2015

June 24, 2015

Please see attached the revised version of CJK coordination presentation ppt for tomorrow. I tried to incorporate your comments and inputs to the ppt. If you have further comments, please send them to me by 7 am tomorrow (Wednesday). HIro

2 3

draft agenda items of CJK coordination meeting Thursday 1:300-15:00
by HiroHOTTA June 24, 2015

June 24, 2015

Dear all, Below are the agenda items I currently imagine for the CJK coordination meeting on Thursday 13:00-15:00. Please comment/add/.... by 3pm today in Argentina time, because I plan to send the draft agenda to ICANN and IP as soon as possible. 1. reduction of allocatable labels - continued from Monday 2. finalizing terminology document 3. terminology used in updated CJK Integration Algorithm Best, Hiro

1 1

Statistics of generated variant labels
by Yoshiro YONEYA June 24, 2015

June 24, 2015

Dear all, Please find attached statistics of generated variant labels. FYI, The maximum variant number for one character in LGR-2 (LGR-beta) is 7 (3 characters), so combination of them (only 3 characters!) generates 343 labels. The 3 characters are: 札鹸寧 Regards, -- Yoshiro YONEYA <yoshiro.yoneya(a)jprs.co.jp>

2 1

[lgr] IDN Program Update and Workshop at ICANN 53 in Buenos Aires
by Fahd Batayneh June 24, 2015

June 24, 2015

Friends and Colleagues, I'd like to bring to your attention the following two sessions that will take place at ICANN 53 in Buenos Aires today (Wednesday June 24, 2015). The sessions are: . IDN Program Update | 13.30 - 14.45 UTC | http://buenosaires53.icann.org/en/schedule/wed-idn . IDN Root Zone LGR Workshop | 16.00 - 17.15 UTC | http://buenosaires53.icann.org/en/schedule/wed-lgr Both sessions have Remote Participation facilities. Thank you, Fahd Batayneh ICANN _______________________________________________ lgr mailing list lgr(a)icann.org https://mm.icann.org/mailman/listinfo/lgr

1 0

Statistics of registered variant labels
by Yoshiro YONEYA June 24, 2015

June 24, 2015

Dear all, Please find attached statistics of registered variant labels. The domain names are anonymised due to .JP's policy. Each characters are replaced by the category like Hiragana and Katakana. The equivalency of registrant and nameserver are checked by WHOIS output. As you see, some of them use new and old form Kanji simultaneously. Regards, -- Yoshiro YONEYA <yoshiro.yoneya(a)jprs.co.jp>

1 1

review solicitation: Integration Algorithm
by Yoshiro YONEYA June 23, 2015

June 23, 2015

Dear all, Please review following integration algorithm. I will try to explain this on Thursday meeting if time allows. Of course, your questions, comment and suggestions prior to the meeting are very welcome. If you want to see pretty-print form (PDF), please let me know. Major changes since v0.2 are: - LGR-1 -> LGR-alpha, LGR-2 -> LGR-beta - Notation of variable-like keywords changed to ${keywords} style - Bug fix in Step3, 1.1.2 and 1.1.3 ====================================================================== CJK Integration Algorithm (v0.3) Precondition - Each of CJK Generation Panels (GPs) generates LGR for each language TLD before integration. > CJK GPs pick up ideographic variants for CJK from domain name usage perspective. > CJK GPs don’t elaborate ideographic variants for CJK from linguistic perspective. - CJK GPs agree on the mechanism (steps) to integrate and extract each language (script) LGR. Step 1: Each CJK GP generates its own LGR (hereinafter, LGR-alpha) - LGR-alpha generation process is left to each CJK GP. - LGR-alpha format must follow XML schema for LGR. <https://datatracker.ietf.org/doc/draft-davies-idntables/> - Each code point must have individual <char> element (i.e. don’t use <range> element). - Each <char> element in LGR-alpha must have reflexive mapping as <var> element (i.e. each code point must have explicit variant type/subtype). - WLE of Each LGR-alpha must not conflict (Conflict of WLE must be coordinated and solved at this step). Step 2: CJK GPs collectively generate a merged table of each LGR-alpha (hereinafter, LGR-M) 1. Extract every <char> element tagged “sc:Hani” from each LGR-alpha. 2. For each extracted <char> element, check the existence of another <char> element with the same code point (“cp” value), and if exitsts, merge them into one element. At this time, “type” attribute of <var> element must be removed. 3. After the check was finished, record every merged <char> elements to LGR-M. - Repertoire of LGR-M is the union of all sc:Hani in each CJK LGR-alpha. - Variants of each <char> elements in LGR-M is the union of all variants defined for the code point in each CJK LGR-alpha. - LGR-M does not have following information. > Language tag. > Variant type/subtype attribute of <var> elements. > WLE (Whole Label Evaluation rules). Step 3: Each CJK GP extract its original repertoire with integrated variants from LGR-M. 1. For each <char> element in its LGR-alpha (hereinafter, ${char:: LGR-alpha}), extract <char> element of the same code point (“cp” value) from LGR-M (hereinafter, ${char::LGR-M}). 1.1. For each <var> element in ${char::LGR-M} (hereinafter, ${var::LGR-M}), compare with <var> elements in ${char::LGR-alpha} (hereinafter, ${var::LGR-alpha}). 1.1.1. If ${var::LGR-M} has the same code point (“cp” value) with one of ${var::LGR-alpha}, then copy “type” attribute of corresponding ${var::LGR-alpha} to ${var::LGR-M}. 1.1.2. Otherwise, if ${var::LGR-M} has the same code point (“cp” value) with any of <char> elements in LGR-alpha, set “type” attribute with value “allocatable” to ${var::LGR-M}. 1.1.3. Otherwise, set “type” attribute with value “blocked” to ${var::LGR-M}, and record the code point of ${var::LGR-M} to Out-of-Repertoire list (hereinafter, ${OoR-list}). 1.2. Record ${char::LGR-M} to Integrated-Repertoire list (hereinafter, ${IR-list}). Step 4: Each CJK GP add “Out of Repertoire” code points for symmetry. 1. For each code point in ${OoR-list} (hereinafter, ${cp::OoR-list}), extract <char> element of the same code point (“cp” value) from LGR-M (hereinafter, ${char::LGR-M}). 1.1. For each <var> element in ${char::LGR-M} (hereinafter, ${var::LGR-M}), compare ${cp::OoR-list} and code point (“cp” value) of ${var::LGR-M}. 1.2. If the two code points are the same, add “type” attribute with value “out-of-repertoire-var” to ${var::LGR-M}. 1.3. Otherwise, add “type” attribute with value “blocked” to ${var::LGR-M}. 1.4. Record ${char::LGR-M} to ${IR-list}. Step 5: Each CJK GP merge WLE in LGR-alpha into one. 1. Each GP extract <rules> element from each LGR-alpha and merge them into one WLE (generate integrated <rules> element, hereinafter, ${rules::LGR-M}). 2. Each GP add following rule to ${rules::LGR-M} for handling “out-of-repertoire-var” variant type. <action disp=”invalid” any-variant=”out-of-repertoire-var” /> Step 6: Each CJK GP generates integrated LGR (hereinafter, LGR-beta). 1. Each GP extract preambles from its LGR-alpha (hereinafter, ${preamble::LGR-alpha}). 2. Each GP extract all <char> elements with “tag” value other than “sc:Hani” and record to IR-list. 3. Each GP merge ${preamble::LGR-alpha}, IR-list and ${rules::LGR-M} into LGR-beta. - In other words, this step replaces body of <data> element and <rules> element of LGR-alpha to IR-list and ${rules::LGR-M} respectively. ====================================================================== Regards, -- Yoshiro YONEYA <yoshiro.yoneya(a)jprs.co.jp>

1 0

review solicitation: Terminology for CJK coordination committee and IP (v0.5)
by Yoshiro YONEYA June 23, 2015

June 23, 2015

Dear IP members, CJK GP members, Edmon and Sarmad, Please review following terminology text. I'd like to finalize the text at Thursday meeting. Marc gave me a suggestion to use LGR-alpha and LGR-beta instead of LGR-1 and LGR-2. It seems more generic term representing the development status of LGR. Your comments, suggestions and refinements are very welcome. ====================================================================== Terminology for CJK coordination committee and IP (v0.5) Background CGP, JGP, and KGP are collaborating to create Root zone LGR for CJK. CJK GPs’ collaboration is not limited to among us, but also involving IP and ICANN. For the efficiency and the good progress, we should have common terminology definition for key concepts. Terminology (1) Script Based on Unicode, script is a collection of letters and other written signs used to represent textual information in one or more writing systems. Ex. Han, Hiragana, Katakana and Hangul. (2) Chinese script, Japanese script, Korean script Script(s) used in the language. Chinese script is Han, Japanese script is a mixture of Han, Hiragana and Katakana, and Korean script is a mixture of Han and Hangul. In Root zone LGR context, Chinese script, Japanese script and Korean script are equivalent to und-hani, und-jpan and und-kore respectively. Here, hani, jpan and kore are terms from ISO 15924. (3) Disposition Result of whole level evaluation (WLE). Disposition is assigned to a label, not to a character. In general, the Root zone process only allows the two dispositions 'allocatable' and 'blocked' (as well as 'invalid' for labels that are not valid at all). It is not possible to add new dispositions other than 'allocatable', 'blocked' and 'invalid'. Label disposition assigned as a result of WLE cannot be reassigned. (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. (5) LGR-1 LGR-1 is an LGR defined by each GP for CJK integration purpose. Each CJK GP can define LGR-1 independently from each other. LGR-1 must consist of language tag (one of und-hani, und-jpan, and und-kore), repertoire of allowed characters for applied-for label, variants of each character where variant type (and variant subtype if necessary) is associated with each variant characters, and WLE. The variant type must not have “out of repertoire var”. LGR-1 is an intermediate product and it is not a final proposal of each GP. The development of LGR-1 can be cyclic. Once CJK GPs generate each LGR-2, each GP assess it and modify LGR-1 if necessary. This cycle can be repeated until all CJK GPs get conclusion. (6) LGR-2 LGR-2 is a LGR generated by LGR-1 integration process. LGR-2 is generated for each Chinese/Japanese/Korean script. The differences between each LGR-2 are (A) language tag, (B) repertoire, and (C) variant type (including variant subtype) of each variant. The set of variants and WLE are common between LGR-2s. Once each CJK GP concluded their LGR-1, the generated LGR-2 to be a final proposal of them. NOTE: THESE TERMINOLOGY DEFINITIONS ARE VERY PRELIMINARY AND ARE NOT EXHAUSTIVE. THIS IS PREPARED FOR (Y)OUR REVIEW. ====================================================================== Regards, -- Yoshiro YONEYA <yoshiro.yoneya(a)jprs.co.jp>

5 5

agenda items for Thursday CJK+IP meeting
by HiroHOTTA June 22, 2015

June 22, 2015

Dear CJK GP colleagues, Thank you for your participation in today's CJK+IP meeting. We will continue the discussion on Thursday 09:00-11:00. The agenda includes "reduction of allocatable variant labels", which is a continuation of today's discussion. Please propose other agenda items if you have any by tomorrow (Tuesday) night. Regards, Hiro

1 0

[lgr] regarding IETF lager wg-to-be
by Marc Blanchet June 22, 2015

June 22, 2015

Hello, in a discussion with some GP members, there was a question about the status of an initiative in IETF named ‘lager’ (stands for LAbel GEneration Rules). This initiative is to create a working group to work on a IETF standards-track specification for LGRs, based on draft-davies-idntables. The IESG is going to discuss it this week. Below is the relevant info. Obviously, you are very invited to participate in the working group. A mailing list has been setup to discuss. Marc. ======== mailing list: https://www.ietf.org/mailman/listinfo/lager charter: http://datatracker.ietf.org/wg/lager/charter/ Charter for proposed Working Group Domain registries, particularly those implementing IDNA (RFC 5890 et.al), usually maintain a set of criteria (or "ruleset") that governs permissible labels allowed for registration, such as [IANAIDNTABLES]. These rulesets are commonly a mixture of eligible code points along with contextual criteria that must be met concerning the positioning of certain code points. Some registries also specify rules regarding variant labels and how they are to be handled. Domain registries commonly need to share these rules, but there is no interoperable format that can be used that can support many common use cases. This group seeks to produce such a format, which will enable re-use and simpler implementation of rulesets in registries. A comprehensive format specification has been developed, named Label Generation Rules, primarily to support the rules to be used for the DNS Root Zone [Davies]. This group will use this specification as a starting point to develop a common XML language that provides a superset of functionality of current specifications [RFC 3743, RFC 4290, et.al], along with other known use cases. This single format is expected to supersede existing formats, and form the basis for future rulesets used at different levels of the DNS hierarchy. Work items: - Standard Track Specification of the Label Generation Rules References: [Davies] https://datatracker.ietf.org/doc/draft-davies-idntables/ [IANAIDNTABLES] https://www.iana.org/domains/idn-tables Proposed milestones Date Milestone Dec 2015 Send the Label Generation Rules specification to the IESG draft-davies-idntables _______________________________________________ lgr mailing list lgr(a)icann.org https://mm.icann.org/mailman/listinfo/lgr

1 0

Redefinable
by Dillon, Chris June 22, 2015

June 22, 2015

Dear Yoshiro and colleagues, I¹d like to start a discussion about improving the last sentence of terminology 3 (given in full below for context), along the lines mentioned yesterday: (3) Disposition Result of whole level evaluation (WLE). Disposition is assigned to a label, not to a character. In general, the Root zone process only allows the two dispositions ³allocatable² and ³blocked² (as well as ³invalid² for labels that are not valid at all). And dispositions for the labels are not redefinable. There was a feeling yesterday that ³reassignable² may be better than ³redefinable², and ³assign² was already used of ³disposition² in the second sentence in the paragraph. The meaning would then be that dispositions cannot change as a result of some other process. If, on the other hand, the meaning is that it is not possible to create new dispositions, perhaps we could have something like: It is not possible to add new dispositions other than ³allocatable², ³blocked² and ³invalid². Regards, Chris. == Research Associate in Linguistic Computing, Centre for Digital Humanities, UCL, Gower St, London WC1E 6BT Tel +44 20 7679 1599 (int 31599) ucl.ac.uk/dis/people/chrisdillon

3 9