draft-ietf-calsify-rfc2447bis-02.txt   draft-ietf-calsify-rfc2447bis-03.txt 
Document: draft-ietf-calsify-rfc2447bis-02.txt A. Melnikov INTERNET-DRAFT A. Melnikov
Intended category: Standard Track Editor Document: draft-ietf-calsify-rfc2447bis-03.txt Editor
Intended status: Standard Track February 2007
Expires: August 2007
iCalendar Message-Based Interoperability Protocol iCalendar Message-Based Interoperability Protocol
(iMIP) (iMIP)
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet
Task Force (IETF), its areas, and its working groups. Note that Engineering Task Force (IETF), its areas, and its
other groups may also distribute working documents as Internet- working groups. Note that other groups may also distribute
Drafts. working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of
and may be updated, replaced, or obsoleted by other documents at any six months and may be updated, replaced, or obsoleted by
time. It is inappropriate to use Internet-Drafts as reference other documents at any time. It is inappropriate to use
material or to cite them other than as "work in progress". Internet-Drafts as reference material or to cite them other
than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt http://www.ietf.org/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html
A revised version of this draft document will be submitted to the RFC A revised version of this draft document will be submitted to the RFC
editor as a Draft Standard for the Internet Community. Discussion editor as a Draft Standard for the Internet Community. Discussion
and suggestions for improvement are requested, and should be sent to and suggestions for improvement are requested, and should be sent to
the CALSIFY Mailing list <ietf-calsify@osafoundation.org>. the CALSIFY Mailing list <ietf-calsify@osafoundation.org>.
Distribution of this document is unlimited. Distribution of this document is unlimited.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2006). Copyright (C) The IETF Trust (2007).
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 (iCAL) are Calendaring entries defined by the iCalendar Object Model (iCAL) are
composed using constructs from RFC 2822, RFC 2045, RFC 2046, composed using constructs from RFC 2822, RFC 2045, RFC 2046,
RFC 2047, RFC 2048 and RFC 2049. RFC 2047 and RFC 2049.
This document is a product of Calendaring and Scheduling Standards This document is a product of Calendaring and Scheduling Standards
Simplification (calsify) working group. More information about the Simplification (calsify) working group. More information about the
IETF CALSIFY working group activities can be found on the IETF web IETF CALSIFY working group activities can be found on the IETF web
site at <http://www.ietf.org/html.charters/calsify-charter.html>. site at <http://www.ietf.org/html.charters/calsify-charter.html>.
The issue tracker for the Calsify WG is located at:
<http://www.ofcourseimright.com/cgi-bin/roundup/calsify>
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
2.2.1 Authorization ...............................................4 2.2.1 Authorization ...............................................4
skipping to change at page 3, line 39 skipping to change at page 3, line 39
5 RECOMMENDED PRACTICES..............................................14 5 RECOMMENDED PRACTICES..............................................14
5.1 USE OF CONTENT AND MESSAGE IDS .................................14 5.1 USE OF CONTENT AND MESSAGE IDS .................................14
6 REFERENCES.........................................................15 6 REFERENCES.........................................................15
7 EDITOR'S ADDRESSES.................................................16 7 EDITOR'S ADDRESSES.................................................16
8 FULL COPYRIGHT STATEMENT...........................................XX 8 FULL COPYRIGHT STATEMENT...........................................XX
9 INTELLECTUAL PROPERTY..............................................XX 9 INTELLECTUAL PROPERTY..............................................XX
1 Introduction 1 Introduction
This binding document provides the transport specific information This binding document provides the transport specific information
necessary to convey iCalendar Transport-independent Interoperability necessary to convey iCalendar Transport-independent Interoperability
Protocol (iTIP) over MIME as defined in [RFC-2822] and [RFC-2045]. Protocol (iTIP) [iTIP] over MIME as defined in [RFC-2822] and
[RFC-2045].
1.1 Related Memos 1.1 Related Memos
Implementers will need to be familiar with several other memos that, Implementers will need to be familiar with several other memos that,
along with this memo, form a framework for Internet calendaring and along with this memo, form a framework for Internet calendaring and
scheduling standards. scheduling standards.
This document, [iMIP], specifies an Internet email binding for iTIP. This document, [iMIP], specifies an Internet email binding for iTIP.
[iCAL] - specifies a core specification of objects, data types, [iCAL] - specifies a core specification of objects, data types,
skipping to change at page 7, line 4 skipping to change at page 7, line 4
ascertained by opening the "text/calendar" MIME body part and ascertained by opening the "text/calendar" MIME body part and
examining the "ATTENDEE" and "ORGANIZER" properties. examining the "ATTENDEE" and "ORGANIZER" properties.
2.4 Content Type 2.4 Content Type
A MIME body part containing content information that conforms to this A MIME body part containing content information that conforms to this
document MUST have an [RFC-2045] "Content-Type" value of document MUST have an [RFC-2045] "Content-Type" value of
"text/calendar". The [RFC-2045] "Content-Type" header field MUST also "text/calendar". The [RFC-2045] "Content-Type" header field MUST also
include the type parameter "method". The value MUST be the same as include the type parameter "method". The value MUST be the same as
the value of the "METHOD" calendar property within the iCalendar the value of the "METHOD" calendar property within the iCalendar
object. This means that a MIME message containing multiple iCalendar object.
objects with different method values must be further encapsulated
with a "multipart/mixed" MIME entity. This will allow each of the Note 1: A MIME message containing multiple iCalendar objects with
iCalendar objects to be encapsulated within their own "text/calendar" different method values must be further encapsulated with a
MIME entity. "multipart/mixed" MIME entity. This will allow each of the iCalendar
objects to be encapsulated within their own "text/calendar" MIME
entity.
Note 2: A MIME body part of "text/calendar" "Content-Type" 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 Note that according to [iCAL] the default character set for iCalendar
objects is UTF-8 [UTF-8]. However the default character set for a objects is UTF-8 [UTF-8]. However the default character set for a
"text/*" MIME entity [RFC-2046] is US-ASCII. Thus a "charset" "text/*" MIME entity [RFC-2046] is US-ASCII. Thus a "charset"
parameter MUST be present if the iCalendar object contains characters parameter MUST be present if the iCalendar object contains characters
that are not part of the US-ASCII character set. [RFC-2046] discusses that are not part of the US-ASCII character set. [RFC-2046] discusses
the selection of an appropriate "charset" value. the selection of an appropriate "charset" value.
The optional "component" parameter defines the iCalendar component The optional "component" parameter defines the iCalendar component
type contained within the iCalendar object. type contained within the iCalendar object.
skipping to change at page 7, line 41 skipping to change at page 7, line 47
In order to permit the information in the scheduling message to be In order to permit the information in the scheduling message to be
understood by MIME user agents (UA) that do not support the understood by MIME user agents (UA) that do not support the
"text/calendar" content type, scheduling messages SHOULD be sent with "text/calendar" content type, scheduling messages SHOULD be sent with
an alternative, human-readable form of the information. an alternative, human-readable form of the information.
Note that "multiple/alternative" MUST NOT be used to represent two Note that "multiple/alternative" MUST NOT be used to represent two
slightly different iCalendar objects, for example two VEVENT with slightly different iCalendar objects, for example two VEVENT with
alternative starting times. alternative starting times.
<<CUA can use language and other parameters to pick a "text/calendar" CUA can use language and other parameters to pick a "text/calendar"
part if a "multipart/alternative" MIME message contains more than one part if a "multipart/alternative" MIME message contains more than one
"text/calendar" part.>> "text/calendar" part.
Any receiving UA compliant with this specification MUST be able to Any receiving UA compliant with this specification MUST be able to
process "text/calendar" body parts enclosed within "multipart/*". process "text/calendar" body parts enclosed within "multipart/*".
Note that a "multipart/mixed" MIME message can include multiple Note that a "multipart/mixed" MIME message can include multiple
"text/calendar" components. The receiving UA MUST be able to process "text/calendar" components. The receiving UA MUST be able to process
all of them. all of them.
2.5 Content-Transfer-Encoding 2.5 Content-Transfer-Encoding
Unless iMIP message is transported over 8-bit clean transport (such Unless iMIP message is transported over 8-bit clean transport (such
as SMTP [8BITMIME]), a transfer encoding such as quoted-printable or as SMTP [8BITMIME]), a transfer encoding such as quoted-printable or
base64 [RFC-2045] MUST be used for iCalendar objects containing any base64 [RFC-2045] MUST be used for iCalendar objects containing any
characters that are not part of the US-ASCII character set. characters that are not part of the US-ASCII character set.
<<Add examples of 8bit and quoted-printable>> <<Add examples of 8bit and quoted-printable>>
2.6 Content-Disposition 2.6 Content-Disposition
Implementations MAY include a "Content-Disposition" header field to Implementations MAY include a "Content-Disposition" header field to
skipping to change at page 9, line 23 skipping to change at page 9, line 23
the requested operation. Compliant applications MUST support signing the requested operation. Compliant applications MUST support signing
and encrypting text/calendar attachments using a mechanism based on and encrypting text/calendar attachments using a mechanism based on
Security Multiparts for MIME [RFC-1847] to facilitate the Security Multiparts for MIME [RFC-1847] to facilitate the
authentication the originator of the iCalendar object. authentication the originator of the iCalendar object.
Implementations MAY provide a means for users to disable signing and Implementations MAY provide a means for users to disable signing and
encrypting. The steps are described below: encrypting. The steps are described below:
1. The iCalendar object MUST be signed by the "Organizer" sending an 1. The iCalendar object MUST be signed by the "Organizer" sending an
update or the "Attendee" sending a reply. update or the "Attendee" sending a reply.
2. Using the compliant security mechanism with [RFC-1847], determine 2. Using the security mechanism compliant with [RFC-1847], determine
who signed the iCalendar object. This is the "signer". Note that the who signed the iCalendar object. This is the "signer". Note that the
signer is not necessarily the person sending an e-mail message since signer is not necessarily the person sending an e-mail message since
an e-mail message can be forwarded. an e-mail message can be forwarded.
3. Correlate the signer to an "ATTENDEE" property in the iCalendar 3. Correlate the signer to an "ATTENDEE" property in the iCalendar
object. If the signer cannot be correlated to an "ATTENDEE" property, object. If the signer cannot be correlated to an "ATTENDEE" property,
ignore the message. ignore the message.
4. Determine whether or not the "ATTENDEE" is authorized to perform 4. Determine whether or not the "ATTENDEE" is authorized to perform
the operation as defined by [iTIP]. If the conditions are not met, the operation as defined by [iTIP]. If the conditions are not met,
skipping to change at page 9, line 47 skipping to change at page 9, line 47
To address the confidentiality security threats, signed iMIP messages To address the confidentiality security threats, signed iMIP messages
SHOULD be encrypted by a mechanism based on Security Multiparts for SHOULD be encrypted by a mechanism based on Security Multiparts for
MIME [RFC-1847]. MIME [RFC-1847].
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 applying changes from someone working on behalf of a "Calendar User".
User">>.
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 18, line 37 skipping to change at page 17, line 37
"Security Multiparts for MIME: Multipart/Signed and "Security Multiparts for MIME: Multipart/Signed and
Multipart/Encrypted", RFC 1847, October 1995. Multipart/Encrypted", RFC 1847, October 1995.
[RFC-2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail [RFC-2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) - Part One: Format of Internet Message Bodies", RFC Extensions (MIME) - Part One: Format of Internet Message Bodies", RFC
2045, November 1996. 2045, November 1996.
[RFC-2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail [RFC-2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) - Part Two: Media Types", RFC 2046, November 1996. Extensions (MIME) - Part Two: Media Types", RFC 2046, November 1996.
[RFC-2047] Moore, K., "Multipurpose Internet Mail Extensions (MIME) -
Part Three: Message Header Extensions for Non-ASCII Text", RFC 2047,
November 1996.
[RFC-2048] Freed, N., Klensin, J. and J. Postel, "Multipurpose
Internet Mail Extensions (MIME) - Part Four: Registration
Procedures", RFC 2048, January 1997.
[RFC-2049] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part Five: Conformance Criteria and Examples", RFC
2049, November 1996.
[RFC-2392] Levinson, E., "Content-ID and Message-ID Uniform Resource [RFC-2392] Levinson, E., "Content-ID and Message-ID Uniform Resource
Locators", RFC 2392, August 1998. Locators", RFC 2392, August 1998.
[RFC-2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC-2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[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) -
Part Three: Message Header Extensions for Non-ASCII Text", RFC 2047,
November 1996.
[RFC-2049] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part Five: Conformance Criteria and Examples", RFC
2049, November 1996.
8 Editor's Addresses 8 Editor's Addresses
The following address information is provided in a vCard v3.0, The following address information is provided in a vCard v3.0,
Electronic Business Card, format. Electronic Business Card, format.
BEGIN:VCARD BEGIN:VCARD
VERSION:3.0 VERSION:3.0
N:Melnikov;Alexey N:Melnikov;Alexey
FN:Alexey Melnikov FN:Alexey Melnikov
ORG:Isode Ltd. ORG:Isode Ltd.
ADR;TYPE=WORK,POSTAL,PARCEL:;;5 Castle Business Village, ADR;TYPE=WORK,POSTAL,PARCEL:;;5 Castle Business Village,
36 Station Road;Hampton;Middlesex;TW12 2BX;UK 36 Station Road;Hampton;Middlesex;TW12 2BX;UK
EMAIL;TYPE=INTERNET:Alexey.Melnikov@isode.com EMAIL;TYPE=INTERNET:Alexey.Melnikov@isode.com
END:VCARD END:VCARD
9. Full Copyright Statement 9. Full Copyright Statement
Copyright (C) The Internet Society (2006). Copyright (C) The IETF Trust (2007).
This document is subject to the rights, licenses and restrictions This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors contained in BCP 78, and except as set forth therein, the authors
retain all their rights. retain all their rights.
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement Acknowledgement
Funding for the RFC Editor function is currently provided by the Funding for the RFC Editor function is provided by the IETF
Internet Society. Administrative Support Activity (IASA).
10. Intellectual Property 10. Intellectual Property
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be on the procedures with respect to rights in RFC documents can be
 End of changes. 22 change blocks. 
45 lines changed or deleted 56 lines changed or added

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