mirror of
https://git.friendi.ca/friendica/friendica-addons.git
synced 2024-08-20 20:30:27 +00:00
1235 lines
40 KiB
Text
1235 lines
40 KiB
Text
|
||
|
||
|
||
|
||
|
||
|
||
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]
|
||
|