Tech-invite3GPPspaceIETFspace
959493929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 2446

iCalendar Transport-Independent Interoperability Protocol (iTIP) Scheduling Events, BusyTime, To-dos and Journal Entries

Pages: 109
Obsoleted by:  5546
Part 1 of 4 – Pages 1 to 12
None   None   Next

ToP   noToC   RFC2446 - Page 1
Network Working Group                                     S. Silverberg
Request for Comments: 2446                                    Microsoft
Category: Standards Track                                    S. Mansour
                                                               Netscape
                                                              F. Dawson
                                                                  Lotus
                                                              R. Hopson
                                                        ON Technologies
                                                          November 1998


       iCalendar Transport-Independent Interoperability Protocol
                                 (iTIP)
        Scheduling Events, BusyTime, To-dos and Journal Entries

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) The Internet Society (1998).  All Rights Reserved.

Abstract

   This document specifies how calendaring systems use iCalendar objects
   to interoperate with other calendar systems. It does so in a general
   way so as to allow multiple methods of communication between systems.
   Subsequent documents specify interoperable methods of communications
   between systems that use this protocol.

   The document outlines a model for calendar exchange that defines both
   static and dynamic event, to-do, journal and free/busy objects.
   Static objects are used to transmit information from one entity to
   another without the expectation of continuity or referential
   integrity with the original item. Dynamic objects are a superset of
   static objects and will gracefully degrade to their static
   counterparts for clients that only support static objects.

   This document specifies an Internet protocol based on the iCalendar
   object specification that provides scheduling interoperability
   between different calendar systems. The Internet protocol is called
   the "iCalendar Transport-Independent Interoperability Protocol
   (iTIP)".
ToP   noToC   RFC2446 - Page 2
   iTIP complements the iCalendar object specification by adding
   semantics for group scheduling methods commonly available in current
   calendar systems. These scheduling methods permit two or more
   calendar systems to perform transactions such as publish, schedule,
   reschedule, respond to scheduling requests, negotiation of changes or
   cancel iCalendar-based calendar components.

   iTIP is defined independent of the particular transport used to
   transmit the scheduling information. Companion memos to iTIP provide
   bindings of the interoperability protocol to a number of Internet
   protocols.

Table of Contents

   1 INTRODUCTION...................................................5
    1.1 FORMATTING CONVENTIONS .....................................5
    1.2 RELATED DOCUMENTS ..........................................6
    1.3 ITIP ROLES AND TRANSACTIONS ................................6
   2 INTEROPERABILITY MODELS........................................8
    2.1 APPLICATION PROTOCOL .......................................9
      2.1.1 Calendar Entry State ...................................9
      2.1.2 Delegation .............................................9
      2.1.3 Acting on Behalf of other Calendar Users ..............10
      2.1.4 Component Revisions ...................................10
      2.1.5 Message Sequencing ....................................11
   3 APPLICATION PROTOCOL ELEMENTS.................................12
    3.1 COMMON COMPONENT RESTRICTION TABLES .......................13
    3.2 METHODS FOR VEVENT CALENDAR COMPONENTS ....................14
      3.2.1 PUBLISH ...............................................15
      3.2.2 REQUEST ...............................................17
        3.2.2.1 Rescheduling an Event..............................19
        3.2.2.2 Updating or Reconfirmation of an Event.............19
        3.2.2.3 Delegating an Event to another CU..................19
        3.2.2.4 Changing the Organizer.............................20
        3.2.2.5 Sending on Behalf of the Organizer.................20
        3.2.2.6 Forwarding to An Uninvited CU......................20
        3.2.2.7 Updating Attendee Status...........................21
      3.2.3 REPLY .................................................21
      3.2.4 ADD ...................................................23
      3.2.5 CANCEL ................................................25
      3.2.6 REFRESH ...............................................26
      3.2.7 COUNTER ...............................................28
      3.2.8 DECLINECOUNTER ........................................29
    3.3 METHODS FOR VFREEBUSY COMPONENTS ..........................31
      3.3.1 PUBLISH ...............................................32
      3.3.2 REQUEST ...............................................33
      3.3.3 REPLY .................................................34
    3.4 METHODS FOR VTODO COMPONENTS ..............................35
ToP   noToC   RFC2446 - Page 3
      3.4.1 PUBLISH ...............................................35
      3.4.2 REQUEST ...............................................37
        3.4.2.1 REQUEST for Rescheduling a VTODO...................39
        3.4.2.2 REQUEST for Update or Reconfirmation of a VTODO....39
        3.4.2.3 REQUEST for Delegating a VTODO.....................40
        3.4.2.4 REQUEST Forwarded To An Uninvited Calendar User....40
        3.4.2.5 REQUEST Updated Attendee Status....................41
      3.4.3 REPLY .................................................41
      3.4.4 ADD ...................................................43
      3.4.5 CANCEL ................................................44
      3.4.6 REFRESH ...............................................46
      3.4.7 COUNTER ...............................................48
      3.4.8 DECLINECOUNTER ........................................49
    3.5 METHODS FOR VJOURNAL COMPONENTS ...........................50
      3.5.1 PUBLISH ...............................................51
      3.5.2 ADD ...................................................52
      3.5.3 CANCEL ................................................53
    3.6 STATUS REPLIES ............................................55
    3.7 IMPLEMENTATION CONSIDERATIONS .............................57
      3.7.1 Working With Recurrence Instances .....................57
      3.7.2 Attendee Property Considerations ......................58
      3.7.3 X-Tokens ..............................................59
   4 EXAMPLES......................................................59
    4.1 PUBLISHED EVENT EXAMPLES ..................................59
      4.1.1 A Minimal Published Event .............................60
      4.1.2 Changing A Published Event ............................60
      4.1.3 Canceling A Published Event ...........................61
      4.1.4 A Rich Published Event ................................62
      4.1.5 Anniversaries or Events attached to entire days .......63
    4.2 GROUP EVENT EXAMPLES ......................................63
      4.2.1 A Group Event Request .................................64
      4.2.2 Reply To A Group Event Request ........................65
      4.2.3 Update An Event .......................................65
      4.2.4 Countering an Event Proposal ..........................66
      4.2.5 Delegating an Event ...................................68
      4.2.6 Delegate Accepts the Meeting ..........................70
      4.2.7 Delegate Declines the Meeting .........................71
      4.2.8 Forwarding an Event Request ...........................72
      4.2.9 Cancel A Group Event ..................................72
      4.2.10 Removing Attendees ...................................74
      4.2.11 Replacing the Organizer ..............................75
    4.3 BUSY TIME EXAMPLES ........................................76
      4.3.1 Request Busy Time .....................................77
      4.3.2 Reply To A Busy Time Request ..........................77
    4.4 RECURRING EVENT AND TIME ZONE EXAMPLES ....................78
      4.4.1 A Recurring Event Spanning Time Zones .................78
      4.4.2 Modify A Recurring Instance ...........................79
      4.4.3 Cancel an Instance ....................................81
ToP   noToC   RFC2446 - Page 4
      4.4.4 Cancel Recurring Event ................................81
      4.4.5 Change All Future Instances ...........................82
      4.4.6 Add A New Instance To A Recurring Event ...............82
      4.4.7 Add A New Series of Instances To A Recurring Event ....83
      4.4.8 Counter An Instance Of A Recurring Event ..............87
      4.4.9 Error Reply To A Request ..............................88
    4.5 GROUP TO-DO EXAMPLES ......................................89
      4.5.1 A VTODO Request .......................................90
      4.5.2 A VTODO Reply .........................................90
      4.5.3 A VTODO Request for Updated Status ....................91
      4.5.4 A Reply: Percent-Complete .............................91
      4.5.5 A Reply: Completed ....................................92
      4.5.6 An Updated VTODO Request ..............................92
      4.5.7 Recurring VTODOs ......................................92
        4.5.7.1 Request for a Recurring VTODO......................93
        4.5.7.2 Calculating due dates in recurring VTODOs..........93
        4.5.7.3 Replying to an instance of a recurring VTODO.......93
    4.6 JOURNAL EXAMPLES ..........................................94
    4.7 OTHER EXAMPLES ............................................94
      4.7.1 Event Refresh .........................................94
      4.7.2 Bad RECURRENCE-ID .....................................95
   5 APPLICATION PROTOCOL FALLBACKS................................97
    5.1 PARTIAL IMPLEMENTATION ....................................97
      5.1.1 Event-Related Fallbacks ...............................97
      5.1.2 Free/Busy-Related Fallbacks ...........................99
      5.1.3 To-Do-Related Fallbacks ...............................99
      5.1.4 Journal-Related Fallbacks ............................101
    5.2 LATENCY ISSUES ...........................................102
      5.2.1 Cancellation of an Unknown Calendar Component. .......102
      5.2.2 Unexpected Reply from an Unknown Delegate ............103
    5.3 SEQUENCE NUMBER ..........................................103
   6 SECURITY CONSIDERATIONS......................................103
    6.1 SECURITY THREATS .........................................103
      6.1.1 Spoofing the "Organizer" .............................103
      6.1.2 Spoofing the "Attendee" ..............................103
      6.1.3 Unauthorized Replacement of the Organizer ............104
      6.1.4 Eavesdropping ........................................104
      6.1.5 Flooding a Calendar ..................................104
      6.1.6 Procedural Alarms ....................................104
      6.1.7 Unauthorized REFRESH Requests ........................104
    6.2 RECOMMENDATIONS ..........................................104
      6.2.1 Use of [RFC-1847] to secure iTIP transactions ........105
      6.2.2 Implementation Controls ..............................105
   7 ACKNOWLEDGMENTS..............................................106
   8 BIBLIOGRAPHY.................................................106
   9 AUTHORS' ADDRESSES...........................................107
   10 FULL COPYRIGHT STATEMENT....................................109
ToP   noToC   RFC2446 - Page 5
1 Introduction

   This document specifies how calendaring systems use iCalendar objects
   to interoperate with other calendar 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 so as to allow multiple
   methods of communication between systems. Subsequent documents
   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.

1.1 Formatting Conventions

   In order to refer to elements of the calendaring and scheduling
   model, core object or interoperability protocol defined in [iCAL] and
   [iTIP] several formatting conventions have been utilized.

   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 [RFC-2119].

   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 defined by [iTIP]. Calendar components
   defined by [iCAL] 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 defined by [iTIP] 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 [iCAL] 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
ToP   noToC   RFC2446 - Page 6
   defined by this memo are referred to with lower case, 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 memo 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 memos that,
   along with this one, describe the Internet calendaring and scheduling
   standards. This document, [iTIP], specifies an interoperability
   protocol for scheduling between different implementations. The
   related documents are:

        [iCAL] - 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 memo does not attempt to repeat the specification of concepts or
   definitions from these other memos. Where possible, references are
   made to the memo that provides for the specification of these
   concepts or definitions.

1.3 ITIP Roles and Transactions

   ITIP defines methods for exchanging [iCAL] objects for the purposes
   of group calendaring and scheduling between "Calendar Users" (CUs).
   CUs take on one of two roles in iTIP. The CU who initiates an
   exchange takes on the role of "Organizer". For example, the CU who
   proposes a group meeting is the "Organizer". The CUs asked to
   participate in the group meeting by the "Organizer" take on the role
   of "Attendee". Note that "role" is also a descriptive parameter to
   the _ATTENDEE_ property. Its use is to convey descriptive context to
   an "Attendee" such as "chair", "req-participant" or "non-participant"
   and has nothing to do with the calendaring workflow.
ToP   noToC   RFC2446 - Page 7
   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 a calendar entry 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 a calendar entry 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 VTODOs to    |
   |                | other Calendar Users are all examples.           |
   |                | Requests are also used by the "Organizer" to     |
   |                | update the status of a calendar entry.           |
   |                |                                                  |
   | 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 instances to an existing         |
   |                | VEVENT, VTODO, or VJOURNAL.                      |
   |                |                                                  |
   | CANCEL         | Cancel one or more instances of an existing      |
   |                | VEVENT, VTODO, or VJOURNAL.                      |
   |                |                                                  |
   | REFRESH        | The Refresh method is used by an "Attendee" to   |
   |                | request the latest version of a calendar entry.  |
   |                |                                                  |
   | COUNTER        | The Counter method is used by an "Attendee" to   |
   |                | negotiate a change in the calendar entry.        |
   |                | Examples include the request to change a         |
   |                | proposed Event time or change the due date for a |
   |                | VTODO.                                           |
   |                |                                                  |
   | DECLINE-       | Used by the "Organizer" to decline the proposed  |
   | COUNTER        | counter-proprosal.                               |
   +================+==================================================+
ToP   noToC   RFC2446 - Page 8
   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.

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   noToC   RFC2446 - Page 9
   +------------------------------------------+
   |                   iTIP                   |
   +------------------------------------------+
   |Real-time | Store-and-Fwd | Other         |
   |Transport | Transport     | Transports... |
   +------------------------------------------+

2.1 Application Protocol

   In the iTIP model, a calendar entry 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 calendar entry. They can, however, use
   the "COUNTER" method to suggest changes to the "Organizer". In any
   case, the "Organizer" has complete control over the master calendar
   entry.

2.1.1 Calendar Entry State

   There are two distinct states relevant to calendar entries: the
   overall state of the entry and the state associated with an
   "Attendee" to that entry.

   The state of an entry 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 calendar entry.

   The state of a particular "Attendee" relative to an entry is defined
   by the "partstat" parameter in the "ATTENDEE" property for each
   "Attendee".  When an "Organizer" issues the initial entry, "Attendee"
   status is 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 section.
ToP   noToC   RFC2446 - Page 10
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. The rules for incrementing the
   "SEQUENCE" number are defined in [iCAL]. For clarity, these rules are
   paraphrased here in terms of how they are applied in [iTIP]. For a
   given "UID" in a calendar component:

   . For the "PUBLISH" and "REQUEST" methods, the "SEQUENCE" property
      value is incremented according to the rules defined in [iCAL].

   . The "SEQUENCE" property value MUST be incremented each time the
      "Organizer" uses the "ADD" or "CANCEL" methods.

   . 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.
ToP   noToC   RFC2446 - Page 11
   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 entry that has been revised and allow the CU to
   decide whether or not to accept the response.

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" is 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" property value is 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" and "SEQUENCE" properties 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" property values match and
       the "SEQUENCE" property values match, the response with the
       latest "DTSTAMP" overrides all others.
ToP   noToC   RFC2446 - Page 12
   Hence, CUAs must persist the following component properties: "UID",
   "RECURRENCE-ID", "SEQUENCE", and "DTSTAMP".  Furthermore, for each
   "ATTENDEE" property of a component CUAs must persist the "SEQUENCE"
   and "DTSTAMP" property values associated with the "Attendee's"
   response.



(page 12 continued on part 2)

Next Section