May 2020 - Latingp - lists.icann.org

Re: [Latingp] Handling of down casing of I-dotted in Turkish locale
by Tan Tanaka, Dennis May 21, 2020

May 21, 2020

There are two set of rules, one for non-Turkish # Preserve canonical equivalence for I with dot. Turkic is handled below. 0130; 0069 0307; 0130; 0130; # LATIN CAPITAL LETTER I WITH DOT ABOVE And another for Turkish # Turkish and Azeri # I and i-dotless; I-dot and i are case pairs in Turkish and Azeri # The following rules handle those cases. 0130; 0069; 0130; 0130; tr; # LATIN CAPITAL LETTER I WITH DOT ABOVE 0130; 0069; 0130; 0130; az; # LATIN CAPITAL LETTER I WITH DOT ABOVE # When lowercasing, remove dot_above in the sequence I + dot_above, which will turn into i. # This matches the behavior of the canonically equivalent I-dot_above 0307; ; 0307; 0307; tr After_I; # COMBINING DOT ABOVE 0307; ; 0307; 0307; az After_I; # COMBINING DOT ABOVE # When lowercasing, unless an I is before a dot_above, it turns into a dotless i. 0049; 0131; 0049; 0049; tr Not_Before_Dot; # LATIN CAPITAL LETTER I 0049; 0131; 0049; 0049; az Not_Before_Dot; # LATIN CAPITAL LETTER I # When uppercasing, i turns into a dotted capital I 0069; 0069; 0130; 0130; tr; # LATIN SMALL LETTER I 0069; 0069; 0130; 0130; az; # LATIN SMALL LETTER I # Note: the following case is already in the UnicodeData.txt file. # 0131; 0131; 0049; 0049; tr; # LATIN SMALL LETTER DOTLESS I If I understand this correctly, when we test the IDNA behavior of the uppercase string in a Turkish setting we should see the behavior described in the second part. -Dennis From: Latingp <latingp-bounces(a)icann.org> on behalf of Mats Dufberg <mats.dufberg(a)internetstiftelsen.se> Date: Thursday, May 14, 2020 at 4:27 PM To: ICANN Latin GP <Latingp(a)icann.org> Subject: [EXTERNAL] [Latingp] Handling of down casing of I-dotted in Turkish locale The link below goes to the file in the Unicode database that handles the special casing rules for i etc in Turkish and Azerian (sp?). The relevant section is the last section of the file. https://unicode.org/Public/UNIDATA/SpecialCasing.txt<https://secure-web.cisco.com/1dlxHfZjx47yHAT5TJ-TrHDc10FAKGc9NIcXVBJkyDPDxP…> --- Mats Dufberg mats.dufberg(a)internetstiftelsen.se Technical Expert Internetstiftelsen (The Swedish Internet Foundation) Mobile: +46 73 065 3899 https://internetstiftelsen.se/

3 3

Summary of Latin GP Meeting on 14 May 2020
by Pitinan Kooarmornpatana May 20, 2020

May 20, 2020

Dear All, Please find attached the summary of the Latin GP meeting on 14 May 2020. Please let us know if you would like to suggest any edits or additions. Action Items: S. No.Action ItemsOwner 1Prepare test case for dotless I and conduct the testALL 2Review the finalized in-script variant sheet 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: [Ext] Re: Re: Handling of down casing of I-dotted in Turkish locale
by Pitinan Kooarmornpatana May 20, 2020

May 20, 2020

Dear All, Please find the test results tested by Mert Saka, our colleague in ICANN Istanbul office. He also asked me to extend his sincere thanks to everyone on Latin GP for enabling the Turkish IDNs. Regards, Pitinan From: Mert Saka <mert.saka(a)icann.org> Date: Wednesday, May 20, 2020 at 15:48 To: Pitinan Kooarmornpatana <pitinan.koo(a)icann.org> Cc: Sarmad Hussain <sarmad.hussain(a)icann.org> Subject: Re: [Ext] Re: Re: [Latingp] Handling of down casing of I-dotted in Turkish locale Hi Pitinan, Yesterday was a public holiday in Turkey, so I had plenty of time in my hands to test. I resulted testing on 4 different devices, but with only two browsers (Chrome and Firefox). More details about my testing environment (the device details) are below, hoping they help the team evaluate the results better: ICANN’s MacBook Pro on MacOS Mojave (10.14.6) Locale en_US: Only Chrome, no Firefox. Safari was not possible to test because it automatically forwards me to the default search engine for any unrecognized domain names (including base test case, “zil.test” and I couldn’t find how to turn it off). Personal MacBook Air on MacOS Mojave (10.14.6) Locale en_TR: Chrome and Firefox available but couldn’t test Safari (same reason above). Personal MSI GE73VR 8RF-210XTR Laptop on Windows 10 Locale tr; Türkçe : Chrome installed, no Firefox or Safari. Couldn’t test on Edge (same reason as Safari on MacOS above). ICANN’s iPhone on iOS (13.4.1): Chrome and Safari available. No other browsers. Here are some highlights from the test results: In general, results were consistent across devices for IDNA conversion on https://www.punycoder.com/. Even on mobile devices, it worked the consistently and delivered punycode for each word successfully. Chrome on all my computers worked well, except for its different display behavior for “zıl.test” and “ZİL.test”. You can see them below on the images I added inline but to summarize: “zıl.test” (DOTLESS LOWERCASE I) is displayed on the address bar as-is, but “ZIL.test” is displayed as punycode (xn--zil-9dc.test) on the address bar. Both are copy/pasted as punycode, so I see no odd browser behavior, but thought it would be something to take into consideration about consistency with display. Firefox on my personal MacBook has a problem with “ZİL.test” (with CAPITAL DOTTED I). “İ” turns into a LOWERCASE I WITH TWO DOTS ON TOP. I thought this was something weird, so Firefox seems to fail the browser behavior testing when using UPPERCASE I WITH DOT ON TOP. Safari on my company iPhone for “ZİL.test” (with CAPITAL I WITH DOT ON TOP) is displayed as-is (“ZİL.test”) on browser address bar but when copy/pasted on to the iPhone Notes app, it is displayed as a LOWERCASE I WITH TWO DOTS ON TOP. You can find the result attached as screenshot. I elaborate more on this in the below note about the testing methodology. A note about the testing methodology: When we “copy” text, we actually use another application (the Operating System, a.k.a. OS), which may have an impact on the test results. Taking a screenshot would be a better option because when copying, we do not know how OS stores it in memory (as punycode or ISO or UTF or else). When “pasting” on an application (in my case Outlook Mail or iOS Mail or iOS Notes app), results may not be consistent (examples below also point to this difference between copy/pasting and screenshots). You can see the result when I copy/pasted it onto the iOS Notes app on my iPhone in the attached screenshot. To get rid of copy/paste issues into Outlook Mail on my Mac, I also attached a UTF-8 coded plain-text TXT file (Test Results.txt), which can help to observe results as they actually appear on my devices. Now, the test result details: 1. ICANN’s MacBook Pro on MacOS Mojave (10.14.6) IDNA conversión https://www.punycoder.com/ User InputCopy and Paste into “Text” box, then “Convert to Punycode”zilzılZİLZIL Output Register output string in “Punycode” boxzilxn--zl-hpa xn--zil-9dc ZIL Browser Behavior (Chrome) User InputCopy and Paste in URL address Barzil.test zıl.test*ZİL.testZIL.test* Output URL BarRegister returned label in address barhttp://zil.test/http://xn--zl-hpa.test/http://xn--zil-9dc.test/ http://zil.test/ * Below are the images that show the different display behavior of Chrome for the two Turkish characters: “zıl.test” (LOWERCASE I WITHOUT DOT)  “ZİL.test” (CAPITAL I WITH DOT ON TOP)  2. Personal MacBook Air on MacOS Mojave (10.14.6) IDNA conversión https://www.punycoder.com/ User InputCopy and Paste into “Text” box, then “Convert to Punycode”zilzılZİLZIL Output Register output string in “Punycode” boxzilxn--zl-hpa xn--zil-9dc ZIL Browser Behavior (Chrome) User InputCopy and Paste in URL address Barzil.test zıl.test*ZİL.test*ZIL.test Output URL BarRegister returned label in address barhttp://zil.test/http://xn--zl-hpa.test/http://xn--zil-9dc.test/ http://zil.test/ * Same results as ICANN’s MBPro above. Different display behavior of Chrome for the two Turkish characters were observed as in the above screenshots. Browser Behavior (Firefox) User InputCopy and Paste in URL address Barzil.test zıl.testZİL.test*ZIL.test Output URL BarRegister returned label in address barhttp://www.zil.test/http://www.zıl.test/http://www.zi̇l.test/ http://www.zil.test/ * Pleaase note that the result may not be displayed above (due to Outlook Email) properly. Please refer to the results on the image below and the attached TXT file. “ZİL.test” (CAPITAL I WITH DOT ON TOP)  3. Personal MSI GE73VR 8RF-210XTR Laptop on Windows 10 IDNA conversión https://www.punycoder.com/ User InputCopy and Paste into “Text” box, then “Convert to Punycode”zilzılZİLZIL Output Register output string in “Punycode” boxzilxn--zl-hpa xn--zil-9dc ZIL Browser Behavior (Chrome) User InputCopy and Paste in URL address Barzil.test zıl.test*ZİL.test*ZIL.test Output URL BarRegister returned label in address barhttp://zil.test/http://xn--zl-hpa.test/http://xn--zil-9dc.test/http://zil.test/ * Same results as ICANN’s MBPro above. Different display behavior of Chrome for the two Turkish characters were observed as in the above screenshots. 4. ICANN’s iPhone on iOS (13.4.1) IDNA conversión https://www.punycoder.com/ User InputCopy and Paste into “Text” box, then “Convert to Punycode”zilzılZİLZIL Output Register output string in “Punycode” boxzilxn--zl-hpa xn--zil-9dc ZIL Browser Behavior (Chrome) User InputCopy and Paste in URL address Barzil.test zıl.testZİL.testZIL.test Output URL BarRegister returned label in address barhttp://zil.test/http://xn--zl-hpa.test/http://xn--zil-9dc.test/http://zil.test/ * Same results as ICANN’s MBPro above. Different display behavior of Chrome for the two Turkish characters were observed as seen in the screenshots below: “zıl.test” (LOWERCASE I WITHOUT DOT)  “ZİL.test” (CAPITAL I WITH DOT ON TOP)  Browser Behavior (Safari) User InputCopy and Paste in URL address Barzil.test zıl.testZİL.test*ZIL.test Output URL BarRegister returned label in address barhttp://zil.test/http://zıl.testhttp://zi̇l.testhttp://zil.test/ * Pleaase note that the result above may not be displayed (due to Outlook Email) properly. Please refer to the results on the image below and the attached TXT file. “ZİL.test” (CAPITAL I WITH DOT ON TOP)  I hope these will be helpful to evaluate the browsers better and inline images are displayed on your computer properly. If not, please let me know and I can send them in a different format. I wish you a happy COVID-free day… Best regards, Mert Saka gTLD Accounts Manager ICANN – www.icann.org From: Pitinan Kooarmornpatana <pitinan.koo(a)icann.org> Date: Monday, May 18, 2020 at 22:04 To: Mert Saka <mert.saka(a)icann.org> Cc: Sarmad Hussain <sarmad.hussain(a)icann.org> Subject: FW: [Ext] Re: Re: [Latingp] Handling of down casing of I-dotted in Turkish locale Hi Mert, Trust this email finds you well. The Latin GP is testing some behavior with the Turkish locale. I understand that ICANN laptop would have setting of US Locale (en_US). So I’m wondering if you could find the Turkish local computer to conduct the test below? Please feel free to ping me on slack if you have any questions. Regards, Pitinan From: "Tan Tanaka, Dennis" <dtantanaka(a)verisign.com> Date: Saturday, May 16, 2020 at 03:59 To: Pitinan Kooarmornpatana <pitinan.koo(a)icann.org>, "mats.dufberg(a)internetstiftelsen.se" <mats.dufberg(a)internetstiftelsen.se>, "Latingp(a)icann.org" <Latingp(a)icann.org> Subject: [Ext] Re: Re: [Latingp] Handling of down casing of I-dotted in Turkish locale Thanks Pitinan. We would need to determine the IDNA behavior in a conversion tool and the browser. To that effect, could you ask your colleague to try the below examples. (He/She needs to copy and paste the Input strings into the tool and URL address bars, and register the output string for each test). @Mats Dufberg Provided their machines are set up with Turkish locale, are we missing any other test case? IDNA conversion https://www.punycoder.com/ User InputCopy and Paste into “Text” box, then “Convert to Punycode”zilzılZİLZIL Output Register output string in “Punycode” box Browser Behavior (repeat for Chrome, Firefox and Safari/Edge) User InputCopy and Paste in URL address Barzil.test zıl.testZİL.testZIL.test Output URL BarRegister returned label in address bar Thanks, Dennis From: Pitinan Kooarmornpatana <pitinan.koo(a)icann.org> Date: Friday, May 15, 2020 at 4:36 PM To: Mats Dufberg <mats.dufberg(a)internetstiftelsen.se>, Dennis Tan Tanaka <dtantanaka(a)verisign.com>, "Latingp(a)icann.org" <Latingp(a)icann.org> Subject: [EXTERNAL] Re: [Latingp] Handling of down casing of I-dotted in Turkish locale Dear all, Please find attached test case and the results. 1. test case file (test case.xlsx) 2. test result using Turkish locale (testcase-turkishlocale.xlsx) 3. test result using en_US local (test case-en_US-locale.xlsx) The test result for Turkish locale was done by someone in Turkey who use Turkish locale. The result for case folding seems to be stable both up and down. The test result for en_US was done by me and it cannot produce original dotless I after a round-folding. I understand that this due to the absence of CAPITAL LETTER I WITH DOT ABOVE in en-US locale. Kindly let us know if there is any further queries. Regards, Pitinan From: Latingp <latingp-bounces(a)icann.org> on behalf of Mats Dufberg <mats.dufberg(a)internetstiftelsen.se> Date: Friday, May 15, 2020 at 05:13 To: "Tan Tanaka, Dennis" <dtantanaka(a)verisign.com>, "Latingp(a)icann.org" <Latingp(a)icann.org> Subject: Re: [Latingp] Handling of down casing of I-dotted in Turkish locale > If I understand this correctly, when we test the IDNA behavior of the uppercase string in a Turkish setting we should see the behavior described in the second part. That is my interpretation too. I will try to test some generic tool with Turkish locale (tr_TR.UTF-8) set. Mats --- Mats Dufberg mats.dufberg(a)internetstiftelsen.se Technical Expert Internetstiftelsen (The Swedish Internet Foundation) Mobile: +46 73 065 3899 https://internetstiftelsen.se/ From: "Tan Tanaka, Dennis" <dtantanaka(a)verisign.com> Date: Thursday, 14 May 2020 at 23:19 To: Mats Dufberg <mats.dufberg(a)internetstiftelsen.se>, ICANN Latin GP <Latingp(a)icann.org> Subject: Re: [Latingp] Handling of down casing of I-dotted in Turkish locale There are two set of rules, one for non-Turkish # Preserve canonical equivalence for I with dot. Turkic is handled below. 0130; 0069 0307; 0130; 0130; # LATIN CAPITAL LETTER I WITH DOT ABOVE And another for Turkish # Turkish and Azeri # I and i-dotless; I-dot and i are case pairs in Turkish and Azeri # The following rules handle those cases. 0130; 0069; 0130; 0130; tr; # LATIN CAPITAL LETTER I WITH DOT ABOVE 0130; 0069; 0130; 0130; az; # LATIN CAPITAL LETTER I WITH DOT ABOVE # When lowercasing, remove dot_above in the sequence I + dot_above, which will turn into i. # This matches the behavior of the canonically equivalent I-dot_above 0307; ; 0307; 0307; tr After_I; # COMBINING DOT ABOVE 0307; ; 0307; 0307; az After_I; # COMBINING DOT ABOVE # When lowercasing, unless an I is before a dot_above, it turns into a dotless i. 0049; 0131; 0049; 0049; tr Not_Before_Dot; # LATIN CAPITAL LETTER I 0049; 0131; 0049; 0049; az Not_Before_Dot; # LATIN CAPITAL LETTER I # When uppercasing, i turns into a dotted capital I 0069; 0069; 0130; 0130; tr; # LATIN SMALL LETTER I 0069; 0069; 0130; 0130; az; # LATIN SMALL LETTER I # Note: the following case is already in the UnicodeData.txt file. # 0131; 0131; 0049; 0049; tr; # LATIN SMALL LETTER DOTLESS I If I understand this correctly, when we test the IDNA behavior of the uppercase string in a Turkish setting we should see the behavior described in the second part. -Dennis From: Latingp <latingp-bounces(a)icann.org> on behalf of Mats Dufberg <mats.dufberg(a)internetstiftelsen.se> Date: Thursday, May 14, 2020 at 4:27 PM To: ICANN Latin GP <Latingp(a)icann.org> Subject: [EXTERNAL] [Latingp] Handling of down casing of I-dotted in Turkish locale The link below goes to the file in the Unicode database that handles the special casing rules for i etc in Turkish and Azerian (sp?). The relevant section is the last section of the file. https://unicode.org/Public/UNIDATA/SpecialCasing.txt [secure-web.cisco.com] --- Mats Dufberg mats.dufberg(a)internetstiftelsen.se Technical Expert Internetstiftelsen (The Swedish Internet Foundation) Mobile: +46 73 065 3899 https://internetstiftelsen.se/

1 0

Agenda for Latin GP meeting 21st of May
by Pitinan Kooarmornpatana May 20, 2020

May 20, 2020

Dear All, Please find following the proposed agenda for your consideration. AGENDA for the GP call on May the 21st, 2020, 16:00UTC Latin Small Letter I (i,0069) and Latin Small Letter Dotless I (ı,0131) https://docs.google.com/document/d/11aads2CRTE7C_gpSejL8ltW2Z8fMNZXT2cWdT0y… [docs.google.com] Report finalization – discussion topics · D.4.22 Finalize the in-script Variant Analysis sheet. · D.5.1 Latin Small Letter Sharp S (ß) 00DF --- confirm to remove Appendix E as S and S with below diacritics are not variants. · D.5.2 Latin Small Letter Dotless I (ı) 0131 --- waiting for conclusion. · D.6 Underlining Evaluation Process --- underlining is not relevant to the variant analysis. Add conclusion to 6.6.1 · D.7 Generic Glyphs --- to confirm relevant text in section 6.3.4 · D.8 Caron Above --- to confirm relevant text in section 5.3.2. Next tasks- discuss the priorities: Thorough reading and finalization of In-Script variant analysis Review proposed confusables for Similarity review Report finalization XML production and correction of possible errors Test data production Next meeting May the 28th 2020, 16:00 UTC AOB Regards, Pitinan

2 1

Re: [Latingp] Handling of down casing of I-dotted in Turkish locale
by Tan Tanaka, Dennis May 15, 2020

May 15, 2020

Thanks Pitinan. We would need to determine the IDNA behavior in a conversion tool and the browser. To that effect, could you ask your colleague to try the below examples. (He/She needs to copy and paste the Input strings into the tool and URL address bars, and register the output string for each test). @Mats Dufberg Provided their machines are set up with Turkish locale, are we missing any other test case? IDNA conversion https://www.punycoder.com/ User InputCopy and Paste into “Text” box, then “Convert to Punycode”zilzılZİLZIL Output Register output string in “Punycode” box Browser Behavior (repeat for Chrome, Firefox and Safari/Edge) User InputCopy and Paste in URL address Barzil.test zıl.testZİL.testZIL.test Output URL BarRegister returned label in address bar Thanks, Dennis From: Pitinan Kooarmornpatana <pitinan.koo(a)icann.org> Date: Friday, May 15, 2020 at 4:36 PM To: Mats Dufberg <mats.dufberg(a)internetstiftelsen.se>, Dennis Tan Tanaka <dtantanaka(a)verisign.com>, "Latingp(a)icann.org" <Latingp(a)icann.org> Subject: [EXTERNAL] Re: [Latingp] Handling of down casing of I-dotted in Turkish locale Dear all, Please find attached test case and the results. 1. test case file (test case.xlsx) 2. test result using Turkish locale (testcase-turkishlocale.xlsx) 3. test result using en_US local (test case-en_US-locale.xlsx) The test result for Turkish locale was done by someone in Turkey who use Turkish locale. The result for case folding seems to be stable both up and down. The test result for en_US was done by me and it cannot produce original dotless I after a round-folding. I understand that this due to the absence of CAPITAL LETTER I WITH DOT ABOVE in en-US locale. Kindly let us know if there is any further queries. Regards, Pitinan From: Latingp <latingp-bounces(a)icann.org> on behalf of Mats Dufberg <mats.dufberg(a)internetstiftelsen.se> Date: Friday, May 15, 2020 at 05:13 To: "Tan Tanaka, Dennis" <dtantanaka(a)verisign.com>, "Latingp(a)icann.org" <Latingp(a)icann.org> Subject: Re: [Latingp] Handling of down casing of I-dotted in Turkish locale > If I understand this correctly, when we test the IDNA behavior of the uppercase string in a Turkish setting we should see the behavior described in the second part. That is my interpretation too. I will try to test some generic tool with Turkish locale (tr_TR.UTF-8) set. Mats --- Mats Dufberg mats.dufberg(a)internetstiftelsen.se Technical Expert Internetstiftelsen (The Swedish Internet Foundation) Mobile: +46 73 065 3899 https://internetstiftelsen.se/ From: "Tan Tanaka, Dennis" <dtantanaka(a)verisign.com> Date: Thursday, 14 May 2020 at 23:19 To: Mats Dufberg <mats.dufberg(a)internetstiftelsen.se>, ICANN Latin GP <Latingp(a)icann.org> Subject: Re: [Latingp] Handling of down casing of I-dotted in Turkish locale There are two set of rules, one for non-Turkish # Preserve canonical equivalence for I with dot. Turkic is handled below. 0130; 0069 0307; 0130; 0130; # LATIN CAPITAL LETTER I WITH DOT ABOVE And another for Turkish # Turkish and Azeri # I and i-dotless; I-dot and i are case pairs in Turkish and Azeri # The following rules handle those cases. 0130; 0069; 0130; 0130; tr; # LATIN CAPITAL LETTER I WITH DOT ABOVE 0130; 0069; 0130; 0130; az; # LATIN CAPITAL LETTER I WITH DOT ABOVE # When lowercasing, remove dot_above in the sequence I + dot_above, which will turn into i. # This matches the behavior of the canonically equivalent I-dot_above 0307; ; 0307; 0307; tr After_I; # COMBINING DOT ABOVE 0307; ; 0307; 0307; az After_I; # COMBINING DOT ABOVE # When lowercasing, unless an I is before a dot_above, it turns into a dotless i. 0049; 0131; 0049; 0049; tr Not_Before_Dot; # LATIN CAPITAL LETTER I 0049; 0131; 0049; 0049; az Not_Before_Dot; # LATIN CAPITAL LETTER I # When uppercasing, i turns into a dotted capital I 0069; 0069; 0130; 0130; tr; # LATIN SMALL LETTER I 0069; 0069; 0130; 0130; az; # LATIN SMALL LETTER I # Note: the following case is already in the UnicodeData.txt file. # 0131; 0131; 0049; 0049; tr; # LATIN SMALL LETTER DOTLESS I If I understand this correctly, when we test the IDNA behavior of the uppercase string in a Turkish setting we should see the behavior described in the second part. -Dennis From: Latingp <latingp-bounces(a)icann.org> on behalf of Mats Dufberg <mats.dufberg(a)internetstiftelsen.se> Date: Thursday, May 14, 2020 at 4:27 PM To: ICANN Latin GP <Latingp(a)icann.org> Subject: [EXTERNAL] [Latingp] Handling of down casing of I-dotted in Turkish locale The link below goes to the file in the Unicode database that handles the special casing rules for i etc in Turkish and Azerian (sp?). The relevant section is the last section of the file. https://unicode.org/Public/UNIDATA/SpecialCasing.txt [secure-web.cisco.com] --- Mats Dufberg mats.dufberg(a)internetstiftelsen.se Technical Expert Internetstiftelsen (The Swedish Internet Foundation) Mobile: +46 73 065 3899 https://internetstiftelsen.se/

1 0

Handling of down casing of I-dotted in Turkish locale
by Mats Dufberg May 14, 2020

May 14, 2020

The link below goes to the file in the Unicode database that handles the special casing rules for i etc in Turkish and Azerian (sp?). The relevant section is the last section of the file. https://unicode.org/Public/UNIDATA/SpecialCasing.txt --- Mats Dufberg mats.dufberg(a)internetstiftelsen.se Technical Expert Internetstiftelsen (The Swedish Internet Foundation) Mobile: +46 73 065 3899 https://internetstiftelsen.se/

1 0

In-script variant sheet
by Pitinan Kooarmornpatana May 14, 2020

May 14, 2020

Dear Latin GP member, Please find the in-script variant sheet for your review here. The same excel file is attached for your reference. Regards, Pitinan

1 0

[Updated Zoom Link] Latin GP Meeting
by Pitinan Kooarmornpatana May 14, 2020

May 14, 2020

Dear Latin GP members, This is a gentle reminder for the Latin GP meetings on Thursday 14 May 2020 at 16:00UTC. Please join the meeting at the updated link: https://icann.zoom.us/j/95395839226?pwd=ZGxpYmRqV2E2NjloWTFHZWNGbkJWZz09 Password: 096517 AGENDA for the GP call on May the 13th, 2020, 16:00UTC 1. Latin Small Letter I (i,0069) and Latin Small Letter Dotless I (ı,0131) the analysis is already documented, it only requires the final conclusion. Please find the relevant section in the proposal below. Here is the additional research on the stability issue with case folding of dotless I and dotted I by Dennis https://docs.google.com/document/d/11aads2CRTE7C_gpSejL8ltW2Z8fMNZXT2cWdT0y… [docs.google.com]<https://urldefense.proofpoint.com/v2/url?u=https-3A__docs.google.com_docume…> 2. Report finalization – discussion topics * D.4.21 Stacking in Courier New (And Perhaps Other Fonts) --- conclusion is missing. * D.4.22 Finalize the in-script Variant Analysis sheet. * D.5.1 Latin Small Letter Sharp S (ß) 00DF --- confirm to remove Appendix E as S and S with below diacritics are not variants. * D.5.2 Latin Small Letter Dotless I (ı) 0131 --- waiting for conclusion. * D.6 Underlining Evaluation Process --- underlining is not relevant to the variant analysis. Add conclusion to 6.6.1 * D.7 Generic Glyphs --- to confirm relevant text in section 6.3.4 * D.8 Caron Above --- to confirm relevant text in section 5.3.2. 3. Next tasks- discuss the priorities: * Thorough reading and finalization of In-Script variant analysis * Review proposed confusables for Similarity review * Report finalization * XML production and correction of possible errors * Test data production 4. Next meeting May the 21st 2020, 16:00 UTC 5. AOB Regards, Pitinan -------------- To join via phone, please find your local number at https://icann.zoom.us/u/aw6COk4xD Meeting ID: 953 9583 9226 Password: 096517 D.5.2 Latin Small Letter Dotless I (ı) 0131 There are four Latin code points that have a special case (upper case/lower case) relationship: · U+0069 Latin Small Letter I ("i") · U+0049 Latin Capital Letter I ("I") · U+0131 Latin Small Letter Dotless I ("ı") · U+0130 Latin Capital Letter I with Dot Above ("İ") In most locales Latin Small Letter I is lower case of Latin Capital Letter I, and reverse Latin Capital Letter I (U+0069) is upper case of Latin Small Letter I (U+0069). In those locales, Latin Capital Letter I (U+0049) is also upper case of Latin Small Letter Dotless I. It could be described as in the following chart: Table D.8. Case Relationships for 0069, 0049, 0130, and 0131 Character Process Resulting Character Process Resulting Character Latin Small Letter I U+0069 up case → Latin Capital Letter I U+0049 down case → Latin Small Letter I U+0069 Latin Small Letter Dotless I U+0131 up case → Latin Capital Letter I U+0049 down case → Latin Small Letter I U+0069 Latin Capital Letter I with Dot Above U+0130 down case → Latin Small Letter I U+0069 up case → Latin Capital Letter I U+0049 In two locales, Turkish and Azeri, respectively, the case relationship is different. In those two, Latin Small Letter I and Latin Capital Letter I with Dot Above are in mutual upcase/downcase relationship to each other, as well as Latin Small Letter Dotless I and Latin Capital Letter I, which could be described as in the following chart: Table D.9. Case Relationships in Turkish and Azeri Locales Character Process Resulting Character Process Resulting Character Latin Small Letter I up case → Latin Capital Letter I with Dot Above down case → Latin Small Letter I Latin Small Letter Dotless I up case → Latin Capital Letter I down case → Latin Small Letter Dotless I If we look at the repertoire of Latin code points for the root zone, as proposed by the Latin Generation Panel, Latin Small Letter I and Latin Small Letter Dotless I are included, whereas the capital letters are excluded. Capital letters are not even valid in IDNA2008, so the question is, is the case relationship described here a problem or even relevant? Before IDNA2008, there was IDNA2003. Even though IDNA2003 has been replaced by IDNA2008 it is still implemented. For example, the web browser Google Chrome to date remains IDNA2003 compliant but not fully IDNA 2008 compliant. In IDNA2003 there is a pre-process, normalization, of domain names before conversion to Punycode. That normalization includes down casing of Latin characters. For ASCII labels there is already an equivalence between upper case and lower case letters. And this is what users, based on decades of experience, expect to happen. In an IDNA2003-compliant web browser it is expected that "EXÄMPEL" and "EXAMPLE" are equivalent to "exämpel" and "example", respectively. In an IDNA2008 browser "EXAMPLE" must be accepted, but "EXÄMPLE" could be rejected since "Ä" is not valid, but that is not how e.g. Mozilla Firefox and Apple Safari have been designed to handle the problem. They also do down case before the formal IDNA2008 process. Even though down casing is not part of the formal IDNA2008 process, one of the IDNA2008 documents, RFC 5894, states that the user interface of an application, before IDNA2008 processing, can do normalization. The down casing in IDNA2008 browsers should probably be seen in that light. While "TÄT" will probably be down cased to "tät" in the browser, what should the browser do with "TIT"? Depending on the locale that the browser is running in, it may be down cased to either "tit" or "tıt" (with or without the dot). The casing, in an application, is expected to go in one direction, from upper case to lower case. When domain names are presented in text, however, it is common that domain names are presented in upper or mixed case. So "ice" might become "Ice" or "İce". It is quite obvious from the text above that case shift of dotted or dotless I could create erroneous lookup, but the question is how large threat it would be to the users. Since the applications are expected to go from upper case to lower case, when they handle domain names, we should consider a situation where down casing could result in different lower case letters, i.e. when CAPITAL LETTER I is down cased. With a non-Turkish and non-Azeri locale, a Latin CAPITAL LETTER I in a domain name is either down cased to Latin Small Letter I (IDN label) or equivalent to Latin Small Letter I (ASCII label). With a Turkish or Azeri locale, a Latin Capital Letter I is expected to be down cased to Latin Small Letter Dotless I, but in an ASCII label in a domain name, it is still expected to be equivalent with Latin Small Letter I, because that is what the DNS standards says. There is an obvious risk that, in a Turkish or Azeri locale that the two letters are confused or mistreated due to the case folding, and this confusion could be misused. To be on the safe side Latin Small Letter I and Latin Small Letter Dotless I should be variants. Accordingly, the following variant set could be the optimal solution: Table D.10. Possible Variant Relationships for 0069 and 0131 Group Dotless i vs. i Target Source Variant Candidate [Yes/No] Disposition [Allocatable/ Blocked] Rationale Code Point Glyph Name Code Point Glyph Name 0069 i Latin Small Letter I 0131 ı Latin Small Letter Dotless I YES Blocked Risk of confusion due to inconsistent case folding 0131 ı Latin Small Letter Dotless I 0069 i Latin Small Letter I YES Blocked Risk of confusion due to inconsistent case folding

1 0

AGENDA for the GP call on May the 13th 2020, 16:00UTC
by Mirjana Tasić May 13, 2020

May 13, 2020

Dear GP members, Please find enclosed the proposal of Agenda for our call. Any comments, corrections and suggestions are welcome. Regards Mirjana AGENDA for the GP call on May the 13th 2020, 16:00UTC 1. Latin Small Letter I () and Latin Small Letter Dotless I () the analysis is already documented, it only requires the final conclusion. Please find the relevant section in the proposal below. Here is the additional research on the stability issue with case folding of dotless I and dotted I by Dennis https://docs.google.com/document/d/11aads2CRTE7C_gpSejL8ltW2Z8fMNZXT2cWdT0y… 2. Report finalization - pending issues by Pitinan 3. Next tasks- discuss the priorities: * Thorough reading and finalization of In-Script variant analysis * Review proposed confusables for Similarity review * Report finalization * XML production and correction of possible errors * Test data production 4. Next meeting May the 21st 2020, 16:00 UTC 5. AOB D.5.2 Latin Small Letter Dotless I (ı) 0131 There are four Latin code points that have a special case (upper case/lower case) relationship: · U+0069 Latin Small Letter I ("i") · U+0049 Latin Capital Letter I ("I") · U+0131 Latin Small Letter Dotless I ("ı") · U+0130 Latin Capital Letter I with Dot Above ("İ") In most locales Latin Small Letter I is lower case of Latin Capital Letter I, and reverse Latin Capital Letter I (U+0069) is upper case of Latin Small Letter I (U+0069). In those locales, Latin Capital Letter I (U+0049) is also upper case of Latin Small Letter Dotless I. It could be described as in the following chart: Table D.8. Case Relationships for 0069, 0049, 0130, and 0131 Character Process Resulting Character Process Resulting Character Latin Small Letter I U+0069 up case → Latin Capital Letter I U+0049 down case → Latin Small Letter I U+0069 Latin Small Letter Dotless I U+0131 up case → Latin Capital Letter I U+0049 down case → Latin Small Letter I U+0069 Latin Capital Letter I with Dot Above U+0130 down case → Latin Small Letter I U+0069 up case → Latin Capital Letter I U+0049 In two locales, Turkish and Azeri, respectively, the case relationship is different. In those two, Latin Small Letter I and Latin Capital Letter I with Dot Above are in mutual upcase/downcase relationship to each other, as well as Latin Small Letter Dotless I and Latin Capital Letter I, which could be described as in the following chart: Table D.9. Case Relationships in Turkish and Azeri Locales Character Process Resulting Character Process Resulting Character Latin Small Letter I up case → Latin Capital Letter I with Dot Above down case → Latin Small Letter I Latin Small Letter Dotless I up case → Latin Capital Letter I down case → Latin Small Letter Dotless I If we look at the repertoire of Latin code points for the root zone, as proposed by the Latin Generation Panel, Latin Small Letter I and Latin Small Letter Dotless I are included, whereas the capital letters are excluded. Capital letters are not even valid in IDNA2008, so the question is, is the case relationship described here a problem or even relevant? Before IDNA2008, there was IDNA2003. Even though IDNA2003 has been replaced by IDNA2008 it is still implemented. For example, the web browser Google Chrome to date remains IDNA2003 compliant but not fully IDNA 2008 compliant. In IDNA2003 there is a pre-process, normalization, of domain names before conversion to Punycode. That normalization includes down casing of Latin characters. For ASCII labels there is already an equivalence between upper case and lower case letters. And this is what users, based on decades of experience, expect to happen. In an IDNA2003-compliant web browser it is expected that "EXÄMPEL" and "EXAMPLE" are equivalent to "exämpel" and "example", respectively. In an IDNA2008 browser "EXAMPLE" must be accepted, but "EXÄMPLE" could be rejected since "Ä" is not valid, but that is not how e.g. Mozilla Firefox and Apple Safari have been designed to handle the problem. They also do down case before the formal IDNA2008 process. Even though down casing is not part of the formal IDNA2008 process, one of the IDNA2008 documents, RFC 5894, states that the user interface of an application, before IDNA2008 processing, can do normalization. The down casing in IDNA2008 browsers should probably be seen in that light. While "TÄT" will probably be down cased to "tät" in the browser, what should the browser do with "TIT"? Depending on the locale that the browser is running in, it may be down cased to either "tit" or "tıt" (with or without the dot). The casing, in an application, is expected to go in one direction, from upper case to lower case. When domain names are presented in text, however, it is common that domain names are presented in upper or mixed case. So "ice" might become "Ice" or "İce". It is quite obvious from the text above that case shift of dotted or dotless I could create erroneous lookup, but the question is how large threat it would be to the users. Since the applications are expected to go from upper case to lower case, when they handle domain names, we should consider a situation where down casing could result in different lower case letters, i.e. when CAPITAL LETTER I is down cased. With a non-Turkish and non-Azeri locale, a Latin CAPITAL LETTER I in a domain name is either down cased to Latin Small Letter I (IDN label) or equivalent to Latin Small Letter I (ASCII label). With a Turkish or Azeri locale, a Latin Capital Letter I is expected to be down cased to Latin Small Letter Dotless I, but in an ASCII label in a domain name, it is still expected to be equivalent with Latin Small Letter I, because that is what the DNS standards says. There is an obvious risk that, in a Turkish or Azeri locale that the two letters are confused or mistreated due to the case folding, and this confusion could be misused. To be on the safe side Latin Small Letter I and Latin Small Letter Dotless I should be variants. Accordingly, the following variant set could be the optimal solution: Table D.10. Possible Variant Relationships for 0069 and 0131 Group Dotless i vs. i Target Source Variant Candidate [Yes/No] Disposition [Allocatable/ Blocked] Rationale Code Point Glyph Name Code Point Glyph Name 0069 i Latin Small Letter I 0131 ı Latin Small Letter Dotless I YES Blocked Risk of confusion due to inconsistent case folding 0131 ı Latin Small Letter Dotless I 0069 i Latin Small Letter I YES Blocked Risk of confusion due to inconsistent case folding

1 0

[Updated Zoom Link] Latin GP Meeting
by Pitinan Kooarmornpatana May 12, 2020

May 12, 2020

Dear Latin GP members, This is a gentle reminder for the Latin GP meetings on Thursday 14 May 2020 at 16:00UTC. Please join the meeting at the updated link: https://icann.zoom.us/j/95395839226?pwd=ZGxpYmRqV2E2NjloWTFHZWNGbkJWZz09 Password: 096517 Proposed Agenda: 1. Review the document Stability Issue: Locale-dependent Casefolding Latin Small Letter Dotless I and Latin Small Letter I<https://docs.google.com/document/d/11aads2CRTE7C_gpSejL8ltW2Z8fMNZXT2cWdT0y…> 2. Review and finalize the in-script variant excel sheet and its conclusion (the file is under preparation, will share during the meeting) Regards, Pitinan -------------- To join via phone, please find your local number at https://icann.zoom.us/u/aw6COk4xD Meeting ID: 953 9583 9226 Password: 096517

1 0