Zusammenfassung

  • RFC 5262 ordnet vollständige Zustände und Deltas und macht verlorene Updates erkennbar; die Garantie gilt für einen bestimmten Feed eines bestimmten Watchers.
  • Ein belastbarer Beleg verbindet Basis, Versionen, Diffs, Beobachter, Autorisierung, Rekonstruktion und Ablauf und hält den späteren Kontaktversuch getrennt.

Der Zähler war optional, die Behauptung absolut

Ein Empfänger erhielt Partial-PIDF-Dokumente ohne version. Die XML-Änderungen ließen sich anwenden, doch ein späterer Bericht nannte den Zustand „lückenlos synchronisiert“. Dafür fehlte die entscheidende Beobachtung: Ohne verwendete Sequenz gab es keinen Nachweis, dass kein Diff verloren ging.

RFC 5262 macht das Attribut optional. Wenn es genutzt wird, kann der Empfänger Reihenfolge und Lücken prüfen. Die Fähigkeit des Formats darf nicht in eine Behauptung über jeden tatsächlichen Feed verwandelt werden.

Der Beleg muss deshalb auch festhalten, ob Versionierung aktiv war und in welchem Nummernraum sie galt.

Voll- und Teildokumente teilen eine Folge

application/pidf-diff+xml umfasst pidf-full und pidf-diff. Der vollständige Inhalt bildet die lokale Basis; der Teilinhalt verwendet XML-Patch-Operationen zum Hinzufügen, Ersetzen und Entfernen.

Bei verwendeter version steigt der Wert zwischen Updates um eins. Derselbe Zähler läuft über Full und Diff hinweg. So kann ein Empfänger Zustände ordnen und eine erwartete 569 erkennen, wenn stattdessen 570 eintrifft.

Der Zähler bewertet aber weder die Richtigkeit der Ausgangsaussagen noch die Vollständigkeit der Offenlegung oder deren Alter gegenüber der realen Welt.

Eine perfekte Folge braucht die richtige Basis

568 folgt 567 nur sinnvoll, wenn beide zum selben Presentity, Watcher, Abonnement, Dialog und Autorisierungskontext gehören. Eine alte oder fremde Basis kann danach eine fehlerfreie Folge empfangen und den falschen Zustand konsistent fortschreiben.

Darum gehören exakte Basisbytes und Hash, Presentity-URI, Watcher, Feed, Medientyp, Zeichensatz und Policy-Version in den Beleg. Eine Startnummer allein schützt nicht vor Basistausch.

Autorisierung erzeugt unterschiedliche legitime Sichten

Präsenzdaten können sensibel sein. Die umgebende Policy bestimmt, welcher Watcher welche Information zu welchem Zeitpunkt erhält. Ein fehlendes Feld kann „falsch“ oder „nicht offengelegt“ bedeuten.

Die Version ordnet nur die erlaubte Projektion. Sie enthüllt keine zurückgehaltenen Fakten. Zwei lückenlose Folgen dürfen voneinander abweichen, wenn ihre Berechtigungen abweichen.

Vergleiche benötigen daher nachgewiesene Policy-Gleichheit. Gleiche Zahlen ohne gemeinsamen Geltungsbereich sind keine gemeinsamen Zustände.

Lückenerkennung ist noch keine Wiederherstellung

Eine Abweichung zwischen erwartetem und empfangenem Wert beweist eine Lücke. Sie repariert sie nicht. Die Anwendung muss Anzeige stoppen, einen neuen Vollzustand beschaffen, Zwischenstände verwerfen oder einen degradierten Modus ausweisen.

Der Wiederherstellungsbeleg nennt erste Abweichung, fehlenden Bereich, letzten vertrauenswürdigen Hash, Ersatzbasis und Sichtbarwerden. Eine erloschene Warnung ist kein Beweis für die Ursache der Erholung.

Aushandlung, Anwendung und Speicherung bleiben getrennt

SIMPLE-Systeme handeln die Unterstützung partieller Benachrichtigung aus. Das belegt Formatkompatibilität. Ein konkretes Diff kann dennoch fehlen, am Selektor scheitern, nur im Speicher existieren oder nie den Nutzer erreichen.

Empfang, XML-Anwendung, Persistenz und Darstellung brauchen eigene Quittungen. Nur ihre Verbindung erklärt, welcher rekonstruierte Zustand tatsächlich handlungswirksam wurde.

Gültiges XML ist keine menschliche Verfügbarkeit

Das Dokument muss wohlgeformt sein und sollte schemagültig sein. Trotzdem kann ein Endgerät abschalten, eine Person ihre Bereitschaft ändern oder eine spätere Sitzung scheitern.

Beweisbar ist: „Dieser Watcher rekonstruierte den zuletzt empfangenen Zustand dieses Feeds.“ Für „die Person war erreichbar“ braucht es den nachfolgenden Kontakt- und Ergebnisbeleg.

Der Partial-Presence-Beleg

Aufzubewahren sind:

  • Presentity, Watcher, Abonnement, Dialog und Feed-Identität;
  • Autorisierungspolicy, Version, Entscheidung und Feldumfang;
  • Medientyp und Zeichensatz;
  • Basisbytes, Hash, Version, Empfang und Ablauf;
  • Bytes, Hash, Version, Reihenfolge und Empfang jedes Diffs;
  • erwartete und empfangene Version sowie Lücken;
  • Operation, Selektor, Vorzustand und Anwendungsergebnis;
  • Zwischenhashes und rekonstruierter Endhash;
  • Wiederherstellungsanforderung, Ersatzbasis und verworfene Zustände;
  • Speicherbestätigung und nachgelagerte Sichtbarkeit;
  • Kontaktversuch, Aushandlung, Zustellung und menschliches oder technisches Ergebnis.

Der Beleg macht Präsenz nicht gewiss. Er hindert eine vollständige Sequenz daran, als vollständige institutionelle Wahrheit aufzutreten.

Sources