Résumé

  • La RFC 3059 permettait à un User Agent SLPv2 de demander, au moyen d’une extension volontairement vide, que chaque URL de la Service Reply soit accompagnée de sa liste complète d’attributs enregistrés.
  • L’identifiant 0x0002 appartenait à la classe des extensions facultatives à ignorer si elles étaient inconnues. Une réponse sans extension déclenchait donc des Attribute Requests URL par URL ; elle ne certifiait pas une liste d’attributs vide.

Le vide servait de verbe

Dans SLPv2, découvrir une adresse et connaître les propriétés du service étaient deux opérations. La Service Request ramenait des URL. L’Attribute Request demandait ensuite les attributs d’une URL ou d’un type de service. Pour quatre résultats, la seconde étape pouvait produire quatre nouveaux allers-retours.

Publiée comme Proposed Standard en février 2001, la RFC 3059 a proposé de transporter ces deux classes d’information dans une seule réponse. Le User Agent ajoutait une Attribute List Extension à sa Service Request. Côté requête, les longueurs de Service URL et d’Attribute List valaient zéro, et les champs correspondants étaient omis.

Cette enveloppe vide n’était pas une observation sur le service. Elle constituait la demande elle-même. Lire ses zéros comme « aucune URL » ou « aucun attribut » reviendrait à transformer la syntaxe d’une question en contenu de la réponse.

La correspondance appartenait à l’URL

Un Service Agent ou Directory Agent compatible renvoyait une extension pour chaque URL Entry. Chaque extension contenait l’URL correspondante et la liste entière des attributs du service. Le texte recommandait le même ordre que celui des URL Entries, mais il inscrivait aussi l’URL dans l’extension.

L’identité explicite avait donc plus d’autorité que la position. Comparer les ordres pouvait révéler une anomalie ; relier aveuglément la troisième extension à la troisième URL sans vérifier le champ URL supprimait au contraire un contrôle offert par le protocole.

La « liste entière » restait celle de l’annonce enregistrée, dans la langue indiquée par la requête. Elle ne dressait pas l’inventaire de tout ce que le service réel savait faire. Une inscription pouvait rester en cache jusqu’à expiration, une capacité non enregistrée restait invisible et une URL découverte pouvait ne plus répondre. La RFC accélérait le transport d’une description, pas la preuve d’une exécution.

Un numéro facultatif organisait le repli

IANA a enregistré 0x0002 pour l’Attribute List Extension. La RFC 2608 classait les identifiants 0x0000 à 0x3FFF parmi les extensions standardisées mais facultatives : un destinataire qui ne les reconnaissait pas devait les ignorer. Ce choix permettait à un ancien pair de répondre normalement.

La contrepartie se trouvait chez le User Agent. Sans extension dans la Service Reply, il devait supposer que le SA ou le DA ne la prenait pas en charge, puis envoyer une Attribute Request pour chaque URL obtenue. L’absence signalait un travail restant. Elle n’était pas une valeur métier égale à zéro.

Cette règle ne se déduit pas du seul mot « extension ». La RFC 3421 a plus tard placé Select et Sort dans une plage obligatoire et prévu OPTION_NOT_UNDERSTOOD pour certains cas. La RFC 3224 a donné une autre forme aux extensions opaques de fournisseur, et la RFC 3082 encore une autre aux abonnements. Ces textes montrent la diversité du mécanisme ; ils ne réécrivent pas rétroactivement 0x0002.

Une exigence de signature pouvait produire le même silence

La Service Request pouvait contenir un SLP Security Parameter Index. Dans ce cas, chaque Attribute List Extension rendue devait inclure un bloc d’authentification correspondant. Si le répondant ne prenait pas en charge ce SPI, ou ne pouvait pas fournir le bloc, il ne devait pas rendre l’extension.

Deux situations distinctes pouvaient ainsi aboutir à la même surface : extension non implémentée, ou contexte d’authentification impossible à satisfaire. La RFC imposait le repli au client, mais ne lui donnait pas un code lui permettant d’attribuer silencieusement l’une ou l’autre cause.

Le bloc lui-même était un reçu limité. D’après la RFC 2608, il permettait de vérifier que les données couvertes n’avaient pas été modifiées et provenaient d’un agent autorisé, avec les paramètres, clés et date d’expiration associés au SPI. Il ne démontrait ni la disponibilité actuelle du service, ni l’autorisation de l’utilisateur, ni le succès d’une opération future.

Le gain de latence ne changeait pas la nature de la preuve

Lorsque les deux parties connaissaient la RFC 3059, une réponse pouvait remplacer une série de demandes d’attributs. La topologie du dialogue devenait plus courte. L’autorité de l’annonce, elle, restait la même.

Ce partage explique une catégorie d’erreurs toujours actuelle. Une interface affiche « aucune capacité » parce que l’enrichissement n’est pas revenu. Un inventaire écrit « zéro attribut » parce que le chemin de compatibilité n’a pas été exécuté. Un sélecteur automatique élimine une URL parce qu’il confond « non transporté ici » avec « inexistant ». Le protocole avait prévu le remède : constater le reçu manquant, puis poser les questions URL par URL.

Sources