Update SabreDAV from 1.8.9 to 1.8.10.

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