[Latingp] Latin Small Letter Sharp S (ß) U+00DF

[Mats Dufberg]

Dear all,


As I see it, we have concluded that there are special issues around Sharp S and that we should find the best solution around it.

We have identified four possible solutions given the restrictions given to us:

1. Excluding Sharp S from the repertoire. [NoIncl]
2. Making "ss" being a variant of Sharp S and "ss" being allocatable (variant the other way too, but maybe not allocatable). [Var1]
3. Making "ss" and Sharp S being blocked variants to each other. [Var2]
4. Including Sharp S in the repertoire with any variant rules. [NoVar]

For the selection of solution, we have identified three factors that we want to find the optimal mix of:

1. The risk for misconnection, i.e. the users reach a domain name under another TLD, should be minimized. [Mis]
2. If possible, all characters used for writing a language should be available for a TLD name. That is the goal for all languages that we have selected to support. [Inc]
3. The risk for failure of service, i.e. the users is redirected to something else that does not exist, should be minimized. [FoS]


If we then set some score on how well the solutions handle the factors, where 3 means handles it completely (good) and 0 not at all (bad), we get more or less the table that Michael Bauland sent a week ago (but somewhat modified here).

            NoIncl | Var1 | Var2 | NoVar
    Mis (1)  3     |  3   |   3  |  0
    Inc (2)  0     |  3   |   3  |  3
    FoS (3)  3     |  2   |   0  |  1


If Sharp S is excluded or included with variant rules there is no risk of misconnection (score 3). If it is included without variant rules there is risk of misconnections for users of e.g. Chrome (score 0).

If Sharp S is excluded, it will not be available for TLDs for German needs (score 0). If it is included (the other solutions) it is available (score 3).

Failure of Service is the most complex factor in terms of scoring.

If sharp S is excluded, it is never used for TLDs and no failure of service can occur for names under TLDs with Sharp S since they do not exist (score 3). If "ss" is a blocked variant of Sharp S users of Chrome and IE will experience failure of service (score 0).

If "ss" is an allocatable variant we may have no "FoS" if the variants are activated and all that (score 2).

If we Sharp S available without variant rules it is still, at least theoretically, but less likely, that the same Registry Operator get both TLDs, with Sharp S and with "ss" (score 1).

So my conlusion:

If Sharp S is included and let "ss" be a allocatable variant of it (Var1), then the problem of misconnection is handled completely, Sharp S will be available for the language that needs it and at least it will be possible to avoid the risk of failure of service. I think this is the best mix, the best solution.

*

The next question we should ask is how the different solutions will work if (when) Chrome and IE/Edge support IDNA 2008 fully (IE is deprecated, Edge is the replacement).

*

The upcoming two weeks I will be on vacation travelling. I might attend, but probably not.


Yours,
Mats


(I here use "include" and "exclude" instead of "defer". In our document we have used the terms "include" and "exclude". I see no reason why we should use other terminology here. There are code points in MSR that we have decided exclude - or not include - that could be included in the future. There is nothing special about Sharp S.)

---
Mats Dufberg
DNS Specialist
Internetstiftelsen (The Swedish Internet Foundation)
Mobile: +46 73 065 3899
https://internetstiftelsen.se/

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/latingp/attachments/20190816/71ca5bb4/attachment.html>