iCalendar Transport-Independent Interoperability Protocol (iTIP)
obsoletes
- rfc-2446 — iCalendar Transport-Independent Interoperability Protocol (iTIP) Scheduling Events, BusyTime, To-dos and Journal Entries
updated by
- rfc-6638 — Scheduling Extensions to CalDAV
updates
- rfc-5545 — Internet Calendaring and Scheduling Core Object Specification (iCalendar)
Extracted elements (30)
iTIP is defined without reference to a specific transport protocol so that it can be bound to multiple communication methods (real-time, store-and-forward, email via iMIP, etc.). This layered approach allows the application protocol to remain stable while transport bindings evolve independently.
The Organizer retains complete control over the master iCalendar object; Attendees cannot directly modify it but may suggest changes via COUNTER. This asymmetric authority model avoids conflicting simultaneous edits and mirrors common real-world meeting organization practices.
Clients that cannot handle the REQUEST method MAY degrade and treat a REQUEST VEVENT as a PUBLISH. This fallback is defined in Section 5.1.1 to ensure partial implementations can still consume event information even without full interactive scheduling support.
The SENT-BY parameter on ORGANIZER or ATTENDEE properties indicates that a CU is acting on behalf of another (e.g., an assistant managing a meeting for their manager). Attendee responses are still directed to the CU designated as Organizer, not the SENT-BY CU.
Apart from VTIMEZONE components, only one calendar component type is allowed in a single iTIP message. The VERSION property in the VCALENDAR wrapper MUST be 2.0.
Attendee CUAs SHOULD NOT rely solely on a change in SEQUENCE number as a means of detecting a significant change. Instead, CUAs SHOULD compare the old and new versions of calendar components directly and determine the exact nature of changes before deciding whether to notify the user.
For VFREEBUSY REQUEST, the sender MUST include ORGANIZER, DTSTART, DTEND, and DTSTAMP, but MUST NOT include ATTENDEE properties in the request body itself (ATTENDEE appears as the target in the outer wrapper). VFREEBUSY REPLY MUST include FREEBUSY properties reflecting the Attendee's busy periods.
If the UID in an ADD message is not found on the recipient's calendar, the recipient SHOULD send a REFRESH to the Organizer to obtain the latest version. If an Attendee does not support ADD, it should respond with REQUEST-STATUS value 3.14.
In a COUNTER VEVENT, the Attendee proposes an alternative event time or details to the Organizer. The Organizer MUST respond with either an updated REQUEST (accepting the counter) or a DECLINECOUNTER message. COUNTER MUST NOT be used for VJOURNAL or VFREEBUSY components.
In a PUBLISH VEVENT, the ORGANIZER property MUST be present and ATTENDEE properties MUST NOT be present. This distinguishes unsolicited broadcasting of event information from interactive scheduling requests.
In a REPLY VEVENT, optional properties (those listed as 0+ or 0 or 1) MUST NOT be changed from those of the original REQUEST; if property changes are desired, the COUNTER method must be used instead. Exactly one ATTENDEE (the replying Attendee) must be present.
In a REQUEST VEVENT, when multiple VEVENT components appear in a single iCalendar object they MUST all have the same UID (used to express instance-specific data for a recurring series). ATTENDEE (1+), DTSTART (1), ORGANIZER (1), SUMMARY (1), and UID (1) are all required.
In the delegation workflow, the Delegator MUST notify the Organizer by sending a REPLY with PARTSTAT=DELEGATED and including the DELEGATED-TO parameter with the Delegate's calendar address. The Delegate MUST send a REPLY to the Organizer, and SHOULD include the DELEGATED-FROM parameter referencing the Delegator.
The primary key for correlating iCalendar components is the UID property value; for recurring component instances, the primary key is composed of UID and RECURRENCE-ID together. The secondary key is the SEQUENCE property: among components with the same UID and RECURRENCE-ID, the one with the highest SEQUENCE value obsoletes all lower-valued revisions.
The SEQUENCE property MUST be incremented by the Organizer whenever any of the following properties change: DTSTART, DTEND, DURATION, DUE, RRULE, RDATE, EXDATE, or STATUS. Changes to other properties MAY also require incrementing if they would jeopardize the validity of Attendee participation status.
The SEQUENCE property value MUST NOT be incremented when using REPLY, REFRESH, COUNTER, DECLINECOUNTER, or when sending a delegation REQUEST. SEQUENCE MUST be incremented each time the Organizer uses the ADD or CANCEL methods.
To cancel the complete range of a recurring VEVENT, the UID MUST be specified and RECURRENCE-ID MUST NOT be specified. To cancel an individual instance, RECURRENCE-ID MUST be specified. The Organizer MUST send a CANCEL message to each Attendee affected, and SEQUENCE MUST be incremented.
VTIMEZONE MUST be present in an iTIP message if any date/time value in that message refers to a timezone. VTIMEZONE components may contain STANDARD and DAYLIGHT sub-components, of which at least one MUST be present.
When an Attendee forwards a REQUEST to an uninvited CU, the forwarding Attendee MUST NOT make changes to the original message. The Organizer is not obligated to accept the uninvited CU and MAY send a CANCEL to indicate rejection.
When UID, RECURRENCE-ID, and SEQUENCE all match, the DTSTAMP property is used as a tiebreaker: the component or Attendee response with the latest DTSTAMP overrides all others. CUAs MUST persist UID, RECURRENCE-ID, SEQUENCE, and DTSTAMP to correctly process iTIP messages.
iTIP messages inherently reveal personal scheduling information including participants, meeting times, locations, and subjects. Section 6.3 notes that implementations should consider access controls, minimal disclosure of Attendee information, and transport-level confidentiality to protect user privacy.
iTIP defines eight scheduling methods: PUBLISH, REQUEST, REPLY, ADD, CANCEL, REFRESH, COUNTER, and DECLINECOUNTER. Organizers may send PUBLISH, REQUEST, ADD, CANCEL, and DECLINECOUNTER; Attendees may send REPLY, REFRESH, COUNTER, and REQUEST (only when delegating).
Scheduling state has two dimensions: the overall iCalendar object state controlled by the Organizer via the STATUS property, and per-Attendee state tracked by the PARTSTAT parameter on each ATTENDEE property. When an Organizer issues the initial object, Attendees are set to NEEDS-ACTION; each Attendee modifies PARTSTAT (e.g., ACCEPTED, DECLINED, TENTATIVE, DELEGATED) via a REPLY.
The REQUEST-STATUS property carries transaction/request status information in REPLY messages. Its value is a hierarchical numeric code (e.g., 2.0 = success, 3.x = client error, 4.x = scheduling error, 5.x = server error) optionally followed by a human-readable description and data.
RFC 5546 defines the REQUEST-STATUS Value Registry for numeric status codes returned in scheduling responses. The registry is structured with hierarchical codes: 1.x (preliminary), 2.x (success), 3.x (client error), 4.x (scheduling error), 5.x (server error). New values require IETF Review.
RFC 5546 updates the iCalendar METHOD Registry (originally created by RFC 2446) to add the eight iTIP method values: PUBLISH, REQUEST, REPLY, ADD, CANCEL, REFRESH, COUNTER, and DECLINECOUNTER, along with their applicable component types and descriptions.
Eavesdropping and data integrity: iTIP messages may contain sensitive scheduling information. The RFC recommends securing iTIP transactions using S/MIME or similar to provide confidentiality and data integrity, especially over untrusted transports.
Flooding a calendar: a malicious actor could send a large number of unsolicited iTIP REQUEST or PUBLISH messages to fill a user's calendar with bogus events. Implementations SHOULD provide access controls and filtering mechanisms to limit which sources are trusted to inject calendar data.
Spoofing the Organizer: an attacker could forge iTIP messages purporting to come from the Organizer to cancel events, change times, or remove Attendees. Implementations SHOULD use S/MIME, OpenPGP, or equivalent to authenticate the originator of iTIP messages.
Unauthorized replacement of the Organizer: an Attendee could forge a REQUEST with an incremented SEQUENCE and a changed ORGANIZER property to usurp control of an event. Implementations should verify the identity of the sender before accepting a change to the Organizer role.