Internet DRAFT - draft-ietf-calsify-2446bis
draft-ietf-calsify-2446bis
Network Working Group C. Daboo, Ed.
Internet-Draft Apple Inc.
Obsoletes: 2446 (if approved) November 3, 2008
Intended status: Standards Track
Expires: May 7, 2009
iCalendar Transport-Independent Interoperability Protocol (iTIP)
draft-ietf-calsify-2446bis-08
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on May 7, 2009.
Abstract
This document specifies a protocol using 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 using specific interoperable methods of
communications between systems.
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
Daboo Expires May 7, 2009 [Page 1]
Internet-Draft iTIP November 2008
calendaring systems to perform transactions such as publish,
schedule, reschedule, respond to scheduling requests, negotiation of
changes or cancel.
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 . . . . . . . . . . . . . . . . . . . 8
2.1. Application Protocol . . . . . . . . . . . . . . . . . . 9
2.1.1. Scheduling State . . . . . . . . . . . . . . . . . . 9
2.1.2. Delegation . . . . . . . . . . . . . . . . . . . . . 10
2.1.3. Acting on Behalf of other Calendar Users . . . . . . 10
2.1.4. Component Revisions . . . . . . . . . . . . . . . . . 10
2.1.5. Message Sequencing . . . . . . . . . . . . . . . . . 12
3. Application Protocol Elements . . . . . . . . . . . . . . . . 13
3.1. Common Component Restriction Tables . . . . . . . . . . . 14
3.1.1. VCALENDAR . . . . . . . . . . . . . . . . . . . . . . 14
3.1.2. VTIMEZONE . . . . . . . . . . . . . . . . . . . . . . 14
3.1.3. VALARM . . . . . . . . . . . . . . . . . . . . . . . 15
3.2. Methods for VEVENT Calendar Components . . . . . . . . . 16
3.2.1. PUBLISH . . . . . . . . . . . . . . . . . . . . . . . 17
3.2.2. REQUEST . . . . . . . . . . . . . . . . . . . . . . . 19
3.2.3. REPLY . . . . . . . . . . . . . . . . . . . . . . . . 23
3.2.4. ADD . . . . . . . . . . . . . . . . . . . . . . . . . 25
3.2.5. CANCEL . . . . . . . . . . . . . . . . . . . . . . . 27
3.2.6. REFRESH . . . . . . . . . . . . . . . . . . . . . . . 29
3.2.7. COUNTER . . . . . . . . . . . . . . . . . . . . . . . 31
3.2.8. DECLINECOUNTER . . . . . . . . . . . . . . . . . . . 33
3.3. Methods For VFREEBUSY Components . . . . . . . . . . . . 34
3.3.1. PUBLISH . . . . . . . . . . . . . . . . . . . . . . . 35
3.3.2. REQUEST . . . . . . . . . . . . . . . . . . . . . . . 36
3.3.3. REPLY . . . . . . . . . . . . . . . . . . . . . . . . 38
3.4. Methods For VTODO Components . . . . . . . . . . . . . . 39
3.4.1. PUBLISH . . . . . . . . . . . . . . . . . . . . . . . 40
3.4.2. REQUEST . . . . . . . . . . . . . . . . . . . . . . . 42
3.4.3. REPLY . . . . . . . . . . . . . . . . . . . . . . . . 47
3.4.4. ADD . . . . . . . . . . . . . . . . . . . . . . . . . 49
3.4.5. CANCEL . . . . . . . . . . . . . . . . . . . . . . . 50
3.4.6. REFRESH . . . . . . . . . . . . . . . . . . . . . . . 52
3.4.7. COUNTER . . . . . . . . . . . . . . . . . . . . . . . 54
3.4.8. DECLINECOUNTER . . . . . . . . . . . . . . . . . . . 56
3.5. Methods For VJOURNAL Components . . . . . . . . . . . . . 58
3.5.1. PUBLISH . . . . . . . . . . . . . . . . . . . . . . . 58
Daboo Expires May 7, 2009 [Page 2]
Internet-Draft iTIP November 2008
3.5.2. ADD . . . . . . . . . . . . . . . . . . . . . . . . . 60
3.5.3. CANCEL . . . . . . . . . . . . . . . . . . . . . . . 62
3.6. Status Replies . . . . . . . . . . . . . . . . . . . . . 64
3.7. Implementation Considerations . . . . . . . . . . . . . . 67
3.7.1. Working With Recurrence Instances . . . . . . . . . . 67
3.7.2. Attendee Property Considerations . . . . . . . . . . 68
3.7.3. Extension Tokens . . . . . . . . . . . . . . . . . . 69
4. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 69
4.1. Published Event Examples . . . . . . . . . . . . . . . . 69
4.1.1. A Minimal Published Event . . . . . . . . . . . . . . 70
4.1.2. Changing A Published Event . . . . . . . . . . . . . 70
4.1.3. Canceling A Published Event . . . . . . . . . . . . . 71
4.1.4. A Rich Published Event . . . . . . . . . . . . . . . 71
4.1.5. Anniversaries or Events attached to entire days . . . 73
4.2. Group Event Examples . . . . . . . . . . . . . . . . . . 73
4.2.1. A Group Event Request . . . . . . . . . . . . . . . . 74
4.2.2. Reply To A Group Event Request . . . . . . . . . . . 75
4.2.3. Update An Event . . . . . . . . . . . . . . . . . . . 75
4.2.4. Countering an Event Proposal . . . . . . . . . . . . 76
4.2.5. Delegating an Event . . . . . . . . . . . . . . . . . 79
4.2.6. Delegate Accepts the Meeting . . . . . . . . . . . . 81
4.2.7. Delegate Declines the Meeting . . . . . . . . . . . . 82
4.2.8. Forwarding an Event Request . . . . . . . . . . . . . 83
4.2.9. Cancel A Group Event . . . . . . . . . . . . . . . . 83
4.2.10. Removing Attendees . . . . . . . . . . . . . . . . . 84
4.2.11. Replacing the Organizer . . . . . . . . . . . . . . . 86
4.3. Busy Time Examples . . . . . . . . . . . . . . . . . . . 87
4.3.1. Publish Busy Time . . . . . . . . . . . . . . . . . . 87
4.3.2. Request Busy Time . . . . . . . . . . . . . . . . . . 88
4.3.3. Reply To A Busy Time Request . . . . . . . . . . . . 89
4.4. Recurring Event and Time Zone Examples . . . . . . . . . 89
4.4.1. A Recurring Event Spanning Time Zones . . . . . . . . 89
4.4.2. Modify A Recurring Instance . . . . . . . . . . . . . 91
4.4.3. Cancel an Instance . . . . . . . . . . . . . . . . . 93
4.4.4. Cancel Recurring Event . . . . . . . . . . . . . . . 94
4.4.5. Change All Future Instances . . . . . . . . . . . . . 94
4.4.6. Add A New Instance To A Recurring Event . . . . . . . 95
4.4.7. Add A New Series of Instances To A Recurring Event . 96
4.4.8. Counter An Instance Of A Recurring Event . . . . . . 101
4.4.9. Error Reply To A Request . . . . . . . . . . . . . . 102
4.5. Group To-do Examples . . . . . . . . . . . . . . . . . . 104
4.5.1. A VTODO Request . . . . . . . . . . . . . . . . . . . 105
4.5.2. A VTODO Reply . . . . . . . . . . . . . . . . . . . . 105
4.5.3. A VTODO Request for Updated Status . . . . . . . . . 106
4.5.4. A Reply: Percent-Complete . . . . . . . . . . . . . . 106
4.5.5. A Reply: Completed . . . . . . . . . . . . . . . . . 107
4.5.6. An Updated VTODO Request . . . . . . . . . . . . . . 107
4.5.7. Recurring VTODOs . . . . . . . . . . . . . . . . . . 108
Daboo Expires May 7, 2009 [Page 3]
Internet-Draft iTIP November 2008
4.6. Journal Examples . . . . . . . . . . . . . . . . . . . . 109
4.7. Other Examples . . . . . . . . . . . . . . . . . . . . . 109
4.7.1. Event Refresh . . . . . . . . . . . . . . . . . . . . 109
4.7.2. Bad RECURRENCE-ID . . . . . . . . . . . . . . . . . . 110
5. Application Protocol Fallbacks . . . . . . . . . . . . . . . 113
5.1. Partial Implementation . . . . . . . . . . . . . . . . . 113
5.1.1. Event-Related Fallbacks . . . . . . . . . . . . . . . 113
5.1.2. Free/Busy-Related Fallbacks . . . . . . . . . . . . . 115
5.1.3. To-Do-Related Fallbacks . . . . . . . . . . . . . . . 116
5.1.4. Journal-Related Fallbacks . . . . . . . . . . . . . . 118
5.2. Latency Issues . . . . . . . . . . . . . . . . . . . . . 119
5.2.1. Cancellation of an Unknown Calendar Component. . . . 119
5.2.2. Unexpected Reply from an Unknown Delegate . . . . . . 120
5.3. Sequence Number . . . . . . . . . . . . . . . . . . . . . 120
6. Security Considerations . . . . . . . . . . . . . . . . . . . 120
6.1. Security Threats . . . . . . . . . . . . . . . . . . . . 120
6.1.1. Spoofing the "Organizer" . . . . . . . . . . . . . . 120
6.1.2. Spoofing the "Attendee" . . . . . . . . . . . . . . . 120
6.1.3. Unauthorized Replacement of the Organizer . . . . . . 121
6.1.4. Eavesdropping . . . . . . . . . . . . . . . . . . . . 121
6.1.5. Flooding a Calendar . . . . . . . . . . . . . . . . . 121
6.1.6. Unauthorized REFRESH Requests . . . . . . . . . . . . 121
6.2. Recommendations . . . . . . . . . . . . . . . . . . . . . 121
6.2.1. Use of [RFC1847] to secure iTIP transactions . . . . 121
6.2.2. Implementation Controls . . . . . . . . . . . . . . . 122
7. IANA Consideration . . . . . . . . . . . . . . . . . . . . . 122
7.1. METHOD:PUBLISH . . . . . . . . . . . . . . . . . . . . . 123
7.2. METHOD:REQUEST . . . . . . . . . . . . . . . . . . . . . 123
7.3. METHOD:REPLY . . . . . . . . . . . . . . . . . . . . . . 123
7.4. METHOD:ADD . . . . . . . . . . . . . . . . . . . . . . . 123
7.5. METHOD:CANCEL . . . . . . . . . . . . . . . . . . . . . . 124
7.6. METHOD:REFRESH . . . . . . . . . . . . . . . . . . . . . 124
7.7. METHOD:COUNTER . . . . . . . . . . . . . . . . . . . . . 124
7.8. METHOD:DECLINE-COUNTER . . . . . . . . . . . . . . . . . 124
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 124
9. Normative References . . . . . . . . . . . . . . . . . . . . 125
Appendix A. Differences from RFC 2446 . . . . . . . . . . . . . 125
A.1. Changed Restrictions . . . . . . . . . . . . . . . . . . 125
A.2. Deprecated features . . . . . . . . . . . . . . . . . . . 126
Appendix B. Change History (to be removed prior to
publication as an RFC) . . . . . . . . . . . . . . . 126
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 129
Intellectual Property and Copyright Statements . . . . . . . . . 130
Daboo Expires May 7, 2009 [Page 4]
Internet-Draft iTIP November 2008
1. Introduction and Overview
This document specifies how calendaring systems use iCalendar
[I-D.ietf-calsify-rfc2445bis] 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 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 [I-D.ietf-calsify-rfc2445bis] 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 [I-D.ietf-calsify-rfc2445bis] are referred to
Daboo Expires May 7, 2009 [Page 5]
Internet-Draft iTIP November 2008
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:
[I-D.ietf-calsify-rfc2445bis] - specifies the objects, data types,
properties and property parameters used in the protocols, along
with the methods for representing and encoding them.
[I-D.ietf-calsify-rfc2447bis] 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". |
| | |
Daboo Expires May 7, 2009 [Page 6]
Internet-Draft iTIP November 2008
| 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. |
| | |
Daboo Expires May 7, 2009 [Page 7]
Internet-Draft iTIP November 2008
| CANCEL | Cancel one or more instances of an existing |
| | iCalendar object. |
| | |
| REFRESH | The Refresh method is used by an "Attendee" to |
| | request the latest version of an iCalendar |
| | object. |
| | |
| COUNTER | The Counter method is used by an "Attendee" to |
| | negotiate a change in an iCalendar objecy. |
| | 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
[I-D.ietf-calsify-rfc2447bis] focus on the Transport Protocol.
The connection between Sender and Receiver in the diagram below
Daboo Expires May 7, 2009 [Page 8]
Internet-Draft iTIP November 2008
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.
Daboo Expires May 7, 2009 [Page 9]
Internet-Draft iTIP November 2008
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 a 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 section.
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
Daboo Expires May 7, 2009 [Page 10]
Internet-Draft iTIP November 2008
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
Daboo Expires May 7, 2009 [Page 11]
Internet-Draft iTIP November 2008
versions of the calendar components and 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",
Daboo Expires May 7, 2009 [Page 12]
Internet-Draft iTIP November 2008
"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.
3. Application Protocol Elements
ITIP messages are "text/calendar" MIME entities that contain
calendaring and scheduling information. The particular type of
iCalendar message is referred to as the "method type". Each method
type is identified by a "METHOD" property specified as part of the
"text/calendar" content type. The table below shows various
combinations of calendar components and the method types that this
specification supports.
+----------------+--------+-------+----------+-----------+
| | VEVENT | VTODO | VJOURNAL | VFREEBUSY |
+----------------+--------+-------+----------+-----------+
| PUBLISH | Yes | Yes | Yes | Yes |
| REQUEST | Yes | Yes | No | Yes |
| REFRESH | Yes | Yes | No | No |
| CANCEL | Yes | Yes | Yes | No |
| ADD | Yes | Yes | Yes | No |
| REPLY | Yes | Yes | No | Yes |
| COUNTER | Yes | Yes | No | No |
| DECLINECOUNTER | Yes | Yes | No | No |
+----------------+--------+-------+----------+-----------+
Each method type is defined in terms of its associated components and
properties. Some components and properties are required, some are
optional and others are excluded. The restrictions are expressed in
this document using a simple "restriction table". The first column
indicates the name of a component or property. Properties of the
iCalendar object are not indented. Properties of a component are
indented. The second column (the "Presence" column) indicates
whether a component or property should be present or not, and if
present how many times it can occur. The third column contains
comments for further clarification.
The presence column uses the following values to assert whether a
property is required, is optional and the number of times it may
appear in the iCalendar object.
Daboo Expires May 7, 2009 [Page 13]
Internet-Draft iTIP November 2008
+----------------+--------------------------------------------------+
| Presence Value | Description |
+----------------+--------------------------------------------------+
| 1 | One instance MUST be present |
| 1+ | At least one instance MUST be present |
| 0 | Instances of this property MUST NOT be present |
| 0+ | Multiple instances MAY be present |
| 0 or 1 | Up to 1 instance of this property MAY be present |
+----------------+--------------------------------------------------+
The tables also call out "IANA-PROPERTY", "X-PROPERTY", "IANA-
COMPONENT" and "X-COMPONENT" to show where registered and vendor-
specific property and component extensions can appear. The tables do
not lay out the restrictions of property parameters. Those
restrictions are defined in [I-D.ietf-calsify-rfc2445bis].
3.1. Common Component Restriction Tables
3.1.1. VCALENDAR
The restriction table below applies to properties of the iCalendar
object. That is, the properties at the outermost scope.
+-----------------------------------------------------+
| Constraints for properties in a VCALENDAR Component |
+-----------------------------------------------------+
+--------------------+----------+---------------------+
| Component/Property | Presence | Comment |
+--------------------+----------+---------------------+
| CALSCALE | 0 or 1 | |
| PRODID | 1 | |
| VERSION | 1 | Value MUST be "2.0" |
| IANA-PROPERTY | 0+ | |
| X-PROPERTY | 0+ | |
+--------------------+----------+---------------------+
3.1.2. VTIMEZONE
"VTIMEZONE" components may be referred to by other components via a
"TZID" parameter on a "DATETIME" value type. The property
restrictions in the table below apply to any "VTIMEZONE" component in
an ITIP message.
+--------------------------------------+
| Constraints for VTIMEZONE Components |
+--------------------------------------+
Daboo Expires May 7, 2009 [Page 14]
Internet-Draft iTIP November 2008
+--------------------+----------+-----------------------------------+
| Component/Property | Presence | Comment |
+--------------------+----------+-----------------------------------+
| VTIMEZONE | 0+ | MUST be present if any date/time |
| | | refers to timezone |
| DAYLIGHT | 0+ | MUST be one or more of either |
| | | STANDARD or DAYLIGHT |
| COMMENT | 0+ | |
| DTSTART | 1 | MUST be local time format |
| RDATE | 0+ | if present RRULE MUST NOT be |
| | | present |
| RRULE | 0 or 1 | if present RDATE MUST NOT be |
| | | present |
| TZNAME | 0+ | |
| TZOFFSETFROM | 1 | |
| TZOFFSETTO | 1 | |
| IANA-PROPERTY | 0+ | |
| X-PROPERTY | 0+ | |
| LAST-MODIFIED | 0 or 1 | |
| STANDARD | 0+ | MUST be one or more of either |
| | | STANDARD or DAYLIGHT |
| COMMENT | 0+ | |
| DTSTART | 1 | MUST be local time format |
| RDATE | 0+ | if present RRULE MUST NOT be |
| | | present |
| RRULE | 0 or 1 | if present RDATE MUST NOT be |
| | | present |
| TZNAME | 0+ | |
| TZOFFSETFROM | 1 | |
| TZOFFSETTO | 1 | |
| IANA-PROPERTY | 0+ | |
| X-PROPERTY | 0+ | |
| TZID | 1 | |
| TZURL | 0 or 1 | |
| IANA-PROPERTY | 0+ | |
| X-PROPERTY | 0+ | |
+--------------------+----------+-----------------------------------+
3.1.3. VALARM
The property restrictions in the table below apply to any "VALARM"
component in an ITIP message.
+-----------------------------------+
| Constraints for VALARM Components |
+-----------------------------------+
Daboo Expires May 7, 2009 [Page 15]
Internet-Draft iTIP November 2008
+--------------------+----------+-----------------------------------+
| Component/Property | Presence | Comment |
+--------------------+----------+-----------------------------------+
| VALARM | 0+ | |
| ACTION | 1 | |
| ATTACH | 0+ | |
| ATTENDEE | 0+ | |
| DESCRIPTION | 0 or 1 | |
| DURATION | 0 or 1 | if present REPEAT MUST be present |
| REPEAT | 0 or 1 | if present DURATION MUST be |
| | | present |
| SUMMARY | 0 or 1 | |
| TRIGGER | 1 | |
| IANA-PROPERTY | 0+ | |
| X-PROPERTY | 0+ | |
+--------------------+----------+-----------------------------------+
3.2. Methods for VEVENT Calendar Components
This section defines the property set restrictions for the method
types that are applicable to the "VEVENT" calendar component. Each
method is defined using a table that clarifies the property
constraints that define the particular method.
The following summarizes the methods that are defined for the
"VEVENT" calendar component.
+----------------+--------------------------------------------------+
| Method | Description |
+----------------+--------------------------------------------------+
| PUBLISH | Post notification of an event. Used primarily |
| | as a method of advertising the existence of an |
| | event. |
| | |
| REQUEST | Make a request for an event. This is an |
| | explicit invitation to one or more "Attendees". |
| | Event requests are also used to update or change |
| | an existing event. Clients that cannot handle |
| | REQUEST MAY degrade the event to view it as an |
| | PUBLISH. |
| | |
| REPLY | Reply to an event request. Clients may set |
| | their status ("PARTSTAT") to ACCEPTED, DECLINED, |
| | TENTATIVE, or DELEGATED. |
| | |
| ADD | Add one or more instances to an existing event. |
| | |
Daboo Expires May 7, 2009 [Page 16]
Internet-Draft iTIP November 2008
| CANCEL | Cancel one or more instances of an existing |
| | event. |
| | |
| REFRESH | A request is sent to an "Organizer" by an |
| | "Attendee" asking for the latest version of an |
| | event to be resent to the requester. |
| | |
| COUNTER | Counter a REQUEST with an alternative proposal, |
| | Sent by an "Attendee" to the "Organizer". |
| | |
| DECLINECOUNTER | Decline a counter proposal. Sent to an |
| | "Attendee" by the "Organizer". |
+----------------+--------------------------------------------------+
3.2.1. PUBLISH
The "PUBLISH" method in a "VEVENT" calendar component is an
unsolicited posting of an iCalendar object. Any CU may add published
components to their calendar. The "Organizer" MUST be present in a
published iCalendar component. "Attendees" MUST NOT be present. Its
expected usage is for encapsulating an arbitrary event as an
iCalendar object. The "Organizer" may subsequently update (with
another "PUBLISH" method), add instances to (with an "ADD" method),
or cancel (with a "CANCEL" method) a previously published "VEVENT"
calendar component.
This method type is an iCalendar object that conforms to the
following property constraints:
+----------------------------------------------+
| Constraints for a METHOD:PUBLISH of a VEVENT |
+----------------------------------------------+
+--------------------+----------+-----------------------------------+
| Component/Property | Presence | Comment |
+--------------------+----------+-----------------------------------+
| METHOD | 1 | MUST equal "PUBLISH" |
| | | |
| VEVENT | 1+ | |
| DTSTAMP | 1 | |
| DTSTART | 1 | |
| ORGANIZER | 1 | |
| SUMMARY | 1 | Can be null. |
| UID | 1 | |
| RECURRENCE-ID | 0 or 1 | Only if referring to an instance |
| | | of a recurring calendar |
| | | component. Otherwise it MUST NOT |
| | | be present. |
Daboo Expires May 7, 2009 [Page 17]
Internet-Draft iTIP November 2008
| SEQUENCE | 0 or 1 | MUST be present if value is |
| | | greater than 0, MAY be present if |
| | | 0 |
| ATTACH | 0+ | |
| CATEGORIES | 0+ | |
| CLASS | 0 or 1 | |
| COMMENT | 0+ | |
| CONTACT | 0 or 1 | |
| CREATED | 0 or 1 | |
| DESCRIPTION | 0 or 1 | Can be null |
| DTEND | 0 or 1 | If present DURATION MUST NOT be |
| | | present |
| DURATION | 0 or 1 | If present DTEND MUST NOT be |
| | | present |
| EXDATE | 0+ | |
| GEO | 0 or 1 | |
| LAST-MODIFIED | 0 or 1 | |
| LOCATION | 0 or 1 | |
| PRIORITY | 0 or 1 | |
| RDATE | 0+ | |
| RELATED-TO | 0+ | |
| RESOURCES | 0+ | |
| RRULE | 0 or 1 | |
| STATUS | 0 or 1 | MAY be one of |
| | | TENTATIVE/CONFIRMED/CANCELLED |
| TRANSP | 0 or 1 | |
| URL | 0 or 1 | |
| IANA-PROPERTY | 0+ | |
| X-PROPERTY | 0+ | |
| ATTENDEE | 0 | |
| REQUEST-STATUS | 0 | |
| | | |
| VALARM | 0+ | |
| | | |
| VFREEBUSY | 0 | |
| | | |
| VJOURNAL | 0 | |
| | | |
| VTODO | 0 | |
| | | |
| VTIMEZONE | 0+ | MUST be present if any date/time |
| | | refers to a timezone |
| | | |
| IANA-COMPONENT | 0+ | |
| X-COMPONENT | 0+ | |
+--------------------+----------+-----------------------------------+
Daboo Expires May 7, 2009 [Page 18]
Internet-Draft iTIP November 2008
3.2.2. REQUEST
The "REQUEST" method in a "VEVENT" component provides the following
scheduling functions:
o Invite "Attendees" to an event
o Reschedule an existing event
o Response to a REFRESH request
o Update the details of an existing event, without rescheduling it
o Update the status of "Attendees" of an existing event, without
rescheduling it
o Reconfirm an existing event, without rescheduling it
o Forward a "VEVENT" to another uninvited CU
o For an existing "VEVENT" calendar component, delegate the role of
"Attendee" to another CU
o For an existing "VEVENT" calendar component, changing the role of
"Organizer" to another CU
The "Organizer" originates the "REQUEST". The recipients of the
"REQUEST" method are the CUs invited to the event, the "Attendees".
"Attendees" use the "REPLY" method to convey attendance status to the
"Organizer".
The "UID" and "SEQUENCE" properties are used to distinguish the
various uses of the "REQUEST" method. If the "UID" property value in
the "REQUEST" is not found on the recipient's calendar, then the
"REQUEST" is for a new "VEVENT" calendar component. If the "UID"
property value is found on the recipient's calendar, then the
"REQUEST" is for a rescheduling, an update, or a reconfirm of the
"VEVENT" calendar component.
For the "REQUEST" method, multiple "VEVENT" components in a single
iCalendar object are only permitted when for components with the same
"UID" property. That is, a series of recurring events may have
instance-specific information. In this case, multiple "VEVENT"
components are needed to express the entire series.
This method type is an iCalendar object that conforms to the
following property constraints:
+----------------------------------------------+
| Constraints for a METHOD:REQUEST of a VEVENT |
+----------------------------------------------+
+--------------------+----------+-----------------------------------+
| Component/Property | Presence | Comment |
+--------------------+----------+-----------------------------------+
| METHOD | 1 | MUST be "REQUEST" |
Daboo Expires May 7, 2009 [Page 19]
Internet-Draft iTIP November 2008
| | | |
| VEVENT | 1+ | All components MUST have the same |
| | | UID |
| ATTENDEE | 1+ | |
| DTSTAMP | 1 | |
| DTSTART | 1 | |
| ORGANIZER | 1 | |
| SEQUENCE | 0 or 1 | MUST be present if value is |
| | | greater than 0, MAY be present if |
| | | 0 |
| SUMMARY | 1 | Can be null |
| UID | 1 | |
| ATTACH | 0+ | |
| CATEGORIES | 0+ | |
| CLASS | 0 or 1 | |
| COMMENT | 0+ | |
| CONTACT | 0+ | |
| CREATED | 0 or 1 | |
| DESCRIPTION | 0 or 1 | Can be null |
| DTEND | 0 or 1 | if present DURATION MUST NOT be |
| | | present |
| DURATION | 0 or 1 | if present DTEND MUST NOT be |
| | | present |
| EXDATE | 0+ | |
| GEO | 0 or 1 | |
| LAST-MODIFIED | 0 or 1 | |
| LOCATION | 0 or 1 | |
| PRIORITY | 0 or 1 | |
| RDATE | 0+ | |
| RECURRENCE-ID | 0 or 1 | Only if referring to an instance |
| | | of a recurring calendar |
| | | component. Otherwise it MUST NOT |
| | | be present. |
| RELATED-TO | 0+ | |
| REQUEST-STATUS | 0+ | |
| RESOURCES | 0+ | |
| RRULE | 0 or 1 | |
| STATUS | 0 or 1 | MAY be one of TENTATIVE/CONFIRMED |
| TRANSP | 0 or 1 | |
| URL | 0 or 1 | |
| IANA-PROPERTY | 0+ | |
| X-PROPERTY | 0+ | |
| | | |
| VALARM | 0+ | |
| | | |
| VTIMEZONE | 0+ | MUST be present if any date/time |
| | | refers to a timezone |
| | | |
Daboo Expires May 7, 2009 [Page 20]
Internet-Draft iTIP November 2008
| IANA-COMPONENT | 0+ | |
| X-COMPONENT | 0+ | |
| | | |
| VFREEBUSY | 0 | |
| | | |
| VJOURNAL | 0 | |
| | | |
| VTODO | 0 | |
+--------------------+----------+-----------------------------------+
3.2.2.1. Rescheduling an Event
The "REQUEST" method may be used to reschedule an event. A
rescheduled event involves a change to the existing event in terms of
its time or recurrence intervals and possibly the location or
description. If the recipient CUA of a "REQUEST" method finds that
the "UID" property value already exists on the calendar, but that the
"SEQUENCE" (or "DTSTAMP") property value in the "REQUEST" method is
greater than the value for the existing event, then the "REQUEST"
method describes a rescheduling of the event.
3.2.2.2. Updating or Reconfirmation of an Event
The "REQUEST" method may be used to update or reconfirm an event. An
update to an existing event does not involve changes to the time or
recurrence intervals, and might not involve a change to the location
or description for the event. If the recipient CUA of a "REQUEST"
method finds that the "UID" property value already exists on the
calendar and that the "SEQUENCE" property value in the "REQUEST" is
the same as the value for the existing event, then the "REQUEST"
method describes an update of the event details, but no rescheduling
of the event.
The update "REQUEST" method is the appropriate response to a
"REFRESH" method sent from an "Attendee" to the "Organizer" of an
event.
The "Organizer" of an event may also send unsolicited "REQUEST"
methods. The unsolicited "REQUEST" methods may be used to update the
details of the event without rescheduling it, to update the
"PARTSTAT" parameter of "Attendees", or to reconfirm the event.
3.2.2.3. Delegating an Event to another CU
Some calendar and scheduling systems allow "Attendees" to delegate
their presence at an event to another calendar user. ITIP supports
this concept using the following workflow. Any "Attendee" may
delegate their right to participate in a calendar VEVENT to another
Daboo Expires May 7, 2009 [Page 21]
Internet-Draft iTIP November 2008
CU. The implication is that the delegate participates in lieu of the
original "Attendee"; NOT in addition to the "Attendee". The
delegator MUST notify the "Organizer" of this action using the steps
outlined below. Implementations may support or restrict delegation
as they see fit. For instance, some implementations may restrict a
delegate from delegating a "REQUEST" to another CU.
The "Delegator" of an event forwards the existing "REQUEST" to the
"Delegate". The "REQUEST" method MUST include an "ATTENDEE" property
with the calendar address of the "Delegate". The "Delegator" MUST
also send a "REPLY" method to the "Organizer" with the "Delegator's"
"ATTENDEE" property "PARTSTAT" parameter value set to "DELEGATED".
In addition, the "DELEGATED-TO" parameter MUST be included with the
calendar address of the "Delegate". Also, a new "ATTENDEE" property
for the "Delegate" MUST be included and must specify the calendar
user address set in the "DELEGATED-TO" parameter, as above.
In response to the request, the "Delegate" MUST send a "REPLY" method
to the "Organizer" and optionally, to the "Delegator". The "REPLY"
method SHOULD include the "ATTENDEE" property with the "DELEGATED-
FROM" parameter value of the "Delegator's" calendar address.
The "Delegator" may continue to receive updates to the event even
though they will not be attending. This is accomplished by the
"Delegator" setting their "role" attribute to " NON-PARTICIPANT" in
the "REPLY" to the "Organizer"
3.2.2.4. Changing the Organizer
The situation may arise where the "Organizer" of a VEVENT is no
longer able to perform the "Organizer" role and abdicates without
passing on the "Organizer" role to someone else. When this occurs
the "Attendees" of the VEVENT may use out-of-band mechanisms to
communicate the situation and agree upon a new "Organizer". The new
"Organizer" should then send out a new "REQUEST" with a modified
version of the VEVENT in which the "SEQUENCE" number has been
incremented and the "ORGANIZER" property has been changed to the new
"Organizer".
3.2.2.5. Sending on Behalf of the Organizer
There are a number of scenarios that support the need for a calendar
user to act on behalf of the "Organizer" without explicit role
changing. This might be the case if the CU designated as "Organizer"
was sick or unable to perform duties associated with that function.
In these cases iTIP supports the notion of one CU acting on behalf of
another. Using the "SENT-BY" parameter, a calendar user could send
an updated "VEVENT" REQUEST. In the case where one CU sends on
Daboo Expires May 7, 2009 [Page 22]
Internet-Draft iTIP November 2008
behalf of another CU, the "Attendee" responses are still directed
back towards the CU designated as "Organizer".
3.2.2.6. Forwarding to An Uninvited CU
An "Attendee" invited to an event may invite another uninvited CU to
the event. The invited "Attendee" accomplishes this by forwarding
the original "REQUEST" method to the uninvited CU. The uninvited CU
then replies to the "Organizer". The "Organizer" decides whether or
not the uninvited CU is added to the attendee list. If the
"Organizer" decides not to add the uninvited CU no further action is
required, however the "Organizer" MAY send the uninvited CU a
"CANCEL" message. If the "Organizer" decides to add an uninvited CU,
a new "ATTENDEE" property is added for the uninvited CU with its
property parameters set as the "Organizer" deems appropriate. When
forwarding a "REQUEST" to another CU, the forwarding "Attendee" MUST
NOT make changes to the original message.
3.2.2.7. Updating Attendee Status
The "Organizer" of an event may also request updated status from one
or more "Attendees. The "Organizer" sends a "REQUEST" method to the
"Attendee" and sets the "ATTENDEE;RSVP=TRUE" property parameter. The
"SEQUENCE" property for the event is not changed from its previous
value. A recipient will determine that the only change in the
"REQUEST" is that their "RSVP" property parameter indicates a request
for updated status. The recipient SHOULD respond with a "REPLY"
method indicating their current status with respect to the "REQUEST".
3.2.3. REPLY
The "REPLY" method in a "VEVENT" calendar component is used to
respond (e.g., accept or decline) to a "REQUEST" or to reply to a
delegation "REQUEST". When used to provide a delegation response,
the "Delegator" SHOULD include the calendar address of the "Delegate"
on the "DELEGATED-TO" property parameter of the "Delegator's"
"ATTENDEE" property. The "Delegate" SHOULD include the calendar
address of the "Delegator" on the "DELEGATED-FROM" property parameter
of the "Delegate's" "ATTENDEE" property.
The "REPLY" method is also used when processing of a "REQUEST" fails.
Depending on the value of the "REQUEST-STATUS" property no scheduling
action may have been performed.
The "Organizer" of an event may receive the "REPLY" method from a CU
not in the original "REQUEST". For example, a "REPLY" may be
received from a "Delegate" to an event. In addition, the "REPLY"
method may be received from an unknown CU (a "Party Crasher"). This
Daboo Expires May 7, 2009 [Page 23]
Internet-Draft iTIP November 2008
uninvited "Attendee" may be accepted, or the "Organizer" may cancel
the event for the uninvited "Attendee" by sending a "CANCEL" method
to the uninvited "Attendee".
An "Attendee" MAY include a message to the "Organizer" using the
"COMMENT" property. For example, if the user indicates tentative
acceptance and wants to let the "Organizer" know why, the reason can
be expressed in the "COMMENT" property value.
The "Organizer" may also receive a "REPLY" from one CU on behalf of
another. Like the scenario enumerated above for the "Organizer",
"Attendees" may have another CU respond on their behalf. This is
done using the "SENT-BY" parameter.
The optional properties listed in the table below (those listed as
"0+" or "0 or 1") MUST NOT be changed from those of the original
request. If property changes are desired the COUNTER message must be
used.
This method type is an iCalendar object that conforms to the
following property constraints:
+--------------------------------------------+
| Constraints for a METHOD:REPLY of a VEVENT |
+--------------------------------------------+
+--------------------+----------+-----------------------------------+
| Component/Property | Presence | Comment |
+--------------------+----------+-----------------------------------+
| METHOD | 1 | MUST be "REPLY" |
| | | |
| VEVENT | 1+ | All components MUST have the same |
| | | UID |
| ATTENDEE | 1 | MUST be the address of the |
| | | Attendee replying. |
| DTSTAMP | 1 | |
| ORGANIZER | 1 | |
| RECURRENCE-ID | 0 or 1 | Only if referring to an instance |
| | | of a recurring calendar |
| | | component. Otherwise it MUST NOT |
| | | be present. |
| UID | 1 | MUST be the UID of the original |
| | | REQUEST |
| SEQUENCE | 0 or 1 | MUST if non-zero, MUST be the |
| | | sequence number of the original |
| | | REQUEST. MAY be present if 0. |
| ATTACH | 0+ | |
| CATEGORIES | 0+ | |
Daboo Expires May 7, 2009 [Page 24]
Internet-Draft iTIP November 2008
| CLASS | 0 or 1 | |
| COMMENT | 0+ | |
| CONTACT | 0+ | |
| CREATED | 0 or 1 | |
| DESCRIPTION | 0 or 1 | |
| DTEND | 0 or 1 | if present DURATION MUST NOT be |
| | | present |
| DTSTART | 0 or 1 | |
| DURATION | 0 or 1 | if present DTEND MUST NOT be |
| | | present |
| EXDATE | 0+ | |
| GEO | 0 or 1 | |
| LAST-MODIFIED | 0 or 1 | |
| LOCATION | 0 or 1 | |
| PRIORITY | 0 or 1 | |
| RDATE | 0+ | |
| RELATED-TO | 0+ | |
| RESOURCES | 0+ | |
| REQUEST-STATUS | 0+ | |
| RRULE | 0 or 1 | |
| STATUS | 0 or 1 | |
| SUMMARY | 0 or 1 | |
| TRANSP | 0 or 1 | |
| URL | 0 or 1 | |
| IANA-PROPERTY | 0+ | |
| X-PROPERTY | 0+ | |
| | | |
| VALARM | 0 | |
| | | |
| VTIMEZONE | 0 or 1 | MUST be present if any date/time |
| | | refers to a timezone |
| | | |
| IANA-COMPONENT | 0+ | |
| X-COMPONENT | 0+ | |
| | | |
| VFREEBUSY | 0 | |
| | | |
| VJOURNAL | 0 | |
| | | |
| VTODO | 0 | |
+--------------------+----------+-----------------------------------+
3.2.4. ADD
The "ADD" method allows the "Organizer" to add one or more new
instances to an existing "VEVENT" using a single ITIP message without
having to send the entire "VEVENT" with all the existing instance
data, as it would have to do if the "REQUEST" method were used.
Daboo Expires May 7, 2009 [Page 25]
Internet-Draft iTIP November 2008
The "UID" must be that of the existing event. If the "UID" property
value in the "ADD" is not found on the recipient's calendar, then the
recipient SHOULD send a "REFRESH" to the "Organizer" in order to be
updated with the latest version of the "VEVENT". If an "Attendee"
implementation does not support the "ADD" method it should respond
with a "REQUEST-STATUS" value of 3.14 and ask for a "REFRESH".
This method type is an iCalendar object that conforms to the
following property constraints:
+------------------------------------------+
| Constraints for a METHOD:ADD of a VEVENT |
+------------------------------------------+
+--------------------+----------+-----------------------------------+
| Component/Property | Presence | Comment |
+--------------------+----------+-----------------------------------+
| METHOD | 1 | MUST be "ADD" |
| | | |
| VEVENT | 1 | |
| DTSTAMP | 1 | |
| DTSTART | 1 | |
| ORGANIZER | 1 | |
| SEQUENCE | 1 | MUST be greater than 0 |
| SUMMARY | 1 | Can be null |
| UID | 1 | MUST match that of the original |
| | | event |
| ATTACH | 0+ | |
| ATTENDEE | 0+ | |
| CATEGORIES | 0+ | |
| CLASS | 0 or 1 | |
| COMMENT | 0+ | |
| CONTACT | 0+ | |
| CREATED | 0 or 1 | |
| DESCRIPTION | 0 or 1 | Can be null |
| DTEND | 0 or 1 | if present DURATION MUST NOT be |
| | | present |
| DURATION | 0 or 1 | if present DTEND MUST NOT be |
| | | present |
| EXDATE | 0+ | |
| GEO | 0 or 1 | |
| LAST-MODIFIED | 0 or 1 | |
| LOCATION | 0 or 1 | |
| PRIORITY | 0 or 1 | |
| RDATE | 0+ | |
| RELATED-TO | 0+ | |
| RESOURCES | 0+ | |
| RRULE | 0 or 1 | |
Daboo Expires May 7, 2009 [Page 26]
Internet-Draft iTIP November 2008
| STATUS | 0 or 1 | MAY be one of TENTATIVE/CONFIRMED |
| TRANSP | 0 or 1 | |
| URL | 0 or 1 | |
| IANA-PROPERTY | 0+ | |
| X-PROPERTY | 0+ | |
| RECURRENCE-ID | 0 | |
| REQUEST-STATUS | 0 | |
| | | |
| VALARM | 0+ | |
| | | |
| VTIMEZONE | 0+ | MUST be present if any date/time |
| | | refers to a timezone |
| | | |
| IANA-COMPONENT | 0+ | |
| X-COMPONENT | 0+ | |
| | | |
| VFREEBUSY | 0 | |
| | | |
| VTODO | 0 | |
| | | |
| VJOURNAL | 0 | |
+--------------------+----------+-----------------------------------+
3.2.5. CANCEL
The "CANCEL" method in a "VEVENT" calendar component is used to send
a cancellation notice of an existing event request to the affected
"Attendees". The message is sent by the "Organizer" of the event.
For a recurring event, either the whole event or instances of an
event may be cancelled. To cancel the complete range of recurring
event, the "UID" property value for the event MUST be specified and a
"RECURRENCE-ID" MUST NOT be specified in the "CANCEL" method. In
order to cancel an individual instance of the event, the
"RECURRENCE-ID" property value for the event MUST be specified in the
"CANCEL" method.
There are two options for canceling a sequence of instances of a
recurring "VEVENT" calendar component:
a. the "RECURRENCE-ID" property for an instance in the sequence MUST
be specified with the "RANGE" property parameter value of
"THISANDFUTURE" to indicate cancellation of the specified
"VEVENT" calendar component and all instances after; or
b. individual recurrence instances may be cancelled by specifying
multiple "VEVENT" components each with a "RECURRENCE-ID" property
corresponding to one of the instances to be cancelled.
When a "VEVENT" is cancelled, the "SEQUENCE" property value MUST be
Daboo Expires May 7, 2009 [Page 27]
Internet-Draft iTIP November 2008
incremented.
This method type is an iCalendar object that conforms to the
following property constraints:
+---------------------------------------------+
| Constraints for a METHOD:CANCEL of a VEVENT |
+---------------------------------------------+
+--------------------+----------+-----------------------------------+
| Component/Property | Presence | Comment |
+--------------------+----------+-----------------------------------+
| METHOD | 1 | MUST be "CANCEL" |
| | | |
| VEVENT | 1+ | All must have the same UID |
| ATTENDEE | 0+ | MUST include all "Attendees" |
| | | being removed from the event. |
| | | MUST include all "Attendees" if |
| | | the entire event is cancelled. |
| DTSTAMP | 1 | |
| ORGANIZER | 1 | |
| SEQUENCE | 1 | |
| UID | 1 | MUST be the UID of the original |
| | | REQUEST |
| COMMENT | 0+ | |
| ATTACH | 0+ | |
| CATEGORIES | 0+ | |
| CLASS | 0 or 1 | |
| CONTACT | 0+ | |
| CREATED | 0 or 1 | |
| DESCRIPTION | 0 or 1 | |
| DTEND | 0 or 1 | if present DURATION MUST NOT be |
| | | present |
| DTSTART | 0 or 1 | |
| DURATION | 0 or 1 | if present DTEND MUST NOT be |
| | | present |
| EXDATE | 0+ | |
| GEO | 0 or 1 | |
| LAST-MODIFIED | 0 or 1 | |
| LOCATION | 0 or 1 | |
| PRIORITY | 0 or 1 | |
| RDATE | 0+ | |
| RECURRENCE-ID | 0 or 1 | Only if referring to an instance |
| | | of a recurring calendar |
| | | component. Otherwise it MUST NOT |
| | | be present. |
| RELATED-TO | 0+ | |
| RESOURCES | 0+ | |
Daboo Expires May 7, 2009 [Page 28]
Internet-Draft iTIP November 2008
| RRULE | 0 or 1 | |
| STATUS | 0 or 1 | MUST be set to CANCELLED to |
| | | cancel the entire event. If |
| | | uninviting specific "Attendees" |
| | | then MUST NOT be included. |
| SUMMARY | 0 or 1 | |
| TRANSP | 0 or 1 | |
| URL | 0 or 1 | |
| IANA-PROPERTY | 0+ | |
| X-PROPERTY | 0+ | |
| REQUEST-STATUS | 0 | |
| | | |
| VALARM | 0 | |
| | | |
| VTIMEZONE | 0+ | MUST be present if any date/time |
| | | refers to a timezone |
| | | |
| IANA-COMPONENT | 0+ | |
| X-COMPONENT | 0+ | |
| | | |
| VTODO | 0 | |
| | | |
| VJOURNAL | 0 | |
| | | |
| VFREEBUSY | 0 | |
+--------------------+----------+-----------------------------------+
3.2.6. REFRESH
The "REFRESH" method in a "VEVENT" calendar component is used by
"Attendees" of an existing event to request an updated description
from the event "Organizer". The "REFRESH" method must specify the
"UID" property of the event to update. A recurrence instance of an
event may be requested by specifying the "RECURRENCE-ID" property
corresponding to the associated event. The "Organizer" responds with
the latest description and version of the event.
This method type is an iCalendar object that conforms to the
following property constraints:
+----------------------------------------------+
| Constraints for a METHOD:REFRESH of a VEVENT |
+----------------------------------------------+
+--------------------+----------+-----------------------------------+
| Component/Property | Presence | Comment |
+--------------------+----------+-----------------------------------+
| METHOD | 1 | MUST be "REFRESH" |
Daboo Expires May 7, 2009 [Page 29]
Internet-Draft iTIP November 2008
| | | |
| VEVENT | 1 | |
| ATTENDEE | 1 | MUST be the address of requester |
| DTSTAMP | 1 | |
| ORGANIZER | 1 | |
| UID | 1 | MUST be the UID associated with |
| | | original REQUEST |
| COMMENT | 0+ | |
| RECURRENCE-ID | 0 or 1 | Only if referring to an instance |
| | | of a recurring calendar |
| | | component. Otherwise it MUST NOT |
| | | be present. |
| IANA-PROPERTY | 0+ | |
| X-PROPERTY | 0+ | |
| ATTACH | 0 | |
| CATEGORIES | 0 | |
| CLASS | 0 | |
| CONTACT | 0 | |
| CREATED | 0 | |
| DESCRIPTION | 0 | |
| DTEND | 0 | |
| DTSTART | 0 | |
| DURATION | 0 | |
| EXDATE | 0 | |
| GEO | 0 | |
| LAST-MODIFIED | 0 | |
| LOCATION | 0 | |
| PRIORITY | 0 | |
| RDATE | 0 | |
| RELATED-TO | 0 | |
| REQUEST-STATUS | 0 | |
| RESOURCES | 0 | |
| RRULE | 0 | |
| SEQUENCE | 0 | |
| STATUS | 0 | |
| SUMMARY | 0 | |
| TRANSP | 0 | |
| URL | 0 | |
| | | |
| VALARM | 0 | |
| | | |
| VTIMEZONE | 0+ | |
| | | |
| IANA-COMPONENT | 0+ | |
| X-COMPONENT | 0+ | |
| | | |
| VTODO | 0 | |
| | | |
Daboo Expires May 7, 2009 [Page 30]
Internet-Draft iTIP November 2008
| VJOURNAL | 0 | |
| | | |
| VFREEBUSY | 0 | |
+--------------------+----------+-----------------------------------+
3.2.7. COUNTER
The "COUNTER" method for a "VEVENT" calendar component is used by an
"Attendee" of an existing event to submit to the "Organizer" a
counter proposal to the event. The "Attendee" sends this message to
the "Organizer" of the event.
The counter proposal is an iCalendar object consisting of a VEVENT
calendar component describing the complete description of the
alternate event.
The "Organizer" rejects the counter proposal by sending the
"Attendee" a VEVENT "DECLINECOUNTER" method. The "Organizer" accepts
the counter proposal by rescheduling the event as described in
section 3.2.2.1 Rescheduling an Event.
This method type is an iCalendar object that conforms to the
following property constraints:
+----------------------------------------------+
| Constraints for a METHOD:COUNTER of a VEVENT |
+----------------------------------------------+
+--------------------+----------+-----------------------------------+
| Component/Property | Presence | Comment |
+--------------------+----------+-----------------------------------+
| METHOD | 1 | MUST be "COUNTER" |
| | | |
| VEVENT | 1 | |
| DTSTAMP | 1 | |
| DTSTART | 1 | |
| ORGANIZER | 1 | MUST be the "Organizer" of the |
| | | original event |
| SEQUENCE | 1 | MUST echo the original SEQUENCE |
| | | number. MUST be present if |
| | | non-zero. MAY be present if |
| | | zero. |
| SUMMARY | 1 | Can be null |
| UID | 1 | MUST be the UID associated with |
| | | the REQUEST being countered |
| ATTACH | 0+ | |
| ATTENDEE | 0+ | Can also be used to propose other |
| | | "Attendees" |
Daboo Expires May 7, 2009 [Page 31]
Internet-Draft iTIP November 2008
| CATEGORIES | 0+ | |
| CLASS | 0 or 1 | |
| COMMENT | 0+ | |
| CONTACT | 0+ | |
| CREATED | 0 or 1 | |
| DESCRIPTION | 0 or 1 | |
| DTEND | 0 or 1 | if present DURATION MUST NOT be |
| | | present |
| DURATION | 0 or 1 | if present DTEND MUST NOT be |
| | | present |
| EXDATE | 0+ | |
| GEO | 0 or 1 | |
| LAST-MODIFIED | 0 or 1 | |
| LOCATION | 0 or 1 | |
| PRIORITY | 0 or 1 | |
| RDATE | 0+ | |
| RECURRENCE-ID | 0 or 1 | Only if referring to an instance |
| | | of a recurring calendar |
| | | component. Otherwise it MUST NOT |
| | | be present. |
| RELATED-TO | 0+ | |
| REQUEST-STATUS | 0+ | |
| RESOURCES | 0+ | |
| RRULE | 0 or 1 | |
| STATUS | 0 or 1 | Value must be one of |
| | | CONFIRMED/TENATIVE/CANCELLED |
| TRANSP | 0 or 1 | |
| URL | 0 or 1 | |
| IANA-PROPERTY | 0+ | |
| X-PROPERTY | 0+ | |
| | | |
| VALARM | 0+ | |
| | | |
| VTIMEZONE | 0+ | MUST be present if any date/time |
| | | refers to a timezone |
| | | |
| IANA-COMPONENT | 0+ | |
| X-COMPONENT | 0+ | |
| | | |
| VTODO | 0 | |
| | | |
| VJOURNAL | 0 | |
| | | |
| VFREEBUSY | 0 | |
+--------------------+----------+-----------------------------------+
Daboo Expires May 7, 2009 [Page 32]
Internet-Draft iTIP November 2008
3.2.8. DECLINECOUNTER
The "DECLINECOUNTER" method in a "VEVENT" calendar component is used
by the "Organizer" of an event to reject a counter proposal submitted
by an "Attendee". The "Organizer" must send the "DECLINECOUNTER"
message to the "Attendee" that sent the "COUNTER" method to the
"Organizer".
This method type is an iCalendar object that conforms to the
following property constraints:
+-----------------------------------------------------+
| Constraints for a METHOD:DECLINECOUNTER of a VEVENT |
+-----------------------------------------------------+
+--------------------+----------+-----------------------------------+
| Component/Property | Presence | Comment |
+--------------------+----------+-----------------------------------+
| METHOD | 1 | MUST be "DECLINECOUNTER" |
| | | |
| VEVENT | 1 | |
| DTSTAMP | 1 | |
| ORGANIZER | 1 | |
| UID | 1 | MUST, same UID specified in |
| | | original REQUEST and subsequent |
| | | COUNTER |
| COMMENT | 0+ | |
| RECURRENCE-ID | 0 or 1 | Only if referring to an instance |
| | | of a recurring calendar |
| | | component. Otherwise it MUST NOT |
| | | be present. |
| REQUEST-STATUS | 0+ | |
| SEQUENCE | 0 or 1 | MUST be present if value is |
| | | greater than 0, MAY be present if |
| | | 0 |
| IANA-PROPERTY | 0+ | |
| X-PROPERTY | 0+ | |
| ATTACH | 0 | |
| ATTENDEE | 0 | |
| CATEGORIES | 0 | |
| CLASS | 0 | |
| CONTACT | 0 | |
| CREATED | 0 | |
| DESCRIPTION | 0 | |
| DTEND | 0 | |
| DTSTART | 0 | |
| DURATION | 0 | |
| EXDATE | 0 | |
Daboo Expires May 7, 2009 [Page 33]
Internet-Draft iTIP November 2008
| GEO | 0 | |
| LAST-MODIFIED | 0 | |
| LOCATION | 0 | |
| PRIORITY | 0 | |
| RDATE | 0 | |
| RELATED-TO | 0 | |
| RESOURCES | 0 | |
| RRULE | 0 | |
| STATUS | 0 | |
| SUMMARY | 0 | |
| TRANSP | 0 | |
| URL | 0 | |
| | | |
| VALARM | 0 | |
| | | |
| VTIMEZONE | 0+ | |
| | | |
| IANA-COMPONENT | 0+ | |
| X-COMPONENT | 0+ | |
| | | |
| VTODO | 0 | |
| | | |
| VJOURNAL | 0 | |
| | | |
| VFREEBUSY | 0 | |
+--------------------+----------+-----------------------------------+
3.3. Methods For VFREEBUSY Components
This section defines the property set for the methods that are
applicable to the "VFREEBUSY" calendar component. Each of the
methods is defined using a restriction table.
This document only addresses the transfer of busy time information.
Applications desiring free time information MUST infer this from
available busy time information.
The "FREEBUSY" property value MAY include a list of values, separated
by the COMMA character (US-ASCII decimal 44). Alternately, multiple
busy time periods MAY be specified with multiple instances of the
"FREEBUSY" property. Both forms MUST be supported by implementations
conforming to this document. Duplicate busy time periods SHOULD NOT
be specified in an iCalendar object. However, two different busy
time periods MAY overlap.
"FREEBUSY" properties SHOULD be sorted such that their values are in
ascending order, based on the start time, and then the end time, with
the earliest periods first. For example, today's busy time
Daboo Expires May 7, 2009 [Page 34]
Internet-Draft iTIP November 2008
information should appear after yesterday's busy time information.
And the busy time for this half-hour should appear after the busy
time for earlier today. Busy time periods may also span a day
boundary.
The following summarizes the methods that are defined for the
"VFREEBUSY" calendar component.
+---------+-------------------------------------+
| Method | Description |
+---------+-------------------------------------+
| PUBLISH | Publish unsolicited busy time data. |
| | |
| REQUEST | Request busy time data. |
| | |
| REPLY | Reply to a busy time request. |
+---------+-------------------------------------+
3.3.1. PUBLISH
The "PUBLISH" method in a "VFREEBUSY" calendar component is used to
publish busy time data. The method may be sent from one CU to any
other. The purpose of the method is to provide a way to send
unsolicited busy time data. That is, the busy time data is not being
sent as a "REPLY" to the receipt of a "REQUEST" method.
The "ORGANIZER" property MUST be specified in the busy time
information. The value is the CU address of the originator of the
busy time information.
The busy time information within the iCalendar object MAY be grouped
into more than one "VFREEBUSY" calendar component. This capability
allows busy time periods to be grouped according to some common
periodicity, such as a calendar week, month, or year. In this case,
each "VFREEBUSY" calendar component MUST include the "ORGANIZER",
"DTSTART" and "DTEND" properties in order to specify the source of
the busy time information and the date and time interval over which
the busy time information covers.
This method type is an iCalendar object that conforms to the
following property constraints:
+-------------------------------------------------+
| Constraints for a METHOD:PUBLISH of a VFREEBUSY |
+-------------------------------------------------+
Daboo Expires May 7, 2009 [Page 35]
Internet-Draft iTIP November 2008
+--------------------+----------+-----------------------------------+
| Component/Property | Presence | Comment |
+--------------------+----------+-----------------------------------+
| METHOD | 1 | MUST be "PUBLISH" |
| | | |
| VFREEBUSY | 1+ | |
| DTSTAMP | 1 | |
| DTSTART | 1 | DateTime values must be in UTC |
| DTEND | 1 | DateTime values must be in UTC |
| FREEBUSY | 0+ | MUST be BUSYTIME. Multiple |
| | | instances are allowed. Multiple |
| | | instances SHOULD be sorted in |
| | | ascending order |
| ORGANIZER | 1 | MUST contain the address of |
| | | originator of busy time data. |
| UID | 1 | |
| COMMENT | 0+ | |
| CONTACT | 0 or 1 | |
| IANA-PROPERTY | 0+ | |
| X-PROPERTY | 0+ | |
| URL | 0 or 1 | Specifies busy time URL |
| ATTENDEE | 0 | |
| DURATION | 0 | |
| REQUEST-STATUS | 0 | |
| | | |
| VALARM | 0 | |
| | | |
| IANA-COMPONENT | 0+ | |
| X-COMPONENT | 0+ | |
| | | |
| VEVENT | 0 | |
| | | |
| VTODO | 0 | |
| | | |
| VJOURNAL | 0 | |
| | | |
| VTIMEZONE | 0 | |
+--------------------+----------+-----------------------------------+
3.3.2. REQUEST
The "REQUEST" method in a "VFREEBUSY" calendar component is used to
ask a "Calendar User" for their busy time information. The request
may be for a busy time information bounded by a specific date and
time interval.
This message only permits requests for busy time information. The
message is sent from a "Calendar User" requesting the busy time
Daboo Expires May 7, 2009 [Page 36]
Internet-Draft iTIP November 2008
information to one or more intended recipients.
If the originator of the "REQUEST" method is not authorized to make a
busy time request on the recipient's calendar system, then an
exception message SHOULD be returned in a "REPLY" method, but no busy
time data need be returned.
This method type is an iCalendar object that conforms to the
following property constraints:
+-------------------------------------------------+
| Constraints for a METHOD:REQUEST of a VFREEBUSY |
+-------------------------------------------------+
+--------------------+----------+-----------------------------------+
| Component/Property | Presence | Comment |
+--------------------+----------+-----------------------------------+
| METHOD | 1 | MUST be "REQUEST" |
| | | |
| VFREEBUSY | 1 | |
| ATTENDEE | 1+ | contains the calendar user |
| | | addresses of the calendar users |
| | | whose freebusy is being requested |
| DTEND | 1 | DateTime values must be in UTC |
| DTSTAMP | 1 | |
| DTSTART | 1 | DateTime values must be in UTC |
| ORGANIZER | 1 | MUST be the request originator's |
| | | address |
| UID | 1 | |
| COMMENT | 0+ | |
| CONTACT | 0 or 1 | |
| IANA-PROPERTY | 0+ | |
| X-PROPERTY | 0+ | |
| FREEBUSY | 0 | |
| DURATION | 0 | |
| REQUEST-STATUS | 0 | |
| URL | 0 | |
| | | |
| VALARM | 0 | |
| | | |
| IANA-COMPONENT | 0+ | |
| X-COMPONENT | 0+ | |
| | | |
| VEVENT | 0 | |
| | | |
| VTODO | 0 | |
| | | |
| VJOURNAL | 0 | |
Daboo Expires May 7, 2009 [Page 37]
Internet-Draft iTIP November 2008
| | | |
| VTIMEZONE | 0 | |
+--------------------+----------+-----------------------------------+
3.3.3. REPLY
The "REPLY" method in a "VFREEBUSY" calendar component is used to
respond to a busy time request. The method is sent by the recipient
of a busy time request to the originator of the request.
The "REPLY" method may also be used to respond to an unsuccessful
"REQUEST" method. Depending on the "REQUEST-STATUS" value, no busy
time information may be returned.
This method type is an iCalendar object that conforms to the
following property constraints:
+-----------------------------------------------+
| Constraints for a METHOD:REPLY of a VFREEBUSY |
+-----------------------------------------------+
Daboo Expires May 7, 2009 [Page 38]
Internet-Draft iTIP November 2008
+--------------------+----------+-----------------------------------+
| Component/Property | Presence | Comment |
+--------------------+----------+-----------------------------------+
| METHOD | 1 | MUST be "REPLY" |
| | | |
| VFREEBUSY | 1 | |
| ATTENDEE | 1 | MUST be the address of the |
| | | Attendee replying. |
| DTSTAMP | 1 | |
| DTEND | 1 | DateTime values must be in UTC |
| DTSTART | 1 | DateTime values must be in UTC |
| FREEBUSY | 0+ | values MUST all be of the same |
| | | data type. Multiple instances |
| | | SHOULD be sorted in ascending |
| | | order. Values MUST NOT overlap |
| ORGANIZER | 1 | MUST be the request originator's |
| | | address |
| UID | 1 | MUST be the UID of the original |
| | | REQUEST |
| COMMENT | 0+ | |
| CONTACT | 0 or 1 | |
| REQUEST-STATUS | 0+ | |
| URL | 0 or 1 | specifies busy time URL |
| IANA-PROPERTY | 0+ | |
| X-PROPERTY | 0+ | |
| DURATION | 0 | |
| SEQUENCE | 0 | |
| | | |
| VALARM | 0 | |
| | | |
| IANA-COMPONENT | 0+ | |
| X-COMPONENT | 0+ | |
| | | |
| VEVENT | 0 | |
| | | |
| VTODO | 0 | |
| | | |
| VJOURNAL | 0 | |
| | | |
| VTIMEZONE | 0 | |
+--------------------+----------+-----------------------------------+
3.4. Methods For VTODO Components
This section defines the property set for the methods that are
applicable to the "VTODO" calendar component. Each of the methods is
defined using a restriction table that specifies the property
constraints that define the particular method.
Daboo Expires May 7, 2009 [Page 39]
Internet-Draft iTIP November 2008
The following summarizes the methods that are defined for the "VTODO"
calendar component.
+----------------+--------------------------------------------------+
| Method | Description |
+----------------+--------------------------------------------------+
| PUBLISH | Post notification of a VTODO. Used primarily as |
| | a method of advertising the existence of a |
| | VTODO. |
| | |
| REQUEST | Assign a VTODO. This is an explicit assignment |
| | to one or more Calendar Users. The REQUEST |
| | method is also used to update or change an |
| | existing VTODO. Clients that cannot handle |
| | REQUEST MAY degrade the method to treat it as a |
| | PUBLISH. |
| | |
| REPLY | Reply to a VTODO request. Attendees MAY set |
| | PARTSTAT to ACCEPTED, DECLINED, TENTATIVE, |
| | DELEGATED, PARTIAL, and COMPLETED. |
| | |
| ADD | Add one or more instances to an existing to-do. |
| | |
| CANCEL | Cancel one or more instances of an existing |
| | to-do. |
| | |
| REFRESH | A request sent to a VTODO Organizer asking for |
| | the latest version of a VTODO. |
| | |
| COUNTER | Counter a REQUEST with an alternative proposal. |
| | |
| DECLINECOUNTER | Decline a counter proposal by an Attendee. |
+----------------+--------------------------------------------------+
3.4.1. PUBLISH
The "PUBLISH" method in a "VTODO" calendar component has no
associated response. It is simply a posting of an iCalendar object
that maybe added to a calendar. It MUST have an "Organizer". It
MUST NOT have "Attendees". Its expected usage is for encapsulating
an arbitrary "VTODO" calendar component as an iCalendar object. The
"Organizer" MAY subsequently update (with another "PUBLISH" method),
add instances to (with an "ADD" method), or cancel (with a "CANCEL"
method) a previously published "VTODO" calendar component.
This method type is an iCalendar object that conforms to the
following property constraints:
Daboo Expires May 7, 2009 [Page 40]
Internet-Draft iTIP November 2008
+---------------------------------------------+
| Constraints for a METHOD:PUBLISH of a VTODO |
+---------------------------------------------+
+--------------------+----------+-----------------------------------+
| Component/Property | Presence | Comment |
+--------------------+----------+-----------------------------------+
| METHOD | 1 | MUST be "PUBLISH" |
| | | |
| VTODO | 1+ | |
| DTSTAMP | 1 | |
| DTSTART | 1 | |
| OR
