Dear Asmus Thanks for your elaboration. It really help us to reduce ambiguity and conflicts. 发件人: Kenny Huang, Ph.D. [mailto:huangksh@gmail.com] 发送时间: 2014年10月28日 14:15 收件人: Asmus Freytag 抄送: Sarmad Hussain; Wang Wei; Hiro HOTTA; KIM Kyongsok; LGR@icann.org 主题: Re: [ChineseGP] [lgr] Question about coordination principles for C J and K Dear Asmus, Thanks for your feedback, please see my comments below Kenny Huang 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. The presented sample table complies with the principles (1)same variant mappings amount CJK (2)variant types (allocatable/block) can be different. in the case, und-Jpan treats them as "block variants" while und-Hani treats them with (allocatable/block) 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 environment they are treated as different OLD form and NEW form. All variants under 2nd column and 3rd column has been assigned variant type (allocatable/block). The default type of the 1st column is "allocatable". 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). Yes, this is the goal of the proposal based on informed constraints. 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. Yes, only the allocatable code points (1st column) can be used to generate valid whole label package (2nd/3rd column). (ref: RFC3743) 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. yes, if the presented sample table is considered "tightly coupled". Otherwise it has to be clearly defined somewhere. Regards Kenny Huang _______________________________________________ lgr mailing list lgr@icann.org https://mm.icann.org/mailman/listinfo/lgr