aboutsummaryrefslogtreecommitdiffstats
path: root/vendor/sabre/dav/docs/rfc6047.txt
diff options
context:
space:
mode:
authorKlaus Weidenbach <Klaus.Weidenbach@gmx.net>2014-06-28 22:28:08 +0200
committerKlaus Weidenbach <Klaus.Weidenbach@gmx.net>2014-06-29 01:17:07 +0200
commit03b31d113ea316c8384a4cbf3d27ca22bb528eac (patch)
tree92ed87436b09ab806f9effff08145408044d77f4 /vendor/sabre/dav/docs/rfc6047.txt
parentf49b74c5f6ebe57937fb6dfea7d2e917f4680ce9 (diff)
downloadvolse-hubzilla-03b31d113ea316c8384a4cbf3d27ca22bb528eac.tar.gz
volse-hubzilla-03b31d113ea316c8384a4cbf3d27ca22bb528eac.tar.bz2
volse-hubzilla-03b31d113ea316c8384a4cbf3d27ca22bb528eac.zip
Update SabreDAV from 1.8.9 to 1.8.10.
Diffstat (limited to 'vendor/sabre/dav/docs/rfc6047.txt')
-rw-r--r--vendor/sabre/dav/docs/rfc6047.txt1235
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]
-