Tech-invite3GPPspaceIETFspace
959493929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 5546

iCalendar Transport-Independent Interoperability Protocol (iTIP)

Pages: 133
Proposed Standard
Errata
Obsoletes:  2446
Updates:  5545
Updated by:  6638
Part 1 of 5 – Pages 1 to 13
None   None   Next

Top   ToC   RFC5546 - Page 1
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
Top   ToC   RFC5546 - Page 2
   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
Top   ToC   RFC5546 - Page 3
      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
Top   ToC   RFC5546 - Page 4
           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
Top   ToC   RFC5546 - Page 5
   Appendix A.  Differences from RFC 2446 ...........................132
     A.1.  Changed Restrictions .....................................132
     A.2.  Deprecated Features ......................................133

1. 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.
Top   ToC   RFC5546 - Page 6
   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:
Top   ToC   RFC5546 - Page 7
   +-----------+-------------------------------------------------------+
   | 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.
Top   ToC   RFC5546 - Page 8
   +----------------+--------------------------------------------------+
   | 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.                                |
   +----------------+--------------------------------------------------+
Top   ToC   RFC5546 - Page 9
   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.
Top   ToC   RFC5546 - Page 10
      +--------------------------------------------------------+
      |                     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.
Top   ToC   RFC5546 - Page 11

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
Top   ToC   RFC5546 - Page 12
   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
Top   ToC   RFC5546 - Page 13
   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)

Next Section