Zusammenfassung

  • RFC 2446 modelliert Kalenderabstimmung als Folge unterscheidbarer Protokollschritte: Ein COUNTER kann eine vollständige alternative Veranstaltung enthalten, verändert aber nicht selbst den vom Organizer kontrollierten Master-Eintrag.
  • Die belastbare Evidenzkette reicht deshalb weit über eine syntaktisch gültige Nachricht hinaus: Senderautorität, METHOD und UID, Organizer-SEQUENCE, individuelles PARTSTAT, Organizer-Entscheidung, neue REQUEST, Zustellung, lokale Speicherung und tatsächliche Teilnahme sind voneinander getrennte Ebenen.

RFC 2446, iCalendar Transport-Independent Interoperability Protocol (iTIP), erschien im November 1998 als Standards Track und wurde später durch RFC 5546 abgelöst. Sein Platz in der damaligen Kalenderarchitektur wird verständlicher, wenn die benachbarten Spezifikationen getrennt betrachtet werden. RFC 2445 beschreibt iCalendar-Objekte und das zugrunde liegende Datenmodell. RFC 2446 definiert dagegen die vom Transport unabhängigen Scheduling-Transaktionen. RFC 2447 bindet diese Abläufe an E-Mail; RFC 6047 aktualisiert dieses iMIP-Binding.

Diese Aufteilung verhindert eine häufige Verkürzung: Ein Kalenderobjekt, eine Scheduling-Nachricht und deren Transport sind nicht dasselbe. Ebenso sind die Rollen im Protokoll nicht mit beschreibenden Feldern innerhalb eines Kalendereintrags gleichzusetzen. Der Organizer initiiert den Austausch und kontrolliert den Master-Eintrag; eingeladene Teilnehmer sind Attendees. Das ist etwas anderes als der beschreibende Parameter ROLE einer ATTENDEE-Eigenschaft.

Auch Zustände liegen auf verschiedenen Ebenen. STATUS beschreibt den Zustand des gesamten Eintrags. PARTSTAT bezeichnet dagegen den Teilnahmezustand eines einzelnen Attendees. Schon dadurch wird sichtbar, dass aus einem globalen Eventzustand nicht automatisch auf den Zustand jedes Teilnehmers geschlossen werden kann und umgekehrt.

Die in RFC 2446 definierten Methoden erfüllen ebenfalls unterschiedliche Funktionen. PUBLISH erwartet keine interaktive Antwort. REQUEST fordert Verarbeitung an und unterstützt eine anschließende Reaktion. REPLY übermittelt den Status eines Attendees. COUNTER schlägt eine Änderung vor. DECLINECOUNTER ermöglicht dem Organizer, einen solchen Gegenvorschlag zurückzuweisen.

Gerade COUNTER macht die Autoritätsgrenze sichtbar. Ein Attendee kann damit einen vollständigen alternativen VEVENT oder VTODO übermitteln. Dieser alternative Inhalt ist jedoch ein Vorschlag und keine direkte Änderung des Master-Eintrags. Die Kontrolle über diesen Eintrag verbleibt beim Organizer. Akzeptiert dieser den Vorschlag, folgt daraus ein eigener Scheduling-Schritt: Der Organizer disponiert neu und sendet den betroffenen Attendees eine neue REQUEST. RFC 5546 erhält dieses Modell bei und empfiehlt nach Annahme eines COUNTER die anschließende REQUEST.

Ein rein hypothetisches Beispiel macht die Trennung anschaulich. Ein Organizer lädt für Montag ein. Ein Attendee sendet einen COUNTER mit Dienstag. Damit existiert ein dokumentierter Dienstag-Vorschlag, aber noch kein vom Organizer auf Dienstag geänderter Master-Termin. Erst wenn der Organizer den Vorschlag akzeptiert und eine entsprechende neue REQUEST erzeugt, entsteht eine Organizer-Revision, die den neuen Scheduling-Zustand transportiert. Das Montag-zu-Dienstag-Beispiel beschreibt keinen realen Vorfall.

Dabei darf auch SEQUENCE nicht als Zustimmungszähler gelesen werden. Nach RFC 2446 zählt die Sequenz Organizer-Revisionen. REPLY, REFRESH, COUNTER, DECLINECOUNTER und ein Delegations-REQUEST erhöhen sie nicht; ADD und CANCEL tun es. Ein REPLY kann zudem auf eine frühere Revision Bezug nehmen. Eine höhere oder niedrigere Zahl beantwortet daher allein weder die Frage nach Zustimmung noch nach dem tatsächlichen Endzustand eines Teilnehmers.

Ähnliche Grenzen gelten für Weiterleitungen. Wird eine Einladung weitergegeben, wird ein zuvor nicht eingeladener Empfänger dadurch nicht automatisch Teil der Master-Liste. Die Entscheidung darüber verbleibt beim Organizer. Der Weiterleitende soll dabei nicht eigenmächtig die Eigenschaften des Events verändern. Auch hier trennt das Protokoll die technische Weitergabe einer Nachricht von der Autorität, den kanonischen Scheduling-Zustand zu verändern.

Die Transportrealität kann die Reihenfolge zusätzlich stören. In einem Store-and-forward-System kann eine CANCEL vor der ursprünglichen REQUEST eintreffen. RFC 2446 schlägt für eine nicht korrelierbare CANCEL mit einer von null verschiedenen SEQUENCE vor, auf eine frühere Nachricht zu warten; ein solcher Wartezustand kann ablaufen. Die Nachrichtensequenz auf dem Draht muss daher nicht der logischen Reihenfolge entsprechen, in der das Scheduling-Modell gedacht ist.

Noch grundlegender ist die Sicherheitsgrenze. Felder wie Organizer oder Attendee authentifizieren ihre behaupteten Identitäten nicht selbst. Spoofing dieser Rollen ist deshalb möglich. Authentifizierung und gegebenenfalls Verschlüsselung müssen über das jeweilige Transport-Binding bereitgestellt werden. RFC 2447, dessen Umfeld auch MIME-Sicherheitsmechanismen wie RFC 1847 berührt, gehört damit zu einer anderen Beweisschicht als die iTIP-Semantik selbst.

Für historische wie operative Analyse ergibt sich daraus eine nützliche Evidenzleiter. Zuerst stehen die empfangenen Bytes. Davon getrennt sind ein authentifizierter Sender und dessen Berechtigung. Danach folgen METHOD und UID, die Organizer-SEQUENCE, individuelles PARTSTAT, ein möglicher COUNTER, die Entscheidung des Organizers, eine neue REQUEST, deren Zustellung, lokale Speicherung, eine Erinnerung und schließlich beobachtete Teilnahme.

Keine dieser Schichten darf stillschweigend die nächste ersetzen. Ein geparster COUNTER beweist, dass ein bestimmter Vorschlag verarbeitet werden konnte; er beweist nicht seine Autorisierung oder Annahme. Eine höhere SEQUENCE beweist eine Organizer-Revision, aber nicht automatisch Konvergenz aller Kopien. Ein Zustellbeleg beweist keine inhaltliche Zustimmung. Ein REPLY beweist nicht zwingend die Verarbeitung der jüngsten Revision. Ein lokaler Annahmeeintrag, eine Erinnerung oder ein sichtbarer Kalendereintrag beweisen weder tatsächliche Teilnahme noch Durchführung.

Damit illustriert RFC 2446 ein breiteres Prinzip der Internetstandardisierung: Norm, Autorität, authentifizierter Transport, Implementierungsverhalten, lokaler Zustand und beobachtete Realität sind verschiedene Kategorien. Die Veröffentlichung einer Spezifikation oder die syntaktische Gültigkeit eines Objekts beweist weder praktischen Einsatz noch Annahme, Konsens oder Ausführung. Die bereitgestellten Texte von Heng Lu können als Perspektive auf genau diese Ebenentrennung gelesen werden, sind aber keine Quellen für die Normativität von iTIP.

Quellen