Résumé

  • RFC 5263 sérialise les NOTIFY partiels en imposant une réponse finale ou une expiration avant l’envoi suivant pour le même Request-URI ; cette barrière règle le flux, elle ne constitue pas un reçu de persistance chez le watcher.
  • Une preuve exploitable relie l’abonnement et la version au corps NOTIFY, à la réponse SIP, au résultat de parsing et de patch, aux empreintes avant et après, à l’acquittement du stockage et à l’exposition aval.

Le format a changé, le compteur a survécu

Un watcher recevait des deltas. Le Presence Agent est ensuite revenu au PIDF complet. Le watcher a jeté l’information de présence qu’il avait accumulée, mais il a conservé son compteur local. Plus tard, le format partiel est revenu et la numérotation a repris.

À chaque échange, la couche SIP pouvait répondre correctement. Pourtant, le même nombre ne désignait pas une seule histoire de stockage : des représentations avaient été abandonnées, un état complet les avait remplacées, puis une nouvelle série de deltas avait commencé.

Cette situation rend visible la limite du 200. Il atteste la clôture automatique d’une transaction acceptable. Il ne raconte ni la migration de représentation, ni la copie effectivement conservée, ni ce que le consommateur aval a lu.

La réponse finale protège la fenêtre d’envoi

Le Presence Agent ne doit pas émettre un nouveau NOTIFY partiel pour le même Request-URI avant d’avoir reçu la réponse finale au précédent, ou avant l’expiration de celui-ci. La règle évite de faire circuler simultanément une série de deltas dépendants sans borne claire.

Le cadre générique des événements SIP précise qu’une notification jugée acceptable reçoit normalement 200. La transaction ne doit pas durer au-delà du traitement automatisé nécessaire. Le subscriber ne doit surtout pas attendre la réponse d’un utilisateur avant de rendre sa réponse finale.

La norme construit donc une barrière de transport volontairement étroite. Elle permet d’avancer la file et de traiter l’échec transactionnel. Elle n’a pas la portée d’un accusé de lecture, d’une validation humaine ou d’un engagement durable de l’application.

L’abonnement donne son sens à la version

Le watcher qui accepte le mécanisme annonce application/pidf-diff+xml et application/pidf+xml. Sa préférence peut être exprimée, mais le Presence Agent conserve une décision soumise à sa politique locale.

La première notification au format partiel contient un état complet et initialise la version à un pour cet abonnement. Les documents suivants avancent le compteur. Un rafraîchissement ne le remet pas à zéro ; la terminaison de l’abonnement, oui.

Il faut donc conserver l’identité de l’abonnement, du dialogue et du corps avec la réponse. Une version isolée n’est pas une coordonnée mondiale. Un 200 isolé ne précise même pas quelle mutation locale devait être réalisée.

L’envoi réussi décrit le point de vue de l’émetteur

Le Presence Agent incrémente par rapport au document de présence partielle précédemment envoyé avec succès au watcher concerné. Il attend ensuite la fin ou l’expiration de la transaction avant de libérer la version suivante.

Cette chronologie établit ce que l’émetteur connaît : le corps est parti, une réponse finale est revenue ou le délai a expiré, la fenêtre peut évoluer. Elle ne montre pas la copie complète détenue après traitement, l’écriture sur disque, la survie à un redémarrage ou l’empreinte réellement lue par un autre composant.

Dans un fonctionnement sain, les étapes se suivent presque immédiatement. En gouvernance, leur proximité n’autorise pas leur fusion. La preuve nécessaire apparaît précisément quand l’une d’elles s’écarte des autres.

Une erreur locale peut rester muette vers l’amont

Le watcher compare chaque version à son compteur local. Une valeur égale ou inférieure est considérée comme une défaillance du Presence Agent et devrait être ignorée. Une hausse d’une unité permet d’appliquer le delta. Une hausse supérieure signale une ou plusieurs notifications perdues et conduit à rafraîchir ou terminer l’abonnement.

Le document prévoit aussi l’échec du traitement lui-même. Le watcher devrait renouveler l’abonnement et peut revenir au PIDF complet en n’annonçant plus le type partiel. RFC 5263 observe qu’il est peu raisonnable de signaler cette erreur au notifier, même si elle provient du traitement côté notifier.

Ainsi, le journal amont peut rester propre tandis que le watcher déclenche discrètement une resynchronisation. Une suite de réponses finales n’est pas une suite de commits applicatifs.

Le rafraîchissement apporte un nouvel ancrage, pas une histoire

Lors d’un SUBSCRIBE de rafraîchissement ou de terminaison, le Presence Agent devrait envoyer un document complet. Ce comportement fournit un point de reprise utile. Il ne reconstitue pas ce qui s’est produit avant lui.

Si le delta précédent a échoué après la réponse SIP, le nouvel état complet peut remettre la vue courante en cohérence. Il ne prouve pas que l’état intermédiaire avait été affiché, stocké ou utilisé. Le reçu doit enregistrer le motif du rafraîchissement, l’ancienne empreinte, la nouvelle et les données abandonnées.

Sans ces éléments, la reprise efface la panne au lieu de l’expliquer.

L’authenticité du message reste une autre couche

RFC 5263 hérite des exigences de confidentialité, d’intégrité, d’authenticité, de prévention du rejeu et de résistance au déni de service du cadre de présence SIP. Il recommande TLS dans son contexte d’origine et permet S/MIME pour protéger SUBSCRIBE et NOTIFY. RFC 8996 a ensuite mis à jour la dépendance TLS en dépréciant TLS 1.0 et 1.1.

Une injection peut faire croire à une rupture de séquence et provoquer une demande d’état complet. Protéger le message contre cette attaque est indispensable. Mais un message authentique peut encore échouer dans le parseur, le patch, le stockage ou l’exposition.

La provenance cryptographique et la clôture transactionnelle appartiennent au reçu. Aucune ne remplace l’observation de l’état appliqué.

Le reçu d’état du watcher

Pour une décision à conséquences, conservez :

  • le presentity, le watcher, le Request-URI, l’abonnement, le dialogue et l’événement ;
  • les types acceptés, les préférences et le choix local du Presence Agent ;
  • Call-ID, tags, CSeq, type, octets, empreinte et heure de réception du NOTIFY ;
  • la version liée à l’abonnement et la version précédente attendue ;
  • le code de réponse SIP, son heure, l’expiration ou la tentative suivante ;
  • le résultat du parseur et l’erreur précise ;
  • l’empreinte de l’état complet avant application et le résultat du patch ;
  • l’empreinte reconstruite et le compteur local après application ;
  • l’acquittement du stockage durable et la génération du processus ;
  • tout rafraîchissement, repli, changement de format ou nouvel état complet ;
  • l’identité, l’empreinte et l’heure de l’exposition aval ; et
  • l’affichage, la tentative de contact, la livraison et le résultat humain ou de service.

Ce reçu ne ralentit pas nécessairement SIP. Il empêche seulement la couche institutionnelle de transformer la vitesse du transport en certitude sur l’application.

Sources