February 2019 - Latingp - lists.icann.org

new character to be included in MSR
by Michael Bauland March 7, 2019

March 7, 2019

Dear Pitinan, as discussed briefly during the face-to-face meeting, the Latin GP is requesting to have the "ela geminada" used by the Catalan language to be made available for TLDs (as it's an integral part of their language). For this, we would need the middle dot (U+00B7) to be included in MSR. Of course, we would only include the character sequence U+006C U+00B7 U+006C l·l in our repertoire. Please take a look at the .cat IDN table, which already allows this character. Catalan has an EGIDS scale of 2. Best regards, Michael -- ____________________________________________________________________ | | | knipp | Knipp Medien und Kommunikation GmbH ------- Technologiepark Martin-Schmeisser-Weg 9 44227 Dortmund Germany Dipl.-Informatiker Fon: +49 231 9703-0 Fax: +49 231 9703-200 Dr. Michael Bauland SIP: Michael.Bauland(a)knipp.de Software Development E-mail: Michael.Bauland(a)knipp.de Register Court: Amtsgericht Dortmund, HRB 13728 Chief Executive Officers: Dietmar Knipp, Elmar Knipp

5 12

Re: [Latingp] Work Product Quality
by Tan Tanaka, Dennis Feb. 26, 2019

Feb. 26, 2019

Sarmad, Thanks and appreciate your suggestion. It’s a good plan forward. If everyone agrees, these are the items to consider: * Latin Script LGR Proposal, version 5: we need to complete the following items: 1. Complete URL Underlining Analysis (Dennis)– Started 2. Review “base character” analysis per assignments (Everyone); finish reviewing previous work – In progress 3. Review input on German Eszett by German Registries (Michael) – Awaiting written report from Michael 4. Write-up proposal to include 00B7 (Middle Dot) to support “l·l” (letter L + Middle Dot + letter L) for Catalan language (Michael) – Complete? Next step: document interaction with IP 5. Develop test label strategy (Mats) 6. Create test cases for dotless I vis-a-vis IDNA 2003 Compatibility issues (Mats) 7. Complete section for IDNA2003 compatibility issues (Dennis) * As far as maintaining a list of deferred cases, who volunteers to do this? Dennis From: Latingp <latingp-bounces(a)icann.org> on behalf of Sarmad Hussain <sarmad.hussain(a)icann.org> Date: Tuesday, February 26, 2019 at 5:54 AM To: Latin GP <latingp(a)icann.org> Subject: [EXTERNAL] Re: [Latingp] Work Product Quality Dear Latin GP members, May I suggest an option for the GP members to consider to keep moving forward – is it possible to split this discussion into two parts: 1. The first would be to focus on the agreed upon methods, complete the remaining analysis and share the version of Latin LGR proposal for review by IP. 2. In parallel, include any items which are not agreed by members in a separately maintained list, to be revisited for further discussion after completing step 1. This may actually be a very small list. This can help make progress while allowing to address any items the members consider may require more discussion. IP may also be consulted for such cases. Regards, Sarmad From: Latingp <latingp-bounces(a)icann.org> On Behalf Of Tan Tanaka, Dennis via Latingp Sent: Tuesday, February 26, 2019 4:38 AM To: meikal(a)mumin.de; latingp(a)icann.org; bill.jouris(a)insidethestack.com Subject: Re: [Latingp] Work Product Quality The data was that we had votes from two users of languages, which make use of diaresis, both of which judged them confusable, namely me and Michael Bauland Thus far, it is only your opinion of such confusability. We have not seen evidence that support your claims (again, other than your verbal statements). At the outset, this is fine to start looking at this case closer (which we have), but if we want to make a case for variant relationship on non-visual grounds, then let’s back it up with such evidence. All we heard on our last call was about comparing two characters on visual grounds using rare fonts. So, if we are making a visual argument, let’s use our visual methodology. If we want to support a variant relationship on semantic, interchangeability or other grounds we are going to be asked for this hard evidence. We haven’t seen it yet. When it was suggested we do the analysis using wordmark it, the thesis was to find out -among several font types- whether hand-writing conventions were transferred to font design. In the case of “a” with diaresis and double acute, we saw there is no confusion; a diaresis is always a diaresis and a double acute is a double acute. What I suggest the panel do is remain open to the possibility (I would say the certainty) that we have not yet created methodologies which will identify all variants. But we define what variants are, not the other way around. We designed a method for visual analysis. Is it limited? Yes. But we chose widely-used, stable font types reflecting different styles to capture alternative renderings. We accepted this design knowing its shortcomings. I don’t think it is productive to challenge this decision at this point in time. Let us remember that we need to focus on clear-cut cases and leave subjectivity to the visual similarity process. -Dennis From: Latingp <latingp-bounces(a)icann.org<mailto:latingp-bounces@icann.org>> on behalf of Meikal Mumin <meikal(a)mumin.de<mailto:meikal@mumin.de>> Date: Monday, February 25, 2019 at 1:57 PM To: Latin GP <latingp(a)icann.org<mailto:latingp@icann.org>>, Bill Jouris <bill.jouris(a)insidethestack.com<mailto:bill.jouris@insidethestack.com>> Subject: [EXTERNAL] Re: [Latingp] Work Product Quality Dear colleagues, To chime into this discussion - I tend to agree with Bill in that the data is always more important the theory. Our methodologies are based on certain hypotheses. If these turn out to be insufficient, the solution is not to ignore the data but to amend the methodology and change the hypothesis and those are very basic principles of scientific analysis and methods. Nonetheless I find this last exchange of emails a bit unspecific and would suggest focusing on the actual data, rather than having abstract methodological debates: I assume that Bill’s email makes reference to the discussions we had regarding the cases of double diaresis vs. double acute during our last teleconference. If I remember correctly the gist of the line of argumentation by Dennis was that us considering them variants was not possible, because our reasons were based on visual similarity, while we were discussing non-visual similarity at this time. The data was that we had votes from two users of languages, which make use of diaresis, both of which judged them confusable, namely me and Michael Bauland. We had several examples from fonts where they were near-homoglyphs if not homoglyphs to use established terminology (without implying a categrorial notion of visual vs. non-visual similarity). Now Dennis argued that if we would make them variants because they were near-homoglyphs or homoglyphs, we would have to restrain ourselves to the rendering in the same three fonts we had opted for earlier in our analysis of cross-script visual variants. In this context, I would like to remind the group of two facts: 1) We have not yet conducted an analysis of in-script variants on strictly visual grounds. With cross-script variants we started with a visual analysis, and then during that work discovered that we had to consider further non-visual criteria. This led us to developing the current theories and framework of how to identify non-visual criteria. We went on to amend our visual analysis in the case of cross-script variants and then proceed with an analysis of in-script variants. Accordingly, we haven’t had an analysis of in-script variants on strictly visual grounds as of yet. So, either that task remains, or we do a combined pass analyzing both aspects together, and the latter seems the obvious choice to me. 2) As I tried to explain in the proposal itself, there is no systematic, non-arbitrary boundary between visual and non-visual similarity - One conditions the other and vice versa. Therefore, in my opinion we should not try to enforce such a boundary, neither from the point of analysis nor from the point of methodology. We started with a visual analysis of cross-script variant candidates because that is what was expected from us, as clarified by the Integration Panel on various occasions. However, we cannot abuse these statements to deduct that - by consequence - other things are out of scope and I’m confident that an incomplete analysis will not be accepted by the Integration Panel. Therefore, the relevant question in our discussion will be if there is a succinct risk for stability, rather that which type of variant relationship a particular case falls into and whether we applied the correct methodology. In the case under discussion I interpret the data to substantiate such a risk for stability simply because users would confuse them for whatever reasons. We should however stick to discussing the data rather than arguing over methodology, because it is such arguments which keep us from making progress, not the quality or quantity of the data. I hope this summary will speed up our discussion during our next tele-conference, but even if it does not settle the discussion it is important that we *cannot* rule out any analysis because of any methodology developed before analyzing the data. Best, Meikal Am 23. Feb. 2019, 18:44 +0100 schrieb Bill Jouris <bill.jouris(a)insidethestack.com<mailto:bill.jouris@insidethestack.com>>: Dennis, I'm not saying that the methodologies we have developed are flawed. I am saying that they are limited. There is some set of code points which are variants. Each methodology we have can identify some subset of those variants -- but not all of them. That is, after all, why we have developed multiple methodologies. Our task, I submit, is not to process our methodologies; our task is to identify variants. The methodologies are a means to that end; they are not the end itself. I believe we need to bear in mind that the methodologies which we have at this point may still not be sufficient to identify all of the variants which exist. We need to accept that, if we find code points which we generally agree are variants, but which are not identified by our existing methodologies, that is not a bad thing. It would be good to then identify why they are variants, in the interests of then finding others of the same type; to develop an additional methodology. Good, but not critical. The quality of our work product is determined by how successfully we identify the variants which exist. If we find variants which are not generated by our methodologies, that improves the quality of our work. It does not, as you appeared to suggest, diminish it. What I suggest the panel do is remain open to the possibility (I would say the certainty) that we have not yet created methodologies which will identify all variants. At some point, of course, we do have to stop. But that doesn't justify just saying "These code points do not fit the existing methodologies, so we cannot even consider them." Again, the methodologies are a tool, not an end. Bill Jouris Inside Products bill.jouris(a)insidethestack.com<mailto:bill.jouris@insidethestack.com> 831-659-8360 925-855-9512 (direct) On Friday, February 22, 2019, 10:23:19 AM PST, Tan Tanaka, Dennis <dtantanaka(a)verisign.com<mailto:dtantanaka@verisign.com>> wrote: Bill, I don’t see how the methods this panel have developed and signed-off on (some of them over a year ago) misalign with our goal. What exactly are you suggesting this panel to do? -Dennis From: Latingp <latingp-bounces(a)icann.org<mailto:latingp-bounces@icann.org>> on behalf of Bill Jouris <bill.jouris(a)insidethestack.com<mailto:bill.jouris@insidethestack.com>> Reply-To: Bill Jouris <bill.jouris(a)insidethestack.com<mailto:bill.jouris@insidethestack.com>> Date: Thursday, February 21, 2019 at 5:36 PM To: Latin GP <latingp(a)icann.org<mailto:latingp@icann.org>> Subject: [EXTERNAL] [Latingp] Work Product Quality Dear colleagues, I want to strongly disagree with the thesis put forward at this morning's meeting that the quality of our work product depends on our following some very small number of discrete methodologies for identifying variants. It does not. A methodology, any methodology, is merely a tool. Its purpose is to help us get to our goal -- identifying variants. If we use multiple methodologies, each of which allows us to identify some (quite possibly overlapping) subset of the universe of variants, that's OK. If we identify a few additional cases that we believe to be variants, while going outside those methodologies, that's OK too. It is desirable to have methodologies which identify large subsets, but only because that expedites our work. The methodologies are a means to an end, not the end in themselves. The quality of our work product is based on how successfully we identify the members of the underlying universe of variants. How we get there is really irrelevant to the quality of what we produce. Bill Jouris Sent from Yahoo Mail on Android [go.onelink.me]<https://urldefense.proofpoint.com/v2/url?u=https-3A__go.onelink.me_10787296…> _______________________________________________ Latingp mailing list Latingp(a)icann.org<mailto:Latingp@icann.org> https://mm.icann.org/mailman/listinfo/latingp

3 4

Work Product Quality
by Bill Jouris Feb. 26, 2019

Feb. 26, 2019

Dear colleagues, I want to strongly disagree with the thesis put forward at this morning's meeting that the quality of our work product depends on our following some very small number of discrete methodologies for identifying variants. It does not. A methodology, any methodology, is merely a tool. Its purpose is to help us get to our goal -- identifying variants. If we use multiple methodologies, each of which allows us to identify some (quite possibly overlapping) subset of the universe of variants, that's OK. If we identify a few additional cases that we believe to be variants, while going outside those methodologies, that's OK too. It is desirable to have methodologies which identify large subsets, but only because that expedites our work. The methodologies are a means to an end, not the end in themselves. The quality of our work product is based on how successfully we identify the members of the underlying universe of variants. How we get there is really irrelevant to the quality of what we produce. Bill Jouris Sent from Yahoo Mail on Android

4 5

Meeting yesterday 2019-02-21
by Mats Dufberg Feb. 22, 2019

Feb. 22, 2019

I'm sorry I missed the meeting yesterday. I am teaching a DNS class for a couple of months, and yesterday we had a lab session that ran over the schedule. Some students needed more help than expected. Mats --- Mats Dufberg DNS Specialist, IIS Mobile: +46 73 065 3899 https://www.iis.se/en/

1 0

[lgr] Public comment for Proposal for Hebrew Script Root Zone Label Generation Rules
by Pitinan Kooarmornpatana Feb. 22, 2019

Feb. 22, 2019

Dear all, The Hebrew scrip LGR is published for public comment at https://www.icann.org/public-comments/hebrew-lgr-2019-02-20-en Please see the announcement at https://www.icann.org/news/announcement-2019-02-20-en Proposal for Hebrew Script Root Zone Label Generation Rules Open Date: 20 February 2019 Close Date: 18 April 2019 Originating Organization: Global Domains Division Categories/Tags: Top-Level Domains Brief Overview: The Hebrew community has formed the Hebrew Script Generation Panel (GP), which in turn has developed a Proposal for Hebrew Script Root Zone Label Generation Rules (Proposal<https://www.icann.org/en/system/files/files/proposal-hebrew-lgr-20feb19-en.…> and Supporting Document<https://www.icann.org/en/system/files/files/proposal-hebrew-lgr-20feb19-en.…>). As per the LGRprocedure<https://www.icann.org/en/system/files/files/lgr-procedure-20mar13-en.pdf>, this proposal is being posted for public comment to allow those who have not participated in the Hebrew Script GP to make their views known to the GP. Based on the feedback, the Hebrew Script GP will finalize the proposal for submission for integration into the Label Generation Rules for the Root Zone(RZ-LGR) Link: https://www.icann.org/public-comments/hebrew-lgr-2019-02-20-en Best Regards, Pitinan _______________________________________________ lgr mailing list lgr(a)icann.org https://mm.icann.org/mailman/listinfo/lgr

1 0

Latin GP Conference Call
by Pitinan Kooarmornpatana Feb. 21, 2019

Feb. 21, 2019

Dear Latin GP member, This is a gentle reminder for the Lain GP call in the next hour Agenda for the Latin GP call on 21 February 2019 at 16:00 UTC. 1. Roll call 2. Action items from previous calls Item no 1. Complete URL Underlining Analysis * Send spreadsheet with analysis for review by IP * Focus on clear-cut cases, but make a call for other cases as well * Consider incorporating "q" vs "g" in similarity section; mention URL underlining case * Bare in mind effect of transitivity when defining variants * Cedilla and Comma Below have historic relationship; good candidate for variants (even without URL underlining) Dennis 2. Create clear guidelines for variant definition that can be used as references in the proposal Dennis, Meikal, Bill 3. Review "base character" analysis per assignments finish reviewing previous work Everyone 4. Further input on German Eszett by German Registries Michael 5. Write-up proposal to include 00B7 (Middle Dot) to support "l*l" (letter L + Middle Dot + letter L) for Catalan language -- Complete; awaiting feedback from IP Michael 6. Develop test label strategy Mats 7. Create test cases for dotless I vis-a-vis IDNA 2003 Compatibility issues Mats 8. Complete section for IDNA2003 compatibility issues in next version Dennis 3. Report from Michael re Action Item 4 (10 min) 4. Report on base character homework (Item Action 3) (50 min) 5. Next meeting proposal March the 7th, 2019, 16:00 6. AOB Regards, Pitinan .......................... Link to Adobe Connect: https://participate.icann.org/idn/ *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: https://www.myrcplus.com/cnums.asp?bwebid=8369444&ppc=1064158692&num=1-719-… [myrcplus.com]<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.myrcplus.com_cnums…> Participant Passcode: 1064158692

1 0

AGENDA for the GP call on February the 21st, 2019, 16:00UTC
by Mirjana Tasić Feb. 20, 2019

Feb. 20, 2019

Dear GP members. Please find enclosed the Agenda proposal for our next telephone conference. Any comments are welcome. Pitinan will send the remainder on time. Regards Mirjana ___________________________________________ AGENDA for the GP call on February the 21st, 2019, 16:00UTC 1. Roll call 2. Action items from previous calls Item no 1. Complete URL Underlining Analysis * Send spreadsheet with analysis for review by IP * Focus on clear-cut cases, but make a call for other cases as well * Consider incorporating “q” vs “g” in similarity section; mention URL underlining case * Bare in mind effect of transitivity when defining variants * Cedilla and Comma Below have historic relationship; good candidate for variants (even without URL underlining) Dennis 2. Create clear guidelines for variant definition that can be used as references in the proposal Dennis, Meikal, Bill 3. Review “base character” analysis per assignments finish reviewing previous work Everyone 4. Further input on German Eszett by German Registries Michael 5. Write-up proposal to include 00B7 (Middle Dot) to support “l·l” (letter L + Middle Dot + letter L) for Catalan language -- Complete; awaiting feedback from IP Michael 6. Develop test label strategy Mats 7. Create test cases for dotless I vis-a-vis IDNA 2003 Compatibility issues Mats 8. Complete section for IDNA2003 compatibility issues in next version Dennis 1. Report from Michael re Action Item 4 (10 min) 2. Report on base character homework (Item Action 3) (50 min) 3. Next meeting proposal March the 7th, 2019, 16:00 4. AOB

2 1

Latin GP Conference Call
by Pitinan Kooarmornpatana Feb. 20, 2019

Feb. 20, 2019

Dear Latin GP member, This is the agenda for the Latin GP call on 21 February 2019 at 16:00 UTC. 1. Roll call 2. Action items from previous calls Item no 1. Complete URL Underlining Analysis * Send spreadsheet with analysis for review by IP * Focus on clear-cut cases, but make a call for other cases as well * Consider incorporating "q" vs "g" in similarity section; mention URL underlining case * Bare in mind effect of transitivity when defining variants * Cedilla and Comma Below have historic relationship; good candidate for variants (even without URL underlining) Dennis 2. Create clear guidelines for variant definition that can be used as references in the proposal Dennis, Meikal, Bill 3. Review "base character" analysis per assignments finish reviewing previous work Everyone 4. Further input on German Eszett by German Registries Michael 5. Write-up proposal to include 00B7 (Middle Dot) to support "l*l" (letter L + Middle Dot + letter L) for Catalan language -- Complete; awaiting feedback from IP Michael 6. Develop test label strategy Mats 7. Create test cases for dotless I vis-a-vis IDNA 2003 Compatibility issues Mats 8. Complete section for IDNA2003 compatibility issues in next version Dennis 3. Report from Michael re Action Item 4 (10 min) 4. Report on base character homework (Item Action 3) (50 min) 5. Next meeting proposal March the 7th, 2019, 16:00 6. AOB Regards, Pitinan .......................... Link to Adobe Connect: https://participate.icann.org/idn/ *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: https://www.myrcplus.com/cnums.asp?bwebid=8369444&ppc=1064158692&num=1-719-… [myrcplus.com]<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.myrcplus.com_cnums…> Participant Passcode: 1064158692

1 0

Letter Shape Homework
by Bill Jouris Feb. 18, 2019

Feb. 18, 2019

Analysis of my assigned letter shape homework is attached. Bill Jouris Inside Products bill.jouris(a)insidethestack.com 831-659-8360 925-855-9512 (direct)

2 1

Letter Shape Homework- Open E vs E
by Mirjana Tasić Feb. 17, 2019

Feb. 17, 2019

Dear Latin GP Analysis of my assigned letter shape homework is attached. Regards Mirjana

1 0

AE, OE, and Ligatures
by Bill Jouris Feb. 12, 2019

Feb. 12, 2019

Hi All, I have, thanks to a long plane ride, come up with what I hope is a clear exposition of the point that I was trying to make earlier this week. We have three relationships among 4 sets of code points. The code points are: - Latin Small Letters A and E - Latin Small Ligature Æ - Latin Small Ligature Œ - Latin Small Letters O and E There are potential variant relationships between each adjacent pair. Clearly these cannot all be made variant pairs, as transitivity would then require two ASCII letters (A and E) to be variants, which is not allowed. So the question becomes, when we look at the various pairs, which is the strongest case for variant and which is the weakest? If we look at the ligature Æ and the ligature Œ in one of the fonts where A is rendered as a we see æ. Comparing this to œ we see that visually they are at least a 2, and quite possible a 1. Which means this pair does need to be included as an in-script variant. In contrast, a comparison between AE and Æ (ae vs æ) is at best a 3 and perhaps even a 4. Likewise with OE and Œ (oe vs œ). But the resemblance is not, in my opinion, equal. Because of the vertical line on the right-hand side of the small letter A, there is about half as much white space at the top and bottom of the non-ligature A and E as in the case of O and E. Which to me says that, since we must drop one of these from consideration as a variant, OE and ligature Œ is the relationship which gets downgraded to Confusable. I hope that clarifies where I was coming from. (Certainly it is clearer than just saying "gut feel". Which, alas, was all I could come up with on the fly for an explanation.) Bill Jouris Inside Products bill.jouris(a)insidethestack.com 831-659-8360 925-855-9512 (direct)

4 7

Action Items, Brussels Workshop
by Tan Tanaka, Dennis Feb. 6, 2019

Feb. 6, 2019

Action items enclosed … https://docs.google.com/document/d/1dpJBiq2K5KBJ0sxrpxLxF06WMQaOBY0bhvTU7Za… Next conference call : Thursday, 21 Feb 2019 D

1 0

Hebrew Cursive
by Meikal Mumin Feb. 6, 2019

Feb. 6, 2019

Hebrew cursive is used by Hebrew, Ladino, and Yiddish It is the standard everyday handwriting today across the three languages. It is also encoded in several fonts unicode fonts. I would suggest to reach out to Hebrew GP and ask for their view. https://www.quora.com/Should-I-learn-the-Hebrew-cursive-or-printed-alphabet… http://www.hebrewtoday.com/content/hebrew-writing http://www.oketz.com/fonts/script.html http://www.ulpan.net/hebrew-handwriting-and-rashi-script http://www.oketz.com/cursive/ https://omniglot.com/writing/hebrew.htm I highlighted the stronger candidates towards Latin. Not saying the need to be variants Below are some samples from cursive fonts: Cursive script Another version of the cursive script Cursive script with ligatures (informal) Website to convert between the two styles of the script: https://stevemorse.org/hebrew/printcurs.html?style=rtl&font=ashkenazi&leftp… Best, Meikal

1 0

Notes from meeting with IP - 5 Feb 2019
by Tan Tanaka, Dennis Feb. 6, 2019

Feb. 6, 2019

Link to notes: https://docs.google.com/document/d/1o6fV3pBjsz4j_hkPojA2qS92HN4t0enW3tMpI7C… Please review and provide input if I missed anything. D

1 0

Lain-Greek variant discussion
by Pitinan Kooarmornpatana Feb. 6, 2019

Feb. 6, 2019

Hi All, This is the list of Latin-Greek Variants for our discussion. https://docs.google.com/spreadsheets/d/17Wo4yTSb0mEotj4r4LXR6AlUETrRflZre4r… Regards, Pitinan

1 0

Note from discussion on IP feedback on proposal version4.
by Pitinan Kooarmornpatana Feb. 4, 2019

Feb. 4, 2019

Dear All, Please find attached the note of from the discussion on IP feedback document this morning. Hi Sarmad, Could you please share with the IP so they have input before the call tomorrow. Regards, Pitinan

2 1

underlining
by Tan Tanaka, Dennis Feb. 4, 2019

Feb. 4, 2019

https://docs.google.com/spreadsheets/d/1dmx0HaO_6Iu64AXsIDjbOWM1-B9uf9rfvRR…

1 0

IP feedback on the Proposal for Latin script LGR dated 20190119
by Sarmad Hussain Feb. 2, 2019

Feb. 2, 2019

Dear All, Please find attached feedback from the IP members on the Latin LGR proposal. Regards, Sarmad From: Latingp <latingp-bounces(a)icann.org> On Behalf Of Pitinan Kooarmornpatana Sent: Saturday, January 19, 2019 10:35 PM To: Latin GP <latingp(a)icann.org> Subject: Re: [Latingp] [Ext] For IP: 2019-01-17 version of the Proposal for Latin script LGR-V4 Dear Latin GP members, Please find attached the package of Latin Script LGR version 4.0. The XML is updated according to the latest fie from Mirjana, and the XML file name is included in the proposal. List of attachments: 1. LGR proposal version 4.0 date 2019-01-19 (Proposal-for-LatinScriptRootZone-LGR-V4-submitted-2019-01-19.docx) 2. LGR in XML(proposal-lgr-latin-20190119.xml) 3. LGR in HTML (proposal-lgr-latin-20190119.html) We will share this package to the IP, as instructed. Kindly review and let us know any feedback. Regards, Pitinan From: Mirjana Tasić <Mirjana.Tasic(a)rnids.rs <mailto:Mirjana.Tasic@rnids.rs> > Date: Sunday, January 20, 2019 at 00:05 To: Pitinan Kooarmornpatana <pitinan.koo(a)icann.org <mailto:pitinan.koo@icann.org> >, Sarmad Hussain <sarmad.hussain(a)icann.org <mailto:sarmad.hussain@icann.org> > Cc: Latin GP <latingp(a)icann.org <mailto:latingp@icann.org> > Subject: [Ext] For IP: 2019-01-17 version of the Proposal for Latin script LGR-V4 Dear Pitinan, Dear Sarmad, Please find enclosed new version of the Proposal for Latin script LGR. Please be so kind to produce new version of XML file using Repertoire and Variants table submitted in the document. Also I would ask you to put the name of the XML file at the beginning of our Report. The placeholder for the name is commented by me for Pitinan. Then our report should be ready for new inspection by IP. Latin GP is submitting this Report to IP for new comments and suggestions. Best regards Mirjana Tasic

2 1

Latin GP call with Integration Panel - 15:00 - 16:00 UTC on Feb 5.
by Sarmad Hussain Feb. 2, 2019

Feb. 2, 2019

Dear Latin GP members, Please find below the details of the online meeting between Latin GP and Integration Panel members at 15:00 - 16:00 UTC (4-5pm Brussels time) on Feb 5. Regards, Sarmad Link to Adobe Connect: https://participate.icann.org/idn/ If you are Unable to log into Adobe Connect and can only join via phone: Dial In Phone Numbers: Participant Passcode: 1064158692 USA: 1-719-457-1414 Canada, Calgary: +1 403 407 5792 Canada, Montreal: +1 514 669 5944 Canada, Toronto: +1 647 426 9168 Canada, Vancouver: +1 604 224 1367 Argentina (toll free): 0800 800 1222 Argentina, Buenos Aires: +54 (0) 11 5172 6012 Australia (toll free): 1 800 804 723 Australia, Brisbane: +61 (0) 7 3015 0541 Australia, Melbourne: +61 (0) 3 8687 0557 Australia, Sydney: +61 (0) 2 8017 6141 Bahrain (toll free): 800 04075 Bahrain, Manama: +973 1619 8740 Belarus (toll free): 8 820 0011 0349 Belgium (toll free): 0800 39270 Belgium, Brussels: +32 (0) 2 400 6949 Brazil (toll free): 0800 887 0276 Brazil, Rio de Janeiro: +55 21 4560 0000 Brazil, Sao Paulo: +55 11 4935 7173 Bulgaria (toll free): 00800 111 4994 Bulgaria, Sofia: +359 (0) 2 491 6046 Canada (toll free): 1 855 950 3716 Chile, Santiago: +56 (0) 2 2666 0695 China (national): +400 613 8102 China, Beijing: +86 10 5667 0002 China, Shanghai: +86 21 2039 7080 Colombia, Bogota: +57 1 508 8134 Costa Rica (toll free): 800 542 5354 Croatia (toll free): 0800 7744 Cyprus (toll free): 800 97414 Czech Republic (toll free): 800 142 926 Czech Republic, Prague: +420 225 986 562 Denmark (toll free): 80 25 00 00 Denmark, Copenhagen: +45 32 72 78 89 Egypt (toll free): 0800 000 0540 Estonia (toll free): 800 011 1585 Estonia, Tallinn: +372 622 6557 Fiji (toll free): 00800 3321 Finland (toll free): 0800 770 321 Finland, Helsinki: +358 (0) 9 2310 1662 France (national): 0811 655 104 France (toll free): 0805 101 205 France, Paris: +33 (0) 1 76 77 22 58 Germany (national): 01801 001 073 Germany (toll free): 0800 588 9227 Germany, Frankfurt: +49 (0) 69 5060 9538 Germany, Munich: +49 (0) 89 7104 3510 Greece (toll free): 00800 128 827 Greece, Athens: +30 211 181 3858 Hong Kong: +852 3018 9110 Hong Kong (toll free): 800 930 242 Hungary (toll free): 068 002 0141 Hungary, Budapest: +36 1408 8955 Iceland (toll free): 800 8378 Indonesia (toll free): 007 803 321 8932 Ireland (national): 1890 907 633 Ireland (toll free): 1800 936 896 Ireland, Dublin: +353 (0) 1 246 5616 Israel (toll free): 1809 246 054 Israel, Tel Aviv: +972 (0)3 721 7933 Italy (toll free): 800 148 223 Italy, Milan: +39 02 3600 8021 Italy, Rome: +39 06 8750 0695 Japan (mobile): 0120 526 211 Japan (toll free): 0120 625 211 Japan, Osaka: +81 6 4560 2415 Japan, Tokyo: +81 3 4560 1269 Kazakhstan (toll free): 8800 333 7569 Latvia (toll free): 8000 3408 Latvia, Riga: +371 6601 3632 Lithuania (toll free): 8800 31460 Lithuania, Vilnius: +370 5205 5473 Luxembourg: +352 2088 1756 Luxembourg (toll free): 800 24393 Malaysia (toll free): 1 800 816 163 Malaysia, Kuala Lumpur: +60 (0) 3 7724 8015 Morocco (toll free): 0800 091 309 Morocco, Casablanca: +212 (0) 525 06 0228 Netherlands (toll free): 0800 023 0691 Netherlands, Amsterdam: +31 (0) 20 715 3980 New Zealand (toll free): 0800 452 941 New Zealand, Auckland: +64 (0) 9 929 1833 New Zealand, Christchurch: +64 (0) 3 974 2594 New Zealand, Wellington: +64 (0) 4 909 4677 Nigeria, Lagos: +234 1 277 3943 Norway (toll free): 800 51061 Norway, Oslo: +47 21 00 26 03 Panama (toll free): 00800 223 1389 Panama, Panama City: +507 8 335 912 Peru (toll free): 0800 78101 Peru, Lima: +51 (0) 1 700 9570 Philippines (toll free): 1 800 111 014 10 Philippines, Manila: +63 (0)2 395 3425 Poland (toll free): 00 800 121 4362 Poland, Warsaw: +48 22 295 3578 Portugal (toll free): 800 784 436 Portugal, Lisbon: +351 21 318 0031 Qatar (freephone): 00 800 100 490 Romania (toll free): 0800 885 830 Romania, Bucharest: +40 (0) 31 810 7132 Russia (toll free): 810 800 2504 1012 Russia, Moscow: +7 495 646 1861 Saudi Arabia (toll free): 800 844 8424 Saudi Arabia (toll free): 800 850 0218 Serbia (toll free): 0800 190 709 Singapore (toll free): 800 616 3196 Slovakia (toll free): 0800 002 007 Slovakia, Bratislava: +421 (0)2 3321 5499 Slovenia (toll free): 0800 81127 Slovenia, Ljubljana: +386 1888 8188 South Africa (toll free): 0800 999 287 South Africa, Johannesburg: +27 (0)11 589 8329 South Korea (toll free): 00798 6136 1459 South Korea, Seoul: +82 (0) 2 6007 0078 Spain (toll free): 900 803 691 Spain, Barcelona: +34 93 800 1968 Spain, Madrid: +34 91 114 7290 Sweden (toll free): 0200 883 444 Sweden, Stockholm: +46 (0) 8 5066 2770 Switzerland (toll free): 0800 841 704 Switzerland, Geneva: +41 (0) 22 595 4798 Switzerland, Zurich: +41 (0) 44 580 7251 Taiwan (toll free): 0800 666 672 Taiwan, Taipei: +886 (0) 2 2650 7334 Thailand (toll free): 001 800 6136 1477 Turkey (toll free): 00 800 4488 28190 Turkey, Istanbul: +90 212 375 5021 UAE (toll free): 8000 3570 2669 UK (03): +44 (0)330 336 6001 UK (toll free): 0800 368 0952 Ukraine (toll free): 0800 500 689 Uruguay (toll free): 0004 019 0188 USA /Canada (toll free): 1-888-619-1583 Venezuela (toll free): 0 800 100 8300 Venezuela, Caracas: +58 212 720 2159 USA: 1-605-475-5603 USA: 1-712-770-4202 Austria, Vienna: +43 (0)1 928 2757 Austria (toll free): 0800 070 883 Bosnia and Herzegovina: +387 7031 1441 Cambodia, Phnom Penh: +855 23 965 722 Chile (toll free): 800 914 862 Colombia (toll free): 1 800 518 9119 France (national): 0821 231 670 Georgia, Tbilisi: +995 32 2 050 690 India, Delhi: +91 11 6310 0247 India, Mumbai: +91 22 6310 0289 India, Chennai: +91 44 6310 0219 India, Bangalore: +91 80 6760 8742 India (toll free): 1800 3002 1163 Indonesia, Jakarta: +62 21 2188 9083 Ireland (national): 0818 270 270 Japan (national): 0570 039 744 Jordan (toll free): 0800 22171 Kenya, Nairobi: +254 (0)207 643 580 Macau (national): +853 6262 1675 Mexico, Guadalajara: +52 33 2101 0294 Mexico, Mexico City: +52 55 7100 0100 Mexico, Monterrey: +52 81 2188 0001 Mexico (toll free): 1 800 099 1124 Oman (toll free): 800 77254 Pakistan, Islamabad: +92 5181 08862 Singapore: +65 6654 9118 Sri Lanka, Sri Lanka: +94 720 910 332 Thailand, Bangkok: +66 (0) 2104 0762 UK (national): 0844 473 5009 UK (national): 0845 545 0018 Vietnam, Hanoi: +84 24 4458 3311 Vietnam (toll free): 1800 400 370

1 0