Résumé

  • RFC 3404 faisait de la résolution une requête typée : I2L, I2R, I2C et I2N demandaient respectivement emplacement, instance de ressource, description et nom persistant ; certaines formes distinguaient aussi un résultat d’un ensemble.
  • S, A et U indiquaient la représentation de l’étape suivante. P quittait au contraire DDDS pour un traitement propre à l’application. La découverte d’un résolveur n’authentifiait ni ce résolveur ni le contenu rendu.

Un journal peut annoncer « résolution réussie » alors que le système vient de changer de question. Donner l’adresse d’un dépôt à quelqu’un qui demandait le document n’est pas une variante de présentation. Donner une notice bibliographique à la place d’un nom persistant ne l’est pas davantage. Le succès syntaxique peut ainsi masquer une erreur sémantique.

Publié en octobre 2002 sur la voie de normalisation, RFC 3404 définissait les applications DDDS de résolution des URI et des URN. Il s’inscrivait dans une série cohérente : RFC 3401 présentait DDDS, RFC 3402 son algorithme, RFC 3403 sa base de règles NAPTR dans DNS, RFC 3404 les applications de résolution, et RFC 3405 l’administration de uri.arpa. et urn.arpa..

Le parcours commençait par une chaîne propre à l’application. Pour un URI absolu, la forme canonique et encodée fournissait l’entrée ; le schéma devenait la première clé bien connue, complétée par uri.arpa. dans DNS. Pour un URN, l’identifiant d’espace de noms jouait ce rôle sous urn.arpa.. Des règles NAPTR déléguaient ou réécrivaient ensuite l’entrée jusqu’à une sortie terminale ou un autre système.

Les deux applications étaient techniquement identiques, mais leur séparation opérationnelle était intentionnelle. La résolution des URN disposait déjà d’un raccourci et ne devait pas attendre l’adoption d’un résolveur général pour tous les URI. Un espace de noms pouvait donc publier son mécanisme utile sans dépendre d’une décision universelle prise par chaque schéma.

La précision centrale se trouvait dans Services. I2L demandait un URI d’emplacement ; I2Ls en autorisait plusieurs. I2R et I2Rs demandaient une ou plusieurs instances de la ressource. I2C réclamait une description. I2N devait rendre un URN, avec l’avertissement que l’égalité de deux URN pouvait dépendre de règles propres à l’espace de noms.

Ces produits ne sont pas interchangeables. Un emplacement explique où tenter un accès. Une instance est le contenu effectivement rendu. Une description est une assertion sur ce contenu. Un nom persistant vise l’identité à travers les déplacements. Un URI peut offrir plusieurs opérations, mais la preuve d’un emplacement n’est pas la preuve de la ressource, et une description correcte ne garantit pas que l’objet récupéré soit le bon.

La cardinalité faisait aussi partie du contrat. Le s de I2Ls ou I2Rs autorisait un ensemble. En ne conservant que le premier élément, un client ajoutait sa propre politique de sélection. Une trace sérieuse doit donc garder le service demandé, le nombre attendu, tous les résultats reçus et la décision finale du consommateur.

Le champ Services pouvait commencer par un protocole. Ce nom n’était pourtant pas un contrat de résolution. RFC 3404 exigeait une définition séparée de l’encodage de la requête et de la sémantique de la réponse. Écrire « HTTP » ne précisait ni la manière de demander une description plutôt qu’une ressource, ni la signification des types de contenu, ni la représentation d’un résultat multiple.

La découverte trouvait donc une capacité, pas un protocole d’application complet. L’interopérabilité naissait seulement lorsque l’annonce, la requête observable et la réponse typée décrivaient le même service.

Flags portait une dimension différente. S, A et U étaient terminaux pour l’algorithme DDDS : S livrait un nom à interroger en SRV, A un nom pour une recherche d’adresse, U un URI. « Terminal » signifiait ici que la boucle DDDS s’arrêtait, non que tout travail réseau ou toute validation était terminé.

P n’appartenait pas à cette catégorie. Il disait que la suite relevait d’une procédure spécifique à l’application, hors des concepts DDDS. Le traiter comme quatrième format terminal effacerait un changement de régime : l’autorité de traitement venait de passer à un autre système.

En 2002, les quatre drapeaux étaient mutuellement exclusifs, mais le texte interdisait aux programmes de supposer que Flags resterait toujours vide ou long d’un caractère. Une version future pouvait définir des combinaisons. Un drapeau inconnu imposait d’ignorer l’enregistrement puis de continuer ; cette vérification précédait l’ordre normal, car le drapeau pouvait modifier l’interprétation des autres champs.

Services pouvait être vide lors d’une délégation précoce. Le publieur ne connaissait pas encore nécessairement le protocole final. Vide ne signifiait donc ni invalide ni universel : il reportait la décision vers une étape ultérieure.

RFC 3404 autorisait une optimisation limitée parmi les règles de même ORDER. Un client pouvait chercher le service qu’il savait mieux utiliser, à condition de conserver exactement l’entrée et la sortie de l’algorithme de base. Il ne pouvait traverser une autre branche de délégation ni consulter un ORDER supérieur après une correspondance.

Cette barrière séparait aptitude locale et autorité publiée. Le client peut choisir entre offres équivalentes ; il ne peut promouvoir une destination commode située dans un autre niveau. Sinon, l’optimisation devient une réécriture silencieuse de la délégation.

Des enregistrements SRV ou d’adresse dans la section Additional pouvaient économiser des requêtes, mais leur présence restait facultative. L’application devait fonctionner sans eux. « Nom suivant découvert », « données auxiliaires reçues » et « connexion réussie » constituaient trois événements distincts.

La sécurité suivait les mêmes frontières. Trouver un résolveur ne définissait pas la manière de lui parler en sécurité. Chaque protocole de résolution devait porter ce contrat. DNS, uri.arpa. et urn.arpa. avaient leurs risques de disponibilité, d’usurpation et d’administration ; même un chemin DNS validé ne prouvait ni l’identité du pair applicatif, ni l’authenticité de la ressource, ni l’actualité d’une description.

Les expressions régulières exigeaient enfin un contrôle avant exécution. Une règle correctement publiée pouvait rester dangereuse si elle était transmise à un environnement trop puissant. Authenticité de la règle et sûreté de son interprétation n’étaient pas la même preuve.

Le RFC Editor répertorie trois errata éditoriaux. Les errata vérifiés 282 et 787 remplacent une référence à RFC 3404 par RFC 3403 pour le traitement des informations Additional. L’erratum 2923, conservé pour une mise à jour du document, corrige les numéros de références de la section 4. Aucun ne modifie les services typés, leur cardinalité ou les drapeaux.

Une preuve d’exécution devrait conserver l’entrée canonique, le schéma ou espace de noms, la première clé, la requête DNS, tout l’ensemble NAPTR, la décision sur Flags, le protocole, le service et sa cardinalité, la sélection au même ORDER, la règle choisie, le passage S/A/U/P, la requête suivante, l’identité authentifiée du pair, le type de réponse et le résultat réellement consommé.

Le principe de spécification initiale minimale de Lu Heng explique cette composition : normaliser précisément les frontières communes, laisser les protocoles particuliers évoluer localement. La primauté du code en fonctionnement donne le banc d’essai : demander successivement emplacement, ressource et description ; supprimer Additional ; introduire un drapeau inconnu ; varier les capacités dans le même ORDER. Une mise en œuvre conforme ne change de comportement qu’aux endroits autorisés par le contrat.

RFC 3404 ne promettait pas qu’un identifiant fournirait toutes les réponses. Il imposait de nommer la réponse cherchée et la frontière franchie. Grâce à cette discipline, « réussi » devenait enfin une affirmation vérifiable.

Sources