Résumé

  • Le rapport de synthèse du 24 août 2026 retient une correction ciblée : dans la restriction propre à U+A9B4, le prédécesseur U+A9BC doit être remplacé par U+A9BB, U+A9BA restant l’autre possibilité autorisée.
  • La formulation fautive figure dans les trois vues du projet du 23 avril : proposition PDF, présentation HTML et règle XML follows-A9BA-A9BC.
  • L’ICANN indique que la modification sera discutée avec la communauté javanaise, puis intégrée à la version finale. Au 1er septembre, sa page de publication reste à la version du 25 octobre 2024 et ne contient aucun LGR javanais définitif.
  • Un LGR de référence sert à concevoir et à examiner les tables IDN des registres ; il ne remplace pas automatiquement ces tables.
  • La clôture devrait prendre la forme d’un reçu versionné reliant commentaire, décision communautaire, diff exact et empreintes des fichiers finaux, sans prétendre qu’un rapport a modifié le DNS en production.

Une correction minoritaire, mais normative

La consultation ouverte le 12 mai portait sur deux nouveaux LGR de référence, javanais et UCAS, ainsi que sur six mises à jour. Sur 33 contributions pertinentes, 32 soutenaient l’ensemble. La dernière ne contestait pas le projet global : elle signalait une erreur et demandait une clarification dans le document javanais.

Le point paraît étroit. U+A9B4, JAVANESE VOWEL SIGN TARUNG, ne devrait pouvoir suivre que U+A9BA, JAVANESE VOWEL SIGN TALING, ou U+A9BB, JAVANESE VOWEL SIGN DIRGA MURE. Le projet citait U+A9BC, JAVANESE VOWEL SIGN PEPET, à la place de U+A9BB. Arif Budiarto, contributeur à la proposition, a formulé la substitution et précisé que l’intention orthographique ne changeait pas : il s’agissait de la rétablir correctement.

Ce n’est pas seulement une coquille dans un commentaire. La page 38 de la proposition énonce la paire A9BA/A9BC dans la règle 4. La version HTML la reproduit. Le XML applique à U+A9B4 une condition nommée follows-A9BA-A9BC, dont la classe contient ces deux valeurs. Le commentaire public vise donc bien la représentation exploitable par une machine.

La clarification sur les règles 3 et 4 évite un second malentendu. La règle 3 impose en général qu’une voyelle dépendante suive une consonne, une consonne médiale ou une voyelle indépendante. La règle 4 ajoute une restriction particulière à U+A9B4. Elle n’annule pas la règle générale ; elle resserre le cas précis. Le groupe de travail a annoncé une mise à jour du texte, des références de règle et du document justificatif.

Il faut aussi borner la portée du constat. U+A9BC demeure un caractère du répertoire javanais proposé. Rien ne permet d’en faire un caractère « invalide ». L’erreur concerne sa relation avec U+A9B4 dans cette condition particulière.

Le rapport fixe l’intention, pas encore les octets

Le rapport de synthèse de l’ICANN reconnaît le retour et décrit la suite : discussion avec la communauté javanaise, intégration dans la version finale, puis publication des LGR définitifs sur la page Second-Level Reference LGR. Cette réponse est substantielle. Elle n’est toutefois ni le XML corrigé, ni le HTML correspondant, ni la nouvelle proposition justificative.

Au moment de la vérification, le 1er septembre, la page publique affichait encore « Current Version (25 October 2024) ». Sa liste des LGR par script ne comportait pas le javanais. Le seul paquet javanais publiquement accessible dans la procédure restait donc le projet du 23 avril soumis à commentaires.

Ce décalage de huit jours n’est pas en soi un retard anormal. Une confirmation communautaire, une modification cohérente de trois fichiers et une validation du XML demandent du travail. L’erreur consisterait plutôt à effacer les états : citer le PDF de synthèse comme si la condition XML avait déjà changé, ou citer l’ancien XML comme si l’ICANN avait refusé la correction.

Les propres lignes directrices de l’ICANN expliquent pourquoi le fichier compte. Le LGR normatif est représenté en XML selon la RFC 7940. L’examen doit notamment vérifier que les points de code et les règles souhaités sont fidèlement exprimés. Une décision narrative prouve la direction ; une publication versionnée prouve le résultat.

Trois objets que le récit ne doit pas fusionner

Après publication, le LGR de référence servira de base aux opérateurs de registre qui conçoivent leurs tables IDN et à l’ICANN lorsqu’elle examinera les tables soumises par les registres gTLD. Ce rôle est concret, mais il ne s’agit pas d’un mécanisme de mise à jour automatique.

Le fichier commun, la table présentée par un registre et l’implémentation effectivement utilisée restent trois objets. À ceux-ci s’ajoute la décision d’examen de l’ICANN. Une même correction peut les atteindre à des dates différentes.

Cette distinction protège contre deux exagérations opposées. Aucun élément examiné ne relie le projet erroné à un domaine actif, à un refus d’enregistrement ou à un incident de sécurité. Mais l’apparition future du XML final ne suffira pas non plus à démontrer que toutes les tables de registre l’ont adopté. Chaque étape exige son propre reçu.

Un reçu court pour fermer la boucle

Le dossier public contient déjà les pièces : procédure, commentaire, synthèse, XML, HTML, proposition et page de publication. Il lui manque une relation explicite entre elles.

Le reçu commencerait par identifier le paquet du 23 avril et ses empreintes. Il nommerait U+A9B4, la règle affectée, l’expression A9BA/A9BC observée et la demande A9BA/A9BB. Il conserverait l’explication limitée du contributeur et le rapport entre les règles 3 et 4.

Puis viendraient les états d’autorité : commentaire reçu, discussion communautaire, décision de l’ICANN, personne ou fonction responsable de la validation finale. Si la règle est renommée ou restructurée, un équivalent explicite remplacerait la simple comparaison de chaînes.

La publication finale devrait réunir date, version, URL et empreinte pour le XML, le HTML et le document justificatif. Un diff lisible par machine montrerait la sortie de A9BC et l’entrée de A9BB dans la condition de U+A9B4. Quelques tests de conformité documenteraient les séquences permises et interdites. Le projet resterait archivé, mais porterait un statut « remplacé » impossible à confondre avec la version courante.

Enfin, les tables de registre seraient liées, non présumées. Une soumission indiquerait la version de référence consultée ; l’ICANN enregistrerait son examen ; l’opérateur déclarerait son état d’adoption. L’absence de lien signifierait « non démontré », pas « non adopté ».

Cette économie rejoint la discipline de Heng Lu : le niveau commun ne doit porter que l’état déterministe nécessaire à la coordination — acteur, artefact, règle, version, date et révision — tandis que les décisions locales restent chez leurs responsables.

Limites de l’enquête

Aucune source consultée ne montre qu’un registre gTLD actuel a repris la condition du projet. Aucun dommage touchant un domaine ou un utilisateur n’est établi. La consultation publique a précisément permis de détecter le problème avant une publication finale.

Rien ne permet non plus d’accuser l’ICANN d’avoir ignoré le commentaire. Son rapport prévoit l’intégration après discussion. La question ouverte n’est pas la volonté déclarée, mais la preuve finale et versionnée de son exécution.

Sources

  1. ICANN — rapport de synthèse, 24 août 2026
  2. ICANN — procédure Additional Reference LGRs
  3. ICANN — contribution d’Arif Budiarto
  4. ICANN — index du paquet du 12 mai
  5. ICANN — projet javanais en XML
  6. ICANN — projet javanais en HTML
  7. Generation Panel javanais — proposition justificative
  8. ICANN — LGR de référence de second niveau
  9. ICANN — lignes directrices pour les LGR de référence
  10. RFC Editor — RFC 7940
  11. Heng Lu — Minimum Initial Specification, Localized Future Decision, and Voluntary Adoption