draft-ietf-calsify-rfc2447bis-07.txt   draft-ietf-calsify-rfc2447bis-08.txt 
INTERNET-DRAFT A. Melnikov INTERNET-DRAFT A. Melnikov
Document: draft-ietf-calsify-rfc2447bis-07.txt Editor Document: draft-ietf-calsify-rfc2447bis-08.txt Editor
Intended status: Standard Track October 9, 2009 Intended status: Standard Track January 30, 2010
Expires: April 2010 Expires: June 2010
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 4 skipping to change at page 2, line 4
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 Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of Provisions Relating to IETF Documents
publication of this document (http://trustee.ietf.org/license-info). (http://trustee.ietf.org/license-info) in effect on the date of
Please review these documents carefully, as they describe your rights publication of this document. Please review these documents
and restrictions with respect to this document. 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 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 (iCAL) are Calendaring entries defined by the iCalendar Object Model (iCalendar)
wrapped using constructs from RFC 5322, RFC 2045, RFC 2046, RFC 2047 are wrapped using constructs from RFC 5322, RFC 2045, RFC 2046, RFC
and RFC 2049, and then transported over SMTP. 2047 and RFC 2049, and then transported over SMTP.
This document is a product of the Calendaring and Scheduling This document is a product of the Calendaring and Scheduling
Standards Simplification (calsify) working group. More information Standards Simplification (calsify) working group. More information
about the IETF CALSIFY working group activities can be found on the about the IETF CALSIFY working group activities can be found on the
IETF web site at <http://www.ietf.org/html.charters/calsify- IETF web site at <http://www.ietf.org/html.charters/calsify-
charter.html>. 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>
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-5322] ADDRESSES ............................................5 2.3 EMAIL 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 40 skipping to change at page 3, line 40
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-5322] and Protocol (iTIP) [iTIP] over Internet email (using MIME) as defined in
[RFC-2045]. [RFC-5322] 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 5, line 16 skipping to change at page 5, line 16
The email terms used in this memo are defined in [RFC-5322] 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 "recipient" of
an iMIP message. Typically, the originator is the "Organizer" of an an iMIP message. In the case of a "request" method, the originator is
event and the respondent is an "Attendee" of the event. 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 [RFC-5322] "Reply-To" header typically contains the email address The [RFC-5322] "Reply-To" header field typically contains the email
of the originator or respondent of an event. However, this cannot be address of the originator of the scheduling message. <<However, this
guaranteed as Mail User Agents (MUA) are not required to enforce iMIP cannot be guaranteed as Mail User Agents (MUA) are not required to
semantics. enforce iMIP 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.
2.2 Security 2.2 Security
skipping to change at page 6, line 6 skipping to change at page 6, line 6
In [iTIP] messages, only the "Organizer" is authorized to modify or In [iTIP] messages, only the "Organizer" is authorized to modify or
cancel calendar entries she organizes. That is, spoof@xyz.example.net cancel calendar entries she organizes. That is, spoof@xyz.example.net
is not allowed to modify or cancel a meeting that was organized by is not allowed to modify or cancel a meeting that was organized by
a@example.com. Furthermore, only the respondent has the authorization a@example.com. Furthermore, only the respondent has the authorization
to indicate their status to the "Organizer". That is, the "Organizer" to indicate their status to the "Organizer". That is, the "Organizer"
must ignore an [iTIP] message from spoof@xyz.example.net that must ignore an [iTIP] message from spoof@xyz.example.net that
declines a meeting invitation for b@example.com. declines a meeting invitation for b@example.com.
Implementations of iMIP SHOULD verify the authenticity of the creator Implementations of iMIP SHOULD verify the authenticity of the creator
of an iCalendar object before taking any action. The methods for of an iCalendar object before taking any action. Methods for doing
doing this are presented later in this document. this are presented later in this document.
[RFC-1847] Message flow in iTIP supports someone working on behalf of [RFC-1847] Message flow in iTIP supports someone working on behalf of
a "Calendar User" through use of the "sent-by" parameter that is a "Calendar User" through use of the "sent-by" parameter that is
associated with the "ATTENDEE" and "ORGANIZER" properties. However, associated with the "ATTENDEE" and "ORGANIZER" properties. However,
there is no mechanism to verify whether or not a "Calendar User" has there is no mechanism to verify whether or not a "Calendar User" has
authorized someone to work on their behalf. It is left to authorized someone to work on their behalf. It is left to
implementations to provide mechanisms for the "Calendar Users" to implementations to provide mechanisms for the "Calendar Users" to
make that decision. make that decision.
2.2.2 Authentication 2.2.2 Authentication
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-5322] Addresses 2.3 Email Addresses
The calendar address specified within the "ATTENDEE" property in an The calendar address specified within the "ORGANIZER" and "ATTENDEE"
iCalendar object MUST be a fully qualified, [RFC-5322] address properties in an iCalendar object MUST be a proper "mailto:" [MAILTO]
specification for the corresponding "Organizer" or "Attendee" of the URI specification for the corresponding "Organizer" or "Attendee" of
"VEVENT" or "VTODO". the "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-5322] "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-5322] "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 Header Field
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 include the type MIME parameter "method". The value MUST be the same
(ignoring case) as the value of the "METHOD" calendar property within (ignoring case) as the value of the "METHOD" property within the
the iCalendar object. iCalendar object.
Note 1: A MIME message containing multiple iCalendar objects with Note 1: A MIME message containing multiple iCalendar objects with
different method values must be further encapsulated with a different method values MUST be further encapsulated with a
"multipart/mixed" MIME entity. This will allow each of the iCalendar "multipart/mixed" MIME entity. This will allow each of the iCalendar
objects to be encapsulated within their own "text/calendar" MIME objects to be encapsulated within their own "text/calendar" MIME
entity. entity.
Note 2: A MIME body part of "text/calendar" "Content-Type" that lacks 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 the "method" parameter is not considered to be an iMIP body part and
thus is not subject to the requirements specified in this document. 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 according to [RFC-2046] is US-ASCII. Thus a "text/*" MIME entity according to [RFC-2046] is US-ASCII. Thus a
"charset" parameter MUST be present if the iCalendar object contains "charset" MIME parameter MUST be present if the iCalendar object
characters that can't be represented in US-ASCII character set. contains characters that can't be represented in US-ASCII character
[RFC-2046] discusses the selection of an appropriate "charset" value. set and, as specified in [iCAL], it MUST have the value "UTF-8".
The optional "component" parameter defines the iCalendar component The optional "component" MIME parameter defines the iCalendar
type contained within the iCalendar object. component 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
The "text/calendar" content type allows for the scheduling message The "text/calendar" content type allows for the scheduling message
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-
skipping to change at page 7, line 47 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 "multipart/alternative" MUST NOT be used to represent two Note that "multipart/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.
CUAs can use language <<add ref>> and other parameters to pick a CUAs can use other MIME parameters of the Content-Type header field,
"text/calendar" part if a "multipart/alternative" MIME message as well as a language specified in the Content-Language header field
contains more than one "text/calendar" part. [RFC-3282], 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 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 Header Field
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 From: user1@example.com
To: user2@example.com To: user2@example.com
Subject: Phone Conference Subject: Phone Conference
Mime-Version: 1.0 Mime-Version: 1.0
Date: Wed, 07 May 2008 21:30:25 +0400 Date: Wed, 07 May 2008 21:30:25 +0400
Message-ID: <4821E731.5040506@laptop1.example.com> Message-ID: <4821E731.5040506@laptop1.example.com>
Content-Type: text/calendar; method=REQUEST; charset=UTF-8 Content-Type: text/calendar; method=REQUEST; charset=UTF-8
Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable
BEGIN:VCALENDAR BEGIN:VCALENDAR
PRODID:-//ACME/DesktopCalendar//EN PRODID:-//Example/ExampleCalendarClient//EN
METHOD:REQUEST METHOD:REQUEST
VERSION:2.0 VERSION:2.0
BEGIN:VEVENT BEGIN:VEVENT
ORGANIZER:mailto:user1@example.com ORGANIZER:mailto:user1@example.com
ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:mailto:user1@example.com ATTENDEE;ROLE=CHAIR;PARTSTAT=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 DTSTAMP:20080507T170000Z
DTSTART:20080701T160000Z DTSTART:20080701T160000Z
DTEND:20080701T163000Z DTEND:20080701T163000Z
SUMMARY:Phone call to discuss your last visit 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 =D0=BF=D0=BE=D0=B5=D0=B7=D0=B4=D0=BA=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? =B9?
UID:calsvr.example.com-8739701987387998 UID:calsvr.example.com-8739701987387998
SEQUENCE:0 SEQUENCE:0
STATUS:TENTATIVE STATUS:TENTATIVE
END:VEVENT END:VEVENT
END:VCALENDAR END:VCALENDAR
2.6 Content-Disposition 2.6 Content-Disposition Header Field
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
Content-Type header field. Content-Type header field.
skipping to change at page 10, line 35 skipping to change at page 10, line 35
organizer>> organizer>>
2. Using the security mechanism compliant 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 either an "ATTENDEE" property or to the 3. Correlate the signer to either an "ATTENDEE" property or to the
"ORGANIZER" property in the iCalendar object, based on the method and "ORGANIZER" property in the iCalendar object, based on the method and
the calendar component specified in the iCalendar object, as defined the calendar component specified in the iCalendar object, as defined
in Section 3 of [iTIP]. If the signer cannot be correlated to an in Section 1.4 of [iTIP]. If the signer cannot be correlated to an
"ATTENDEE"/"ORGANIZER" property (or is not authorized to act on her "ATTENDEE"/"ORGANIZER" property (or is not authorized to act on her
behalf), ignore the message. behalf), ignore the message.
4. Determine whether or not the "ATTENDEE"/"ORGANIZER" is authorized 4. Determine whether or not the "ATTENDEE"/"ORGANIZER" is authorized
to perform the operation as defined by [iTIP]. If the conditions are to perform the operation as defined by [iTIP]. If the conditions are
not met, ignore the message. not met, ignore the message.
5. If all the above conditions are met, the message can be processed. 5. If all the above conditions are met, the message can be processed.
[RFC-1847] signing also protects against malicious changes in [RFC-1847] signing also protects against malicious changes in
skipping to change at page 12, line 20 skipping to change at page 12, line 20
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
Mime-Version: 1.0 Mime-Version: 1.0
Content-Type: text/calendar; method=REQUEST; charset=US-ASCII Content-Type: text/calendar; method=REQUEST; charset=US-ASCII
Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit
BEGIN:VCALENDAR BEGIN:VCALENDAR
PRODID:-//ACME/DesktopCalendar//EN PRODID:-//Example/ExampleCalendarClient//EN
METHOD:REQUEST METHOD:REQUEST
VERSION:2.0 VERSION:2.0
BEGIN:VEVENT BEGIN:VEVENT
ORGANIZER:mailto:sman@netscape.example.com ORGANIZER:mailto:sman@netscape.example.com
ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:mailto:sman@netscape.example.com ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:mailto:sman@netscape.example.com
ATTENDEE;RSVP=YES:mailto:stevesil@microsoft.example.com ATTENDEE;RSVP=YES:mailto:stevesil@microsoft.example.com
DTSTAMP:19970611T190000Z DTSTAMP:19970611T190000Z
DTSTART:19970701T210000Z DTSTART:19970701T210000Z
DTEND:19970701T230000Z DTEND:19970701T230000Z
SUMMARY:Phone Conference SUMMARY:Phone Conference
skipping to change at page 13, line 17 skipping to change at page 13, line 17
When: 7/1/1997 10:00AM PDT - 7/1/97 10:30AM PDT When: 7/1/1997 10:00AM PDT - 7/1/97 10:30AM PDT
Where: Where:
Organizer: foo1@example.com Organizer: foo1@example.com
Summary: Phone Conference Summary: Phone Conference
--01BD3665.3AF0D360 --01BD3665.3AF0D360
Content-Type: text/calendar; method=REQUEST; charset=US-ASCII Content-Type: text/calendar; method=REQUEST; charset=US-ASCII
Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit
BEGIN:VCALENDAR BEGIN:VCALENDAR
PRODID:-//ACME/DesktopCalendar//EN PRODID:-//Example/ExampleCalendarClient//EN
METHOD:REQUEST METHOD:REQUEST
VERSION:2.0 VERSION:2.0
BEGIN:VEVENT BEGIN:VEVENT
ORGANIZER:mailto:foo1@example.com ORGANIZER:mailto:foo1@example.com
ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:mailto:foo1@example.com ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:mailto:foo1@example.com
ATTENDEE;RSVP=YES;CUTYPE=INDIVIDUAL:mailto:foo2@example.com ATTENDEE;RSVP=YES;CUTYPE=INDIVIDUAL:mailto:foo2@example.com
DTSTAMP:19970611T190000Z DTSTAMP:19970611T190000Z
DTSTART:19970701T170000Z DTSTART:19970701T170000Z
DTEND:19970701T173000Z DTEND:19970701T173000Z
SUMMARY:Phone Conference SUMMARY:Phone Conference
UID:calsvr.example.com-8739701987387771 UID:calsvr.example.com-8739701987387771
SEQUENCE:0 SEQUENCE:0
STATUS:CONFIRMED STATUS:CONFIRMED
END:VEVENT END:VEVENT
END:VCALENDAR END:VCALENDAR
--01BD3665.3AF0D360 --01BD3665.3AF0D360
4.3 Single Component With An ATTACH Property and Inline Attachment 4.3 Single Component With An ATTACH Property
This example shows how a message containing an iCalendar object This example shows how a message containing an iCalendar object
references an attached document. The reference is made using a references an attached document. The reference is made using a
Content-id (CID). Thus, the iCalendar object and the document are Content-id (CID). Thus, the iCalendar object and the document are
packaged in a multipart/related encapsulation. packaged in a multipart/related encapsulation.
From: foo1@example.com From: foo1@example.com
To: foo2@example.com To: foo2@example.com
Subject: Phone Conference Subject: Phone Conference
Mime-Version: 1.0 Mime-Version: 1.0
Content-Type: multipart/related; boundary="boundary-example-1" Content-Type: multipart/related; boundary="boundary-example-1"
--boundary-example-1 --boundary-example-1
Content-Type: text/calendar; method=REQUEST; charset=US-ASCII Content-Type: text/calendar; method=REQUEST; charset=US-ASCII
Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename="event.ics" Content-Disposition: attachment; filename="event.ics"
BEGIN:VCALENDAR BEGIN:VCALENDAR
PRODID:-//ACME/DesktopCalendar//EN PRODID:-//Example/ExampleCalendarClient//EN
METHOD:REQUEST METHOD:REQUEST
VERSION:2.0 VERSION:2.0
BEGIN:VEVENT BEGIN:VEVENT
ORGANIZER:mailto:foo1@example.com ORGANIZER:mailto:foo1@example.com
ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:mailto:foo1@example.com ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:mailto:foo1@example.com
ATTENDEE;RSVP=YES;CUTYPE=INDIVIDUAL:mailto:foo2@example.com ATTENDEE;RSVP=YES;CUTYPE=INDIVIDUAL:mailto:foo2@example.com
DTSTAMP:19970611T190000Z DTSTAMP:19970611T190000Z
DTSTART:19970701T180000Z DTSTART:19970701T180000Z
DTEND:19970701T183000Z DTEND:19970701T183000Z
SUMMARY:Phone Conference SUMMARY:Phone Conference
skipping to change at page 15, line 5 skipping to change at page 15, line 5
iCalendar object when the METHOD is the same for each component. iCalendar object when the METHOD is the same for each component.
From: foo1@example.com From: foo1@example.com
To: foo2@example.com To: foo2@example.com
Subject: Summer Company Holidays Subject: Summer Company Holidays
Mime-Version: 1.0 Mime-Version: 1.0
Content-Type: text/calendar; method=PUBLISH; charset=US-ASCII Content-Type: text/calendar; method=PUBLISH; charset=US-ASCII
Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename="event.ics" Content-Disposition: attachment; filename="event.ics"
BEGIN:VCALENDAR BEGIN:VCALENDAR
PRODID:-//ACME/DESKTOPCALENDAR//EN PRODID:-//Example/ExampleCalendarClient//EN
METHOD:PUBLISH METHOD:PUBLISH
VERSION:2.0 VERSION:2.0
BEGIN:VEVENT BEGIN:VEVENT
ORGANIZER:MAILTO:FOO1@EXAMPLE.COM ORGANIZER:MAILTO:FOO1@EXAMPLE.COM
DTSTAMP:19970611T150000Z DTSTAMP:19970611T150000Z
DTSTART:19970701T150000Z DTSTART:19970701T150000Z
DTEND:19970701T230000Z DTEND:19970701T230000Z
SUMMARY:Company Picnic SUMMARY:Company Picnic
DESCRIPTION:Food and drink will be provided DESCRIPTION:Food and drink will be provided
UID:CALSVR.EXAMPLE.COM-873970198738777-1 UID:CALSVR.EXAMPLE.COM-873970198738777-1
skipping to change at page 16, line 5 skipping to change at page 16, line 5
Mime-Version: 1.0 Mime-Version: 1.0
Content-Type: multipart/mixed;boundary="--FEE3790DC7E35189CA67CE2C" Content-Type: multipart/mixed;boundary="--FEE3790DC7E35189CA67CE2C"
This is a multi-part message in MIME format. This is a multi-part message in MIME format.
----FEE3790DC7E35189CA67CE2C ----FEE3790DC7E35189CA67CE2C
Content-Type: text/calendar; method=REQUEST; charset=US-ASCII Content-Type: text/calendar; method=REQUEST; charset=US-ASCII
Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename="event1.ics" Content-Disposition: attachment; filename="event1.ics"
BEGIN:VCALENDAR BEGIN:VCALENDAR
PRODID:-//ACME/DesktopCalendar//EN PRODID:-//Example/ExampleCalendarClient//EN
METHOD:REQUEST METHOD:REQUEST
VERSION:2.0 VERSION:2.0
BEGIN:VEVENT BEGIN:VEVENT
ORGANIZER:mailto:foo1@example.com ORGANIZER:mailto:foo1@example.com
ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:mailto:foo1@example.com ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:mailto:foo1@example.com
ATTENDEE;RSVP=YES;CUTYPE=INDIVIDUAL:mailto:foo2@example.com ATTENDEE;RSVP=YES;CUTYPE=INDIVIDUAL:mailto:foo2@example.com
DTSTAMP:19970611T190000Z DTSTAMP:19970611T190000Z
DTSTART:19970701T210000Z DTSTART:19970701T210000Z
DTEND:19970701T230000Z DTEND:19970701T230000Z
SUMMARY:Phone Conference SUMMARY:Phone Conference
skipping to change at page 16, line 29 skipping to change at page 16, line 29
STATUS:CONFIRMED STATUS:CONFIRMED
END:VEVENT END:VEVENT
END:VCALENDAR END:VCALENDAR
----FEE3790DC7E35189CA67CE2C ----FEE3790DC7E35189CA67CE2C
Content-Type: text/calendar; method=REQUEST; charset=US-ASCII Content-Type: text/calendar; method=REQUEST; charset=US-ASCII
Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename="todo1.ics" Content-Disposition: attachment; filename="todo1.ics"
BEGIN:VCALENDAR BEGIN:VCALENDAR
PRODID:-//ACME/DesktopCalendar//EN PRODID:-//Example/ExampleCalendarClient//EN
METHOD:REQUEST METHOD:REQUEST
VERSION:2.0 VERSION:2.0
BEGIN:VTODO BEGIN:VTODO
DUE:19970701T160000Z DUE:19970701T160000Z
ORGANIZER:mailto:foo1@example.com ORGANIZER:mailto:foo1@example.com
ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:mailto:foo1@example.com ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:mailto:foo1@example.com
ATTENDEE;RSVP=YES:mailto:foo2@example.com ATTENDEE;RSVP=YES:mailto:foo2@example.com
SUMMARY:Phone Conference SUMMARY:Phone Conference
DESCRIPTION:Discuss a new location for the company picnic DESCRIPTION:Discuss a new location for the company picnic
UID:calsvr.example.com-td-8739701987387773 UID:calsvr.example.com-td-8739701987387773
skipping to change at page 17, line 39 skipping to change at page 17, line 39
Summary: Let's discuss the attached document Summary: Let's discuss the attached document
----00FEE3790DC7E35189CA67CE2C00 ----00FEE3790DC7E35189CA67CE2C00
Content-Type: text/calendar; method=REQUEST; charset=US-ASCII; Content-Type: text/calendar; method=REQUEST; charset=US-ASCII;
Component=vevent Component=vevent
Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename="event.ics" Content-Disposition: attachment; filename="event.ics"
BEGIN:VCALENDAR BEGIN:VCALENDAR
PRODID:-//ACME/DesktopCalendar//EN PRODID:-//Example/ExampleCalendarClient//EN
METHOD:REQUEST METHOD:REQUEST
VERSION:2.0 VERSION:2.0
BEGIN:VEVENT BEGIN:VEVENT
ORGANIZER:foo1@example.com ORGANIZER:foo1@example.com
ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED: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:foo2@example.com
ATTENDEE;RSVP=YES;CUTYPE=INDIVIDUAL:mailto:foo3@example.com ATTENDEE;RSVP=YES;CUTYPE=INDIVIDUAL:mailto:foo3@example.com
DTSTAMP:19970611T190000Z DTSTAMP:19970611T190000Z
DTSTART:19970621T170000Z DTSTART:19970621T170000Z
DTEND:199706211T173000Z DTEND:199706211T173000Z
skipping to change at page 19, line 25 skipping to change at page 19, line 25
[iCAL] Desruisseaux, B., (Ed.), "Internet Calendaring and [iCAL] Desruisseaux, B., (Ed.), "Internet Calendaring and
Scheduling Core Object Specification (iCalendar)", RFC 5545. Scheduling Core Object Specification (iCalendar)", RFC 5545.
[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-5322] Resnick, P., "Internet Message Format", RFC 5322, October [RFC-5322] Resnick, P., "Internet Message Format", RFC 5322, October
2008. 2008.
[MAILTO] Hoffmann, P., Masinter, L., and J. Zawinski, "The mailto URL
scheme", RFC 2368, June 1998.
[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
Extensions (MIME) - Part Two: Media Types", RFC 2046, November 1996. Extensions (MIME) - Part Two: Media Types", RFC 2046, November 1996.
skipping to change at page 21, line 5 skipping to change at page 20, line 13
July 1994. July 1994.
[RFC-2047] Moore, K., "Multipurpose Internet Mail Extensions (MIME) - [RFC-2047] Moore, K., "Multipurpose Internet Mail Extensions (MIME) -
Part Three: Message Header Extensions for Non-ASCII Text", RFC 2047, Part Three: Message Header Extensions for Non-ASCII Text", RFC 2047,
November 1996. November 1996.
[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-3282] Alvestrand, H., "Content Language Headers", RFC 3282, May
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
Hampton, Middlesex TW12 2BX Hampton, Middlesex TW12 2BX
UK UK
Email: Alexey.Melnikov@isode.com Email: Alexey.Melnikov@isode.com
 End of changes. 31 change blocks. 
53 lines changed or deleted 67 lines changed or added

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