draft-ietf-calsify-rfc2447bis-00.txt   draft-ietf-calsify-rfc2447bis-01.txt 
Document: draft-ietf-calsify-rfc2447bis-00.txt A. Melnikov Document: draft-ietf-calsify-rfc2447bis-01.txt A. Melnikov
Intended category: Standard Track Editor Intended category: Standard Track Editor
Expires: February 2006 August 2005 Expires: September 2006 March 2006
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.
skipping to change at page 1, line 41 skipping to change at page 1, line 41
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 (2005). All Rights Reserved. Copyright (C) The Internet Society (2006).
Abstract Abstract
This document, [iMIP], specifies a binding from the iCalendar This document, [iMIP], specifies a binding from the iCalendar
Transport-independent Interoperability Protocol (iTIP) to Internet Transport-independent Interoperability Protocol (iTIP) to Internet
email-based transports. Calendaring entries defined by the iCalendar email-based transports. Calendaring entries defined by the iCalendar
Object Model [iCAL] are composed using constructs from [RFC-2822], Object Model [iCAL] are composed using constructs from [RFC-2822],
[RFC-2045], [RFC-2046], [RFC-2047], [RFC-2048] and [RFC-2049]. [RFC-2045], [RFC-2046], [RFC-2047], [RFC-2048] and [RFC-2049].
This document is a product of Calendaring and Scheduling Standards This document is a product of Calendaring and Scheduling Standards
skipping to change at page 6, line 50 skipping to change at page 6, line 50
not equal that of the "Organizer". Additionally, the "Organizer" or not equal that of the "Organizer". Additionally, the "Organizer" or
"Attendee" cannot be reliably inferred by the [RFC-2822] "Sender" or "Attendee" cannot be reliably inferred by the [RFC-2822] "Sender" or
"Reply-to" values of an iMIP message. The relevant address MUST be "Reply-to" values of an iMIP message. The relevant address MUST be
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 "text/calendar". The [RFC-2045] "Content-Type" header field MUST also
<<MUST?>> also include the type parameter "method". The value MUST be include the type parameter "method". The value MUST be the same as
the same as the value of the "METHOD" calendar property within the the value of the "METHOD" calendar property within the iCalendar
iCalendar object. This means that a MIME message containing multiple object. This means that a MIME message containing multiple iCalendar
iCalendar objects with different method values must be further objects with different method values must be further encapsulated
encapsulated with a "multipart/mixed" MIME entity. This will allow with a "multipart/mixed" MIME entity. This will allow each of the
each of the iCalendar objects to be encapsulated within their own iCalendar objects to be encapsulated within their own "text/calendar"
"text/calendar" MIME entity. MIME entity.
A "charset" parameter MUST be present if the iCalendar object Note that according to [iCAL] the default character set for iCalendar
contains characters that are not part of the US-ASCII character set. objects is UTF-8 [UTF-8]. However the default character set for an
[RFC-2046] discusses the selection of an appropriate "charset" value. RFC 2822 message is US-ASCII. Thus a "charset" parameter MUST be
present if the iCalendar object contains characters that are not part
of the US-ASCII character set. [RFC-2046] discusses 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.
The following is an example of this header field with a value that The following is an example of this header field with a value that
indicates an event message. indicates an event message.
Content-Type: text/calendar; method=request; charset=UTF-8; Content-Type: text/calendar; method=request; charset=UTF-8;
component=vevent component=vevent
skipping to change at page 7, line 34 skipping to change at page 7, line 37
type to be included in a MIME message with other content information 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- (i.e., "multipart/mixed") or included in a MIME message with a clear-
text, human-readable form of the scheduling message (i.e., text, human-readable form of the scheduling message (i.e.,
"multipart/alternative"). "multipart/alternative").
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
slightly different iCalendar objects, for example two VEVENT with
alternative starting times.
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/*".
<<Is any clarification about handling of "multipart/alternative" Note that a "multipart/mixed" MIME message can include multiple
needed?>> Note that a "multipart/mixed" MIME message can include "text/calendar" components. The receiving UA MUST be able to process
multiple "text/calendar" components. The receiving UA MUST be able to all of them. <<Should infinite multipart/mixed nesting be allowed?>>
process all of them. <<Should infinite multipart/mixed nesting be
allowed?>>
2.5 Content-Transfer-Encoding 2.5 Content-Transfer-Encoding
Note that the default character set for iCalendar objects is UTF-8. Unless iMIP message is transported over 8-bit clean transport (such
<<What does this actually mean? RFC 2822 says that the default as SMTP [8BITMIME]), a transfer encoding such as quoted-printable or
charset is US-ASCII, if not specified. This document can't override base64 [RFC 2045] MUST be used for iCalendar objects containing any
this rule.>> A transfer encoding such as quoted-printable or base64 characters that are not part of the US-ASCII character set.
[RFC 2045] SHOULD be used for iCalendar objects containing any
characters that are not part of the US-ASCII character set. <<What
is the purpose of this SHOULD? Is it trying to say that unless you
know that you can use 8bit/binary, you SHOULD use one of the 7bit
safe ones?>>
<<Add examples of 8bit and quoted-printable>> <<Add examples of 8bit and quoted-printable>>
2.6 Content-Disposition 2.6 Content-Disposition
The handling of a MIME part should be based on its [RFC-2045] Implementations MAY include a "Content-Disposition" header field to
"Content-Type". However, this is not guaranteed to work in all define a file name for an iCalendar object. However, the handling of
environments. <<Should this still be encouraged? This is a security a MIME part MUST be based on its [RFC-2045] "Content-Type" and not on
risk as shown by recent virus' outbreaks.>> Some environments handle the extension specified in the "Content-Disposition", as different
MIME attachments based on their file type or extension. To operate email malware is known to trick User Agents into misinterpreting
correctly in these environments, implementations may wish to include content of messages by specifying a file extension in the Content-
a "Content-Disposition" property to define a file name. Disposition header field that doesn't correspond to the value of
Content-Type header field.
3 Security Considerations 3 Security Considerations
The security threats that applications must address when implementing The security threats that applications must address when implementing
iTIP are detailed in [iTIP]. Two spoofing threats are identified: iTIP are detailed in [iTIP]. Two spoofing threats are identified:
Spoofing the "Organizer", and Spoofing an "Attendee". To address Spoofing the "Organizer", and Spoofing an "Attendee". To address
these threats, the originator of an iCalendar object must be these threats, the originator of an iCalendar object must be
authenticated by a recipient. Once authenticated, a determination can authenticated by a recipient. Once authenticated, a determination can
be made as to whether or not the originator is authorized to perform be made as to whether or not the originator is authorized to perform
the requested operation. Compliant applications MUST support signing the requested operation. Compliant applications MUST support signing
skipping to change at page 10, line 5 skipping to change at page 9, line 51
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".
A security consideration associated with use of Content-Disposition
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.
From: sman@netscape.example.com From: sman@netscape.example.com
To: stevesil@microsoft.example.com To: stevesil@microsoft.example.com
Subject: Phone Conference Subject: Phone Conference
skipping to change at page 16, line 18 skipping to change at page 16, line 18
END:VCALENDAR END:VCALENDAR
----00FEE3790DC7E35189CA67CE2C00 ----00FEE3790DC7E35189CA67CE2C00
----FEE3790DC7E35189CA67CE2C ----FEE3790DC7E35189CA67CE2C
Content-Type: application/msword; name="FieldReport.doc" Content-Type: application/msword; name="FieldReport.doc"
Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="FieldReport.doc" Content-Disposition: attachment; filename="FieldReport.doc"
Content-ID: <calsvr.example.com-12345aaa> Content-ID: <calsvr.example.com-12345aaa>
R0lGODdhTAQZAJEAAFVVVd3d3e4AAP///ywAAAAATAQZAAAC/5yPOSLhD6OctNqLs94XqAG R0lGODdhTAQZAJEAAFVVVd3d3e4AAP///ywAAAAATAQZAAAC/5yPOSLhD6OctNqLs94Xq
4kiW5omm6sq27gvH8kzX9o1y+s73/g8MCofEovGITCoxKMbyCR16cNSq9YrNarfcrvdriIH AG4kiW5omm6sq27gvH8kzX9o1y+s73/g8MCofEovGITCoxKMbyCR16cNSq9YrNarfcrvd
5LL5jE6rxc3G+v2cguf0uv2Oz+v38L7/DxgoOKjURnjIIbe3yNjo+AgZWYVIWWl5iZnJY6J riIH5LL5jE6rxc3G+v2cguf0uv2Oz+v38L7/DxgoOKjURnjIIbe3yNjo+AgZWYVIWWl5i
ZnJY6J
... ...
----FEE3790DC7E35189CA67CE2C ----FEE3790DC7E35189CA67CE2C
5 Recommended Practices 5 Recommended Practices
This section outlines a series of recommended practices when using a This section outlines a series of recommended practices when using a
messaging transport to exchange iCalendar objects. messaging transport to exchange iCalendar objects.
5.1 Use of Content and Message IDs 5.1 Use of Content and Message IDs
skipping to change at page 16, line 42 skipping to change at page 16, line 43
The [iCAL] specification makes frequent use of the URI for data types The [iCAL] specification makes frequent use of the URI for data types
in properties such as "DESCRIPTION", "ATTACH", "CONTACT" and others. in properties such as "DESCRIPTION", "ATTACH", "CONTACT" and others.
Two forms of URIs are Message ID (MID) and Content ID (CID). These Two forms of URIs are Message ID (MID) and Content ID (CID). These
are defined in [RFC-2392]. Although [RFC-2392] allows referencing are defined in [RFC-2392]. Although [RFC-2392] allows referencing
messages or MIME body parts in other MIME entities or stores, it is messages or MIME body parts in other MIME entities or stores, it is
strongly recommended that iMIP implementations include all referenced strongly recommended that iMIP implementations include all referenced
messages and body parts in a single MIME entity. Simply put, if an messages and body parts in a single MIME entity. Simply put, if an
iCalendar object contains CID or MID references to other messages or iCalendar object contains CID or MID references to other messages or
body parts, implementations should ensure that these messages and/or body parts, implementations should ensure that these messages and/or
body parts are transmitted with the iCalendar object. If they are not body parts are transmitted with the iCalendar object. If they are not
there is no guarantee that the receiving "CU" will have the access or there is no guarantee that the receiving CUA will have the access or
the authorization to view those objects. the authorization to view those objects.
6 References 6 References
6.1 Normative References 6.1 Normative References
[iCAL] Dawson, F. and D. Stenerson, "Internet Calendaring and [iCAL] Dawson, F. and D. Stenerson, "Internet Calendaring and
Scheduling Core Object Specification - iCalendar", RFC 2445, November Scheduling Core Object Specification - iCalendar", RFC 2445, November
1998. 1998.
[iTIP] Silverberg, S., Mansour, S., Dawson, F. and R. Hopson, [iTIP] Daboo, C., "iCalendar Transport-Independent
"iCalendar Transport-Independent Interoperability Protocol (iTIP): Interoperability Protocol (iTIP)", work in progress, draft-ietf-
Scheduling Events, Busy Time, To-dos and Journal Entries", RFC 2446, calsify-2446bis-XX.txt (Updates RFC 2446)
November 1998.
[RFC-2822] Resnick, P., "Internet Message Format", RFC 2822, April [RFC-2822] Resnick, P., "Internet Message Format", RFC 2822, April
2001. 2001.
[RFC-1847] Galvin, J., Murphy, S., Crocker, S. and N. Freed, [RFC-1847] Galvin, J., Murphy, S., Crocker, S. and N. Freed,
"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
skipping to change at page 17, line 50 skipping to change at page 17, line 49
[RFC-2049] Freed, N. and N. Borenstein, "Multipurpose Internet Mail [RFC-2049] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part Five: Conformance Criteria and Examples", RFC Extensions (MIME) Part Five: Conformance Criteria and Examples", RFC
2049, November 1996. 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.
6.2 Informative References [UTF-8] Yergeau, F., "UTF-8, a transformation format of ISO 10646",
STD 63, RFC 3629, November 2003.
[CHST] Character Sets, http://www.iana.org/ 6.2 Informative References
assignments/character-sets [8BITMIME] Klensin, J., Freed, N., Rose, M., Stefferud, E., and D.
Crocker, "SMTP Service Extension for 8bit-MIMEtransport", RFC 1652,
July 1994.
7 Editor's Addresses 7 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
8. Full Copyright Statement 8. Full Copyright Statement
Copyright (C) The Internet Society (2005). Copyright (C) The Internet Society (2006).
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 AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
 End of changes. 17 change blocks. 
48 lines changed or deleted 55 lines changed or added

This html diff was produced by rfcdiff 1.29, available from http://www.levkowetz.com/ietf/tools/rfcdiff/