diff options
Diffstat (limited to 'vendor/sabre/dav/docs/rfc6047.txt')
| -rw-r--r-- | vendor/sabre/dav/docs/rfc6047.txt | 1235 |
1 files changed, 0 insertions, 1235 deletions
diff --git a/vendor/sabre/dav/docs/rfc6047.txt b/vendor/sabre/dav/docs/rfc6047.txt deleted file mode 100644 index c839c8ed3..000000000 --- a/vendor/sabre/dav/docs/rfc6047.txt +++ /dev/null @@ -1,1235 +0,0 @@ - - - - - - -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] - |