Résumé

  • La RFC 3987 a donné une place définie aux identifiants de ressource internationalisés (IRI), capables de contenir Unicode, aux côtés des logiciels centrés sur les URI. La conversion dépend de la composante : un hôte de type nom de domaine peut relever d’IDNA, tandis que les caractères Unicode d’un chemin ou d’une requête passent par UTF-8 et l’encodage en pourcentage.
  • La RFC 3987 attribue le texte à Martin J. Dürst et Michel Suignard ; le CV universitaire de Dürst le décrit comme l’auteur principal de la spécification IRI. Cette norme relie les écritures utilisées par les lecteurs aux logiciels plus anciens, sans enregistrer un nom, établir le contrôle d’un domaine ni prouver que deux chaînes visuellement proches désignent la même ressource.

À quel moment la chaîne change-t-elle de rôle ?

Imaginons une adresse dont le chemin contient des caractères japonais et dont le nom d’hôte s’écrit dans une autre langue. À l’écran, la personne voit une seule adresse Web. Le client doit pourtant la découper en schéma, autorité, chemin, requête et éventuellement fragment. Chaque morceau rencontre ensuite des règles différentes. La forme lisible et celle envoyée à un composant qui n’accepte que les URI peuvent être liées sans être identiques caractère par caractère.

C’est la raison d’être des Internationalized Resource Identifiers, ou IRI. La RFC 3986 définit la syntaxe générique des identifiants uniformes de ressource (URI), dont le répertoire de caractères est limité à une partie de l’ASCII américain. Publiée en janvier 2005, la RFC 3987 ajoute un compagnon qui accepte Unicode au lieu de modifier discrètement l’ancienne définition. Ses auteurs expliquent qu’un nouvel élément de protocole préserve une distinction claire et évite les incompatibilités avec les logiciels existants.

Un composant qui accepte les IRI peut les conserver ; lorsqu’un parcours de récupération n’accepte que les URI, l’IRI doit être converti vers la forme URI correspondante.

La norme ne promet pas que chaque composant ancien du réseau comprendra soudain toutes les écritures. Elle propose une architecture d’interopérabilité : laisser les logiciels compatibles garder une séquence plus large, puis définir le passage vers une interface plus restreinte lorsque cela devient nécessaire. La distinction compte parce qu’un identifiant peut être stocké, affiché, copié ou utilisé pour récupérer une ressource. Ces opérations n’ont pas besoin d’avoir lieu dans le même composant ni au même moment.

L’hôte suit une règle particulière

La séparation la plus importante apparaît après //, dans la partie autorité d’une adresse Web. Si l’hôte est un nom de domaine de type DNS, la conversion décrite en 2005 par la RFC 3987 fait appel à l’opération ToASCII d’IDNA pour chaque étiquette séparée par un point. Le résultat est une forme ASCII compatible avec les logiciels conçus autour des URI. L’exemple de la RFC transforme l’hôte résumé.example.org en xn--rsum-bpad.example.org.

Cet exemple montre ce que fait Punycode, mais aussi ce qu’il ne fait pas. Il encode une étiquette de domaine dans une forme ASCII compatible. Il ne convertit pas toute l’URL et ne doit pas être appliqué à chaque composante non ASCII. Le préfixe xn-- n’est pas non plus un certificat : la RFC 5890 distingue une étiquette A-label validée par IDNA d’une chaîne qui lui ressemble seulement. La conformité dépend de la validation, pas de l’apparence.

Les générations de normes forment une autre frontière. Pour la conversion de l’hôte, la RFC 3987 cite la RFC 3490, le protocole IDNA de 2003. Le cadre IDNA2008 ultérieur, dont les RFC 5890 et 5891, a révisé la terminologie et les règles du protocole. La RFC 5895, un document informatif, décrit les correspondances qu’une application peut appliquer à une saisie avant le protocole IDNA2008. Elle reconnaît qu’une transformation utile peut dépendre de la langue, de l’application et du mode de saisie.

L’exemple de la RFC 3987 doit donc être lu dans son contexte de 2005, non comme la garantie que chaque navigateur actuel applique une conversion universelle.

Un chemin n’est pas une étiquette de domaine

Déplacez les mêmes caractères vers le chemin : le traitement change. Un segment tel que /研究 peut être représenté dans l’URI comme /%E7%A0%94%E7%A9%B6, ses octets UTF-8 étant encodés en pourcentage. Punycode n’est pas l’algorithme du chemin. Celui-ci peut être interprété par un serveur Web, un cadre applicatif, un système de fichiers ou un routeur propre à l’application ; le DNS ne résout pas chaque segment du chemin.

Les requêtes et fragments ont aussi leur sémantique. Le pourcentage, la barre oblique, le point d’interrogation ou le dièse peuvent être des délimiteurs et non de simples données ; l’ordre d’analyse et d’échappement compte donc. La RFC 3987 conserve la syntaxe des composantes URI tout en élargissant les caractères directement admis dans un IRI. Sa conversion ne revient pas à « remplacer chaque caractère Unicode par une graphie ASCII ». Le schéma et la composante déterminent l’opération pertinente.

C’est pourquoi la norme recommande de retarder la conversion jusqu’au composant qui ne sait pas traiter les IRI. Un passage trop précoce peut supprimer une forme utile au lecteur avant qu’une autre application compatible ne la reçoive. Si le serveur normalise ou décode dans un ordre différent, deux systèmes peuvent ne pas parler de la même route. Le travail de Dürst et Suignard porte donc sur la jonction entre des systèmes, et pas uniquement sur l’affichage de caractères non latins dans la barre d’adresse.

Une conversion valide n’enregistre pas un nom

IDNA répond à une question étroite : une étiquette peut-elle être représentée et validée selon les règles applicables ? La RFC 5891 sépare les processus d’enregistrement et de recherche DNS. Elle précise que le traitement réalisé par un bureau d’enregistrement avant l’arrivée de la demande au gestionnaire de zone se trouve hors du protocole IDNA ; le registre ou gestionnaire de zone valide la chaîne précise qui lui est soumise. Une A-label syntaxiquement valide ne prouve donc pas que le nom a été enregistré, délégué dans le DNS ou placé sous le contrôle du service attendu par le lecteur.

Cette séparation est facile à oublier lorsqu’on copie dans un document un nom Unicode familier. Il existe au moins quatre reçus distincts : les caractères saisis, la correspondance appliquée par l’interface, l’étiquette d’hôte transmise au DNS et la réponse du service Web. Les données d’enregistrement et les preuves de contrôle du service constituent encore d’autres éléments ; ce ne sont pas des graphies différentes d’une seule chaîne. Une conversion réussie ne les établit pas.

La question relève aussi de la sécurité. La RFC 3987 avertit des risques d’usurpation dans l’hôte comme dans le chemin : caractères visuellement proches, attentes de normalisation différentes ou traitement divergent entre client et serveur peuvent faire paraître semblables des adresses qui désignent des ressources différentes. La norme ne dit pas qu’Unicode est dangereux. Elle exige plutôt que le système sache quelle composante et quelle transformation fondent son résultat. Une chaîne affichée renseigne sur la présentation ; elle ne certifie pas une identité.

Un standard au cœur du parcours de la chaîne

La RFC cite M. Dürst et M. Suignard. Le CV officiel de Dürst à l’Université Aoyama Gakuin le décrit comme l’auteur principal de la spécification IRI et rappelle ses travaux sur l’internationalisation du Web, l’usage d’Unicode et la normalisation des caractères composites. Il situe également Dürst à la tête de l’activité Internationalization du W3C pendant une grande partie de la période où la RFC 3987 a pris forme. L’université le présente comme professeur à son College of Science and Engineering.

Ces sources étayent une contribution majeure, pas une paternité solitaire. L’importance du travail apparaît dans le choix de conception : au lieu de laisser les lecteurs d’URI deviner le sens de nouveaux caractères, les IRI offrent aux logiciels compatibles une représentation propre au niveau des caractères et précisent quand une conversion est nécessaire. La contribution de Dürst s’inscrit dans un effort de normalisation collectif ; le texte est cosigné avec Suignard.

Le lien avec le « droit à des registres exacts » de Heng Lu reste volontairement limité. Son texte porte sur les registres Internet régionaux et les ressources de numérotation IP ; il ne constitue pas une politique DNS et ne régit pas les noms de domaine. La question utile ici est seulement de savoir si un registre décrit fidèlement l’état qu’il prétend représenter. Une graphie Unicode, une A-label, une délégation DNS et une clé de ressource côté Web sont des inscriptions liées, mais situées à des couches différentes. Aucune ne peut remplacer les autres.

Sources