Zusammenfassung

  • ifUnchangedBy prüft ausgewählte Eigenschaften ausgewählter Objekte am Beginn einer Methode; atomic:true verpflichtet den Server, alle Änderungen des Foo/set gemeinsam oder gar nicht zu committen.
  • Ein erfolgreicher atomarer Commit bezeugt nicht, dass externe Caches, Indizes und Worker den neuen Zustand bereits übernommen haben. Auch die geschäftliche Entscheidungsbefugnis bleibt ein eigener Nachweis.

Zwei Geschwisterobjekte sollten ihre eindeutigen Namen tauschen. Würde der Server zuerst A in den Namen von B umbenennen, entstünde vorübergehend eine Kollision. Umgekehrt gilt dasselbe. Der gewünschte Endzustand war widerspruchsfrei, aber keine sequentielle Zwischenstufe war es.

Mit atomic:true konnte der Server beide Änderungen gegen den gemeinsamen Endzustand prüfen und zusammen committen. Die Antwort war grün. Ein nachgelagerter Cache aktualisierte sich jedoch später und lieferte für kurze Zeit die alte Zuordnung. Ein Überwachungssystem bezeichnete den Zeitpunkt der Serverantwort bereits als „Umstellung abgeschlossen“.

Genau dort endet die Aussagekraft des Belegs.

draft-ietf-jmap-conditional-00, JMAP Conditional Set, ist vom 15. September 2026 und läuft am 19. März 2027 ab. Zum Recherchezeitpunkt war es ein aktiver Internet-Draft der JMAP-Arbeitsgruppe, für den Standards Track vorgesehen und als mögliche Aktualisierung von RFC 8620 angelegt. Es ist kein endgültiger RFC und keine Aussage über Implementierungen, Verbreitung oder Betriebsergebnisse.

Der Entwurf ergänzt zwei getrennte Werkzeuge. ifUnchangedBy bindet eine Änderung an ausgewählte Objektwerte. atomic:true bindet die Änderungen einer Methode an ein gemeinsames Commit-Schicksal. Das erste schützt den behaupteten Ausgangspunkt, das zweite die Einheit des Übergangs.

Eine Bedingung ist so breit wie ihre Zeiger

JMAP Core kennt ifInState. Der Zustandsstring gilt für einen gesamten Objekttyp im Konto. Ändert irgendein Client oder der Server irgendein Objekt dieses Typs, kann ein Schreibversuch auf einem unberührten Einzelobjekt abgewiesen werden. Das verhindert unbemerkte Überschreibungen, erzeugt in aktiven Konten aber auch sachfremde Konflikte.

ifUnchangedBy bildet Objekt-IDs auf PatchObjects ab. Für jeden Zeiger muss der aktuelle Wert dem erwarteten Wert entsprechen; das Anwenden des PatchObjects wäre ein Nullschritt. null behauptet, dass die Eigenschaft fehlt. Verglichen wird die Darstellung, die Foo/get liefern würde.

Ein Client kann damit nur blobId, eine Freigabeberechtigung oder die Abwesenheit von $seen schützen. Ändert sich eine nicht genannte Eigenschaft, bleibt die Bedingung bewusst wahr. Deshalb darf der Erfolg nicht als „Objekt unverändert“ gespeichert werden. Er sagt nur, dass die ausgewählten lesbaren Werte am Auswertungszeitpunkt passten.

Ein vollständiger Compare-and-Swap ist möglich, wenn der Datentyp ein servergepflegtes Änderungsmerkmal besitzt, das bei jedem Schreibweg fortgeschrieben wird. Die Vertrauenswürdigkeit entsteht nicht durch den Feldnamen. Sie hängt davon ab, ob Reparaturwerkzeuge, Migrationen und Verwaltungswege dieselbe Regel einhalten.

Der Entwurf erlaubt außerdem Bedingungen auf einem Objekt desselben Typs, das die Methode nicht ändert. Ein Dateiupdate kann davon abhängen, dass die Datei noch im Elternobjekt d3 liegt und dieses weiterhin Reports heißt. Das begrenzt einen Kontextfehler, bildet aber keine vollständige Hierarchie, Aufbewahrungspolitik oder Organisationsvollmacht ab.

Sichtbarkeit verhindert den Bedingungs-Orakel

Auch servergesetzte und schreibgeschützte Eigenschaften dürfen als Bedingung dienen, etwa Inhaltskennung, Größe oder Änderungszeit. Der Client muss sie jedoch lesen dürfen. Für ein unsichtbares Feld muss der Server forbidden liefern, statt die vermutete Eigenschaft zu testen.

Andernfalls könnte ein Angreifer Kandidatenwerte durchprobieren und aus Erfolg oder Fehlschlag geheime Daten ableiten. Die Bedingung darf nicht mehr offenbaren, als Foo/get offenbaren würde.

Leseberechtigung ist wiederum keine Änderungsbefugnis. Alle Werte können stimmen und die Mutation trotzdem wegen fehlender Schreibrechte scheitern. Und technische Schreibrechte eines Dienstkontos beweisen noch nicht, dass dieser Dienst eine wirtschaftlich oder rechtlich relevante Entscheidung treffen durfte.

Heng Lus Trennung von Evidenz und Autorität ist hier praktisch: Der Server kann präzise feststellen, was er sieht. Er darf daraus nicht erfinden, wer außerhalb des Protokolls den Verlust tragen oder das Asset binden darf.

Der Fehlerumfang ist explizit

Scheitert eine ifUnchangedBy-Bedingung, weist der Server die gesamte Methode mit stateMismatch ab. Keine Erstellung, Aktualisierung oder Löschung tritt ein; der Zustandsstring bleibt gleich. Optional kann der Server die fehlgeschlagenen IDs nennen, ohne aktuelle Werte auszugeben.

Sollen Änderungen unabhängig sein, muss der Client getrennte Methoden verwenden. Damit entscheidet die Anwendung, welches Bündel ein gemeinsames Schicksal besitzt. Gruppierung verhindert Teilfortschritt; Trennung macht Zwischenzustände sichtbar. Das Protokoll stellt die Form bereit, aber nicht das Geschäftsurteil über den erträglichen Schaden.

Atomarität prüft das Ergebnis als Ganzes

Ohne neue Option können Elemente eines Foo/set unabhängig gelingen oder scheitern. Mit atomic:true gilt alles oder nichts. Nebenbedingungen werden gegen die gemeinsame Ergebnismenge geprüft, nicht gegen zufällige Zwischenreihenfolgen.

So kann der Namenstausch gelingen. Scheitert irgendein Teil wegen ungültigem Patch, fehlender Berechtigung, Eindeutigkeitsregel oder anderem SetError, antwortet der Server mit atomicFailure und committet nichts. Optionale Fehlermengen zeigen Ursachen. Nicht genannte Objekte wurden ebenfalls nicht verändert; sie waren nur nicht die Ursache.

Eine falsche Ausgangsbedingung bleibt stateMismatch, auch bei angeforderter Atomarität. Diese Unterscheidung hält fest, ob die angenommene Vergangenheit falsch war oder der vorgeschlagene gemeinsame Übergang nicht möglich war.

Kann der Server eine konkrete Methode nicht atomar ausführen, muss er cannotApplyAtomically zurückgeben und darf nicht still auf Teilanwendung zurückfallen. Ein Client kann ohne atomic neu anfragen, aber nur nach der Entscheidung, Teilzustände zu akzeptieren. Diese schwächere Anfrage ist kein identischer Retry.

Große atomare Methoden können Transaktionen oder gleichwertige Sperren länger halten. Bestehende Objektlimits gelten weiter. Ein Server darf übergroße Einheiten ablehnen. Atomarität ist ein begrenzter Vertrag, keine Zusage grenzenloser Ressourcen.

Commit und Konvergenz brauchen verschiedene Uhren

Die atomare Antwort gilt für den Foo/set des antwortenden Servers. Ein Pfad-Cache, Suchindex, Benachrichtigungssystem, Worker oder Offline-Client gehört nicht automatisch zu derselben Transaktion.

Darum kann der Namenstausch korrekt committed sein, während ein Cache noch alte Pfade liefert. Eine Freigabe kann im Objekt entfernt sein, während ein anderes System ein zuvor ausgestelltes Token noch akzeptiert. Eine Nachricht kann gelöscht sein, während eine lokale Kopie sichtbar bleibt.

Ein belastbarer Nachweis führt getrennte Zeitpunkte: authentifizierter Akteur, geschäftliche Vollmacht, ausgewertete Bedingungen, Servercommit, Readback, von jedem Verbraucher beobachtete Generation und Nutzerwirkung. Nur so bleibt erkennbar, welcher Teil bereits wahr war.

Tests sollten die Grenzen sichtbar machen. Eine unselektierte Eigenschaft ändern und den bedingten Erfolg erwarten. Einen selektierten Wert ändern und vollständige Wirkungslosigkeit erwarten. Eine verborgene Eigenschaft testen und forbidden verlangen. Einen Teil einer atomaren Methode fehlschlagen lassen und prüfen, dass kein anderer Teil auftaucht. Danach externe Verbraucher gezielt verzögern.

Der Server kann zwei Namen gemeinsam tauschen. Er kann nicht allein bezeugen, dass jeder Beobachter die neue Welt schon kennt. Gute Führung akzeptiert diese Lücke nicht als Fehler des Protokolls, sondern behandelt sie als Aufgabe der Evidenzkette.

Quellen