Mon blog

Une fois définie une norme pour les noms de domaines internationalisés, il reste à régler quelques problèmes liés à leur enregistrement. Par exemple, le chinois s'écrit couramment avec deux écritures, la traditionnelle et la simplifiée. Faut-il permettre l'enregistrement de deux noms de domaines identiques, ne se différenciant que par cette écriture ? Notre RFC propose un cadre pour spécifier de telles règles et crée la notion de lot (package), un ensemble de domaines qu'IDN considérerait différents mais que le registre préfère traiter comme équivalents, et ne pouvant donc faire l'objet que d'un seul enregistrement.

IDN, normalisé dans le RFC 3490 , permet d'exprimer des noms de domaine en Unicode. Une canonicalisation est effectuée par le mécanisme nameprep (RFC 3491) et certaines chaînes de caractères Unicode (commme Straße et strasse) sont donc identiques pour nameprep. Il ne peut donc y avoir qu'un seul nom de domaine pour ces deux chaînes.

Mais d'autres chaînes Unicode sont considérées comme distinctes par nameprep, et donc peuvent être enregistrées séparément, alors qu'un locuteur de telle ou telle langue pourrait les voir comme identiques. C'est le cas de deux mots en chinois en écriture traditionnelle ou simplifiée, par exemple. De même, en français, certains pourraient considérer que congres et congrès doivent être considérés comme identiques, car ne se différenciant que par un accent.

Notre RFC, qui n'a pas le statut de norme, n'essaie pas de décrire une telle politique pour toutes les langues du monde. Il fournit simplement un cadre permettant de décrire de telles politiques, en mettant l'accès sur les questions spécifiques des langues asiatiques, souvent désignées par le sigle CJC. Il a été co-écrit par les registres de noms de domaine de Chine, de Taïwan, de Corée et du Japon, regroupés dans une structure ad-hoc, le JET. Le RFC 4290 étendra ensuite cette méthode aux autres écritures du monde.

Avant de voir la technique, il est bon de se rappeler que l'IETF n'a aucune légitimité pour décider des politiques d'enregistrement suivies dans .tw ou .kr. Il ne peut s'agir ici que de recommandations, telles qu'exprimées dans la note de l'IESG qui précède le RFC, qui incite les autres registres à suivre le même chemin, en rappelant (à regret ?) que l'IESG ne peut pas les y obliger.

En quoi consiste le mécanisme de ce RFC ? Simplement en la définition d'une table des variantes de chaque caractère (sections 2.1.11 et 3.2.1). Toute chaîne peut donc être canonicalisée en étant réduite à la variante préférée (section 2.1.13). Les chaînes qui ont la même forme canonique font partie du même lot (package, section 2.1.18, nommé bundle dans le RFC 4290) et ne peuvent donc pas faire l'objet d'enregistrements distincts. Seule la variante préférée est enregistrée. Les autres sont réservées.

La section 3 du RFC détaille ce mécanisme et traite de certains cas particuliers, comme la suppression d'un nom de domaine (section 3.3).

Appliqué au français, avec une table de variantes telle que celle proposée pour .fr, cette méthode ferait de congres et congrès, mais aussi de côngrës et congrês les membres d'un même lot.

Notre RFC ne répond pas à la question posée plus haut sur l'équivalence des écritures chinoises traditionnelles et simplifiées. Comme expliqué en section 4, cette tâche est laissé à des tables de variantes, dont certaines sont déposées sur le registre (non obligatoire) de l'IANA.

La section 5 du RFC décrit une proposition de syntaxe pour les tables de variantes, qui sera reprise dans le RFC 4290.