Zusammenfassung

  • RFC 3341 wählte aus passenden Owner/Actor-Einträgen den spezifischsten; nach dem Löschen des exakten Eintrags konnte eine breitere Wildcard-Freigabe wirksam werden.
  • Vollständige Sperre erforderte dann den verbliebenen exakten Wert all:none; Zeilenlöschung, Änderungsquittung, Owner-Benachrichtigung, effektive Entscheidung und Durchsetzung waren getrennt.

Das Beispiel enthält zwei Regeln. Eine exakte Regel erlaubt einem Actor Kerndaten, Presence-Abonnement und Beobachtung. Eine zweite Regel erlaubt allen Akteuren derselben Domäne nur Kerndaten. Wird die exakte Regel gelöscht, verschwinden die Presence-Rechte, der Datentransport bleibt aber über die breite Regel erlaubt.

Die Löschung ist dabei erfolgreich. Nicht die Zeile überlebt, sondern ihre teilweise Wirkung, weil sich die Rangfolge der Kandidaten verschiebt. Der zuvor verdeckte Eintrag wird zum besten Treffer. Soll der Actor gar nichts mehr dürfen, bleibt sein exakter Eintrag mit all:none bestehen und überstimmt die breite Freigabe.

Berechtigung als Auswertung

Ein Eintrag bestand aus Owner, Actor, erlaubten Aktionen und einem vom Dienst vergebenen lastUpdate. Der Owner war Endpunkt oder Unteradresse der Richtlinie; der Actor die berechtigte Entität oder Gruppe. Aktionen kombinierten Dienst und Operation. core:data bezeichnete etwa das Recht, Daten über das Relay-Netz an den Owner zu senden.

Lokaler und Domain-Teil des Actors konnten begrenzt mit Wildcards beschrieben werden. Mehrere Zeilen passten dadurch auf dieselbe konkrete Adresse. Zuerst wurden Owner und passende Actor-Werte gefiltert. Dann entschied die Genauigkeit der Domain als Primärschlüssel und die des lokalen Teils als Sekundärschlüssel. Exakt gewann; sonst hatte die kürzere, spezifischere Wildcard Vorrang.

Effektiver Zugriff war somit kein Attribut einer einzelnen Zeile, sondern das Ergebnis aus Kandidatenmenge, Rangfolge und angefragter Aktion. Der Screenshot einer gelöschten Zeile beweist einen Tabellenzustand, nicht die nächste Entscheidung.

Auch Defaults gehörten zum Zustand. Owner und APEX-Dienste derselben Domain erhielten weitreichende Rechte, APEX-Dienste beliebiger Domains core:data, andere globale Akteure all:none. Ein expliziter Eintrag verdrängte nur den Default mit demselben Actor-Wert. Eine vollständige Prüfung musste gespeicherte und definierte Regeln sehen.

Warum die Sperre gespeichert blieb

Zum Löschen wurde ein set mit Owner, Actor und aktueller Version, aber ohne actions, gesendet. Der Dienst entfernte die Zeile, antwortete dem Ändernden und sandte dem Owner separat eine actions-lose set-Benachrichtigung.

Danach warnt RFC 3341, dass Wildcards aus Löschung eine Änderung der Berechtigung machen können. all:none bedeutet keinerlei Operation. Als exakter Eintrag bleibt die Sperre vor dem breiten Grant in der Auswahl.

Die negative Zeile enthält daher Information. Fehlt sie, gilt der allgemeinere Fall; ist sie vorhanden, wird Vererbung verhindert. Eine generische Tombstone-Bereinigung kann Zugang ohne neuen Grant wiederherstellen, wenn sie diesen Unterschied ignoriert.

Versionsschutz ohne Vollzugsbeweis

Vor Änderung oder Löschung holte die Anwendung gewöhnlich den Eintrag und sein lastUpdate. Der nachfolgende set musste diesen Wert wiederholen. Existierte kein exakter Eintrag mehr oder war die Version nicht semantisch identisch, antwortete der Dienst mit 555. Eine Neuanlage kam ohne Version.

Das war ein Vergleich vor Ersetzung und verhinderte stilles Überschreiben zwischen Lesen und Schreiben. Nach Anlage oder Änderung vergab der Dienst einen neuen Zeitpunkt, der vom ersetzten Wert verschieden sein sollte.

Der erfolgreiche Vergleich bewies aber keine Verteilung. Er sagte nicht, ob der Owner die Meldung erhalten, jedes Relay die neue Kandidatenmenge gesehen oder ein Durchsetzungspunkt die Aktion abgelehnt hatte. Die Belegkette umfasst gelesene Version, Mutation, Erfolg oder Konflikt, neuen Zustand, gesendete und empfangene Meldung, Neuberechnung, Ausbreitung und Test.

Auch Abfragen hatten Zugriffsregeln

Bei einer Query prüfte der Dienst Domain und Gültigkeit des Subjects. Dann wählte er den Subject-Eintrag passend zum Abfrage-Ursprung und verlangte access:query. Erst danach wählte er den Eintrag für den untersuchten Actor und prüfte alle genannten Aktionen.

Fragender und geprüfter Actor waren verschiedene Rollen. Abfragerecht war kein Ausführungsrecht. Ein allow besagte, dass die Aktionen bei dieser Auswertung enthalten waren, nicht dass eine spätere Operation dieselbe Version sah oder erfolgreich endete.

Einträge waren persistent zu speichern, auch wenn der Owner nicht angekoppelt war. Trennung vom Netz widerrief Richtlinie nicht. Persistenz war trotzdem kein Beweis für Replikation, Aktualität oder Vollzug.

Historischer Ausgang

RFC 3341 erschien im Juli 2002 auf dem Standards Track zusammen mit APEX-Kern, Optionen und Präsenz. Am 29. Juli 2012 vermerkte die IETF die Umstufung der RFCs 3340 bis 3343 auf Historic: Nach bestem Wissen seien keine Implementierungen eingesetzt worden; die Funktionalität werde von dem weit verbreiteten XMPP aus RFC 6120 und RFC 6121 erbracht.

Der Vermerk nennt Wildcards nicht als Ursache und dokumentiert keinen Vorfall. Er begrenzt eine Aussage über Adoption. Die Beleggrenze bleibt bestehen: Richtlinienobjekt löschen, wirksames Recht widerrufen und Ablehnung durchsetzen sind unterschiedliche Ereignisse.

Heutige Systeme können diese Trennung nutzen, ohne APEX-Gleichheit zu behaupten. Sie speichern Kandidaten und Algorithmus, schützen bedeutungstragende Denials, lesen das Ergebnis nach Änderung und prüfen den Vollzugspunkt. Die Änderungsquittung zeigt, was der Dienst akzeptierte. Widerruf zeigt, was der Actor nicht mehr tun kann.

Quellen