Summary

  • La chaîne IDN principale est la racine de dépendance de l’évaluation : sa disqualification entraîne celle de toutes les variantes associées.
  • Une variante demandée qui est disqualifiée suit une autre voie : son retrait par une Application Change Request qui aboutit peut permettre à la chaîne principale et aux variantes restantes qui ne sont pas disqualifiées de continuer.

Les Root Zone Label Generation Rules ne produisent pas simplement des graphies alternatives. Elles calculent le variant-string-set d’une chaîne principale et attribuent à chaque variante le statut contrôlé « allocatable » ou « blocked ». Le candidat peut demander une variante allocatable, mais pas une variante blocked. La chaîne principale détermine donc à la fois l’ensemble disponible et l’architecture d’évaluation de la candidature.

Pour un nouvel IDN au cours du même cycle, la chaîne principale et les variantes allocatable demandées sont déposées dans une seule candidature. Après une évaluation concluante, elles sont attribuées au même opérateur de registre dans le cadre d’un seul Registry Agreement. Ce dépôt commun ne signifie pas que chaque chaîne dispose de la même indépendance.

La section 7.6.3 fixe le premier sens de la dépendance. Si la chaîne IDN principale demandée est disqualifiée, quelle qu’en soit la raison, toutes les variantes associées le sont également et l’ensemble de la candidature ne peut pas poursuivre son parcours. Une variante ne peut donc pas sauver une candidature dont la chaîne principale a échoué.

Le sens inverse est plus limité. Si une variante demandée est disqualifiée, le candidat doit déposer une Application Change Request afin de la retirer. Si cette demande aboutit, la chaîne principale et les variantes restantes qui ne sont pas disqualifiées peuvent continuer. La variante en échec est donc amovible, mais son retrait constitue une étape de procédure obligatoire et non une correction automatique.

Le dépôt fixe aussi la limite extérieure de l’ensemble. Par la suite, un candidat peut retirer une variante demandée au moyen d’une Application Change Request, mais il ne peut pas ajouter une variante allocatable absente de la candidature initiale. Chaque variante demandée doit en outre faire l’objet d’une justification de sa nécessité portant sur le sens de la chaîne, sa reconnaissance par la communauté d’utilisateurs visée, ses bénéfices et les communautés qui en bénéficieront.

BTW recommande de tenir un registre de dépendance comprenant une ligne pour la chaîne principale et une pour chaque variante demandée, avec le statut RZ-LGR, la justification, le résultat de l’évaluation et toute Application Change Request. Il s’agit d’un conseil éditorial et non d’une exigence de l’ICANN.

Sources