ICANN ICANN Email List Archives

[comments-lgr-second-level-07jun16]


<<< Chronological Index >>>        Thread Index >>>

Comments on Reference Label Generation Rulesets (LGRs) for the Second Level

  • To: comments-lgr-second-level-07jun16@xxxxxxxxx
  • Subject: Comments on Reference Label Generation Rulesets (LGRs) for the Second Level
  • From: Yoshiro YONEYA <yoshiro.yoneya@xxxxxxxxxx>
  • Date: Sun, 17 Jul 2016 21:02:38 +0900

Dear ICANN,

Please find my comments on Reference Label Generation Rulesets (LGRs) 
for the Second Level as follows.  Also please note that these comments 
are based on technical aspects.

- Comments to
  "Reference Label Generation Rules (LGR) for the Second Level -- Overview and 
Summary"
  
<https://www.icann.org/en/system/files/files/lgr-second-level-overview-summary-20may16-en.pdf>

  + Page3, 2nd paragraph
    Adding some references to existing integration work at RootLGR project 
    would be helpful.

  + Page5, last paragraph
    The referred URL is too old.
    <https://datatracker.ietf.org/doc/draft-ietf-lager-specification/>
    is much preferrable.


- Comment to 
  "Evaluation of Deviation from the Second Level LGR References"
  
<https://www.icann.org/en/system/files/files/lgr-second-level-evaluation-deviation-07jun16-en.pdf>

  + Page1, 3rd paragraph
    In the sentence "Current reference LGRs include a core set of code
    points, variant rules, and Whole Label Evaluation (WLE) rules that
    must be supported and also include an (optional) extended ruleset
    serving special needs based on geographical or other variations.", 
    I think the phrase "must be supported" is too strong.  I suggest
    rephrasing it as "must be referred to".


- Comments to
  "Label Generation Rules for Japanese"
  
https://www.icann.org/sites/default/files/packages/lgr/lgr-second-level-japanese-15may16-en.html

  + Section "Repertoire"
    incorrect: JIS X 208-1990
    correct:   JIS X 0208:1997

  + Section "Rules"
    Explanation about U+3006 and U+30FC in Japanese specific rules are
    incorrect.

    U+3006 is not a word separator, but is an alternative form of U+7DE0.
    In the Unicode specification, the character U+3006 is classified as
    "Common" in Scripts.txt and "Hani Hira Kana" in ScriptExtensions.txt.
    This is the reason why U+3006 was required to have special context 
    rule by PDT provider.  I strongly suggest removing the requirement 
    of context rule for U+3006.  Otherwise, the explanation for the
    necessity of the context rule must be consistent with previous PDT 
    specification.

    U+30FC is a kind of iteration mark which denotes to prolong the
    previous vowel.  The common usage of U+30FC is explained in the
    Unicode standard [123], but it is not the restricted rule.
    In the Unicode specification, the character U+30FC is classified as
    "Common" in Scripts.txt and "Hira Kana" in ScriptExtensions.txt.
    This is the reason why U+30FC was required special context rule by 
    PDT provider.  I strongly suggest removing the requirement of 
    context rule for U+30FC.  Otherwise, the explanation for the
    necessity of the context rule must be consistent with previous 
    PDT specification.

  + Section "Table of References"
    [110]
    incorrect: JIS X 208-1990
    correct:   JIS X 0208:1997

    [123]
    incorrect: section 18.4 Hiragana and Katakana
    correct:   section 12.4 Hiragana and Katakana
    (18.4 is correct if [123] refers to the Unicode 7.0.0 or later)


Regards,

-- 
Yoshiro YONEYA <yoshiro.yoneya@xxxxxxxxxx>



<<< Chronological Index >>>        Thread Index >>>

Privacy Policy | Terms of Service | Cookies Policy