Résumé

  • RFC 3490 maintenait le DNS en ASCII et plaçait IDNA dans l’application. ToASCII pouvait refuser une étiquette ; ToUnicode, lui, ne signalait jamais d’échec et rendait l’entrée originale si une étape ou le contrôle aller-retour échouait.
  • Une chaîne lisible ne prouvait donc ni sa validité IDNA, ni son admission par un registre, ni sa présence dans une zone, ni sa résolution, ni son authentification, ni le contrôle du nom.

Une opération qui « n’échoue jamais » inspire confiance. Dans RFC 3490, cette formule désignait pourtant une limite, non une garantie générale. ToUnicode devait toujours rendre une suite de caractères. Si le décodage, la préparation ou le contrôle final échouait, l’opération restituait simplement son entrée. L’écran restait alimenté ; le nom n’obtenait aucun certificat de validité.

Ce choix devient clair dès que l’on regarde l’architecture. IDNA ne modifiait ni les serveurs DNS, ni les résolveurs, ni le format du protocole. La conversion vivait dans l’application, comme une cale entre l’interface Unicode et une infrastructure historique fondée sur l’ASCII. Lorsqu’un nom entrait dans un fichier de zone ou un appel de résolution ancien, il devait franchir la voie ASCII. Lorsqu’il revenait vers un lecteur, l’application pouvait essayer d’en présenter la forme Unicode.

RFC 3490 appelait « emplacement de nom de domaine » tout champ ou argument explicitement chargé de transporter un nom : QNAME, argument d’une bibliothèque, partie domaine d’une adresse électronique, composant hôte d’un URI. Un nom cité dans un paragraphe ordinaire n’était pas, par cela seul, un tel emplacement. La même chaîne n’acquérait donc pas le même statut partout.

La voie descendante était normative et susceptible de s’arrêter. ToASCII traitait chaque étiquette. Pour une entrée non ASCII, il appliquait Nameprep, vérifiait éventuellement les règles lettre-chiffre-tiret, empêchait une chaîne Unicode de commencer déjà par le préfixe réservé, encodait avec Punycode, ajoutait xn--, puis imposait une longueur de un à 63 points de code. L’échec d’une étape faisait échouer l’opération. L’échec d’une seule étiquette interdisait d’utiliser le nom comme IDN.

La voie d’affichage devait répondre à une autre nécessité. ToUnicode repérait le préfixe ACE, le retirait, décodait Punycode, puis réappliquait ToASCII au résultat. La forme ASCII recalculée devait coïncider, sans tenir compte de la casse ASCII, avec l’entrée sauvegardée. Cet aller-retour empêchait une chaîne qui ressemblait à une ACE de se transformer arbitrairement en nom présenté comme équivalent.

Lorsque ce contrôle ne tenait pas, le contrat n’était pas « valide quand même ». Il était « rendre l’original ». RFC 3490 précisait qu’une étiquette qui commençait encore par le préfixe ACE après ToUnicode n’était pas une ACE valide et n’était équivalente à aucune forme Unicode intermédiaire. Le retour assurait la continuité de l’affichage ; il ne délivrait pas une admission.

Il faut alors séparer les reçus. Une chaîne peut être affichée. Elle peut réussir ToASCII. Un registre peut l’autoriser selon des règles de langue ou d’écriture plus strictes. Une A-label peut être inscrite dans une zone. Le DNS peut répondre. DNSSEC peut authentifier les données servies. Enfin, une personne peut reconnaître — ou confondre — le nom affiché. Chaque proposition a une source de preuve différente.

La remarque DNSSEC de RFC 3490 rend cette frontière particulièrement nette : la signature portait sur le nom ASCII, pas sur la forme Unicode ni sur l’association psychologique entre l’affichage et une identité. La cryptographie pouvait protéger les données de la couche DNS sans garantir la lecture humaine.

Le texte de 2003 ne prétendait pas davantage résoudre la langue. Le DNS restait un service de correspondance exacte. Les graphies proches, les caractères visuellement confondables, les variantes chinoises traditionnelles et simplifiées ou les équivalences propres à une langue ne devenaient pas automatiquement un seul nom. Les administrateurs de zone pouvaient imposer des restrictions supplémentaires. L’encodage assurait l’interopérabilité ; il ne distribuait pas les droits de nommage.

IDNA2008 rendit plus visible ce que l’ancienne asymétrie contenait déjà. RFC 5890 et RFC 5891 distinguèrent A-label et U-label, puis séparèrent le protocole d’enregistrement de celui de consultation. L’enregistrement pouvait exiger un accord exact entre les deux formes et rejeter une divergence. La consultation appliquait des tests plus permissifs, mais ne transformait pas une ressemblance en validité. RFC 5891 le formule sans détour : une comparaison réussie n’implique pas la validité.

RFC 5895 plaça les adaptations d’interface en amont du protocole commun. Cette organisation rejoint le principe de spécification initiale minimale de Heng Lu : normaliser le passage indispensable, mais laisser les décisions linguistiques et locales à ceux qui en portent le contexte. La couche commune reste mince et vérifiable.

L’héritage de RFC 3490 tient ainsi dans une négation bien conçue. Ne pas échouer peut être la bonne politique pour une fonction d’affichage, parce que l’utilisateur doit voir quelque chose. Ce serait une mauvaise politique pour décider ce qui entre dans le DNS. Le nom lisible était un résultat de présentation. Le nom accepté demandait un autre reçu.

Sources