Résumé

  • Après traitement de terminate et envoi de sa réponse, le service RFC 3343 n’émettait plus de nouvelles mises à jour, mais celles déjà parties pouvaient encore arriver.
  • Le code 250 prouvait donc une coupure côté service, pas la vidange du maillage; corrélation, génération d’abonnement, actualité et décision du consommateur restaient distinctes.

On imagine volontiers la résiliation comme une barrière absolue. Tout ce qui arrive ensuite paraît fautif. RFC 3343 décrivait une frontière plus précise : le producteur arrête ses émissions futures, tandis que le réseau conserve la réalité physique des messages remis auparavant aux relais.

Une mise à jour tardive et une résiliation réussie pouvaient ainsi être vraies ensemble. Le problème n’était pas de choisir laquelle croire, mais de conserver le moment et la portée de chacune.

Trois opérations durables

Le service de présence APEX répondait à l’adresse connue apex=presence dans chaque domaine administratif. Il permettait de publier une entrée de présence, de s’abonner à celle d’un endpoint et d’observer les endpoints qui s’y abonnaient.

Un abonnement renvoyait immédiatement l’état courant. Avec une durée non nulle, il envoyait ensuite les changements jusqu’à expiration, puis un terminate. Une durée nulle réalisait un sondage unique. L’opération watch répondait d’abord 250, listait les abonnés actuels par notify, puis signalait les abonnements et fins d’abonnement.

Le service devait conserver en stockage persistant les entrées et les opérations en cours. Les publish et notify initiés par le service reprenaient l’identifiant de transaction de l’abonnement ou de la surveillance. Cet identifiant retraçait la filiation; il ne garantissait pas que le message restait d’actualité.

Ce que prouvait la réponse 250

Le consommateur comme le service pouvait terminer une opération. Un identifiant inconnu pour l’auteur provoquait l’erreur 550. Un identifiant valide supprimait l’opération en cours et produisait la réponse 250.

Le texte avertissait pourtant qu’après terminate, l’auteur pouvait recevoir encore des mises à jour de présence ou de watcher. Le service n’en envoyait plus après avoir traité la résiliation et expédié la réponse, mais des messages antérieurs pouvaient rester en transit.

La réponse prouvait donc le changement d’état dans le service et sa politique d’envoi future. Elle ne certifiait pas l’absence de données dans les tampons des relais, les connexions, les ordonnanceurs ou la file d’entrée du consommateur. Une vraie barrière de vidange aurait dû rendre compte de chaque travail antérieur; ce protocole ne prétendait pas fournir cette preuve.

Même identifiant, autre autorité

La mise à jour tardive conservait l’identifiant de l’opération terminée. Le consommateur pouvait la rattacher au bon passé. Mais une corrélation exacte n’accordait pas le droit de modifier l’état présent.

Il fallait mémoriser une génération ou une pierre tombale de l’abonnement. Selon le produit, la mise à jour pouvait être rejetée, archivée, comparée à un nouvel instantané ou mise en quarantaine. Une application ne devait pas confondre « appartient à cette opération » avec « cette opération est encore active ».

Le risque augmentait lors d’un nouvel abonnement au même sujet. RFC 3343 terminait silencieusement l’ancien avant de poursuivre. La relation logique semblait identique, mais les générations ne l’étaient pas. Sans identifiant de génération, une ancienne publication pouvait être prise pour la première publication du nouveau flux.

Présence enregistrée et attachement vivant

Chaque domaine gardait une entrée pour tous ses endpoints, même non attachés au maillage. L’entrée contenait lastUpdate, des URI et des tuples avec destination, availableUntil et capacités. Son existence ne prouvait donc pas une connexion active ni une livraison réussie.

La publication possédait un contrôle atomique distinct : le lastUpdate fourni devait être sémantiquement identique à la valeur stockée, sinon le service répondait 555. Un succès 250 confirmait la mutation du registre de présence, non la réception de cette mutation par chaque abonné.

Une mise à jour tardive pouvait ainsi être authentique, correctement corrélée et déjà dépassée pour la décision courante. Ces qualités ne s’annulent pas; elles doivent être enregistrées séparément.

Portée historique et confidentialité

RFC 3343 a été publié en avril 2003 comme protocole Experimental. Il est aujourd’hui Historic. L’historique IETF du 29 juillet 2012 indique, avec la réserve « à la connaissance de l’IETF », qu’aucune mise en œuvre des RFC 3340 à 3343 n’avait été déployée et que leurs fonctions étaient fournies par XMPP, largement déployé selon RFC 6120 et RFC 6121.

Cela ne dit pas que la course de résiliation a causé cette trajectoire. Le document ne donne ni incident ni mesure. Il relevait séparément que les fuseaux horaires des horodatages pouvaient révéler une localisation et autorisait la conversion suivie de -00:00 pour masquer cette information.

La discipline durable consiste à conserver des reçus distincts pour création, remise au transport, résiliation, coupure d’émission, vidange, arrivée et décision. Si la preuve de vidange manque, il faut l’admettre. Une annulation peut être accomplie pendant que son passé continue d’approcher.

Sources