Zusammenfassung

  • iMIP legte fest, wie ein iTIP-Kalenderobjekt in eine MIME-E-Mail eingebettet wird, statt die Terminbedeutung aus gewöhnlichen Nachrichtenköpfen abzuleiten.
  • Eine menschenlesbare Fassung verbesserte die Kompatibilität; sie war jedoch keine zweite, abweichende Terminoption.

Was die E-Mail transportierte – und was nicht

Eine Einladung konnte im Posteingang sichtbar sein, bevor irgendein Kalenderprogramm verstand, was zu tun war. RFC 2447, veröffentlicht 1998 als iCalendar Message-Based Interoperability Protocol (iMIP), definierte den Übergang zwischen E-Mail und dem transportunabhängigen iTIP. iCalendar lieferte das Objektmodell, iTIP die Operationen für den Austausch, MIME die Verpackung in Nachrichtenteile. Der Mailtransport musste keine eigenen Regeln für Terminänderungen erfinden.

Die entscheidende MIME-Teilart hieß text/calendar. Ihr Parameter method musste denselben Wert wie die Eigenschaft METHOD im eingebetteten iCalendar-Objekt führen. So konnte der äußere Parser den Nachrichtenteil erkennen, während der Kalenderclient die konkrete Operation aus dem Objekt las. Die doppelte Angabe hob die Schichten nicht auf; sie verband sie. Enthielt eine Nachricht mehrere Kalenderobjekte mit unterschiedlichen Methoden, mussten sie in getrennten text/calendar-Teilen innerhalb von multipart/mixed stehen. Andernfalls würden eigenständige Vorgänge in einer uneindeutigen Einheit verschwimmen.

Lesetext ist keine zweite Terminlage

Nicht jeder Mail User Agent konnte iCalendar verarbeiten. MIME erlaubte daher, in multipart/alternative zusätzlich eine lesbare Erklärung unterzubringen. Ein einfacher Mailclient konnte Datum, Ort und Anlass anzeigen; ein Kalenderclient konnte das strukturierte Objekt importieren. Beide Ansichten sollten denselben Termin beschreiben.

Das ist etwas anderes, als zwei unterschiedliche VEVENTs als „Alternativen“ anzubieten. Zwei abweichende Uhrzeiten sind nicht zwei Darstellungen desselben Objekts. Der Empfänger könnte nicht erkennen, ob er eine Auswahl treffen, eine Korrektur lesen oder einen Widerspruch auflösen soll. Ein neuer Terminvorschlag gehört in die dafür vorgesehene iTIP-Operation. Die MIME-Struktur organisiert Darstellung und Transport, nicht die Entscheidung über den Termin.

Auch Zeichensatz und Transfer-Encoding waren Teil der Brücke. RFC 2447 verlangte eine Charset-Angabe, wenn Kalendertext über US-ASCII hinausging, und erläuterte geeignete Codierungen für Transportwege, die bestimmte Bytes nicht unmittelbar tragen konnten. RFC 6047 löste RFC 2447 2010 ab und aktualisierte die Bindung unter anderem für neuere Nachrichtenformate und S/MIME. Diese Regeln schützen die Darstellung im Transit; sie belegen nicht, dass eine Nachricht tatsächlich zugestellt oder ein Termin lokal gespeichert wurde.

Verweise auf Anhänge zeigen denselben Unterschied zwischen Adresse und Inhalt. Ein Kalenderobjekt kann Material über Content-ID oder Message-ID referenzieren. RFC 2447 empfahl, referenzierte MIME-Teile nach Möglichkeit gemeinsam mit dem Kalenderobjekt zu übertragen: Der Empfänger könnte sonst weder Zugriff noch Berechtigung auf ein extern gespeichertes Dokument haben. Ein Bezeichner ist kein Anhang und kein Zugriffsrecht.

Auch Sender und Reply-To liefern nicht zuverlässig die Kalenderrolle. Nach einer Weiterleitung kann der Absender vom Organizer abweichen; ein Mailprogramm muss die Rolle nicht in Reply-To spiegeln. Die Implementierung muss deshalb ORGANIZER und ATTENDEE im Kalenderteil lesen. RFC 2447 beschrieb MIME-Sicherheitsteile zur Authentifizierung und Vertraulichkeit; RFC 6047 machte später S/MIME-Authentifizierung verbindlich. Eine gültige Signatur gilt für den geschützten Teil. Sie weist weder Zustellung noch Verarbeitung durch den Kalenderclient, Zustimmung oder tatsächliche Teilnahme nach.

RFC 2447 erschien im November 1998 als Standards-Track-Dokument und wurde 2010 durch RFC 6047 obsolet. Die Abfolge dokumentiert eine aktualisierte Transportschnittstelle, aber keine Marktverbreitung. Der dauerhafte historische Punkt ist enger: Kalenderobjekt, MIME-Paket und E-Mail-Transport erledigen verschiedene Aufgaben. Eine erfolgreiche Zustellung darf nicht als Beleg für einen geänderten Termin ausgegeben werden.

Quellen