Zusammenfassung

  • RFC 5264 wendet angenommene Deltas auf eine vollständige lokale Publication an. Ohne rechtzeitigen Refresh wird dieser gesamte Zustand gelöscht; der Kompositor entfernt nicht nur den letzten Patch und rekonstruiert keine Vorgängerversion.
  • Eine belastbare Quittung verbindet Entity-Tag-Kette, Body, Vorher- und Nachher-Hash, Laufzeit, Refresh, Commit und Wirkung auf den zusammengesetzten Zustand.

Die falsche Frage lautet: Welcher Patch lief ab?

Nach einer vollständigen Erstveröffentlichung änderte ein Endgerät nur noch einzelne Felder. Eine Aktivität kam hinzu, ein Hinweis verschwand, eine Kontaktpriorität änderte sich. Jeder PUBLISH war klein und erfolgreich.

Später fehlte der Refresh. Der Kompositor entfernte den gesamten Beitrag des Endgeräts. Wer in Patch-Kategorien denkt, sucht nun den Patch, dessen Wirkung zurückgenommen wurde. RFC 5264 gibt darauf keine Antwort, weil die Frage die falsche Einheit voraussetzt.

Abgelaufen ist die Publication. Die Deltas hatten deren jeweils aktuellen Gesamtzustand erzeugt.

Transportgranularität ist keine Lebenszeitgranularität

RFC 3903 beschreibt PUBLISH-Zustand als Soft State mit ausgehandelter Lebensdauer. RFC 5264 ändert nicht dieses Objektmodell, sondern die Transportform.

Die erste partielle Publication enthält unter application/pidf-diff+xml einen vollständigen pidf-full-Körper. Spätere Änderungen dürfen pidf-diff oder erneut vollständigen Zustand verwenden. Der Kompositor hält danach in beiden Fällen ein vollständiges Dokument.

Ein Delta spart Bytes. Es teilt die Publication aber nicht in selbständige Mietobjekte, deren Fristen einzeln verwaltet werden könnten.

Eine Entity-Tag-Kette ordnet die Übergänge

Jeder erfolgreiche PUBLISH erzeugt ein SIP-ETag. Der nächste Refresh, die nächste Änderung oder Entfernung nennt den erwarteten Zustand in SIP-If-Match. Zusammen mit Request-URI und Event-Paket identifiziert die Bedingung die Publication.

Das partielle PIDF-Format besitzt zusätzlich ein Versionsattribut. RFC 5264 verwendet es nicht als zweite Reihenfolge, weil ein Widerspruch zwischen Nummer und Entity-Tag eine unbestimmte Fehlerlage schaffen würde.

Für die Beweiskette genügt deshalb der gespeicherte Diff-Body nicht. Ohne altes Tag, Bedingung, Antwort und neues Tag fehlt die kausale Zuordnung zum anerkannten Zustand.

Der Kompositor führt aus, er archiviert nicht

add, replace und remove werden nacheinander auf das lokal gespeicherte Dokument angewandt. Das Ergebnis geht als vollständiger Zustand in die Kompositionslogik.

Die Spezifikation verlangt kein Patchjournal. Sie erklärt ausdrücklich, dass beim Ablauf nicht auf eine ältere Version zurückgerollt wird. Wer früheren Zustand wiederherstellen will, muss ihn als vollständige Publication neu einreichen.

Diese Grenze verhindert eine falsche Gleichsetzung mit Versionsverwaltung. Ein deterministischer Patch kann einen neuen Zustand erzeugen, ohne dessen gesamte Ahnenreihe dauerhaft zu speichern.

Ein kleiner letzter Body kann einen großen Verlust ankündigen

Änderungen an Expires gelten für die vollständige, bereits gepatchte Publication. Bleibt der Refresh aus, muss der Kompositor sie vollständig leeren.

Damit besteht keine Proportionalität zwischen der Größe der letzten Nachricht und der Größe des gefährdeten Zustands. Ein winziger Delta-Body kann der letzte erfolgreiche Schritt vor dem Verlust eines umfangreichen Beitrags sein.

Umgekehrt bleibt die Wirkung eines alten Deltas über viele Refreshes erhalten. Ihre Lebensdauer hängt nicht am ursprünglichen Patch, sondern am Fortbestand der Publication.

Der Umfang endet an der Publication

Mehrere Geräte können für dieselbe Ressource getrennte Publications unterhalten. Der Kompositor bildet daraus einen zusammengesetzten Zustand und kann zusätzlich nicht ablaufenden Hard State verwenden.

Das Löschen einer abgelaufenen Publication vernichtet daher nicht automatisch alle Beiträge zur Ressource. Welche Sicht übrig bleibt, bestimmen die verbleibenden Publications und die Kompositionspolitik.

Ein Audit muss den entfernten Beitrag benennen, die verbleibenden Eingaben erfassen und die Composite-Hashes vergleichen. „Der ganze Präsenzzustand wurde gelöscht“ ist nur innerhalb der betroffenen Publication präzise.

Vor dem Commit gibt es echte Rückkehr zum alten Zustand

Ein pidf-diff darf keine Initial Publication bilden. Dokumentfehler führen zu 400 und können RFC-5261-Diagnosen tragen. Andere Fehler vor vollständiger Verarbeitung erfordern 500 und die Wiederherstellung des ursprünglich gespeicherten Dokuments.

Hier wurde der Übergang nicht angenommen; deshalb bleibt der Vorgängerzustand bestehen. Späterer Ablauf betrifft dagegen bereits angenommenen Soft State und entfernt die Publication.

Diese Ereignisse müssen getrennte Typen haben: abgelehnte Vorbedingung, ungültiger Patch, erfolgreicher Commit, explizite Entfernung und natürlicher Ablauf. Ein Sammelbegriff „Publish-Fehler“ zerstört die Ursache.

Quittung für Publication und Laufzeit

Für folgenreiche Nutzung sind zu sichern:

  • Request-URI, Event-Paket, Publisher, Presentity und Publication-Identität;
  • vorheriges Entity-Tag, SIP-If-Match und neues SIP-ETag;
  • vollständiger oder partieller Body, Bytes, Hash und Empfangszeit;
  • Reihenfolge und Ergebnis aller Patchoperationen;
  • vollständiger Dokumenthash vor und nach der Verarbeitung;
  • angeforderte, gewährte und wirksame Lebensdauer;
  • Refresh-Frist, Anfrage, Antwort und Commit-Zeit;
  • explizite Entfernung oder Ablauf samt gelöschtem Zustand;
  • andere Publications und Hard-State-Beiträge;
  • Composite-Hash, Policy-Version und nachgelagerte Meldung; sowie
  • Anzeige, automatisierte Entscheidung oder menschliches Ergebnis.

Das Entity-Tag belegt einen bedingten Übergang. Der Commit belegt lokalen Zustand. Der Composite-Hash belegt das Ergebnis einer Politik. Keine dieser Ebenen belegt ohne weitere Beobachtung Zustellung oder menschliche Wirkung.

Sources