Zusammenfassung

  • RFC 5367 lässt eine flache Ressourcenliste im ersten SUBSCRIBE mehrere Subscriptions über einen Dialog anstoßen. recipient-list-subscribe bezeichnet diese Fähigkeit, belegt aber weder ihre erfolgreiche Ausführung noch den Zustand einzelner URIs.
  • Der Statuscode des ersten Requests gilt für die Anfrage an den Listendienst. Erst NOTIFY mit rlmi+xml liefert konstituentenspezifische Beobachtungen; der erwartete Nenner bleibt die kanonische Liste.
  • Spätere SUBSCRIBE-Requests verwenden das vom Server bereitgestellte Dialogziel und dürfen die Liste nicht neu deuten. Management-URI, Ablauf und Vernichtung bilden weitere, separat nachzuweisende Autoritätsstufen.

Die Registrierung schuf eine gemeinsame Sprache

IANA führt das SIP-Option-Tag recipient-list-subscribe und den Call-Info-Zweck list-management. Clients und Server können damit eine Fähigkeit beziehungsweise die vorgesehene Art eines Links erkennen.

Diese Registrierung ist für Interoperabilität entscheidend. Ohne einen stabilen Namen würden Implementierungen dieselbe Funktion verschieden signalisieren oder unbekannte Erweiterungen falsch behandeln.

Doch ein Name im Register ist keine Messung am laufenden System. Das Option-Tag sagt, welche Erweiterung eine Nachricht verlangt oder unterstützt; es berichtet nicht, welche Downstream-Subscription erfolgreich wurde.

Ebenso beschreibt purpose=list-management die Rolle einer URI. Es beweist weder, dass eine Änderung stattfand, noch dass der aktuelle Inhaber autorisiert ist oder der Link noch lebt.

Der erste Request hatte eine präzise Form

Der UAC richtet den anfänglichen SUBSCRIBE an die öffentliche URI der Listenressource. Mindestens ein Body-Teil trägt den Disposition-Typ recipient-list, und Require enthält recipient-list-subscribe.

Zudem muss der Client rlmi+xml akzeptieren. Bereits diese Anforderung zeigt die Arbeitsteilung: Die Liste benennt beim Erstellen den Umfang, die Benachrichtigungen berichten anschließend über die Bestandteile.

Als Standardformat dient RFC 4826, doch RFC 5367 benötigt nur eine flache Liste. Hierarchien und entry-ref sind unnötig; zusätzliche Information darf der Server verwerfen.

Ein Audit sollte daher Originalbytes, akzeptiertes Profil, verworfene Elemente, URI-Normalisierung und kanonische Menge getrennt speichern. Ein Dokument-Hash beweist Verwahrung, nicht automatisch die ausgeführte Interpretation.

Die Antwort galt dem Listendienst

RFC 5367 hält ausdrücklich fest, dass der Response-Code auf SUBSCRIBE keine Information darüber liefert, ob der Server die in der Liste enthaltenen URIs erfolgreich abonnieren konnte.

Ein 2xx kann den übergeordneten Dialog herstellen, während ein Ziel zustimmt, ein zweites wegen fehlender Berechtigung scheitert und ein drittes noch unbekannt ist. Der Dialog und seine Bestandteile haben unterschiedliche Subjekte.

Die Formulierung „Subscription erfolgreich“ ist deshalb zu ungenau. Direkt nach der Antwort darf sie höchstens bedeuten, dass der Listendienst die aggregierte Anfrage angenommen hat.

Ein Betriebsbild braucht zwei Ebenen: Dialogzustand und konstituente Abdeckung. Der Nenner stammt aus der kanonischen Menge und darf nicht auf jene Ressourcen schrumpfen, die zuletzt eine Nachricht erzeugten.

NOTIFY lieferte beobachtete Einzelzustände

RFC 4662 definiert das Ereignisbenachrichtigungsmodell für Ressourcenlisten. Mit rlmi+xml kann der Client Einträge und Instanzen innerhalb der aggregierten Beziehung unterscheiden.

Jede Position benötigt kanonische URI, Zustand, Instanz, Version, Beobachtungszeit und gegebenenfalls Beendigungsgrund. „Unbekannt“ ist ein legitimer Evidenzzustand, kein Darstellungsfehler.

Reihenfolge und Vollständigkeit gehören ebenfalls zum Beleg. Eine ältere Benachrichtigung darf einen neueren Zustand nicht überschreiben; eine partielle Meldung darf nicht als vollständiger Snapshot behandelt werden.

Auch Frische ist mehrdimensional. Ein lebender Dialog kann Ressourcen mit veralteter Beobachtung enthalten. Eine frische Meldung über einen Eintrag sagt nichts über die übrigen Positionen aus.

Erneuerung war keine zweite Erstellung

Nach Dialogaufbau kann der UAC weitere SUBSCRIBE-Requests senden, um die Laufzeit zu verlängern. Diese Requests gehen an die URI, die der Server als Dialogziel geliefert hat.

Für einen Ressourcenlisten-Body in späteren Requests definiert RFC 5367 keine Semantik. Der Client sollte ihn weglassen; der Server antwortet bei Empfang mit 415 Unsupported Media Type.

Damit bleibt Wartungsautorität von Erstellungsautorität getrennt. Wer einen bestehenden Dialog verlängern darf, darf nicht stillschweigend dessen Ressourcenmenge austauschen.

Eine tolerante Implementierung, die den Body dennoch zusammenführt, würde nicht nur von der Spezifikation abweichen. Sie erfände eine Änderungsoperation ohne festgelegte Zustimmung, Identität und Revisionsgeschichte.

Die Ziel-URI kodierte die Phase

Beim Erstellen spricht der Client die öffentliche Listen-URI an. Danach verwendet er die serverseitig gelieferte URI des Dialogs. Aus Client-Sicht akzeptiert die erste recipient-list, die zweite nicht.

Logs müssen öffentliche URI, authentisierten Principal, Event, Listen-Hash, Dialogkennungen, Fortsetzungsziel und Expires verbinden. Nur so lässt sich erklären, aus welcher Entscheidung die Erneuerungsfähigkeit entstand.

Ein syntaktisch korrekter SUBSCRIBE an die falsche Oberfläche ist nicht derselbe Vorgang. Metriken, die nur Methoden und Statuscodes zählen, übersehen den Autoritätswechsel.

Auch ein Retry muss die Phase bewahren. Das erneute Senden eines Creation-Requests kann eine zweite Liste erzeugen, während ein Dialog-Retry lediglich dieselbe Beziehung fortsetzen soll.

Die Management-URI war eine dritte Fähigkeit

Der erste NOTIFY darf ein Call-Info mit purpose=list-management enthalten. Die referenzierte URI ermöglicht die Manipulation der mit der Subscription verbundenen Liste.

Öffentliche URI erstellt, Dialog-URI erhält, Management-URI verändert. Gemeinsame Produktdarstellung macht daraus keine austauschbaren Berechtigungen.

Der Managementdienst muss Principal, Objekt, gewünschte Änderung und Policy selbst prüfen und einen eigenen Ausführungsbeleg erzeugen. Die Ausgabe des Links ist noch kein Änderungsbeleg.

Die URI braucht außerdem einen Lebenszyklus. In Browserhistorien, Tickets oder Dashboards gespeicherte Links dürfen nach Ende der Subscription nicht als dauerhafte Seitentür weiterwirken.

Die Liste sollte mit der Subscription sterben

RFC 5367 bündelt die Lebensdauer einer manipulierbaren Liste an die Subscription. Läuft sie ab oder endet aus anderem Grund, sollte die Liste vernichtet werden.

Die Regel verhindert, dass ein temporärer Beobachtungsumfang durch organisatorische Trägheit zu einem dauerhaften Beziehungsregister wird.

Ein Expires-Wert von null oder ein Terminierungsereignis ist jedoch kein physischer Löschbeleg. Primärspeicher, Cache, Index, Replik, Backup und Auditspur können unterschiedliche Zeitachsen haben.

Die Organisation muss Dialogende, Capability-Widerruf, Primärlöschung und Bereinigung der Ableitungen separat beobachten. Aufbewahrungsausnahmen brauchen Gegenstand, Grund, Frist und Zugriffsschutz.

Ein authentisierter Client genügte nicht

Der Mechanismus übernimmt die Sicherheitsanforderungen aus RFC 4662 und RFC 5363. Der Listendienst authentisiert und autorisiert den Client und schützt die betroffenen Ziele durch geeignete Opt-in-Regeln.

Die Identität des Aufrufers beantwortet, wer beobachten möchte. Sie beantwortet nicht, ob jede Ressource diesem Event-Package, Zweck und Zeitraum zugestimmt hat.

Policy-Entscheidungen sollten Principal, Dienst, Event, kanonische URI, Zweck, Zeit und Policy-Version verbinden. Eine grobe Administratorrolle darf nicht beliebige Massenlisten autorisieren.

Ablehnungen brauchen intern kontrollierte Gründe. Datenschutz, fehlendes Opt-in, Routingfehler und noch nicht versuchte Verarbeitung dürfen nicht als derselbe leere Platz erscheinen.

Standardstatus und Laufzeitstatus blieben getrennt

RFC 5367 erschien im Oktober 2008 als Standards Track und aktualisierte RFC 3265 hinsichtlich Call-Info in NOTIFY. RFC 6665 erklärte RFC 3265 später für obsolet.

Diese Dokumentgeschichte ist wichtig für eine aktuelle Implementierung. Sie ändert jedoch nicht die Kardinalität der Beweise: Standardsstatus, registriertes Vokabular, ausgehandelter Dialog und beobachtete Ressource bleiben verschiedene Aussagen.

Eine Compliance-Liste kann prüfen, ob die Option erkannt, der Medientyp akzeptiert und 415 korrekt verwendet wird. Sie kann nicht ohne Laufzeitdaten behaupten, alle Ziele seien erfolgreich oder alle temporären Daten vernichtet.

Die Notizen von Lu Heng bilden die ausgewiesene analytische Linse. Minimum Initial Specification erklärt, weshalb der Basiskontrakt für spätere Bodies keine erfundene Mutationssemantik braucht. Reality Layers erinnert daran, dass Tag, URI, Response, NOTIFY und Timer Symbole verschiedener Wirklichkeiten sind. Die Protokollfakten stammen weiterhin aus RFCs und IANA.