Résumé

  • La version 1.123 de la base RIPE applique la forme NFC à l’Unicode décomposé dans le traitement UTF-8 de descr: et remarks:, avant l’assainissement des caractères de contrôle et la conversion IDNA.
  • La mesure est favorable à l’interopérabilité, mais la saisie, la valeur canonique et les octets rendus par une interface donnée restent trois objets de preuve différents.
  • Un reçu de normalisation respectueux de la confidentialité peut relier ces états sans publier le texte libre, les identifiants d’accès ni des données personnelles.

Le même caron ne donne pas les mêmes octets

Le nom Ondřej Caletka paraît sans ambiguïté à l’écran. Pourtant, le ř peut être le caractère précomposé U+0159. Il peut aussi être construit avec un r ordinaire, U+0072, suivi du caron combinant U+030C. Les deux suites représentent le même caractère abstrait et devraient s’afficher de la même façon. Une comparaison binaire brute les distingue.

Le correctif publié par RIPE NCC transforme cette subtilité en fait vérifiable. Son nouveau test injecte la suite décomposée dans un attribut descr: et exige une chaîne Java de longueur un. Il vérifie ensuite que la graphie décomposée de Ondřej Caletka ressort avec le caractère unique ř.

Le chemin du programme compte autant que le résultat. Dans Utf8Conversion.createUtf8Attribute, la valeur est d’abord débarrassée de ses échappements Java. L’instance NFC d’ICU la normalise ; le programme parcourt ensuite les points de code obtenus, assainit les caractères de contrôle, puis applique la conversion IDNA déjà présente. La normalisation précède donc ces deux filtres. Elle n’est ni un choix de police ni un embellissement du navigateur.

Les notes de version datent le passage en production de Whois 1.123 du 8 juillet 2026. Elles limitent le changement aux caractères Unicode décomposés de descr: et remarks:. La documentation actuelle sur l’encodage confirme que ces deux attributs libres acceptent l’UTF-8 et utilisent la composition canonique NFC.

Défendre la normalisation avant d’en demander la preuve

La NFC répond à un vrai problème. L’annexe 15 du standard Unicode la définit comme une décomposition canonique suivie d’une composition canonique. Deux chaînes canoniquement équivalentes obtiennent ainsi la même forme NFC. Un accent saisi séparément ne devient pas à jamais un texte binaire différent de la forme précomposée choisie par un autre clavier.

Présenter ce mécanisme comme une altération arbitraire serait donc inexact. Le texte abstrait reste canoniquement équivalent. La NFC ne doit pas non plus être confondue avec une normalisation de compatibilité qui effacerait plus largement des différences de présentation. Ici, l’objectif raisonnable est une représentation stable pour l’échange.

La prudence se lit déjà dans la version précédente. Whois 1.122, déployée en production le 30 avril, n’a ouvert l’UTF-8 qu’à descr: et remarks:. La proposition du groupe de travail cherchait un changement minimal : permettre des messages locaux utiles, accumuler de l’expérience et ne pas toucher aux noms, aux adresses ni aux champs destinés aux données personnelles. Elle rappelle d’ailleurs que ces attributs libres ne doivent pas contenir de données personnelles.

La question n’est donc pas de revenir à deux écritures binaires pour un même caractère. Elle est de savoir si l’on peut encore distinguer ce qui a été soumis, ce que la base a rendu canonique et ce qu’un service a livré.

Une valeur canonique peut avoir plusieurs sorties

Le tableau des interfaces de RIPE montre pourquoi cette distinction n’est pas théorique. Whois sur le port 43, NRTMv3 et les fichiers quotidiens ordinaires utilisent le Latin-1 par défaut. Lorsqu’une interface ne sait pas représenter un caractère, la documentation prévoit son remplacement par ?. L’application web, l’API REST Whois, RDAP, NRTMv4, Syncupdates et les fichiers .utf8.gz emploient l’UTF-8 par défaut. Le client du port 43 peut aussi choisir son jeu de caractères avec l’option prévue.

Ces sorties servent des contraintes différentes. La continuité d’un ancien client peut justifier le Latin-1 ; un service UTF-8 doit pouvoir préserver la valeur canonique. Mais un objet recueilli sur un flux Latin-1 n’est pas la copie binaire de la valeur UTF-8 parce que tous deux portent le nom RIPE Database. Un point d’interrogation ajouté à la sortie n’est pas un point d’interrogation saisi par l’opérateur.

Une archive peut calculer l’empreinte du flux reçu. Une équipe réseau peut conserver l’accusé d’une mise à jour. Un enquêteur peut rapprocher un dump historique et une réponse d’API. Sans mention de la représentation, un écart d’empreinte peut passer pour une modification de fond alors qu’il vient de l’encodage ou de la NFC. Inversement, deux rendus identiques ne prouvent pas que les suites soumises l’étaient.

Les sources publiques ne montrent pas qu’un miroir précis commet cette erreur. Elles ne disent pas non plus si tous les anciens objets ont été normalisés en bloc ni si RIPE NCC conserve chaque saisie antérieure à la NFC. Elles établissent une frontière de traitement. C’est cette frontière, et seulement elle, qui appelle une trace.

Un reçu sans exposer le texte

Le reçu utile peut rester mince. Au moment de la mise à jour, il nommerait la version de l’objet, l’accusé de l’opération, la classe d’attribut, l’interface d’entrée et son encodage. Il indiquerait la NFC, la version ou le commit du logiciel, le fait que la suite de points de code a changé ou non et la présence éventuelle d’une substitution liée à l’assainissement ou aux points de code admis.

La liaison d’intégrité doit tenir compte de la confidentialité. Une empreinte publique d’un texte très court et prévisible peut être devinée. Un engagement authentifié, une empreinte de lot protégée ou un accès limité vaut mieux qu’une publication irréfléchie. Le reçu n’a aucune raison de révéler descr:, remarks:, une clé de mise à jour ou une donnée personnelle.

À la sortie, il ajouterait l’interface de requête ou de réplication, le jeu de caractères demandé, la version de sérialisation et l’empreinte de l’objet effectivement émis. Une relation de remplacement relierait la version à ses corrections. La chaîne disposerait alors de trois repères explicites : soumis, canonique, émis.

Ce reçu ne certifie pas la vérité du contenu. Une remarque normalisée ne prouve ni l’exploitant d’un réseau, ni la propriété d’une ressource, ni l’état du routage. Elle permet seulement de dire quelle règle relie les textes comparés. C’est une prétention plus modeste, donc plus robuste.

Les limites à ne pas franchir

Aucune source citée ne signale un incident, une attaque, un défaut d’autorisation ou une erreur d’identité causés par la NFC. Le changement ne rend pas tous les attributs RPSL compatibles avec l’UTF-8. Il n’internationalise pas automatiquement person:, role:, org-name: ou les adresses. Le seul correctif de code ne décrit pas davantage le traitement de chaque objet historique.

L’incident NRTM du mois d’août appartient à une autre enquête : nouvelles lignes supplémentaires, objet RPSL invalide, arrêt du flux et correctifs de la version 1.124. La continuité d’un miroir et la représentation canonique du texte ne sont pas le même contrôle.

Sources

  1. Notes de version de la base RIPE
  2. Encodage des caractères dans la base RIPE
  3. Archives des plans trimestriels de la base RIPE
  4. Point opérationnel du groupe de travail Base de données à RIPE 90
  5. Proposition UTF-8 pour descr: et remarks:
  6. Message de sortie de Whois 1.122
  7. Analyse d’impact de l’UTF-8 sur RIPE Labs
  8. Commit RIPE-NCC normalisant l’Unicode décomposé
  9. Versions de Whois publiées par RIPE-NCC
  10. Annexe 15 du standard Unicode