mirror of
https://git.friendi.ca/friendica/friendica-addons.git
synced 2024-09-12 09:45:12 +00:00
1236 lines
40 KiB
Text
1236 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]
|
|||
|
|