Résumé

  • Dans RFC 5264, les patchs successifs sont incorporés à une publication complète identifiée par une lignée d’entity-tags. L’expiration sans rafraîchissement supprime cette publication complète, pas seulement le dernier delta.
  • La preuve exploitable doit relier corps, précondition, état complet avant et après, durée de vie, rafraîchissement, décision du compositeur et effet sur l’état composite.

Reconstituer le document à rebours ne fait pas partie du protocole

Imaginons un état initial comportant trois services. Un premier delta modifie la disponibilité, un second retire une note devenue fausse, un troisième change une priorité de contact. Le compositeur applique chaque opération à la copie complète qu’il détient.

À l’échéance, il ne possède pas nécessairement trois patchs capables de refaire l’histoire en sens inverse. RFC 5264 précise au contraire qu’il ne conserve pas un journal des patchs à cette fin. La publication actuelle est un résultat, pas une pile réversible.

Si cette publication expire, le résultat entier est effacé. Pour revenir à un état antérieur, le producteur doit publier un état complet qui l’exprime de nouveau.

L’économie de bande passante ne change pas l’objet de durée de vie

Le mécanisme répond à une contrainte concrète : répéter un grand document PIDF pour une petite variation coûte cher, surtout sur un lien lent ou à forte latence. Le format pidf-diff transporte uniquement les opérations utiles.

Mais la durée de vie vient de PUBLISH. RFC 3903 définit un état souple, créé pour une période négociée et renouvelé par des requêtes ultérieures. RFC 5264 ne crée pas un bail par élément XML. Il fournit une autre manière de modifier le même état souple.

Le premier message du mécanisme partiel contient d’ailleurs un pidf-full. Les messages suivants peuvent envoyer un delta ou un nouvel état complet. Dans les deux cas, le compositeur finit avec une publication complète courante.

L’entity-tag est la charnière causale

Chaque publication réussie reçoit un SIP-ETag. La requête qui rafraîchit, modifie ou supprime l’état présente cette valeur dans SIP-If-Match. La précondition désigne la version de la publication que le client croit modifier.

RFC 5264 choisit ce mécanisme comme seul ordre de publication. Le format PIDF partiel possède bien un attribut de version, mais l’utiliser en parallèle créerait deux autorités susceptibles de se contredire. Le document préfère une seule lignée conditionnelle.

La conséquence documentaire est importante : un fichier de delta sans entity-tag précédent, sans réponse et sans nouvel entity-tag ne prouve pas une mutation acceptée. Il montre une intention de modification, pas l’état reconnu par le compositeur.

Le traitement convertit les opérations en état

Un pidf-diff peut ajouter, remplacer ou retirer des éléments et des attributs. Le compositeur exécute les opérations dans l’ordre sur sa copie locale. Le document obtenu est ensuite soumis à la logique de composition comme une présence complète.

À cet instant, la distinction « complet ou partiel » décrit le message reçu, non la forme de l’état conservé. L’application peut choisir la granularité des changements et regrouper plusieurs événements liés. Si le delta devient plus volumineux que le document complet, elle devrait envoyer le document complet lorsque la comparaison est possible.

La bonne unité d’audit est donc la transition du document complet : empreinte avant, opérations appliquées, empreinte après et nouvel identifiant conditionnel.

Expirer signifie retirer la contribution courante

L’expiration s’applique à la publication complète après patch. Sans rafraîchissement, le compositeur doit la vider. Il ne peut pas déduire que seule la dernière opération était temporaire, car le protocole ne lui donne ni cette sémantique ni une chronologie de restauration.

Cette règle révèle un risque de gouvernance : la taille du dernier message ne mesure pas l’ampleur de l’état qui dépend du délai. Quelques octets peuvent précéder la disparition de toute la contribution du producteur.

Il faut donc surveiller le bail et le rafraîchissement avec autant de soin que l’application des patchs. Un tableau de bord centré sur le taux de réussite des modifications peut rester vert jusqu’au moment où la publication entière expire.

Toute la publication ne veut pas dire toute la ressource

Un même présentity peut recevoir des publications de plusieurs terminaux. RFC 3903 permet au compositeur de réunir ces contributions ; il peut aussi disposer d’un état dur configuré séparément et non expirant.

La suppression imposée par RFC 5264 vise la publication expirée. Les autres publications ne sont pas automatiquement détruites. L’état composite visible après l’opération dépend des contributions restantes et de la politique de composition.

Cette précision évite deux erreurs opposées : minimiser l’événement comme disparition d’un patch, ou l’exagérer comme suppression universelle de la ressource. L’enregistrement doit identifier exactement la contribution retirée et le composite recalculé.

Le rejet protège l’ancien état avant le commit

Les branches d’erreur possèdent une autre logique. Un delta présenté comme publication initiale est invalide, car l’initialisation doit contenir un état complet. Une erreur de traitement du document entraîne un rejet 400, éventuellement accompagné d’un diagnostic RFC 5261. Une autre erreur avant traitement complet conduit à 500 et au rétablissement de l’état local original.

Ici, l’ancien état subsiste parce que la transition n’a pas été acceptée. Après une acceptation réussie, il ne s’agit plus d’un essai : le résultat est la publication courante. Son expiration ultérieure ne déclenche pas le même retour arrière.

Il faut donc distinguer trois événements : tentative rejetée, transition conditionnelle acceptée et publication arrivée à échéance. Les fusionner sous le mot « échec » détruit la causalité.

Le reçu de publication complète

Pour une utilisation à conséquences, conservez :

  • Request-URI, package d’événement, producteur, presentity et identifiant de publication ;
  • entity-tag attendu, valeur SIP-If-Match et entity-tag retourné ;
  • type complet ou partiel, octets, empreinte et heure du corps ;
  • résultat ordonné de chaque ajout, remplacement ou retrait ;
  • empreintes du document complet avant et après traitement ;
  • durée demandée, durée accordée, échéance et marge de rafraîchissement ;
  • requête de rafraîchissement, réponse et confirmation du commit ;
  • suppression explicite ou expiration naturelle et état retiré ;
  • autres publications actives et état dur restant ;
  • empreinte du composite, politique appliquée et notification aval ; et
  • affichage, décision automatique ou résultat humain ultérieur.

Ce reçu maintient les couches de réalité séparées. L’entity-tag prouve un ordre conditionnel. Le stockage du compositeur prouve un état local. La composition prouve un résultat calculé. Aucun de ces faits ne prouve seul ce qu’un watcher a reçu ou ce qu’une personne a décidé.

Sources