La norme pour les noms de domaine en
Unicode, dite « IDNA 2008 », prévoit une révision à
chaque nouvelle version d'Unicode pour
éventuellement s'adapter à des changements dus à ces nouvelles
versions. Ce processus de révision a pas mal cafouillé (euphémisme),
et ce RFC doit
donc traiter d'un coup les versions 6 à 12
d'Unicode.
Le fond du problème est que l'ancienne norme sur les IDN (RFC 3490) était strictement liée à une version
donnée d'Unicode et qu'il fallait donc une
nouvelle norme pour chacune des versions annuelles d'Unicode. Vu le
processus de publication d'une norme à l'IETF, ce n'était pas
réaliste. La seconde norme IDN, « IDN
2 » ou « IDN 2008 » (bien qu'elle soit sortie en 2010) remplaçait
les anciennes tables fixes de caractères autorisés ou interdits par
un algorithme, à faire tourner à chaque sortie d'une version
d'Unicode pour produire les tables listant les caractères qu'on peut
accepter dans un nom de domaine
internationalisé (le mécanisme exact, utilisant les
propriétés des caractères listées dans la norme Unicode, figure dans
le RFC 5892). En théorie, c'était très
bien. En pratique, malgré les règles de stabilité d'Unicode, il se
produisait parfois des problèmes. Comme le documente le RFC 8753, un caractère peut ainsi passer d'interdit
à autorisé, ce qui n'est pas grave mais aussi dans certains cas
d'autorisé à interdit ce qui est bien plus embêtant : que faire des
noms déjà réservés qui utilisent ce caractère ? En général, il faut
ajouter une exception manuelle, ce qui justifie un mécanisme de
révision de la norme IDN, mis en place par ce RFC 8753. Ce nouveau RFC 9233 est le premier RFC de
révision. Heureusement, cette fois, aucune exception manuelle n'a
été nécessaire.
La précédente crise était due à Unicode
version 6 qui avait créé trois incompatibilités (RFC 6452). Une seule était vraiment gênante, le
caractère ᧚,
qui, autorisé auparavant, était devenu interdit suite au changement
de ses propriétés dans la norme Unicode. Le RFC 6452 avait documenté la décision de ne rien faire pour ce
cas, ce caractère n'ayant apparemment jamais été utilisé. Unicode 7 a ajouté un autre problème, le
ࢡ, qui
était un cas différent (la possibilité de l'écrire de plusieurs
façons), et la décision a été prise de faire désormais un examen
formel de chaque nouvelle version d'Unicode. Mais cet examen a été
souvent retardé et voilà pourquoi, alors qu'Unicode 13 est sorti (ainsi qu'Unicode 14 depuis), ce nouveau RFC ne
traite que jusqu'à la version
12.
Passons maintenant à l'examen des changements apportés par les
versions 7 à 12 d'Unicode, fait en section 3 du RFC :
- À part le cas du ࢡ
cité plus haut, Unicode 7 n'a pas
apporté de changements gênants pour IDN (par exemple, U+17B4 (caractère
non visible) a
changé de propriétés mais il était interdit pour IDN et le
reste),
- Unicode 8, Unicode 9 et Unicode 10 n'ont appporté aucun
changement gênant,
- Unicode 11 a changé les
propriétés de certains caractères existants mais le résultat pour
IDN ne change pas (par exemple, 𑨇, qui
était autorisé, le reste),
- Et Unicode 12 ? Rien de
problématique.
En Unicode 11,
𑇉
qui passe d'interdit à autorisé, était un cas peu gênant. Le RFC
prend donc la décision de ne pas ajouter d'exception pour ce
caractère peu commun.
Voilà, arrivé ici, vous pensez peut-être que cela fait beaucoup
de bruit pour rien puisque finalement les différentes versions
d'Unicode n'ont pas créé de problème. Mais c'est justement pour
s'assurer de cela que cet examen était nécessaire.
Pour compliquer davantage les choses, on notera qu'il existe
encore sans doute (section 2.3 du RFC) des déploiements d'IDN qui en
sont restés à la première version (celle du RFC 3490) voire qui sont un mélange des deux versions d'IDN,
en ce qui concerne l'acceptation ou le refus des caractères.
En avril 2022, le travail pour Unicode
13 ou Unicode 14 n'a
apparemment pas encore commencé…
