[Gnso-epdp-idn-team] primary labels and consequences of retiring them

[Michael Bauland]

Hi Dennis,

On 25.07.2022 21:46, Tan Tanaka, Dennis via Gnso-epdp-idn-team wrote:
> A few additional comments on 2.3 re: use of “primary label”
> 
>   * Some questions I reckon we will face throughout: what is the
>     “primary” label? what function does it serve? should we use such
>     nomenclature? … some background notes:
>   * When we talk about variants in a set, it is important to note which
>     of all labels is the source for variant label calculation, or as we
>     have adopted: the primary label. As a way of context, first, the
>     variant relationship between two code points must satisfy the
>     symmetrical property (there are other properties, but not relevant
>     to this topic). This means, if ‘A’ is a variant of ‘B’, then ‘B’ is
>     a variant of ‘A’. Second, any variant relationship is also assigned
>     a disposition value: allocatable or blocked. The disposition value
>     is unidirectional. Which means, a variant relationship could yield
>     an ‘allocatable’ variant in one direction (e.g., AàB: allocatable),
>     but a ‘blocked’ variant in the other direction (e.g., BàA: blocked).
>     These rules are encoded in the LGR.
>   * As we progress in our deliberations about the lifecycle of gTLDs it
>     is important to understand (and remember) how the various variant
>     labels and disposition values came to be (to discern which ones are
>     allocatable/withheld or blocked). However, I believe we need to
>     remain open (or at least give thoughtful consideration) to cases
>     where one TLD label in the set needs to be handled separately e.g.,
>     retirement, and the implications of this one change applies to the
>     rest of the labels in the set. For instance, what if the registry
>     operator wants to retire the “primary” label and continue to operate
>     the rest of variants. In this case, it would be unwise, perhaps, to
>     re-assign the attribute of “primary” to another label in the set,
>     because that might change the profile of the set as a whole (of
>     course, this would depend what “primary” means and how it is used).

This is a very good point. Especially with asymmetric disposition we 
have a real problem if a primary label is retired and the other variants 
are kept. There might arise a situation in which none of the remaining 
variants can be made primary, because it would entail one of the other 
existing variants to become blocked instead of allocatable.

The question would then be
* Do we allow a variant set to exist without a primary label?
* Will retiring a primary label require the registry to select another 
primary label and thereby possibly force them to retire other variants 
together with the former primary label?

Take the following quite simple example.
Applied for primary label: bıß
Allocatable Variants: biß, bıss, biss

So, someone might have all four labels in the Root zone at some point.

If they now retire the primary label bıß, the other three labels could 
not exist at the time (without bıß also existing).

Case 1:
biß is made new primary
Consequence: bıss becomes a blocked variant.

Case 2:
bıss is made new primary
Consequence: biß becomes a blocked variant.

Case 3:
biss is made a new primary
Consequence: both bıss and biß become blocked variants.


Even though the example is not very likely, it's certainly possible and 
in other scripts might be similar examples that are more likely.


So, to summarise my points:
* Initially, we need a primary label to determine the disposition value 
of all variants.
* Retiring a primary label may cause problems and we need to decide how 
to deal with these problems.

Best regards,

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 at knipp.de
      Software Development        E-mail: Michael.Bauland at knipp.de

                                  Register Court:
                                  Amtsgericht Dortmund, HRB 13728

                                  Chief Executive Officers:
                                  Dietmar Knipp, Elmar Knipp