draft-ietf-calsify-rfc2447bis-05.txt   draft-ietf-calsify-rfc2447bis-06.txt 
INTERNET-DRAFT A. Melnikov INTERNET-DRAFT A. Melnikov
Document: draft-ietf-calsify-rfc2447bis-05.txt Editor Document: draft-ietf-calsify-rfc2447bis-06.txt Editor
Intended status: Standard Track June 9, 2008 Intended status: Standard Track September 6, 2009
Expires: December 2008
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 This Internet-Draft is submitted to IETF in full conformance with the
applicable patent or other IPR claims of which he or she is aware provisions of BCP 78 and BCP 79. This document may contain material
have been or will be disclosed, and any of which he or she becomes from IETF Documents or IETF Contributions published or made publicly
aware will be disclosed, in accordance with Section 6 of BCP 79. 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.
Internet-Drafts are working documents of the Internet Internet-Drafts are working documents of the Internet
Engineering Task Force (IETF), its areas, and its Engineering Task Force (IETF), its areas, and its
working groups. Note that other groups may also distribute working groups. Note that other groups may also distribute
working documents as Internet-Drafts. working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of Internet-Drafts are draft documents valid for a maximum of
six months and may be updated, replaced, or obsoleted by six months and may be updated, replaced, or obsoleted by
other documents at any time. It is inappropriate to use other documents at any time. It is inappropriate to use
Internet-Drafts as reference material or to cite them other Internet-Drafts as reference material or to cite them other
than as "work in progress." 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/1id-abstracts.html 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) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved.
Copyright (C) The IETF Trust (2008). This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.
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 5322, RFC 2045, RFC 2046, RFC 2047
RFC 2047 and RFC 2049. 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: The issue tracker for the Calsify WG is located at:
<http://www.ofcourseimright.com/cgi-bin/roundup/calsify> <http://www.ofcourseimright.com/cgi-bin/roundup/calsify>
Table of Contents Table of Contents
skipping to change at page 3, line 17 skipping to change at page 3, line 17
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
2.2.2 Authentication ..............................................5 2.2.2 Authentication ..............................................5
2.2.3 Confidentiality .............................................5 2.2.3 Confidentiality .............................................5
2.3 [RFC-2822] ADDRESSES ............................................5 2.3 [RFC-5322] ADDRESSES ............................................5
2.4 CONTENT TYPE ....................................................5 2.4 CONTENT TYPE ....................................................5
2.5 CONTENT-TRANSFER-ENCODING .......................................6 2.5 CONTENT-TRANSFER-ENCODING .......................................6
2.6 CONTENT-DISPOSITION .............................................6 2.6 CONTENT-DISPOSITION .............................................6
3 SECURITY CONSIDERATIONS.............................................7 3 SECURITY CONSIDERATIONS.............................................7
4 EXAMPLES............................................................8 4 EXAMPLES............................................................8
4.1 SINGLE COMPONENT WITH AN ATTACH PROPERTY ........................8 4.1 SINGLE COMPONENT WITH AN ATTACH PROPERTY ........................8
4.2 USING MULTIPART ALTERNATIVE FOR LOW FIDELITY CLIENTS ............8 4.2 USING MULTIPART ALTERNATIVE FOR LOW FIDELITY CLIENTS ............8
4.3 SINGLE COMPONENT WITH AN ATTACH PROPERTY AND INLINE ATTACHMENT ..9 4.3 SINGLE COMPONENT WITH AN ATTACH PROPERTY AND INLINE ATTACHMENT ..9
4.4 MULTIPLE SIMILAR COMPONENTS ....................................10 4.4 MULTIPLE SIMILAR COMPONENTS ....................................10
4.5 MULTIPLE MIXED COMPONENTS ......................................11 4.5 MULTIPLE MIXED COMPONENTS ......................................11
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) [iTIP] over MIME as defined in [RFC-2822] and Protocol (iTIP) [iTIP] over MIME as defined in [RFC-5322] and
[RFC-2045]. [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.
skipping to change at page 5, line 7 skipping to change at page 5, line 7
"ATTENDEE" property refers to the iCalendar property used to convey "ATTENDEE" property refers to the iCalendar property used to convey
the calendar address of a calendar user. the calendar address of a calendar user.
Property parameters defined by [iCAL] are referred to with lower Property parameters defined by [iCAL] are referred to with lower
case, quoted-strings of text, followed by the word "parameter". For case, quoted-strings of text, followed by the word "parameter". For
example, "value" parameter refers to the iCalendar property parameter example, "value" parameter refers to the iCalendar property parameter
used to override the default data type for a property value. used to override the default data type for a property value.
1.3 Terminology 1.3 Terminology
The email terms used in this memo are defined in [RFC-2822] and The email terms used in this memo are defined in [RFC-5322] and
[RFC-2045]. The calendaring and scheduling terms used in this memo [RFC-2045]. The calendaring and scheduling terms used in this memo
are defined in [iCAL] and [iTIP]. are defined in [iCAL] and [iTIP].
2 MIME Message Format Binding 2 MIME Message Format Binding
This section defines the message binding to the MIME electronic mail This section defines the message binding to the MIME electronic mail
transport. transport.
The sections below refer to the "originator" and the "respondent" of The sections below refer to the "originator" and the "respondent" of
an iMIP message. Typically, the originator is the "Organizer" of an an iMIP message. Typically, the originator is the "Organizer" of an
event. The respondent is an "Attendee" of the event. event. The respondent is an "Attendee" of the event.
The [RFC-2822] "Reply-To" header typically contains the email address The [RFC-5322] "Reply-To" header typically contains the email address
of the originator or respondent of an event. However, this cannot be of the originator or respondent of an event. However, this cannot be
guaranteed as Mail User Agents (MUA) are not required to enforce iMIP guaranteed as Mail User Agents (MUA) are not required to enforce iMIP
semantics. semantics.
2.1 MIME Media Type 2.1 MIME Media Type
A MIME entity containing content information formatted according to A MIME entity containing content information formatted according to
this document will be referenced as a "text/calendar" content type. this document will be referenced as a "text/calendar" content type.
It is assumed that this content type will be transported through a It is assumed that this content type will be transported through a
MIME electronic mail transport. MIME electronic mail transport.
skipping to change at page 6, line 31 skipping to change at page 6, line 31
Authentication is possible only on messages that have been signed. Authentication is possible only on messages that have been signed.
Authenticating an unsigned message may not be reliable. Authenticating an unsigned message may not be reliable.
2.2.3 Confidentiality 2.2.3 Confidentiality
To ensure confidentiality using iMIP implementations should utilize To ensure confidentiality using iMIP implementations should utilize
encryption compliant with [RFC-1847]. The protocol does not restrict encryption compliant with [RFC-1847]. The protocol does not restrict
a "Calendar User Agent" (CUA) from forwarding iCalendar objects to a "Calendar User Agent" (CUA) from forwarding iCalendar objects to
other users or agents. other users or agents.
2.3 [RFC-2822] Addresses 2.3 [RFC-5322] Addresses
The calendar address specified within the "ATTENDEE" property in an The calendar address specified within the "ATTENDEE" property in an
iCalendar object MUST be a fully qualified, [RFC-2822] address iCalendar object MUST be a fully qualified, [RFC-5322] address
specification for the corresponding "Organizer" or "Attendee" of the specification for the corresponding "Organizer" or "Attendee" of the
"VEVENT" or "VTODO". "VEVENT" or "VTODO".
Because [iTIP] does not preclude "Attendees" from forwarding Because [iTIP] does not preclude "Attendees" from forwarding
"VEVENTS" or "VTODOS" to others, the [RFC-2822] "Sender" value may "VEVENTS" or "VTODOS" to others, the [RFC-5322] "Sender" value may
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-5322] "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 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
skipping to change at page 8, line 17 skipping to change at page 8, line 17
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 can't be represented in the US-ASCII character set. characters that can't be represented in the US-ASCII character set.
For example: For example:
From: user1@example.com To: user2@example.com Subject: Phone From: user1@example.com
Conference Mime-Version: 1.0 Date: Wed, 07 May 2008 21:30:25 +0400 To: user2@example.com
Message-ID: <4821E731.5040506@laptop1.example.com> Content-Type: Subject: Phone Conference
text/calendar; method=REQUEST; charset=UTF-8 Content-Transfer- Mime-Version: 1.0
Encoding: quoted-printable 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:-//ACME/DesktopCalendar//EN METHOD:REQUEST BEGIN:VCALENDAR
VERSION:2.0 BEGIN:VEVENT ORGANIZER:mailto:user1@example.com PRODID:-//ACME/DesktopCalendar//EN
METHOD:REQUEST
VERSION:2.0
BEGIN:VEVENT
ORGANIZER:mailto:user1@example.com
ATTENDEE;ROLE=CHAIR;ATTSTAT=ACCEPTED:mailto:user1@example.com ATTENDEE;ROLE=CHAIR;ATTSTAT=ACCEPTED:mailto:user1@example.com
ATTENDEE;RSVP=YES;CUTYPE=INDIVIDUAL:mailto:user2@example.com ATTENDEE;RSVP=YES;CUTYPE=INDIVIDUAL:mailto:user2@example.com
DTSTAMP:20080507T170000Z DTSTART:20080701T160000Z DTSTAMP:20080507T170000Z
DTEND:20080701T163000Z SUMMARY:Phone call to discuss your last visit 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= 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 =B2=D0=BE=D0=BB=D0=B5=D0=BD =D0=BF=D0=BE=D0=B5=D0=B7=D0=B4=D0=BA=D0=BE=D0=
=D0=BF=D0=BE=D0=B5=D0=B7=D0=B4=D0=BA=D0=BE=D0= =B9?
=B9? UID:calsvr.example.com-8739701987387998 SEQUENCE:0 UID:calsvr.example.com-8739701987387998
STATUS:TENTATIVE END:VEVENT END:VCALENDAR SEQUENCE:0
STATUS:TENTATIVE
END:VEVENT
END:VCALENDAR
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
define a file name for an iCalendar object. However, the handling of define a file name for an iCalendar object. However, the handling of
a MIME part MUST be based on its [RFC-2045] "Content-Type" and not on a MIME part MUST be based on its [RFC-2045] "Content-Type" and not on
the extension specified in the "Content-Disposition", as different the extension specified in the "Content-Disposition", as different
email malware is known to trick User Agents into misinterpreting email malware is known to trick User Agents into misinterpreting
content of messages by specifying a file extension in the Content- content of messages by specifying a file extension in the Content-
Disposition header field that doesn't correspond to the value of Disposition header field that doesn't correspond to the value of
skipping to change at page 18, line 23 skipping to change at page 19, line 23
7.1 Normative References 7.1 Normative References
[iCAL] Desruisseaux, B., (Ed.), "Internet Calendaring and [iCAL] Desruisseaux, B., (Ed.), "Internet Calendaring and
Scheduling Core Object Specification (iCalendar)", work in progress, Scheduling Core Object Specification (iCalendar)", work in progress,
draft-ietf-calsify-rfc2445bis-XX.txt (Updated RFC 2445) draft-ietf-calsify-rfc2445bis-XX.txt (Updated RFC 2445)
[iTIP] Daboo, C., "iCalendar Transport-Independent [iTIP] Daboo, C., "iCalendar Transport-Independent
Interoperability Protocol (iTIP)", work in progress, draft-ietf- Interoperability Protocol (iTIP)", work in progress, draft-ietf-
calsify-2446bis-XX.txt (Updates RFC 2446) calsify-2446bis-XX.txt (Updates RFC 2446)
[RFC-2822] Resnick, P., "Internet Message Format", RFC 2822, April [RFC-5322] Resnick, P., "Internet Message Format", RFC 5322, October
2001. 2008.
[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
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
skipping to change at page 21, line 5 skipping to change at page 22, line 5
Alexey Melnikov (editor) Alexey Melnikov (editor)
Isode Ltd Isode Ltd
5 Castle Business Village 5 Castle Business Village
36 Station Road 36 Station Road
Hampton, Middlesex TW12 2BX Hampton, Middlesex TW12 2BX
UK UK
Email: Alexey.Melnikov@isode.com Email: Alexey.Melnikov@isode.com
9. Full Copyright Statement
Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
10. Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
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
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Appendix A. Changes since RFC 2447. Appendix A. Changes since RFC 2447.
Updated references. Split them into Normative and Informative. Updated references. Split them into Normative and Informative.
Updated examples to use example.com/example.net domains. Updated examples to use example.com/example.net domains.
Corrected usage of RFC 2119 language. Corrected usage of RFC 2119 language.
Clarified that charset=UTF-8 is required, unless the calendar can be Clarified that charset=UTF-8 is required, unless the calendar can be
entirely represented in US-ASCII. entirely represented in US-ASCII.
 End of changes. 21 change blocks. 
81 lines changed or deleted 59 lines changed or added

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