Résumé

  • RFC 3743 regroupe certaines variantes de caractères chinois, japonais et coréens dans un paquet administratif lié à un titulaire unique.
  • Les variantes dites préférées sont normalement activées dans la zone ; d’autres sont réservées sans nécessairement devenir des noms DNS actifs. Le document ne prouve ni l’adoption d’une table par un registre ni la résolution d’un nom.

Une étiquette visible, plusieurs formes administrées

L’enregistrement d’un nom de domaine semble souvent porter sur une seule chaîne : si elle est libre, un demandeur l’obtient et le registre peut la publier. Les noms internationalisés compliquent ce modèle. En chinois, japonais et coréen, des points de code distincts peuvent paraître identiques, partager une interprétation ou être considérés comme des variantes dans une langue ou une région donnée. Le DNS compare des étiquettes encodées ; il ne décide pas quelles formes devraient appartenir au même titulaire.

C’est la séparation visée par les lignes directrices du Joint Engineering Team dans RFC 3743, document informationnel publié en avril 2004. Les participants venaient notamment des communautés d’information réseau de Chine, de Taïwan, de Corée et du Japon. La note de l’IESG salue la façon dont JET relie une politique à un mécanisme d’application, tout en précisant que l’IETF ne dicte pas les politiques des zones. Le même format de table peut donc soutenir des décisions locales différentes.

Ce mécanisme n’est pas un nouvel algorithme de conversion Unicode vers ASCII. Les textes IDNA antérieurs définissaient la préparation et l’encodage des chaînes destinées au DNS. RFC 3743 traite plutôt de leur administration : une zone peut considérer certaines formes comme suffisamment liées pour qu’elles ne soient pas enregistrées par des titulaires différents. Un profil de protocole peut vérifier la validité technique d’une chaîne ; il ne tranche pas à lui seul les équivalences de toutes les communautés linguistiques.

La table transforme une politique linguistique en procédure

Pour chaque langue utilisée dans une zone, une Language Variant Table (LVT) décrit les points de code valides, les variantes préférées et les variantes de caractères. Ces catégories définissent un traitement administratif, pas une hiérarchie universelle entre écritures ni la promesse que chaque chaîne générée forme un mot courant.

À l’inscription, la chaîne proposée passe d’abord par Nameprep, dans le cadre IDNA de l’époque. Le registre vérifie les caractères au regard de chaque langue associée à la demande. Il génère ensuite des combinaisons de variantes, supprime les doublons et compare les étiquettes candidates aux noms déjà enregistrés ou réservés. La zone peut filtrer les formes qu’elle juge inappropriées. Unicode ne fournit pas ces décisions : elles viennent des tables et des procédures locales.

La distinction déterminante sépare activation et réservation. L’étiquette demandée et, normalement, les variantes préférées admissibles sont activées et placées dans le fichier de zone. Les variantes de caractères restent en général réservées : un autre demandeur ne peut pas les prendre, mais elles ne sont pas pour autant publiées comme étiquettes actives. RFC 3743 appelle « paquet IDL » l’ensemble formé par l’étiquette initiale, ses langues, ses variantes activées et ses variantes réservées.

Le paquet change l’unité de gestion. Dans le modèle traditionnel, inscription, suppression et transfert sont effectués étiquette par étiquette. Ici, le paquet est atomique : le transfert ou la suppression de l’IDL affecte toutes ses variantes associées. Cette règle évite que deux titulaires obtiennent des formes que la zone a choisi de relier. Elle signifie aussi qu’une transaction peut comprendre des chaînes absentes du DNS actif.

Les exemples du RFC montrent que la langue associée à une demande compte. Une chaîne peut être valide dans plusieurs tables et produire des variantes préférées différentes ; elle peut aussi échouer si un point de code n’est pas admis dans l’une des langues sélectionnées. Ce sont des exemples d’algorithme, pas la preuve qu’un registre nommé a adopté la table ni qu’un domaine commercial a été enregistré de cette façon.

Les limites de l’objet réservé

RFC 3743 laisse des choix essentiels à chaque zone : tables, langues, règles de conflit, nombre acceptable de variantes et partage des tâches entre bureau d’enregistrement et registre. Les exemples supposent parfois une priorité au premier arrivé, mais le texte permet de remplacer cette hypothèse par la politique locale de droits ou de litige. Il ne prouve ni les droits juridiques sur un nom, ni l’activation d’un paquet, ni l’insertion d’une étiquette ASCII dans une zone, ni le succès d’une requête DNS.

Les textes IDNA2008 aident à tracer la frontière ultérieure : ils établissent des règles techniques de validité et de traitement, tout en reconnaissant que les registres peuvent imposer des restrictions locales. Cette continuité ne transforme pas les algorithmes de l’époque IDNA2003 de RFC 3743 en règles de protocole actuelles. Elle ne rend pas non plus universelle la table linguistique de JET. Validation, politique de registre, inscription, publication dans la zone et résolution sont des preuves distinctes.

La contribution historique est une architecture administrative. JET n’a pas tenté d’encoder chaque jugement d’équivalence CJK dans le protocole DNS. L’équipe a donné aux zones un moyen d’exprimer localement ces choix et d’associer les variantes à un même titulaire. Cela réduit un risque de partage de formes entre titulaires, mais crée une autre dépendance : la table linguistique et les règles de cycle de vie deviennent partie intégrante de l’objet acquis. Le nom visible peut n’être qu’une étiquette ; l’ensemble réservé est plus vaste.

Sources