RFC 6047

iCalendar Message-Based Interoperability Protocol (iMIP)

📅 published December 2010, from ietf

RFC 6047: iCalendar Message-Based Interoperability Protocol (iMIP) 💌✨

okay bestie, let's get into it 🎀 this one is RFC 6047, the iMIP spec, written by A. Melnikov, Ed. from Isode Ltd. It's a Standards Track doc, dated December 2010, with ISSN 2070-1721. It obsoletes RFC 2447, so it's the newer, glowed-up version of that one 🦋 It doesn't update anything else.

Abstract

so the big idea 🧚 this doc is a binding from iTIP (the iCalendar Transport-independent Interoperability Protocol) to internet email transports. Calendar entries from the iCalendar Object Model get wrapped up in RFC 5322 and MIME (that's RFC 2045, RFC 2046, RFC 2047, and RFC 2049), and then they get sent over SMTP 💅 it's basically calendar invites riding email rails 📬

Status of This Memo

this is an Internet Standards Track document 🌸

it's a product of the Internet Engineering Task Force (IETF) 💖 it represents the consensus of the IETF community, it got public review, and the Internet Engineering Steering Group (IESG) approved it for publication 🫶 if you want more on Internet Standards, check out Section 2 of RFC 5741.

if you want the current status, any errata, or a way to send feedback, go to http://www.rfc-editor.org/info/rfc6047 🔥

Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved. 💜

this doc is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as they stand on the publication date. read them carefully, because they explain your rights and restrictions with this doc 📜 any Code Components pulled out of this doc have to include Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions, and they come with no warranty, per that same Simplified BSD License 🙈

this doc might have material from IETF Documents or IETF Contributions that were published or made publicly available before November 10, 2008. the people who control the copyright in some of that material might not have given the IETF Trust permission to allow changes outside the IETF Standards Process 😭 so unless you get a proper license from those copyright holders, this doc can't be modified outside the IETF Standards Process, and derivative works can't be made outside it either. the only exceptions are formatting it for publication as an RFC or translating it into languages other than English 🌈

Table of Contents

   1. Introduction ....................................................3
      1.1. Related Memos ..............................................3
      1.2. Formatting Conventions .....................................3
      1.3. Terminology ................................................4
   2. MIME Message Format Binding .....................................4
      2.1. MIME Media Type ............................................4
      2.2. Security ...................................................5
           2.2.1. Authorization .......................................5
           2.2.2. Authentication ......................................5
           2.2.3. Confidentiality .....................................5
      2.3. Email Addresses ............................................6
      2.4. Content-Type Header Field ..................................6
      2.5. Content-Transfer-Encoding Header Field .....................7
      2.6. Content-Disposition Header Field ...........................8
   3. Security Considerations .........................................8
   4. Examples .......................................................11
      4.1. Single Component with an ATTACH Property ..................11
      4.2. Using multipart/alternative for Low-Fidelity Clients ......11
      4.3. Single Component with an ATTACH Property and
           Inline Attachment .........................................12
      4.4. Multiple Similar Components ...............................14
      4.5. Multiple Mixed Components .................................15
      4.6. Detailed Components with an ATTACH Property ...............16
   5. Recommended Practices ..........................................18
      5.1. Use of Content and Message IDs ............................18
   6. IANA Considerations ............................................18
   7. References .....................................................19
      7.1. Normative References ......................................19
      7.2. Informative References ....................................20
   Appendix A. Changes since RFC 2447 ................................21
   Appendix B. Acknowledgements ......................................22

1. Introduction ✨

this doc gives you the transport-specific info (the "binding") you need to send iCalendar Transport-independent Interoperability Protocol (iTIP) [iTIP] messages over internet email, using MIME as defined in [RFC5322] and [RFC2045] 💖 so this is where we officially define the iCalendar Message-Based Interoperability Protocol (iMIP) 🎀

implementers are going to need to know a few other memos too 🧚 together with this one, they make up the framework for Internet calendaring and scheduling standards.

this memo is the Internet email binding for iTIP 💌

[iCAL] is the core spec for objects, data types, properties, and property parameters 📚

[iTIP] is the interoperability protocol for scheduling between different implementations 🤝

this memo doesn't try to repeat the concepts and definitions from those other memos 🙅‍♀️ when it can, it just points you to the memo that defines them.

1.2. Formatting Conventions

the mechanisms in this memo are written in prose 📝 to talk about the calendaring and scheduling model, the core objects, or the interoperability protocol from [iCAL] and [iTIP], there are some formatting conventions.

the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. these are the BCP 14 key words, so pay attention to them 👑

calendaring and scheduling roles show up in quoted strings where every word starts with a capital letter 🎀 for example, "Organizer" means a role of a "Calendar User" in the scheduling protocol from [iTIP].

calendar components from [iCAL] are also written as capitalized, quoted strings, and they all start with the letter "V" 🌸 for example, "VEVENT" is the event component, "VTODO" is the to-do component, and "VJOURNAL" is the daily journal component.

scheduling methods from [iTIP] get the same capitalized, quoted-string treatment. for example, "REQUEST" is the method for asking that a scheduling calendar component be created or modified 💅 and "REPLY" is what a recipient of a request uses to update their status with the "Organizer" of that component.

properties from [iCAL] are capitalized, quoted strings followed by the word "property" 🦋 for example, the "ATTENDEE" property is the iCalendar property that carries the calendar address of a "Calendar User".

property parameters from [iCAL] are lowercase, quoted strings followed by the word "parameter" 🍓 for example, the "value" parameter is the iCalendar property parameter that overrides the default data type for a property value.

1.3. Terminology

the email terms in this memo come from [RFC5322] and [RFC2045] 📬 the calendaring and scheduling terms come from [iCAL] and [iTIP]. easy 💖

2. MIME Message Format Binding 🌈

this section defines the message binding for the MIME electronic mail transport 💌

when this section talks about the "originator" and the "recipient" of an iMIP message, here's the deal: for a "request" method, the originator is the "Organizer" and the recipient is an "Attendee" of the event 🎀 for a "response" method, it's flipped, so the originator is an "Attendee" and the recipient is the "Organizer" of the event.

the "Reply-To" header field from [RFC5322] usually has the email address of the originator of the scheduling message 🧚 but that's not guaranteed, because the sender of the iMIP message might not be the originator, and the sender's "Mail User Agent" (MUA) might not turn the originator's address into the "Reply-To" email header field 🙈

2.1. MIME Media Type

a MIME entity with content info formatted according to this document gets referred to as a "text/calendar" content type [iCAL] 💜 it's assumed this content type gets carried through a MIME electronic mail transport.

2.2. Security

this section covers several security aspects: authentication, authorization, and confidentiality 🔐 authentication and confidentiality can be done with Secure/MIME (S/MIME) [RFC5750] [RFC5751], which uses the Security Multiparts framework for MIME [RFC1847].

2.2.1. Authorization

in iTIP messages [iTIP], only the "Organizer" is authorized to modify or cancel the calendar entries she organizes 👑 so spoof@xyz.example.net is not allowed to modify or cancel a meeting that was organized by a@example.com. 💀 also, only the respondent has the authorization to indicate their status to the "Organizer". so the "Organizer" MUST ignore an iTIP message from spoof@xyz.example.net that declines a meeting invitation for b@example.com. no thank you 🙅‍♀️

implementations of iMIP SHOULD verify the authenticity of the creator of an iCalendar object before taking any action 🫶 the methods for doing that come later in this doc.

the [RFC1847] message flow in iTIP lets someone work on behalf of a "Calendar User" through the "sent-by" parameter that's attached to the "ATTENDEE" and "ORGANIZER" properties ✨ but there's no mechanism to verify whether a "Calendar User" actually authorized someone to act for them 😭 it's up to implementations to give "Calendar Users" a way to make that decision.

2.2.2. Authentication

authentication MUST be done with S/MIME [RFC5750] [RFC5751] 🔥 it's only possible on messages that have been signed. unauthenticated messages (aka unsigned messages) may not be trusted 🙈

2.2.3. Confidentiality

to keep things confidential with iMIP, implementations SHOULD use the encryption specified in S/MIME [RFC5750] [RFC5751] 🔐 and iMIP doesn't stop a "Calendar User Agent" (CUA) from forwarding iCalendar objects to other users or agents, so keep that in mind 💅

2.3. Email Addresses 💌

okay so the calendar address in the ORGANIZER and ATTENDEE properties of an iCalendar object sent over iMIP MUST be a proper mailto: [MAILTO] URI for the matching "Organizer" or "Attendee" of the VEVENT or VTODO. no vibes-based addresses, bestie 📧✨

here's the tea: [iTIP] doesn't stop "Attendees" from forwarding VEVENTs or VTODOs to other people, so the [RFC5322] "Sender" value may not equal the "Organizer". and it gets worse 🙈 you also can't reliably figure out the "Organizer" or "Attendee" from the [RFC5322] "Sender" or "Reply-To" header fields of an iMIP message. so the real address MUST be found by opening the "text/calendar" MIME body part and checking the ATTENDEE and ORGANIZER properties. trust the calendar, not the envelope 💅

2.4. Content-Type Header Field 🎀

a MIME body part with content that follows this document MUST have an [RFC2045] "Content-Type" value of text/calendar. the [RFC2045] "Content-Type" header field MUST also include the MIME parameter method. its value MUST match the value of the METHOD property in the iCalendar object (ignoring case). ✅

Note 1: a MIME message with several iCalendar objects that have different method values MUST be further wrapped in a multipart/mixed MIME entity [RFC2046]. this lets each iCalendar object live in its own text/calendar MIME entity. 🧁
Note 2: a MIME body part with a Content-Type of text/calendar that doesn't have the method parameter is not considered an iMIP body part, so it isn't subject to this document's requirements. 🫠

ngl, the charset thing is so iconic 🌈. according to [iCAL], the default character set for iCalendar objects is UTF-8 [UTF-8]. but the default for a "text/*" MIME entity under [RFC2046] is US-ASCII. so a charset MIME parameter MUST be present if the iCalendar object has characters that can't be shown in US-ASCII, and as [iCAL] says, it MUST have the value UTF-8. no mismatch drama allowed 💜

the optional component MIME parameter tells you which iCalendar component type is inside the iCalendar object. here's an example of this header field with a value for an event message:

Content-Type: text/calendar; method=REQUEST; charset=UTF-8;
      component=vevent

the text/calendar content type lets the scheduling message ride along with other content in a MIME message (that's multipart/mixed), or sit inside a MIME message next to a clear-text, human-readable version of the scheduling message (that's multipart/alternative [RFC2046]). 🦋

so MIME User Agents (UAs) that don't support text/calendar can still understand the scheduling message, scheduling messages SHOULD be sent with an alternative, human-readable version of the information. 🌸

also, multipart/alternative MUST NOT be used to represent two slightly different iCalendar objects, like two VEVENTs with different starting times. that's a hard no 🙅‍♀️

CUAs can use other MIME parameters of the Content-Type header field, plus a language set in the Content-Language header field [RFC3282], to pick which text/calendar part to process when a multipart/alternative MIME message has more than one text/calendar part. 🔍

any receiving UA that follows this specification MUST be able to process text/calendar body parts inside multipart/*. and a multipart/mixed MIME message can contain several text/calendar components, so the receiving UA MUST be able to process all of them. main character energy, every single one 👑

2.5. Content-Transfer-Encoding Header Field 🍓

unless the iMIP message travels over an 8-bit clean transport (like SMTP [8BITMIME]), a transfer encoding such as quoted-printable or base64 [RFC2045] MUST be used for iCalendar objects that contain any characters that can't be shown in US-ASCII. here's an example:

From: user1@example.com
To: user2@example.com
Subject: Phone Conference
Mime-Version: 1.0
Date: Wed, 07 May 2008 21:30:25 +0400
Message-ID: <4821E731.5040506@laptop1.example.com>
Content-Type: text/calendar; method=REQUEST; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

BEGIN:VCALENDAR
PRODID:-//Example/ExampleCalendarClient//EN
METHOD:REQUEST
VERSION:2.0
BEGIN:VEVENT
ORGANIZER:mailto:user1@example.com
ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:mailto:user1@example.com
ATTENDEE;RSVP=YES;CUTYPE=INDIVIDUAL:mailto:user2@example.com
DTSTAMP:20080507T170000Z
DTSTART:20080701T160000Z
DTEND:20080701T163000Z
SUMMARY:Phone call to discuss your last visit
DESCRIPTION:=D1=82=D1=8B =D0=BA=D0=B0=D0=BA - =D0=B4=D0=BE=D0=
 =B2=D0=BE=D0=BB=D0=B5=D0=BD =D0=BF=D0=BE=D0=B5=D0=B7=D0=B4=D0=BA=D0
 =BE=D0=B9?
UID:calsvr.example.com-8739701987387998
SEQUENCE:0
STATUS:TENTATIVE
END:VEVENT
END:VCALENDAR

the encoded DESCRIPTION is the Cyrillic text, so it's totally safe for any transport 🪄

2.6. Content-Disposition Header Field 🙃

implementations MAY include a Content-Disposition header field to set a file name for an iCalendar object. BUT the way a MIME part gets handled MUST depend on its [RFC2045] Content-Type, NOT on the extension in Content-Disposition. why? because email malware is known to trick User Agents into misreading message content by putting a file extension in Content-Disposition that doesn't match the Content-Type value. 🚨 nice try, sus email

3. Security Considerations 🔐

the security threats applications must deal with when implementing iTIP are laid out in [iTIP]. two spoofing threats show up in Section 6.1 of [iTIP]: spoofing the "Organizer" and spoofing an "Attendee". to handle these, a recipient must authenticate the originator of an iCalendar object. once that's done, it can figure out whether the originator is allowed to do the requested operation. 🕵️‍♀️ compliant applications MUST support signing and encrypting text/calendar body parts with a mechanism based on S/MIME [RFC5750] [RFC5751], so the originator of the iCalendar object can be authenticated (see Sections 2.2.2 and 2.2.3). here's how to process a signed iMIP message:

  1. using S/MIME, find out who signed the text/calendar body part with the iCalendar object. that's the "signer". (fun fact: the signer's email address MUST be in the rfc822Name field of the "subject alternative name" extension of the signer certificate, as specified in [RFC5280], Section 4.1.2.6.) the signer isn't always the person who sent the email, since emails can be forwarded. 📨
  2. match the signer to either an ATTENDEE property or the ORGANIZER property in the iCalendar object, based on the method and the calendar component in the iCalendar object, as defined in Section 1.4 of [iTIP]. if the signer can't be matched to an ATTENDEE/ORGANIZER property, actively warn the user controlling the "Calendar User Agent" that the iCalendar object is untrusted, and encourage them to ignore the message. advanced users still get the option to (a) look at the signer's certificate and the full certificate chain (if there is one) to help decide whether the signer should be trusted to send the message, and then (b) let the CUA accept and process the iCalendar object. 🧐
  3. check whether the ATTENDEE/ORGANIZER is allowed to do the operation as defined by [iTIP]. if the conditions aren't met, ignore the message. 🚫
  4. if all the conditions above are met, the message can be processed. ✨

S/MIME signing also protects against malicious changes to messages in transit. 🛡️

if the sender needs calendar confidentiality, signed iMIP messages SHOULD be encrypted with a mechanism based on S/MIME [RFC5750] [RFC5751]. if iMIP is used within a single ADministrative Management Domain (ADMD) [RFC5598], SMTP STARTTLS [SMTP-TLS] (together with STARTTLS in IMAP/POP [IMAP-POP-TLS]) MAY be used instead to provide calendar confidentiality. 🔒

once a CUA has received and successfully verified a signed and/or encrypted iMIP message (as detailed above), the CUA SHOULD remember whether that sender uses signing and/or encryption. if an unsigned iMIP message later comes from that same sender, the receiving CUA SHOULD warn the user about a possible man-in-the-middle attack and SHOULD ignore the message, unless the user explicitly overrides it. 🚨👀

implementations MAY give users a way to turn off signing and encrypting. 🎛️

it's possible to get iMIP messages sent by someone working on behalf of another "Calendar User". you can tell by checking the "sent-by" parameter in the relevant ORGANIZER or ATTENDEE property. but [iCAL] and [iTIP] have no way to verify that a "Calendar User" has authorized someone else to act for them. to deal with this, implementations MUST provide mechanisms that let "Calendar Users" make that decision before applying changes from someone working on behalf of a "Calendar User". one option is to reject iMIP messages sent by anyone other than the "ORGANIZER" or the "ATTENDEE"s. another option is for the receiver to keep a list of trusted <sent-by, organizer> proxies in its local security policy. and one more way is to prompt the user for confirmation. this part is extremely important, bestie 🥺

iMIP calendaring is often deployed within a single ADMD, with boundary filtering used to keep email calendaring flows inside the ADMD. this can help minimize malicious changes to calendaring messages in transit, and it makes authorization decisions less risky. 🏰

a security consideration for the Content-Disposition header field is covered in Section 2.6. 🎀

using S/MIME makes the security considerations discussed in [RFC5750] [RFC5751] relevant to this document. for more security considerations about certificate and Certificate Revocation List (CRL) verification, check out [RFC5280]. 📜

4. Examples 🧚

4.1. Single Component with an ATTACH Property 📎

this minimal message shows how an iCalendar object references an attachment. the attachment can be reached through its URL. 🍒

From: sman@netscape.example.com
To: stevesil@microsoft.example.com
Subject: Phone Conference
Mime-Version: 1.0
Content-Type: text/calendar; method=REQUEST; charset=US-ASCII
Content-Transfer-Encoding: 7bit

BEGIN:VCALENDAR
PRODID:-//Example/ExampleCalendarClient//EN
METHOD:REQUEST
VERSION:2.0
BEGIN:VEVENT
ORGANIZER:mailto:man@netscape.example.com
ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:mailto:man@netscape.example.com
ATTENDEE;RSVP=YES:mailto:stevesil@microsoft.example.com
DTSTAMP:19970611T190000Z
DTSTART:19970701T210000Z
DTEND:19970701T230000Z
SUMMARY:Phone Conference
DESCRIPTION:Please review the attached document.
UID:calsvr.example.com-873970198738777
ATTACH:ftp://ftp.bar.example.com/pub/docs/foo.doc
STATUS:CONFIRMED
END:VEVENT
END:VCALENDAR

4.2. Using multipart/alternative for Low-Fidelity Clients 💌

okay so this one is giving multipart/alternative realness 💅 It shows how a client can send ONE message that has a plain text version AND the full iCalendar object. That way, clients that don't support "text/calendar" can still show the plain text part 🫶

From: foo1@example.com
To: foo2@example.com
Subject: Phone Conference
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="01BD3665.3AF0D360"

--01BD3665.3AF0D360
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

This is an alternative representation of a "text/calendar"
MIME object.

When: 7/1/1997 10:00AM PDT - 7/1/97 10:30AM PDT
Where:
Organizer: foo1@example.com
Summary: Phone Conference

--01BD3665.3AF0D360
Content-Type: text/calendar; method=REQUEST; charset=US-ASCII
Content-Transfer-Encoding: 7bit

BEGIN:VCALENDAR
PRODID:-//Example/ExampleCalendarClient//EN
METHOD:REQUEST
VERSION:2.0
BEGIN:VEVENT
ORGANIZER:mailto:foo1@example.com
ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:mailto:foo1@example.com
ATTENDEE;RSVP=YES;CUTYPE=INDIVIDUAL:mailto:foo2@example.com
DTSTAMP:19970611T190000Z
DTSTART:19970701T170000Z
DTEND:19970701T173000Z
SUMMARY:Phone Conference
UID:calsvr.example.com-8739701987387771
SEQUENCE:0
STATUS:CONFIRMED
END:VEVENT
END:VCALENDAR

--01BD3665.3AF0D360

4.3. Single Component with an ATTACH Property and Inline Attachment 📎

this example is about a message with an iCalendar object that points to an attached doc 🦋 The pointer is a Content-ID (CID), so the iCalendar object and the doc get packed up together in a "multipart/related" encapsulation. Very neat, very tidy 🎀

From: foo1@example.com
To: foo2@example.com
Subject: Phone Conference
Mime-Version: 1.0
Content-Type: multipart/related; boundary="boundary-example-1"

--boundary-example-1

Content-Type: text/calendar; method=REQUEST; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename="event.ics"

BEGIN:VCALENDAR
PRODID:-//Example/ExampleCalendarClient//EN
METHOD:REQUEST
VERSION:2.0
BEGIN:VEVENT
ORGANIZER:mailto:foo1@example.com
ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:mailto:foo1@example.com
ATTENDEE;RSVP=YES;CUTYPE=INDIVIDUAL:mailto:foo2@example.com
DTSTAMP:19970611T190000Z
DTSTART:19970701T180000Z
DTEND:19970701T183000Z
SUMMARY:Phone Conference
UID:calsvr.example.com-8739701987387771
ATTACH:cid:123456789@example.com
SEQUENCE:0
STATUS:CONFIRMED
END:VEVENT
END:VCALENDAR

--boundary-example-1
Content-Type: application/msword; name="FieldReport.doc"
Content-Transfer-Encoding: base64
Content-Disposition: inline; filename="FieldReport.doc"
Content-ID: <123456789@example.com>

0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAABAAAARAAAAAAA
AAAAEAAAQAAAAAEAAAD+////AAAAAEUAAAD/////////////////////////////////
 ...

--boundary-example-1--

4.4. Multiple Similar Components 🍓

okay so you CAN put several iCalendar components of the same type into one iCalendar object, as long as the "METHOD" is the same for each one ✨ This example is a whole summer of company fun, bestie 🌞

From: foo1@example.com
To: foo2@example.com
Subject: Summer Company Holidays
Mime-Version: 1.0
Content-Type: text/calendar; method=PUBLISH; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename="event.ics"

BEGIN:VCALENDAR
PRODID:-//Example/ExampleCalendarClient//EN
METHOD:PUBLISH
VERSION:2.0
BEGIN:VEVENT
ORGANIZER:mailto:foo1@example.com
DTSTAMP:19970611T150000Z
DTSTART:19970701T150000Z
DTEND:19970701T230000Z
SUMMARY:Company Picnic
DESCRIPTION:Food and drink will be provided
UID:calsvr.example.com-873970198738777-1
SEQUENCE:0
STATUS:CONFIRMED
END:VEVENT
BEGIN:VEVENT
ORGANIZER:mailto:foo1@example.com
DTSTAMP:19970611T190000Z
DTSTART:19970715T150000Z
DTEND:19970715T230000Z
SUMMARY:Company Bowling Tournament
DESCRIPTION:We have 10 lanes reserved
UID:calsvr.example.com-873970198738777-2
SEQUENCE:0
STATUS:CONFIRMED
END:VEVENT
END:VCALENDAR

4.5. Multiple Mixed Components 🌈

different component types must be wrapped in separate iCalendar objects, so no mixing them in one 🙅‍♀️ This one has a meeting AND a to-do, each in its own little calendar box 📦

From: foo1@example.com
To: foo2@example.com
Subject: Phone Conference
Mime-Version: 1.0
Content-Type: multipart/mixed;
              boundary="--FEE3790DC7E35189CA67CE2C"

This is a multi-part message in MIME format.

----FEE3790DC7E35189CA67CE2C
Content-Type: text/calendar; method=REQUEST; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename="event1.ics"

BEGIN:VCALENDAR
PRODID:-//Example/ExampleCalendarClient//EN
METHOD:REQUEST
VERSION:2.0
BEGIN:VEVENT
ORGANIZER:mailto:foo1@example.com
ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:mailto:foo1@example.com
ATTENDEE;RSVP=YES;CUTYPE=INDIVIDUAL:mailto:foo2@example.com
DTSTAMP:19970611T190000Z
DTSTART:19970701T210000Z
DTEND:19970701T230000Z
SUMMARY:Phone Conference
DESCRIPTION:Discuss what happened at the last meeting
UID:calsvr.example.com-8739701987387772
SEQUENCE:0
STATUS:CONFIRMED
END:VEVENT
END:VCALENDAR
----FEE3790DC7E35189CA67CE2C
Content-Type: text/calendar; method=REQUEST; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename="todo1.ics"

BEGIN:VCALENDAR
PRODID:-//Example/ExampleCalendarClient//EN
METHOD:REQUEST
VERSION:2.0
BEGIN:VTODO
DUE:19970701T160000Z
ORGANIZER:mailto:foo1@example.com
ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:mailto:foo1@example.com
ATTENDEE;RSVP=YES:mailto:foo2@example.com
SUMMARY:Phone Conference
DESCRIPTION:Discuss a new location for the company picnic
UID:calsvr.example.com-td-8739701987387773
SEQUENCE:0
STATUS:NEEDS-ACTION
END:VEVENT
END:VCALENDAR

----FEE3790DC7E35189CA67CE2C

4.6. Detailed Components with an ATTACH Property 🧚

this one is the full group meeting look 👑 Three people, one meeting, and a doc attached. It uses "multipart/related" because the iCalendar object has an ATTACH property that uses a CID to point at the attachment. Layers on layers, it's iconic 💜

From: foo1@example.com
MIME-Version: 1.0
To: foo2@example.com,foo3@example.com
Subject: REQUEST - Phone Conference
Content-Type: multipart/related;
              boundary="--FEE3790DC7E35189CA67CE2C"

----FEE3790DC7E35189CA67CE2C
Content-Type: multipart/alternative;
              boundary="--00FEE3790DC7E35189CA67CE2C00"

----00FEE3790DC7E35189CA67CE2C00
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

When: 7/1/1997 10:00PM PDT - 7/1/97 10:30 PM PDT
Where:
Organizer: foo1@example.com
Summary: Let's discuss the attached document

----00FEE3790DC7E35189CA67CE2C00

Content-Type: text/calendar; method=REQUEST; charset=US-ASCII;
                 Component=vevent
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename="event.ics"

BEGIN:VCALENDAR
PRODID:-//Example/ExampleCalendarClient//EN
METHOD:REQUEST
VERSION:2.0
BEGIN:VEVENT
ORGANIZER:foo1@example.com
ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:foo1@example.com
ATTENDEE;RSVP=YES;CUTYPE=INDIVIDUAL:mailto:foo2@example.com
ATTENDEE;RSVP=YES;CUTYPE=INDIVIDUAL:mailto:foo3@example.com
DTSTAMP:19970611T190000Z
DTSTART:19970621T170000Z
DTEND:199706211T173000Z
SUMMARY:Let's discuss the attached document
UID:calsvr.example.com-873970198738777-8aa
ATTACH:cid:calsvr.example.com-12345aaa
SEQUENCE:0
STATUS:CONFIRMED
END:VEVENT
END:VCALENDAR

----00FEE3790DC7E35189CA67CE2C00
----FEE3790DC7E35189CA67CE2C
Content-Type: application/msword; name="FieldReport.doc"
Content-Transfer-Encoding: base64
Content-Disposition: inline; filename="FieldReport.doc"
Content-ID: <calsvr.example.com-12345aaa>

R0lGODdhTAQZAJEAAFVVVd3d3e4AAP///ywAAAAATAQZAAAC/5yPOSLhD6OctNqLs94Xq
AG4kiW5omm6sq27gvH8kzX9o1y+s73/g8MCofEovGITCoxKMbyCR16cNSq9YrNarfcrvd
riIH5LL5jE6rxc3G+v2cguf0uv2Oz+v38L7/DxgoOKjURnjIIbe3yNjo+AgZWYVIWWl5i
ZnJY6J
 ...

----FEE3790DC7E35189CA67CE2C

this section is a list of recommended practices for when you use a messaging transport to send iCalendar objects around 💖

5.1. Use of Content and Message IDs 🔗

the [iCAL] spec uses URIs for data types a LOT, like in properties such as "DESCRIPTION", "ATTACH", "CONTACT", and more 🤭 Two kinds of URIs are the Message ID (MID) and the Content-ID (CID), and they're defined in [RFC2392]. [RFC2392] lets you reference messages or MIME body parts that live in other MIME entities or stores, but it is strongly RECOMMENDED that iMIP implementations include all referenced messages and body parts in a single MIME entity 🫶 Simply put, if an iCalendar object has CID or MID references to other messages or body parts, implementations should make sure those messages and/or body parts are sent along with the iCalendar object. If they aren't, there's no guarantee that the receiving CUA will have the access or the authorization to view them 😭

6. IANA Considerations 🦋

the "text/calendar" MIME media type was registered in [iCAL] ✨

7. References 📚

7.1. Normative References 💜

  • [iCAL] Desruisseaux, B., Ed., "Internet Calendaring and Scheduling Core Object Specification (iCalendar)", RFC 5545, September 2009.
  • [iTIP] Daboo, C., Ed., "iCalendar Transport-Independent Interoperability Protocol (iTIP)", RFC 5546, December 2009.
  • [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, October 2008.
  • [MAILTO] Duerst, M., Masinter, L., and J. Zawinski, "The 'mailto' URI Scheme", RFC 6068, October 2010.
  • [RFC1847] Galvin, J., Murphy, S., Crocker, S., and N. Freed, "Security Multiparts for MIME: Multipart/Signed and Multipart/Encrypted", RFC 1847, October 1995.
  • [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, November 1996.
  • [RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", RFC 2046, November 1996.
  • [RFC2392] Levinson, E., "Content-ID and Message-ID Uniform Resource Locators", RFC 2392, August 1998.
  • [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
  • [UTF-8] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, November 2003.
  • [SMTP-TLS] Hoffman, P., "SMTP Service Extension for Secure SMTP over Transport Layer Security", RFC 3207, February 2002.
  • [IMAP-POP-TLS] Newman, C., "Using TLS with IMAP, POP3 and ACAP", RFC 2595, June 1999.
  • [RFC5750] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.2 Certificate Handling", RFC 5750, January 2010.
  • [RFC5751] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.2 Message Specification", RFC 5751, January 2010.
  • [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, May 2008.

7.2. Informative References 📚

Okay so now the "just for context" pile 🙈 These are the ones that help you understand the vibe but aren't strictly required reading:

  • [8BITMIME]: Klensin, J., Freed, N., Rose, M., Stefferud, E., and D. Crocker, "SMTP Service Extension for 8bit-MIMEtransport", RFC 1652, July 1994. 💌
  • [RFC5598]: Crocker, D., "Internet Mail Architecture", RFC 5598, July 2009. 🏛️
  • [RFC3282]: Alvestrand, H., "Content Language Headers", RFC 3282, May 2002. 🌍

Appendix A. Changes since RFC 2447 🦋

This is the glow-up montage. Here's everything that got updated since the last version:

  • Updated references. They were split into Normative and Informative. 📑
  • Updated examples to use example.com/example.net domains. 🌸
  • Corrected usage of RFC 2119 language. ✏️
  • Clarified that charset=UTF-8 is required, unless the calendar can be entirely represented in US-ASCII. 🔤
  • Clarified that 7-bit content transfer encodings should be used unless the calendar object is known to be transferred over 8-bit clean transport. 📦
  • Clarified that file extension specified in the Content-Disposition header field is not to be used to override the "Content-Type" MIME type. 🙅‍♀️
  • Disallowed use of "multipart/alternative" for slightly different representations of the same calendar. 🚫
  • Clarified handling of the "method" MIME parameter of the "Content-Type" header field. 🧩
  • Clarified that in an iMIP message an ORGANIZER/ATTENDEE property contains a mailto: URI. 💜
  • Fixed examples with ATTENDEE property to use "CUTYPE=" instead of "TYPE=". 🔧
  • Clarified that message integrity/confidentiality should be achieved using S/MIME. 🔐
  • Provided additional examples. ✨
  • Improved the Security Considerations section. 🛡️
  • Made multiple editorial changes to different sections of the document. 💅

Appendix B. Acknowledgements 🫶

The editor wants to give a huge shoutout to Frank Dawson, Steve Mansour, and Steve Silverberg, the original authors of RFC 2447 👑. Thank you for laying the foundation!

The editor also thanks these people, who helped with drafting, reviewing, and discussing this memo 🌈:

Reinhold Kainhofer, Cyrus Daboo, Bernard Desruisseaux, Eliot Lear, and Peter Saint-Andre. 💖

Author's Address 🧚

Alexey Melnikov (editor)
Isode Ltd
5 Castle Business Village
36 Station Road
Hampton, Middlesex  TW12 2BX
UK

EMail: Alexey.Melnikov@isode.com
📦 where this page comes from