iTIP is defined independent of the particular transport used to transmit scheduling information. This allows the same application-layer protocol to be bound to multiple transports (store-and-forward email via iMIP, real-time, or others), preventing lock-in to a single delivery mechanism.

The COUNTER/DECLINECOUNTER method pair was introduced to support negotiation workflows common in existing calendar systems, where an Attendee may propose an alternate time or location. The Organizer retains final authority: acceptance of a COUNTER requires the Organizer to issue a new REQUEST (rescheduling), while rejection uses DECLINECOUNTER.

The DTSTAMP tie-breaker rule (section 2.1.5 rule 4) was added to handle the common case where the same UID and SEQUENCE appear in multiple messages — for example, when an Organizer sends unsolicited reconfirmations without incrementing SEQUENCE. Using the latest DTSTAMP ensures the most recently generated object wins without requiring a new revision number.

Clients that cannot handle the REQUEST method MAY degrade the event to view it as a PUBLISH. Similarly, clients that cannot handle VTODO REQUEST MAY degrade it to treat it as a PUBLISH. This graceful degradation allows read-only calendar clients to participate in the ecosystem.

If a VFREEBUSY REQUEST originator is not authorized to make a busy time request, an exception SHOULD be returned in a REPLY method but no busy time data need be returned. If the transport binding supports exception messages, an 'unsupported capability' message may also be returned to the requester.

Applications desiring free time information MUST infer it from available busy time information; iTIP only transfers busy time data. Duplicate busy time periods SHOULD NOT be specified, though two different periods MAY overlap. FREEBUSY properties SHOULD be sorted in ascending order by start time.

CUAs must correlate components using UID as the primary key (with RECURRENCE-ID for recurring instances), SEQUENCE as the secondary key (highest numeric value obsoletes lower), and DTSTAMP as the tie-breaker when UID and SEQUENCE match. CUAs MUST persist the UID, RECURRENCE-ID, SEQUENCE, and DTSTAMP properties for each component and for each Attendee's response.

If the UID in an ADD method is not found on the recipient's calendar, the recipient SHOULD send a REFRESH to the Organizer to obtain the latest version of the VEVENT. An Attendee implementation that does not support ADD should respond with REQUEST-STATUS value 3.14 and request a REFRESH.

In a VEVENT REPLY, the 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.

In a VFREEBUSY REPLY, FREEBUSY property values MUST all be of the same data type; multiple instances MUST be sorted in ascending order; and values MAY NOT overlap. Both comma-separated lists within a single FREEBUSY property and multiple FREEBUSY properties MUST be supported by conforming implementations.

In VEVENT PUBLISH, ATTENDEE MUST NOT be present (value = 0). In VEVENT REQUEST, at least one ATTENDEE (1+) MUST be present. The VERSION property MUST equal '2.0' and PRODID MUST appear exactly once in every iTIP message.

In VFREEBUSY REQUEST and REPLY methods, all DateTime values for DTSTART and DTEND MUST be in UTC. In VFREEBUSY PUBLISH, DTSTART and DTEND likewise MUST be in UTC.

The SEQUENCE property value MUST be incremented each time the Organizer uses the ADD or CANCEL methods. It MUST NOT be incremented when using REPLY, REFRESH, COUNTER, DECLINECOUNTER, or when sending a delegation REQUEST.

VTIMEZONE components MUST be present in an iTIP message if any date/time value in the message refers to a timezone. Within VTIMEZONE, DTSTART MUST be in local time format, and each STANDARD or DAYLIGHT sub-component must have TZOFFSETFROM and TZOFFSETTO.

When a VEVENT is cancelled, the SEQUENCE property value MUST be incremented. To cancel the entire recurring event, RECURRENCE-ID MUST NOT be specified; to cancel a single instance, RECURRENCE-ID MUST be specified. A range of instances may be cancelled using RECURRENCE-ID with the RANGE parameter set to THISANDPRIOR or THISANDFUTURE.

When delegating, the Delegator MUST notify the Organizer by sending a REPLY with partstat=DELEGATED and a 'delegated-to' parameter containing the Delegate's calendar address. The Delegate MUST send a REPLY to the Organizer and SHOULD include the 'delegated-from' parameter with the Delegator's address.

When forwarding a REQUEST to an uninvited calendar user, the forwarding Attendee MUST NOT make changes to the VEVENT property set. The Organizer decides whether to add the uninvited CU; if declining, the Organizer MAY send a CANCEL to the uninvited CU.

iTIP defines eight scheduling methods: PUBLISH (unsolicited posting), REQUEST (interactive scheduling), REPLY (attendee response), ADD (add instances), CANCEL (cancel instances), REFRESH (request latest version), COUNTER (propose alternate), and DECLINECOUNTER (reject counter). Organizers may send PUBLISH, REQUEST, ADD, CANCEL, and DECLINECOUNTER; Attendees may send REPLY, REFRESH, and COUNTER (plus REQUEST when delegating).

realtime

iTIP defines two calendar user roles: 'Organizer' (the CU who initiates scheduling and retains full control over the master calendar entry) and 'Attendee' (the CU invited to participate). Attendees do not make direct changes to the master entry; they may only suggest changes via COUNTER.

The PUBLISH method is an unsolicited posting of a calendar component. For VEVENT PUBLISH, ORGANIZER MUST be present, ATTENDEE MUST NOT be present, and DTSTAMP, DTSTART, SUMMARY, and UID are required. The Organizer may subsequently update (PUBLISH), add instances (ADD), or cancel (CANCEL) the published component.

The REQUEST method is used to invite Attendees, reschedule, update, reconfirm, delegate, or change Organizer for a VEVENT. If the UID is not found on the recipient's calendar, it is a new event; if found with a higher SEQUENCE or DTSTAMP, it is a reschedule; if found with the same SEQUENCE, it is an update. Multiple VEVENT components in one REQUEST are permitted only if they share the same UID.

The 'sent-by' parameter may be specified in either the ORGANIZER or ATTENDEE properties to indicate that the responding calendar user acted on behalf of the named principal. Attendee responses sent via 'sent-by' are still directed toward the CU designated as Organizer.

VTODO REPLY Attendees may set PARTSTAT to ACCEPTED, DECLINED, TENTATIVE, DELEGATED, PARTIAL, and COMPLETED — a superset of the VEVENT REPLY values. This reflects the need to convey task progress states (partial completion, full completion) that have no equivalent for meeting attendance.

iTIP implementations SHOULD use RFC-1847 (S/MIME multipart/signed and multipart/encrypted) to sign and/or encrypt iTIP transactions, providing data integrity, authentication, and confidentiality. Implementation controls such as filtering unknown or unauthorized organizers and rate-limiting incoming scheduling messages are also recommended.

security, email

Key iTIP security threats include: spoofing the Organizer (forging REQUEST/CANCEL to manipulate attendees' calendars), spoofing the Attendee (forging REPLY to falsify attendance status), unauthorized replacement of the Organizer, eavesdropping on scheduling data, flooding a calendar with unsolicited REQUEST messages, procedural alarms triggered by malicious calendar components, and unauthorized REFRESH requests.

security

Calendar entry state is controlled by the Organizer via the STATUS property (no default; values include TENTATIVE, CONFIRMED, CANCELLED). Attendee-specific state is carried in the 'partstat' parameter of the ATTENDEE property; initial value is NEEDS-ACTION, and Attendees update it (ACCEPTED, DECLINED, TENTATIVE, DELEGATED, etc.) via REPLY messages.