- Koreangp - lists.icann.org

[lgr] IDN Root Zone LGR (Workshop) | Wednesday, 11 February 2015 | 13:00 – 14:15 (Local Singapore Time)
by Jia-Juh Kimoto Feb. 3, 2015

Feb. 3, 2015

Meeting: IDN Root Zone LGR (Workshop) Date: Wednesday, 11 February 2015 Time: 13:00 – 14:15 (Local Singapore Time) Location: Moor Conf. Room | 4th Level Raffles City Convention Center Remote Participation: http://singapore52.icann.org/en/schedule/wed-lgr Overview: This session will focus on explaining the steps involved in the LGR procedure implementation and providing more detailed guidance by the IDN team and the Integration Panel to address the issues which have been raised by the Generation Panel members for different scripts. Additionally, script communities will provide updates on their progress. Agenda: 1. Introduction – Sarmad Hussain 2. Integration Panel Discussion a. Guidelines for LGR Development – Wil Tan b. How to Design Variants and WLE Rules – Michel Suignard 3. Community Updates a. Armenian GP Update – Igor Mkrtumyan b. Cyrillic GP Update – Dusan Stojičević and Yuriy Kargapolov c. Beyond the Root Zone - Applications of LGR – Philippe Collin 4. Q/A _______________________________________________ lgr mailing list lgr(a)icann.org https://mm.icann.org/mailman/listinfo/lgr

1 0

[lgr] IDN Program Update | Wednesday, 11 February 2015 | 9:00 – 10:15 (Local Singapore Time)
by Jia-Juh Kimoto Feb. 3, 2015

Feb. 3, 2015

Meeting: IDN Program Update Date: Wednesday, 11 February 2015 Time: 9:00 – 10:15 (Local Singapore Time) Location: Sophia Conf. Room | 4th Level Raffles City Convention Center Remote Participation: http://singapore52.icann.org/en/schedule/wed-idn Overview: ICANN’s IDN Program team will discuss the overall progress of the program, giving details of the different projects the IDN program is undertaking. This includes the community-based efforts to develop rules to validate and determine variants of top-level domains in different scripts. They will share the stage with community members who are making the decisions about characters in a particular script to develop these “Label Generation Rules” for the Internet’s Root Zone. These community representatives will share the challenges associated with the work and report on the progress. Agenda: 1. IDN Program – Overview and Progress – Sarmad Hussain 2. Update by Integration Panel – Wil Tan 3. Community Updates on Generation Panels a. Arabic GP Update – Nabil Benamar b. Japanese GP Update – Hiro Hotta and Yoshiro Yoneya c. Korean GP Update – Kyongsok Kim d. Chinese GP Update – Kenny Huang 4. Q/A _______________________________________________ lgr mailing list lgr(a)icann.org https://mm.icann.org/mailman/listinfo/lgr

1 0

IDN Program - Coordination Meeting between CJK GPs [CLOSED] | Monday, 9 February 2015 | 2:30-3:30pm (Local Singapore Time)
by Jia-Juh Kimoto Feb. 3, 2015

Feb. 3, 2015

Meeting: IDN Program - Coordination Meeting between CJK GPs [CLOSED] Date: Monday, 9 February 2015 Time: 14:30 - 15:30 (Local Singapore Time) Location: Moor Conf. Room | 4th Level Raffles City Convention Center Remote Participation: * Adobe Connect URL: https://icann.adobeconnect.com/cjk_gp/ * PGI Guest passcode: 1918217881 * PDF list of PGI dial-in numbers:

1 0

Coordination Meeting between CJK GPs [CLOSED] | Monday, 9 February 2015 | 2:30-3:30pm (Local Singapore Time)
by Jia-Juh Kimoto Feb. 3, 2015

Feb. 3, 2015

Meeting: Coordination Meeting between CJK GPs [CLOSED] Date: Monday, 9 February 2015 Time: 14:30 - 15:30 (Local Singapore Time) Location: Moor Conf. Room | 4th Level Raffles City Convention Center Remote Participation: * Adobe Connect URL: https://icann.adobeconnect.com/cjk_gp/ * PGI Guest passcode: 1918217881 * PDF list of PGI dial-in numbers:

1 0

[lgr] Sarmad Hussain is forwarding an email to you
by Sarmad Hussain Feb. 1, 2015

Feb. 1, 2015

ICANN staff = ICANN staff = Hi LGR Email List member, Sarmad Hussain thought you'd be interested in this: http://us3.forward-to-friend1.com/forward/show?u=818d573897ed5ea25ee71ebc1&… Sarmad Hussain also included this personal message to you: Hi alll, ICANN EMEA Newsletter interviews Yuriy Kargapolov of Cyrillic Generation Panel. See the Community Highlights section. Did you find the link interesting? You can forward it on to your friends, too: http://us3.forward-to-friend1.com/forward?u=818d573897ed5ea25ee71ebc1&id=60… You can subscribe for more emails at: http://icann.us3.list-manage2.com/subscribe?u=818d573897ed5ea25ee71ebc1&id=… * Note: if any of the URLs above are not clickable, you can copy/paste them into your web browser. <http://www.mailchimp.com/monkey-rewards/?utm_source=freemium_newsletter&utm…> _______________________________________________ lgr mailing list lgr(a)icann.org https://mm.icann.org/mailman/listinfo/lgr

1 0

[lgr] FW: ICANN News Alert -- Third Face-to-Face Meeting for the Task Force on Arabic Script IDNs (TF-AIDN) to Convene in Singapore
by Sarmad Hussain Feb. 1, 2015

Feb. 1, 2015

Dear All, FYI: ArabicGP is meeting in Singapore and intends to finalize its proposal for Root Zone LGR. Kindly note that you are welcome to come and observe. There is also an open house on Sunday, in case you want to interact with Arabic GP. Regards, Sarmad From: ICANN News Alert [mailto:communications@icann.org] Sent: Saturday, January 31, 2015 6:24 AM To: Sarmad Hussain Subject: ICANN News Alert -- Third Face-to-Face Meeting for the Task Force on Arabic Script IDNs (TF-AIDN) to Convene in Singapore <http://www.icann.org/> News Alert https://www.icann.org/news/announcement-2015-01-30-en _____ Third Face-to-Face Meeting for the Task Force on Arabic Script IDNs (TF-AIDN) to Convene in Singapore 30 January 2015 When: February 6-8, 2015 Where: Raffles City Convention Center, Singapore (Room "Fullerton") <https://www.icann.org/sites/default/files/assets/tf-aidn-468x268-22mar14-en…> Members of the TF-AIDN at the First F2F Meeting in Singapore during March 20-22, 2014 Background Since the second Face-to-Face meeting of the TF-AIDN in Istanbul, Turkey last June, the group has been working on several fronts related to Arabic Script IDNs including scrutinizing the code point repertoire and defining variant code points for the proposal for Root Zone Label Generation Rules (LGR) and the Universal Acceptance of Arabic script IDNs. The third face-to-face meeting in Singapore will conclude the work covering topics such as the Arabic Script Code Point Repertoire, Code Point Variants, Variant Disposition, Whole Label Evaluation Rules and the XML Representation of the Data, all in the context of finalizing the proposal for the Arabic script for the Root Zone LGR. The group will also discuss the next steps to be taken like addressing the Universal Acceptance of Arabic script IDNs. Though the meeting is closed, observers are welcome to attend. Ten members of the group will be in Singapore, and in addition to the meeting, they are expected to interact at various IDN related sessions with the community. Agenda Friday February 6 (Day I) 8.45 – 9.00 Opening Remarks 9.00 – 10.30 Review of Current Status 10.30 – 11.00 Coffee Break 11.00 – 12.30 Code Point Repertoire Review of Write-up for Code Point Repertoire 12.30 – 13.30 Lunch Break 13.30 – 15.00 Variant Analysis Review of Write-up on Variant Analysis 15.00 – 15.30 Coffee Break 15.30 – 17.00 Variant Disposition (Allocatable vs. Blocked) Saturday February 7 (Day II) 9.00 – 10.30 Variant Disposition – cont. Review of Write-up on Variant Disposition 10.30 – 11.00 Coffee Break 11.00 – 12.30 Whole Label Evaluation Rules 12.30 – 13.30 Lunch Break 13.30 – 15.00 Whole Label Evaluation Rules XML Document 15.00 – 15.30 Coffee Break 15.30 – 17.00 XML Document Sunday February 8 (Day III) 9.00 – 10.30 Review the Complete Document for Submission 10.30 – 11.00 Coffee Break 11.00 – 12.30 Preparation of Presentations for Singapore Community Interaction 12.30 – 13.30 Lunch Break 13.30 – 15.00 Open House 15.00 – 15.30 Coffee Break 15.30 – 17.00 Next Steps (Universal Acceptance; Second Level LGRs, etc.) About the Middle East Strategy Working Group (MESWG) The Middle East Strategy Working Group (MESWG) is an ad-hoc group of Internet experts from the region the strategy covers; i.e. the 22 Arab States, Iran, Afghanistan, and Pakistan (collectively defined as "The Region"). The working group consists of 20 experts from 11 countries of the region. ICANN has coordinated the formation of the working group, and provides all the necessary support to drive its mandate forward. ICANN's strategic goals for its engagement in the region are to: 1. Foster two-way engagement between ICANN and the broader Internet community in the region; 2. Build strong and competitive domain name industry in the region; and 3. Promote multi-stakeholder Internet governance mechanisms in the region. These goals are divided into three strategic focus areas, namely: DNS Security and Stability, Domain Name Industry, and Internet Governance Ecosystem. More on the MESWG can be found online at https://community.icann.org/display/MES/Middle+East+Working+Group. About the Task Force on Arabic Script IDNs (TF-AIDN) TF-AIDN is an initiative of MESWG which focuses on technical issues and solutions to promote Arabic Script IDNs; this includes their definition, secure deployment, and ease of use for the community. The current technical matters include the following: * Arabic Script Label Generation Ruleset (LGR) for the Root Zone; * Second level LGRs for the Arabic script; * Arabic script Internationalized Registration Data Protocol and Practice; * Universal acceptability of Arabic script IDNs and variants; * Technical challenges around registration of Arabic IDNs and variants; * Operational software for Arabic script IDN registry and registrar operations; * DNS security matters specifically related to Arabic IDNs and variants; and * Technical training material around Arabic script IDNs Membership to join the TF-AIDN is always open. Those interested to join the task force on voluntary basis should email their CV and Statement of Interest (SOI) to tf-aidnadmin(a)meswg.org <mailto:tf-aidnadmin@meswg.org> . More on the TF-AIDN can be found online at https://community.icann.org/display/MES/TF-AIDN+Work+Space. _______________________________________________ lgr mailing list lgr(a)icann.org https://mm.icann.org/mailman/listinfo/lgr

1 0

reference to SAC 60 during coordination call between KoreanGP and ChineseGP
by Sarmad Hussain Jan. 21, 2015

Jan. 21, 2015

Dear Prof. Kim, All, Here is the relevant text from SSAC's SAC 60 report (https://www.icann.org/en/system/files/files/sac-060-en.pdf) as mentioned during the call today: Recommendation 7: Should ICANN decide to implement safeguards it should seek to distinguish the following two types of failure modes when a user expects a variant to work but it is not implemented: . Denial of service: the user attempts to visit http://example.Y, reading it as being the same Uniform Resource Identifier (URI) as the http://example.X that, for example, he or she saw in an advertisement, but the connection does not work (lookup fails) because Y is either blocked, withheld, or X has no variant at all, and example.Y is not registered. . Misconnection: the user attempts to visit http://example.Y, reading it as being the same URI as the http://example.X that, for example, he or she saw in an advertisement, but arrives at a site controlled by a registrant different to that of example.X. The second case is much more dangerous than the first one. In the first case, the user is frustrated and may conclude that "the Internet does not work," but no serious harm has arisen. The second case is problematic even if this effect is not the result of malicious work on the part of Y's operator or example.Y registrant. Misconnections to a perfectly legitimate site operating at example.Y present issues of possible credential compromise or other accidental disclosure of information in addition to user confusion and frustration. Regards, Sarmad

2 1

Chinese, Japanese and Korean GP Coordination meeting 2:30-3:30pm Monday 9 Feb. at ICANN 52, Singapore
by Sarmad Hussain Jan. 19, 2015

Jan. 19, 2015

Dear All, We will be organizing a coordination meeting between Chinese, Japanese and Korean Generation Panel members during the Singapore meeting as per the following schedule. IP members will be present. We will also arrange remote participation during this session. Time: 14:30 - 15:30 Date: Monday, 9 February 2015 Room: To be announced If this is insufficient time, please let us know details and we can organize an additional session. We will share further details as soon as they are available. Regards, Sarmad -----Original Message----- From: hotta(a)jprs.co.jp [mailto:hotta@jprs.co.jp] Sent: Sunday, January 18, 2015 8:19 PM To: Dillon, Chris Cc: ?超; Sarmad Hussain; Yoshiro YONEYA; ChineseGP(a)icann.org Subject: Re: [ChineseGP] proposal to eliminate the divergence between us > I’m also looking forward to discussing these things in Singapore! Yes, definitely. Is there a plan for CJK & IP & ICANN to meet in Singapore already? Hiro

4 5

Re: [Koreangp] [ChineseGP] proposal to eliminate the divergence between us
by Dillon, Chris Jan. 18, 2015

Jan. 18, 2015

Dear Hiro, Thank you for your emails. XX means (the same) two Han characters (followed by). Sorry for the confusion. ASCII and Arabic numerals in Japanese addresses is certainly another hot topic. I've attached Professor Kim's presentation. "Passive variants" are indeed the same phenomenon as what I have referred to as "adopted/inherited variants". Any character only occurring in Japanese, for example栞, will need to be defined somewhere actively, if it is ever to be used in a Japanese TLD. The same is true for 国字 (characters made in Japan), although they only occur in Japanese.* I think I have found one国字, 込 ‘put in’ which also occurs in the Korean word 진입 'application', if it is written in hanja. *Interestingly, the国字, 掴 ‘catch’ exists in two forms, the other being 摑. Presumably掴is a 拡張新字体 (Extended New Form), as it is not a Joyo Kanji (in the Japanese Ministry of Education table). There is a plan for the CP, KP and JP to meet in Singapore, but we don't have a time or venue yet. Looking forward to seeing you soon, 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 Dear Chris, I'm chasing you but I have to apologize for my slowness. You wrote > From a Japanese (Traditional Chinese and Korean) perspective, .... on > slide 8 of Professor Kim’s presentation, there was a possible > situation where .XX壱 was allocated, disallowing the separate > allocation of . XX一, although 一 is a much more basic character. I'd like to know what XX means here. Does it represent one Unicode character, 2 ASCII characters 'X' and 'X', or something else? BTW, could you send Professor Kim's presentation which you referred to here? Hiro -----Original Message----- From: hotta(a)jprs.co.jp [mailto:hotta@jprs.co.jp] Sent: 18 January 2015 15:16 To: Dillon, Chris Cc: qichao(a)cnnic.cn; Sarmad Hussain; Yoshiro YONEYA; ChineseGP(a)icann.org Subject: Re: [ChineseGP] proposal to eliminate the divergence between us Hi Chris, JGP is investigating how each language GP should generate its LGR. We finally have come to understand that, for example, JGP should have at least "passively defined" variants that are defined in CGP and/or KGP. Borrowing Wang Wei's example, Let's suppose CGP defines 一4E00 (0); 一4E00(86),一4E00(886); 一(0),壱(0),壹(0),弌(0); 壱58F1 (0); 壹58F9(86),壹58F9(886); 一(0),壱(0),壹(0),弌(0); 壹58F9 (0); 壹58F9(86),壹58F9(886); 一(0),壱(0),壹(0),弌(0); 弌5F0C (0); 一4E00(86),一4E00(886); 一(0),壱(0),壹(0),弌(0); JGP defines '一' and '壱' as independent (non-variant) characters, and '壹' and '弌' are not in JGP repertoire. In such a case, JGP must define '一', '壱', '壹', and '弌' as variants, and '一'and '壱' are both allocatable when '一'or '壱' is applied for registration. In JGP, we call this as "passively defined variants" - it seems that 'inherited' or 'adopted' is used by Chris for this. "Passively defined variants" is necessary if this is not automatically calculated in an output of IP. I hope each language GP and IP have a discussion on the possibility and specification of this (automatic) calculation. Hiro > I’m also looking forward to discussing these things in Singapore! Yes, definitely. Is there a plan for CJK & IP & ICANN to meet in Singapore already? Hiro On Fri, 9 Jan 2015 12:16:26 +0000 "Dillon, Chris" <c.dillon(a)ucl.ac.uk> wrote: > Dear Qichao, > Effectively the CN rule becomes a general rule once the mappings are made compatible. Variants in any language LGR may block labels even if they come from an LGR where they would not be blocked. > I like that particular example especially, as it indicates a first come first served situation where a label including a low frequency character (and which is not a variant in all the language LGRs) blocks a label with a high frequency character. > Again this is presuming the “each language has a descriptive LGR of its own situation (with or without variant mappings) and then another LGR (with possibly adopted* variant mappings) which is compatible with other LGRs for the script” model. > *I have been using the word “inherited” for this, but “adopted” (i.e. from other languages using the script) may be better. > Regards, > Chris. > -- > Research Associate in Linguistic Computing, Centre for Digital Humanities, UCL, Gower St, London WC1E 6BT Tel +44 20 7679 1599 (int 31599) www.ucl.ac.uk/dis/people/chrisdillon<http://www.ucl.ac.uk/dis/people/chrisdillon> > > From: ?超 [mailto:qichao@cnnic.cn] > Sent: 09 January 2015 03:21 > To: Dillon, Chris; Sarmad Hussain > Cc: Yoshiro YONEYA; ChineseGP(a)icann.org; hotta(a)jprs.co.jp > Subject: Re: Re: [ChineseGP] proposal to eliminate the divergence between us > > Dear Chris, > > I agree with your understanding: if there is a variant mapping in any language, there will be the mapping in all language. So the mappings are formally unified, but C J and K still could apply different rule for allocated/blocked case. > > Your case is a nice example, but this is a minor error that the situation of > > 'where .XX壱 was allocated, disallowing the separate allocation of . XX一' > > is a rule only for language tag CN, while '.XX壱' and '.XX一 'could be both allocated for language tag JP or KR, and these are in a mapping similar to tag CN but different disposition rule. > > Maybe my understanding is wrong, and I hope IP can give an common example for C, J and K. > > > Best Regards > > ________________________________ > ?超 via foxmail > > ?件人： Dillon, Chris<mailto:c.dillon@ucl.ac.uk> > ?送??： 2015年1月8日(星期四) 下午9:04 > 收件人： Sarmad Hussain<mailto:sarmad.hussain@icann.org> > 抄送： yoshiro.yoneya(a)jprs.co.jp<mailto:yoshiro.yoneya@jprs.co.jp>; ChineseGP(a)icann.org<mailto:ChineseGP@icann.org>; hotta(a)jprs.co.jp<mailto:hotta@jprs.co.jp> > 主?： Re: [ChineseGP] proposal to eliminate the divergence between us > Dear Sarmad, > That is certainly an example of what I mean. The possible issue with CJK is that there will be many such examples. We will only know how many when we have tables for SC, TC, J and K. > The CJK tables with compatible mappings* (i.e. not the tables which describe the situation in SC, TC, J and K) will probably end up with: > “If it’s a variant in any language, it will be a variant in the tables with compatible mappings*.” > *If my understanding is right, there will be no single amalgamated table. > From a Japanese (Traditional Chinese and Korean) perspective, it Is weird to have, for example, 髮 ‘hair’ and 發 ‘send’ as variants (as they are both ? in Simplified Chinese) and on slide 8 of Professor Kim’s presentation, there was a possible situation where .XX壱 was allocated, disallowing the separate allocation of . XX一, although 一 is a much more basic character. However, I am yet to discover cases (and there would need to be quite a few of them) which could be party-stoppers. > The Procedure is very well made and I believe it will be possible to follow it. > Regards, > Chris. > -- > Research Associate in Linguistic Computing, Centre for Digital Humanities, UCL, Gower St, London WC1E 6BT Tel +44 20 7679 1599 (int 31599) www.ucl.ac.uk/dis/people/chrisdillon<http://www.ucl.ac.uk/dis/people/chrisdillon> > > From: Sarmad Hussain [mailto:sarmad.hussain@icann.org] > Sent: 08 January 2015 11:01 > To: Dillon, Chris > Cc: ChineseGP(a)icann.org<mailto:ChineseGP@icann.org>; Wang Wei; yoshiro.yoneya(a)jprs.co.jp<mailto:yoshiro.yoneya@jprs.co.jp>; hotta(a)jprs.co.jp<mailto:hotta@jprs.co.jp> > Subject: RE: [ChineseGP] proposal to eliminate the divergence between us > Dear Chris, > If I understand this correctly, here is an example from Arabic script which could be relevant: > U+06A9 (?) and U+06AA (?) are distinct letters (not variants) in Sindhi language (see http://www.omniglot.com/writing/sindhi.htm) > However, these code points are considered variants of U+0643 (?) by other language communities (e.g. Arabic language). > Therefore, they are being considered as variants by the ArabicGP (see Table 3 in https://community.icann.org/download/attachments/47253587/Arabic%20Variant%…) > Regards, > Sarmad > From: Dillon, Chris [mailto:c.dillon@ucl.ac.uk] > Sent: Monday, January 05, 2015 3:09 PM > To: Wang Wei; yoshiro.yoneya(a)jprs.co.jp<mailto:yoshiro.yoneya@jprs.co.jp>; hotta(a)jprs.co.jp<mailto:hotta@jprs.co.jp> > Cc: ChineseGP(a)icann.org<mailto:ChineseGP@icann.org>; Sarmad Hussain > Subject: RE: [ChineseGP] proposal to eliminate the divergence between us > Dear colleagues, > 新年快樂 > 明けましておめでとうございます > ? ? 福 ?? ???? > Or/. Happy New Year! > I am wondering whether there may be a way of making the proposal below work, without the JGP’s having to define variant sets and mappings (well, only a small number in scenario 2). > Scripts used by many languages, for example Cyrillic and Arabic (I’ll leave out Latin as it is used by so many languages it may cause confusion) may be in a situation where some implementations of the script define variants (cf. SC and TC) and some don’t (cf. Japanese). One possible approach could be that languages which don’t define variants inherit the variant sets and mappings from the languages using the script that do define variants. I’m copying Sarmad in on this email, as this is a phenomenon which may have occurred in the work of one of the other GPs. > I reckon this approach would work for cases 1, 3 and 4 below. (Actually 5 too as long as there are no examples of it…) > That only leaves us with cases in scenario 2 such as 栞 (a variant which only exists in the Japanese table) for which a mapping to 刊 and 刋 would need to be created. For all other cases, the SC/TC mappings would be inherited. > Regards, > Chris. > -- > Research Associate in Linguistic Computing, Centre for Digital Humanities, UCL, Gower St, London WC1E 6BT Tel +44 20 7679 1599 (int 31599) www.ucl.ac.uk/dis/people/chrisdillon<http://www.ucl.ac.uk/dis/people/chrisdillon> > > From: chinesegp-bounces(a)icann.org<mailto:chinesegp-bounces@icann.org> [mailto:chinesegp-bounces@icann.org] On Behalf Of Wang Wei > Sent: 29 December 2014 07:54 > To: yoshiro.yoneya(a)jprs.co.jp<mailto:yoshiro.yoneya@jprs.co.jp>; hotta(a)jprs.co.jp<mailto:hotta@jprs.co.jp> > Cc: ChineseGP(a)icann.org<mailto:ChineseGP@icann.org> > Subject: [ChineseGP] proposal to eliminate the divergence between us > > Dear Yoneya San and Hotta San > > Please kindly accept my belated but best wishes for the Christmas and new year. > Recently, we carried out the following works and I outlined them here for your comments: > > For any Hanzi in CGP repertoire, it belong to a variant mapping set (minimum set size is 1 which means there is no variant for the code point) under the current rules borrowed from CDNC; and for any Kanji code point in JGP repertoire, it may also belong to some variant mapping set (we acknowledge that there is no variant in JPRS practice so far, but we assume that there will be a kind of variant mapping definition in JGP repertoire). > > All the variant mapping sets can be divided into FIVE scenarios: > > > > 1. the variant mapping set in JPRS ∈ variant mapping set in CDNC > [cid:image001.jpg@01D02C04.FD28B860] > In CGP > 愛 611B (0);?(86),愛(886);愛(0),?(0); > ? 7231 (0);?(86),愛(886);愛(0),?(0); > > In JGP > 愛611B(2,3);611B(2,3); > > > > > 2. the variant mapping set in CDNC ∈ the variant mapping set in JPRS > [cid:image002.jpg@01D02C04.FD28B860] > In CGP: > 刊520A (0);刊520A(86),刊520A(886);刊(0),刋(0); > 刋520B (0);刊520A(86),刊520A(886);刊(0),刋(0); > > In JGP: > 刊 520A(2,3);520A(2,3); > 刋 520B(2,3);520B(2,3); > 栞 681E(2,3);681E(2,3); > *: this example is ONLY an assumption > > > > > 3. the variant mapping set in CDNC = the variant mapping set in JPRS > [cid:image003.jpg@01D02C04.FD28B860] > In CGP > 一4E00 (0); 一4E00(86),一4E00(886); 一(0),壱(0),壹(0),弌(0); > 壱58F1 (0); 壹58F9(86),壹58F9(886); 一(0),壱(0),壹(0),弌(0); > 壹58F9 (0); 壹58F9(86),壹58F9(886); 一(0),壱(0),壹(0),弌(0); > 弌5F0C (0); 一4E00(86),一4E00(886); 一(0),壱(0),壹(0),弌(0); > > In JGP: > 一 4E00(2,3);4E00(2,3); > 壱 58F1(2,3);58F1(2,3); > 壹 58F9(2,3);58F9(2,3); > 弌 5F0C(2,3);5F0C(2,3); > *: this example is ONLY an assumption > > > > > 4. the variant mapping set in CDNC ∩ the variant mapping set in JPRS = 0 > [cid:image004.jpg@01D02C04.FD28B860] > The code point UNIQUELY exists in JGP table > 辻8FBB(2,3);8FBB(2,3); > > > > > 5. the variant mapping set in CDNC ∩ the variant mapping set in JPRS ≠ 0 > > and > the variant mapping set in CDNC ≠ the variant mapping set in JPRS > [cid:image005.jpg@01D02C04.FD28B860] > > No specified example so far > > \ > > In the past, we discussed the variants problem for many times, but mainly based on the two types: allocatable and blocked. However, we think another type ("out-of- repertoire") in the XML draft, may help the conflicted issue between JGP and CGP, which was recommended by Asmus' mail. > The basic principle is "any variant label with a code point out-of-repertoire is invalid". We think this “out-of-repertoire” type and consequent “invalid” action will tremendously decrease the complexity of variant mapping coordination between us. > > For scenario 1: > In CGP > 愛 611B (0);?(86),愛(886);愛(0),?(0); > ? 7231 (0);?(86),愛(886);愛(0),?(0); > In JGP > 愛 611B(2,3);611B(2,3); > > JGP take? 7231 into variant mapping set, but mark it as “out-of-repertoire” and take “invalid” action for WLG process, which means, ? 7231 will never be generated into the labels. > > JGP LGR: > <language>und-Jpan</language> > <char cp="611B" tag="sc:Hani"> > <var cp="611B" type="alloc" comment="identity" /> > <var cp="7231" type="out-of-repertoire-var" />  > </char> > WLE rules: > <action disposition="invalid" any-variant="out-of-repertoire-var" > comment="any variant label with a code point out of repertoire is invalid"/> > <action disp="allocatable" all-variant="alloc" /> > > CGP LGR: > <language>und-Hani</language> > <char cp="611B" tag="sc:Hani"> > <var cp="611B" type="trad" comment="identity" />  > <var cp="7231" type="simp" /> > </char> > <char cp="7231" tag="sc:Hani"> > <var cp="611B" type="trad" />  > <var cp="7231" type="simp" comment="identity" /> > </char> > WLE rules: > <action disp="blocked" any-variant="block" /> > <action disp="allocatable" only-variants="simp both" /> > <action disp="allocatable" only-variants="trad both" /> > <action disp="blocked" any-variant="simp trad" /> > <action disp="allocatable" comment="catch-all" /> > > > For scenario 2: > In CGP: > 刊520A (0);刊520A(86),刊520A(886);刊(0),刋(0); > 刋520B (0);刊520A(86),刊520A(886);刊(0),刋(0); > > In JGP: > 刊 520A(2,3);520A(2,3); > 刋 520B(2,3);520B(2,3); > 栞 681E(2,3);681E(2,3); > > Now it is CGP’s turn to take栞 681E into variant mapping set, but mark it as “out-of-repertoire” and take “invalid” action for WLG process, which means, 栞 681E will never be generated into the labels. > > CGP LGR > <language>und-Hani</language> > <char cp="520A" tag="sc:Hani"> > <var cp="520A" type="both" comment="identity" /> > <var cp="520B" type="block" /> > <var cp="681E" type="out-of-repertoire-var" />  > </char> > <char cp="520B" tag="sc:Hani"> > <var cp="520A" type="both" /> > <var cp="520B" type="block" comment="identity" /> > <var cp="681E" type="out-of-repertoire-var" />  > </char> > <char cp="681E" tag="sc:Hani">  > <var cp="520A" type="block" /> > <var cp="520B" type="block" /> > <var cp="681E" type="out-of-repertoire-var" comment="identity"/> > </char> > WLE rules: > <action disp="invalid" any-variant="out-of-repertoire-var" > comment="any variant label with a code point out of repertoire is invalid"/> > <action disp="blocked" any-variant="block" /> > <action disp="allocatable" only-variants="simp both" /> > <action disp="allocatable" only-variants="trad both" /> > <action disp="blocked" any-variant="simp trad" /> > <action disp="allocatable" comment="catch-all" /> > > JGP LGR: > <language>und-Jpan</language> > <char cp="520A" tag="sc:Hani"> > <var cp="520A" type="alloc" comment="identity" /> > <var cp="520B" type="block" /> > <var cp="681E" type="block" /> > </char> > <char cp="520B" tag="sc:Hani"> > <var cp="520A" type="block" /> > <var cp="520B" type="alloc" comment="identity" /> > <var cp="681E" type="block" /> > </char> > <char cp="681E" tag="sc:Hani"> > <var cp="520A" type="block" /> > <var cp="520B" type="block" /> > <var cp="681E" type="alloc" comment="identity"/> > </char> > WLE rules: > <action disp="blocked" any-variant="block" /> > <action disp="allocatable" all-variant="alloc" /> > > > > For Scenario 3: > > In CGP > 一4E00 (0); 一4E00(86),一4E00(886); 一(0),壱(0),壹(0),弌(0); > 壱58F1 (0); 壹58F9(86),壹58F9(886); 一(0),壱(0),壹(0),弌(0); > 壹58F9 (0); 壹58F9(86),壹58F9(886); 一(0),壱(0),壹(0),弌(0); > 弌5F0C (0); 一4E00(86),一4E00(886); 一(0),壱(0),壹(0),弌(0); > > In JGP: > 一 4E00(2,3);4E00(2,3); > 壱 58F1(2,3);58F1(2,3); > 壹 58F9(2,3);58F9(2,3); > 弌 5F0C(2,3);5F0C(2,3); > > JGP needs to create its own mapping set including all above 4 code points and corresponding rules, otherwise, it will fall into scenario 1.. > > > For Scenario 4: > Like UNIQUE code point ONLY exists in JGP table > 辻8FBB(2,3);8FBB(2,3); > > > CGP probably will not include this code point into its repertoire. > No extra work or rule are needed. > > > For Scenario 5: > [cid:image006.jpg@01D02C04.FD28B860] > > Actually, we have not find the code points which fit into this scenario. > But the solution will refer to scenario 1 or 2, like: > > For JGP, “C” will be included but marked as “out-of-repertoire” > For CGP, “A” will be included but marked as “out-of-repertoire” > > > In conclusion, “out-of ?repertoire type” and “invalid action” provide us a conservative and simple way to reach a consensus for the variant mapping and rules. > According to our analysis on CGP table and JPRS table > There are 4983 code points fit for Scenario 1 > There are 840 code points fit for Scenario 3 > There are 170 code points fit for Scenario 4 > > Since JGP has not decided yet if variant relationship exist in JGP repertoire, we don’t have analytical number about scenario 3 and scenario 5. But what we believe is that the above solution can also be applied for scenario 3 and 5 no matter what kind of variant mapping JGP will produce. > > > All above is our proposal for settle the divergence at minimum cost for both of us. > What do you think about it? Looking forward for your reply. > > > Best Regards, > Wei Wang

1 0

Chinese and Korean Generation Panels: Coordination Call
by Sarmad Hussain Jan. 6, 2015

Jan. 6, 2015

Coordination meeting between Chinese and Korean Generation Panels on Thursday 8 January 0700 UTC, 3pm Beijing Time, 4pm Seoul Time (please visit http://www.timeanddate.com/worldclock/converter.html for other time zones). Relevant documents for discussion: Instructions to connect: Link to Adobe Connect: https://icann.adobeconnect.com/r72wznoryti/ *Upon logging into Adobe Connect, a pop up window will provide you the option to Dial Out to your Phone. Enter your Phone Number* (Remember to change the Country Code if needed). After joining the call, as a courtesy to others and the presenters, please MUTE your phone. This can be done by selecting *6 on your keypad. To UNMUTE select *6 again. If you are Unable to log into Adobe Connect and can only join via phone: List of International Dial In Numbers: https://www.myrcplus.com/cnums.asp?bwebid=8369444&ppc=4054049491&num=1-719-… Participant Passcode: 4054049491

1 0