Résumé

  • La RFC 9517 enregistre l’espace URN ddi : un identifiant d’agence approuvé, un identifiant de ressource attribué par cette agence et une version composent le nom.
  • La résolution transforme l’agence en nom sous ddi.urn.arpa, suit les délégations DNS et les règles NAPTR, choisit un type de service, puis soumet l’URN original.
  • Un nom valide ne prouve ni son attribution réelle, ni la disponibilité d’un dépôt, ni l’intégrité de l’objet, ni sa conservation. Chaque niveau exige son propre reçu.

Le catalogue affichait un identifiant permanent et le contrôle syntaxique était vert. Pourtant, le premier service découvert ne répondait plus. Le second renvoyait une fiche descriptive, pas l’objet demandé. Le nom n’avait pas échoué : il continuait à désigner. C’est l’organisation qui avait confondu désignation, localisation et conservation.

La RFC 9517, publiée en janvier 2024 dans le flux Independent avec le statut Informational, enregistre ddi pour les ressources conformes aux normes de la Data Documentation Initiative. Elle n’appartient pas au Standards Track et ne représente pas un consensus de l’IETF. Son intérêt opérationnel vient de la répartition explicite des responsabilités qu’elle impose derrière un nom apparemment simple.

La grammaire ne suffit pas à attribuer un nom

La forme est urn:ddi:<agence>:<ressource>:<version>. L’identifiant d’agence suit l’ordre des noms de domaine inversés. La DDI Alliance approuve les agences ; chacune attribue ensuite les identifiants de ressources et de versions dans son propre périmètre.

L’unicité résulte donc de deux contrôles. L’Alliance doit éviter les collisions entre agences. L’agence doit les éviter dans ses ressources. Un parseur ne peut constater que la conformité de la chaîne. Comme le rappelle la RFC 8141, commencer par urn: et respecter une grammaire ne suffit pas : le NID doit être enregistré et le nom doit venir du processus d’attribution déclaré.

La comparaison est asymétrique. urn, ddi et l’agence sont insensibles à la casse ; la ressource et la version y sont sensibles. Une normalisation qui met tout en minuscules peut fusionner deux objets différents. L’opération inverse peut créer deux autorités fictives. Il faut conserver les octets d’origine, les trois composantes et la règle appliquée.

Les deux-points n’archivent rien

La persistance dépend d’une délégation de résolution appropriée et du maintien de l’attribution de l’agence. La ressource elle-même reste sous la responsabilité de cette agence. Un URN peut demeurer stable alors que le serveur DNS, le dépôt, la politique d’accès ou les fichiers ont disparu.

La version ne ferme pas cette brèche. Elle distingue une révision selon les règles de l’agence ; elle ne prouve pas que le dépôt a renvoyé cette révision, que plusieurs dépôts possèdent les mêmes octets ou que l’agence la tient encore pour autoritative. La réponse doit être rapprochée de son identifiant, de son empreinte, de sa provenance et de son dossier de conservation.

Les sous-agences rendent l’administration souple et permettent des délégations différentes. Elles ajoutent aussi un niveau de garde. Une agence mère peut rester enregistrée tandis qu’une branche change de serveur ou de dépositaire. Le chemin complet d’autorité appartient donc à la preuve.

Résoudre signifie franchir plusieurs frontières

Le client extrait l’agence, normalise sa casse, inverse les éléments séparés par des points et ajoute .ddi.urn.arpa. DNS sert de base DDDS. La requête peut passer de urn.arpa à la DDI Alliance, puis au serveur de l’agence. Les enregistrements NAPTR proposent des services ; un drapeau u peut livrer directement un URI, tandis que s conduit à une recherche SRV.

Le résultat attendu est une information de connexion vers un ou plusieurs services. Ce n’est ni l’objet ni une preuve que le service est actif, toujours mandaté ou cohérent avec ses pairs. Il faut enregistrer le résolveur, l’heure, le TTL, l’âge du cache, l’état de validation, tous les champs NAPTR, le résultat SRV, le service choisi, le certificat du point terminal et sa réponse.

La RFC distingue I2R, qui peut retourner une instance de ressource, I2C, qui retourne des caractéristiques, I2L, qui fournit un emplacement, et I2Ls, qui en fournit plusieurs. Ces réponses ne sont pas substituables. Une fiche exacte peut décrire un objet indisponible ; un URL valide peut viser une ancienne version ; plusieurs emplacements peuvent diverger. Réduire ces états à trouvé=true détruit précisément l’information nécessaire à la décision.

Une requête DNS chiffrée n’authentifie pas les données

Le document qualifie le profil de sécurité de faible parce que les ressources visées sont publiques, mais rappelle que la résolution dépend de la sécurité générale du DNS. DoH peut protéger le trajet entre le client et son résolveur. Il ne prouve ni la délégation finale, ni le mandat de l’agence, ni l’identité du dépôt, ni l’intégrité de l’objet.

Il faut séparer la validation DNSSEC, le chiffrement de la requête, TLS au service, l’autorisation de l’agence et la signature ou l’empreinte de l’objet. Le dossier probant progresse ainsi : espace enregistré, syntaxe, agence approuvée, attribution interne, délégation observée, service interprété, point terminal authentifié, réponse liée à l’URN exact, contenu vérifié, usage accepté par le responsable.

L’URN garde la question stable pendant que l’infrastructure change. C’est un rôle puissant. Il cesse d’être fiable seulement lorsqu’on lui fait promettre la réponse, la disponibilité ou la vérité.

Sources