[Latingp] Latin Small Letter Sharp S (ß) U+00DF
Tan Tanaka, Dennis
dtantanaka at verisign.com
Thu Aug 22 15:08:54 UTC 2019
That’s a big “if”. With no plans in sight for Chrome to fully comply with IDNA2008, I don’t believe we can factor that in. What we should factor in is that 55%<https://gs.statcounter.com/browser-market-share/all/germany> of the end-users in Germany today (the most likely market) cannot reliably use a domain name using 00DF because they are redirected to another domain name.
Browser market share data point https://gs.statcounter.com/browser-market-share/all/germany
From: Latingp <latingp-bounces at icann.org> on behalf of Meikal Mumin <meikal at mumin.de>
Date: Thursday, August 22, 2019 at 10:53 AM
To: Bill Jouris <bill.jouris at insidethestack.com>, Latin GP <latingp at icann.org>, Mats Dufberg <mats.dufberg at internetstiftelsen.se>
Subject: [EXTERNAL] Re: [Latingp] Latin Small Letter Sharp S (ß) U+00DF
In the light of Mats response, I wanted to point out again that the ecosystem of browsers is shrinking, and that Microsoft switched to Chromium as engine for Edge, and thererefore if the issue will be fixed in Chromium it will be presumably be fixed in Edge as well.
Am 22. Aug. 2019, 3:46 PM +0200 schrieb Mats Dufberg <mats.dufberg at internetstiftelsen.se>:
It seems like we have to accept that the IDNA 2003 behavior will stay for quite some time. Besides Chrome and IE, which predates the release of IDNA 2008, even Microsoft Edge, which is a new web browser has the IDNA 2003 behavior on Sharp S.
Users of those browsers will not be able to reach domain names under a TLD with sharp S unless there is an activated variant with double S. I really think that is a significant problem. I think we agree that the behavior of those browsers is unwanted, but I am not sure that we should consider it to be a bug that will be fixed.
Internetstiftelsen (The Swedish Internet Foundation)
Mobile: +46 73 065 3899
From: Latingp <latingp-bounces at icann.org> on behalf of Bill Jouris <bill.jouris at insidethestack.com>
Reply to: Bill Jouris <bill.jouris at insidethestack.com>
Date: Monday, 19 August 2019 at 15:32
To: ICANN Latin GP <latingp at icann.org>
Subject: [Latingp] Latin Small Letter Sharp S (ß) U+00DF
I had a couple of thoughts over the weekend.
First, I think that in order to make progress we need to unpack our analysis a little. In particular, we need to consider each option, for both misconnection and failure of connection, separately for IDNA 2003 and for IDNA 2008. Then we will have the information in front of us to decide how much of a problem we have.
For example, consider Option 2 (Sharp S and double S as blocked variants). (For this discussion, assume a TLD using the Sharp S exists. Thus the TLD which only differs by having a double S is blocked.) If the user enters a valid domain name using the Sharp S, on a browser which uses IDNA 2003, the browser converts it to double s before going to the DNS. The DNS doesn't find the name, and so the connection fails. Whereas a browser with IDNA 2008 goes to the DNS with the correct name, and the connection succeeds.
Does this constitute a change of behavior? Absolutely. But is this change, "instability" if you will, a significant problem? I would suggest that it is not. To call it a significant problem is to argue that bugs should not be fixed. A bug fix, after all, necessarily results in a change of behavior; that is its whole purpose. Back-level software (which IDNA 2003 is) will always give problematic results. That's why we upgrade.
Certainly an ideal solution will have no misconnection under either level of IDNA, and no failed connection when the user enters a valid domain name. But unless we find such a paragon, we will need to find the "least bad" solution. And having this additional data in front of us will help with that.
Second, I want to comment on the Option for Sharp S and double S with no variant relationship. I have a question for those who are more fluent in German than I -- which is most of you. Are there any examples of two different German words which are identical except that one is rendered with a Sharp S and the other is rendered strictly with a double S?
It seems to me that, unless there are, a "not variant" judgement is unsustainable and the option should be rejected out of hand. Regardless of what this analysis might find.
bill.jouris at insidethestack.com
Latingp mailing list
Latingp at icann.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Latingp