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
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-jmxFuKh32IcWZWqRzjuk1ySIqN07HMzjfpNElshtWzSkI9ucp3ce87uXhg3dFoDnQBH-wJA15VZBmg6g0kC_gXcnZuk9nxWJOMwLRZY6A_R9YOpD1MHAtF813GYxFgLg2vn2JJHxTPWeup8lcuEKocJCHSgnd7x5nDRvIs5MNTV29o3wndBce-lbHiHnTd92ZqePgp5x-_ANonD1eXLfVN5sMGry_pcyDr1ROIqLxcxanIz2cvQp1CFqJpgXqzI-XpQWoGKJQ/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://secure-web.cisco.com/1lkgMlbb5K8XJ2GM2RiJXRpcjzDzNvFK4Ek8O4UNBWbMyXcSUeDBasUhmpzT84yc-2a7zPz4F_U2GociyufyKCi8yQAdeTUX9I8hj2qxIAJ0wqfBH9vK0Ng-EDJ0mDkJo7DsJtxVxQ6788XHrcXPfF8DDwUcTbodGU0rKGFglS5Gh8R9zOko-WGL5EH8nbeEsfHaDrIqDEGj_w7pHSpk7m7-pxcsUmU2RKOx2_Xj1NbuOulWe29KrY5rATEg9li9w3tyJFzgl5tSMndpL3cGtJw/https%3A%2F%2Fwww.icann.org%2Fprivacy%2Fpolicy) and the website Terms of Service (https://secure-web.cisco.com/1HPr3HlZA0YZxu0pFpzYRaI22Oe-VYEY1rTNFWcfYJ3Y98f-gIxhM-XDmVsH3ClE1bpf9eIBvEnM7JFIwPKyWSR36bpE4WePqQ-B_S9IhzOGRYVkGs3a15BBN6OA1_vYdS3Y7qoUJttzmhZxjRMzgirT_HMJ5qh3nYClfRm5fa0EiGU-00GyeFwmaSgIcpJM6-mXIBpGBdKFVm9MkXAbVB4tSjSsgX4-Ow5wJiVzSt1sLgIMP9uvvQ02G3sy4yN0TuwXyyMAD3itdrfkuDGUUuw/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.
_______________________________________________
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.