February 2020 - Latingp - lists.icann.org

Re: [Latingp] ACTION NEEDED: New underlining test cases
by Tan Tanaka, Dennis Feb. 24, 2020

Feb. 24, 2020

I added my initials to the test cases I have access to. From: Latingp <latingp-bounces(a)icann.org> on behalf of Mirjana Tasić <Mirjana.Tasic(a)rnids.rs> Date: Sunday, February 23, 2020 at 3:46 PM To: Latin GP <latingp(a)icann.org> Subject: [EXTERNAL] [Latingp] ACTION NEEDED: New underlining test cases Dear GP members, Here is the link to Google drive with proposed platforms for new underlining test cases. https://docs.google.com/spreadsheets/d/17gw-hvYN7SEJ9ronBlMws5kkP7umptmt/ed… Please send the information to this list what cases you could test on your platforms. WE NEED THESE INFORMATIONA ASAP. Here are the test cases which I can test. We have to share the workload with all members willing to help finishing the analysis. Regards Mirjana Browser Win10 MAC OS Android Chrome MT MT MT Safari MT Firefox MT MT MT Mail Client Apple Mail MT MS Outlook MT Gmail mail App on Mobile MT Webmail Gmail on Chrome MT MT Gmail on Safari MT Gmail on Firefox MT MT Outlook owa on Chrome MT MT Outlook owa on Safari MT Outlook owa on Firefox MT MT

1 0

Excel file for underlining analysis task distribution
by Pitinan Kooarmornpatana Feb. 21, 2020

Feb. 21, 2020

Dear Latin GP members, Please find attached the updated excel file from the meeting today. At the tab ‘test case’ the combination of possible test case were listed out. Kindly review and let Mirjana and me know which of the test cases you would be able to conduct, based on your existing tool/system. The recording of the meeting is posted on the Latin GP Wiki. The note will be shared soon. Regards, Pitinan

2 1

Summary of Latin GP Meeting on 20 February 2020
by Pitinan Kooarmornpatana Feb. 21, 2020

Feb. 21, 2020

Dear Latin GP members, Please find attached the summary of the Latin GP meeting on 20 February 2020. Please let us know if you would like to suggest any edits or additions Action Item: S. No.Action ItemsOwner 1Review the test case table and inform Mirjana which cases member could volunteer to testALL I also attached the table here for your convenience. The recording for this meeting and the note are posted at Latin GP wiki page at https://community.icann.org/display/croscomlgrprocedure/Latin+GP. Regards, Pitinan

1 0

Summary of Latin GP Meeting on 13 February 2020
by Pitinan Kooarmornpatana Feb. 20, 2020

Feb. 20, 2020

Dear Latin GP members, Please find attached the summary of the Latin GP meeting on 13 February 2020. Please let us know if you would like to suggest any edits or additions Action Items S. No.Action ItemsOwner 1Reach out to Pitinan for ICANN67 presentation preparation. BJ 2Prepare the list of browsers and email clients for the task distribution in the next meeting.MT 3Review the HTML for any human errors as discussed. BJ, ALL The recording for this meeting and the note are posted at Latin GP wiki page at https://community.icann.org/display/croscomlgrprocedure/Latin+GP. Regards, Pitinan

1 0

FW: Consolidated Underlining
by Tan Tanaka, Dennis Feb. 18, 2020

Feb. 18, 2020

This is the table I used to build the HTML From: Bill Jouris <bill.jouris(a)insidethestack.com> Reply-To: Bill Jouris <bill.jouris(a)insidethestack.com> Date: Tuesday, January 28, 2020 at 11:37 AM To: Dennis Tan Tanaka <dtantanaka(a)verisign.com> Subject: [EXTERNAL] Re: Consolidated Underlining With requested updates Bill Jouris Inside Products bill.jouris(a)insidethestack.com 831-659-8360 925-855-9512 (direct) On Tuesday, January 28, 2020, 11:53:05 AM GMT+1, Bill Jouris <bill.jouris(a)insidethestack.com> wrote: Here are the underlining cases. I included the cases from both tabs. The cases where we did a full vote are after then ones from the first tab. Bill Jouris Inside Products bill.jouris(a)insidethestack.com 831-659-8360 925-855-9512 (direct)

2 2

AGENDA for the GP call on February the 20th 2020, 16:00UTC
by Mirjana Tasić Feb. 18, 2020

Feb. 18, 2020

Dear GP members. Here is the Agenda for the next call. I have produced some materila for discussion MarketShare-Browsers-EmailClients<https://drive.google.com/open?id=17gw-hvYN7SEJ9ronBlMws5kkP7umptmt>. This excel file is on Google docs drive, and I am sending it also in this e-mail. Any comments are welcome. Regards Mirjana ___________________________________________ AGENDA for the GP call on February the 20th 2020, 16:00UTC 1. Roll call 2. New underlining analysis discussion and conclusions * Decision:which browsers and mail clients should be used for analysis * MarketShare-Browsers-EmailClients<https://drive.google.com/open?id=17gw-hvYN7SEJ9ronBlMws5kkP7umptmt> * Discussion: on which platforms browsers and mail clients should be tested * Mac OS * WIN * Mobile platform * Tablets * How to present results of test( .pdf?) * Who will compile the results of the analysis 3. Discussion on 2020-02-01-AditionalAnalysis<https://drive.google.com/open?id=19BgFtZNvA5cQs1nHLX5WZmFhcRYCb6QZ> 4. Allocation of tasks for first phase of Report completion 2020-02-01-Tasks-to-finalize Report<https://drive.google.com/open?id=1bRHfeLFZvAPXQIgpcKOtKfjAVRfjmD8-> 5. AOB

3 3

Latin GP meeting
by Pitinan Kooarmornpatana Feb. 18, 2020

Feb. 18, 2020

Dear Latin GP members, This is a gentle reminder for the Latin GP meeting on Thursday 20 February 2020. Please join the zoom meeting room at https://icann.zoom.us/j/931353600. Please find following note and agenda from the chair. …. Dear GP members. Here is the Agenda for the next call. I have produced some materila for discussion MarketShare-Browsers-EmailClients [drive.google.com]<https://urldefense.proofpoint.com/v2/url?u=https-3A__drive.google.com_open-…>. This excel file is on Google docs drive, and I am sending it also in this e-mail. Any comments are welcome. Regards Mirjana ___________________________________________ AGENDA for the GP call on February the 20th 2020, 16:00UTC 1. Roll call 2. New underlining analysis discussion and conclusions * Decision:which browsers and mail clients should be used for analysis * MarketShare-Browsers-EmailClients [drive.google.com]<https://urldefense.proofpoint.com/v2/url?u=https-3A__drive.google.com_open-…> * Discussion: on which platforms browsers and mail clients should be tested * Mac OS * WIN * Mobile platform * Tablets * How to present results of test( .pdf?) * Who will compile the results of the analysis 3. Discussion on 2020-02-01-AditionalAnalysis [drive.google.com]<https://urldefense.proofpoint.com/v2/url?u=https-3A__drive.google.com_open-…> 4. Allocation of tasks for first phase of Report completion 2020-02-01-Tasks-to-finalize Report [drive.google.com]<https://urldefense.proofpoint.com/v2/url?u=https-3A__drive.google.com_open-…> 5. AOB ……. To connect via phone, find your local number: https://icann.zoom.us/u/aw6COk4xD Meeting ID: 931 353 600 Regards, Pitinan

1 0

FW: Follow-up on Phone Call with Latin GP
by Pitinan Kooarmornpatana Feb. 13, 2020

Feb. 13, 2020

Dear Latin GP members, Please find below the message from the IP. This is a follow-up from the Phone call with Latin GP, suggesting guidelines for Latin script variant analysis. Regards, Pitinan From: Sarmad Hussain <sarmad.hussain(a)icann.org> Date: Wednesday, February 5, 2020 at 16:43 To: Pitinan Kooarmornpatana <pitinan.koo(a)icann.org> Subject: Fwd: Follow-up on Phone Call with Latin GP Dear Pitinan, Please share with Latin GP from IP. Regards, Sarmad Considerations in designing variant sets First, we generally say that more blocked variants are "good"; reducing the namespace a bit can make it safer, because it removes instances that can be exploited for malicious registrations. However, as we've recognized with cross-script variants, there's also a cost. There are two costs, one is that large variant sets tend to link things via transitivity that do not pass the "smell test" for users. They appear unmotivated, and when they lead to a desirable label being blocked by some other label that on the face of it isn't a true look-alike, the LGR comes out looking bad. There was the case of the Cyrillic country code that people claimed looked too much like "br". The similarity was not that close and it was allowed on appeal. An LGR variant, by design, does not allow appeal, so the goal has to be to limit such variants to "clear-cut" cases (where one would expect an appeal to fail, if it had been possible to lodge one). The other cost is that there is a tendency to impose in-language variants: except for well-defined exceptions we can assume that any two characters that are used in contrast in a language can (and will) be distinguished by its users (even if they look confusingly similar to people unfamiliar with them). We have been making similar arguments when it comes to in-script and cross-script variants. Preventing simultaneous registrations of words that are seen as clearly different by native users is not ideal. We need to treat that on the "cost" side of the ledger. Even in cases where the distinctions are subtle or where two spellings lead to the same result. For example, for ASCII TLD's, both .unicorn and .unicom are available (subject to further manual review) as are ".color" and ".colour". When it comes to diacritical marks, these precedents need to be borne in mind. However, diacritical marks themselves are not always easy to tell apart at small sizes (and/or when an underline interferes that is drawn without a "skip-ink" feature"). That also needs to be recognized, because it may well be that they provide an especially convenient target for spoofing. When it comes to possible confusions, the variant process is intended to deal with cases where one character, if placed inside a label, makes the label look like it is spelled with another character. Usually by substituting something that is "out of context". It is often said that labels do not have a linguistic context, but if a label matches the spelling of a word in the user's language (or a wordlike entity like a brand name that the user thinks they recognize) then we know that users do not necessarily read such labels letter by letter, but recognize them as a whole. If the altered "whole" looks acceptable enough, it will be treated as equivalent - even if we assume our "reasonably observant user". A user in a language that only has a macron above as a diacritic may be unlikely to accept most of the other diacritics as a substitute, but in the right context, a g with dot above, perhaps, might not be noticed when standing in for a g with cedilla (a small comma like shape above). If, however, the language context in which a user thinks they are recognizing a label includes both a dot above and some other mark, these two are less likely conflated --- even if they do not occur on the same base character. So, what we have are a number of principles, some that define benefits, some that define costs for adding or not adding variants. Like the case with so many other principles, any two individual principles may be in tension with each other. The goal is therefore to judge how much weight to give each one, so that they are collectively best satisfied, even if that means that some won't be. This also goes with the principle of language neutrality: ideally, we don't want to either burden or treat preferentially any given language to the exclusion of other. However, sometimes, taking other principles to their logical extreme, may impose too much of a cost. Or, in reverse, some balancing may lead to such an uneven treatment inside a single language that we are better off with more consistency. (This situation isn't new to the Latin script, it has been a constant across the Root Zone LGR -- and, again, it is a matter of judgment to get it right). For the Latin script: If two diacritics are never used in the same language, then there should be very limited cost on making those two a variant pair - unless doing so creates a large variant set with transitivity issues). This is true, in particular, if they occur on the same base character: G with dot above and G with cedilla might be an example; there's little downside and potential benefit of making them variants. If the language with the G cedilla also has a dot above some other letter, that language would not benefit from the variant, but the other language still might. If both have a dot above on some letters, but the other language has some other mark above some letters, the case would be even weaker: neither set of users would be very likely to accept a substitute of the other language's marks. If some diacritics are practically only ever used in one language (and look quite distinct) then it makes little sens to make them variants of each other. Native users can be expected to discriminate them and therefore a variant would have substantial cost and little benefit. If some diacritics are used contrastively in some language(s) on the same base character, the cost of making them a variant is potentially quite high (blocking many labels that users consider distinct). It might be best to limit variants in that case to diacritics that are particularly prone to being misidentified in any other contexts. If marks are reasonably distinct in printed presentation (as typical for user interfaces), causing in-language variants between them by transitivity should probably be avoided (if possible). Even if there's some hypothetical scenario why certain users might confuse them. Example is tilde vs. o-diaeresis. Even if there's a scenario where these can be substituted in Swedish, that scenario is perhaps not the most obvious and if it were to lead to some other language having two common characters made variants it would not pass the cost/benefit analysis. Variant sets with cross-script members need to be well-scrutinized for issues of transitivity. Overlapped variants cause permutations and need to be curtailed sharply; otherwise the attendant cost imposed especially in cross script cases will violate some of the overall principles against complexity and unexpected behavior. Hopefully, this summary is a useful guideline to help reasoning about these variant sets. As always, it's not a recipe or algorithm, but might be an aid in making judgements.

3 3

Latin GP meeting
by Pitinan Kooarmornpatana Feb. 10, 2020

Feb. 10, 2020

Dear Latin GP members, This is a gentle reminder for the Latin GP call on Thursday 13 February 2020 at 16:00UTC. Please join the meeting at https://icann.zoom.us/j/931353600. Please find the note and agenda from Mirjana as follow: …………………………………… Dear GP members. I am proposing next call to be held on February the 13th 16:00 UTC. I have made two tables with tasks , first with clear decisions which should be implemented in th Report and second with additional analysis which should be completed. Both tables are uploaded to Google drive and I am also sending them in thi mail. I am asking all members of the GP to look at these tables and add the tasks I might missed to include, or correct anything which I might not understand. If you find anything else that could be discussed, please, let me know it. Any comments are welcome. Regards Mirjana ___________________________________________ AGENDA for the GP call on February the 13th 2020, 16:00UTC 1. Roll call 2. Presentation for ICANN 67 in Cancun 3. Allocation of tasks for first phase of Report completion 2020-02-01-Tasks-to-finalize Report [drive.google.com]<https://urldefense.proofpoint.com/v2/url?u=https-3A__drive.google.com_open-…> 4. Discussion on 2020-02-01-AditionalAnalysis [drive.google.com]<https://urldefense.proofpoint.com/v2/url?u=https-3A__drive.google.com_open-…> 5. AOB …………………….. Regards, Pitinan ----------------- To join via phone, Find your local number: https://icann.zoom.us/u/aw6COk4xD Meeting ID: 931 353 600

1 0

AGENDA for the GP call on February the 13th 2020, 16:00UTC
by Mirjana Tasić Feb. 9, 2020

Feb. 9, 2020

Dear GP members. I am proposing next call to be held on February the 13th 16:00 UTC. I have made two tables with tasks , first with clear decisions which should be implemented in th Report and second with additional analysis which should be completed. Both tables are uploaded to Google drive and I am also sending them in thi mail. I am asking all members of the GP to look at these tables and add the tasks I might missed to include, or correct anything which I might not understand. If you find anything else that could be discussed, please, let me know it. Any comments are welcome. Regards Mirjana ___________________________________________ AGENDA for the GP call on February the 13th 2020, 16:00UTC 1. Roll call 2. Presentation for ICANN 67 in Cancun 3. Allocation of tasks for first phase of Report completion 2020-02-01-Tasks-to-finalize Report<https://drive.google.com/open?id=1bRHfeLFZvAPXQIgpcKOtKfjAVRfjmD8-> 4. Discussion on 2020-02-01-AditionalAnalysis<https://drive.google.com/open?id=19BgFtZNvA5cQs1nHLX5WZmFhcRYCb6QZ> 5. AOB

1 0