Résumé

  • La révision du 28 octobre décrit une première recherche par mDNS/DNS-SD, puis une description A2A ou une session MCP pour joindre un agent proche.
  • Sur un lien partagé, n’importe quel hôte peut publier l’annonce. Le titre, le pointeur vers la description et son empreinte sont des informations choisies par cet annonceur.

Une liste ouverte avant la poignée de main

Dans un laboratoire ou une agence, les services apparaissent et disparaissent. Écrire à la main l’adresse de chaque serveur d’outils devient vite absurde. Le projet individuel de Jakab et Brockners reprend un mécanisme connu : parcourir les services DNS-SD, résoudre l’hôte et le port, puis obtenir les renseignements complets par le protocole de l’agent. La nouvelle version ajoute MCP au scénario A2A, rapproche les paramètres de découverte de ceux du DNS unicast et envisage le relais au-delà du lien local. Rien de cela n’est encore une norme adoptée.

Le premier parcours sert à trouver, pas à élire. Le projet dit qu’un hôte du même lien peut publier une instance, imiter un nom d’affichage et remplir librement les champs TXT. Le nouveau desc-ref désigne une description; il ne dit pas qui la tient. desc-ref-digest semble plus solennel, mais l’émetteur l’inscrit dans la même annonce non authentifiée. Il peut signaler un changement de description. Il ne protège pas l’intégrité de cette description. Une empreinte posée par celui qui écrit l’étiquette n’est pas un contrôleur indépendant.

La connexion forme la seconde étape. Le client reçoit une adresse issue de l’hôte et du port SRV, complétés par un chemin. Il doit traiter cette adresse comme toute destination fournie par une partie extérieure : filtrer schémas, plages d’adresses, ports, redirections, identifiants et demandes entre domaines, puis vérifier l’identité du serveur. Le schéma https ajouté par défaut ne réalise pas à lui seul cette vérification. Pour MCP, les outils, ressources et instructions présentés après la poignée de main gardent leur propre frontière de confiance. Un serveur peut être visible dans le bureau sans mériter le droit de diriger le travail.

Le relais ne transforme pas davantage la provenance. Il propage le nom à d’autres auditeurs. RFC 9665 prévoit un enregistrement où le premier arrivé garde un nom occupé; cette priorité ne révèle pas l’exploitant du premier inscrit. Un filtre administratif réduit le nombre de candidats, sans certifier le contenu qu’ils annoncent.

Enfin, l’annonce divulgue le petit inventaire des agents présents à tous les hôtes qui la voient. Un sous-type A2A ou MCP facilite le tri, pas le secret. La bonne répartition des rôles apparaît alors : l’opérateur choisit où la publicité est permise; le client choisit quel point de connexion est admissible; le protocole authentifie ce qu’il rencontre. La liste demeure utile précisément tant qu’elle reste une liste.

Sources : version 01, version 00, état du document, mDNS, RFC 6762, DNS-SD, RFC 6763, enregistrement, RFC 9665.