Résumé

  • RFC 5262 permet d’ordonner un document complet et ses deltas, puis de repérer un numéro manquant ; cette continuité reste celle d’un flux destiné à un observateur donné.
  • Une preuve exploitable conserve le socle complet, chaque diff, l’observateur, la politique d’autorisation, la reconstruction et l’expiration, sans confondre cet ensemble avec le résultat d’un contact réel.

Deux observateurs, deux suites parfaites

Un serveur de présence livre à une équipe d’astreinte une suite complète : un état initial, puis tous les deltas successifs. Il livre à un partenaire externe une autre suite, tout aussi complète. La première contient un moyen de contact interne que la seconde n’est pas autorisée à voir.

Aucun paquet n’a été perdu. Aucun compteur n’est faux. Les deux reconstructions diffèrent parce que la politique le demande.

Le numéro de version répond donc à une question précise : cette vue a-t-elle reçu sa continuité ? Il ne répond pas à la question plus large : tout ce qui est vrai au sujet du presentity se trouve-t-il ici ?

Un compteur commun aux documents complets et partiels

RFC 5262 définit pidf-full et pidf-diff pour le type application/pidf-diff+xml. Le document complet établit le socle local. Le diff transporte des opérations add, replace et remove issues du cadre XML Patch.

Lorsque l’attribut optionnel version est employé, il augmente de un entre deux mises à jour. Le même compteur couvre les documents complets et les deltas. Le destinataire peut ordonner les arrivées et constater qu’une étape manque.

Cette propriété est forte, mais bornée. Elle ne vérifie pas les affirmations placées dans le premier document, ne révèle pas un champ volontairement masqué et ne mesure pas le temps écoulé entre un changement réel et sa publication.

Une suite exacte peut partir d’un mauvais socle

La version 568 ne devient une continuation fiable de 567 que si 567 est bien le socle accepté pour le même presentity, le même abonnement et la même politique. Une cache ancienne peut recevoir ensuite une série parfaitement ordonnée et produire une erreur parfaitement reproductible.

Il faut donc conserver les octets et le hachage du document complet, son numéro, l’URI du presentity, l’identité de l’observateur, le dialogue ou flux, le type de contenu, le jeu de caractères et la version de politique. Le seul numéro de départ ne protège pas contre une substitution de socle.

La politique fabrique une vue légitime

Les données de présence peuvent être sensibles. Le protocole environnant doit décider quelles informations peuvent être données à quel observateur et à quel moment. Une absence de champ ne signifie donc pas nécessairement que le fait est faux ; elle peut signifier que sa divulgation est interdite.

La continuité ne traverse pas cette frontière d’autorisation. Elle ordonne ce qui a été permis, sans exposer ce qui a été retenu. Deux abonnements portant le même numéro apparent ne sont comparables que si leur portée et leur séquence ont été définies comme communes.

Détecter un trou ne le répare pas

Si le destinataire attend 569 et reçoit 570, le compteur révèle la perte. Il ne commande pas à lui seul la récupération. L’application peut suspendre l’affichage, demander un nouvel état complet, écarter ses intermédiaires ou continuer en mode dégradé.

La preuve de reprise doit enregistrer la première version inattendue, la plage absente, le dernier hachage fiable, le nouvel état complet et le moment où celui-ci devient visible. Sinon, une alerte peut repasser au vert sans montrer ce qui a restauré la cohérence.

Recevoir, appliquer et publier sont trois étapes

Le support du type MIME se négocie dans les systèmes SIMPLE. Cette négociation prouve une capacité commune, pas l’application d’un diff particulier. Les sélecteurs RFC 5261 peuvent encore échouer ; une application réussie peut rester en mémoire ; un stockage réussi peut ne pas être exposé au consommateur.

Le reçu doit relier l’ordre de réception au résultat de chaque opération XML, aux hachages intermédiaires, à la persistance et au document effectivement lu en aval.

Un XML valide n’est pas une personne disponible

Le document doit être bien formé et devrait être valide. Ces garanties appartiennent à la représentation. Elles ne prouvent ni qu’un terminal répond encore, ni qu’une personne souhaite être contactée, ni qu’une session ultérieure réussira.

La formule honnête est : « cet observateur a reconstruit le dernier état reçu pour ce flux ». Transformer cette phrase en « la personne était disponible » ajoute une conclusion que le compteur n’a jamais mesurée.

Le reçu de présence partielle

Conserver au minimum :

  • presentity, observateur, abonnement, dialogue ou identité de flux ;
  • politique d’autorisation, version, décision et portée divulguée ;
  • type MIME et jeu de caractères acceptés ;
  • octets, hachage, version, réception et expiration du socle complet ;
  • octets, hachage, version et ordre de chaque diff ;
  • version attendue, version reçue et tout trou détecté ;
  • opération, sélecteur, préimage et résultat d’application ;
  • hachages intermédiaires et reconstruction finale ;
  • demande de reprise, nouvel état complet et intermédiaires abandonnés ;
  • confirmation de stockage et exposition aval ;
  • tentative de contact, négociation et résultat humain ou applicatif.

Ce reçu ne transforme pas la présence en certitude. Il empêche une continuité de transport de se présenter comme une vérité institutionnelle complète.

Sources