Résumé

  • Dans RFC 9176, une inscription RD est un enregistrement maintenu de liens, d’un nom d’endpoint, d’une URI de base et d’une durée de vie ; ce n’est pas une observation de disponibilité actuelle.
  • La création de l’inscription, son renouvellement, la réponse à une recherche, l’accès au transport et le résultat métier appartiennent à des chaînes de preuve distinctes.

Le mot « découverte » invite à une conclusion trop rapide. Un client consulte un Resource Directory, reçoit un lien et peut imaginer que l’endpoint est là, que la ressource répondra et que le service est prêt. Le texte de RFC 9176 est moins expansif. Il définit un RD comme une entité Web qui stocke des informations sur les ressources hébergées par d’autres serveurs. Il normalise les interfaces permettant de découvrir le RD, d’inscrire, de maintenir, de rechercher ou de retirer ces informations. Cette fonction est déjà importante, notamment quand les nœuds dorment ou lorsque la multidiffusion directe est coûteuse.

Elle ne produit pas à elle seule une attestation d’exécution.

L’inscription possède une forme précise. Elle est associée à un endpoint et comprend un nom d’endpoint, une URI de base, une durée de vie, une localisation de ressource d’inscription dans le RD, des liens, éventuellement un secteur et d’autres attributs. Le RD renvoie une localisation stable au créateur ; celle-ci sert aux mises à jour ultérieures, au renouvellement de la durée de vie, à la maintenance des liens et, si nécessaire, à la suppression. Cette localisation est le reçu d’une opération sur la base du RD. Elle n’est pas le reçu d’une opération sur le dispositif décrit.

La durée de vie empêche précisément de confondre les deux. Les inscriptions sont à état souple et doivent être renouvelées. Une fois cette durée expirée, le RD devrait cesser de répondre aux requêtes de découverte concernant l’endpoint. Il peut néanmoins conserver la ressource d’inscription pour permettre un rafraîchissement tardif, puis la supprimer lors de sa collecte. Voir encore une ressource de gestion après expiration ne démontre donc ni alimentation électrique, ni rattachement réseau, ni récupération du service. Cela décrit une possibilité de reprise dans l’état du répertoire.

Une recherche a elle aussi une portée étroite. RFC 9176 renvoie les liens enregistrés, avec résolution des cibles et des ancres selon l’URI de base. Le résultat informe sur ce qui a été inscrit et sur la manière de l’interpréter. Il ne teste pas depuis le point de vue du lecteur un chemin réseau, une négociation CoAP ou HTTP, une identité, une autorisation, le traitement d’une requête ou l’effet physique qu’une application pourrait annoncer. Une URI peut rester syntaxiquement bien formée alors que l’endpoint est hors ligne. Un endpoint peut accepter le transport sans être autorisé pour ce client.

Une réponse de ressource peut être correcte sans prouver qu’un actionneur a achevé une action.

La partie sécurité de la RFC protège également contre l’inférence hâtive. Le nom d’endpoint ne doit pas être déduit du protocole, du port ou de l’adresse IP : ces valeurs peuvent changer au cours de sa vie. La politique concrète détermine l’autorisation d’utiliser un nom ou un secteur. Le contrôle d’accès pour l’inscription et celui de la recherche doivent être séparés. Une personne qui peut lire un lien n’acquiert pas le droit d’agir sur la ressource ; une personne qui peut inscrire un lien ne garantit pas que le monde auquel il renvoie est encore identique.

Le dossier opérationnel doit ainsi conserver, séparément, la requête d’inscription et sa réponse, la localisation attribuée par le RD, l’identité et la politique de secteur, l’URI de base, les liens, la durée de vie et les renouvellements. Il doit ensuite conserver la recherche datée, puis, lorsque le besoin porte sur l’état réel, un test de joignabilité, le résultat de sécurité et de transport, la requête de ressource, sa réponse et la preuve d’effet applicatif. Peter van der Stok ne contrôle pas ces étapes par sa qualité d’auteur ; le RD, le registrant, l’opérateur d’endpoint et le client gardent chacun une partie différente de la décision.

La discipline de Lu Heng est utile ici dans son sens limité : une surface commune peut coordonner sans absorber les décisions de celui qui fait fonctionner le système. Le répertoire rend des liens inspectables. L’état courant doit encore être observé. Cette distinction n’est pas une critique du RD ; c’est la condition pour que ses données restent fiables au lieu d’être transformées en promesse qu’elles ne font pas.

Sources