Zusammenfassung

  • RFC 5263 lässt einen Presence Agent vor der nächsten partiellen NOTIFY für dieselbe Request-URI auf die letzte Antwort oder den Timeout warten. Das serialisiert Transaktionen, ist aber keine dauerhafte Empfangsbestätigung des Beobachterzustands.
  • Ein belastbarer Beleg verknüpft Abonnement, Version und NOTIFY-Inhalt mit SIP-Antwort, Parser- und Patch-Ergebnis, Vorher- und Nachher-Hash, Speicherquittung und nachgelagerter Sichtbarkeit.

Die Präferenz war keine Zusage für den gewählten Pfad

Der Beobachter kündigte den partiellen Medientyp mit hoher Präferenz an. Der Presence Agent durfte sich dennoch aufgrund lokaler Richtlinien für vollständige Dokumente entscheiden. Später wechselte er zum partiellen Format und musste zunächst einen vollständigen Zustand senden.

Alle SUBSCRIBE- und NOTIFY-Transaktionen konnten korrekt beantwortet werden. Trotzdem ließ sich aus der ursprünglichen Präferenz nicht ableiten, welcher Darstellungsweg tatsächlich genutzt wurde oder welche lokale Kopie am Ende bestand.

Das Gleiche gilt für 200 OK. Die Antwort bestätigt eine akzeptable Transaktion. Sie ist keine Zusage über die gesamte Verarbeitungskette hinter der SIP-Schicht.

Eine finale Antwort öffnet das nächste Sendefenster

Der Presence Agent darf für dieselbe Request-URI keine neue partielle NOTIFY senden, bevor die vorherige eine finale Antwort erhalten hat oder abgelaufen ist. Damit bleibt die Reihe voneinander abhängiger Änderungen beherrschbar.

Das allgemeine SIP-Ereignismodell sieht für eine akzeptable NOTIFY normalerweise 200 vor. Eine Transaktion soll nicht länger dauern als die automatisierte Verarbeitung benötigt. Auf eine Reaktion des Benutzers darf der Subscriber ausdrücklich nicht warten.

Diese Grenze ist für Flusssteuerung und Fehlerbehandlung wertvoll. Sie wurde nicht als Lesebestätigung, menschliche Freigabe oder universeller Commit-Nachweis definiert.

Der Zähler gehört zum Abonnement

Ein Beobachter erlaubt partielle Benachrichtigungen, indem er application/pidf-diff+xml und application/pidf+xml in Accept angibt. Präferenzen helfen bei der Auswahl, sofern die lokale Richtlinie des Presence Agent nichts anderes verlangt.

Die erste Nachricht im partiellen Format enthält den vollständigen Zustand und beginnt bei Version eins. Der Zähler gilt für dieses Abonnement. Eine Erneuerung setzt ihn nicht zurück; eine Beendigung schon.

Eine Antwort ohne Request-URI, Dialog, Call-ID, Tags, CSeq, Versionswert und Body-Hash hat daher keinen eindeutigen Zustandsbezug. Sie sagt, dass eine Transaktion endete, nicht welcher lokale Hash daraus hervorging.

Erfolgreich gesendet bleibt eine Aussage des Senders

Die Version wird gegenüber dem zuvor erfolgreich an diesen Beobachter in diesem Abonnement gesendeten partiellen Dokument erhöht. Nach finaler Antwort oder Timeout kann der Sender seinen Ablauf fortsetzen.

Der Verlauf belegt aus Sicht des Presence Agent: Nachricht versandt, Transaktion abgeschlossen oder abgelaufen, nächster Schritt freigegeben. Er sieht weder den XML-Parser noch den gewählten Basiszustand, den Patch, die dauerhafte Speicherung oder die Sicht eines nachgelagerten Prozesses.

Im Normalbetrieb liegen diese Ereignisse eng beieinander. Für institutionelle Entscheidungen müssen sie trotzdem getrennt bleiben, weil nur dann ein abweichender Schritt sichtbar wird.

Der lokale Versionsvergleich entscheidet über die Wirkung

Empfängt der Beobachter eine Version gleich oder kleiner als seinen lokalen Wert, soll er das Dokument als Fehler des Presence Agent verwerfen. Ist ein Diff genau eins höher, wendet er es an und erhöht den Zähler. Ist es um mehr als eins höher, nimmt er verlorene NOTIFY-Nachrichten an und soll erneuern oder das Abonnement beenden.

Verwerfen, anwenden und neu synchronisieren sind drei verschiedene Zustandsentscheidungen. Die finale SIP-Antwort an der Grenze beschreibt keine davon vollständig.

Ein Beleg muss erwartete und empfangene Version, gewählten Zweig, Patch-Ergebnis und resultierenden Hash enthalten. Sonst wird die Sicht des Senders zur erfundenen Sicht des Empfängers.

Ein Verarbeitungsfehler kann oben unsichtbar bleiben

Scheitert die Verarbeitung eines partiellen Dokuments, soll der Beobachter das Abonnement erneuern. Er darf beim neuen SUBSCRIBE den partiellen Medientyp weglassen und auf vollständige Präsenz zurückfallen.

RFC 5263 hält es für kaum sinnvoll, diesen Verarbeitungsfehler an den Notifier zu signalisieren, selbst wenn der Fehler im Notifier-Prozess liegt. Der Sender kann deshalb eine saubere Folge finaler Antworten sehen, während der Beobachter den inkrementellen Pfad bereits verlassen hat.

Keine Fehlermeldung ist kein Anwendungsbeleg.

Beim Formatwechsel überlebt der Zähler, nicht der Inhalt

Wechselt der Presence Agent innerhalb eines Abonnements den Inhaltstyp, verwirft der Beobachter die zuvor empfangenen Präsenzdaten. Nur der lokale Versionszähler bleibt, weil eine spätere Rückkehr zum partiellen Format die Nummerierung fortsetzt.

Damit kann numerische Kontinuität eine ausgetauschte Darstellung überdecken. Ein Audit, das nur Versionen und Antworten speichert, verliert den verworfenen Vollzustand, den neuen Anker und den Zeitpunkt der nachgelagerten Sichtbarkeit.

Ein vollständiges Dokument bei einer Erneuerung schafft einen neuen Ausgangspunkt. Es beweist nicht rückwirkend, dass frühere Deltas angewendet oder genutzt wurden.

Authentizität ist nicht dauerhafte Anwendung

RFC 5263 übernimmt Vertraulichkeit, Integrität, Authentizität, Replay-Schutz und Schutz vor Dienstverweigerung aus dem SIP-Präsenzmodell. Im ursprünglichen Kontext wird TLS zwischen den Elementen empfohlen und S/MIME ermöglicht; RFC 8996 aktualisiert die TLS-Abhängigkeit durch die Ablösung von TLS 1.0 und 1.1.

Eine eingeschleuste partielle Nachricht kann eine vermeintliche Lücke erzeugen und eine Vollzustandsanforderung auslösen. Der Schutz dagegen ist notwendig. Eine authentische Nachricht kann jedoch weiterhin beim Parsen, Patchen, Speichern oder Anzeigen scheitern.

Transportherkunft und SIP-Abschluss gehören in die Beweiskette. Sie ersetzen nicht die lokale Zustandsquittung.

Die Zustandsquittung des Beobachters

Für folgenreiche Nutzung sind aufzubewahren:

  • Presentity, Beobachter, Request-URI, Abonnement, Dialog und Ereignispaket;
  • akzeptierte Medientypen, Präferenzen und lokale Auswahl des Agenten;
  • Call-ID, Tags, CSeq, Typ, Bytes, Hash und Empfangszeit der NOTIFY;
  • abonnementspezifische Version und erwarteter Vorgänger;
  • SIP-Antwortcode und -zeit, Timeout oder Wiederholung;
  • Parser-Ergebnis und konkreter Verarbeitungsfehler;
  • Hash des Vollzustands vor Anwendung und Patch-Ergebnis;
  • rekonstruierter Hash, lokaler Zähler und Speicherbestätigung;
  • Erneuerung, Rückfall, Formatwechsel und Ersatz-Vollzustand;
  • Identität, Hash und Zeit der nachgelagerten Sichtbarkeit; sowie
  • Anzeige, Kontaktversuch, Zustellung und menschliches oder dienstliches Ergebnis.

Die Quittung nimmt 200 OK nichts von seinem Wert. Sie verhindert nur, dass eine Flussbestätigung als Zustandsbeweis ausgegeben wird.

Sources