RFC 5546
iCalendar Transport-Independent Interoperability Protocol (iTIP)
Pages: 133
Proposed Standard
→ Errata
Obsoletes: 2446
Updates: 5545
Updated by: 6638
Proposed Standard
→ Errata
Obsoletes: 2446
Updates: 5545
Updated by: 6638
Part 1 of 5 – Pages 1 to 13
Network Working Group C. Daboo, Ed. Request for Comments: 5546 Apple Inc. Obsoletes: 2446 December 2009 Updates: 5545 Category: Standards Track iCalendar Transport-Independent Interoperability Protocol (iTIP)Abstract
This document specifies a protocol that uses the iCalendar object specification to provide scheduling interoperability between different calendaring systems. This is done without reference to a specific transport protocol so as to allow multiple methods of communication between systems. Subsequent documents will define profiles of this protocol that use specific, interoperable methods of communication between systems. The iCalendar Transport-Independent Interoperability Protocol (iTIP) complements the iCalendar object specification by adding semantics for group scheduling methods commonly available in current calendaring systems. These scheduling methods permit two or more calendaring systems to perform transactions such as publishing, scheduling, rescheduling, responding to scheduling requests, negotiating changes, or canceling. Status of This Memo This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents 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. This document may contain material from IETF Documents or IETF Contributions published or made publicly 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.Table of Contents
1. Introduction and Overview .......................................5 1.1. Formatting Conventions .....................................5 1.2. Related Documents ..........................................6 1.3. Roles ......................................................6 1.4. Methods ....................................................7 2. Interoperability Models .........................................9 2.1. Application Protocol ......................................10 2.1.1. Scheduling State ...................................10 2.1.2. Delegation .........................................10 2.1.3. Acting on Behalf of Other Calendar Users ...........11 2.1.4. Component Revisions ................................11 2.1.5. Message Sequencing .................................12 3. Application Protocol Elements ..................................13 3.1. Common Component Restriction Tables .......................15 3.1.1. VCALENDAR ..........................................15 3.1.2. VTIMEZONE ..........................................15 3.1.3. VALARM .............................................17 3.2. Methods for VEVENT Calendar Components ....................17 3.2.1. PUBLISH ............................................18 3.2.2. REQUEST ............................................20 3.2.3. REPLY ..............................................25 3.2.4. ADD ................................................27 3.2.5. CANCEL .............................................29 3.2.6. REFRESH ............................................31 3.2.7. COUNTER ............................................33 3.2.8. DECLINECOUNTER .....................................35 3.3. Methods for VFREEBUSY Components ..........................37 3.3.1. PUBLISH ............................................37 3.3.2. REQUEST ............................................40 3.3.3. REPLY ..............................................42
3.4. Methods for VTODO Components ..............................44
3.4.1. PUBLISH ............................................44
3.4.2. REQUEST ............................................46
3.4.3. REPLY ..............................................51
3.4.4. ADD ................................................53
3.4.5. CANCEL .............................................55
3.4.6. REFRESH ............................................57
3.4.7. COUNTER ............................................59
3.4.8. DECLINECOUNTER .....................................61
3.5. Methods for VJOURNAL Components ...........................62
3.5.1. PUBLISH ............................................63
3.5.2. ADD ................................................64
3.5.3. CANCEL .............................................66
3.6. Status Replies ............................................68
3.7. Implementation Considerations .............................77
3.7.1. Working With Recurrence Instances ..................77
3.7.2. Attendee Property Considerations ...................78
3.7.3. Extension Tokens ...................................79
4. Examples .......................................................79
4.1. Published Event Examples ..................................79
4.1.1. A Minimal Published Event ..........................80
4.1.2. Changing a Published Event .........................80
4.1.3. Canceling a Published Event ........................81
4.1.4. A Rich Published Event .............................81
4.1.5. Anniversaries or Events Attached to Entire Days ....83
4.2. Group Event Examples ......................................83
4.2.1. A Group Event Request ..............................84
4.2.2. Reply to a Group Event Request .....................85
4.2.3. Update an Event ....................................85
4.2.4. Countering an Event Proposal .......................86
4.2.5. Delegating an Event ................................88
4.2.6. Delegate Accepts the Meeting .......................90
4.2.7. Delegate Declines the Meeting ......................91
4.2.8. Forwarding an Event Request ........................92
4.2.9. Cancel a Group Event ...............................92
4.2.10. Removing Attendees ................................93
4.2.11. Replacing the Organizer ...........................95
4.3. Busy Time Examples ........................................96
4.3.1. Publish Busy Time ..................................96
4.3.2. Request Busy Time ..................................96
4.3.3. Reply to a Busy Time Request .......................97
4.4. Recurring Event and Time Zone Examples ....................98
4.4.1. A Recurring Event Spanning Time Zones ..............98
4.4.2. Modify a Recurring Instance ........................99
4.4.3. Cancel an Instance ................................101
4.4.4. Cancel a Recurring Event ..........................101
4.4.5. Change All Future Instances .......................102
4.4.6. Add a New Instance to a Recurring Event ...........102
4.4.7. Add a New Series of Instances to a
Recurring Event ...................................103
4.4.8. Refreshing a Recurring Event ......................104
4.4.9. Counter an Instance of a Recurring Event ..........106
4.4.10. Error Reply to a Request .........................107
4.5. Group To-Do Examples .....................................108
4.5.1. A VTODO Request ...................................109
4.5.2. A VTODO Reply .....................................110
4.5.3. A VTODO Request for Updated Status ................110
4.5.4. A Reply: Percent-Complete .........................111
4.5.5. A Reply: Completed ................................111
4.5.6. An Updated VTODO Request ..........................112
4.5.7. Recurring VTODOs ..................................112
4.6. Journal Examples .........................................113
4.7. Other Examples ...........................................114
4.7.1. Event Refresh .....................................114
4.7.2. Bad RECURRENCE-ID .................................114
5. Application Protocol Fallbacks ................................116
5.1. Partial Implementation ...................................116
5.1.1. Event-Related Fallbacks ...........................117
5.1.2. Free/Busy-Related Fallbacks .......................119
5.1.3. To-Do-Related Fallbacks ...........................120
5.1.4. Journal-Related Fallbacks .........................122
5.2. Latency Issues ...........................................123
5.2.1. Cancellation of an Unknown Calendar Component .....123
5.2.2. Unexpected Reply from an Unknown Delegate .........124
5.3. Sequence Number ..........................................124
6. Security Considerations .......................................124
6.1. Security Threats .........................................124
6.1.1. Spoofing the Organizer ............................124
6.1.2. Spoofing the Attendee .............................124
6.1.3. Unauthorized Replacement of the Organizer .........125
6.1.4. Eavesdropping and Data Integrity ..................125
6.1.5. Flooding a Calendar ...............................125
6.1.6. Unauthorized REFRESH Requests .....................125
6.2. Recommendations ..........................................125
6.2.1. Securing iTIP transactions ........................125
6.2.2. Implementation Controls ...........................126
6.2.3. Access Controls and Filtering .....................126
6.3. Privacy Issues ...........................................126
7. IANA Considerations ...........................................127
7.1. Registration Template for REQUEST-STATUS Values ..........127
7.2. Additions to iCalendar METHOD Registry ...................127
7.3. REQUEST-STATUS Value Registry ............................129
8. Acknowledgments ...............................................130
9. References ....................................................131
9.1. Normative References .....................................131
9.2. Informative References ...................................131
Appendix A. Differences from RFC 2446 ...........................132 A.1. Changed Restrictions .....................................132 A.2. Deprecated Features ......................................1331. Introduction and Overview
This document specifies how calendaring systems use iCalendar [RFC5545] objects to interoperate with other calendaring systems. In particular, it specifies how to schedule events, to-dos, or daily journal entries. It further specifies how to search for available busy time information. It does so in a general way, without specifying how communication between different systems actually takes place. Subsequent documents will specify transport bindings between systems that use this protocol. This protocol is based on messages sent from an originator to one or more recipients. For certain types of messages, a recipient may reply in order to update their status and may also return transaction/request status information. The protocol supports the ability for the message originator to modify or cancel the original message. The protocol also supports the ability for recipients to suggest changes to the originator of a message. The elements of the protocol also define the user roles for its transactions. This specification obsoletes RFC 2446 - a list of important changes is provided in Appendix A.1.1. Formatting Conventions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. Calendaring and scheduling roles are referred to in quoted-strings of text with the first character of each word in upper case. For example, "Organizer" refers to a role of a "Calendar User" (CU) within the scheduling protocol. Calendar components defined by [RFC5545] are referred to with capitalized, quoted-strings of text. All calendar components start with the letter "V". For example, "VEVENT" refers to the event calendar component, "VTODO" refers to the to-do calendar component, and "VJOURNAL" refers to the daily journal calendar component.
Scheduling methods are referred to with capitalized, quoted-strings of text. For example, "REQUEST" refers to the method for requesting a scheduling calendar component be created or modified; "REPLY" refers to the method a recipient of a request uses to update their status with the "Organizer" of the calendar component. Properties defined by [RFC5545] are referred to with capitalized, quoted-strings of text, followed by the word "property". For example, "ATTENDEE" property refers to the iCalendar property used to convey the calendar address of a "Calendar User". Property parameters defined by this specification are referred to with capitalized, quoted-strings of text, followed by the word "parameter". For example, "VALUE" parameter refers to the iCalendar property parameter used to override the default data type for a property value. Enumerated values defined by this specification are referred to with capitalized text, either alone or followed by the word "value". In tables, the quoted-string text is specified without quotes in order to minimize the table length.1.2. Related Documents
Implementers will need to be familiar with several other specifications that, along with this one, describe the Internet calendaring and scheduling standards. The related documents are: [RFC5545] - specifies the objects, data types, properties, and property parameters used in the protocols, along with the methods for representing and encoding them. [iMIP] - specifies an Internet email binding for iTIP. This specification does not attempt to repeat the concepts or definitions from these other specifications. Where possible, explicit references are made to the other specifications.1.3. Roles
Exchanges of iCalendar objects for the purposes of group calendaring and scheduling occur between "Calendar Users" (CUs). CUs take on several roles in iTIP:
+-----------+-------------------------------------------------------+ | Role | Description | +-----------+-------------------------------------------------------+ | Organizer | The CU who initiates an exchange takes on the role of | | | Organizer. For example, the CU who proposes a group | | | meeting is the Organizer. | | | | | Attendee | CUs who are included in the scheduling message as | | | possible recipients of that scheduling message. For | | | example, the CUs asked to participate in a group | | | meeting by the Organizer take on the role of | | | Attendee. | | | | | Other CU | A CU that is not explicitly included in a scheduling | | | message, i.e., not the Organizer or an Attendee. | +-----------+-------------------------------------------------------+ Note that "ROLE" is also a descriptive parameter to the iCalendar "ATTENDEE" property. Its use is to convey descriptive context about an "Attendee" -- such as "chair", "required participant", or "non- required participant" -- and has nothing to do with the calendaring workflow.1.4. Methods
The iTIP methods are listed below and their usage and semantics are defined in Section 3 of this document.
+----------------+--------------------------------------------------+ | Method | Description | +----------------+--------------------------------------------------+ | PUBLISH | Used to publish an iCalendar object to one or | | | more "Calendar Users". There is no | | | interactivity between the publisher and any | | | other "Calendar User". An example might include | | | a baseball team publishing its schedule to the | | | public. | | | | | REQUEST | Used to schedule an iCalendar object with other | | | "Calendar Users". Requests are interactive in | | | that they require the receiver to respond using | | | the reply methods. Meeting requests, busy-time | | | requests, and the assignment of tasks to other | | | "Calendar Users" are all examples. Requests are | | | also used by the Organizer to update the status | | | of an iCalendar object. | | | | | REPLY | A reply is used in response to a request to | | | convey Attendee status to the Organizer. | | | Replies are commonly used to respond to meeting | | | and task requests. | | | | | ADD | Add one or more new instances to an existing | | | recurring iCalendar object. | | | | | CANCEL | Cancel one or more instances of an existing | | | iCalendar object. | | | | | REFRESH | Used by an Attendee to request the latest | | | version of an iCalendar object. | | | | | COUNTER | Used by an Attendee to negotiate a change in an | | | iCalendar object. Examples include the request | | | to change a proposed event time or change the | | | due date for a task. | | | | | DECLINECOUNTER | Used by the Organizer to decline the proposed | | | counter proposal. | +----------------+--------------------------------------------------+
Group scheduling in iTIP is accomplished using the set of "request" and "response" methods described above. The following table shows the methods broken down by who can send them. +------------+------------------------------------------------------+ | Originator | Methods | +------------+------------------------------------------------------+ | Organizer | PUBLISH, REQUEST, ADD, CANCEL, DECLINECOUNTER | | | | | Attendee | REPLY, REFRESH, COUNTER, REQUEST (only when | | | delegating) | +------------+------------------------------------------------------+ Note that for some calendar component types, the allowable methods are a subset of the above set. In addition, apart from "VTIMEZONE" iCalendar components, only one component type is allowed in a single iTIP message.2. Interoperability Models
There are two distinct protocols relevant to interoperability: an "application protocol" and a "transport protocol". The application protocol defines the content of the iCalendar objects sent between sender and receiver to accomplish the scheduling transactions listed above. The transport protocol defines how the iCalendar objects are sent between the sender and receiver. This document focuses on the application protocol. Binding documents such as [iMIP] focus on the transport protocol. The connection between sender and receiver in the diagram below refers to the application protocol. The iCalendar objects passed from the sender to the receiver are presented in Section 3, "Application Protocol Elements". +----------+ +----------+ | | iTIP | | | Sender |<-------------->| Receiver | | | | | +----------+ +----------+ There are several variations of this diagram in which the sender and receiver take on various roles of a "Calendar User Agent" (CUA) or a "Calendar Service" (CS). The architecture of iTIP is depicted in the diagram below. An application written to this specification may work with bindings for the store-and-forward transport, the real-time transport, or both. Also note that iTIP could be bound to other transports.
+--------------------------------------------------------+
| iTIP Protocol |
+--------------------------------------------------------+
| Transport |
+ - - - - - + - - - - - - + - - - - - +
| Real-Time | Store-and-Forward | Others |
+-----------------+--------------------+-----------------+
2.1. Application Protocol
In the iTIP model, an iCalendar object is created and managed by an
"Organizer". The "Organizer" interacts with other CUs by sending one
or more of the iTIP messages listed above. "Attendees" use the
"REPLY" method to communicate their status. "Attendees" do not make
direct changes to the master iCalendar object. They can, however,
use the "COUNTER" method to suggest changes to the "Organizer". In
any case, the "Organizer" has complete control over the master
iCalendar object.
2.1.1. Scheduling State
There are two distinct states relevant to iCalendar objects used in
scheduling: the overall state of the iCalendar object and the state
associated with an "Attendee" in that iCalendar object.
The state of an iCalendar object is defined by the "STATUS" property
and is controlled by the "Organizer." There is no default value for
the "STATUS" property. The "Organizer" sets the "STATUS" property to
the appropriate value for each iCalendar object.
The state of a particular "Attendee" relative to an iCalendar object
used for scheduling is defined by the "PARTSTAT" parameter in the
"ATTENDEE" property for each "Attendee". When an "Organizer" issues
the initial iCalendar object, "Attendee" status is typically unknown.
The "Organizer" specifies this by setting the "PARTSTAT" parameter to
"NEEDS-ACTION". Each "Attendee" modifies their "ATTENDEE" property
"PARTSTAT" parameter to an appropriate value as part of a "REPLY"
message sent back to the "Organizer".
2.1.2. Delegation
Delegation is defined as the process by which an "Attendee" grants
another CU (or several CUs) the right to attend on their behalf. The
"Organizer" is made aware of this change because the delegating
"Attendee" informs the "Organizer". These steps are detailed in the
"REQUEST" method sections for the appropriate components.
2.1.3. Acting on Behalf of Other Calendar Users
In many organizations, one user will act on behalf of another to organize and/or respond to meeting requests. iTIP provides two mechanisms that support these activities. First, the "Organizer" is treated as a special entity, separate from "Attendees". All responses from "Attendees" flow to the "Organizer", making it easy to separate a "Calendar User" organizing a meeting from "Calendar Users" attending the meeting. Additionally, iCalendar provides descriptive roles for each "Attendee". For instance, a role of "chair" may be ascribed to one or more "Attendees". The "chair" and the "Organizer" may or may not be the same "Calendar User". This maps well to scenarios where an assistant may manage meeting logistics for another individual who chairs a meeting. Second, a "SENT-BY" parameter may be specified in either the "Organizer" or "Attendee" properties. When specified, the "SENT-BY" parameter indicates that the responding CU acted on behalf of the specified "Attendee" or "Organizer".2.1.4. Component Revisions
The "SEQUENCE" property is used by the "Organizer" to indicate revisions to the calendar component. When the "Organizer" makes changes to one of the following properties, the sequence number MUST be incremented: o "DTSTART" o "DTEND" o "DURATION" o "DUE" o "RRULE" o "RDATE" o "EXDATE" o "STATUS" In addition, changes made by the "Organizer" to other properties MAY also require the sequence number to be incremented. The "Organizer" CUA MUST increment the sequence number whenever it makes changes to properties in the calendar component that the "Organizer" deems will
jeopardize the validity of the participation status of the
"Attendees". For example, changing the location of a meeting from
one location to another distant location could effectively impact the
participation status of the "Attendees".
Depending on the "METHOD", the "SEQUENCE" property MUST follow these
rules in the context of iTIP:
o For the "PUBLISH" and "REQUEST" methods, the "SEQUENCE" property
value is incremented according to the rules stated above.
o The "SEQUENCE" property value MUST be incremented each time the
"Organizer" uses the "ADD" or "CANCEL" methods.
o The "SEQUENCE" property value MUST NOT be incremented when using
"REPLY", "REFRESH", "COUNTER", "DECLINECOUNTER", or when sending a
delegation "REQUEST".
In some circumstances, the "Organizer" may not have received
responses to the final revision sent out. In this situation, the
"Organizer" may wish to send an update "REQUEST" and set "RSVP=TRUE"
for all "Attendees" so that current responses can be collected.
The value of the "SEQUENCE" property contained in a response from an
"Attendee" may not always match the "Organizer's" revision.
Implementations may choose to have the CUA indicate to the CU that
the response is to an iCalendar object that has been revised, and
allow the CU to decide whether or not to accept the response.
Whilst a change in sequence number is indicative of a significant
change to a previously scheduled item, "Attendee" CUAs SHOULD NOT
rely solely on a change in sequence number as a means of detecting a
significant change. Instead, CUAs SHOULD compare the old and new
versions of the calendar components, determine the exact nature of
the changes, and make decisions -- possibly based on "Calendar User"
preferences -- as to whether the user needs to be explicitly informed
of the change.
2.1.5. Message Sequencing
CUAs that handle the iTIP application protocol must often correlate a
component in a calendar store with a component received in the iTIP
message. For example, an event may be updated with a later revision
of the same event. To accomplish this, a CUA must correlate the
version of the event already in its calendar store with the version
sent in the iTIP message. In addition to this correlation, there are
several factors that can cause iTIP messages to arrive in an
unexpected order. That is, an "Organizer" could receive a reply to
an earlier revision of a component after receiving a reply to a later
revision.
To maximize interoperability and to handle messages that arrive in an
unexpected order, use the following rules:
1. The primary key for referencing a particular iCalendar component
is the "UID" property value. To reference an instance of a
recurring component, the primary key is composed of the "UID" and
the "RECURRENCE-ID" properties.
2. The secondary key for referencing a component is the "SEQUENCE"
property value. For components where the "UID" and
"RECURRENCE-ID" property values are the same, the component with
the highest numeric value for the "SEQUENCE" property obsoletes
all other revisions of the component with lower values.
3. "Attendees" send "REPLY" messages to the "Organizer". For
replies where the "UID" and "RECURRENCE-ID" property values are
the same, the value of the "SEQUENCE" property indicates the
revision of the component to which the "Attendee" is replying.
The reply with the highest numeric value for the "SEQUENCE"
property obsoletes all other replies with lower values.
4. In situations where the "UID", "RECURRENCE-ID", and "SEQUENCE"
property values match, the "DTSTAMP" property is used as the tie-
breaker. The component with the latest "DTSTAMP" overrides all
others. Similarly, for "Attendee" responses where the "UID",
"RECURRENCE-ID", and "SEQUENCE" property values match, the
response with the latest "DTSTAMP" overrides all others.
Hence, CUAs will need to persist the following component properties
in order to correctly process iTIP messages: "UID", "RECURRENCE-ID",
"SEQUENCE", and "DTSTAMP". Furthermore, for each "ATTENDEE" property
of a component, "Organizer" CUAs will need to persist the "SEQUENCE"
and "DTSTAMP" property values associated with the "Attendee's" last
response, so that any earlier responses from an "Attendee" that are
received out of order (e.g., due to a delay in the transport) can be
correctly discarded.
(page 13 continued on part 2)