Merge pull request #3 from friendica/master

Align to main project HEAD

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]
+