7Internet Engineering Task Force (IETF) A. Melnikov, Ed.
8Request for Comments: 6047 Isode Ltd
9Obsoletes: 2447 December 2010
10Category: Standards Track
14 iCalendar Message-Based Interoperability Protocol (iMIP)
18 This document, "iCalendar Message-Based Interoperability Protocol
19 (iMIP)", specifies a binding from the iCalendar Transport-independent
20 Interoperability Protocol (iTIP) to Internet email-based transports.
21 Calendaring entries defined by the iCalendar Object Model (iCalendar)
22 are wrapped using constructs from RFC 5322 and MIME (RFC 2045, RFC
23 2046, RFC 2047, and RFC 2049), and then transported over SMTP.
27 This is an Internet Standards Track document.
29 This document is a product of the Internet Engineering Task Force
30 (IETF). It represents the consensus of the IETF community. It has
31 received public review and has been approved for publication by the
32 Internet Engineering Steering Group (IESG). Further information on
33 Internet Standards is available in Section 2 of RFC 5741.
35 Information about the current status of this document, any errata,
36 and how to provide feedback on it may be obtained at
37 http://www.rfc-editor.org/info/rfc6047.
41 Copyright (c) 2010 IETF Trust and the persons identified as the
42 document authors. All rights reserved.
44 This document is subject to BCP 78 and the IETF Trust's Legal
45 Provisions Relating to IETF Documents
46 (http://trustee.ietf.org/license-info) in effect on the date of
47 publication of this document. Please review these documents
48 carefully, as they describe your rights and restrictions with respect
49 to this document. Code Components extracted from this document must
50 include Simplified BSD License text as described in Section 4.e of
51 the Trust Legal Provisions and are provided without warranty as
52 described in the Simplified BSD License.
58Melnikov Standards Track [Page 1]
60RFC 6047 iMIP December 2010
63 This document may contain material from IETF Documents or IETF
64 Contributions published or made publicly available before November
65 10, 2008. The person(s) controlling the copyright in some of this
66 material may not have granted the IETF Trust the right to allow
67 modifications of such material outside the IETF Standards Process.
68 Without obtaining an adequate license from the person(s) controlling
69 the copyright in such materials, this document may not be modified
70 outside the IETF Standards Process, and derivative works of it may
71 not be created outside the IETF Standards Process, except to format
72 it for publication as an RFC or to translate it into languages other
77 1. Introduction ....................................................3
78 1.1. Related Memos ..............................................3
79 1.2. Formatting Conventions .....................................3
80 1.3. Terminology ................................................4
81 2. MIME Message Format Binding .....................................4
82 2.1. MIME Media Type ............................................4
83 2.2. Security ...................................................5
84 2.2.1. Authorization .......................................5
85 2.2.2. Authentication ......................................5
86 2.2.3. Confidentiality .....................................5
87 2.3. Email Addresses ............................................6
88 2.4. Content-Type Header Field ..................................6
89 2.5. Content-Transfer-Encoding Header Field .....................7
90 2.6. Content-Disposition Header Field ...........................8
91 3. Security Considerations .........................................8
92 4. Examples .......................................................11
93 4.1. Single Component with an ATTACH Property ..................11
94 4.2. Using multipart/alternative for Low-Fidelity Clients ......11
95 4.3. Single Component with an ATTACH Property and
96 Inline Attachment .........................................12
97 4.4. Multiple Similar Components ...............................14
98 4.5. Multiple Mixed Components .................................15
99 4.6. Detailed Components with an ATTACH Property ...............16
100 5. Recommended Practices ..........................................18
101 5.1. Use of Content and Message IDs ............................18
102 6. IANA Considerations ............................................18
103 7. References .....................................................19
104 7.1. Normative References ......................................19
105 7.2. Informative References ....................................20
106 Appendix A. Changes since RFC 2447 ................................21
107 Appendix B. Acknowledgements ......................................22
114Melnikov Standards Track [Page 2]
116RFC 6047 iMIP December 2010
121 This document provides the transport-specific information ("binding")
122 necessary to convey iCalendar Transport-independent Interoperability
123 Protocol (iTIP) [iTIP] over Internet email (using MIME) as defined in
124 [RFC5322] and [RFC2045]. Therefore, this document defines the
125 iCalendar Message-Based Interoperability Protocol (iMIP).
129 Implementers will need to be familiar with several other memos that,
130 along with this memo, form a framework for Internet calendaring and
131 scheduling standards.
133 This document specifies an Internet email binding for iTIP.
135 [iCAL] specifies a core specification of objects, data types,
136 properties, and property parameters.
138 [iTIP] specifies an interoperability protocol for scheduling between
139 different implementations.
141 This memo does not attempt to repeat the specification of concepts or
142 definitions from these other memos. Where possible, references are
143 made to the memo that provides for the specification of these
144 concepts or definitions.
1461.2. Formatting Conventions
148 The mechanisms defined in this memo are defined in prose. In order
149 to refer to elements of the calendaring and scheduling model, core
150 object, or interoperability protocol defined in [iCAL] and [iTIP],
151 some formatting conventions have been used.
153 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
154 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
155 document are to be interpreted as described in RFC 2119 [RFC2119].
157 Calendaring and scheduling roles are referred to in quoted strings of
158 text with the first character of each word in uppercase. For
159 example, "Organizer" refers to a role of a "Calendar User" within the
160 scheduling protocol defined by [iTIP].
162 Calendar components defined by [iCAL] are referred to with
163 capitalized, quoted strings of text. All calendar components start
164 with the letter "V". For example, "VEVENT" refers to the event
165 calendar component, "VTODO" refers to the to-do calendar component,
166 and "VJOURNAL" refers to the daily journal calendar component.
170Melnikov Standards Track [Page 3]
172RFC 6047 iMIP December 2010
175 Scheduling methods defined by [iTIP] are referred to with
176 capitalized, quoted strings of text. For example, "REQUEST" refers
177 to the method for requesting a scheduling calendar component be
178 created or modified; "REPLY" refers to the method a recipient of a
179 request uses to update their status with the "Organizer" of the
182 Properties defined by [iCAL] are referred to with capitalized, quoted
183 strings of text, followed by the word "property". For example,
184 "ATTENDEE" property refers to the iCalendar property used to convey
185 the calendar address of a "Calendar User".
187 Property parameters defined by [iCAL] are referred to with lowercase,
188 quoted strings of text, followed by the word "parameter". For
189 example, "value" parameter refers to the iCalendar property parameter
190 used to override the default data type for a property value.
194 The email terms used in this memo are defined in [RFC5322] and
195 [RFC2045]. The calendaring and scheduling terms used in this memo
196 are defined in [iCAL] and [iTIP].
1982. MIME Message Format Binding
200 This section defines the message binding to the MIME electronic mail
203 The sections below refer to the "originator" and the "recipient" of
204 an iMIP message. In the case of a "request" method, the originator
205 is the "Organizer" and the recipient is an "Attendee" of the event.
206 In the case of a "response" method, the originator is an "Attendee"
207 and the recipient is the "Organizer" of the event.
209 The [RFC5322] "Reply-To" header field typically contains the email
210 address of the originator of the scheduling message. However, this
211 cannot be guaranteed because the sender of the iMIP message might not
212 be the originator of the scheduling message and the sender's "Mail
213 User Agent" (MUA) might not enforce iMIP semantics by translating the
214 originator's address into the "Reply-To" email header field.
218 A MIME entity containing content information formatted according to
219 this document will be referenced as a "text/calendar" content type
220 [iCAL]. It is assumed that this content type will be transported
221 through a MIME electronic mail transport.
226Melnikov Standards Track [Page 4]
228RFC 6047 iMIP December 2010
233 This section addresses several aspects of security including
234 authentication, authorization, and confidentiality. Authentication
235 and confidentiality can be achieved using Secure/MIME (S/MIME)
236 [RFC5750] [RFC5751], which uses the Security Multiparts framework for
241 In iTIP messages [iTIP], only the "Organizer" is authorized to modify
242 or cancel calendar entries she organizes. That is,
243 spoof@xyz.example.net is not allowed to modify or cancel a meeting
244 that was organized by a@example.com. Furthermore, only the
245 respondent has the authorization to indicate their status to the
246 "Organizer". That is, the "Organizer" MUST ignore an iTIP message
247 from spoof@xyz.example.net that declines a meeting invitation for
250 Implementations of iMIP SHOULD verify the authenticity of the creator
251 of an iCalendar object before taking any action. Methods for doing
252 this are presented later in this document.
254 [RFC1847] message flow in iTIP supports someone working on behalf of
255 a "Calendar User" through use of the "sent-by" parameter that is
256 associated with the "ATTENDEE" and "ORGANIZER" properties. However,
257 there is no mechanism to verify whether or not a "Calendar User" has
258 authorized someone to work on their behalf. It is left to
259 implementations to provide mechanisms for the "Calendar Users" to
264 Authentication MUST be performed using S/MIME [RFC5750] [RFC5751].
265 Authentication is possible only on messages that have been signed.
266 Unauthenticated messages (i.e., unsigned messages) may not be
2692.2.3. Confidentiality
271 To ensure confidentiality using iMIP, implementations SHOULD utilize
272 encryption specified in S/MIME [RFC5750] [RFC5751]. iMIP does not
273 restrict a "Calendar User Agent" (CUA) from forwarding iCalendar
274 objects to other users or agents.
282Melnikov Standards Track [Page 5]
284RFC 6047 iMIP December 2010
289 The calendar address specified within the "ORGANIZER" and "ATTENDEE"
290 properties in an iCalendar object sent using iMIP MUST be a proper
291 "mailto:" [MAILTO] URI specification for the corresponding
292 "Organizer" or "Attendee" of the "VEVENT" or "VTODO".
294 Because [iTIP] does not preclude "Attendees" from forwarding
295 "VEVENT"s or "VTODO"s to others, the [RFC5322] "Sender" value may not
296 equal that of the "Organizer". Additionally, the "Organizer" or
297 "Attendee" cannot be reliably inferred by the [RFC5322] "Sender" or
298 "Reply-To" header field values of an iMIP message. The relevant
299 address MUST be ascertained by opening the "text/calendar" MIME body
300 part and examining the "ATTENDEE" and "ORGANIZER" properties.
3022.4. Content-Type Header Field
304 A MIME body part containing content information that conforms to this
305 document MUST have an [RFC2045] "Content-Type" value of
306 "text/calendar". The [RFC2045] "Content-Type" header field MUST also
307 include the MIME parameter "method". The value MUST be the same
308 (ignoring case) as the value of the "METHOD" property within the
311 Note 1: A MIME message containing multiple iCalendar objects with
312 different "method" values MUST be further encapsulated with a
313 "multipart/mixed" MIME entity [RFC2046]. This will allow each of
314 the iCalendar objects to be encapsulated within their own
315 "text/calendar" MIME entity.
317 Note 2: A MIME body part with a "Content-Type" value of
318 "text/calendar" that lacks the "method" parameter is not
319 considered to be an iMIP body part and thus is not subject to the
320 requirements specified in this document.
322 Note that according to [iCAL] the default character set for iCalendar
323 objects is UTF-8 [UTF-8]. However, the default character set for a
324 "text/*" MIME entity according to [RFC2046] is US-ASCII. Thus, a
325 "charset" MIME parameter MUST be present if the iCalendar object
326 contains characters that can't be represented in the US-ASCII
327 character set and, as specified in [iCAL], it MUST have the value
330 The optional "component" MIME parameter defines the iCalendar
331 component type contained within the iCalendar object.
338Melnikov Standards Track [Page 6]
340RFC 6047 iMIP December 2010
343 The following is an example of this header field with a value that
344 indicates an event message.
346 Content-Type: text/calendar; method=REQUEST; charset=UTF-8;
349 The "text/calendar" content type allows for the scheduling message
350 type to be included in a MIME message with other content information
351 (i.e., "multipart/mixed") or included in a MIME message with a clear-
352 text, human-readable form of the scheduling message (i.e.,
353 "multipart/alternative" [RFC2046]).
355 In order to permit the information in the scheduling message to be
356 understood by MIME User Agents (UAs) that do not support the
357 "text/calendar" content type, scheduling messages SHOULD be sent with
358 an alternative, human-readable form of the information.
360 Note that "multipart/alternative" MUST NOT be used to represent two
361 slightly different iCalendar objects, for example, two "VEVENT"s with
362 alternative starting times.
364 CUAs can use other MIME parameters of the "Content-Type" header
365 field, as well as a language specified in the Content-Language header
366 field [RFC3282], to pick a "text/calendar" part for processing if a
367 "multipart/alternative" MIME message contains more than one
368 "text/calendar" part.
370 Any receiving UA compliant with this specification MUST be able to
371 process "text/calendar" body parts enclosed within "multipart/*".
372 Note that a "multipart/mixed" MIME message can include multiple
373 "text/calendar" components. The receiving UA MUST be able to process
3762.5. Content-Transfer-Encoding Header Field
378 Unless an iMIP message is transported over 8-bit clean transport
379 (such as SMTP [8BITMIME]), a transfer encoding such as quoted-
380 printable or base64 [RFC2045] MUST be used for iCalendar objects
381 containing any characters that can't be represented in the US-ASCII
382 character set. For example:
394Melnikov Standards Track [Page 7]
396RFC 6047 iMIP December 2010
399 From: user1@example.com
400 To: user2@example.com
401 Subject: Phone Conference
403 Date: Wed, 07 May 2008 21:30:25 +0400
404 Message-ID: <4821E731.5040506@laptop1.example.com>
405 Content-Type: text/calendar; method=REQUEST; charset=UTF-8
406 Content-Transfer-Encoding: quoted-printable
409 PRODID:-//Example/ExampleCalendarClient//EN
413 ORGANIZER:mailto:user1@example.com
414 ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:mailto:user1@example.com
415 ATTENDEE;RSVP=YES;CUTYPE=INDIVIDUAL:mailto:user2@example.com
416 DTSTAMP:20080507T170000Z
417 DTSTART:20080701T160000Z
418 DTEND:20080701T163000Z
419 SUMMARY:Phone call to discuss your last visit
420 DESCRIPTION:=D1=82=D1=8B =D0=BA=D0=B0=D0=BA - =D0=B4=D0=BE=D0=
421 =B2=D0=BE=D0=BB=D0=B5=D0=BD =D0=BF=D0=BE=D0=B5=D0=B7=D0=B4=D0=BA=D0
423 UID:calsvr.example.com-8739701987387998
4292.6. Content-Disposition Header Field
431 Implementations MAY include a "Content-Disposition" header field to
432 define a file name for an iCalendar object. However, the handling of
433 a MIME part MUST be based on its [RFC2045] "Content-Type" and not on
434 the extension specified in the "Content-Disposition", as different
435 email malware is known to trick User Agents into misinterpreting
436 content of messages by specifying a file extension in the Content-
437 Disposition header field that doesn't correspond to the value of the
438 "Content-Type" header field.
4403. Security Considerations
442 The security threats that applications must address when implementing
443 iTIP are detailed in [iTIP]. In particular, two spoofing threats are
444 identified in Section 6.1 of [iTIP]: spoofing the "Organizer", and
445 spoofing an "Attendee". To address these threats, the originator of
446 an iCalendar object must be authenticated by a recipient. Once
450Melnikov Standards Track [Page 8]
452RFC 6047 iMIP December 2010
455 authenticated, a determination can be made as to whether or not the
456 originator is authorized to perform the requested operation.
457 Compliant applications MUST support signing and encrypting
458 "text/calendar" body parts using a mechanism based on S/MIME
459 [RFC5750] [RFC5751] in order to facilitate the authentication of the
460 originator of the iCalendar object (see Sections 2.2.2 and 2.2.3).
461 The steps for processing a signed iMIP message are described below:
463 1. Using S/MIME, determine who signed the "text/calendar" body part
464 containing the iCalendar object. This is the "signer". (Note
465 that the email address of the signer MUST be specified in the
466 rfc822Name field of the "subject alternative name" extension of
467 the signer certificate, as specified in [RFC5280],
468 Section 4.1.2.6.) Note that the signer is not necessarily the
469 person sending an e-mail message, since an e-mail message can be
472 2. Correlate the signer to either an "ATTENDEE" property or to the
473 "ORGANIZER" property in the iCalendar object, based on the method
474 and the calendar component specified in the iCalendar object, as
475 defined in Section 1.4 of [iTIP]. If the signer cannot be
476 correlated to an "ATTENDEE"/"ORGANIZER" property, then actively
477 warn the user controlling the "Calendar User Agent" that the
478 iCalendar object is untrusted, and encourage the user to ignore
479 the message, but give advanced users the option to (a) view the
480 certificate of the signer and the entire certificate chain (if
481 any) in order to help decide if the signer should be trusted to
482 send the message, and then (b) allow the CUA to accept and process
483 the iCalendar object.
485 3. Determine whether or not the "ATTENDEE"/"ORGANIZER" is authorized
486 to perform the operation as defined by [iTIP]. If the conditions
487 are not met, ignore the message.
489 4. If all the above conditions are met, the message can be processed.
491 S/MIME signing also protects against malicious changes to messages in
494 If calendar confidentiality is required by the sender, signed iMIP
495 messages SHOULD be encrypted by a mechanism based on S/MIME [RFC5750]
496 [RFC5751]. If iMIP is used within a single ADministrative Management
497 Domain (ADMD) [RFC5598], SMTP STARTTLS [SMTP-TLS] (together with
498 STARTTLS in IMAP/POP [IMAP-POP-TLS]) MAY alternatively be used to
499 provide calendar confidentiality.
506Melnikov Standards Track [Page 9]
508RFC 6047 iMIP December 2010
511 Once a signed and/or encrypted iMIP message is received and
512 successfully verified (as detailed above) by a CUA, the CUA SHOULD
513 remember whether the sender of the message is using signing and/or
514 encrypting. If an unsigned iMIP message is received from the same
515 sender later on, the receiving CUA SHOULD warn the receiving user
516 about a possible man-in-the-middle attack and SHOULD ignore the
517 message, unless explicitly overridden by the user.
519 Implementations MAY provide means for users to disable signing and
522 It is possible to receive iMIP messages sent by someone working on
523 behalf of another "Calendar User". This is determined by examining
524 the "sent-by" parameter in the relevant "ORGANIZER" or "ATTENDEE"
525 property. [iCAL] and [iTIP] provide no mechanism to verify that a
526 "Calendar User" has authorized someone else to work on their behalf.
527 To address this security issue, implementations MUST provide
528 mechanisms for the "Calendar Users" to make that decision before
529 applying changes from someone working on behalf of a "Calendar User".
530 One way to achieve this is to reject iMIP messages sent by users
531 other than the "ORGANIZER" or the "ATTENDEE"s. Alternatively, the
532 receiver could have a list of trusted <sent-by, organizer> proxies in
533 its local security policy. And yet another way is to prompt the user
536 iMIP-based calendaring is frequently deployed within a single ADMD,
537 with boundary filtering employed to restrict email calendaring flows
538 to be inside the ADMD. This can help in minimizing malicious changes
539 to calendaring messages in transit, as well as in making
540 authorization decisions less risky.
542 A security consideration associated with the use of the Content-
543 Disposition header field is described in Section 2.6.
545 Use of S/MIME makes the security considerations discussed in
546 [RFC5750] [RFC5751] relevant to this document. For additional
547 security considerations regarding certificate and Certificate
548 Revocation List (CRL) verification, please see [RFC5280].
562Melnikov Standards Track [Page 10]
564RFC 6047 iMIP December 2010
5694.1. Single Component with an ATTACH Property
571 This minimal message shows how an iCalendar object references an
572 attachment. The attachment is accessible via its URL.
574 From: sman@netscape.example.com
575 To: stevesil@microsoft.example.com
576 Subject: Phone Conference
578 Content-Type: text/calendar; method=REQUEST; charset=US-ASCII
579 Content-Transfer-Encoding: 7bit
582 PRODID:-//Example/ExampleCalendarClient//EN
586 ORGANIZER:mailto:man@netscape.example.com
587 ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:mailto:man@netscape.example.com
588 ATTENDEE;RSVP=YES:mailto:stevesil@microsoft.example.com
589 DTSTAMP:19970611T190000Z
590 DTSTART:19970701T210000Z
591 DTEND:19970701T230000Z
592 SUMMARY:Phone Conference
593 DESCRIPTION:Please review the attached document.
594 UID:calsvr.example.com-873970198738777
595 ATTACH:ftp://ftp.bar.example.com/pub/docs/foo.doc
6004.2. Using multipart/alternative for Low-Fidelity Clients
602 This example shows how a client can emit a multipart message that
603 includes both a plain text version and the full iCalendar object.
604 Clients that do not support "text/calendar" will still be capable of
605 rendering the plain text representation.
618Melnikov Standards Track [Page 11]
620RFC 6047 iMIP December 2010
623 From: foo1@example.com
625 Subject: Phone Conference
627 Content-Type: multipart/alternative; boundary="01BD3665.3AF0D360"
630 Content-Type: text/plain; charset=us-ascii
631 Content-Transfer-Encoding: 7bit
633 This is an alternative representation of a "text/calendar"
636 When: 7/1/1997 10:00AM PDT - 7/1/97 10:30AM PDT
638 Organizer: foo1@example.com
639 Summary: Phone Conference
642 Content-Type: text/calendar; method=REQUEST; charset=US-ASCII
643 Content-Transfer-Encoding: 7bit
646 PRODID:-//Example/ExampleCalendarClient//EN
650 ORGANIZER:mailto:foo1@example.com
651 ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:mailto:foo1@example.com
652 ATTENDEE;RSVP=YES;CUTYPE=INDIVIDUAL:mailto:foo2@example.com
653 DTSTAMP:19970611T190000Z
654 DTSTART:19970701T170000Z
655 DTEND:19970701T173000Z
656 SUMMARY:Phone Conference
657 UID:calsvr.example.com-8739701987387771
6654.3. Single Component with an ATTACH Property and Inline Attachment
667 This example shows how a message containing an iCalendar object
668 references an attached document. The reference is made using a
669 Content-ID (CID). Thus, the iCalendar object and the document are
670 packaged in a "multipart/related" encapsulation.
674Melnikov Standards Track [Page 12]
676RFC 6047 iMIP December 2010
679 From: foo1@example.com
681 Subject: Phone Conference
683 Content-Type: multipart/related; boundary="boundary-example-1"
687 Content-Type: text/calendar; method=REQUEST; charset=US-ASCII
688 Content-Transfer-Encoding: 7bit
689 Content-Disposition: attachment; filename="event.ics"
692 PRODID:-//Example/ExampleCalendarClient//EN
696 ORGANIZER:mailto:foo1@example.com
697 ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:mailto:foo1@example.com
698 ATTENDEE;RSVP=YES;CUTYPE=INDIVIDUAL:mailto:foo2@example.com
699 DTSTAMP:19970611T190000Z
700 DTSTART:19970701T180000Z
701 DTEND:19970701T183000Z
702 SUMMARY:Phone Conference
703 UID:calsvr.example.com-8739701987387771
704 ATTACH:cid:123456789@example.com
711 Content-Type: application/msword; name="FieldReport.doc"
712 Content-Transfer-Encoding: base64
713 Content-Disposition: inline; filename="FieldReport.doc"
714 Content-ID: <123456789@example.com>
716 0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAABAAAARAAAAAAA
717 AAAAEAAAQAAAAAEAAAD+////AAAAAEUAAAD/////////////////////////////////
720 --boundary-example-1--
730Melnikov Standards Track [Page 13]
732RFC 6047 iMIP December 2010
7354.4. Multiple Similar Components
737 Multiple iCalendar components of the same type can be included in the
738 iCalendar object when the "METHOD" is the same for each component.
740 From: foo1@example.com
742 Subject: Summer Company Holidays
744 Content-Type: text/calendar; method=PUBLISH; charset=US-ASCII
745 Content-Transfer-Encoding: 7bit
746 Content-Disposition: attachment; filename="event.ics"
749 PRODID:-//Example/ExampleCalendarClient//EN
753 ORGANIZER:mailto:foo1@example.com
754 DTSTAMP:19970611T150000Z
755 DTSTART:19970701T150000Z
756 DTEND:19970701T230000Z
757 SUMMARY:Company Picnic
758 DESCRIPTION:Food and drink will be provided
759 UID:calsvr.example.com-873970198738777-1
764 ORGANIZER:mailto:foo1@example.com
765 DTSTAMP:19970611T190000Z
766 DTSTART:19970715T150000Z
767 DTEND:19970715T230000Z
768 SUMMARY:Company Bowling Tournament
769 DESCRIPTION:We have 10 lanes reserved
770 UID:calsvr.example.com-873970198738777-2
786Melnikov Standards Track [Page 14]
788RFC 6047 iMIP December 2010
7914.5. Multiple Mixed Components
793 Different component types must be encapsulated in separate iCalendar
796 From: foo1@example.com
798 Subject: Phone Conference
800 Content-Type: multipart/mixed;
801 boundary="--FEE3790DC7E35189CA67CE2C"
803 This is a multi-part message in MIME format.
805 ----FEE3790DC7E35189CA67CE2C
806 Content-Type: text/calendar; method=REQUEST; charset=US-ASCII
807 Content-Transfer-Encoding: 7bit
808 Content-Disposition: attachment; filename="event1.ics"
811 PRODID:-//Example/ExampleCalendarClient//EN
815 ORGANIZER:mailto:foo1@example.com
816 ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:mailto:foo1@example.com
817 ATTENDEE;RSVP=YES;CUTYPE=INDIVIDUAL:mailto:foo2@example.com
818 DTSTAMP:19970611T190000Z
819 DTSTART:19970701T210000Z
820 DTEND:19970701T230000Z
821 SUMMARY:Phone Conference
822 DESCRIPTION:Discuss what happened at the last meeting
823 UID:calsvr.example.com-8739701987387772
842Melnikov Standards Track [Page 15]
844RFC 6047 iMIP December 2010
847 ----FEE3790DC7E35189CA67CE2C
848 Content-Type: text/calendar; method=REQUEST; charset=US-ASCII
849 Content-Transfer-Encoding: 7bit
850 Content-Disposition: attachment; filename="todo1.ics"
853 PRODID:-//Example/ExampleCalendarClient//EN
858 ORGANIZER:mailto:foo1@example.com
859 ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:mailto:foo1@example.com
860 ATTENDEE;RSVP=YES:mailto:foo2@example.com
861 SUMMARY:Phone Conference
862 DESCRIPTION:Discuss a new location for the company picnic
863 UID:calsvr.example.com-td-8739701987387773
869 ----FEE3790DC7E35189CA67CE2C
8714.6. Detailed Components with an ATTACH Property
873 This example shows the format of a message containing a group meeting
874 between three individuals. The "multipart/related" encapsulation is
875 used because the iCalendar object contains an ATTACH property that
876 uses a CID to reference the attachment.
878 From: foo1@example.com
880 To: foo2@example.com,foo3@example.com
881 Subject: REQUEST - Phone Conference
882 Content-Type: multipart/related;
883 boundary="--FEE3790DC7E35189CA67CE2C"
885 ----FEE3790DC7E35189CA67CE2C
886 Content-Type: multipart/alternative;
887 boundary="--00FEE3790DC7E35189CA67CE2C00"
898Melnikov Standards Track [Page 16]
900RFC 6047 iMIP December 2010
903 ----00FEE3790DC7E35189CA67CE2C00
904 Content-Type: text/plain; charset=us-ascii
905 Content-Transfer-Encoding: 7bit
907 When: 7/1/1997 10:00PM PDT - 7/1/97 10:30 PM PDT
909 Organizer: foo1@example.com
910 Summary: Let's discuss the attached document
912 ----00FEE3790DC7E35189CA67CE2C00
914 Content-Type: text/calendar; method=REQUEST; charset=US-ASCII;
916 Content-Transfer-Encoding: 7bit
917 Content-Disposition: attachment; filename="event.ics"
920 PRODID:-//Example/ExampleCalendarClient//EN
924 ORGANIZER:foo1@example.com
925 ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:foo1@example.com
926 ATTENDEE;RSVP=YES;CUTYPE=INDIVIDUAL:mailto:foo2@example.com
927 ATTENDEE;RSVP=YES;CUTYPE=INDIVIDUAL:mailto:foo3@example.com
928 DTSTAMP:19970611T190000Z
929 DTSTART:19970621T170000Z
930 DTEND:199706211T173000Z
931 SUMMARY:Let's discuss the attached document
932 UID:calsvr.example.com-873970198738777-8aa
933 ATTACH:cid:calsvr.example.com-12345aaa
939 ----00FEE3790DC7E35189CA67CE2C00
954Melnikov Standards Track [Page 17]
956RFC 6047 iMIP December 2010
959 ----FEE3790DC7E35189CA67CE2C
960 Content-Type: application/msword; name="FieldReport.doc"
961 Content-Transfer-Encoding: base64
962 Content-Disposition: inline; filename="FieldReport.doc"
963 Content-ID: <calsvr.example.com-12345aaa>
965 R0lGODdhTAQZAJEAAFVVVd3d3e4AAP///ywAAAAATAQZAAAC/5yPOSLhD6OctNqLs94Xq
966 AG4kiW5omm6sq27gvH8kzX9o1y+s73/g8MCofEovGITCoxKMbyCR16cNSq9YrNarfcrvd
967 riIH5LL5jE6rxc3G+v2cguf0uv2Oz+v38L7/DxgoOKjURnjIIbe3yNjo+AgZWYVIWWl5i
971 ----FEE3790DC7E35189CA67CE2C
9735. Recommended Practices
975 This section outlines a series of recommended practices when using a
976 messaging transport to exchange iCalendar objects.
9785.1. Use of Content and Message IDs
980 The [iCAL] specification makes frequent use of the URI for data types
981 in properties such as "DESCRIPTION", "ATTACH", "CONTACT", and others.
982 Two forms of URIs are the Message ID (MID) and the Content-ID (CID).
983 These are defined in [RFC2392]. Although [RFC2392] allows
984 referencing messages or MIME body parts in other MIME entities or
985 stores, it is strongly RECOMMENDED that iMIP implementations include
986 all referenced messages and body parts in a single MIME entity.
987 Simply put, if an iCalendar object contains CID or MID references to
988 other messages or body parts, implementations should ensure that
989 these messages and/or body parts are transmitted with the iCalendar
990 object. If they are not, there is no guarantee that the receiving
991 CUA will have the access or the authorization to view those objects.
9936. IANA Considerations
995 The "text/calendar" MIME media type was registered in [iCAL].
1010Melnikov Standards Track [Page 18]
1012RFC 6047 iMIP December 2010
10177.1. Normative References
1019 [iCAL] Desruisseaux, B., Ed., "Internet Calendaring and
1020 Scheduling Core Object Specification (iCalendar)",
1021 RFC 5545, September 2009.
1023 [iTIP] Daboo, C., Ed., "iCalendar Transport-Independent
1024 Interoperability Protocol (iTIP)", RFC 5546, December
1027 [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322,
1030 [MAILTO] Duerst, M., Masinter, L., and J. Zawinski, "The 'mailto'
1031 URI Scheme", RFC 6068, October 2010.
1033 [RFC1847] Galvin, J., Murphy, S., Crocker, S., and N. Freed,
1034 "Security Multiparts for MIME: Multipart/Signed and
1035 Multipart/Encrypted", RFC 1847, October 1995.
1037 [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
1038 Extensions (MIME) Part One: Format of Internet Message
1039 Bodies", RFC 2045, November 1996.
1041 [RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
1042 Extensions (MIME) Part Two: Media Types", RFC 2046,
1045 [RFC2392] Levinson, E., "Content-ID and Message-ID Uniform Resource
1046 Locators", RFC 2392, August 1998.
1048 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
1049 Requirement Levels", BCP 14, RFC 2119, March 1997.
1051 [UTF-8] Yergeau, F., "UTF-8, a transformation format of ISO
1052 10646", STD 63, RFC 3629, November 2003.
1054 [SMTP-TLS] Hoffman, P., "SMTP Service Extension for Secure SMTP over
1055 Transport Layer Security", RFC 3207, February 2002.
1058 Newman, C., "Using TLS with IMAP, POP3 and ACAP",
1059 RFC 2595, June 1999.
1066Melnikov Standards Track [Page 19]
1068RFC 6047 iMIP December 2010
1071 [RFC5750] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet
1072 Mail Extensions (S/MIME) Version 3.2 Certificate
1073 Handling", RFC 5750, January 2010.
1075 [RFC5751] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet
1076 Mail Extensions (S/MIME) Version 3.2 Message
1077 Specification", RFC 5751, January 2010.
1079 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
1080 Housley, R., and W. Polk, "Internet X.509 Public Key
1081 Infrastructure Certificate and Certificate Revocation
1082 List (CRL) Profile", RFC 5280, May 2008.
10847.2. Informative References
1086 [8BITMIME] Klensin, J., Freed, N., Rose, M., Stefferud, E., and D.
1087 Crocker, "SMTP Service Extension for 8bit-MIMEtransport",
1088 RFC 1652, July 1994.
1090 [RFC5598] Crocker, D., "Internet Mail Architecture", RFC 5598, July
1093 [RFC3282] Alvestrand, H., "Content Language Headers", RFC 3282, May
1122Melnikov Standards Track [Page 20]
1124RFC 6047 iMIP December 2010
1127Appendix A. Changes since RFC 2447
1129 Updated references. Split them into Normative and Informative.
1131 Updated examples to use example.com/example.net domains.
1133 Corrected usage of RFC 2119 language.
1135 Clarified that charset=UTF-8 is required, unless the calendar can be
1136 entirely represented in US-ASCII.
1138 Clarified that 7-bit content transfer encodings should be used unless
1139 the calendar object is known to be transferred over 8-bit clean
1142 Clarified that file extension specified in the Content-Disposition
1143 header field is not to be used to override the "Content-Type" MIME
1146 Disallowed use of "multipart/alternative" for slightly different
1147 representations of the same calendar.
1149 Clarified handling of the "method" MIME parameter of the "Content-
1152 Clarified that in an iMIP message an ORGANIZER/ATTENDEE property
1153 contains a mailto: URI.
1155 Fixed examples with ATTENDEE property to use "CUTYPE=" instead of
1158 Clarified that message integrity/confidentiality should be achieved
1161 Provided additional examples.
1163 Improved the Security Considerations section.
1165 Made multiple editorial changes to different sections of the
1178Melnikov Standards Track [Page 21]
1180RFC 6047 iMIP December 2010
1183Appendix B. Acknowledgements
1185 The editor of this document wishes to thank Frank Dawson, Steve
1186 Mansour, and Steve Silverberg, the original authors of RFC 2447, as
1187 well as the following individuals who have participated in the
1188 drafting, review, and discussion of this memo:
1190 Reinhold Kainhofer, Cyrus Daboo, Bernard Desruisseaux, Eliot Lear,
1191 and Peter Saint-Andre.
1195 Alexey Melnikov (editor)
1197 5 Castle Business Village
1199 Hampton, Middlesex TW12 2BX
1202 EMail: Alexey.Melnikov@isode.com
1234Melnikov Standards Track [Page 22]