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

[Maxim Alzoba]

I think the procedure of the retirement needs to have a check for the existence of the primary and if not - election of the new one.

⁣Maxim Alzoba​

On Jul 26, 2022, 09:42, at 09:42, Michael Bauland <michael.bauland at knipp.de> wrote:
>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
>_______________________________________________
>Gnso-epdp-idn-team mailing list
>Gnso-epdp-idn-team at icann.org
>https://mm.icann.org/mailman/listinfo/gnso-epdp-idn-team
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mm.icann.org/pipermail/gnso-epdp-idn-team/attachments/20220726/4d11abcb/attachment.html>