Résumé

  • RFC 9590 autorise un serveur incapable de consulter les annotations d’une boîte à omettre la réponse METADATA correspondante, puis à terminer LIST par un OK étiqueté.
  • NIL, absence de réponse, nom \NonExistent et parent renvoyé uniquement pour ses descendants décrivent quatre situations différentes ; les fondre dans une cellule vide détruit la preuve.

Le piège ne se trouve pas dans une erreur obscure. Il se trouve dans une réponse apparemment propre. Le client demande les boîtes de premier niveau et leur couleur. Il reçoit une série de LIST, quelques METADATA, puis A01 OK List completed. Un indicateur passe au vert. Une couleur manque pourtant.

La bonne question n’est pas « la commande a-t-elle réussi ? ». Elle est : « pour quelles paires boîte–entrée disposons-nous d’une réponse explicite ? »

Une économie de requêtes, pas une fusion des significations

RFC 9590 enregistre la capacité LIST-METADATA et ajoute METADATA aux options de retour de LIST-EXTENDED. Le client peut donc demander, en une seule commande, les noms, les attributs LIST et certaines annotations. Il évite la boucle consistant à envoyer GETMETADATA boîte après boîte.

Pour chaque boîte listable qui correspond au motif canonique et aux options de sélection, le serveur doit renvoyer LIST puis une ou plusieurs réponses METADATA. RFC 5464 permet de regrouper plusieurs couples entrée–valeur ou de les répartir sur plusieurs réponses. Le dossier logique n’est donc ni « une ligne par boîte » ni « une réponse par commande » : c’est un ensemble de couples indexés par boîte et par entrée demandée.

Puis vient l’exception décisive. Si le serveur ne parvient pas à consulter les annotations d’une boîte donnée, il peut supprimer la réponse METADATA correspondante. LIST peut malgré tout finir avec un OK. Le reçu global ferme l’échange ; il ne complète pas magiquement chaque résultat local.

Quatre silences qui ne disent pas la même chose

NIL est une réponse. Dans le modèle de RFC 5464, il signifie que l’entrée n’a pas de valeur. L’exemple de RFC 9590 montre la couleur de foo renvoyée explicitement à NIL parce qu’elle n’a pas été définie. Le serveur a répondu à la question portant sur cette entrée.

Une omission après échec de consultation n’est pas NIL. Aucun couple entrée–valeur n’a été observé. On connaît le succès de la commande, mais pas l’état de l’annotation.

Un nom marqué \NonExistent relève encore d’une autre logique. RFC 5258 précise que ce nom ne désigne pas une boîte existante et implique \NoSelect. Il peut néanmoins apparaître comme élément de hiérarchie, notamment parce qu’il possède des descendants. L’absence de METADATA pour ce nom ne prouve pas une panne de consultation.

Enfin, avec SUBSCRIBED RECURSIVEMATCH, LIST peut renvoyer un parent uniquement pour rendre visible un descendant qui satisfait les critères. Si le parent ne satisfait pas lui-même la sélection, RFC 9590 n’exige pas sa réponse METADATA. Ici, le silence vient du périmètre de sélection.

Une interface peut choisir la même apparence pour ces quatre cas. Un journal d’audit doit conserver leur différence.

Construire le dénominateur avant de célébrer le taux

Le taux de couverture utile part des boîtes qui correspondent au motif, satisfont les options de sélection et constituent réellement les cibles d’annotation. On croise ensuite ce groupe avec les entrées demandées. Les couples explicitement reçus — valeur concrète ou NIL — forment le numérateur. Les parents présents seulement pour le contexte récursif ne gonflent pas le dénominateur ; les couples éligibles mais omis ne s’en évaporent pas.

Ce calcul oblige à conserver le tag de commande, le motif, les options de sélection, les entrées demandées, les noms et attributs LIST, les couples attendus, les valeurs reçues, les NIL, les absences, les résultats d’une éventuelle relance, l’époque de session et la décision de cache. Sans cette matière, « synchronisation réussie » n’est qu’une interprétation irréversible d’un jeton OK.

RFC 5258 rappelle en outre qu’un descendant peut être supprimé ou renommé après la réponse LIST mais avant son accès par le client. Même un inventaire complet à l’instant de la réponse n’est pas un univers de boîtes figé. RFC 9051 organise l’état de la commande ; il ne promet ni fraîcheur durable, ni rendu correct, ni observation humaine.

La norme trace une frontière de compétence

Les registres IANA rendent LIST-METADATA et l’option de retour METADATA identifiables par les implémentations. Leur présence normalise un vocabulaire. Elle ne mesure ni déploiement, ni conformité, ni fréquence d’omission.

La primauté du code en exécution conduit à lire le résultat au niveau le plus bas qui puisse être vérifié : les réponses réellement émises, analysées et rattachées à la bonne commande. La spécification minimale commune fixe leur syntaxe et leur sens. Le délai de relance, l’âge maximal d’un cache, le traitement d’une valeur inconnue et le seuil d’acceptation restent des décisions locales ; les faire passer pour le sens de OK reviendrait à transformer coordination en autorité imaginaire.

Sources