Zusammenfassung

  • Revision 08 des iCalendar-Erweiterungsentwurfs führt OWNER als Teilnehmerrolle ein, erklärt sie aber ausdrücklich für nur indikativ; allein daraus darf keine Änderungsbefugnis entstehen.
  • JMAP Calendars zeigt die fehlenden Kontrollen: Teilnehmerrolle und Kontoidentität müssen zusammenpassen, danach müssen aktuelle Kalenderrechte und Ereignisregeln die Operation erlauben.
  • Rollen-Parsing, Identitätsbindung, Autorisierung, Speicherung, Versand, entfernte Verarbeitung und sichtbares Ergebnis sind getrennte Belege.

Der gefährliche Eintrag muss nicht fehlerhaft sein. Er kann syntaktisch korrekt sein, jeden Parser passieren und ein überzeugendes Eigentümer-Abzeichen anzeigen. Der Fehler beginnt, wenn Software diese Beschreibung zur Berechtigung erhebt.

Revision 08 definiert OWNER als Teilnehmerrolle. Ein Eigentümer könne Änderungen vornehmen, die alle Beteiligten betreffen, etwa den Termin verlegen oder Teilnehmer und Rollen ändern. Direkt danach zieht der Entwurf die entscheidende Grenze: Die Rolle ist nur indikativ, ihre Semantik hängt vom Austauschprotokoll ab, und keine Implementierung darf allein wegen dieses Werts Änderungen erlauben.

Damit trennt der Text eine Behauptung im Datensatz von der Macht des Systems. Gerade in Kalendern wird beides leicht verwechselt, weil Rolle, Zeit, Ort, Wiederholung und Teilnehmer in derselben handlungsorientierten Oberfläche erscheinen.

Die Behauptung ist portabel, die Befugnis nicht

RFC 5545 schafft ein portables Format. Derselbe Datensatz kann durch Dateien, Nachrichten, CalDAV-Speicher und JMAP-Dienste mit unterschiedlichen Konten, Identitäten und Rechtemodellen laufen. Eine universelle Schreibberechtigung kann daher nicht im Rollenwert stecken.

Der Entwurf definiert ausdrücklich keine CalDAV-Semantik für OWNER. Ein Empfänger kann die Rolle bewahren und anzeigen, darf aber keine fehlende Schreibregel erfinden. Auch ein künftiger Eintrag in den IANA-iCalendar-Registern würde nur Namen und Referenz koordinieren; er authentifiziert keinen Teilnehmer und erteilt keine Befugnis.

Das entspricht der Minimum Initial Specification: Gemeinsame Syntax soll die kleinste interoperable Bedeutung festlegen, nicht jede spätere lokale Entscheidung zentralisieren. OWNER kann gemeinsames Vokabular sein, während die Gewährung beim Protokoll und seinem Betreiber bleibt.

JMAP legt die Entscheidungskette offen

Der aktive Entwurf JMAP Calendars erkennt einen Nutzer nur dann als Ereigniseigentümer, wenn ein Participant die Rolle owner trägt und einer ParticipantIdentity dieses Nutzers im Konto entspricht.

Auch diese Kombination ist keine allgemeine Fähigkeit. mayWriteOwn erlaubt Änderungen nur im betreffenden Kalender und nur, wenn der Nutzer das Ereignis besitzt oder kein Eigentümer vorhanden ist. mayWriteAll, mayRSVP, mayShare und mayDelete bezeichnen andere Rechte.

Bei CalendarEvent/set muss der Server myRights durchsetzen und eine unerlaubte Änderung mit forbidden zurückweisen. Dieses Urteil ist der Autorisierungsbeleg. Die Rolle ist lediglich ein Eingangswert.

Ursprung, Vertraulichkeit, Wiederholung und Kalenderzugehörigkeit können die Operation weiter einschränken. Ist eine Kopie nicht der Scheduling-Ursprung, darf der Client trotz scheinbar breiter Rechte nur nutzerspezifische Eigenschaften ändern, weil ein späteres autoritatives Update sie überschreiben kann.

Stufe Was sie belegt Was offen bleibt
Parsing OWNER steht in gültiger Syntax Wer es behauptet und ob es aktuell ist
Identität Teilnehmer passt zu einer Kontoidentität Rechte an Kalender und Ereignis
Autorisierung Eine aktuelle Regel erlaubt die Operation Ob die Änderung angenommen wurde
Mutation Der Server speicherte neuen Zustand Ob Nachrichten versandt wurden
Zustellung Ein anderes System erhielt die Nachricht Ob es sie anwandte und zeigte
Rücklesen Ein Teilnehmer sieht die Änderung Dauerhafte Konvergenz aller Kopien

Erfolgreiches Speichern ist noch keine geänderte Besprechung

JMAP kann beim Ändern eines geplanten Ereignisses Scheduling-Nachrichten anfordern. Die Anforderung beweist keine Zustellung. Nach dem lokalen Speichern folgen Empfängerauswahl, Warteschlange, Transport, entfernte Annahme und die sichtbare Kopie.

RFC 6638 und RFC 4791 zeigen Speicherung und Planung als verbundene, aber getrennte Flächen. Sammlung, Scheduling-Befugnis, Ausgang und Teilnehmerkopie sind kein atomarer Fakt.

Ein belastbarer Nachweis verbindet Objekt-Hash, Rollenposition, Identitätsabgleich, Rechteversion, Ursprung und Privatsphäre, Richtlinienurteil, Mutationskennung und Vorher-nachher-Hashes, Empfängerauswahl, Transport und Rücklesen. Private Inhalte müssen dafür nicht protokolliert werden.

Standardfortschritt ist kein Betriebsnachweis

Der Datatracker führt Revision 08 als Internet-Draft der CALENDAR EXTENSIONS WG mit Ziel Proposed Standard und beantragter Veröffentlichung. Historie und Shepherd-Bericht dokumentieren das Verfahren. Ein RFC oder Beleg für Produktverhalten liegt nicht vor.

Dasselbe Dokument ergänzt SHOW-WITHOUT-TIME, betont aber, dass diese Darstellung den für Konflikte relevanten Zeitraum nicht verändert. Dieselbe Disziplin gilt für OWNER: Eine Anzeige darf tieferen Zustand und Berechtigung nicht unbemerkt umschreiben.

Running-Code Primacy verlangt die Prüfung der tatsächlich aufgelösten Identität, geladenen Rechte und Serverentscheidung. The Policy Mirror zeigt Macht in Auflösung, Cache und Standardwerten. Reality Layers hält Syntax, Rolle, Befugnis und Ergebnis auseinander.

Die Führungsfrage lautet daher nicht „Steht im Kalender Eigentümer?“, sondern „Welches System gewährte welche Operation für welchen Zustand, und welcher spätere Beleg zeigt, dass die Änderung die Betroffenen erreichte?“

Quellen