iCalendar Message-Based Interoperability Protocol (iMIP)
obsoleted by
- rfc-6047 — iCalendar Message-Based Interoperability Protocol (iMIP)
Extracted elements (25)
CID and MID references within iCalendar objects (e.g., in ATTACH properties) should be self-contained in a single MIME entity because there is no guarantee that the receiving Calendar User will have access or authorization to retrieve externally referenced objects.
Content-Disposition with a filename is recommended because some environments dispatch MIME attachments based on file type or extension rather than Content-Type, and providing a filename enables correct handling in those environments.
The 'method' MIME parameter is required on the Content-Type to allow mail processing agents to dispatch iCalendar objects by scheduling method without parsing the body, and its value is constrained to match the internal METHOD property to prevent inconsistency.
Because iTIP does not preclude Attendees from forwarding VEVENTs or VTODOs, the RFC-822 Sender value may not equal the Organizer's address, and the Organizer or Attendee cannot be reliably inferred from the Sender or Reply-To headers of an iMIP message.
The RFC-822 Reply-To header typically contains the email address of the originator or respondent, but this cannot be guaranteed since Mail User Agents are not required to enforce iMIP semantics.
A 'charset' parameter MUST be present in the Content-Type header if the iCalendar object contains characters outside the US-ASCII character set.
A Content-Transfer-Encoding SHOULD be used for iCalendar objects containing characters outside US-ASCII, since the default character set for iCalendar is UTF-8.
A MIME body part conforming to iMIP MUST have an RFC-2045 Content-Type value of 'text/calendar'. The Content-Type header MUST also include the 'method' parameter whose value MUST be the same as the METHOD property in the iCalendar object.
A MIME message containing multiple iCalendar objects with different METHOD values MUST encapsulate each in its own 'text/calendar' MIME entity within a 'multipart/mixed' wrapper.
Compliant applications MUST support signing and encrypting text/calendar attachments using a mechanism based on Security Multiparts for MIME (RFC-1847) to authenticate the originator. Implementations MAY provide a means for users to disable signing and encrypting.
If the signer of an iCalendar message cannot be correlated to an ATTENDEE property in the object, the message MUST be ignored.
Implementations MUST provide mechanisms for Calendar Users to decide whether to apply changes from someone working on their behalf (via the 'sent-by' parameter), since iCAL and iTIP provide no verification mechanism for delegation.
Implementations of iMIP SHOULD verify the authenticity of the creator of an iCalendar object before taking any action.
Scheduling messages SHOULD be sent with an alternative, human-readable (e.g., text/plain) form of the information so that MIME UAs that do not support 'text/calendar' can still render the content.
Signed iMIP messages SHOULD be encrypted using an RFC-1847-based mechanism to address confidentiality threats.
The calendar address in the ATTENDEE property of an iCalendar object MUST be a fully qualified RFC-822 address specification for the corresponding Organizer or Attendee.
The iCalendar object MUST be signed by the Organizer sending an update or the Attendee sending a reply, as the first step in the authentication/authorization procedure.
The relevant Organizer or Attendee address MUST be ascertained by opening the 'text/calendar' MIME body part and examining the ATTENDEE and ORGANIZER properties; the RFC-822 Sender or Reply-To values cannot be relied upon.
Authentication and confidentiality are achieved via RFC-1847 Security Multiparts for MIME, which defines multipart/signed and multipart/encrypted subtypes, each containing a protected data part and a control information part.
iMIP binds iTIP to Internet email by encoding iCalendar objects as 'text/calendar' MIME body parts transported via RFC-822 and RFC-2045 compliant messages.
The optional 'component' parameter on the text/calendar Content-Type defines the iCalendar component type (e.g., component=vevent) contained within the object, allowing processing agents to identify the component type without parsing the body.
Authentication is possible only on signed messages using RFC-1847 multipart/signed with public/private key certificates; authenticating an unsigned message may not be reliable.
Authorization rules from iTIP are enforced at the iMIP layer: only the Organizer may modify or cancel entries they organize, and only the Attendee may reply on their own behalf. Messages from unauthorized originators must be ignored.
The protocol does not restrict a Calendar User Agent from forwarding iCalendar objects to other users or agents, so confidentiality requires explicit RFC-1847-compliant encryption rather than relying on transport security.
Two spoofing threats are identified: spoofing the Organizer and spoofing an Attendee. Receivers must authenticate the originator of an iCalendar object and then determine whether the originator is authorized for the requested operation before processing.