Re: [Latingp] Summary of Latin GP Meeting on 2 July 2020
All, On the action item, I researched several papers about case insensitivity and case mapping, including https://tools.ietf.org/html/rfc5895 , https://tools.ietf.org/html/rfc8264#section-5.2.3, https://tools.ietf.org/html/rfc7790#section-2.3 which discusses the issue Turkish locale. What we found is that the application layer has solved the “local case mapping” issue by applying a context-free mapping, i.e. 0049 --> 0069, regardless of the user’s locale setting. Thus removing the ambiguity or stability issue when resolving domain names. Dennis From: Latingp <latingp-bounces@icann.org> on behalf of Pitinan Kooarmornpatana <pitinan.koo@icann.org> Date: Wednesday, July 8, 2020 at 2:46 PM To: "latingp@icann.org" <latingp@icann.org> Subject: [EXTERNAL] [Latingp] Summary of Latin GP Meeting on 2 July 2020 Dear All, Please find attached the summary of the Latin GP meeting on 2 July 2020. Please let us know if you would like to suggest any edits or additions. S. No. Action Items Owner 1 Research further to find the variant supporting rationale which is not linguistic based to avoid open up other concluded cases. DT The recording for this meeting, the updated presentation, and the note are posted at Latin GP wiki page at https://community.icann.org/display/croscomlgrprocedure/Latin+GP<https://secure-web.cisco.com/1EITQdd9WRhpV4MXmeqTx-W0Bl-qV5OBaS36VLdEyGPIg0rf7LuVnOnGIKA4ivnQAhb7wIW-A88aHpGMgnKM-ldaGEtZXcX6HvAmQyTgr5Dm6TdvGknOsPeTsu-iLC0fz_xzs84G6c_EEF6HrYcFg2Xnzq_l4XWmyQLxAQ49BHoW2zXwnV_J1iy9hiUspVAeR_AMbGgRl5HDFyRgNjloxnW11339UwvID8B7B2KUSIJ0Sb6aa2nxokrBsXR2hAHdsqc-mn9Nz8k603AYMUke6Yw/https%3A%2F%2Fcommunity.icann.org%2Fdisplay%2Fcroscomlgrprocedure%2FLatin%2BGP>. Regards, Pitinan
I'm not clear how thess relates to our issue. The RFCs deal with how the software should deal with converting upper to lower case. But our issue is how human beings will see things. That is, what they will expect that what they see will produce. It's real clear from our last two meetings that, for Turkish users, I vs Dotless I will be an issue. For them, even though their language has pairs of words which differ only by which letter is used, allowing two domain names like that is a problem. I believe the word used was "unacceptable." We can discuss whether to make such variants allocatable rather than blocked. (Which I incline against.) But I don't see that we can refuse to make them variants. Bill Jouris Sent from Yahoo Mail on Android On Wed, Jul 8, 2020 at 12:39 PM, Tan Tanaka, Dennis via Latingp<latingp@icann.org> wrote: _______________________________________________ Latingp mailing list Latingp@icann.org https://mm.icann.org/mailman/listinfo/latingp _______________________________________________ By submitting your personal data, you consent to the processing of your personal data for purposes of subscribing to this mailing list accordance with the ICANN Privacy Policy (https://www.icann.org/privacy/policy) and the website Terms of Service (https://www.icann.org/privacy/tos). You can visit the Mailman link above to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on.
Hi all, even though I usually side with Dennis, when it comes to creating variant relations (especially regarding similar/same looking characters), I have to agree with Bill in this point. The dotless I is only used in Turkish and Azerbaijan and we've heard from those communities (we might want to check with Azerbaijan, too, before making a final decision) that there is confusion: If a capital dotless I (i.e., "our" I) is used, it is not clear to them to which lower-case I this is referring. Sure, the browsers lowercase it to i, but many other computer software lowercases it to the dotless i. Even though this is not a stability issue, as Dennis said, the behaviour in DNS is well defined and stable, it is a security issue. Therefore I think they should be variants. Regarding the question whether they're blocked or allocatable, I'd vote for having dotless I -> I: allocatable I -> dotless I: blocked Cheers, 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@knipp.de Software Development E-mail: Michael.Bauland@knipp.de Register Court: Amtsgericht Dortmund, HRB 13728 Chief Executive Officers: Dietmar Knipp, Elmar Knipp
It is a fine line between solutions i.e. variant or no variant relationship, so I understand the disagreement. Re: The stability issue I was referring to would be one where the browsers behave in conformance to the user's locale settings. So for example, a user using a Turkish system goes to one website one day; another day the same user using a non-Turkish system (and using the same browser brand) types the same domain name but the browser resolved it to a different website, because the system locale was different. Browsers have solved for this issue, albeit at a cost for Turkish users. In my mind, since the DNS behavior is stable (due to the browser's implementation), then the only thing left is user expectation. The RZ-LGR should not cater to languages, otherwise all sort of user expectation behavior could be argued for inclusion. This is why I don't agree that a variant relationship is warranted. Again, it is a fine line. We can state all of the pros and cons and find some consensus, and move on. Dennis On 7/9/20, 4:20 AM, "Latingp on behalf of Michael Bauland" <latingp-bounces@icann.org on behalf of Michael.Bauland@knipp.de> wrote: Hi all, even though I usually side with Dennis, when it comes to creating variant relations (especially regarding similar/same looking characters), I have to agree with Bill in this point. The dotless I is only used in Turkish and Azerbaijan and we've heard from those communities (we might want to check with Azerbaijan, too, before making a final decision) that there is confusion: If a capital dotless I (i.e., "our" I) is used, it is not clear to them to which lower-case I this is referring. Sure, the browsers lowercase it to i, but many other computer software lowercases it to the dotless i. Even though this is not a stability issue, as Dennis said, the behaviour in DNS is well defined and stable, it is a security issue. Therefore I think they should be variants. Regarding the question whether they're blocked or allocatable, I'd vote for having dotless I -> I: allocatable I -> dotless I: blocked Cheers, 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@knipp.de Software Development E-mail: Michael.Bauland@knipp.de Register Court: Amtsgericht Dortmund, HRB 13728 Chief Executive Officers: Dietmar Knipp, Elmar Knipp _______________________________________________ Latingp mailing list Latingp@icann.org https://secure-web.cisco.com/1-bnZn6-Dr_lb-jmxFuKh32IcWZWqRzjuk1ySIqN07HMzjf... _______________________________________________ By submitting your personal data, you consent to the processing of your personal data for purposes of subscribing to this mailing list accordance with the ICANN Privacy Policy (https://secure-web.cisco.com/1lkgMlbb5K8XJ2GM2RiJXRpcjzDzNvFK4Ek8O4UNBWbMyXc...) and the website Terms of Service (https://secure-web.cisco.com/1HPr3HlZA0YZxu0pFpzYRaI22Oe-VYEY1rTNFWcfYJ3Y98f...). You can visit the Mailman link above to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on.
Hi Dennis, You say "The RZ-LGR should not cater to languages, otherwise all sort of user expectation behavior could be argued for inclusion." Yet catering to a specific language and its users is precisely the rationalization we used when deciding that glyphs with multiple diacritics used in Vietnamese should not be variants. Even though, in the test we use otherwise (whether *we* can tell them apart), they would be. Bill Sent from Yahoo Mail on Android On Thu, Jul 9, 2020 at 7:54 AM, Tan Tanaka, Dennis via Latingp<latingp@icann.org> wrote: It is a fine line between solutions i.e. variant or no variant relationship, so I understand the disagreement. Re: The stability issue I was referring to would be one where the browsers behave in conformance to the user's locale settings. So for example, a user using a Turkish system goes to one website one day; another day the same user using a non-Turkish system (and using the same browser brand) types the same domain name but the browser resolved it to a different website, because the system locale was different. Browsers have solved for this issue, albeit at a cost for Turkish users. In my mind, since the DNS behavior is stable (due to the browser's implementation), then the only thing left is user expectation. The RZ-LGR should not cater to languages, otherwise all sort of user expectation behavior could be argued for inclusion. This is why I don't agree that a variant relationship is warranted. Again, it is a fine line. We can state all of the pros and cons and find some consensus, and move on. Dennis On 7/9/20, 4:20 AM, "Latingp on behalf of Michael Bauland" <latingp-bounces@icann.org on behalf of Michael.Bauland@knipp.de> wrote: Hi all, even though I usually side with Dennis, when it comes to creating variant relations (especially regarding similar/same looking characters), I have to agree with Bill in this point. The dotless I is only used in Turkish and Azerbaijan and we've heard from those communities (we might want to check with Azerbaijan, too, before making a final decision) that there is confusion: If a capital dotless I (i.e., "our" I) is used, it is not clear to them to which lower-case I this is referring. Sure, the browsers lowercase it to i, but many other computer software lowercases it to the dotless i. Even though this is not a stability issue, as Dennis said, the behaviour in DNS is well defined and stable, it is a security issue. Therefore I think they should be variants. Regarding the question whether they're blocked or allocatable, I'd vote for having dotless I -> I: allocatable I -> dotless I: blocked Cheers, 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@knipp.de Software Development E-mail: Michael.Bauland@knipp.de Register Court: Amtsgericht Dortmund, HRB 13728 Chief Executive Officers: Dietmar Knipp, Elmar Knipp _______________________________________________ Latingp mailing list Latingp@icann.org https://secure-web.cisco.com/1-bnZn6-Dr_lb-jmxFuKh32IcWZWqRzjuk1ySIqN07HMzjf... _______________________________________________ By submitting your personal data, you consent to the processing of your personal data for purposes of subscribing to this mailing list accordance with the ICANN Privacy Policy (https://secure-web.cisco.com/1lkgMlbb5K8XJ2GM2RiJXRpcjzDzNvFK4Ek8O4UNBWbMyXc...) and the website Terms of Service (https://secure-web.cisco.com/1HPr3HlZA0YZxu0pFpzYRaI22Oe-VYEY1rTNFWcfYJ3Y98f...). You can visit the Mailman link above to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on. _______________________________________________ Latingp mailing list Latingp@icann.org https://mm.icann.org/mailman/listinfo/latingp _______________________________________________ By submitting your personal data, you consent to the processing of your personal data for purposes of subscribing to this mailing list accordance with the ICANN Privacy Policy (https://www.icann.org/privacy/policy) and the website Terms of Service (https://www.icann.org/privacy/tos). You can visit the Mailman link above to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on.
Some of us suggested Vietnamese characters can be confused with other characters (i.e. visual similarity case). These arguments were not strong enough on their own. The language reality was brought up to validate that such motivations did not have merit. From: Bill Jouris <b_jouris@yahoo.com> Reply-To: "b_jouris@yahoo.com" <b_jouris@yahoo.com> Date: Thursday, July 9, 2020 at 11:26 AM To: Dennis Tan Tanaka <dtantanaka@verisign.com>, "Tan Tanaka, Dennis via Latingp" <latingp@icann.org>, "Michael.Bauland@knipp.de" <Michael.Bauland@knipp.de>, "latingp@icann.org" <latingp@icann.org> Subject: [EXTERNAL] Re: [Latingp] Summary of Latin GP Meeting on 2 July 2020 Hi Dennis, You say "The RZ-LGR should not cater to languages, otherwise all sort of user expectation behavior could be argued for inclusion." Yet catering to a specific language and its users is precisely the rationalization we used when deciding that glyphs with multiple diacritics used in Vietnamese should not be variants. Even though, in the test we use otherwise (whether *we* can tell them apart), they would be. Bill Sent from Yahoo Mail on Android<https://secure-web.cisco.com/1HhS9pa-_8bY2kguxXn1fM3ediRtr0LLrcw3wVCioD55nYN...> On Thu, Jul 9, 2020 at 7:54 AM, Tan Tanaka, Dennis via Latingp <latingp@icann.org> wrote: It is a fine line between solutions i.e. variant or no variant relationship, so I understand the disagreement. Re: The stability issue I was referring to would be one where the browsers behave in conformance to the user's locale settings. So for example, a user using a Turkish system goes to one website one day; another day the same user using a non-Turkish system (and using the same browser brand) types the same domain name but the browser resolved it to a different website, because the system locale was different. Browsers have solved for this issue, albeit at a cost for Turkish users. In my mind, since the DNS behavior is stable (due to the browser's implementation), then the only thing left is user expectation. The RZ-LGR should not cater to languages, otherwise all sort of user expectation behavior could be argued for inclusion. This is why I don't agree that a variant relationship is warranted. Again, it is a fine line. We can state all of the pros and cons and find some consensus, and move on. Dennis On 7/9/20, 4:20 AM, "Latingp on behalf of Michael Bauland" <latingp-bounces@icann.org<mailto:latingp-bounces@icann.org> on behalf of Michael.Bauland@knipp.de<mailto:Michael.Bauland@knipp.de>> wrote: Hi all, even though I usually side with Dennis, when it comes to creating variant relations (especially regarding similar/same looking characters), I have to agree with Bill in this point. The dotless I is only used in Turkish and Azerbaijan and we've heard from those communities (we might want to check with Azerbaijan, too, before making a final decision) that there is confusion: If a capital dotless I (i.e., "our" I) is used, it is not clear to them to which lower-case I this is referring. Sure, the browsers lowercase it to i, but many other computer software lowercases it to the dotless i. Even though this is not a stability issue, as Dennis said, the behaviour in DNS is well defined and stable, it is a security issue. Therefore I think they should be variants. Regarding the question whether they're blocked or allocatable, I'd vote for having dotless I -> I: allocatable I -> dotless I: blocked Cheers, 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@knipp.de<mailto:Michael.Bauland@knipp.de> Software Development E-mail: Michael.Bauland@knipp.de<mailto:Michael.Bauland@knipp.de> Register Court: Amtsgericht Dortmund, HRB 13728 Chief Executive Officers: Dietmar Knipp, Elmar Knipp _______________________________________________ Latingp mailing list Latingp@icann.org<mailto:Latingp@icann.org> https://secure-web.cisco.com/1-bnZn6-Dr_lb-jmxFuKh32IcWZWqRzjuk1ySIqN07HMzjf... _______________________________________________ By submitting your personal data, you consent to the processing of your personal data for purposes of subscribing to this mailing list accordance with the ICANN Privacy Policy (https://secure-web.cisco.com/1lkgMlbb5K8XJ2GM2RiJXRpcjzDzNvFK4Ek8O4UNBWbMyXc...) and the website Terms of Service (https://secure-web.cisco.com/1HPr3HlZA0YZxu0pFpzYRaI22Oe-VYEY1rTNFWcfYJ3Y98f...). You can visit the Mailman link above to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on. _______________________________________________ Latingp mailing list Latingp@icann.org<mailto:Latingp@icann.org> https://mm.icann.org/mailman/listinfo/latingp<https://secure-web.cisco.com/1S3UeGMnOlR8rw9jzkfxpMkJk5ZciIbMVllSPj6tIvmsYv0kzwOE7LjHQpOQNWYRCDU6jRXavFY3qoFDmoJ0xvun2dKNKOMsomGO-M8lOM8ken-Bba6PvR9xoUIumGi4lXG5o36pzLW6kEXkhj0gAyoIxwiSppOh1GhaFdiGSEbDJEEA3S1AEtYxkITuHP37LbdBtQaSLBvDUxd-mQ-rCK3bpWHP2-z1_fzFae8eX9N4uBuKWjRKcdsRFI8gz1JlriqmZVuconSfEXyIOewMmhg/https%3A%2F%2Fmm.icann.org%2Fmailman%2Flistinfo%2Flatingp> _______________________________________________ By submitting your personal data, you consent to the processing of your personal data for purposes of subscribing to this mailing list accordance with the ICANN Privacy Policy (https://www.icann.org/privacy/policy<https://secure-web.cisco.com/1zSgoIij9pyvI4xafn8iyvI7B86u-K02rzb3i3JlVFW2qAzRxbsi8LAiYopaGDma49C7f3HRfYL9dBOLIWMyJrusSoW5CykrOil12_Xo6x-xr_ukNEDEB_eUFWYy9hDKnoKjybaqpxNyNC_yhWTX1nxMs_SzDjn481ZlYN2cn7eKMavhcl3D__tkHPD3JRYn05Kzf-UcG4T4t-M36W9Aw0mRgUbi6aANjPfnvqAvOnXOAvSOyBUkjbvjA5Obww2Ki6U83CYdNh3CDukahSw_tdw/https%3A%2F%2Fwww.icann.org%2Fprivacy%2Fpolicy>) and the website Terms of Service (https://www.icann.org/privacy/tos<https://secure-web.cisco.com/1aOQKZjQ7rFUtBeNqt_qXA01D_CvREqoFE6jTY37qfNinuLngsfS0hByGE5WpBgpg7UtUtH7nK9WyS8g3ORxlGSq4CAMbJu0mAvez0voCqTehLknXFohWywN9B7krmdmYEHHpFxq2q-3dN-v_shp6eJE5_pTdhkZlsvmhBxXYK9a3X2zXpEZRfhj4HGtOZ0MHpkRNfoy-2zh7KacJmfbXulB6e2ExAlMFApLaMA2oszAMqKXn36-JAjkFzRqQyvH_WOeuefJJ24rxzmmLohQvfg/https%3A%2F%2Fwww.icann.org%2Fprivacy%2Ftos>). You can visit the Mailman link above to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on.
I do not think that this is more "language" then other considerations that we have done, eg. f and f with a tail. Mats --- Mats Dufberg mats.dufberg@internetstiftelsen.se Technical Expert Internetstiftelsen (The Swedish Internet Foundation) Mobile: +46 73 065 3899 https://internetstiftelsen.se/ -----Original Message----- From: Latingp <latingp-bounces@icann.org> on behalf of ICANN Latin GP <latingp@icann.org> Reply to: "Tan Tanaka, Dennis" <dtantanaka@verisign.com> Date: Thursday, 9 July 2020 at 16:54 To: "Michael.Bauland@knipp.de" <Michael.Bauland@knipp.de>, ICANN Latin GP <latingp@icann.org> Subject: Re: [Latingp] Summary of Latin GP Meeting on 2 July 2020 It is a fine line between solutions i.e. variant or no variant relationship, so I understand the disagreement. Re: The stability issue I was referring to would be one where the browsers behave in conformance to the user's locale settings. So for example, a user using a Turkish system goes to one website one day; another day the same user using a non-Turkish system (and using the same browser brand) types the same domain name but the browser resolved it to a different website, because the system locale was different. Browsers have solved for this issue, albeit at a cost for Turkish users. In my mind, since the DNS behavior is stable (due to the browser's implementation), then the only thing left is user expectation. The RZ-LGR should not cater to languages, otherwise all sort of user expectation behavior could be argued for inclusion. This is why I don't agree that a variant relationship is warranted. Again, it is a fine line. We can state all of the pros and cons and find some consensus, and move on. Dennis On 7/9/20, 4:20 AM, "Latingp on behalf of Michael Bauland" <latingp-bounces@icann.org on behalf of Michael.Bauland@knipp.de> wrote: Hi all, even though I usually side with Dennis, when it comes to creating variant relations (especially regarding similar/same looking characters), I have to agree with Bill in this point. The dotless I is only used in Turkish and Azerbaijan and we've heard from those communities (we might want to check with Azerbaijan, too, before making a final decision) that there is confusion: If a capital dotless I (i.e., "our" I) is used, it is not clear to them to which lower-case I this is referring. Sure, the browsers lowercase it to i, but many other computer software lowercases it to the dotless i. Even though this is not a stability issue, as Dennis said, the behaviour in DNS is well defined and stable, it is a security issue. Therefore I think they should be variants. Regarding the question whether they're blocked or allocatable, I'd vote for having dotless I -> I: allocatable I -> dotless I: blocked Cheers, 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@knipp.de Software Development E-mail: Michael.Bauland@knipp.de Register Court: Amtsgericht Dortmund, HRB 13728 Chief Executive Officers: Dietmar Knipp, Elmar Knipp _______________________________________________ Latingp mailing list Latingp@icann.org https://secure-web.cisco.com/1-bnZn6-Dr_lb-jmxFuKh32IcWZWqRzjuk1ySIqN07HMzjf... _______________________________________________ By submitting your personal data, you consent to the processing of your personal data for purposes of subscribing to this mailing list accordance with the ICANN Privacy Policy (https://secure-web.cisco.com/1lkgMlbb5K8XJ2GM2RiJXRpcjzDzNvFK4Ek8O4UNBWbMyXc...) and the website Terms of Service (https://secure-web.cisco.com/1HPr3HlZA0YZxu0pFpzYRaI22Oe-VYEY1rTNFWcfYJ3Y98f...). You can visit the Mailman link above to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on. _______________________________________________ Latingp mailing list Latingp@icann.org https://mm.icann.org/mailman/listinfo/latingp _______________________________________________ By submitting your personal data, you consent to the processing of your personal data for purposes of subscribing to this mailing list accordance with the ICANN Privacy Policy (https://www.icann.org/privacy/policy) and the website Terms of Service (https://www.icann.org/privacy/tos). You can visit the Mailman link above to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on.
participants (5)
-
Bill Jouris -
Bill Jouris -
Mats Dufberg -
Michael Bauland -
Tan Tanaka, Dennis