Zusammenfassung

  • PARTSTAT=ACCEPTED bezeichnet den mitgeteilten Teilnahmestatus eines Kalendernutzers; das Feld beobachtet keine spätere Anwesenheit.
  • Antwort, Vertretung, Version, Wiederholung, Zustellung und Ereignisbeobachtung gehören in getrennte Nachweisspalten.

Der Raum ist gebucht, zwölf Einladungen stehen auf „angenommen“, aber zwei Stühle bleiben leer. Darin liegt kein Widerspruch. Die Kalenderdaten beschreiben Antworten aus der Planungsphase. Die leeren Stühle gehören zu einer Beobachtung während des Termins. Erst ein Auswertungssystem, das beides gleichsetzt, erzeugt eine falsche Tatsachenbehauptung.

RFC 5545 definiert PARTSTAT als Teilnahmestatus eines Kalendernutzers. Für Ereignisse nennt die Spezifikation unter anderem NEEDS-ACTION, ACCEPTED, DECLINED, TENTATIVE und DELEGATED. Das ist ein präzises Vokabular für Einladungen. Es misst weder Zutritt noch Verbindung, Aufenthaltsdauer, Aufmerksamkeit oder Mitwirkung.

Daboos Verbindung zwischen den Protokollschichten

Cyrus Daboo arbeitete an den Normen, die diesen Status durch mehrere Systeme tragen. Er ist Mitautor von CalDAV, RFC 4791, Autor von iTIP, RFC 5546 und mit Bernard Desruisseaux Mitautor von CalDAV Scheduling, RFC 6638. Sein IETF-Profil führte im Rechercheabzug 26 RFCs auf. Die CalConnect-Auszeichnung von 2013 hält seine damaligen Beiträge zu CalDAV und Kalender-Interoperabilität fest.

RFC 5545 stammt allerdings von Bernard Desruisseaux. Die Personalisierung einer Geschichte darf die gemeinschaftliche Urheberschaft technischer Standards nicht verwischen. Daboos besondere Relevanz liegt hier in iTIP und der serverseitigen CalDAV-Planung.

Wer welchen Zustand beherrscht

In iTIP kontrolliert der Organisator das maßgebliche Planungsobjekt. Eine eingeladene Person beginnt gewöhnlich mit NEEDS-ACTION. Sie ändert PARTSTAT an ihrer eigenen ATTENDEE-Eigenschaft und sendet eine REPLY; der Organisator übernimmt die Antwort. Der allgemeine STATUS des Ereignisses und das PARTSTAT eines Teilnehmers sind getrennte Zustände mit getrennter Autorität.

Ein ACCEPTED in der Organisator-Kopie belegt daher nur, dass dieser Adresse in dieser Objektversion eine Annahmeantwort zugeordnet ist. Wer das Programm bedient hat und was beim Termin geschah, folgt daraus nicht.

Adresse, Antwortender und Anwesender

RFC 5546 sieht Vertretung ausdrücklich vor. Ein Eingeladener kann einem anderen Kalendernutzer die Teilnahme in seinem Namen übertragen. SENT-BY zeigt, dass ein Nutzer für den genannten Teilnehmer oder Organisator geantwortet hat. Assistenz, gemeinsames Postfach oder autorisierte Automatisierung können also rechtmäßig am Vorgang beteiligt sein.

Die Einladungsadresse, der Auslöser der Antwort und die später anwesende Person können drei verschiedene Identitäten sein. Wer Delegations- und SENT-BY-Daten verwirft, kann diese Zuordnung nachträglich nicht mehr prüfen.

Eine Zusage gilt für eine bestimmte Fassung

Termine ändern sich. Nach RFC 5546 kennzeichnet SEQUENCE die Revisionen des Organisators; eine REPLY erhöht die Nummer nicht. Die Sequenz der Antwort zeigt, auf welche Fassung reagiert wurde. Nach einer wesentlichen Änderung von Zeit, Ort oder Inhalt darf die alte Zusage nicht als Zustimmung zur neuen Fassung gelten.

Bei Serien kommt die einzelne Instanz hinzu. Eine generelle Zusage kann neben einer mit RECURRENCE-ID bezeichneten Absage, Verschiebung oder Ausnahme bestehen. Das Serien-ACCEPTED auf jeden Termin zu kopieren erzeugt Anwesenheiten, die nie erklärt wurden.

Ein CalDAV-Server verarbeitet Planung

RFC 6638 beschreibt implizite Planung: Speichern, Ändern oder Löschen eines Planungsobjekts kann den Server veranlassen, Nachrichten zu versenden. Eingehende Nachrichten können automatisch verarbeitet werden. Eine Antwort aktualisiert beim Organisator das PARTSTAT; SCHEDULE-STATUS kann Zustell- oder Verarbeitungsergebnisse festhalten. Der Planungsagent kann SERVER, CLIENT oder NONE sein.

Diese Spuren sind für den Betrieb sehr nützlich. Sie zeigen jedoch keine menschliche Wahrnehmung. Erfolgreiche Zustellung bedeutet nicht, dass jemand die Einladung gelesen hat; automatische Verarbeitung bedeutet erst recht nicht, dass die Person beim Ereignis war.

Anwesenheit braucht einen eigenen Messvertrag

Für Sicherheit, Quorum, Zertifizierung oder Abrechnung kann ein Anwesenheitsnachweis notwendig sein. Dann muss eine geeignete Ereignisquelle samt Fehlergrenzen festgelegt werden. Karten lassen sich weitergeben, Konferenzverbindungen unbeaufsichtigt offenhalten, Anwesenheitslisten falsch führen. Jede Methode belegt nur ihr jeweiliges Signal.

Ein belastbares Nachweisregister trennt Einladungsadresse, Antwortwert, Antwortenden oder Vertreter, SEQUENCE, Instanz, Zustellstatus, Ereignissignal, Messmethode, Zeitfenster und Einspruch. PARTSTAT=ACCEPTED gehört in die Antwortspalte. Ohne Beobachtung bleibt die Anwesenheitsspalte leer.

Diese Lücke ist keine fehlende Datenpflege, sondern eine zutreffende Grenze des Wissens.