Zusammenfassung

  • Eine lebende ContactCard gehört nach RFC 9610 mindestens einem AddressBook an, kann aber mehreren zugeordnet sein; das Entfernen einer Zuordnung ist nicht die Zerstörung der Karte.
  • Gruppen speichern Mitglieds-UIDs. Geht der Zugriff auf die passende Karte vorübergehend verloren, verschwindet das Mitglied aus der Ansicht, während die unaufgelöste UID erhalten bleibt und später wieder auflösbar wird.
  • Ein belastbarer Löschbeleg braucht Account, Server-ID, UID, vorherige Zuordnungen, genaue /set-Argumente, Antwort und eine spätere autoritative Abfrage.

Das Projektadressbuch war weg, der Datensatz möglicherweise nicht

Nach Projektende löscht ein Betreiber das gemeinsame Adressbuch. Die Anwendung zeigt keine Kontakte mehr, der Prüfbericht vermerkt „Kontakte gelöscht“. Monate später erscheint ein Lieferant weiterhin im Notfalladressbuch. Bevor man eine Wiederherstellung oder einen Verstoß behauptet, muss geklärt werden, was der erste Vorgang tatsächlich verändert hat.

RFC 9610 modelliert ein AddressBook als benannte Sammlung. Dieselbe ContactCard kann gleichzeitig den Sammlungen Projekt, Bereitschaft und Verlängerung angehören. Wird das Projektbuch mit onDestroyRemoveContents:true zerstört, entfernt der Server diese Zuordnung. Die Karte selbst wird nur zerstört, wenn sie keinem anderen AddressBook mehr angehört.

Eine erfolgreiche Operation, eine leere Ansicht und eine fortbestehende Karte sind deshalb miteinander vereinbar. Wer Ansicht, Beziehung und Objektlebenszyklus zu „gelöscht“ verdichtet, macht aus einer lokalen Beobachtung ein unbelegtes Gesamturteil.

Eine Sammlung besitzt ihre Karten nicht exklusiv

Ein JMAP-Account mit Kontakten enthält AddressBooks; jede ContactCard führt ihre Sammlungen in addressBookIds. Solange die Karte existiert, darf diese Menge nicht leer sein. Das ermöglicht einen gemeinsamen Datensatz für mehrere betriebliche Kontexte, ohne drei auseinanderlaufende Kopien zu erzeugen.

Das Entfernen aus „Verlängerung“ ändert eine Kante. Es widerruft nicht die Zuordnungen zu „Einkauf“ und „Störung“. Der Standard setzt damit eine minimale gemeinsame Zustandsmaschine. Produkte dürfen sie als Ordner, Listen oder Arbeitsräume darstellen, doch die Metapher erweitert die Wirkung der Operation nicht.

Gerade diese Begrenzung schützt laufende Systeme: Interoperabilität benötigt eine klare Zuordnung, nicht die zentrale Entscheidung über Aufbewahrung, rechtliche Löschung oder Daten in fremden Systemen.

Die Kaskade ist an den vorherigen Zustand gebunden

Standardmäßig ist onDestroyRemoveContents false. Ein nicht leeres AddressBook kann dann nicht zerstört werden; der Server antwortet mit addressBookHasContents. Das belegt die Ablehnung dieses Auftrags, aber keine ewige Aufbewahrung aller Karten.

Bei true entfernt der Server das AddressBook aus den Karten. Nur eine Karte ohne weitere Zuordnung wird zerstört. Ein Methodenaufruf kann daher das Buch zerstören, mehrfach zugeordnete Karten erhalten und verwaiste Karten zerstören.

Ein Auditfeld „Kaskade aktiviert“ unterschlägt die entscheidende Bedingung. Erforderlich sind die vorherigen addressBookIds jeder Karte sowie destroyed, notDestroyed, updated und Fehler der Antwort. Der Optionsname dokumentiert Absicht; Zustand und Serverantwort dokumentieren Wirkung.

Server-id und uid erhalten verschiedene Identitäten

Eine ContactCard hat eine unveränderliche, servergesetzte id und eine JSContact-uid. RFC 9610 lässt unterschiedliche Werte ausdrücklich zu. Innerhalb eines Accounts darf es höchstens eine ContactCard mit derselben UID geben.

Die Server-ID bezeichnet das Objekt für JMAP-Methoden. Die UID trägt die Identität der Kontaktkarte und ist die Referenz in Gruppen. Nur den Anzeigenamen zu protokollieren verliert beides. Nur die UID zu behalten verrät nicht, welches Serverobjekt in welchem Account geändert wurde. Nur die ID zu behalten verliert die durch Gruppen ausgedrückte Kontinuität.

Auch beide zusammen sind nicht die reale Person. Die Zerstörung einer Karte entfernt nicht automatisch Nachrichten, Exporte, Endgeräte, CRM-Einträge, Sicherungen oder unabhängige Kopien.

Die Gruppe bewahrt eine derzeit unsichtbare Referenz

Eine Gruppen-ContactCard speichert eine Menge von UIDs. Der Client sucht passende Karten in zugänglichen Accounts mit JMAP Contacts. Kann eine UID nicht gefunden werden, soll sie in der Darstellung ignoriert, aber gespeichert werden.

RFC 9610 nennt den maßgeblichen Fall: Ein Nutzer fügt Kontakte aus einem geteilten Adressbuch seiner privaten Gruppe hinzu und verliert vorübergehend den Zugriff. Die Mitglieder verschwinden, weil ihre UIDs nicht auflösbar sind. Nach Rückkehr der Berechtigung finden die bewahrten UIDs die Karten wieder; die Mitglieder erscheinen erneut.

Es musste nichts restauriert werden. Die Kontinuität blieb erhalten. Ein Screenshot während der Unterbrechung beweist nur, dass dieser Principal die Karte zu diesem Zeitpunkt nicht auflösen konnte. Er beweist weder Objektzerstörung noch UID-Entfernung noch Unsichtbarkeit für andere.

Ein fehlender Abfragetreffer bleibt eine begrenzte Aussage

inAddressBook filtert Karten einer bestimmten Sammlung. Fehlt eine Karte, kann sie weiterhin in einem anderen AddressBook oder außerhalb der aktuellen Zugriffsfläche existieren. Der Filter beantwortet seine konkrete Frage und keine universelle Existenzfrage.

JMAP-Zustände und /changes machen Übergänge nachvollziehbar, wenn der Client den alten Zustand behält, erstellte, aktualisierte und zerstörte IDs prüft und Unklarheiten mit /get im richtigen Account auflöst. Eine verschwundene Zeile ersetzt diese Kette nicht.

Selbst eine bestätigte Zerstörung bleibt begrenzt: Diese ContactCard existiert nicht mehr in diesem JMAP-Account. Andere Accounts, Kopien, Backups, Nachrichtenarchive und externe Systeme sind damit nicht beurteilt.

Auch der Default-Auftrag trennt Anfrage und Ergebnis

onSuccessSetIsDefault fordert nach erfolgreichen Änderungen ein neues Standardadressbuch an. Wird die ID nicht gefunden oder verbietet die Serverpolitik den Wechsel, wird dieser Teil ohne Fehler ignoriert; der bisherige Standard bleibt.

Die gesendete Absicht ist also kein beobachteter Zustand. Der Client muss zurückgegebene Eigenschaften lesen oder den aktuellen Zustand abrufen. Schaltfläche und Payload belegen den Versuch; Antwort und Readback belegen das Ergebnis.

Ein Löschbeleg ist eine prüfbare Kette

Der Beleg beginnt mit Account, Server-id und UID. Er bewahrt die vollständigen vorherigen addressBookIds und einschlägige UID-Referenzen in Gruppen. Er trennt die Zerstörung eines AddressBook von der direkten Zerstörung einer ContactCard und hält onDestroyRemoveContents exakt fest.

Danach folgen Methodenresultat, neuer Zustand und spätere Abfrage. Die Schlussfolgerung lautet begrenzt: aus diesem Buch entfernt; für diesen Principal derzeit nicht auflösbar; ContactCard in diesem Account zerstört; oder nicht belegt. RFC 9610 kann nicht bescheinigen, dass eine Person überall gelöscht wurde.

Die Trennung von Ansicht, Beziehung, Objekt und Außenwelt ist keine Wortklauberei. Sie ordnet jeder Entscheidung den Beleg zu, der sie tatsächlich tragen kann.

Quellen