diff options
Diffstat (limited to 'vendor/sabre/dav/docs/rfc6047.txt')
| -rw-r--r-- | vendor/sabre/dav/docs/rfc6047.txt | 1235 |
1 files changed, 1235 insertions, 0 deletions
diff --git a/vendor/sabre/dav/docs/rfc6047.txt b/vendor/sabre/dav/docs/rfc6047.txt new file mode 100644 index 000000000..c839c8ed3 --- /dev/null +++ b/vendor/sabre/dav/docs/rfc6047.txt @@ -0,0 +1,1235 @@ + + + + + + +Internet Engineering Task Force (IETF) A. Melnikov, Ed. +Request for Comments: 6047 Isode Ltd +Obsoletes: 2447 December 2010 +Category: Standards Track +ISSN: 2070-1721 + + + iCalendar Message-Based Interoperability Protocol (iMIP) + +Abstract + + This document, "iCalendar Message-Based Interoperability Protocol + (iMIP)", specifies a binding from the iCalendar Transport-independent + Interoperability Protocol (iTIP) to Internet email-based transports. + Calendaring entries defined by the iCalendar Object Model (iCalendar) + are wrapped using constructs from RFC 5322 and MIME (RFC 2045, RFC + 2046, RFC 2047, and RFC 2049), and then transported over SMTP. + +Status of This Memo + + This is an Internet Standards Track document. + + This document is a product of the Internet Engineering Task Force + (IETF). It represents the consensus of the IETF community. It has + received public review and has been approved for publication by the + Internet Engineering Steering Group (IESG). Further information on + Internet Standards is available in Section 2 of RFC 5741. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + http://www.rfc-editor.org/info/rfc6047. + +Copyright Notice + + Copyright (c) 2010 IETF Trust and the persons identified as the + document authors. All rights reserved. + + This document is subject to BCP 78 and the IETF Trust's Legal + Provisions Relating to IETF Documents + (http://trustee.ietf.org/license-info) in effect on the date of + publication of this document. Please review these documents + carefully, as they describe your rights and restrictions with respect + to this document. Code Components extracted from this document must + include Simplified BSD License text as described in Section 4.e of + the Trust Legal Provisions and are provided without warranty as + described in the Simplified BSD License. + + + + + +Melnikov Standards Track [Page 1] + +RFC 6047 iMIP December 2010 + + + This document may contain material from IETF Documents or IETF + Contributions published or made publicly available before November + 10, 2008. The person(s) controlling the copyright in some of this + material may not have granted the IETF Trust the right to allow + modifications of such material outside the IETF Standards Process. + Without obtaining an adequate license from the person(s) controlling + the copyright in such materials, this document may not be modified + outside the IETF Standards Process, and derivative works of it may + not be created outside the IETF Standards Process, except to format + it for publication as an RFC or to translate 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 + + + + + + +Melnikov Standards Track [Page 2] + +RFC 6047 iMIP December 2010 + + +1. Introduction + + This document provides the transport-specific information ("binding") + necessary to convey iCalendar Transport-independent Interoperability + Protocol (iTIP) [iTIP] over Internet email (using MIME) as defined in + [RFC5322] and [RFC2045]. Therefore, this document defines the + iCalendar Message-Based Interoperability Protocol (iMIP). + +1.1. Related Memos + + Implementers will need to be familiar with several other memos that, + along with this memo, form a framework for Internet calendaring and + scheduling standards. + + This document specifies an Internet email binding for iTIP. + + [iCAL] specifies a core specification of objects, data types, + properties, and property parameters. + + [iTIP] specifies an interoperability protocol for scheduling between + different implementations. + + This memo does not attempt to repeat the specification of concepts or + definitions from these other memos. Where possible, references are + made to the memo that provides for the specification of these + concepts or definitions. + +1.2. Formatting Conventions + + The mechanisms defined in this memo are defined in prose. In order + to refer to elements of the calendaring and scheduling model, core + object, or interoperability protocol defined in [iCAL] and [iTIP], + some formatting conventions have been used. + + 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]. + + Calendaring and scheduling roles are referred to in quoted strings of + text with the first character of each word in uppercase. For + example, "Organizer" refers to a role of a "Calendar User" within the + scheduling protocol defined by [iTIP]. + + Calendar components defined by [iCAL] are referred to with + capitalized, quoted strings of text. All calendar components start + with the letter "V". For example, "VEVENT" refers to the event + calendar component, "VTODO" refers to the to-do calendar component, + and "VJOURNAL" refers to the daily journal calendar component. + + + +Melnikov Standards Track [Page 3] + +RFC 6047 iMIP December 2010 + + + Scheduling methods defined by [iTIP] are referred to with + capitalized, quoted strings of text. For example, "REQUEST" refers + to the method for requesting a scheduling calendar component be + created or modified; "REPLY" refers to the method a recipient of a + request uses to update their status with the "Organizer" of the + calendar component. + + Properties defined by [iCAL] are referred to with capitalized, quoted + strings of text, followed by the word "property". For example, + "ATTENDEE" property refers to the iCalendar property used to convey + the calendar address of a "Calendar User". + + Property parameters defined by [iCAL] are referred to with lowercase, + quoted strings of text, followed by the word "parameter". For + example, "value" parameter refers to the iCalendar property parameter + used to override the default data type for a property value. + +1.3. Terminology + + The email terms used in this memo are defined in [RFC5322] and + [RFC2045]. The calendaring and scheduling terms used in this memo + are defined in [iCAL] and [iTIP]. + +2. MIME Message Format Binding + + This section defines the message binding to the MIME electronic mail + transport. + + The sections below refer to the "originator" and the "recipient" of + an iMIP message. In the case of a "request" method, the originator + is the "Organizer" and the recipient is an "Attendee" of the event. + In the case of a "response" method, the originator is an "Attendee" + and the recipient is the "Organizer" of the event. + + The [RFC5322] "Reply-To" header field typically contains the email + address of the originator of the scheduling message. However, this + cannot be guaranteed because the sender of the iMIP message might not + be the originator of the scheduling message and the sender's "Mail + User Agent" (MUA) might not enforce iMIP semantics by translating the + originator's address into the "Reply-To" email header field. + +2.1. MIME Media Type + + A MIME entity containing content information formatted according to + this document will be referenced as a "text/calendar" content type + [iCAL]. It is assumed that this content type will be transported + through a MIME electronic mail transport. + + + + +Melnikov Standards Track [Page 4] + +RFC 6047 iMIP December 2010 + + +2.2. Security + + This section addresses several aspects of security including + authentication, authorization, and confidentiality. Authentication + and confidentiality can be achieved using 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 calendar entries she organizes. That is, + spoof@xyz.example.net is not allowed to modify or cancel a meeting + that was organized by a@example.com. Furthermore, only the + respondent has the authorization to indicate their status to the + "Organizer". That is, the "Organizer" MUST ignore an iTIP message + from spoof@xyz.example.net that declines a meeting invitation for + b@example.com. + + Implementations of iMIP SHOULD verify the authenticity of the creator + of an iCalendar object before taking any action. Methods for doing + this are presented later in this document. + + [RFC1847] message flow in iTIP supports someone working on behalf of + a "Calendar User" through use of the "sent-by" parameter that is + associated with the "ATTENDEE" and "ORGANIZER" properties. However, + there is no mechanism to verify whether or not a "Calendar User" has + authorized someone to work on their behalf. It is left to + implementations to provide mechanisms for the "Calendar Users" to + make that decision. + +2.2.2. Authentication + + Authentication MUST be performed using S/MIME [RFC5750] [RFC5751]. + Authentication is possible only on messages that have been signed. + Unauthenticated messages (i.e., unsigned messages) may not be + trusted. + +2.2.3. Confidentiality + + To ensure confidentiality using iMIP, implementations SHOULD utilize + encryption specified in S/MIME [RFC5750] [RFC5751]. iMIP does not + restrict a "Calendar User Agent" (CUA) from forwarding iCalendar + objects to other users or agents. + + + + + + + +Melnikov Standards Track [Page 5] + +RFC 6047 iMIP December 2010 + + +2.3. Email Addresses + + The calendar address specified within the "ORGANIZER" and "ATTENDEE" + properties in an iCalendar object sent using iMIP MUST be a proper + "mailto:" [MAILTO] URI specification for the corresponding + "Organizer" or "Attendee" of the "VEVENT" or "VTODO". + + Because [iTIP] does not preclude "Attendees" from forwarding + "VEVENT"s or "VTODO"s to others, the [RFC5322] "Sender" value may not + equal that of the "Organizer". Additionally, the "Organizer" or + "Attendee" cannot be reliably inferred by the [RFC5322] "Sender" or + "Reply-To" header field values of an iMIP message. The relevant + address MUST be ascertained by opening the "text/calendar" MIME body + part and examining the "ATTENDEE" and "ORGANIZER" properties. + +2.4. Content-Type Header Field + + A MIME body part containing content information that conforms to 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". The value MUST be the same + (ignoring case) as the value of the "METHOD" property within the + iCalendar object. + + Note 1: A MIME message containing multiple iCalendar objects with + different "method" values MUST be further encapsulated with a + "multipart/mixed" MIME entity [RFC2046]. This will allow each of + the iCalendar objects to be encapsulated within their own + "text/calendar" MIME entity. + + Note 2: A MIME body part with a "Content-Type" value of + "text/calendar" that lacks the "method" parameter is not + considered to be an iMIP body part and thus is not subject to the + requirements specified in this document. + + Note that according to [iCAL] the default character set for iCalendar + objects is UTF-8 [UTF-8]. However, the default character set for a + "text/*" MIME entity according to [RFC2046] is US-ASCII. Thus, a + "charset" MIME parameter MUST be present if the iCalendar object + contains characters that can't be represented in the US-ASCII + character set and, as specified in [iCAL], it MUST have the value + "UTF-8". + + The optional "component" MIME parameter defines the iCalendar + component type contained within the iCalendar object. + + + + + + +Melnikov Standards Track [Page 6] + +RFC 6047 iMIP December 2010 + + + The following is an example of this header field with a value that + indicates an event message. + + Content-Type: text/calendar; method=REQUEST; charset=UTF-8; + component=vevent + + The "text/calendar" content type allows for the scheduling message + type to be included in a MIME message with other content information + (i.e., "multipart/mixed") or included in a MIME message with a clear- + text, human-readable form of the scheduling message (i.e., + "multipart/alternative" [RFC2046]). + + In order to permit the information in the scheduling message to be + understood by MIME User Agents (UAs) that do not support the + "text/calendar" content type, scheduling messages SHOULD be sent with + an alternative, human-readable form of the information. + + Note that "multipart/alternative" MUST NOT be used to represent two + slightly different iCalendar objects, for example, two "VEVENT"s with + alternative starting times. + + CUAs can use other MIME parameters of the "Content-Type" header + field, as well as a language specified in the Content-Language header + field [RFC3282], to pick a "text/calendar" part for processing if a + "multipart/alternative" MIME message contains more than one + "text/calendar" part. + + Any receiving UA compliant with this specification MUST be able to + process "text/calendar" body parts enclosed within "multipart/*". + Note that a "multipart/mixed" MIME message can include multiple + "text/calendar" components. The receiving UA MUST be able to process + all of them. + +2.5. Content-Transfer-Encoding Header Field + + Unless an iMIP message is transported over 8-bit clean transport + (such as SMTP [8BITMIME]), a transfer encoding such as quoted- + printable or base64 [RFC2045] MUST be used for iCalendar objects + containing any characters that can't be represented in the US-ASCII + character set. For example: + + + + + + + + + + + +Melnikov Standards Track [Page 7] + +RFC 6047 iMIP December 2010 + + + 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 + +2.6. Content-Disposition Header Field + + Implementations MAY include a "Content-Disposition" header field to + define a file name for an iCalendar object. However, the handling of + a MIME part MUST be based on its [RFC2045] "Content-Type" and not on + the extension specified in the "Content-Disposition", as different + email malware is known to trick User Agents into misinterpreting + content of messages by specifying a file extension in the Content- + Disposition header field that doesn't correspond to the value of the + "Content-Type" header field. + +3. Security Considerations + + The security threats that applications must address when implementing + iTIP are detailed in [iTIP]. In particular, two spoofing threats are + identified in Section 6.1 of [iTIP]: spoofing the "Organizer", and + spoofing an "Attendee". To address these threats, the originator of + an iCalendar object must be authenticated by a recipient. Once + + + +Melnikov Standards Track [Page 8] + +RFC 6047 iMIP December 2010 + + + authenticated, a determination can be made as to whether or not the + originator is authorized to perform the requested operation. + Compliant applications MUST support signing and encrypting + "text/calendar" body parts using a mechanism based on S/MIME + [RFC5750] [RFC5751] in order to facilitate the authentication of the + originator of the iCalendar object (see Sections 2.2.2 and 2.2.3). + The steps for processing a signed iMIP message are described below: + + 1. Using S/MIME, determine who signed the "text/calendar" body part + containing the iCalendar object. This is the "signer". (Note + that the email address of the signer MUST be specified in the + rfc822Name field of the "subject alternative name" extension of + the signer certificate, as specified in [RFC5280], + Section 4.1.2.6.) Note that the signer is not necessarily the + person sending an e-mail message, since an e-mail message can be + forwarded. + + 2. Correlate the signer to either an "ATTENDEE" property or to the + "ORGANIZER" property in the iCalendar object, based on the method + and the calendar component specified in the iCalendar object, as + defined in Section 1.4 of [iTIP]. If the signer cannot be + correlated to an "ATTENDEE"/"ORGANIZER" property, then actively + warn the user controlling the "Calendar User Agent" that the + iCalendar object is untrusted, and encourage the user to ignore + the message, but give advanced users the option to (a) view the + certificate of the signer and the entire certificate chain (if + any) in order to help decide if the signer should be trusted to + send the message, and then (b) allow the CUA to accept and process + the iCalendar object. + + 3. Determine whether or not the "ATTENDEE"/"ORGANIZER" is authorized + to perform the operation as defined by [iTIP]. If the conditions + are not met, ignore the message. + + 4. If all the above conditions are met, the message can be processed. + + S/MIME signing also protects against malicious changes to messages in + transit. + + If calendar confidentiality is required by the sender, signed iMIP + messages SHOULD be encrypted by 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 alternatively be used to + provide calendar confidentiality. + + + + + + +Melnikov Standards Track [Page 9] + +RFC 6047 iMIP December 2010 + + + Once a signed and/or encrypted iMIP message is received and + successfully verified (as detailed above) by a CUA, the CUA SHOULD + remember whether the sender of the message is using signing and/or + encrypting. If an unsigned iMIP message is received from the same + sender later on, the receiving CUA SHOULD warn the receiving user + about a possible man-in-the-middle attack and SHOULD ignore the + message, unless explicitly overridden by the user. + + Implementations MAY provide means for users to disable signing and + encrypting. + + It is possible to receive iMIP messages sent by someone working on + behalf of another "Calendar User". This is determined by examining + the "sent-by" parameter in the relevant "ORGANIZER" or "ATTENDEE" + property. [iCAL] and [iTIP] provide no mechanism to verify that a + "Calendar User" has authorized someone else to work on their behalf. + To address this security issue, implementations MUST provide + mechanisms for the "Calendar Users" to make that decision before + applying changes from someone working on behalf of a "Calendar User". + One way to achieve this is to reject iMIP messages sent by users + other than the "ORGANIZER" or the "ATTENDEE"s. Alternatively, the + receiver could have a list of trusted <sent-by, organizer> proxies in + its local security policy. And yet another way is to prompt the user + for confirmation. + + iMIP-based calendaring is frequently deployed within a single ADMD, + with boundary filtering employed to restrict email calendaring flows + to be inside the ADMD. This can help in minimizing malicious changes + to calendaring messages in transit, as well as in making + authorization decisions less risky. + + A security consideration associated with the use of the Content- + Disposition header field is described in Section 2.6. + + Use of S/MIME makes the security considerations discussed in + [RFC5750] [RFC5751] relevant to this document. For additional + security considerations regarding certificate and Certificate + Revocation List (CRL) verification, please see [RFC5280]. + + + + + + + + + + + + + +Melnikov Standards Track [Page 10] + +RFC 6047 iMIP December 2010 + + +4. Examples + +4.1. Single Component with an ATTACH Property + + This minimal message shows how an iCalendar object references an + attachment. The attachment is accessible via 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 + + This example shows how a client can emit a multipart message that + includes both a plain text version and the full iCalendar object. + Clients that do not support "text/calendar" will still be capable of + rendering the plain text representation. + + + + + + + + + + + + +Melnikov Standards Track [Page 11] + +RFC 6047 iMIP December 2010 + + + 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 shows how a message containing an iCalendar object + references an attached document. The reference is made using a + Content-ID (CID). Thus, the iCalendar object and the document are + packaged in a "multipart/related" encapsulation. + + + +Melnikov Standards Track [Page 12] + +RFC 6047 iMIP December 2010 + + + 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-- + + + + + + + + + +Melnikov Standards Track [Page 13] + +RFC 6047 iMIP December 2010 + + +4.4. Multiple Similar Components + + Multiple iCalendar components of the same type can be included in the + iCalendar object when the "METHOD" is the same for each component. + + 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 + + + + + + + + + + + +Melnikov Standards Track [Page 14] + +RFC 6047 iMIP December 2010 + + +4.5. Multiple Mixed Components + + Different component types must be encapsulated in separate iCalendar + objects. + + 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 + + + + + + + + + + + + + + +Melnikov Standards Track [Page 15] + +RFC 6047 iMIP December 2010 + + + ----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 example shows the format of a message containing a group meeting + between three individuals. The "multipart/related" encapsulation is + used because the iCalendar object contains an ATTACH property that + uses a CID to reference the attachment. + + 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" + + + + + + + + + + +Melnikov Standards Track [Page 16] + +RFC 6047 iMIP December 2010 + + + ----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 + + + + + + + + + + + + + + +Melnikov Standards Track [Page 17] + +RFC 6047 iMIP December 2010 + + + ----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 + +5. Recommended Practices + + This section outlines a series of recommended practices when using a + messaging transport to exchange iCalendar objects. + +5.1. Use of Content and Message IDs + + The [iCAL] specification makes frequent use of the URI for data types + in properties such as "DESCRIPTION", "ATTACH", "CONTACT", and others. + Two forms of URIs are the Message ID (MID) and the Content-ID (CID). + These are defined in [RFC2392]. Although [RFC2392] allows + referencing messages or MIME body parts in other MIME entities or + stores, 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 contains CID or MID references to + other messages or body parts, implementations should ensure that + these messages and/or body parts are transmitted with the iCalendar + object. If they are not, there is no guarantee that the receiving + CUA will have the access or the authorization to view those objects. + +6. IANA Considerations + + The "text/calendar" MIME media type was registered in [iCAL]. + + + + + + + + + + + + + + +Melnikov Standards Track [Page 18] + +RFC 6047 iMIP December 2010 + + +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. + + + + + + +Melnikov Standards Track [Page 19] + +RFC 6047 iMIP December 2010 + + + [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 + + [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. + + + + + + + + + + + + + + + + + + + + + + + + + + + +Melnikov Standards Track [Page 20] + +RFC 6047 iMIP December 2010 + + +Appendix A. Changes since RFC 2447 + + Updated references. Split them 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. + + + + + + + + + + + +Melnikov Standards Track [Page 21] + +RFC 6047 iMIP December 2010 + + +Appendix B. Acknowledgements + + The editor of this document wishes to thank Frank Dawson, Steve + Mansour, and Steve Silverberg, the original authors of RFC 2447, as + well as the following individuals who have participated in the + drafting, review, and discussion of 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 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Melnikov Standards Track [Page 22] + |