draft-ietf-calsify-rfc2447bis-09.txt   draft-ietf-calsify-rfc2447bis-10.txt 
INTERNET-DRAFT A. Melnikov INTERNET-DRAFT A. Melnikov
Document: draft-ietf-calsify-rfc2447bis-09.txt Editor Document: draft-ietf-calsify-rfc2447bis-10.txt Editor
Intended status: Standard Track June 21, 2010 Intended status: Standard Track July 27, 2010
Expires: December 2010 Expires: January 2011
iCalendar Message-Based Interoperability Protocol iCalendar Message-Based Interoperability Protocol
(iMIP) (iMIP)
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. This document may contain material provisions of BCP 78 and BCP 79. This document may contain material
from IETF Documents or IETF Contributions published or made publicly from IETF Documents or IETF Contributions published or made publicly
available before November 10, 2008. The person(s) controlling the available before November 10, 2008. The person(s) controlling the
skipping to change at page 2, line 23 skipping to change at page 2, line 23
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the BSD License. described in the BSD License.
Abstract Abstract
This document, iCalendar Message-Based Interoperability Protocol This document, iCalendar Message-Based Interoperability Protocol
(iMIP), specifies a binding from the iCalendar Transport-independent (iMIP), specifies a binding from the iCalendar Transport-independent
Interoperability Protocol (iTIP) to Internet email-based transports. Interoperability Protocol (iTIP) to Internet email-based transports.
Calendaring entries defined by the iCalendar Object Model (iCalendar) Calendaring entries defined by the iCalendar Object Model (iCalendar)
are wrapped using constructs from RFC 5322, RFC 2045, RFC 2046, RFC are wrapped using constructs from RFC 5322 and MIME (RFC 2045, RFC
2047 and RFC 2049, and then transported over SMTP. 2046, RFC 2047 and RFC 2049), and then transported over SMTP.
Table of Contents Table of Contents
1 INTRODUCTION........................................................2 1 INTRODUCTION........................................................2
1.1 RELATED MEMOS ...................................................2 1.1 RELATED MEMOS ...................................................2
1.2 FORMATTING CONVENTIONS ..........................................3 1.2 FORMATTING CONVENTIONS ..........................................3
1.3 TERMINOLOGY .....................................................4 1.3 TERMINOLOGY .....................................................4
2 MIME MESSAGE FORMAT BINDING.........................................4 2 MIME MESSAGE FORMAT BINDING.........................................4
2.1 MIME MEDIA TYPE .................................................4 2.1 MIME MEDIA TYPE .................................................4
2.2 SECURITY ........................................................4 2.2 SECURITY ........................................................4
skipping to change at page 11, line 21 skipping to change at page 11, line 21
It is possible to receive iMIP messages sent by someone working on It is possible to receive iMIP messages sent by someone working on
behalf of another "Calendar User". This is determined by examining behalf of another "Calendar User". This is determined by examining
the "sent-by" parameter in the relevant "ORGANIZER" or "ATTENDEE" the "sent-by" parameter in the relevant "ORGANIZER" or "ATTENDEE"
property. [iCAL] and [iTIP] provide no mechanism to verify that a property. [iCAL] and [iTIP] provide no mechanism to verify that a
"Calendar User" has authorized someone else to work on their behalf. "Calendar User" has authorized someone else to work on their behalf.
To address this security issue, implementations MUST provide To address this security issue, implementations MUST provide
mechanisms for the "Calendar Users" to make that decision before mechanisms for the "Calendar Users" to make that decision before
applying changes from someone working on behalf of a "Calendar User". applying changes from someone working on behalf of a "Calendar User".
One way to achieve this is to reject iMIP messages sent by users One way to achieve this is to reject iMIP messages sent by users
other than the "ORGANIZER" or the "ATTENDEE"s. other than the "ORGANIZER" or the "ATTENDEE"s. Another way is to
prompt the user for confirmation.
iMIP based calendaring is frequently deployed within a single ADMD
(Administrative Domain) [RFC5598], 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 easier.
A security consideration associated with use of Content-Disposition A security consideration associated with use of Content-Disposition
header field is described in section 2.6. header field is described in section 2.6.
4 Examples 4 Examples
4.1 Single Component With An ATTACH Property 4.1 Single Component With An ATTACH Property
This minimal message shows how an iCalendar object references an This minimal message shows how an iCalendar object references an
attachment. The attachment is accessible via its URL. attachment. The attachment is accessible via its URL.
skipping to change at page 20, line 5 skipping to change at page 20, line 5
[UTF-8] Yergeau, F., "UTF-8, a transformation format of ISO 10646", [UTF-8] Yergeau, F., "UTF-8, a transformation format of ISO 10646",
STD 63, RFC 3629, November 2003. STD 63, RFC 3629, November 2003.
7.2 Informative References 7.2 Informative References
[8BITMIME] Klensin, J., Freed, N., Rose, M., Stefferud, E., and D. [8BITMIME] Klensin, J., Freed, N., Rose, M., Stefferud, E., and D.
Crocker, "SMTP Service Extension for 8bit-MIMEtransport", RFC 1652, Crocker, "SMTP Service Extension for 8bit-MIMEtransport", RFC 1652,
July 1994. July 1994.
[RFC-2047] Moore, K., "Multipurpose Internet Mail Extensions (MIME) - [RFC5598] Crocker, D., "Internet Mail Architecture", RFC 5598,
Part Three: Message Header Extensions for Non-ASCII Text", RFC 2047, July 2009.
November 1996.
[RFC-2049] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part Five: Conformance Criteria and Examples", RFC
2049, November 1996.
[RFC-3282] Alvestrand, H., "Content Language Headers", RFC 3282, May [RFC-3282] Alvestrand, H., "Content Language Headers", RFC 3282, May
2002. 2002.
8 Authors' Addresses 8 Authors' Addresses
Alexey Melnikov (editor) Alexey Melnikov (editor)
Isode Ltd Isode Ltd
5 Castle Business Village 5 Castle Business Village
36 Station Road 36 Station Road
 End of changes. 4 change blocks. 
13 lines changed or deleted 15 lines changed or added

This html diff was produced by rfcdiff 1.38. The latest version is available from http://tools.ietf.org/tools/rfcdiff/