WSS
Web Specification Studio Home
On this page
AutomationRecommendedUpdated

iCalendar (iMIP) Automated Calendar Invitations

Publish standards-compliant calendar meeting invites, updates, and cancellations using iCalendar (RFC 5545) and iMIP (RFC 6047) multipart attachments.

What it is

iCalendar Message-Based Interoperability Protocol (iMIP), defined in RFC 6047, is the standard protocol for transmitting calendar invitations, schedule updates, RSVPs, and meeting cancellations over email.

When an email contains an iMIP payload, the email client (Apple Calendar, Google Calendar in Gmail, Microsoft Outlook) detects the calendar stream and presents native “Accept / Decline / Maybe” action buttons, automatically booking the event into the user’s primary calendar upon selection.

Content-Type: multipart/mixed; boundary="boundary-cal-123"

--boundary-cal-123
Content-Type: text/calendar; method=REQUEST; charset="utf-8"
Content-Transfer-Encoding: 7bit

BEGIN:VCALENDAR
PRODID:-//Web Specification Studio//Calendar Dispatcher 1.0//EN
VERSION:2.0
CALSCALE:GREGORIAN
METHOD:REQUEST
BEGIN:VEVENT
UID:[email protected]
DTSTAMP:20260825T143000Z
ORGANIZER;CN="Web Specification Studio":mailto:[email protected]
DTSTART:20260828T160000Z
DTEND:20260828T170000Z
SUMMARY:Technical Review: Next-Gen Web Specifications
DESCRIPTION:Quarterly architecture sync on edge-rendering standards.
LOCATION:https://meet.example.com/spec-sync
SEQUENCE:0
STATUS:CONFIRMED
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN="Dev Team":mailto:[email protected]
END:VEVENT
END:VCALENDAR
--boundary-cal-123--

Why it matters

  • Native Calendar Sync Across All Ecosystems: Sending an .ics attachment without proper iMIP MIME declaration forces the user to manually download a file and import it into their calendar app. A compliant iMIP message allows instant one-tap acceptance inside Google Calendar, Apple Calendar, and Outlook.
  • Update and Cancellation Integrity: When meeting times change or an event is cancelled, emitting an updated iMIP payload with the same UID and an incremented SEQUENCE number automatically updates the recipient’s existing calendar entry without creating duplicate ghost events.
  • Timezone Safety: Specifying timestamps in UTC (Z suffix) or with explicit VTIMEZONE blocks prevents meetings from shifting across daylight saving transitions and international time zones.

How to implement

1. Set the correct MIME Content-Type headers for the calendar part: The calendar part must specify method=REQUEST (or method=CANCEL) in the Content-Type header parameter:

Content-Type: text/calendar; method=REQUEST; charset="utf-8"; name="invite.ics"
Content-Disposition: inline; filename="invite.ics"
Content-Transfer-Encoding: 7bit

2. Generate Persistent, Globally Unique UID Strings: The UID property is the persistent primary key of the event. It must remain constant throughout the entire lifecycle of the meeting (original invitation, rescheduled updates, and eventual cancellation):

UID:[email protected]

3. Manage SEQUENCE Numbers for Updates and Rescheduling:

  • Initial Invitation: Set SEQUENCE:0.
  • Rescheduled / Updated Event: Retain the same UID, update DTSTART/DTEND, and increment to SEQUENCE:1 (then SEQUENCE:2, etc.).
  • Cancellation: Retain the same UID, set METHOD:CANCEL in both Content-Type and VCALENDAR, set STATUS:CANCELLED, and increment the SEQUENCE number:
BEGIN:VCALENDAR
VERSION:2.0
METHOD:CANCEL
BEGIN:VEVENT
UID:[email protected]
SEQUENCE:1
STATUS:CANCELLED
...

4. Format Timestamps in Strict UTC (ISO-8601 / RFC 5545): Format all timestamps in UTC with the trailing Z character: YYYYMMDDTHHMMSSZ (e.g., 20260828T160000Z).

Common mistakes

  • Changing the UID on Meeting Reschedules: Generating a new UID when updating an event time causes email clients to create a duplicate calendar entry while leaving the old obsolete meeting on the user’s schedule.
  • Omitting method=REQUEST in the MIME Header: If method=REQUEST is only inside the .ics file but omitted from the outer HTTP/MIME Content-Type header, Gmail treats the invite as a static file attachment rather than an interactive invitation.
  • Formatting Local Timestamps without Timezone Identifiers: Writing DTSTART:20260828T160000 without a Z or TZID, causing calendar engines to interpret the time in whatever timezone the recipient happens to be in.
  • Missing ORGANIZER or ATTENDEE Fields: Outlook requires both ORGANIZER and ATTENDEE fields with matching email addresses to process inline RSVP responses.

Verification

1. Inspect MIME structure with Python / CLI parser:

python3 -c "
import email
msg = email.message_from_bytes(open('invite.eml', 'rb').read())
for p in msg.walk():
    if p.get_content_type() == 'text/calendar':
        print('Calendar part found. Method:', p.get_param('method'))
"

2. Test full lifecycle in Google Calendar and Apple Mail:

  1. Send initial invite (SEQUENCE:0) -> Click “Accept” -> Confirm event appears on calendar.
  2. Send update (SEQUENCE:1 with changed time) -> Confirm calendar automatically updates to new time.
  3. Send cancellation (SEQUENCE:2, STATUS:CANCELLED) -> Confirm event is removed from calendar.

Related topics

Sources & further reading