7 Network Working Group C. Daboo, Ed.
8 Request for Comments: 5546 Apple Inc.
9 Obsoletes: 2446 December 2009
11 Category: Standards Track
14 iCalendar Transport-Independent Interoperability Protocol (iTIP)
18 This document specifies a protocol that uses the iCalendar object
19 specification to provide scheduling interoperability between
20 different calendaring systems. This is done without reference to a
21 specific transport protocol so as to allow multiple methods of
22 communication between systems. Subsequent documents will define
23 profiles of this protocol that use specific, interoperable methods of
24 communication between systems.
26 The iCalendar Transport-Independent Interoperability Protocol (iTIP)
27 complements the iCalendar object specification by adding semantics
28 for group scheduling methods commonly available in current
29 calendaring systems. These scheduling methods permit two or more
30 calendaring systems to perform transactions such as publishing,
31 scheduling, rescheduling, responding to scheduling requests,
32 negotiating changes, or canceling.
36 This document specifies an Internet standards track protocol for the
37 Internet community, and requests discussion and suggestions for
38 improvements. Please refer to the current edition of the "Internet
39 Official Protocol Standards" (STD 1) for the standardization state
40 and status of this protocol. Distribution of this memo is unlimited.
44 Copyright (c) 2009 IETF Trust and the persons identified as the
45 document authors. All rights reserved.
47 This document is subject to BCP 78 and the IETF Trust's Legal
48 Provisions Relating to IETF Documents
49 (http://trustee.ietf.org/license-info) in effect on the date of
50 publication of this document. Please review these documents
51 carefully, as they describe your rights and restrictions with respect
52 to this document. Code Components extracted from this document must
58 Daboo Standards Track [Page 1]
60 RFC 5546 iTIP December 2009
63 include Simplified BSD License text as described in Section 4.e of
64 the Trust Legal Provisions and are provided without warranty as
65 described in the BSD License.
67 This document may contain material from IETF Documents or IETF
68 Contributions published or made publicly available before November
69 10, 2008. The person(s) controlling the copyright in some of this
70 material may not have granted the IETF Trust the right to allow
71 modifications of such material outside the IETF Standards Process.
72 Without obtaining an adequate license from the person(s) controlling
73 the copyright in such materials, this document may not be modified
74 outside the IETF Standards Process, and derivative works of it may
75 not be created outside the IETF Standards Process, except to format
76 it for publication as an RFC or to translate it into languages other
81 1. Introduction and Overview .......................................5
82 1.1. Formatting Conventions .....................................5
83 1.2. Related Documents ..........................................6
84 1.3. Roles ......................................................6
85 1.4. Methods ....................................................7
86 2. Interoperability Models .........................................9
87 2.1. Application Protocol ......................................10
88 2.1.1. Scheduling State ...................................10
89 2.1.2. Delegation .........................................10
90 2.1.3. Acting on Behalf of Other Calendar Users ...........11
91 2.1.4. Component Revisions ................................11
92 2.1.5. Message Sequencing .................................12
93 3. Application Protocol Elements ..................................13
94 3.1. Common Component Restriction Tables .......................15
95 3.1.1. VCALENDAR ..........................................15
96 3.1.2. VTIMEZONE ..........................................15
97 3.1.3. VALARM .............................................17
98 3.2. Methods for VEVENT Calendar Components ....................17
99 3.2.1. PUBLISH ............................................18
100 3.2.2. REQUEST ............................................20
101 3.2.3. REPLY ..............................................25
102 3.2.4. ADD ................................................27
103 3.2.5. CANCEL .............................................29
104 3.2.6. REFRESH ............................................31
105 3.2.7. COUNTER ............................................33
106 3.2.8. DECLINECOUNTER .....................................35
107 3.3. Methods for VFREEBUSY Components ..........................37
108 3.3.1. PUBLISH ............................................37
109 3.3.2. REQUEST ............................................40
110 3.3.3. REPLY ..............................................42
114 Daboo Standards Track [Page 2]
116 RFC 5546 iTIP December 2009
119 3.4. Methods for VTODO Components ..............................44
120 3.4.1. PUBLISH ............................................44
121 3.4.2. REQUEST ............................................46
122 3.4.3. REPLY ..............................................51
123 3.4.4. ADD ................................................53
124 3.4.5. CANCEL .............................................55
125 3.4.6. REFRESH ............................................57
126 3.4.7. COUNTER ............................................59
127 3.4.8. DECLINECOUNTER .....................................61
128 3.5. Methods for VJOURNAL Components ...........................62
129 3.5.1. PUBLISH ............................................63
130 3.5.2. ADD ................................................64
131 3.5.3. CANCEL .............................................66
132 3.6. Status Replies ............................................68
133 3.7. Implementation Considerations .............................77
134 3.7.1. Working With Recurrence Instances ..................77
135 3.7.2. Attendee Property Considerations ...................78
136 3.7.3. Extension Tokens ...................................79
137 4. Examples .......................................................79
138 4.1. Published Event Examples ..................................79
139 4.1.1. A Minimal Published Event ..........................80
140 4.1.2. Changing a Published Event .........................80
141 4.1.3. Canceling a Published Event ........................81
142 4.1.4. A Rich Published Event .............................81
143 4.1.5. Anniversaries or Events Attached to Entire Days ....83
144 4.2. Group Event Examples ......................................83
145 4.2.1. A Group Event Request ..............................84
146 4.2.2. Reply to a Group Event Request .....................85
147 4.2.3. Update an Event ....................................85
148 4.2.4. Countering an Event Proposal .......................86
149 4.2.5. Delegating an Event ................................88
150 4.2.6. Delegate Accepts the Meeting .......................90
151 4.2.7. Delegate Declines the Meeting ......................91
152 4.2.8. Forwarding an Event Request ........................92
153 4.2.9. Cancel a Group Event ...............................92
154 4.2.10. Removing Attendees ................................93
155 4.2.11. Replacing the Organizer ...........................95
156 4.3. Busy Time Examples ........................................96
157 4.3.1. Publish Busy Time ..................................96
158 4.3.2. Request Busy Time ..................................96
159 4.3.3. Reply to a Busy Time Request .......................97
160 4.4. Recurring Event and Time Zone Examples ....................98
161 4.4.1. A Recurring Event Spanning Time Zones ..............98
162 4.4.2. Modify a Recurring Instance ........................99
163 4.4.3. Cancel an Instance ................................101
164 4.4.4. Cancel a Recurring Event ..........................101
165 4.4.5. Change All Future Instances .......................102
166 4.4.6. Add a New Instance to a Recurring Event ...........102
170 Daboo Standards Track [Page 3]
172 RFC 5546 iTIP December 2009
175 4.4.7. Add a New Series of Instances to a
176 Recurring Event ...................................103
177 4.4.8. Refreshing a Recurring Event ......................104
178 4.4.9. Counter an Instance of a Recurring Event ..........106
179 4.4.10. Error Reply to a Request .........................107
180 4.5. Group To-Do Examples .....................................108
181 4.5.1. A VTODO Request ...................................109
182 4.5.2. A VTODO Reply .....................................110
183 4.5.3. A VTODO Request for Updated Status ................110
184 4.5.4. A Reply: Percent-Complete .........................111
185 4.5.5. A Reply: Completed ................................111
186 4.5.6. An Updated VTODO Request ..........................112
187 4.5.7. Recurring VTODOs ..................................112
188 4.6. Journal Examples .........................................113
189 4.7. Other Examples ...........................................114
190 4.7.1. Event Refresh .....................................114
191 4.7.2. Bad RECURRENCE-ID .................................114
192 5. Application Protocol Fallbacks ................................116
193 5.1. Partial Implementation ...................................116
194 5.1.1. Event-Related Fallbacks ...........................117
195 5.1.2. Free/Busy-Related Fallbacks .......................119
196 5.1.3. To-Do-Related Fallbacks ...........................120
197 5.1.4. Journal-Related Fallbacks .........................122
198 5.2. Latency Issues ...........................................123
199 5.2.1. Cancellation of an Unknown Calendar Component .....123
200 5.2.2. Unexpected Reply from an Unknown Delegate .........124
201 5.3. Sequence Number ..........................................124
202 6. Security Considerations .......................................124
203 6.1. Security Threats .........................................124
204 6.1.1. Spoofing the Organizer ............................124
205 6.1.2. Spoofing the Attendee .............................124
206 6.1.3. Unauthorized Replacement of the Organizer .........125
207 6.1.4. Eavesdropping and Data Integrity ..................125
208 6.1.5. Flooding a Calendar ...............................125
209 6.1.6. Unauthorized REFRESH Requests .....................125
210 6.2. Recommendations ..........................................125
211 6.2.1. Securing iTIP transactions ........................125
212 6.2.2. Implementation Controls ...........................126
213 6.2.3. Access Controls and Filtering .....................126
214 6.3. Privacy Issues ...........................................126
215 7. IANA Considerations ...........................................127
216 7.1. Registration Template for REQUEST-STATUS Values ..........127
217 7.2. Additions to iCalendar METHOD Registry ...................127
218 7.3. REQUEST-STATUS Value Registry ............................129
219 8. Acknowledgments ...............................................130
220 9. References ....................................................131
221 9.1. Normative References .....................................131
222 9.2. Informative References ...................................131
226 Daboo Standards Track [Page 4]
228 RFC 5546 iTIP December 2009
231 Appendix A. Differences from RFC 2446 ...........................132
232 A.1. Changed Restrictions .....................................132
233 A.2. Deprecated Features ......................................133
235 1. Introduction and Overview
237 This document specifies how calendaring systems use iCalendar
238 [RFC5545] objects to interoperate with other calendaring systems. In
239 particular, it specifies how to schedule events, to-dos, or daily
240 journal entries. It further specifies how to search for available
241 busy time information. It does so in a general way, without
242 specifying how communication between different systems actually takes
243 place. Subsequent documents will specify transport bindings between
244 systems that use this protocol.
246 This protocol is based on messages sent from an originator to one or
247 more recipients. For certain types of messages, a recipient may
248 reply in order to update their status and may also return
249 transaction/request status information. The protocol supports the
250 ability for the message originator to modify or cancel the original
251 message. The protocol also supports the ability for recipients to
252 suggest changes to the originator of a message. The elements of the
253 protocol also define the user roles for its transactions.
255 This specification obsoletes RFC 2446 - a list of important changes
256 is provided in Appendix A.
258 1.1. Formatting Conventions
260 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
261 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
262 document are to be interpreted as described in [RFC2119].
264 Calendaring and scheduling roles are referred to in quoted-strings of
265 text with the first character of each word in upper case. For
266 example, "Organizer" refers to a role of a "Calendar User" (CU)
267 within the scheduling protocol.
269 Calendar components defined by [RFC5545] are referred to with
270 capitalized, quoted-strings of text. All calendar components start
271 with the letter "V". For example, "VEVENT" refers to the event
272 calendar component, "VTODO" refers to the to-do calendar component,
273 and "VJOURNAL" refers to the daily journal calendar component.
282 Daboo Standards Track [Page 5]
284 RFC 5546 iTIP December 2009
287 Scheduling methods are referred to with capitalized, quoted-strings
288 of text. For example, "REQUEST" refers to the method for requesting
289 a scheduling calendar component be created or modified; "REPLY"
290 refers to the method a recipient of a request uses to update their
291 status with the "Organizer" of the calendar component.
293 Properties defined by [RFC5545] are referred to with capitalized,
294 quoted-strings of text, followed by the word "property". For
295 example, "ATTENDEE" property refers to the iCalendar property used to
296 convey the calendar address of a "Calendar User".
298 Property parameters defined by this specification are referred to
299 with capitalized, quoted-strings of text, followed by the word
300 "parameter". For example, "VALUE" parameter refers to the iCalendar
301 property parameter used to override the default data type for a
304 Enumerated values defined by this specification are referred to with
305 capitalized text, either alone or followed by the word "value".
307 In tables, the quoted-string text is specified without quotes in
308 order to minimize the table length.
310 1.2. Related Documents
312 Implementers will need to be familiar with several other
313 specifications that, along with this one, describe the Internet
314 calendaring and scheduling standards. The related documents are:
316 [RFC5545] - specifies the objects, data types, properties, and
317 property parameters used in the protocols, along with the methods
318 for representing and encoding them.
320 [iMIP] - specifies an Internet email binding for iTIP.
322 This specification does not attempt to repeat the concepts or
323 definitions from these other specifications. Where possible,
324 explicit references are made to the other specifications.
328 Exchanges of iCalendar objects for the purposes of group calendaring
329 and scheduling occur between "Calendar Users" (CUs). CUs take on
330 several roles in iTIP:
338 Daboo Standards Track [Page 6]
340 RFC 5546 iTIP December 2009
343 +-----------+-------------------------------------------------------+
344 | Role | Description |
345 +-----------+-------------------------------------------------------+
346 | Organizer | The CU who initiates an exchange takes on the role of |
347 | | Organizer. For example, the CU who proposes a group |
348 | | meeting is the Organizer. |
350 | Attendee | CUs who are included in the scheduling message as |
351 | | possible recipients of that scheduling message. For |
352 | | example, the CUs asked to participate in a group |
353 | | meeting by the Organizer take on the role of |
356 | Other CU | A CU that is not explicitly included in a scheduling |
357 | | message, i.e., not the Organizer or an Attendee. |
358 +-----------+-------------------------------------------------------+
360 Note that "ROLE" is also a descriptive parameter to the iCalendar
361 "ATTENDEE" property. Its use is to convey descriptive context about
362 an "Attendee" -- such as "chair", "required participant", or "non-
363 required participant" -- and has nothing to do with the calendaring
368 The iTIP methods are listed below and their usage and semantics are
369 defined in Section 3 of this document.
394 Daboo Standards Track [Page 7]
396 RFC 5546 iTIP December 2009
399 +----------------+--------------------------------------------------+
400 | Method | Description |
401 +----------------+--------------------------------------------------+
402 | PUBLISH | Used to publish an iCalendar object to one or |
403 | | more "Calendar Users". There is no |
404 | | interactivity between the publisher and any |
405 | | other "Calendar User". An example might include |
406 | | a baseball team publishing its schedule to the |
409 | REQUEST | Used to schedule an iCalendar object with other |
410 | | "Calendar Users". Requests are interactive in |
411 | | that they require the receiver to respond using |
412 | | the reply methods. Meeting requests, busy-time |
413 | | requests, and the assignment of tasks to other |
414 | | "Calendar Users" are all examples. Requests are |
415 | | also used by the Organizer to update the status |
416 | | of an iCalendar object. |
418 | REPLY | A reply is used in response to a request to |
419 | | convey Attendee status to the Organizer. |
420 | | Replies are commonly used to respond to meeting |
421 | | and task requests. |
423 | ADD | Add one or more new instances to an existing |
424 | | recurring iCalendar object. |
426 | CANCEL | Cancel one or more instances of an existing |
427 | | iCalendar object. |
429 | REFRESH | Used by an Attendee to request the latest |
430 | | version of an iCalendar object. |
432 | COUNTER | Used by an Attendee to negotiate a change in an |
433 | | iCalendar object. Examples include the request |
434 | | to change a proposed event time or change the |
435 | | due date for a task. |
437 | DECLINECOUNTER | Used by the Organizer to decline the proposed |
438 | | counter proposal. |
439 +----------------+--------------------------------------------------+
450 Daboo Standards Track [Page 8]
452 RFC 5546 iTIP December 2009
455 Group scheduling in iTIP is accomplished using the set of "request"
456 and "response" methods described above. The following table shows
457 the methods broken down by who can send them.
459 +------------+------------------------------------------------------+
460 | Originator | Methods |
461 +------------+------------------------------------------------------+
462 | Organizer | PUBLISH, REQUEST, ADD, CANCEL, DECLINECOUNTER |
464 | Attendee | REPLY, REFRESH, COUNTER, REQUEST (only when |
466 +------------+------------------------------------------------------+
468 Note that for some calendar component types, the allowable methods
469 are a subset of the above set. In addition, apart from "VTIMEZONE"
470 iCalendar components, only one component type is allowed in a single
473 2. Interoperability Models
475 There are two distinct protocols relevant to interoperability: an
476 "application protocol" and a "transport protocol". The application
477 protocol defines the content of the iCalendar objects sent between
478 sender and receiver to accomplish the scheduling transactions listed
479 above. The transport protocol defines how the iCalendar objects are
480 sent between the sender and receiver. This document focuses on the
481 application protocol. Binding documents such as [iMIP] focus on the
484 The connection between sender and receiver in the diagram below
485 refers to the application protocol. The iCalendar objects passed
486 from the sender to the receiver are presented in Section 3,
487 "Application Protocol Elements".
489 +----------+ +----------+
491 | Sender |<-------------->| Receiver |
493 +----------+ +----------+
495 There are several variations of this diagram in which the sender and
496 receiver take on various roles of a "Calendar User Agent" (CUA) or a
497 "Calendar Service" (CS).
499 The architecture of iTIP is depicted in the diagram below. An
500 application written to this specification may work with bindings for
501 the store-and-forward transport, the real-time transport, or both.
502 Also note that iTIP could be bound to other transports.
506 Daboo Standards Track [Page 9]
508 RFC 5546 iTIP December 2009
511 +--------------------------------------------------------+
513 +--------------------------------------------------------+
515 + - - - - - + - - - - - - + - - - - - +
516 | Real-Time | Store-and-Forward | Others |
517 +-----------------+--------------------+-----------------+
519 2.1. Application Protocol
521 In the iTIP model, an iCalendar object is created and managed by an
522 "Organizer". The "Organizer" interacts with other CUs by sending one
523 or more of the iTIP messages listed above. "Attendees" use the
524 "REPLY" method to communicate their status. "Attendees" do not make
525 direct changes to the master iCalendar object. They can, however,
526 use the "COUNTER" method to suggest changes to the "Organizer". In
527 any case, the "Organizer" has complete control over the master
530 2.1.1. Scheduling State
532 There are two distinct states relevant to iCalendar objects used in
533 scheduling: the overall state of the iCalendar object and the state
534 associated with an "Attendee" in that iCalendar object.
536 The state of an iCalendar object is defined by the "STATUS" property
537 and is controlled by the "Organizer." There is no default value for
538 the "STATUS" property. The "Organizer" sets the "STATUS" property to
539 the appropriate value for each iCalendar object.
541 The state of a particular "Attendee" relative to an iCalendar object
542 used for scheduling is defined by the "PARTSTAT" parameter in the
543 "ATTENDEE" property for each "Attendee". When an "Organizer" issues
544 the initial iCalendar object, "Attendee" status is typically unknown.
545 The "Organizer" specifies this by setting the "PARTSTAT" parameter to
546 "NEEDS-ACTION". Each "Attendee" modifies their "ATTENDEE" property
547 "PARTSTAT" parameter to an appropriate value as part of a "REPLY"
548 message sent back to the "Organizer".
552 Delegation is defined as the process by which an "Attendee" grants
553 another CU (or several CUs) the right to attend on their behalf. The
554 "Organizer" is made aware of this change because the delegating
555 "Attendee" informs the "Organizer". These steps are detailed in the
556 "REQUEST" method sections for the appropriate components.
562 Daboo Standards Track [Page 10]
564 RFC 5546 iTIP December 2009
567 2.1.3. Acting on Behalf of Other Calendar Users
569 In many organizations, one user will act on behalf of another to
570 organize and/or respond to meeting requests. iTIP provides two
571 mechanisms that support these activities.
573 First, the "Organizer" is treated as a special entity, separate from
574 "Attendees". All responses from "Attendees" flow to the "Organizer",
575 making it easy to separate a "Calendar User" organizing a meeting
576 from "Calendar Users" attending the meeting. Additionally, iCalendar
577 provides descriptive roles for each "Attendee". For instance, a role
578 of "chair" may be ascribed to one or more "Attendees". The "chair"
579 and the "Organizer" may or may not be the same "Calendar User". This
580 maps well to scenarios where an assistant may manage meeting
581 logistics for another individual who chairs a meeting.
583 Second, a "SENT-BY" parameter may be specified in either the
584 "Organizer" or "Attendee" properties. When specified, the "SENT-BY"
585 parameter indicates that the responding CU acted on behalf of the
586 specified "Attendee" or "Organizer".
588 2.1.4. Component Revisions
590 The "SEQUENCE" property is used by the "Organizer" to indicate
591 revisions to the calendar component. When the "Organizer" makes
592 changes to one of the following properties, the sequence number MUST
611 In addition, changes made by the "Organizer" to other properties MAY
612 also require the sequence number to be incremented. The "Organizer"
613 CUA MUST increment the sequence number whenever it makes changes to
614 properties in the calendar component that the "Organizer" deems will
618 Daboo Standards Track [Page 11]
620 RFC 5546 iTIP December 2009
623 jeopardize the validity of the participation status of the
624 "Attendees". For example, changing the location of a meeting from
625 one location to another distant location could effectively impact the
626 participation status of the "Attendees".
628 Depending on the "METHOD", the "SEQUENCE" property MUST follow these
629 rules in the context of iTIP:
631 o For the "PUBLISH" and "REQUEST" methods, the "SEQUENCE" property
632 value is incremented according to the rules stated above.
634 o The "SEQUENCE" property value MUST be incremented each time the
635 "Organizer" uses the "ADD" or "CANCEL" methods.
637 o The "SEQUENCE" property value MUST NOT be incremented when using
638 "REPLY", "REFRESH", "COUNTER", "DECLINECOUNTER", or when sending a
639 delegation "REQUEST".
641 In some circumstances, the "Organizer" may not have received
642 responses to the final revision sent out. In this situation, the
643 "Organizer" may wish to send an update "REQUEST" and set "RSVP=TRUE"
644 for all "Attendees" so that current responses can be collected.
646 The value of the "SEQUENCE" property contained in a response from an
647 "Attendee" may not always match the "Organizer's" revision.
648 Implementations may choose to have the CUA indicate to the CU that
649 the response is to an iCalendar object that has been revised, and
650 allow the CU to decide whether or not to accept the response.
652 Whilst a change in sequence number is indicative of a significant
653 change to a previously scheduled item, "Attendee" CUAs SHOULD NOT
654 rely solely on a change in sequence number as a means of detecting a
655 significant change. Instead, CUAs SHOULD compare the old and new
656 versions of the calendar components, determine the exact nature of
657 the changes, and make decisions -- possibly based on "Calendar User"
658 preferences -- as to whether the user needs to be explicitly informed
661 2.1.5. Message Sequencing
663 CUAs that handle the iTIP application protocol must often correlate a
664 component in a calendar store with a component received in the iTIP
665 message. For example, an event may be updated with a later revision
666 of the same event. To accomplish this, a CUA must correlate the
667 version of the event already in its calendar store with the version
668 sent in the iTIP message. In addition to this correlation, there are
669 several factors that can cause iTIP messages to arrive in an
670 unexpected order. That is, an "Organizer" could receive a reply to
674 Daboo Standards Track [Page 12]
676 RFC 5546 iTIP December 2009
679 an earlier revision of a component after receiving a reply to a later
682 To maximize interoperability and to handle messages that arrive in an
683 unexpected order, use the following rules:
685 1. The primary key for referencing a particular iCalendar component
686 is the "UID" property value. To reference an instance of a
687 recurring component, the primary key is composed of the "UID" and
688 the "RECURRENCE-ID" properties.
690 2. The secondary key for referencing a component is the "SEQUENCE"
691 property value. For components where the "UID" and
692 "RECURRENCE-ID" property values are the same, the component with
693 the highest numeric value for the "SEQUENCE" property obsoletes
694 all other revisions of the component with lower values.
696 3. "Attendees" send "REPLY" messages to the "Organizer". For
697 replies where the "UID" and "RECURRENCE-ID" property values are
698 the same, the value of the "SEQUENCE" property indicates the
699 revision of the component to which the "Attendee" is replying.
700 The reply with the highest numeric value for the "SEQUENCE"
701 property obsoletes all other replies with lower values.
703 4. In situations where the "UID", "RECURRENCE-ID", and "SEQUENCE"
704 property values match, the "DTSTAMP" property is used as the tie-
705 breaker. The component with the latest "DTSTAMP" overrides all
706 others. Similarly, for "Attendee" responses where the "UID",
707 "RECURRENCE-ID", and "SEQUENCE" property values match, the
708 response with the latest "DTSTAMP" overrides all others.
710 Hence, CUAs will need to persist the following component properties
711 in order to correctly process iTIP messages: "UID", "RECURRENCE-ID",
712 "SEQUENCE", and "DTSTAMP". Furthermore, for each "ATTENDEE" property
713 of a component, "Organizer" CUAs will need to persist the "SEQUENCE"
714 and "DTSTAMP" property values associated with the "Attendee's" last
715 response, so that any earlier responses from an "Attendee" that are
716 received out of order (e.g., due to a delay in the transport) can be
719 3. Application Protocol Elements
721 iTIP messages are "text/calendar" MIME entities that contain
722 calendaring and scheduling information. The particular type of
723 iCalendar message is referred to as the "method type". Each method
724 type is identified by a "METHOD" property specified as part of the
725 "text/calendar" content type. The table below shows various
730 Daboo Standards Track [Page 13]
732 RFC 5546 iTIP December 2009
735 combinations of calendar components and the method types that this
736 specification supports.
738 +----------------+--------+-------+----------+-----------+
739 | | VEVENT | VTODO | VJOURNAL | VFREEBUSY |
740 +----------------+--------+-------+----------+-----------+
741 | PUBLISH | Yes | Yes | Yes | Yes |
742 | REQUEST | Yes | Yes | No | Yes |
743 | REFRESH | Yes | Yes | No | No |
744 | CANCEL | Yes | Yes | Yes | No |
745 | ADD | Yes | Yes | Yes | No |
746 | REPLY | Yes | Yes | No | Yes |
747 | COUNTER | Yes | Yes | No | No |
748 | DECLINECOUNTER | Yes | Yes | No | No |
749 +----------------+--------+-------+----------+-----------+
751 Each method type is defined in terms of its associated components and
752 properties. Some components and properties are required, some are
753 optional, and others are excluded. The restrictions are expressed in
754 this document using a simple "restriction table". The first column
755 indicates the name of a component or property. Properties of the
756 iCalendar object are not indented. Properties of a component are
757 indented. The second column (the "Presence" column) indicates
758 whether or not a component or property should be present and, if
759 present, how many times it can occur. The third column contains
760 comments for further clarification.
762 The presence column uses the following values to assert whether a
763 property is required or optional, and the number of times it may
764 appear in the iCalendar object.
766 +----------------+--------------------------------------------------+
767 | Presence Value | Description |
768 +----------------+--------------------------------------------------+
769 | 1 | One instance MUST be present. |
770 | 1+ | At least one instance MUST be present. |
771 | 0 | Instances of this property MUST NOT be present. |
772 | 0+ | Multiple instances MAY be present. |
773 | 0 or 1 | Up to 1 instance of this property MAY be |
775 +----------------+--------------------------------------------------+
777 The tables also call out "IANA-PROPERTY", "X-PROPERTY", "IANA-
778 COMPONENT", and "X-COMPONENT" to show where registered and
779 experimental property and component extensions can appear. The
780 tables do not lay out the restrictions of property parameters. Those
781 restrictions are defined in [RFC5545].
786 Daboo Standards Track [Page 14]
788 RFC 5546 iTIP December 2009
791 3.1. Common Component Restriction Tables
795 The restriction table below applies to properties of the iCalendar
796 object. That is, the properties at the outermost scope.
798 +-----------------------------------------------------+
799 | Constraints for Properties in a VCALENDAR Component |
800 +-----------------------------------------------------+
802 +--------------------+----------+--------------------+
803 | Component/Property | Presence | Comment |
804 +--------------------+----------+--------------------+
805 | CALSCALE | 0 or 1 | |
807 | VERSION | 1 | Value MUST be 2.0. |
808 | IANA-PROPERTY | 0+ | |
809 | X-PROPERTY | 0+ | |
810 +--------------------+----------+--------------------+
814 "VTIMEZONE" components may be referred to by other components via a
815 "TZID" parameter on a "DATETIME" value type. The property
816 restrictions in the table below apply to any "VTIMEZONE" component in
819 +--------------------------------------+
820 | Constraints for VTIMEZONE Components |
821 +--------------------------------------+
842 Daboo Standards Track [Page 15]
844 RFC 5546 iTIP December 2009
847 +--------------------+----------+-----------------------------------+
848 | Component/Property | Presence | Comment |
849 +--------------------+----------+-----------------------------------+
850 | VTIMEZONE | 0+ | MUST be present if any date/time |
851 | | | refers to timezone. |
852 | DAYLIGHT | 0+ | MUST be one or more of either |
853 | | | STANDARD or DAYLIGHT. |
855 | DTSTART | 1 | MUST be local time format. |
859 | TZOFFSETFROM | 1 | |
861 | IANA-PROPERTY | 0+ | |
862 | X-PROPERTY | 0+ | |
863 | LAST-MODIFIED | 0 or 1 | |
864 | STANDARD | 0+ | MUST be one or more of either |
865 | | | STANDARD or DAYLIGHT. |
867 | DTSTART | 1 | MUST be local time format. |
868 | RDATE | 0+ | If present, RRULE MUST NOT be |
870 | RRULE | 0 or 1 | If present, RDATE MUST NOT be |
873 | TZOFFSETFROM | 1 | |
875 | IANA-PROPERTY | 0+ | |
876 | X-PROPERTY | 0+ | |
879 | IANA-PROPERTY | 0+ | |
880 | X-PROPERTY | 0+ | |
881 +--------------------+----------+-----------------------------------+
898 Daboo Standards Track [Page 16]
900 RFC 5546 iTIP December 2009
905 The property restrictions in the table below apply to any "VALARM"
906 component in an iTIP message.
908 +-----------------------------------+
909 | Constraints for VALARM Components |
910 +-----------------------------------+
912 +--------------------+----------+-----------------------------------+
913 | Component/Property | Presence | Comment |
914 +--------------------+----------+-----------------------------------+
919 | DESCRIPTION | 0 or 1 | |
920 | DURATION | 0 or 1 | If present, REPEAT MUST be |
922 | REPEAT | 0 or 1 | If present, DURATION MUST be |
924 | SUMMARY | 0 or 1 | |
926 | IANA-PROPERTY | 0+ | |
927 | X-PROPERTY | 0+ | |
928 +--------------------+----------+-----------------------------------+
930 3.2. Methods for VEVENT Calendar Components
932 This section defines the property set restrictions for the method
933 types that are applicable to the "VEVENT" calendar component. Each
934 method is defined using a table that clarifies the property
935 constraints that define the particular method.
937 The following summarizes the methods that are defined for the
938 "VEVENT" calendar component.
954 Daboo Standards Track [Page 17]
956 RFC 5546 iTIP December 2009
959 +----------------+--------------------------------------------------+
960 | Method | Description |
961 +----------------+--------------------------------------------------+
962 | PUBLISH | Post notification of an event. Used primarily |
963 | | as a method of advertising the existence of an |
966 | REQUEST | Make a request for an event. This is an |
967 | | explicit invitation to one or more Attendees. |
968 | | Event requests are also used to update or change |
969 | | an existing event. Clients that cannot handle |
970 | | REQUEST MAY degrade the event to view it as a |
973 | REPLY | Reply to an event request. Clients may set |
974 | | their status (PARTSTAT) to ACCEPTED, DECLINED, |
975 | | TENTATIVE, or DELEGATED. |
977 | ADD | Add one or more instances to an existing event. |
979 | CANCEL | Cancel one or more instances of an existing |
982 | REFRESH | A request is sent to an Organizer by an Attendee |
983 | | asking for the latest version of an event to be |
984 | | resent to the requester. |
986 | COUNTER | Counter a REQUEST with an alternative proposal. |
987 | | Sent by an Attendee to the Organizer. |
989 | DECLINECOUNTER | Decline a counter proposal. Sent to an Attendee |
990 | | by the Organizer. |
991 +----------------+--------------------------------------------------+
995 The "PUBLISH" method in a "VEVENT" calendar component is an
996 unsolicited posting of an iCalendar object. Any CU may add published
997 components to their calendar. The "Organizer" MUST be present in a
998 published iCalendar component. "Attendees" MUST NOT be present. Its
999 expected usage is for encapsulating an arbitrary event as an
1000 iCalendar object. The "Organizer" may subsequently update (with
1001 another "PUBLISH" method), add instances to (with an "ADD" method),
1002 or cancel (with a "CANCEL" method) a previously published "VEVENT"
1005 This method type is an iCalendar object that conforms to the
1006 following property constraints:
1010 Daboo Standards Track [Page 18]
1012 RFC 5546 iTIP December 2009
1015 +----------------------------------------------+
1016 | Constraints for a METHOD:PUBLISH of a VEVENT |
1017 +----------------------------------------------+
1019 +--------------------+----------+-----------------------------------+
1020 | Component/Property | Presence | Comment |
1021 +--------------------+----------+-----------------------------------+
1022 | METHOD | 1 | MUST equal PUBLISH. |
1028 | SUMMARY | 1 | Can be null. |
1030 | RECURRENCE-ID | 0 or 1 | Only if referring to an instance |
1031 | | | of a recurring calendar |
1032 | | | component. Otherwise, it MUST |
1033 | | | NOT be present. |
1034 | SEQUENCE | 0 or 1 | MUST be present if value is |
1035 | | | greater than 0; MAY be present if |
1038 | CATEGORIES | 0+ | |
1039 | CLASS | 0 or 1 | |
1041 | CONTACT | 0 or 1 | |
1042 | CREATED | 0 or 1 | |
1043 | DESCRIPTION | 0 or 1 | Can be null. |
1044 | DTEND | 0 or 1 | If present, DURATION MUST NOT be |
1046 | DURATION | 0 or 1 | If present, DTEND MUST NOT be |
1050 | LAST-MODIFIED | 0 or 1 | |
1051 | LOCATION | 0 or 1 | |
1052 | PRIORITY | 0 or 1 | |
1054 | RELATED-TO | 0+ | |
1055 | RESOURCES | 0+ | |
1056 | RRULE | 0 or 1 | |
1057 | STATUS | 0 or 1 | MAY be one of |
1058 | | | TENTATIVE/CONFIRMED/CANCELLED. |
1059 | TRANSP | 0 or 1 | |
1061 | IANA-PROPERTY | 0+ | |
1062 | X-PROPERTY | 0+ | |
1066 Daboo Standards Track [Page 19]
1068 RFC 5546 iTIP December 2009
1072 | REQUEST-STATUS | 0 | |
1082 | VTIMEZONE | 0+ | MUST be present if any date/time |
1083 | | | refers to a timezone. |
1085 | IANA-COMPONENT | 0+ | |
1086 | X-COMPONENT | 0+ | |
1087 +--------------------+----------+-----------------------------------+
1091 The "REQUEST" method in a "VEVENT" component provides the following
1092 scheduling functions:
1094 o Invite "Attendees" to an event.
1096 o Reschedule an existing event.
1098 o Response to a "REFRESH" request.
1100 o Update the details of an existing event, without rescheduling it.
1102 o Update the status of "Attendees" of an existing event, without
1105 o Reconfirm an existing event, without rescheduling it.
1107 o Forward a "VEVENT" to another uninvited CU.
1109 o For an existing "VEVENT" calendar component, delegate the role of
1110 "Attendee" to another CU.
1112 o For an existing "VEVENT" calendar component, change the role of
1113 "Organizer" to another CU.
1115 The "Organizer" originates the "REQUEST". The recipients of the
1116 "REQUEST" method are the CUs invited to the event, the "Attendees".
1117 "Attendees" use the "REPLY" method to convey attendance status to the
1122 Daboo Standards Track [Page 20]
1124 RFC 5546 iTIP December 2009
1127 The "UID" and "SEQUENCE" properties are used to distinguish the
1128 various uses of the "REQUEST" method. If the "UID" property value in
1129 the "REQUEST" is not found on the recipient's calendar, then the
1130 "REQUEST" is for a new "VEVENT" calendar component. If the "UID"
1131 property value is found on the recipient's calendar, then the
1132 "REQUEST" is for a rescheduling, an update, or a reconfirmation of
1133 the "VEVENT" calendar component.
1135 For the "REQUEST" method, multiple "VEVENT" components in a single
1136 iCalendar object are only permitted for components with the same
1137 "UID" property. That is, a series of recurring events may have
1138 instance-specific information. In this case, multiple "VEVENT"
1139 components are needed to express the entire series.
1141 This method type is an iCalendar object that conforms to the
1142 following property constraints:
1144 +----------------------------------------------+
1145 | Constraints for a METHOD:REQUEST of a VEVENT |
1146 +----------------------------------------------+
1148 +--------------------+----------+-----------------------------------+
1149 | Component/Property | Presence | Comment |
1150 +--------------------+----------+-----------------------------------+
1151 | METHOD | 1 | MUST be REQUEST. |
1153 | VEVENT | 1+ | All components MUST have the same |
1159 | SEQUENCE | 0 or 1 | MUST be present if value is |
1160 | | | greater than 0; MAY be present if |
1162 | SUMMARY | 1 | Can be null. |
1165 | CATEGORIES | 0+ | |
1166 | CLASS | 0 or 1 | |
1169 | CREATED | 0 or 1 | |
1170 | DESCRIPTION | 0 or 1 | Can be null. |
1171 | DTEND | 0 or 1 | If present, DURATION MUST NOT be |
1178 Daboo Standards Track [Page 21]
1180 RFC 5546 iTIP December 2009
1183 | DURATION | 0 or 1 | If present, DTEND MUST NOT be |
1187 | LAST-MODIFIED | 0 or 1 | |
1188 | LOCATION | 0 or 1 | |
1189 | PRIORITY | 0 or 1 | |
1191 | RECURRENCE-ID | 0 or 1 | Only if referring to an instance |
1192 | | | of a recurring calendar |
1193 | | | component. Otherwise, it MUST |
1194 | | | NOT be present. |
1195 | RELATED-TO | 0+ | |
1196 | REQUEST-STATUS | 0 | |
1197 | RESOURCES | 0+ | |
1198 | RRULE | 0 or 1 | |
1199 | STATUS | 0 or 1 | MAY be one of |
1200 | | | TENTATIVE/CONFIRMED. |
1201 | TRANSP | 0 or 1 | |
1203 | IANA-PROPERTY | 0+ | |
1204 | X-PROPERTY | 0+ | |
1208 | VTIMEZONE | 0+ | MUST be present if any date/time |
1209 | | | refers to a timezone. |
1211 | IANA-COMPONENT | 0+ | |
1212 | X-COMPONENT | 0+ | |
1219 +--------------------+----------+-----------------------------------+
1221 3.2.2.1. Rescheduling an Event
1223 The "REQUEST" method may be used to reschedule an event. A
1224 rescheduled event involves a change to the existing event in terms of
1225 its time or recurrence intervals and possibly the location or
1226 description. If the recipient CUA of a "REQUEST" method finds that
1227 the "UID" property value already exists on the calendar but that the
1228 "SEQUENCE" (or "DTSTAMP") property value in the "REQUEST" method is
1229 greater than the value for the existing event, then the "REQUEST"
1230 method describes a rescheduling of the event.
1234 Daboo Standards Track [Page 22]
1236 RFC 5546 iTIP December 2009
1239 3.2.2.2. Updating or Reconfirmation of an Event
1241 The "REQUEST" method may be used to update or reconfirm an event. An
1242 update to an existing event does not involve changes to the time or
1243 recurrence intervals, and might not involve a change to the location
1244 or description for the event. If the recipient CUA of a "REQUEST"
1245 method finds that the "UID" property value already exists on the
1246 calendar and that the "SEQUENCE" property value in the "REQUEST" is
1247 the same as the value for the existing event, then the "REQUEST"
1248 method describes an update of the event details, but not a
1249 rescheduling of the event.
1251 The update "REQUEST" method is the appropriate response to a
1252 "REFRESH" method sent from an "Attendee" to the "Organizer" of an
1255 The "Organizer" of an event may also send unsolicited "REQUEST"
1256 methods. The unsolicited "REQUEST" methods may be used to update the
1257 details of the event without rescheduling it, to update the
1258 "PARTSTAT" parameter of "Attendees", or to reconfirm the event.
1260 3.2.2.3. Delegating an Event to Another CU
1262 Some calendar and scheduling systems allow "Attendees" to delegate
1263 their presence at an event to another "Calendar User". iTIP supports
1264 this concept using the following workflow. Any "Attendee" may
1265 delegate their right to participate in a calendar "VEVENT" to another
1266 CU. The implication is that the delegate participates in lieu of the
1267 original "Attendee", NOT in addition to the "Attendee". The
1268 delegator MUST notify the "Organizer" of this action using the steps
1269 outlined below. Implementations may support or restrict delegation
1270 as they see fit. For instance, some implementations may restrict a
1271 delegate from delegating a "REQUEST" to another CU.
1273 The "Delegator" of an event forwards the existing "REQUEST" to the
1274 "Delegate". The "REQUEST" method MUST include an "ATTENDEE" property
1275 with the calendar address of the "Delegate". The "Delegator" MUST
1276 also send a "REPLY" method to the "Organizer" with the "Delegator's"
1277 "ATTENDEE" property "PARTSTAT" parameter value set to "DELEGATED".
1278 In addition, the "DELEGATED-TO" parameter MUST be included with the
1279 calendar address of the "Delegate". Also, a new "ATTENDEE" property
1280 for the "Delegate" MUST be included and must specify the calendar
1281 user address set in the "DELEGATED-TO" parameter, as above.
1283 In response to the request, the "Delegate" MUST send a "REPLY" method
1284 to the "Organizer", and optionally to the "Delegator". The "REPLY"
1285 method SHOULD include the "ATTENDEE" property with the "DELEGATED-
1286 FROM" parameter value of the "Delegator's" calendar address.
1290 Daboo Standards Track [Page 23]
1292 RFC 5546 iTIP December 2009
1295 The "Delegator" may continue to receive updates to the event even
1296 though they will not be attending. This is accomplished by the
1297 "Delegator" setting their "role" attribute to "NON-PARTICIPANT" in
1298 the "REPLY" to the "Organizer".
1300 3.2.2.4. Changing the Organizer
1302 The situation may arise where the "Organizer" of a "VEVENT" is no
1303 longer able to perform the "Organizer" role and abdicates without
1304 passing on the "Organizer" role to someone else. When this occurs,
1305 the "Attendees" of the "VEVENT" may use out-of-band mechanisms to
1306 communicate the situation and agree upon a new "Organizer". The new
1307 "Organizer" should then send out a new "REQUEST" with a modified
1308 version of the "VEVENT" in which the "SEQUENCE" number has been
1309 incremented and the "ORGANIZER" property has been changed to the new
1312 3.2.2.5. Sending on Behalf of the Organizer
1314 There are a number of scenarios that support the need for a "Calendar
1315 User" to act on behalf of the "Organizer" without explicit role
1316 changing. This might be the case if the CU designated as "Organizer"
1317 is sick or unable to perform duties associated with that function.
1318 In these cases, iTIP supports the notion of one CU acting on behalf
1319 of another. Using the "SENT-BY" parameter, a "Calendar User" could
1320 send an updated "VEVENT" "REQUEST". In the case where one CU sends
1321 on behalf of another CU, the "Attendee" responses are still directed
1322 back towards the CU designated as "Organizer".
1324 3.2.2.6. Forwarding to an Uninvited CU
1326 An "Attendee" invited to a "VEVENT" calendar component may send the
1327 "VEVENT" calendar component to another new CU not previously
1328 associated with the "VEVENT" calendar component. The current
1329 "Attendee" invited to the "VEVENT" calendar component does this by
1330 forwarding the original "REQUEST" method to the new CU. The new CU
1331 can send a "REPLY" to the "Organizer" of the "VEVENT" calendar
1332 component. The reply contains an "ATTENDEE" property for the new CU.
1334 The "Organizer" ultimately decides whether or not the new CU becomes
1335 part of the event and is not obligated to do anything with a "REPLY"
1336 from a new (uninvited) CU. If the "Organizer" does not want the new
1337 CU to be part of the event, the new "ATTENDEE" property is not added
1338 to the "VEVENT" calendar component. The "Organizer" MAY send the CU
1339 a "CANCEL" message to indicate that they will not be added to the
1340 event. If the "Organizer" decides to add the new CU, the new
1341 "ATTENDEE" property is added to the "VEVENT" calendar component.
1342 Furthermore, the "Organizer" is free to change any "ATTENDEE"
1346 Daboo Standards Track [Page 24]
1348 RFC 5546 iTIP December 2009
1351 property parameter from the values supplied by the new CU to
1352 something the "Organizer" considers appropriate. The "Organizer"
1353 SHOULD send the new CU a "REQUEST" message to inform them that they
1356 When forwarding a "REQUEST" to another CU, the forwarding "Attendee"
1357 MUST NOT make changes to the original message.
1359 3.2.2.7. Updating Attendee Status
1361 The "Organizer" of an event may also request updated status from one
1362 or more "Attendees". The "Organizer" sends a "REQUEST" method to the
1363 "Attendee" and sets the "ATTENDEE;RSVP=TRUE" property parameter. The
1364 "SEQUENCE" property for the event is not changed from its previous
1365 value. A recipient will determine that the only change in the
1366 "REQUEST" is that their "RSVP" property parameter indicates a request
1367 for updated status. The recipient SHOULD respond with a "REPLY"
1368 method indicating their current status with respect to the "REQUEST".
1372 The "REPLY" method in a "VEVENT" calendar component is used to
1373 respond (e.g., accept or decline) to a "REQUEST" or to reply to a
1374 delegation "REQUEST". When used to provide a delegation response,
1375 the "Delegator" SHOULD include the calendar address of the "Delegate"
1376 on the "DELEGATED-TO" property parameter of the "Delegator's"
1377 "ATTENDEE" property. The "Delegate" SHOULD include the calendar
1378 address of the "Delegator" on the "DELEGATED-FROM" property parameter
1379 of the "Delegate's" "ATTENDEE" property.
1381 The "REPLY" method is also used when processing of a "REQUEST" fails.
1382 Depending on the value of the "REQUEST-STATUS" property, no
1383 scheduling action may have been performed.
1385 The "Organizer" of an event may receive the "REPLY" method from a CU
1386 not in the original "REQUEST". For example, a "REPLY" may be
1387 received from a "Delegate" to an event. In addition, the "REPLY"
1388 method may be received from an unknown CU (a "Party Crasher"). This
1389 uninvited "Attendee" may be accepted, or the "Organizer" may cancel
1390 the event for the uninvited "Attendee" by sending a "CANCEL" method
1391 to the uninvited "Attendee".
1393 An "Attendee" MAY include a message to the "Organizer" using the
1394 "COMMENT" property. For example, if the user indicates tentative
1395 acceptance and wants to let the "Organizer" know why, the reason can
1396 be expressed in the "COMMENT" property value.
1402 Daboo Standards Track [Page 25]
1404 RFC 5546 iTIP December 2009
1407 The "Organizer" may also receive a "REPLY" from one CU on behalf of
1408 another. Like the scenario enumerated above for the "Organizer",
1409 "Attendees" may have another CU respond on their behalf. This is
1410 done using the "SENT-BY" parameter.
1412 The optional properties listed in the table below (those listed as
1413 "0+" or "0 or 1") MUST NOT be changed from those of the original
1414 request. If property changes are desired, the "COUNTER" message must
1417 This method type is an iCalendar object that conforms to the
1418 following property constraints:
1420 +--------------------------------------------+
1421 | Constraints for a METHOD:REPLY of a VEVENT |
1422 +--------------------------------------------+
1424 +--------------------+----------+-----------------------------------+
1425 | Component/Property | Presence | Comment |
1426 +--------------------+----------+-----------------------------------+
1427 | METHOD | 1 | MUST be REPLY. |
1429 | VEVENT | 1+ | All components MUST have the same |
1431 | ATTENDEE | 1 | MUST be the address of the |
1432 | | | Attendee replying. |
1435 | RECURRENCE-ID | 0 or 1 | Only if referring to an instance |
1436 | | | of a recurring calendar |
1437 | | | component. Otherwise, it MUST |
1438 | | | NOT be present. |
1439 | UID | 1 | MUST be the UID of the original |
1441 | SEQUENCE | 0 or 1 | If non-zero, MUST be the sequence |
1442 | | | number of the original REQUEST. |
1443 | | | MAY be present if 0. |
1445 | CATEGORIES | 0+ | |
1446 | CLASS | 0 or 1 | |
1449 | CREATED | 0 or 1 | |
1450 | DESCRIPTION | 0 or 1 | |
1451 | DTEND | 0 or 1 | If present, DURATION MUST NOT be |
1453 | DTSTART | 0 or 1 | |
1458 Daboo Standards Track [Page 26]
1460 RFC 5546 iTIP December 2009
1463 | DURATION | 0 or 1 | If present, DTEND MUST NOT be |
1467 | LAST-MODIFIED | 0 or 1 | |
1468 | LOCATION | 0 or 1 | |
1469 | PRIORITY | 0 or 1 | |
1471 | RELATED-TO | 0+ | |
1472 | RESOURCES | 0+ | |
1473 | REQUEST-STATUS | 0+ | |
1474 | RRULE | 0 or 1 | |
1475 | STATUS | 0 or 1 | |
1476 | SUMMARY | 0 or 1 | |
1477 | TRANSP | 0 or 1 | |
1479 | IANA-PROPERTY | 0+ | |
1480 | X-PROPERTY | 0+ | |
1484 | VTIMEZONE | 0 or 1 | MUST be present if any date/time |
1485 | | | refers to a timezone. |
1487 | IANA-COMPONENT | 0+ | |
1488 | X-COMPONENT | 0+ | |
1495 +--------------------+----------+-----------------------------------+
1499 The "ADD" method allows the "Organizer" to add one or more new
1500 instances to an existing "VEVENT" using a single iTIP message without
1501 having to send the entire "VEVENT" with all the existing instance
1502 data, as it would have to do if the "REQUEST" method were used.
1504 The "UID" must be that of the existing event. If the "UID" property
1505 value in the "ADD" is not found on the recipient's calendar, then the
1506 recipient SHOULD send a "REFRESH" to the "Organizer" in order to be
1507 updated with the latest version of the "VEVENT". If an "Attendee"
1508 implementation does not support the "ADD" method, it should respond
1509 with a "REQUEST-STATUS" value of 3.14 and ask for a "REFRESH".
1514 Daboo Standards Track [Page 27]
1516 RFC 5546 iTIP December 2009
1519 When handling an "ADD" message, the "Attendee" treats each component
1520 in the "ADD" message as if it were referenced via an "RDATE" in the
1523 This method type is an iCalendar object that conforms to the
1524 following property constraints:
1526 +------------------------------------------+
1527 | Constraints for a METHOD:ADD of a VEVENT |
1528 +------------------------------------------+
1530 +--------------------+----------+-----------------------------------+
1531 | Component/Property | Presence | Comment |
1532 +--------------------+----------+-----------------------------------+
1533 | METHOD | 1 | MUST be ADD. |
1539 | SEQUENCE | 1 | MUST be greater than 0. |
1540 | SUMMARY | 1 | Can be null. |
1541 | UID | 1 | MUST match that of the original |
1545 | CATEGORIES | 0+ | |
1546 | CLASS | 0 or 1 | |
1549 | CREATED | 0 or 1 | |
1550 | DESCRIPTION | 0 or 1 | Can be null. |
1551 | DTEND | 0 or 1 | If present, DURATION MUST NOT be |
1553 | DURATION | 0 or 1 | If present, DTEND MUST NOT be |
1556 | LAST-MODIFIED | 0 or 1 | |
1557 | LOCATION | 0 or 1 | |
1558 | PRIORITY | 0 or 1 | |
1559 | RELATED-TO | 0+ | |
1560 | RESOURCES | 0+ | |
1561 | STATUS | 0 or 1 | MAY be one of |
1562 | | | TENTATIVE/CONFIRMED. |
1563 | TRANSP | 0 or 1 | |
1565 | IANA-PROPERTY | 0+ | |
1566 | X-PROPERTY | 0+ | |
1570 Daboo Standards Track [Page 28]
1572 RFC 5546 iTIP December 2009
1576 | RECURRENCE-ID | 0 | |
1577 | REQUEST-STATUS | 0 | |
1583 | VTIMEZONE | 0+ | MUST be present if any date/time |
1584 | | | refers to a timezone. |
1586 | IANA-COMPONENT | 0+ | |
1587 | X-COMPONENT | 0+ | |
1594 +--------------------+----------+-----------------------------------+
1598 The "CANCEL" method in a "VEVENT" calendar component is used to send
1599 a cancellation notice of an existing event request to the affected
1600 "Attendees". The message is sent by the "Organizer" of the event.
1601 For a recurring event, either the whole event or instances of an
1602 event may be cancelled. To cancel the complete range of a recurring
1603 event, the "UID" property value for the event MUST be specified and a
1604 "RECURRENCE-ID" MUST NOT be specified in the "CANCEL" method. In
1605 order to cancel an individual instance of the event, the
1606 "RECURRENCE-ID" property value for the event MUST be specified in the
1609 There are two options for canceling a sequence of instances of a
1610 recurring "VEVENT" calendar component:
1612 a. The "RECURRENCE-ID" property for an instance in the sequence MUST
1613 be specified with the "RANGE" property parameter value of
1614 "THISANDFUTURE" to indicate cancellation of the specified
1615 "VEVENT" calendar component and all instances after.
1617 b. Individual recurrence instances may be cancelled by specifying
1618 multiple "VEVENT" components each with a "RECURRENCE-ID" property
1619 corresponding to one of the instances to be cancelled.
1626 Daboo Standards Track [Page 29]
1628 RFC 5546 iTIP December 2009
1631 The "Organizer" MUST send a "CANCEL" message to each "Attendee"
1632 affected by the cancellation. This can be done using a single
1633 "CANCEL" message for all "Attendees" or by using multiple messages
1634 with different subsets of the affected "Attendees" in each.
1636 When a "VEVENT" is cancelled, the "SEQUENCE" property value MUST be
1637 incremented as described in Section 2.1.4.
1639 This method type is an iCalendar object that conforms to the
1640 following property constraints:
1642 +---------------------------------------------+
1643 | Constraints for a METHOD:CANCEL of a VEVENT |
1644 +---------------------------------------------+
1646 +--------------------+----------+-----------------------------------+
1647 | Component/Property | Presence | Comment |
1648 +--------------------+----------+-----------------------------------+
1649 | METHOD | 1 | MUST be CANCEL. |
1651 | VEVENT | 1+ | All must have the same UID. |
1652 | ATTENDEE | 0+ | MUST include some or all |
1653 | | | Attendees being removed from the |
1654 | | | event. MUST include some or all |
1655 | | | Attendees if the entire event is |
1660 | UID | 1 | MUST be the UID of the original |
1664 | CATEGORIES | 0+ | |
1665 | CLASS | 0 or 1 | |
1667 | CREATED | 0 or 1 | |
1668 | DESCRIPTION | 0 or 1 | |
1669 | DTEND | 0 or 1 | If present, DURATION MUST NOT be |
1671 | DTSTART | 0 or 1 | |
1672 | DURATION | 0 or 1 | If present, DTEND MUST NOT be |
1676 | LAST-MODIFIED | 0 or 1 | |
1677 | LOCATION | 0 or 1 | |
1678 | PRIORITY | 0 or 1 | |
1682 Daboo Standards Track [Page 30]
1684 RFC 5546 iTIP December 2009
1688 | RECURRENCE-ID | 0 or 1 | Only if referring to an instance |
1689 | | | of a recurring calendar |
1690 | | | component. Otherwise, it MUST |
1691 | | | NOT be present. |
1692 | RELATED-TO | 0+ | |
1693 | RESOURCES | 0+ | |
1694 | RRULE | 0 or 1 | |
1695 | STATUS | 0 or 1 | MUST be set to CANCELLED to |
1696 | | | cancel the entire event. If |
1697 | | | uninviting specific Attendees, |
1698 | | | then MUST NOT be included. |
1699 | SUMMARY | 0 or 1 | |
1700 | TRANSP | 0 or 1 | |
1702 | IANA-PROPERTY | 0+ | |
1703 | X-PROPERTY | 0+ | |
1704 | REQUEST-STATUS | 0 | |
1708 | VTIMEZONE | 0+ | MUST be present if any date/time |
1709 | | | refers to a timezone. |
1711 | IANA-COMPONENT | 0+ | |
1712 | X-COMPONENT | 0+ | |
1719 +--------------------+----------+-----------------------------------+
1723 The "REFRESH" method in a "VEVENT" calendar component is used by
1724 "Attendees" of an existing event to request an updated description
1725 from the event "Organizer". The "REFRESH" method must specify the
1726 "UID" property of the event to update. A recurrence instance of an
1727 event may be requested by specifying the "RECURRENCE-ID" property
1728 corresponding to the associated event. The "Organizer" responds with
1729 the latest description and version of the event.
1731 This method type is an iCalendar object that conforms to the
1732 following property constraints:
1738 Daboo Standards Track [Page 31]
1740 RFC 5546 iTIP December 2009
1743 +----------------------------------------------+
1744 | Constraints for a METHOD:REFRESH of a VEVENT |
1745 +----------------------------------------------+
1747 +--------------------+----------+-----------------------------------+
1748 | Component/Property | Presence | Comment |
1749 +--------------------+----------+-----------------------------------+
1750 | METHOD | 1 | MUST be REFRESH. |
1753 | ATTENDEE | 1 | MUST be the address of requester. |
1756 | UID | 1 | MUST be the UID associated with |
1757 | | | original REQUEST. |
1759 | RECURRENCE-ID | 0 or 1 | Only if referring to an instance |
1760 | | | of a recurring calendar |
1761 | | | component. Otherwise, it MUST |
1762 | | | NOT be present. |
1763 | IANA-PROPERTY | 0+ | |
1764 | X-PROPERTY | 0+ | |
1766 | CATEGORIES | 0 | |
1770 | DESCRIPTION | 0 | |
1776 | LAST-MODIFIED | 0 | |
1780 | RELATED-TO | 0 | |
1781 | REQUEST-STATUS | 0 | |
1794 Daboo Standards Track [Page 32]
1796 RFC 5546 iTIP December 2009
1801 | VTIMEZONE | 0+ | |
1803 | IANA-COMPONENT | 0+ | |
1804 | X-COMPONENT | 0+ | |
1811 +--------------------+----------+-----------------------------------+
1815 The "COUNTER" method for a "VEVENT" calendar component is used by an
1816 "Attendee" of an existing event to submit to the "Organizer" a
1817 counter proposal to the event. The "Attendee" sends this message to
1818 the "Organizer" of the event.
1820 The counter proposal is an iCalendar object consisting of a "VEVENT"
1821 calendar component that provides the complete description of the
1824 The "Organizer" rejects the counter proposal by sending the
1825 "Attendee" a "DECLINECOUNTER" method. The "Organizer" accepts the
1826 counter proposal by rescheduling the event as described in
1827 Section 3.2.2.1, "Rescheduling an Event". The "Organizer's" CUA
1828 SHOULD send a "REQUEST" message to all "Attendees" affected by any
1829 change triggered by an accepted "COUNTER".
1831 This method type is an iCalendar object that conforms to the
1832 following property constraints:
1834 +----------------------------------------------+
1835 | Constraints for a METHOD:COUNTER of a VEVENT |
1836 +----------------------------------------------+
1838 +--------------------+----------+-----------------------------------+
1839 | Component/Property | Presence | Comment |
1840 +--------------------+----------+-----------------------------------+
1841 | METHOD | 1 | MUST be COUNTER. |
1850 Daboo Standards Track [Page 33]
1852 RFC 5546 iTIP December 2009
1855 | ORGANIZER | 1 | MUST be the Organizer of the |
1856 | | | original event. |
1857 | SEQUENCE | 1 | MUST echo the original SEQUENCE |
1858 | | | number. MUST be present if |
1859 | | | non-zero. MAY be present if |
1861 | SUMMARY | 1 | Can be null. |
1862 | UID | 1 | MUST be the UID associated with |
1863 | | | the REQUEST being countered. |
1865 | ATTENDEE | 0+ | Can also be used to propose other |
1867 | CATEGORIES | 0+ | |
1868 | CLASS | 0 or 1 | |
1871 | CREATED | 0 or 1 | |
1872 | DESCRIPTION | 0 or 1 | |
1873 | DTEND | 0 or 1 | If present, DURATION MUST NOT be |
1875 | DURATION | 0 or 1 | If present, DTEND MUST NOT be |
1879 | LAST-MODIFIED | 0 or 1 | |
1880 | LOCATION | 0 or 1 | |
1881 | PRIORITY | 0 or 1 | |
1883 | RECURRENCE-ID | 0 or 1 | Only if referring to an instance |
1884 | | | of a recurring calendar |
1885 | | | component. Otherwise, it MUST |
1886 | | | NOT be present. |
1887 | RELATED-TO | 0+ | |
1888 | REQUEST-STATUS | 0+ | |
1889 | RESOURCES | 0+ | |
1890 | RRULE | 0 or 1 | |
1891 | STATUS | 0 or 1 | Value must be one of |
1892 | | | CONFIRMED/TENATIVE/CANCELLED. |
1893 | TRANSP | 0 or 1 | |
1895 | IANA-PROPERTY | 0+ | |
1896 | X-PROPERTY | 0+ | |
1900 | VTIMEZONE | 0+ | MUST be present if any date/time |
1901 | | | refers to a timezone. |
1906 Daboo Standards Track [Page 34]
1908 RFC 5546 iTIP December 2009
1911 | IANA-COMPONENT | 0+ | |
1912 | X-COMPONENT | 0+ | |
1919 +--------------------+----------+-----------------------------------+
1921 3.2.8. DECLINECOUNTER
1923 The "DECLINECOUNTER" method in a "VEVENT" calendar component is used
1924 by the "Organizer" of an event to reject a counter proposal submitted
1925 by an "Attendee". The "Organizer" must send the "DECLINECOUNTER"
1926 message to the "Attendee" that sent the "COUNTER" method to the
1929 This method type is an iCalendar object that conforms to the
1930 following property constraints:
1932 +-----------------------------------------------------+
1933 | Constraints for a METHOD:DECLINECOUNTER of a VEVENT |
1934 +-----------------------------------------------------+
1936 +--------------------+----------+-----------------------------------+
1937 | Component/Property | Presence | Comment |
1938 +--------------------+----------+-----------------------------------+
1939 | METHOD | 1 | MUST be DECLINECOUNTER. |
1941 | VEVENT | 1+ | All components MUST have the same |
1943 | ATTENDEE | 1+ | MUST for all Attendees. |
1946 | SEQUENCE | 1 | MUST echo the original SEQUENCE |
1948 | UID | 1 | MUST echo original UID. |
1950 | CATEGORIES | 0+ | |
1951 | CLASS | 0 or 1 | |
1954 | CREATED | 0 or 1 | |
1955 | DESCRIPTION | 0 or 1 | Can be null. |
1956 | DTSTART | 0 or 1 | |
1957 | DTEND | 0 or 1 | If present, DURATION MUST NOT be |
1962 Daboo Standards Track [Page 35]
1964 RFC 5546 iTIP December 2009
1967 | DURATION | 0 or 1 | If present, DTEND MUST NOT be |
1971 | LAST-MODIFIED | 0 or 1 | |
1972 | LOCATION | 0 or 1 | |
1973 | PRIORITY | 0 or 1 | |
1975 | RECURRENCE-ID | 0 or 1 | Only if referring to an instance |
1976 | | | of a recurring calendar |
1977 | | | component. Otherwise, it MUST |
1978 | | | NOT be present. |
1979 | RELATED-TO | 0+ | |
1980 | REQUEST-STATUS | 0+ | |
1981 | RESOURCES | 0+ | |
1982 | RRULE | 0 or 1 | |
1983 | STATUS | 0 or 1 | MAY be one of |
1984 | | | TENTATIVE/CONFIRMED. |
1985 | SUMMARY | 0 or 1 | Can be null. |
1986 | TRANSP | 0 or 1 | |
1988 | IANA-PROPERTY | 0+ | |
1989 | X-PROPERTY | 0+ | |
1992 | VTIMEZONE | 0+ | MUST be present if any date/time |
1993 | | | refers to a timezone. |
1995 | IANA-COMPONENT | 0+ | |
1996 | X-COMPONENT | 0+ | |
2004 +--------------------+----------+-----------------------------------+
2018 Daboo Standards Track [Page 36]
2020 RFC 5546 iTIP December 2009
2023 3.3. Methods for VFREEBUSY Components
2025 This section defines the property set for the methods that are
2026 applicable to the "VFREEBUSY" calendar component. Each of the
2027 methods is defined using a restriction table.
2029 This document only addresses the transfer of busy time information.
2030 Applications desiring free time information MUST infer this from
2031 available busy time information.
2033 The "FREEBUSY" property value MAY include a list of values, separated
2034 by the COMMA character (US-ASCII decimal 44). Alternately, multiple
2035 busy time periods MAY be specified with multiple instances of the
2036 "FREEBUSY" property. Both forms MUST be supported by implementations
2037 conforming to this document. Duplicate busy time periods SHOULD NOT
2038 be specified in an iCalendar object. However, two different busy
2039 time periods MAY overlap.
2041 "FREEBUSY" properties SHOULD be sorted such that their values are in
2042 ascending order, based on the start time and then the end time, with
2043 the earliest periods first. For example, today's busy time
2044 information should appear after yesterday's busy time information.
2045 And the busy time for this half-hour should appear after the busy
2046 time for earlier today. Busy time periods can also span a day
2049 The following summarizes the methods that are defined for the
2050 "VFREEBUSY" calendar component.
2052 +---------+-------------------------------------+
2053 | Method | Description |
2054 +---------+-------------------------------------+
2055 | PUBLISH | Publish unsolicited busy time data. |
2057 | REQUEST | Request busy time data. |
2059 | REPLY | Reply to a busy time request. |
2060 +---------+-------------------------------------+
2064 The "PUBLISH" method in a "VFREEBUSY" calendar component is used to
2065 publish busy time data. The method may be sent from one CU to any
2066 other. The purpose of the method is to provide a way to send
2067 unsolicited busy time data. That is, the busy time data is not being
2068 sent as a "REPLY" to the receipt of a "REQUEST" method.
2074 Daboo Standards Track [Page 37]
2076 RFC 5546 iTIP December 2009
2079 The "ORGANIZER" property MUST be specified in the busy time
2080 information. The value is the CU address of the originator of the
2081 busy time information.
2083 The busy time information within the iCalendar object MAY be grouped
2084 into more than one "VFREEBUSY" calendar component. This capability
2085 allows busy time periods to be grouped according to some common
2086 periodicity, such as a calendar week, month, or year. In this case,
2087 each "VFREEBUSY" calendar component MUST include the "ORGANIZER",
2088 "DTSTART", and "DTEND" properties in order to specify the source of
2089 the busy time information and the date and time interval over which
2090 the busy time information covers.
2092 This method type is an iCalendar object that conforms to the
2093 following property constraints:
2130 Daboo Standards Track [Page 38]
2132 RFC 5546 iTIP December 2009
2135 +-------------------------------------------------+
2136 | Constraints for a METHOD:PUBLISH of a VFREEBUSY |
2137 +-------------------------------------------------+
2139 +--------------------+----------+-----------------------------------+
2140 | Component/Property | Presence | Comment |
2141 +--------------------+----------+-----------------------------------+
2142 | METHOD | 1 | MUST be PUBLISH. |
2144 | VFREEBUSY | 1+ | |
2146 | DTSTART | 1 | DateTime values must be in UTC. |
2147 | DTEND | 1 | DateTime values must be in UTC. |
2148 | FREEBUSY | 0+ | MUST be BUSYTIME. Multiple |
2149 | | | instances are allowed. Multiple |
2150 | | | instances SHOULD be sorted in |
2151 | | | ascending order. |
2152 | ORGANIZER | 1 | MUST contain the address of |
2153 | | | originator of busy time data. |
2156 | CONTACT | 0 or 1 | |
2157 | IANA-PROPERTY | 0+ | |
2158 | X-PROPERTY | 0+ | |
2159 | URL | 0 or 1 | Specifies busy time URL. |
2162 | REQUEST-STATUS | 0 | |
2166 | IANA-COMPONENT | 0+ | |
2167 | X-COMPONENT | 0+ | |
2176 +--------------------+----------+-----------------------------------+
2186 Daboo Standards Track [Page 39]
2188 RFC 5546 iTIP December 2009
2193 The "REQUEST" method in a "VFREEBUSY" calendar component is used to
2194 ask a "Calendar User" for their busy time information. The request
2195 may be for a busy time information bounded by a specific date and
2198 This message only permits requests for busy time information. The
2199 message is sent from a "Calendar User" requesting the busy time
2200 information of one or more intended recipients.
2202 If the originator of the "REQUEST" method is not authorized to make a
2203 busy time request on the recipient's calendar system, then an
2204 exception message SHOULD be returned in a "REPLY" method, but no busy
2205 time data need be returned.
2207 This method type is an iCalendar object that conforms to the
2208 following property constraints:
2242 Daboo Standards Track [Page 40]
2244 RFC 5546 iTIP December 2009
2247 +-------------------------------------------------+
2248 | Constraints for a METHOD:REQUEST of a VFREEBUSY |
2249 +-------------------------------------------------+
2251 +--------------------+----------+-----------------------------------+
2252 | Component/Property | Presence | Comment |
2253 +--------------------+----------+-----------------------------------+
2254 | METHOD | 1 | MUST be REQUEST. |
2257 | ATTENDEE | 1+ | Contains the calendar user |
2258 | | | addresses of the "Calendar Users" |
2259 | | | whose freebusy is being |
2261 | DTEND | 1 | DateTime values must be in UTC. |
2263 | DTSTART | 1 | DateTime values must be in UTC. |
2264 | ORGANIZER | 1 | MUST be the request originator's |
2268 | CONTACT | 0 or 1 | |
2269 | IANA-PROPERTY | 0+ | |
2270 | X-PROPERTY | 0+ | |
2273 | REQUEST-STATUS | 0 | |
2278 | IANA-COMPONENT | 0+ | |
2279 | X-COMPONENT | 0+ | |
2288 +--------------------+----------+-----------------------------------+
2298 Daboo Standards Track [Page 41]
2300 RFC 5546 iTIP December 2009
2305 The "REPLY" method in a "VFREEBUSY" calendar component is used to
2306 respond to a busy time request. The method is sent by the recipient
2307 of a busy time request to the originator of the request.
2309 The "REPLY" method may also be used to respond to an unsuccessful
2310 "REQUEST" method. Depending on the "REQUEST-STATUS" value, no busy
2311 time information may be returned.
2313 This method type is an iCalendar object that conforms to the
2314 following property constraints:
2354 Daboo Standards Track [Page 42]
2356 RFC 5546 iTIP December 2009
2359 +-----------------------------------------------+
2360 | Constraints for a METHOD:REPLY of a VFREEBUSY |
2361 +-----------------------------------------------+
2363 +--------------------+----------+-----------------------------------+
2364 | Component/Property | Presence | Comment |
2365 +--------------------+----------+-----------------------------------+
2366 | METHOD | 1 | MUST be REPLY. |
2369 | ATTENDEE | 1 | MUST be the address of the |
2370 | | | Attendee replying. |
2372 | DTEND | 1 | DateTime values must be in UTC. |
2373 | DTSTART | 1 | DateTime values must be in UTC. |
2374 | FREEBUSY | 0+ | MUST be BUSYTIME. Multiple |
2375 | | | instances are allowed. Multiple |
2376 | | | instances SHOULD be sorted in |
2377 | | | ascending order. |
2378 | ORGANIZER | 1 | MUST be the request originator's |
2380 | UID | 1 | MUST be the UID of the original |
2383 | CONTACT | 0 or 1 | |
2384 | REQUEST-STATUS | 0+ | |
2385 | URL | 0 or 1 | Specifies busy time URL. |
2386 | IANA-PROPERTY | 0+ | |
2387 | X-PROPERTY | 0+ | |
2393 | IANA-COMPONENT | 0+ | |
2394 | X-COMPONENT | 0+ | |
2403 +--------------------+----------+-----------------------------------+
2410 Daboo Standards Track [Page 43]
2412 RFC 5546 iTIP December 2009
2415 3.4. Methods for VTODO Components
2417 This section defines the property set for the methods that are
2418 applicable to the "VTODO" calendar component. Each of the methods is
2419 defined using a restriction table that specifies the property
2420 constraints that define the particular method.
2422 The following summarizes the methods that are defined for the "VTODO"
2425 +----------------+--------------------------------------------------+
2426 | Method | Description |
2427 +----------------+--------------------------------------------------+
2428 | PUBLISH | Post notification of a VTODO. Used primarily as |
2429 | | a method of advertising the existence of a |
2432 | REQUEST | Assign a VTODO. This is an explicit assignment |
2433 | | to one or more Calendar Users. The REQUEST |
2434 | | method is also used to update or change an |
2435 | | existing VTODO. Clients that cannot handle |
2436 | | REQUEST MAY degrade the method to treat it as a |
2439 | REPLY | Reply to a VTODO request. Attendees MAY set |
2440 | | PARTSTAT to ACCEPTED, DECLINED, TENTATIVE, |
2441 | | DELEGATED, PARTIAL, and COMPLETED. |
2443 | ADD | Add one or more instances to an existing to-do. |
2445 | CANCEL | Cancel one or more instances of an existing |
2448 | REFRESH | A request sent to a VTODO Organizer asking for |
2449 | | the latest version of a VTODO. |
2451 | COUNTER | Counter a REQUEST with an alternative proposal. |
2453 | DECLINECOUNTER | Decline a counter proposal by an Attendee. |
2454 +----------------+--------------------------------------------------+
2458 The "PUBLISH" method in a "VTODO" calendar component has no
2459 associated response. It is simply a posting of an iCalendar object
2460 that may be added to a calendar. It MUST have an "Organizer". It
2461 MUST NOT have "Attendees". Its expected usage is for encapsulating
2462 an arbitrary "VTODO" calendar component as an iCalendar object. The
2466 Daboo Standards Track [Page 44]
2468 RFC 5546 iTIP December 2009
2471 "Organizer" MAY subsequently update (with another "PUBLISH" method),
2472 add instances to (with an "ADD" method), or cancel (with a "CANCEL"
2473 method) a previously published "VTODO" calendar component.
2475 This method type is an iCalendar object that conforms to the
2476 following property constraints:
2478 +---------------------------------------------+
2479 | Constraints for a METHOD:PUBLISH of a VTODO |
2480 +---------------------------------------------+
2482 +--------------------+----------+-----------------------------------+
2483 | Component/Property | Presence | Comment |
2484 +--------------------+----------+-----------------------------------+
2485 | METHOD | 1 | MUST be PUBLISH. |
2492 | SEQUENCE | 0 or 1 | MUST be present if value is |
2493 | | | greater than 0; MAY be present if |
2495 | SUMMARY | 1 | Can be null. |
2498 | CATEGORIES | 0+ | |
2499 | CLASS | 0 or 1 | |
2501 | COMPLETED | 0 or 1 | |
2503 | CREATED | 0 or 1 | |
2504 | DESCRIPTION | 0 or 1 | Can be null. |
2505 | DUE | 0 or 1 | If present, DURATION MUST NOT be |
2507 | DURATION | 0 or 1 | If present, DUE MUST NOT be |
2511 | LAST-MODIFIED | 0 or 1 | |
2512 | LOCATION | 0 or 1 | |
2513 | PERCENT-COMPLETE | 0 or 1 | |
2515 | RECURRENCE-ID | 0 or 1 | Only if referring to an instance |
2516 | | | of a recurring calendar |
2517 | | | component. Otherwise, it MUST |
2518 | | | NOT be present. |
2522 Daboo Standards Track [Page 45]
2524 RFC 5546 iTIP December 2009
2527 | RELATED-TO | 0+ | |
2528 | RESOURCES | 0+ | |
2529 | RRULE | 0 or 1 | |
2530 | STATUS | 0 or 1 | MAY be one of |
2531 | | | COMPLETED/NEEDS-ACTION/ |
2532 | | | IN-PROCESS/CANCELLED. |
2534 | IANA-PROPERTY | 0+ | |
2535 | X-PROPERTY | 0+ | |
2537 | REQUEST-STATUS | 0 | |
2541 | VTIMEZONE | 0+ | MUST be present if any date/time |
2542 | | | refers to a timezone. |
2544 | IANA-COMPONENT | 0+ | |
2545 | X-COMPONENT | 0+ | |
2552 +--------------------+----------+-----------------------------------+
2556 The "REQUEST" method in a "VTODO" calendar component provides the
2557 following scheduling functions:
2559 o Assign a to-do to one or more "Calendar Users".
2561 o Reschedule an existing to-do.
2563 o Update the details of an existing to-do, without rescheduling it.
2565 o Update the completion status of "Attendees" of an existing to-do,
2566 without rescheduling it.
2568 o Reconfirm an existing to-do, without rescheduling it.
2570 o Delegate/reassign an existing to-do to another "Calendar User".
2572 The assigned "Calendar Users" are identified in the "VTODO" calendar
2573 component by individual "ATTENDEE;ROLE=REQ-PARTICIPANT" property
2578 Daboo Standards Track [Page 46]
2580 RFC 5546 iTIP December 2009
2583 Typically, the originator of a "REQUEST" is the "Organizer" of the
2584 to-do, and the recipient of a "REQUEST" is the "Calendar User"
2585 assigned the to-do. The "Attendee" uses the "REPLY" method to convey
2586 their acceptance and completion status to the "Organizer" of the
2589 The "UID", "SEQUENCE", and "DTSTAMP" properties are used to
2590 distinguish the various uses of the "REQUEST" method. If the "UID"
2591 property value in the "REQUEST" is not found on the recipient's
2592 calendar, then the "REQUEST" is for a new to-do. If the "UID"
2593 property value is found on the recipient's calendar, then the
2594 "REQUEST" is a rescheduling, an update, or a reconfirmation of the
2595 "VTODO" calendar object.
2597 If the "Organizer" of the "REQUEST" method is not authorized to make
2598 a to-do request on the "Attendee's" calendar system, then an
2599 exception is returned in the "REQUEST-STATUS" property of a
2600 subsequent "REPLY" method, but no scheduling action is performed.
2602 For the "REQUEST" method, multiple "VTODO" components in a single
2603 iCalendar object are only permitted for components with the same
2604 "UID" property. That is, a series of recurring events may have
2605 instance-specific information. In this case, multiple "VTODO"
2606 components are needed to express the entire series.
2608 This method type is an iCalendar object that conforms to the
2609 following property constraints:
2611 +---------------------------------------------+
2612 | Constraints for a METHOD:REQUEST of a VTODO |
2613 +---------------------------------------------+
2615 +--------------------+----------+-----------------------------------+
2616 | Component/Property | Presence | Comment |
2617 +--------------------+----------+-----------------------------------+
2618 | METHOD | 1 | MUST be REQUEST. |
2620 | VTODO | 1+ | All components must have the same |
2627 | SEQUENCE | 0 or 1 | MUST be present if value is |
2628 | | | greater than 0; MAY be present if |
2630 | SUMMARY | 1 | Can be null. |
2634 Daboo Standards Track [Page 47]
2636 RFC 5546 iTIP December 2009
2641 | CATEGORIES | 0+ | |
2642 | CLASS | 0 or 1 | |
2644 | COMPLETED | 0 or 1 | |
2646 | CREATED | 0 or 1 | |
2647 | DESCRIPTION | 0 or 1 | Can be null |
2648 | DUE | 0 or 1 | If present, DURATION MUST NOT be |
2650 | DURATION | 0 or 1 | If present, DUE MUST NOT be |
2654 | LAST-MODIFIED | 0 or 1 | |
2655 | LOCATION | 0 or 1 | |
2656 | PERCENT-COMPLETE | 0 or 1 | |
2658 | RECURRENCE-ID | 0 or 1 | Only if referring to an instance |
2659 | | | of a recurring calendar |
2660 | | | component. Otherwise, it MUST |
2661 | | | NOT be present. |
2662 | RELATED-TO | 0+ | |
2663 | RESOURCES | 0+ | |
2664 | RRULE | 0 or 1 | |
2665 | STATUS | 0 or 1 | MAY be one of |
2666 | | | COMPLETED/NEEDS-ACTION/ |
2669 | IANA-PROPERTY | 0+ | |
2670 | X-PROPERTY | 0+ | |
2671 | REQUEST-STATUS | 0 | |
2675 | VTIMEZONE | 0+ | MUST be present if any date/time |
2676 | | | refers to a timezone. |
2678 | IANA-COMPONENT | 0+ | |
2679 | X-COMPONENT | 0+ | |
2686 +--------------------+----------+-----------------------------------+
2690 Daboo Standards Track [Page 48]
2692 RFC 5546 iTIP December 2009
2695 3.4.2.1. REQUEST for Rescheduling a VTODO
2697 The "REQUEST" method may be used to reschedule a "VTODO" calendar
2700 Rescheduling a "VTODO" calendar component involves a change to the
2701 existing "VTODO" calendar component in terms of its start or due
2702 time, recurrence intervals, and possibly the description. If the
2703 recipient CUA of a "REQUEST" method finds that the "UID" property
2704 value already exists on the calendar but that the "SEQUENCE" property
2705 value in the "REQUEST" is greater than the value for the existing
2706 "VTODO", then the "REQUEST" method describes a rescheduling of the
2707 "VTODO" calendar component.
2709 3.4.2.2. REQUEST for Update or Reconfirmation of a VTODO
2711 The "REQUEST" method may be used to update or reconfirm a "VTODO"
2712 calendar component. Reconfirmation is merely an update of "Attendee"
2713 completion status or overall "VTODO" calendar component status.
2715 An update to an existing "VTODO" calendar component does not involve
2716 changes to the start or due time, recurrence intervals, or
2717 (generally) the description for the "VTODO" calendar component. If
2718 the recipient CUA of a "REQUEST" method finds that the "UID" property
2719 value already exists on the calendar and that the "SEQUENCE" property
2720 value in the "REQUEST" is the same as the value for the existing
2721 event, then the "REQUEST" method describes an update of the "VTODO"
2722 calendar component details, but not a rescheduling of the "VTODO"
2725 The update "REQUEST" is the appropriate response to a "REFRESH"
2726 method sent from an "Attendee" to the "Organizer" of a "VTODO"
2729 Unsolicited "REQUEST" methods MAY be sent by the "Organizer" of a
2730 "VTODO" calendar component. The unsolicited "REQUEST" methods are
2731 used to update the details of the "VTODO" (without rescheduling it or
2732 updating the completion status of "Attendees") or the "VTODO"
2733 calendar component itself (i.e., reconfirm the "VTODO").
2735 3.4.2.3. REQUEST for Delegating a VTODO
2737 The "REQUEST" method is also used to delegate or reassign ownership
2738 of a "VTODO" calendar component to another "Calendar User". For
2739 example, it may be used to delegate an "Attendee's" role (i.e.,
2740 "chair" or "participant") for a "VTODO" calendar component. The
2741 "REQUEST" method is sent by one of the "Attendees" of an existing
2742 "VTODO" calendar component to some other individual.
2746 Daboo Standards Track [Page 49]
2748 RFC 5546 iTIP December 2009
2751 For the purposes of this description, the "Attendee" delegating the
2752 "VTODO" calendar component is referred to as the "Delegator". The
2753 "Attendee" receiving the delegation request is referred to as the
2756 The "Delegator" of a "VTODO" calendar component MUST forward the
2757 existing "REQUEST" method for a "VTODO" calendar component to the
2758 "Delegate". The "VTODO" calendar component description MUST include
2759 the "Delegator's" up-to-date "VTODO" calendar component definition.
2760 The "REQUEST" method MUST also include an "ATTENDEE" property with
2761 the calendar address of the "Delegate". The "Delegator" MUST also
2762 send a "REPLY" method back to the "Organizer" with the "Delegator's"
2763 "Attendee" property "PARTSTAT" parameter value set to "DELEGATED".
2764 In addition, the "DELEGATED-TO" parameter MUST be included with the
2765 calendar address of the "Delegate". A response to the delegation
2766 "REQUEST" is sent from the "Delegate" to the "Organizer", and
2767 optionally to the "Delegator". The "REPLY" method from the
2768 "Delegate" SHOULD include the "ATTENDEE" property with their calendar
2769 address and the "DELEGATED-FROM" parameter with the value of the
2770 "Delegator's" calendar address.
2772 The delegation "REQUEST" method MUST assign a value for the "RSVP"
2773 property parameter associated with the "Delegator's" "Attendee"
2774 property to that of the "Delegate's" "ATTENDEE" property. For
2775 example, if the "Delegator's" "ATTENDEE" property specifies
2776 "RSVP=TRUE", then the "Delegate's" "ATTENDEE" property MUST specify
2779 3.4.2.4. REQUEST Forwarded to an Uninvited Calendar User
2781 An "Attendee" assigned a "VTODO" calendar component may send the
2782 "VTODO" calendar component to another new CU not previously
2783 associated with the "VTODO" calendar component. The current
2784 "Attendee" assigned the "VTODO" calendar component does this by
2785 forwarding the original "REQUEST" method to the new CU. The new CU
2786 can send a "REPLY" to the "Organizer" of the "VTODO" calendar
2787 component. The reply contains an "ATTENDEE" property for the new CU.
2789 The "Organizer" ultimately decides whether or not the new CU becomes
2790 part of the to-do and is not obligated to do anything with a "REPLY"
2791 from a new (uninvited) CU. If the "Organizer" does not want the new
2792 CU to be part of the to-do, the new "ATTENDEE" property is not added
2793 to the "VTODO" calendar component. The "Organizer" MAY send the CU a
2794 "CANCEL" message to indicate that they will not be added to the to-
2795 do. If the "Organizer" decides to add the new CU, the new "ATTENDEE"
2796 property is added to the "VTODO" calendar component. Furthermore,
2797 the "Organizer" is free to change any "ATTENDEE" property parameter
2798 from the values supplied by the new CU to something the "Organizer"
2802 Daboo Standards Track [Page 50]
2804 RFC 5546 iTIP December 2009
2807 considers appropriate. The "Organizer" SHOULD send the new
2808 "Attendee" a "REQUEST" message to inform them that they have been
2811 When forwarding a "REQUEST" to another CU, the forwarding "Attendee"
2812 MUST NOT make changes to the original message.
2814 3.4.2.5. REQUEST Updated Attendee Status
2816 An "Organizer" of a "VTODO" may request an updated status from one or
2817 more "Attendees". The "Organizer" sends a "REQUEST" method to the
2818 "Attendee" with the "ATTENDEE;RSVP=TRUE" property sequence. The
2819 "SEQUENCE" property for the "VTODO" is not changed from its previous
2820 value. A recipient determines that the only change in the "REQUEST"
2821 is that their "RSVP" property parameter indicates a request for an
2822 updated status. The recipient SHOULD respond with a "REPLY" method
2823 indicating their current status with respect to the "REQUEST".
2827 The "REPLY" method in a "VTODO" calendar component is used to respond
2828 (e.g., accept or decline) to a request or to reply to a delegation
2829 request. It is also used by an "Attendee" to update their completion
2830 status. When used to provide a delegation response, the "Delegator"
2831 MUST include the calendar address of the "Delegate" in the
2832 "DELEGATED-TO" parameter of the "Delegator's" "ATTENDEE" property.
2833 The "Delegate" MUST include the calendar address of the "Delegator"
2834 on the "DELEGATED-FROM" parameter of the "Delegate's" "ATTENDEE"
2837 The "REPLY" method MAY also be used to respond to an unsuccessful
2838 "VTODO" calendar component "REQUEST" method. Depending on the
2839 "REQUEST-STATUS" value, no scheduling action may have been performed.
2841 The "Organizer" of a "VTODO" calendar component MAY receive a "REPLY"
2842 method from a "Calendar User" not in the original "REQUEST". For
2843 example, a "REPLY" method MAY be received from a "Delegate" of a
2844 "VTODO" calendar component. In addition, the "REPLY" method MAY be
2845 received from an unknown "Calendar User" who has been forwarded the
2846 "REQUEST" by an original "Attendee" of the "VTODO" calendar
2847 component. This uninvited "Attendee" MAY be accepted or the
2848 "Organizer" MAY cancel the "VTODO" calendar component for the
2849 uninvited "Attendee" by sending them a "CANCEL" method.
2851 This method type is an iCalendar object that conforms to the
2852 following property constraints:
2858 Daboo Standards Track [Page 51]
2860 RFC 5546 iTIP December 2009
2863 +-------------------------------------------+
2864 | Constraints for a METHOD:REPLY of a VTODO |
2865 +-------------------------------------------+
2867 +--------------------+----------+-----------------------------------+
2868 | Component/Property | Presence | Comment |
2869 +--------------------+----------+-----------------------------------+
2870 | METHOD | 1 | MUST be REPLY. |
2872 | VTODO | 1+ | All components MUST have the same |
2874 | ATTENDEE | 1 | MUST be the address of the |
2875 | | | Attendee replying. |
2878 | REQUEST-STATUS | 0+ | |
2879 | UID | 1 | MUST be the UID of the original |
2882 | CATEGORIES | 0+ | |
2883 | CLASS | 0 or 1 | |
2885 | COMPLETED | 0 or 1 | |
2887 | CREATED | 0 or 1 | |
2888 | DESCRIPTION | 0 or 1 | |
2889 | DTSTART | 0 or 1 | |
2890 | DUE | 0 or 1 | If present, DURATION MUST NOT be |
2892 | DURATION | 0 or 1 | If present, DUE MUST NOT be |
2896 | LAST-MODIFIED | 0 or 1 | |
2897 | LOCATION | 0 or 1 | |
2898 | PERCENT-COMPLETE | 0 or 1 | |
2899 | PRIORITY | 0 or 1 | |
2901 | RELATED-TO | 0+ | |
2902 | RESOURCES | 0+ | |
2903 | RRULE | 0 or 1 | |
2904 | RECURRENCE-ID | 0 or 1 | Only if referring to an instance |
2905 | | | of a recurring calendar |
2906 | | | component. Otherwise, it MUST |
2907 | | | NOT be present. |
2908 | SEQUENCE | 0 or 1 | MUST be the sequence number of |
2909 | | | the original REQUEST if greater |
2910 | | | than 0. MAY be present if 0. |
2914 Daboo Standards Track [Page 52]
2916 RFC 5546 iTIP December 2009
2919 | STATUS | 0 or 1 | |
2920 | SUMMARY | 0 or 1 | Can be null. |
2922 | IANA-PROPERTY | 0+ | |
2923 | X-PROPERTY | 0+ | |
2927 | VTIMEZONE | 0 or 1 | MUST be present if any date/time |
2928 | | | refers to a timezone. |
2930 | IANA-COMPONENT | 0+ | |
2931 | X-COMPONENT | 0+ | |
2936 +--------------------+----------+-----------------------------------+
2940 The "ADD" method allows the "Organizer" to add one or more new
2941 instances to an existing "VTODO" using a single iTIP message without
2942 having to send the entire "VTODO" with all the existing instance
2943 data, as it would have to do if the "REQUEST" method were used.
2945 The "UID" must be that of the existing to-do. If the "UID" property
2946 value in the "ADD" is not found on the recipient's calendar, then the
2947 recipient SHOULD send a "REFRESH" to the "Organizer" in order to be
2948 updated with the latest version of the "VTODO". If an "Attendee"
2949 implementation does not support the "ADD" method, it should respond
2950 with a "REQUEST-STATUS" value of 3.14 and ask for a "REFRESH".
2952 When handling an "ADD" message, the "Attendee" treats each component
2953 in the "ADD" message as if it were referenced via an "RDATE" in the
2956 The "SEQUENCE" property value is incremented since the sequence of
2959 This method type is an iCalendar object that conforms to the
2960 following property constraints:
2970 Daboo Standards Track [Page 53]
2972 RFC 5546 iTIP December 2009
2975 +-----------------------------------------+
2976 | Constraints for a METHOD:ADD of a VTODO |
2977 +-----------------------------------------+
2979 +--------------------+----------+-----------------------------------+
2980 | Component/Property | Presence | Comment |
2981 +--------------------+----------+-----------------------------------+
2982 | METHOD | 1 | MUST be ADD. |
2988 | SEQUENCE | 1 | MUST be greater than 0. |
2989 | SUMMARY | 1 | Can be null. |
2990 | UID | 1 | MUST match that of the original |
2994 | CATEGORIES | 0+ | |
2995 | CLASS | 0 or 1 | |
2997 | COMPLETED | 0 or 1 | |
2999 | CREATED | 0 or 1 | |
3000 | DESCRIPTION | 0 or 1 | Can be null. |
3001 | DTSTART | 0 or 1 | |
3002 | DUE | 0 or 1 | If present, DURATION MUST NOT be |
3004 | DURATION | 0 or 1 | If present, DUE MUST NOT be |
3007 | LAST-MODIFIED | 0 or 1 | |
3008 | LOCATION | 0 or 1 | |
3009 | PERCENT-COMPLETE | 0 or 1 | |
3010 | RELATED-TO | 0+ | |
3011 | RESOURCES | 0+ | |
3012 | STATUS | 0 or 1 | MAY be one of |
3013 | | | COMPLETED/NEEDS-ACTION/ |
3016 | IANA-PROPERTY | 0+ | |
3017 | X-PROPERTY | 0+ | |
3019 | RECURRENCE-ID | 0 | |
3020 | REQUEST-STATUS | 0 | |
3026 Daboo Standards Track [Page 54]
3028 RFC 5546 iTIP December 2009
3034 | VTIMEZONE | 0+ | MUST be present if any date/time |
3035 | | | refers to a timezone. |
3037 | IANA-COMPONENT | 0+ | |
3038 | X-COMPONENT | 0+ | |
3045 +--------------------+----------+-----------------------------------+
3049 The "CANCEL" method in a "VTODO" calendar component is used to send a
3050 cancellation notice of an existing "VTODO" calendar request to the
3051 affected "Attendees". The message is sent by the "Organizer" of a
3052 "VTODO" calendar component to the "Attendees" of the "VTODO" calendar
3053 component. For a recurring "VTODO" calendar component, either the
3054 whole "VTODO" calendar component or instances of a "VTODO" calendar
3055 component may be cancelled. To cancel the complete range of a
3056 recurring "VTODO" calendar component, the "UID" property value for
3057 the "VTODO" calendar component MUST be specified and a "RECURRENCE-
3058 ID" MUST NOT be specified in the "CANCEL" method. In order to cancel
3059 an individual instance of a recurring "VTODO" calendar component, the
3060 "RECURRENCE-ID" property value for the "VTODO" calendar component
3061 MUST be specified in the "CANCEL" method.
3063 There are two options for canceling a sequence of instances of a
3064 recurring "VTODO" calendar component:
3066 a. The "RECURRENCE-ID" property for an instance in the sequence MUST
3067 be specified with the "RANGE" property parameter value of
3068 "THISANDFUTURE" to indicate cancellation of the specified "VTODO"
3069 calendar component and all instances after.
3071 b. Individual recurrence instances may be cancelled by specifying
3072 multiple "VTODO" components each with a "RECURRENCE-ID" property
3073 corresponding to one of the instances to be cancelled.
3075 The "Organizer" MUST send a "CANCEL" message to each "Attendee"
3076 affected by the cancellation. This can be done by using either a
3077 single "CANCEL" message for all "Attendees" or multiple messages with
3078 different subsets of the affected "Attendees" in each.
3082 Daboo Standards Track [Page 55]
3084 RFC 5546 iTIP December 2009
3087 When a "VTODO" is cancelled, the "SEQUENCE" property value MUST be
3088 incremented as described in Section 2.1.4.
3090 This method type is an iCalendar object that conforms to the
3091 following property constraints:
3093 +--------------------------------------------+
3094 | Constraints for a METHOD:CANCEL of a VTODO |
3095 +--------------------------------------------+
3097 +--------------------+----------+-----------------------------------+
3098 | Component/Property | Presence | Comment |
3099 +--------------------+----------+-----------------------------------+
3100 | METHOD | 1 | MUST be CANCEL. |
3103 | ATTENDEE | 0+ | MUST include some or all |
3104 | | | Attendees being removed from the |
3105 | | | to-do. MUST include some or all |
3106 | | | Attendees if the entire to-do is |
3108 | UID | 1 | MUST echo original UID. |
3113 | CATEGORIES | 0+ | |
3114 | CLASS | 0 or 1 | |
3116 | COMPLETED | 0 or 1 | |
3118 | CREATED | 0 or 1 | |
3119 | DESCRIPTION | 0 or 1 | |
3120 | DTSTART | 0 or 1 | |
3121 | DUE | 0 or 1 | If present, DURATION MUST NOT be |
3123 | DURATION | 0 or 1 | If present, DUE MUST NOT be |
3127 | LAST-MODIFIED | 0 or 1 | |
3128 | LOCATION | 0 or 1 | |
3129 | PERCENT-COMPLETE | 0 or 1 | |
3138 Daboo Standards Track [Page 56]
3140 RFC 5546 iTIP December 2009
3143 | RECURRENCE-ID | 0 or 1 | Only if referring to an instance |
3144 | | | of a recurring calendar |
3145 | | | component. Otherwise, it MUST |
3146 | | | NOT be present. |
3147 | RELATED-TO | 0+ | |
3148 | RESOURCES | 0+ | |
3149 | RRULE | 0 or 1 | |
3150 | PRIORITY | 0 or 1 | |
3151 | STATUS | 0 or 1 | MUST be set to CANCELLED to |
3152 | | | cancel the entire VTODO. If |
3153 | | | removing specific Attendees, then |
3154 | | | MUST NOT be included. |
3156 | IANA-PROPERTY | 0+ | |
3157 | X-PROPERTY | 0+ | |
3158 | REQUEST-STATUS | 0 | |
3162 | VTIMEZONE | 0 or 1 | MUST be present if any date/time |
3163 | | | refers to a timezone. |
3165 | IANA-COMPONENT | 0+ | |
3166 | X-COMPONENT | 0+ | |
3171 +--------------------+----------+-----------------------------------+
3175 The "REFRESH" method in a "VTODO" calendar component is used by
3176 "Attendees" of an existing "VTODO" calendar component to request an
3177 updated description from the "Organizer" of the "VTODO" calendar
3178 component. The "Organizer" of the "VTODO" calendar component MAY use
3179 this method to request an updated status from the "Attendees". The
3180 "REFRESH" method MUST specify the "UID" property corresponding to the
3181 "VTODO" calendar component needing update.
3183 A refresh of a recurrence instance of a "VTODO" calendar component
3184 may be requested by specifying the "RECURRENCE-ID" property
3185 corresponding to the associated "VTODO" calendar component. The
3186 "Organizer" responds with the latest description and rendition of the
3187 "VTODO" calendar component. In most cases, this will be a "REQUEST"
3188 unless the "VTODO" has been cancelled, in which case the "Organizer"
3189 MUST send a "CANCEL". This method is intended to facilitate machine
3190 processing of requests for updates to a "VTODO" calendar component.
3194 Daboo Standards Track [Page 57]
3196 RFC 5546 iTIP December 2009
3199 This method type is an iCalendar object that conforms to the
3200 following property constraints:
3202 +---------------------------------------------+
3203 | Constraints for a METHOD:REFRESH of a VTODO |
3204 +---------------------------------------------+
3206 +--------------------+----------+-----------------------------------+
3207 | Component/Property | Presence | Comment |
3208 +--------------------+----------+-----------------------------------+
3209 | METHOD | 1 | MUST be REFRESH. |
3214 | UID | 1 | MUST echo original UID. |
3215 | RECURRENCE-ID | 0 or 1 | Only if referring to an instance |
3216 | | | of a recurring calendar |
3217 | | | component. Otherwise, it MUST |
3218 | | | NOT be present. |
3219 | IANA-PROPERTY | 0+ | |
3220 | X-PROPERTY | 0+ | |
3222 | CATEGORIES | 0 | |
3228 | DESCRIPTION | 0 | |
3234 | LAST-MODIFIED | 0 | |
3237 | PERCENT-COMPLETE | 0 | |
3240 | RELATED-TO | 0 | |
3241 | REQUEST-STATUS | 0 | |
3250 Daboo Standards Track [Page 58]
3252 RFC 5546 iTIP December 2009
3258 | VTIMEZONE | 0+ | |
3260 | IANA-COMPONENT | 0+ | |
3261 | X-COMPONENT | 0+ | |
3266 +--------------------+----------+-----------------------------------+
3270 The "COUNTER" method in a "VTODO" calendar component is used by an
3271 "Attendee" of an existing "VTODO" calendar component to submit to the
3272 "Organizer" a counter proposal for the "VTODO" calendar component.
3274 The counter proposal is an iCalendar object consisting of a "VTODO"
3275 calendar component that provides the complete description of the
3276 alternate "VTODO" calendar component.
3278 The "Organizer" rejects the counter proposal by sending the
3279 "Attendee" a "DECLINECOUNTER" method. The "Organizer" accepts the
3280 counter proposal by rescheduling the to-do as described in
3281 Section 3.4.2.1, "REQUEST for Rescheduling a To-Do". The
3282 "Organizer's" CUA SHOULD send a "REQUEST" message to all "Attendees"
3283 affected by any change triggered by an accepted "COUNTER".
3285 This method type is an iCalendar object that conforms to the
3286 following property constraints:
3288 +---------------------------------------------+
3289 | Constraints for a METHOD:COUNTER of a VTODO |
3290 +---------------------------------------------+
3292 +--------------------+----------+-----------------------------------+
3293 | Component/Property | Presence | Comment |
3294 +--------------------+----------+-----------------------------------+
3295 | METHOD | 1 | MUST be COUNTER. |
3302 | SUMMARY | 1 | Can be null. |
3306 Daboo Standards Track [Page 59]
3308 RFC 5546 iTIP December 2009
3313 | CATEGORIES | 0+ | |
3314 | CLASS | 0 or 1 | |
3316 | COMPLETED | 0 or 1 | |
3318 | CREATED | 0 or 1 | |
3319 | DESCRIPTION | 0 or 1 | Can be null. |
3320 | DTSTART | 0 or 1 | |
3321 | DUE | 0 or 1 | If present, DURATION MUST NOT be |
3323 | DURATION | 0 or 1 | If present, DUE MUST NOT be |
3327 | LAST-MODIFIED | 0 or 1 | |
3328 | LOCATION | 0 or 1 | |
3329 | PERCENT-COMPLETE | 0 or 1 | |
3331 | RECURRENCE-ID | 0 or 1 | Only if referring to an instance |
3332 | | | of a recurring calendar |
3333 | | | component. Otherwise, it MUST |
3334 | | | NOT be present. |
3335 | RELATED-TO | 0+ | |
3336 | REQUEST-STATUS | 0+ | |
3337 | RESOURCES | 0+ | |
3338 | RRULE | 0 or 1 | |
3339 | SEQUENCE | 0 or 1 | MUST echo the original SEQUENCE |
3340 | | | number. MUST be present if |
3341 | | | non-zero. MAY be present if |
3343 | STATUS | 0 or 1 | MAY be one of |
3344 | | | COMPLETED/NEEDS-ACTION/ |
3345 | | | IN-PROCESS/CANCELLED. |
3347 | IANA-PROPERTY | 0+ | |
3348 | X-PROPERTY | 0+ | |
3352 | VTIMEZONE | 0 or 1 | MUST be present if any date/time |
3353 | | | refers to a timezone. |
3355 | IANA-COMPONENT | 0+ | |
3356 | X-COMPONENT | 0+ | |
3362 Daboo Standards Track [Page 60]
3364 RFC 5546 iTIP December 2009
3370 +--------------------+----------+-----------------------------------+
3372 3.4.8. DECLINECOUNTER
3374 The "DECLINECOUNTER" method in a "VTODO" calendar component is used
3375 by an "Organizer" of the "VTODO" calendar component to reject a
3376 counter proposal offered by one of the "Attendees". The "Organizer"
3377 sends the message to the "Attendee" that sent the "COUNTER" method to
3380 This method type is an iCalendar object that conforms to the
3381 following property constraints:
3383 +----------------------------------------------------+
3384 | Constraints for a METHOD:DECLINECOUNTER of a VTODO |
3385 +----------------------------------------------------+
3387 +--------------------+----------+-----------------------------------+
3388 | Component/Property | Presence | Comment |
3389 +--------------------+----------+-----------------------------------+
3390 | METHOD | 1 | MUST be DECLINECOUNTER. |
3393 | ATTENDEE | 1+ | MUST for all ATTENDEEs. |
3396 | SEQUENCE | 1 | MUST echo the original SEQUENCE |
3398 | UID | 1 | MUST echo original UID. |
3400 | CATEGORIES | 0+ | |
3401 | CLASS | 0 or 1 | |
3403 | COMPLETED | 0 or 1 | |
3405 | CREATED | 0 or 1 | |
3406 | DESCRIPTION | 0 or 1 | |
3407 | DTSTART | 0 or 1 | |
3408 | DUE | 0 or 1 | If present, DURATION MUST NOT be |
3410 | DURATION | 0 or 1 | If present, DUE MUST NOT be |
3414 | LAST-MODIFIED | 0 or 1 | |
3418 Daboo Standards Track [Page 61]
3420 RFC 5546 iTIP December 2009
3423 | LOCATION | 0 or 1 | |
3424 | PERCENT-COMPLETE | 0 or 1 | |
3425 | PRIORITY | 0 or 1 | |
3427 | RECURRENCE-ID | 0 or 1 | Only if referring to an instance |
3428 | | | of a recurring calendar |
3429 | | | component. Otherwise, it MUST |
3430 | | | NOT be present. |
3431 | RELATED-TO | 0+ | |
3432 | REQUEST-STATUS | 0+ | |
3433 | RESOURCES | 0+ | |
3434 | RRULE | 0 or 1 | |
3435 | STATUS | 0 or 1 | MAY be one of |
3436 | | | COMPLETED/NEEDS-ACTION/ |
3439 | IANA-PROPERTY | 0+ | |
3440 | X-PROPERTY | 0+ | |
3444 | VTIMEZONE | 0+ | MUST be present if any date/time |
3445 | | | refers to a timezone. |
3447 | IANA-COMPONENT | 0+ | |
3448 | X-COMPONENT | 0+ | |
3453 +--------------------+----------+-----------------------------------+
3455 3.5. Methods for VJOURNAL Components
3457 This section defines the property set for the methods that are
3458 applicable to the "VJOURNAL" calendar component.
3460 The following summarizes the methods that are defined for the
3461 "VJOURNAL" calendar component.
3474 Daboo Standards Track [Page 62]
3476 RFC 5546 iTIP December 2009
3479 +---------+---------------------------------------------------------+
3480 | Method | Description |
3481 +---------+---------------------------------------------------------+
3482 | PUBLISH | Post a journal entry. Used primarily as a method of |
3483 | | advertising the existence of a journal entry. |
3485 | ADD | Add one or more instances to an existing journal entry. |
3487 | CANCEL | Cancel one or more instances of an existing journal |
3489 +---------+---------------------------------------------------------+
3493 The "PUBLISH" method in a "VJOURNAL" calendar component has no
3494 associated response. It is simply a posting of an iCalendar object
3495 that may be added to a calendar. It MUST have an "Organizer". It
3496 MUST NOT have "Attendees". The expected usage is for encapsulating
3497 an arbitrary journal entry as an iCalendar object. The "Organizer"
3498 MAY subsequently update (with another "PUBLISH" method) or cancel
3499 (with a "CANCEL" method) a previously published journal entry.
3501 This method type is an iCalendar object that conforms to the
3502 following property constraints:
3504 +------------------------------------------------+
3505 | Constraints for a METHOD:PUBLISH of a VJOURNAL |
3506 +------------------------------------------------+
3508 +--------------------+----------+-----------------------------------+
3509 | Component/Property | Presence | Comment |
3510 +--------------------+----------+-----------------------------------+
3511 | METHOD | 1 | MUST be PUBLISH. |
3514 | DESCRIPTION | 1 | Can be null. |
3520 | CATEGORIES | 0+ | |
3521 | CLASS | 0 or 1 | |
3524 | CREATED | 0 or 1 | |
3526 | LAST-MODIFIED | 0 or 1 | |
3530 Daboo Standards Track [Page 63]
3532 RFC 5546 iTIP December 2009
3536 | RECURRENCE-ID | 0 or 1 | Only if referring to an instance |
3537 | | | of a recurring calendar |
3538 | | | component. Otherwise, it MUST |
3539 | | | NOT be present. |
3540 | RELATED-TO | 0+ | |
3541 | RRULE | 0 or 1 | |
3542 | SEQUENCE | 0 or 1 | MUST be present if non-zero. MAY |
3543 | | | be present if zero. |
3544 | STATUS | 0 or 1 | MAY be one of |
3545 | | | DRAFT/FINAL/CANCELLED. |
3546 | SUMMARY | 0 or 1 | Can be null. |
3548 | IANA-PROPERTY | 0+ | |
3549 | X-PROPERTY | 0+ | |
3551 | REQUEST-STATUS | 0 | |
3555 | VTIMEZONE | 0+ | MUST be present if any date/time |
3556 | | | refers to a timezone. |
3558 | IANA-COMPONENT | 0+ | |
3559 | X-COMPONENT | 0+ | |
3566 +--------------------+----------+-----------------------------------+
3570 The "ADD" method allows the "Organizer" to add one or more new
3571 instances to an existing "VJOURNAL" using a single iTIP message
3572 without having to send the entire "VJOURNAL" with all the existing
3573 instance data, as it would have to do if the "REQUEST" method were
3576 The "UID" must be that of the existing journal entry. If the "UID"
3577 property value in the "ADD" is not found on the recipient's calendar,
3578 then the recipient MAY treat the "ADD" as a "PUBLISH".
3580 When handling an "ADD" message, the "Attendee" treats each component
3581 in the "ADD" message as if it were referenced via an "RDATE" in the
3582 main component. There is no response to the "Organizer".
3586 Daboo Standards Track [Page 64]
3588 RFC 5546 iTIP December 2009
3591 This method type is an iCalendar object that conforms to the
3592 following property constraints:
3594 +--------------------------------------------+
3595 | Constraints for a METHOD:ADD of a VJOURNAL |
3596 +--------------------------------------------+
3598 +--------------------+----------+-----------------------------------+
3599 | Component/Property | Presence | Comment |
3600 +--------------------+----------+-----------------------------------+
3601 | METHOD | 1 | MUST be ADD. |
3604 | DESCRIPTION | 1 | Can be null. |
3608 | SEQUENCE | 1 | MUST be greater than 0. |
3609 | UID | 1 | MUST match that of the original |
3612 | CATEGORIES | 0+ | |
3613 | CLASS | 0 or 1 | |
3616 | CREATED | 0 or 1 | |
3617 | LAST-MODIFIED | 0 or 1 | |
3618 | RELATED-TO | 0+ | |
3619 | STATUS | 0 or 1 | MAY be one of |
3620 | | | DRAFT/FINAL/CANCELLED. |
3621 | SUMMARY | 0 or 1 | Can be null. |
3623 | IANA-PROPERTY | 0+ | |
3624 | X-PROPERTY | 0+ | |
3627 | RECURRENCE-ID | 0 | |
3628 | REQUEST-STATUS | 0 | |
3634 | VTIMEZONE | 0 or 1 | MUST be present if any date/time |
3635 | | | refers to a timezone. |
3637 | IANA-COMPONENT | 0+ | |
3638 | X-COMPONENT | 0+ | |
3642 Daboo Standards Track [Page 65]
3644 RFC 5546 iTIP December 2009
3653 +--------------------+----------+-----------------------------------+
3657 The "CANCEL" method in a "VJOURNAL" calendar component is used to
3658 send a cancellation notice of an existing journal entry. The message
3659 is sent by the "Organizer" of a journal entry. For a recurring
3660 journal entry, either the whole journal entry or instances of a
3661 journal entry may be cancelled. To cancel the complete range of a
3662 recurring journal entry, the "UID" property value for the journal
3663 entry MUST be specified and a "RECURRENCE-ID" property MUST NOT be
3664 specified in the "CANCEL" method. In order to cancel an individual
3665 instance of the journal entry, the "RECURRENCE-ID" property value for
3666 the journal entry MUST be specified in the "CANCEL" method.
3668 There are two options for canceling a sequence of instances of a
3669 recurring "VJOURNAL" calendar component:
3671 a. The "RECURRENCE-ID" property for an instance in the sequence MUST
3672 be specified with the "RANGE" property parameter value of
3673 "THISANDFUTURE" to indicate cancellation of the specified
3674 "VJOURNAL" calendar component and all instances after.
3676 b. Individual recurrence instances may be cancelled by specifying
3677 multiple "VJOURNAL" components each with a "RECURRENCE-ID"
3678 property corresponding to one of the instances to be cancelled.
3680 When a "VJOURNAL" is cancelled, the "SEQUENCE" property value MUST be
3681 incremented as described in Section 2.1.4.
3683 This method type is an iCalendar object that conforms to the
3684 following property constraints:
3698 Daboo Standards Track [Page 66]
3700 RFC 5546 iTIP December 2009
3703 +-----------------------------------------------+
3704 | Constraints for a METHOD:CANCEL of a VJOURNAL |
3705 +-----------------------------------------------+
3707 +--------------------+----------+-----------------------------------+
3708 | Component/Property | Presence | Comment |
3709 +--------------------+----------+-----------------------------------+
3710 | METHOD | 1 | MUST be CANCEL. |
3712 | VJOURNAL | 1+ | All MUST have the same UID. |
3716 | UID | 1 | MUST be the UID of the original |
3720 | CATEGORIES | 0+ | |
3721 | CLASS | 0 or 1 | |
3724 | CREATED | 0 or 1 | |
3725 | DESCRIPTION | 0 or 1 | |
3726 | DTSTART | 0 or 1 | |
3728 | LAST-MODIFIED | 0 or 1 | |
3730 | RECURRENCE-ID | 0 or 1 | Only if referring to an instance |
3731 | | | of a recurring calendar |
3732 | | | component. Otherwise, it MUST |
3733 | | | NOT be present. |
3734 | RELATED-TO | 0+ | |
3735 | RRULE | 0 or 1 | |
3736 | STATUS | 0 or 1 | MAY be present; MUST be CANCELLED |
3738 | SUMMARY | 0 or 1 | |
3740 | IANA-PROPERTY | 0+ | |
3741 | X-PROPERTY | 0+ | |
3742 | REQUEST-STATUS | 0 | |
3746 | VTIMEZONE | 0+ | MUST be present if any date/time |
3747 | | | refers to a timezone. |
3749 | IANA-COMPONENT | 0+ | |
3750 | X-COMPONENT | 0+ | |
3754 Daboo Standards Track [Page 67]
3756 RFC 5546 iTIP December 2009
3765 +--------------------+----------+-----------------------------------+
3769 The "REQUEST-STATUS" property is used to convey status information
3770 about a "REPLY", "COUNTER", or "DECLINECOUNTER" iTIP message. The
3771 codes listed in the table below SHOULD be used. If the "REQUEST-
3772 STATUS" property is not present in one of these iTIP messages, then a
3773 status code of "2.0" (success) MUST be assumed.
3775 This specification adds a new IANA registry for "REQUEST-STATUS"
3776 property values, as defined in Section 7, which includes a new
3777 registration template for defining the specific components of the
3778 "REQUEST-STATUS" property value. Additional codes MAY be used,
3779 provided the process described in Section 8.2.1 of [RFC5545] is used
3782 This specification allows for multiple "REQUEST-STATUS" properties to
3783 be returned in iCalendar components in the appropriate iTIP messages.
3784 When multiple "REQUEST-STATUS" properties are present, the following
3787 1. Within any one component, the "top-level" numeric value of the
3788 "short return status code" MUST be the same for all "REQUEST-
3789 STATUS" properties, i.e., there cannot be a mixture of, e.g.,
3790 2.xx and 5.xx codes within a single component.
3792 2. Across all components in the iTIP message, the following applies:
3794 A. If any one component would have a 5.xx code, then either all
3795 components MUST have a code in that range or "REQUEST-STATUS"
3796 MUST NOT be present in the other components if a 5.xx code is
3797 not appropriate for those components.
3799 B. Otherwise, if any one component would have a 3.xx code, then
3800 either all components MUST have a code in that range or
3801 "REQUEST-STATUS" MUST NOT be present in the other components
3802 if a 3.xx code is not appropriate for those components.
3804 C. 2.xx and 4.xx codes can be used in different components,
3805 provided that each component follows the restriction in (1)
3810 Daboo Standards Track [Page 68]
3812 RFC 5546 iTIP December 2009
3815 The following "REQUEST-STATUS" codes are defined (any "Offending
3816 Data" MAY be specified in the "REQUEST-STATUS" value as the extdata
3819 3.6.1. Status Code 2.0
3823 Status Description: Success.
3825 Status Exception Data: None.
3827 Description: iTIP operation succeeded.
3829 3.6.2. Status Code 2.1
3833 Status Description: Success, but fallback taken on one or more
3836 Status Exception Data: Property name and value MAY be specified.
3838 Description: iTIP operation succeeded with fallback on one or more
3841 3.6.3. Status Code 2.2
3845 Status Description: Success; invalid property ignored.
3847 Status Exception Data: Property name MAY be specified.
3849 Description: iTIP operation succeeded but a property was ignored.
3851 3.6.4. Status Code 2.3
3855 Status Description: Success; invalid property parameter ignored.
3857 Status Exception Data: Property parameter name and value MAY be
3860 Description: iTIP operation succeeded but a property parameter was
3861 ignored because it was invalid.
3866 Daboo Standards Track [Page 69]
3868 RFC 5546 iTIP December 2009
3871 3.6.5. Status Code 2.4
3875 Status Description: Success; unknown, non-standard property ignored.
3877 Status Exception Data: Non-standard property name MAY be specified.
3879 Description: iTIP operation succeeded but a property parameter was
3880 ignored because it was unknown.
3882 3.6.6. Status Code 2.5
3886 Status Description: Success; unknown, non-standard property value
3889 Status Exception Data: Property and non-standard value MAY be
3892 Description: iTIP operation succeeded but a property was ignored
3893 because its value was unknown.
3895 3.6.7. Status Code 2.6
3899 Status Description: Success; invalid calendar component ignored.
3901 Status Exception Data: Calendar component sentinel (e.g., BEGIN:
3902 ALARM) MAY be specified.
3904 Description: iTIP operation succeeded but a component was ignored
3905 because it was invalid.
3907 3.6.8. Status Code 2.7
3911 Status Description: Success; request forwarded to Calendar User.
3913 Status Exception Data: Original and forwarded calendar user
3914 addresses MAY be specified.
3916 Description: iTIP operation succeeded, and the request was forwarded
3917 to another Calendar User.
3922 Daboo Standards Track [Page 70]
3924 RFC 5546 iTIP December 2009
3927 3.6.9. Status Code 2.8
3931 Status Description: Success; repeating event ignored. Scheduled as
3934 Status Exception Data: RRULE or RDATE property name and value MAY be
3937 Description: iTIP operation succeeded but a repeating event was
3938 truncated to a single instance.
3940 3.6.10. Status Code 2.9
3944 Status Description: Success; truncated end date time to date
3947 Status Exception Data: DTEND property value MAY be specified.
3949 Description: iTIP operation succeeded but the end time was truncated
3952 3.6.11. Status Code 2.10
3956 Status Description: Success; repeating VTODO ignored. Scheduled as
3959 Status Exception Data: RRULE or RDATE property name and value MAY be
3962 Description: iTIP operation succeeded but a repeating to-do was
3963 truncated to a single instance.
3978 Daboo Standards Track [Page 71]
3980 RFC 5546 iTIP December 2009
3983 3.6.12. Status Code 2.11
3987 Status Description: Success; unbounded RRULE clipped at some finite
3988 number of instances.
3990 Status Exception Data: RRULE property name and value MAY be
3991 specified. Number of instances MAY also be specified.
3993 Description: iTIP operation succeeded but an unbounded repeating
3994 object was clipped to a finite number of instances.
3996 3.6.13. Status Code 3.0
4000 Status Description: Invalid property name.
4002 Status Exception Data: Property name MAY be specified.
4004 Description: iTIP operation failed because of an invalid property
4007 3.6.14. Status Code 3.1
4011 Status Description: Invalid property value.
4013 Status Exception Data: Property name and value MAY be specified.
4015 Description: iTIP operation failed because of an invalid property
4018 3.6.15. Status Code 3.2
4022 Status Description: Invalid property parameter.
4024 Status Exception Data: Property parameter name and value MAY be
4027 Description: iTIP operation failed because of an invalid property
4034 Daboo Standards Track [Page 72]
4036 RFC 5546 iTIP December 2009
4039 3.6.16. Status Code 3.3
4043 Status Description: Invalid property parameter value.
4045 Status Exception Data: Property parameter name and value MAY be
4048 Description: iTIP operation failed because of an invalid property
4051 3.6.17. Status Code 3.4
4055 Status Description: Invalid calendar component sequence.
4057 Status Exception Data: Calendar component sentinel MAY be specified
4058 (e.g., BEGIN:VTIMEZONE).
4060 Description: iTIP operation failed because of an invalid component.
4062 3.6.18. Status Code 3.5
4066 Status Description: Invalid date or time.
4068 Status Exception Data: Date/time value(s) MAY be specified.
4070 Description: iTIP operation failed because of an invalid date or
4073 3.6.19. Status Code 3.6
4077 Status Description: Invalid rule.
4079 Status Exception Data: RRULE property value MAY be specified.
4081 Description: iTIP operation failed because of an invalid rule
4090 Daboo Standards Track [Page 73]
4092 RFC 5546 iTIP December 2009
4095 3.6.20. Status Code 3.7
4099 Status Description: Invalid Calendar User.
4101 Status Exception Data: ATTENDEE property value MAY be specified.
4103 Description: iTIP operation failed because of an invalid ATTENDEE
4106 3.6.21. Status Code 3.8
4110 Status Description: No authority.
4112 Status Exception Data: METHOD and ATTENDEE property values MAY be
4115 Description: iTIP operation failed because an Attendee does not have
4116 suitable privileges for the operation.
4118 3.6.22. Status Code 3.9
4122 Status Description: Unsupported version.
4124 Status Exception Data: VERSION property name and value MAY be
4127 Description: iTIP operation failed because the calendar data version
4130 3.6.23. Status Code 3.10
4134 Status Description: Request entity too large.
4136 Status Exception Data: None.
4138 Description: iTIP operation failed because the calendar data was too
4146 Daboo Standards Track [Page 74]
4148 RFC 5546 iTIP December 2009
4151 3.6.24. Status Code 3.11
4155 Status Description: Required component or property missing.
4157 Status Exception Data: Component or property name MAY be specified.
4159 Description: iTIP operation failed because the calendar data did not
4160 contain a required property or component.
4162 3.6.25. Status Code 3.12
4166 Status Description: Unknown component or property found.
4168 Status Exception Data: Component or property name MAY be specified.
4170 Description: iTIP operation failed because the calendar data
4171 contained an unknown property or component.
4173 3.6.26. Status Code 3.13
4177 Status Description: Unsupported component or property found.
4179 Status Exception Data: Component or property name MAY be specified.
4181 Description: iTIP operation failed because the calendar data
4182 contained an unsupported property or component.
4184 3.6.27. Status Code 3.14
4188 Status Description: Unsupported capability.
4190 Status Exception Data: METHOD or action MAY be specified.
4192 Description: iTIP operation failed because the operation is not
4202 Daboo Standards Track [Page 75]
4204 RFC 5546 iTIP December 2009
4207 3.6.28. Status Code 4.0
4211 Status Description: Event conflict. Date/time is busy.
4213 Status Exception Data: DTSTART and DTEND property names and values
4216 Description: iTIP operation failed because the event overlaps the
4217 date and time of another event.
4219 3.6.29. Status Code 5.0
4223 Status Description: Request not supported.
4225 Status Exception Data: METHOD property value MAY be specified.
4227 Description: iTIP operation failed because the operation is not
4230 3.6.30. Status Code 5.1
4234 Status Description: Service unavailable.
4236 Status Exception Data: ATTENDEE property value MAY be specified.
4238 Description: iTIP operation failed because scheduling is not active.
4240 3.6.31. Status Code 5.2
4244 Status Description: Invalid calendar service.
4246 Status Exception Data: ATTENDEE property value MAY be specified.
4248 Description: iTIP operation failed because there is no scheduling
4258 Daboo Standards Track [Page 76]
4260 RFC 5546 iTIP December 2009
4263 3.6.32. Status Code 5.3
4267 Status Description: No scheduling support for user.
4269 Status Exception Data: ATTENDEE property value MAY be specified.
4271 Description: iTIP operation failed because scheduling is not enabled
4274 3.7. Implementation Considerations
4276 3.7.1. Working With Recurrence Instances
4278 iCalendar includes a recurrence grammar to represent recurring
4279 events. The benefit of such a grammar is the ability to represent a
4280 number of events in a single object. However, while this simplifies
4281 creation of a recurring event, meeting instances still need to be
4282 referenced. For instance, an "Attendee" may decline the third
4283 instance of a recurring Friday event. Similarly, the "Organizer" may
4284 change the time or location to a single instance of the recurring
4287 Since implementations may elect to store recurring events as either a
4288 single event object or a collection of discrete, related event
4289 objects, the protocol is designed so that each recurring instance may
4290 be both referenced and versioned. Hence, implementations that choose
4291 to maintain per-instance properties (such as "ATTENDEE" property
4292 "PARTSTAT" parameter) may do so. However, the protocol does not
4293 require per-instance recognition unless the instance itself must be
4296 The scenarios for recurrence instance referencing are listed below.
4297 For purposes of simplification, a change to an event refers to a
4298 "trigger property." That is, a property that has a substantive
4299 effect on the meeting itself, such as start time, location, due date
4300 (for "VTODO" calendar components), and possibly description.
4302 "Organizer"-initiated actions:
4304 o deletes or changes a single instance of a recurring event
4306 o makes changes that affect all future instances
4308 o makes changes that affect all previous instances
4310 o deletes or modifies a previously changed instance
4314 Daboo Standards Track [Page 77]
4316 RFC 5546 iTIP December 2009
4319 "Attendee"-initiated actions:
4321 o changes status for a particular recurrence instance
4323 o sends a "COUNTER" for a particular recurrence instance
4325 An instance of a recurring event is assigned a unique identification,
4326 "RECURRENCE-ID" property, when that instance is renegotiated.
4327 Negotiation may be necessary when a substantive change to the event
4328 or to-do has been made (such as changing the start time, end time,
4329 due date, or location). The "Organizer" can identify a specific
4330 recurrence instance using the "RECURRENCE-ID" property. The property
4331 value is equal to the date/time of the instance. If the "Organizer"
4332 wishes to change the "DTSTART", the original, unmodified "DTSTART"
4333 value of the instance is used as the value "RECURRENCE-ID" property,
4334 and the new "DTSTART" and "DTEND" values reflect the change.
4336 3.7.2. Attendee Property Considerations
4338 The "ORGANIZER" property is required on published events, to-dos, and
4339 journal entries for two reasons. First, only the "Organizer" is
4340 allowed to update and redistribute an event or to-do component. It
4341 follows that the "ORGANIZER" property MUST be present in the event,
4342 to-do, or journal entry component so that the CUA has a basis for
4343 authorizing an update. Second, it is prudent to provide a point of
4344 contact for anyone who receives a published component, in case of
4347 Email addresses that correspond to groups of "Calendar Users" could
4348 be specified as a mailto: URI [RFC2368] calendar user address.
4349 Sending email to such an address results in email being sent to
4350 multiple recipients. Such an address may be used as the value of an
4351 "ATTENDEE" property. Thus, it is possible that the recipient of a
4352 "REQUEST" does not appear explicitly in the list.
4354 It is recommended that the general approach to finding a "Calendar
4355 User" in an "Attendee" list be as follows:
4357 1. Search for the "Calendar User" in the "Attendee" list where
4360 2. Failing (1), look for "Attendees" where "CUTYPE=GROUP" or
4361 "CUTYPE=UNKNOWN". The CUA then determines if the "Calendar User"
4362 is a member of one of these groups. If so, the "REPLY" method
4363 sent to the "Organizer" MUST contain a new "ATTENDEE" property in
4366 * the "TYPE" property parameter is set to INDIVIDUAL
4370 Daboo Standards Track [Page 78]
4372 RFC 5546 iTIP December 2009
4375 * the "MEMBER" property parameter is set to the name of the
4378 3. Failing (2), the CUA MAY ignore or accept the request as the
4379 "Calendar User" wishes.
4381 3.7.3. Extension Tokens
4383 To make iCalendar objects extensible, new component, property, or
4384 property parameters can be used. Two types of extensions are defined
4385 by [RFC5545]: IANA-registered tokens ("iana-token") and experimental
4386 use tokens ("x-name"). A client SHOULD save "iana-token's" and MAY
4387 use them in replies. A client MAY save "x-name's" and MAY use them
4388 in replies. When delegating or forwarding messages to other CUs, a
4389 client SHOULD include "iana-token's" and "x-names's".
4393 4.1. Published Event Examples
4395 In the calendaring and scheduling context, publication refers to the
4396 one-way transfer of event information. Consumers of published events
4397 simply incorporate the event into a calendar. No reply is expected.
4398 Individual "A" publishes an event. Individual "B" reads the event
4399 and incorporates it into their calendar. Events are published in
4400 several ways, including embedding the event as an object in a web
4401 page, emailing the event to a distribution list, or posting the event
4404 The table below illustrates the sequence of events between the
4405 publisher and the consumers of a published event.
4407 +----------------+-----------------------+--------------------------+
4408 | Action | Organizer | Receiver |
4409 +----------------+-----------------------+--------------------------+
4410 | Publish an | "A" sends or posts a | "B" reads a published |
4411 | event | PUBLISH message. | event. |
4413 | Publish an | "A" sends or posts a | "B" reads the updated |
4414 | updated event | PUBLISH message. | event. |
4416 | Cancel a | "A" sends or posts a | "B" reads the canceled |
4417 | published | CANCEL message. | event publication. |
4419 +----------------+-----------------------+--------------------------+
4426 Daboo Standards Track [Page 79]
4428 RFC 5546 iTIP December 2009
4431 4.1.1. A Minimal Published Event
4433 The iCalendar object below describes a single event that begins on
4434 July 1, 1997 at 20:00 UTC. This event contains the minimum set of
4435 properties for a "PUBLISH" for a "VEVENT" calendar component.
4439 PRODID:-//Example/ExampleCalendarClient//EN
4442 ORGANIZER:mailto:a@example.com
4443 DTSTART:19970701T200000Z
4444 DTSTAMP:19970611T190000Z
4445 SUMMARY:ST. PAUL SAINTS -VS- DULUTH-SUPERIOR DUKES
4446 UID:0981234-1234234-23@example.com
4450 4.1.2. Changing a Published Event
4452 The iCalendar object below describes an update to the event described
4453 in Section 4.1.1; the time has been changed, an end time has been
4454 added, and the sequence number has been adjusted.
4459 PRODID:-//Example/ExampleCalendarClient//EN
4461 ORGANIZER:mailto:a@example.com
4462 DTSTAMP:19970612T190000Z
4463 DTSTART:19970701T210000Z
4464 DTEND:19970701T230000Z
4466 UID:0981234-1234234-23@example.com
4467 SUMMARY:ST. PAUL SAINTS -VS- DULUTH-SUPERIOR DUKES
4471 The "UID" property is used by the client to identify the event. The
4472 "SEQUENCE" property indicates that this is a change to the event.
4473 The event with a matching "UID" and sequence number 0 is superseded
4476 The "SEQUENCE" property provides a reliable way to distinguish
4477 different versions of the same event. Each time an event is
4478 published, its sequence number is incremented. If a client receives
4482 Daboo Standards Track [Page 80]
4484 RFC 5546 iTIP December 2009
4487 an event with a sequence number 5 and finds it has the same event
4488 with sequence number 2, the event SHOULD be updated. However, if the
4489 client received an event with sequence number 2 and finds it already
4490 has sequence number 5 of the same event, the event MUST NOT be
4493 4.1.3. Canceling a Published Event
4495 The iCalendar object below cancels the event described in
4496 Section 4.1.1. This cancels the event with "SEQUENCE" property of 0,
4502 PRODID:-//Example/ExampleCalendarClient//EN
4504 ORGANIZER:mailto:a@example.com
4505 COMMENT:DUKES forfeit the game
4507 UID:0981234-1234234-23@example.com
4508 DTSTAMP:19970613T190000Z
4512 4.1.4. A Rich Published Event
4514 This example describes the same event as in Section 4.1.1, but in
4515 much greater detail.
4518 PRODID:-//Example/ExampleCalendarClient//EN
4523 TZID:America-Chicago
4524 TZURL:http://example.com/tz/America-Chicago
4526 DTSTART:19671029T020000
4527 RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=10
4533 DTSTART:19870405T020000
4534 RRULE:FREQ=YEARLY;BYDAY=1SU;BYMONTH=4
4538 Daboo Standards Track [Page 81]
4540 RFC 5546 iTIP December 2009
4549 ORGANIZER:mailto:a@example.com
4550 ATTACH:http://www.example.com/
4551 CATEGORIES:SPORTS EVENT,ENTERTAINMENT
4553 DESCRIPTION:MIDWAY STADIUM\n
4554 Big time game. MUST see.\n
4555 Expected duration:2 hours\n
4556 DTEND;TZID=America-Chicago:19970701T180000
4557 DTSTART;TZID=America-Chicago:19970702T160000
4558 DTSTAMP:19970614T190000Z
4560 LOCATION;VALUE=URI:http://stadium.example.com/
4562 RESOURCES:SCOREBOARD
4564 SUMMARY:ST. PAUL SAINTS -VS- DULUTH-SUPERIOR DUKES
4565 UID:0981234-1234234-23@example.com
4566 RELATED-TO:0981234-1234234-14@example.com
4570 DESCRIPTION:You should be leaving for the game now.
4579 The "RELATED-TO" field contains the "UID" property of a related
4580 calendar event. The "SEQUENCE" property 3 indicates that this event
4581 supersedes versions 0, 1, and 2.
4594 Daboo Standards Track [Page 82]
4596 RFC 5546 iTIP December 2009
4599 4.1.5. Anniversaries or Events Attached to Entire Days
4601 This example demonstrates the use of the "VALUE" parameter to tie a
4602 "VEVENT" to a day rather than a specific time.
4605 PRODID:-//Example/ExampleCalendarClient//EN
4609 ORGANIZER:mailto:a@example.com
4610 DTSTAMP:19970614T190000Z
4611 UID:0981234-1234234-23@example.com
4612 DTSTART;VALUE=DATE:19970714
4613 RRULE:FREQ=YEARLY;INTERVAL=1
4614 SUMMARY: Bastille Day
4618 4.2. Group Event Examples
4620 Group events are distinguished from published events in that they
4621 have "Attendees" and there is interaction between the "Attendees" and
4622 the "Organizer" with respect to the event. Individual "A" requests a
4623 meeting between individuals "A", "B", "C", and "D". Individual "B"
4624 confirms attendance to the meeting. Individual "C" declines
4625 attendance. Individual "D" tentatively confirms attendance. The
4626 following table illustrates the message flow between these
4627 individuals. "A", the CU scheduling the meeting, is referenced as
4650 Daboo Standards Track [Page 83]
4652 RFC 5546 iTIP December 2009
4655 +--------------+-----------------------+----------------------------+
4656 | Action | "Organizer" | Attendee |
4657 +--------------+-----------------------+----------------------------+
4658 | Initiate a | "A" sends a REQUEST | |
4659 | meeting | message to "B", "C", | |
4660 | request | and "D". | |
4662 | Accept the | | "B" sends a REPLY message |
4663 | meeting | | to "A" with its ATTENDEE |
4664 | request | | PARTSTAT parameter set to |
4667 | Decline the | | "C" sends a REPLY message |
4668 | meeting | | to "A" with its ATTENDEE |
4669 | request | | PARTSTAT parameter set to |
4672 | Tentatively | | "D" sends a REPLY message |
4673 | accept the | | to "A" with its ATTENDEE |
4674 | meeting | | PARTSTAT parameter set to |
4675 | request | | TENTATIVE. |
4677 | Confirm | "A" sends a REQUEST | |
4678 | meeting | message to "B" and | |
4679 | status with | "D" with updated | |
4680 | Attendees | information. | |
4681 +--------------+-----------------------+----------------------------+
4683 4.2.1. A Group Event Request
4685 A sample meeting request is sent from "A" to "B", "C", and "D". "E"
4686 is also sent a copy of the request but is not expected to attend and
4687 need not reply. "E" illustrates how CUAs might implement an "FYI"-
4688 type feature. Note the use of the "ROLE" parameter. The default
4689 value for the "ROLE" parameter is "REQ-PARTICIPANT" and it need not
4690 be enumerated. In this case, we are using the value "NON-
4691 PARTICIPANT" to indicate "E" is a non-attending CU. The parameter is
4692 not needed on other "Attendees" since "PARTICIPANT" is the default
4696 PRODID:-//Example/ExampleCalendarClient//EN
4700 ORGANIZER:mailto:a@example.com
4701 ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED;CN=A:mailto:a@example.com
4702 ATTENDEE;RSVP=TRUE;CUTYPE=INDIVIDUAL;CN=B:mailto:b@example.com
4706 Daboo Standards Track [Page 84]
4708 RFC 5546 iTIP December 2009
4711 ATTENDEE;RSVP=TRUE;CUTYPE=INDIVIDUAL;CN=C:mailto:c@example.com
4712 ATTENDEE;RSVP=TRUE;CUTYPE=INDIVIDUAL;CN=Hal:mailto:d@example.com
4713 ATTENDEE;RSVP=FALSE;CUTYPE=ROOM:conf_big@example.com
4714 ATTENDEE;ROLE=NON-PARTICIPANT;RSVP=FALSE:mailto:e@example.com
4715 DTSTAMP:19970611T190000Z
4716 DTSTART:19970701T200000Z
4717 DTEND:19970701T2100000Z
4719 UID:calsrv.example.com-873970198738777@example.com
4725 4.2.2. Reply to a Group Event Request
4727 "Attendee" "B" accepts the meeting.
4730 PRODID:-//Example/ExampleCalendarClient//EN
4734 ATTENDEE;PARTSTAT=ACCEPTED:mailto:b@example.com
4735 ORGANIZER:mailto:a@example.com
4736 UID:calsrv.example.com-873970198738777@example.com
4738 REQUEST-STATUS:2.0;Success
4739 DTSTAMP:19970612T190000Z
4743 "B" could have declined the meeting or indicated tentative acceptance
4744 by setting the "ATTENDEE" "PARTSTAT" parameter to "DECLINED" or
4745 "TENTATIVE", respectively. Also, "REQUEST-STATUS" is not required in
4746 successful transactions.
4748 4.2.3. Update an Event
4750 The event is moved to a different time. The combination of the "UID"
4751 property (unchanged) and the "SEQUENCE" (bumped to 1) properties
4752 indicate the update.
4755 PRODID:-//Example/ExampleCalendarClient//EN
4762 Daboo Standards Track [Page 85]
4764 RFC 5546 iTIP December 2009
4767 ORGANIZER:mailto:a@example.com
4768 ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:mailto:a@example.com
4769 ATTENDEE;RSVP=TRUE;CUTYPE=INDIVIDUAL:mailto:b@example.com
4770 ATTENDEE;RSVP=TRUE;CUTYPE=INDIVIDUAL:mailto:c@example.com
4771 ATTENDEE;RSVP=TRUE;CUTYPE=INDIVIDUAL;CN=Hal:mailto:d@example.com
4772 ATTENDEE;ROLE=NON-PARTICIPANT;RSVP=FALSE;
4773 CUTYPE=ROOM:mailto:conf@example.com
4774 ATTENDEE;ROLE=NON-PARTICIPANT;RSVP=FALSE:mailto:e@example.com
4775 DTSTART:19970701T180000Z
4776 DTEND:19970701T190000Z
4777 SUMMARY:Phone Conference
4778 UID:calsrv.example.com-873970198738777@example.com
4780 DTSTAMP:19970613T190000Z
4785 4.2.4. Countering an Event Proposal
4787 "A" sends a "REQUEST" to "B" and "C". "B" makes a counter proposal
4788 to "A" to change the time and location.
4790 "A" sends the following "REQUEST":
4793 PRODID:-//Example/ExampleCalendarClient//EN
4797 ORGANIZER:mailto:a@example.com
4798 ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:mailto:a@example.com
4799 ATTENDEE;RSVP=TRUE;CUTYPE=INDIVIDUAL:mailto:b@example.com
4800 ATTENDEE;RSVP=TRUE;CUTYPE=INDIVIDUAL:mailto:c@example.com
4801 DTSTART:19970701T190000Z
4802 DTEND:19970701T200000Z
4803 SUMMARY:Discuss the Merits of the election results
4804 LOCATION:Green Conference Room
4805 UID:calsrv.example.com-873970198738777a@example.com
4807 DTSTAMP:19970611T190000Z
4818 Daboo Standards Track [Page 86]
4820 RFC 5546 iTIP December 2009
4823 "B" sends "COUNTER" to "A", requesting changes to time and place.
4824 "B" uses the "COMMENT" property to communicate a rationale for the
4825 change. Note that the "SEQUENCE" property is not incremented on a
4829 PRODID:-//Example/ExampleCalendarClient//EN
4833 ORGANIZER:mailto:a@example.com
4834 ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:mailto:a@example.com
4835 ATTENDEE;RSVP=TRUE;CUTYPE=INDIVIDUAL:mailto:b@example.com
4836 ATTENDEE;RSVP=TRUE;CUTYPE=INDIVIDUAL:mailto:c@example.com
4837 DTSTART:19970701T160000Z
4838 DTEND:19970701T170000Z
4839 DTSTAMP:19970612T190000Z
4840 SUMMARY:Discuss the Merits of the election results
4841 LOCATION:Blue Conference Room
4842 COMMENT:This time works much better and I think the big conference
4844 UID:calsrv.example.com-873970198738777a@example.com
4849 "A" accepts the changes from "B". To accept a counter proposal, the
4850 "Organizer" sends a new event "REQUEST" with an incremented sequence
4854 PRODID:-//Example/ExampleCalendarClient//EN
4858 ORGANIZER:mailto:a@example.com
4859 ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:mailto:a@example.com
4860 ATTENDEE;RSVP=TRUE;CUTYPE=INDIVIDUAL:mailto:b@example.com
4861 ATTENDEE;RSVP=TRUE;CUTYPE=INDIVIDUAL:mailto:c@example.com
4862 DTSTAMP:19970613T190000Z
4863 DTSTART:19970701T160000Z
4864 DTEND:19970701T170000Z
4865 SUMMARY:Discuss the Merits of the election results - changed to
4867 LOCATION:Blue Conference Room
4868 UID:calsrv.example.com-873970198738777@example.com
4874 Daboo Standards Track [Page 87]
4876 RFC 5546 iTIP December 2009
4882 Instead, "A" rejects "B's" counter proposal.
4885 PRODID:-//Example/ExampleCalendarClient//EN
4886 METHOD:DECLINECOUNTER
4889 ORGANIZER:mailto:a@example.com
4890 ATTENDEE;RSVP=TRUE;CUTYPE=INDIVIDUAL:mailto:b@example.com
4891 COMMENT:Sorry, I cannot change this meeting time
4892 UID:calsrv.example.com-873970198738777@example.com
4894 DTSTAMP:19970614T190000Z
4898 4.2.5. Delegating an Event
4900 When delegating an event request to another "Calendar User", the
4901 "Delegator" must both update the "Organizer" with a "REPLY" and send
4902 a request to the "Delegate". There is currently no protocol
4903 limitation to delegation depth. It is possible for the original
4904 delegate to delegate the meeting to someone else, and so on. When a
4905 request is delegated from one CUA to another, there are a number of
4906 responsibilities required of the "Delegator". The "Delegator" MUST:
4908 o Send a "REPLY" to the "Organizer" with the following updates:
4910 A. The "Delegator's" "ATTENDEE" property "PARTSTAT" parameter is
4911 set to "DELEGATED" and the "DELEGATED-TO" parameter is set to
4912 the address of the "Delegate".
4914 B. Add an additional "ATTENDEE" property for the "Delegate" with
4915 the "DELEGATED-FROM" property parameter set to the
4918 C. Indicate whether they want to continue to receive updates when
4919 the "Organizer" sends out updated versions of the event.
4920 Setting the "RSVP" property parameter to "TRUE" will cause the
4921 updates to be sent; setting it to "FALSE" causes no further
4922 updates to be sent. Note that in either case, if the
4923 "Delegate" declines the invitation, the "Delegator" will be
4930 Daboo Standards Track [Page 88]
4932 RFC 5546 iTIP December 2009
4935 o The "Delegator" MUST also send a copy of the original "REQUEST"
4936 method to the "Delegate", with changes (A) and (B), as detailed
4939 If the "Delegate" declines the meeting, the "Organizer" MUST send an
4940 update "REQUEST" to the "Delegator" so that the "Delegator" may elect
4941 to delegate the "REQUEST" to another CUA.
4943 +----------------+-----------------+--------------------------------+
4944 | Action | "Organizer" | Attendee |
4945 +----------------+-----------------+--------------------------------+
4946 | Initiate a | "A" sends a | |
4947 | meeting | REQUEST message | |
4948 | request | to "B" and "C". | |
4950 | Delegate: "C" | | "C" sends a REPLY to "A" with |
4951 | delegates to | | the ATTENDEE PARTSTAT |
4952 | "E" | | parameter set to DELEGATED and |
4953 | | | with a new ATTENDEE property |
4954 | | | for "E". "E's" ATTENDEE |
4955 | | | DELEGATED-FROM parameter is |
4956 | | | set to "C". "C's" ATTENDEE |
4957 | | | DELEGATED-TO parameter is set |
4958 | | | to "E". "C" sends REQUEST |
4959 | | | message to "E" with the |
4960 | | | original meeting request |
4961 | | | information. The PARTSTAT |
4962 | | | property parameter for "C" is |
4963 | | | set to DELEGATED and the |
4964 | | | DELEGATED-TO parameter is set |
4965 | | | to the address of "E". An |
4966 | | | ATTENDEE property is added for |
4967 | | | "E" and the DELEGATED-FROM |
4968 | | | parameter is set to the |
4969 | | | address of "C". |
4971 | Confirm | | "E" sends REPLY message to |
4972 | meeting | | "A", and optionally to "C", |
4973 | attendance | | with its PARTSTAT property |
4974 | | | parameter set to ACCEPTED. |
4976 | Optional: | "A" sends | |
4977 | Redistribute | REQUEST message | |
4978 | meeting to | to "B", "C", | |
4979 | Attendees | and "E". | |
4980 +----------------+-----------------+--------------------------------+
4986 Daboo Standards Track [Page 89]
4988 RFC 5546 iTIP December 2009
4991 "C" responds to the "Organizer".
4994 PRODID:-//Example/ExampleCalendarClient//EN
4998 ORGANIZER:mailto:a@example.com
4999 ATTENDEE;PARTSTAT=DELEGATED;DELEGATED-
5000 TO="mailto:e@example.com":mailto:c@example.com
5001 UID:calsrv.example.com-873970198738777@example.com
5003 REQUEST-STATUS:2.0;Success
5004 DTSTAMP:19970611T190000Z
5008 "Attendee" "C" delegates presence at the meeting to "E".
5011 PRODID:-//Example/ExampleCalendarClient//EN
5015 ORGANIZER:mailto:a@example.com
5016 ATTENDEE;PARTSTAT=DELEGATED;DELEGATED-
5017 TO="mailto:e@example.com":mailto:c@example.com
5019 DELEGATED-FROM="mailto:c@example.com":mailto:e@example.com
5020 DTSTART:19970701T180000Z
5021 DTEND:19970701T200000Z
5022 SUMMARY:Phone Conference
5023 UID:calsrv.example.com-873970198738777@example.com
5026 DTSTAMP:19970611T190000Z
5030 4.2.6. Delegate Accepts the Meeting
5032 To accept a delegated meeting, the delegate, "E", sends the following
5033 message to "A" and "C".
5036 PRODID:-//Example/ExampleCalendarClient//EN
5042 Daboo Standards Track [Page 90]
5044 RFC 5546 iTIP December 2009
5048 ORGANIZER:mailto:a@example.com
5049 ATTENDEE;PARTSTAT=ACCEPTED;DELEGATED-
5050 FROM="mailto:c@example.com":mailto:e@example.com
5051 ATTENDEE;PARTSTAT=DELEGATED;
5052 DELEGATED-TO="mailto:e@example.com":mailto:c@example.com
5053 UID:calsrv.example.com-873970198738777@example.com
5055 REQUEST-STATUS:2.0;Success
5056 DTSTAMP:19970614T190000Z
5060 4.2.7. Delegate Declines the Meeting
5062 In this example, the "Delegate" declines the meeting request and sets
5063 the "ATTENDEE" property "PARTSTAT" parameter to "DECLINED". The
5064 "Organizer" SHOULD resend the "REQUEST" to "C" with the "PARTSTAT"
5065 parameter of the "Delegate" set to "DECLINED". This lets the
5066 "Delegator" know that the "Delegate" has declined and provides an
5067 opportunity to the "Delegator" to either accept the request or
5068 delegate it to another CU.
5070 "E" responds to "A" and "C". Note the use of the "COMMENT" property
5071 "E" uses to indicate why the delegation was declined.
5074 PRODID:-//Example/ExampleCalendarClient//EN
5078 ORGANIZER:mailto:a@example.com
5079 ATTENDEE;PARTSTAT=DELEGATED;
5080 DELEGATED-TO="mailto:e@example.com":mailto:c@example.com
5081 ATTENDEE;PARTSTAT=DECLINED;
5082 DELEGATED-FROM="mailto:c@example.com":mailto:e@example.com
5083 COMMENT:Sorry, I will be out of town at that time.
5084 UID:calsrv.example.com-873970198738777@example.com
5086 REQUEST-STATUS:2.0;Success
5087 DTSTAMP:19970614T190000Z
5091 "A" resends the "REQUEST" method to "C". "A" may also wish to
5092 express the fact that the item was delegated in the "COMMENT"
5098 Daboo Standards Track [Page 91]
5100 RFC 5546 iTIP December 2009
5104 PRODID:-//Example/ExampleCalendarClient//EN
5108 ORGANIZER:mailto:a@example.com
5109 ATTENDEE;PARTSTAT=DECLINED;
5110 DELEGATED-FROM="mailto:c@example.com":mailto:e@example.com
5111 ATTENDEE;RSVP=TRUE:mailto:c@example.com
5112 UID:calsrv.example.com-873970198738777@example.com
5114 SUMMARY:Phone Conference
5115 DTSTART:19970701T180000Z
5116 DTEND:19970701T200000Z
5117 DTSTAMP:19970614T200000Z
5118 COMMENT:DELEGATE (ATTENDEE mailto:e@example.com) DECLINED YOUR
5123 4.2.8. Forwarding an Event Request
5125 The protocol does not prevent an "Attendee" from "forwarding" a
5126 "VEVENT" calendar component to other "Calendar Users". Forwarding
5127 differs from delegation in that the forwarded "Calendar User" (often
5128 referred to as a "Party Crasher") does not replace the forwarding
5129 "Calendar User". Implementations are not required to add the "Party
5130 Crasher" to the "Attendee" list, and hence there is no guarantee that
5131 a "Party Crasher" will receive additional updates to the event. The
5132 forwarding "Calendar User" SHOULD NOT add the "Party Crasher" to the
5133 "Attendee" list. The "Organizer" MAY add the forwarded "Calendar
5134 User" to the "Attendee" list.
5136 4.2.9. Cancel a Group Event
5138 Individual "A" requests a meeting between individuals "A", "B", "C",
5139 and "D". Individual "B" declines attendance to the meeting.
5140 Individual "A" decides to cancel the meeting. The following table
5141 illustrates the sequence of messages that would be exchanged between
5144 Messages related to a previously canceled event ("SEQUENCE" property
5145 value is less than the "SEQUENCE" property value of the "CANCEL"
5146 message) MUST be ignored.
5154 Daboo Standards Track [Page 92]
5156 RFC 5546 iTIP December 2009
5159 +-------------+---------------------+-------------------------------+
5160 | Action | Organizer | Attendee |
5161 +-------------+---------------------+-------------------------------+
5162 | Initiate a | "A" sends a REQUEST | |
5163 | meeting | message to "B", | |
5164 | request | "C", and "D". | |
5166 | Decline the | | "B" sends a REPLY message to |
5167 | meeting | | "A" with its PARTSTAT |
5168 | request | | parameter set to DECLINED. |
5170 | Cancel the | "A" sends a CANCEL | |
5171 | meeting | message to "B", | |
5172 | | "C", and "D". | |
5173 +-------------+---------------------+-------------------------------+
5175 This example shows how "A" cancels the event.
5178 PRODID:-//Example/ExampleCalendarClient//EN
5182 ORGANIZER:mailto:a@example.com
5183 ATTENDEE;CUTYPE=INDIVIDUAL;mailto:a@example.com
5184 ATTENDEE;CUTYPE=INDIVIDUAL:mailto:b@example.com
5185 ATTENDEE;CUTYPE=INDIVIDUAL:mailto:c@example.com
5186 ATTENDEE;CUTYPE=INDIVIDUAL:mailto:d@example.com
5187 COMMENT:Mr. B cannot attend. It's raining. Lets cancel.
5188 UID:calsrv.example.com-873970198738777@example.com
5191 DTSTAMP:19970613T190000Z
5195 4.2.10. Removing Attendees
5197 "A" wants to remove "B" from a meeting. This is done by sending a
5198 "CANCEL" to "B" and removing "B" from the "Attendee" list in the
5199 master copy of the event.
5210 Daboo Standards Track [Page 93]
5212 RFC 5546 iTIP December 2009
5215 +--------------------+-----------------------------------+----------+
5216 | Action | Organizer | Attendee |
5217 +--------------------+-----------------------------------+----------+
5218 | Remove "B" as an | "A" sends a CANCEL message to | |
5219 | Attendee | "B". | |
5221 | Update the master | "A" optionally sends the updated | |
5222 | copy of the event | event to the remaining Attendees. | |
5223 +--------------------+-----------------------------------+----------+
5225 The original meeting includes "A", "B", "C", and "D". The example
5226 below shows the "CANCEL" that "A" sends to "B". Note that in the
5227 example below, the "STATUS" property is omitted. This is used when
5228 the meeting itself is cancelled and not when the intent is to remove
5229 an "Attendee" from the event.
5232 PRODID:-//Example/ExampleCalendarClient//EN
5236 ORGANIZER:mailto:a@example.com
5237 ATTENDEE:mailto:b@example.com
5238 COMMENT:You're off the hook for this meeting
5239 UID:calsrv.example.com-873970198738777@example.com
5240 DTSTAMP:19970613T193000Z
5245 The updated master copy of the event is shown below. The "Organizer"
5246 MAY resend the updated event to the remaining "Attendees". Note that
5247 "B" has been removed.
5250 PRODID:-//Example/ExampleCalendarClient//EN
5254 ORGANIZER:mailto:a@example.com
5255 ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:mailto:a@example.com
5256 ATTENDEE;CUTYPE=INDIVIDUAL:mailto:c@example.com
5257 ATTENDEE;CUTYPE=INDIVIDUAL:mailto:d@example.com
5258 ATTENDEE;CUTYPE=ROOM:mailto:cr_big@example.com
5259 ATTENDEE;ROLE=NON-PARTICIPANT;
5260 RSVP=FALSE:mailto:e@example.com
5261 DTSTAMP:19970611T190000Z
5262 DTSTART:19970701T200000Z
5266 Daboo Standards Track [Page 94]
5268 RFC 5546 iTIP December 2009
5271 DTEND:19970701T203000Z
5272 SUMMARY:Phone Conference
5273 UID:calsrv.example.com-873970198738777@example.com
5279 4.2.11. Replacing the Organizer
5281 The scenario for this example begins with "A" as the "Organizer" for
5282 a recurring meeting with "B", "C", and "D". "A" receives a new job
5283 offer in another country and drops out of touch. "A" left no
5284 forwarding address or way to be reached. Using out-of-band
5285 communication, the other "Attendees" eventually learn what has
5286 happened and reach an agreement that "B" should become the new
5287 "Organizer" for the meeting. To do this, "B" sends out a new version
5288 of the event and the other "Attendees" agree to accept "B" as the new
5289 "Organizer". "B" also removes "A" from the event.
5291 When the "Organizer" is replaced, the "SEQUENCE" property value MUST
5294 This is the message "B" sends to "C" and "D".
5297 PRODID:-//Example/ExampleCalendarClient//EN
5301 ORGANIZER:mailto:b@example.com
5302 ATTENDEE;ROLE=CHAIR;STATUS=ACCEPTED:mailto:b@example.com
5303 ATTENDEE;CUTYPE=INDIVIDUAL:mailto:c@example.com
5304 ATTENDEE;CUTYPE=INDIVIDUAL:mailto:d@example.com
5305 DTSTAMP:19970611T190000Z
5306 DTSTART:19970701T200000Z
5307 DTEND:19970701T203000Z
5309 SUMMARY:Phone Conference
5310 UID:123456@example.com
5322 Daboo Standards Track [Page 95]
5324 RFC 5546 iTIP December 2009
5327 4.3. Busy Time Examples
5329 Busy time objects can be used in several ways. First, a CU may
5330 request busy time from another CU for a specific range of time. That
5331 request can be answered with a busy time "REPLY". Additionally, a CU
5332 may simply publish their busy time for a given interval and point
5333 other CUs to the published location. The following examples outline
5336 4.3.1. Publish Busy Time
5338 Individual "A" publishes busy time for one week.
5341 PRODID:-//Example/ExampleCalendarClient//EN
5345 DTSTAMP:19980101T124100Z
5346 ORGANIZER:mailto:a@example.com
5347 DTSTART:19980101T124200Z
5348 DTEND:19980108T124200Z
5349 FREEBUSY:19980101T180000Z/19980101T190000Z
5350 FREEBUSY:19980103T020000Z/19980103T050000Z
5351 FREEBUSY:19980107T020000Z/19980107T050000Z
5352 FREEBUSY:19980113T000000Z/19980113T010000Z
5353 FREEBUSY:19980115T190000Z/19980115T200000Z
5354 FREEBUSY:19980115T220000Z/19980115T230000Z
5355 FREEBUSY:19980116T013000Z/19980116T043000Z
5359 4.3.2. Request Busy Time
5361 Individual "A" requests busy time from individuals "B" and "C".
5362 Individuals "B" and "C" reply with busy time data to individual "A".
5363 The following table illustrates the sequence of messages that would
5364 be exchanged between these individuals.
5378 Daboo Standards Track [Page 96]
5380 RFC 5546 iTIP December 2009
5383 +---------------------+--------------------+------------------------+
5384 | Action | Organizer | Attendee |
5385 +---------------------+--------------------+------------------------+
5386 | Initiate a busy | "A" sends REQUEST | |
5387 | time request | message to "B" and | |
5390 | Reply to the BUSY | | "B" sends a REPLY |
5391 | request with BUSY | | message to "A" with |
5392 | time data | | busy time data. |
5393 +---------------------+--------------------+------------------------+
5395 "A" sends a "REQUEST" to "B" and "C" for busy time.
5398 PRODID:-//Example/ExampleCalendarClient//EN
5402 ORGANIZER:mailto:a@example.com
5403 ATTENDEE;ROLE=CHAIR:mailto:a@example.com
5404 ATTENDEE:mailto:b@example.com
5405 ATTENDEE:mailto:c@example.com
5406 DTSTAMP:19970613T190000Z
5407 DTSTART:19970701T080000Z
5408 DTEND:19970701T200000
5409 UID:calsrv.example.com-873970198738777@example.com
5413 4.3.3. Reply to a Busy Time Request
5415 "B" sends a "REPLY" method type of a "VFREEBUSY" calendar component
5419 PRODID:-//Example/ExampleCalendarClient//EN
5423 ORGANIZER:mailto:a@example.com
5424 ATTENDEE:mailto:b@example.com
5425 DTSTART:19970701T080000Z
5426 DTEND:19970701T200000Z
5427 UID:calsrv.example.com-873970198738777@example.com
5428 FREEBUSY:19970701T090000Z/PT1H,19970701T140000Z/PT30M
5429 DTSTAMP:19970613T190030Z
5434 Daboo Standards Track [Page 97]
5436 RFC 5546 iTIP December 2009
5441 "B" is busy from 09:00 to 10:00 and from 14:00 to 14:30.
5443 4.4. Recurring Event and Time Zone Examples
5445 4.4.1. A Recurring Event Spanning Time Zones
5447 This event describes a weekly phone conference. The "Attendees" are
5448 each in a different time zone.
5451 PRODID:-//Example/ExampleCalendarClient//EN
5455 TZID:America-SanJose
5456 TZURL:http://example.com/tz/America-SanJose
5458 DTSTART:19671029T020000
5459 RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=10
5465 DTSTART:19870405T020000
5466 RRULE:FREQ=YEARLY;BYDAY=1SU;BYMONTH=4
5473 ORGANIZER:mailto:a@example.com
5474 ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED;
5475 CUTYPE=INDIVIDUAL:a@example.com
5476 ATTENDEE;RSVP=TRUE;CUTYPE=INDIVIDUAL:b@example.fr
5477 ATTENDEE;RSVP=TRUE;CUTYPE=INDIVIDUAL:c@example.jp
5478 DTSTAMP:19970613T190030Z
5479 DTSTART;TZID=America-SanJose:19970701T140000
5480 DTEND;TZID=America-SanJose:19970701T150000
5481 RRULE:FREQ=WEEKLY;COUNT=20;WKST=SU;BYDAY=TU
5482 RDATE;TZID=America-SanJose:19970910T140000
5483 EXDATE;TZID=America-SanJose:19970909T140000
5484 EXDATE;TZID=America-SanJose:19971028T140000
5485 SUMMARY:Weekly Phone Conference
5486 UID:calsrv.example.com-873970198738777@example.com
5490 Daboo Standards Track [Page 98]
5492 RFC 5546 iTIP December 2009
5500 The first component of this iCalendar object is the time zone
5501 component. The "DTSTART" date coincides with the first instance of
5502 the "RRULE" property.
5504 The recurring meeting is defined in a particular time zone,
5505 presumably that of the originator. The client for each "Attendee"
5506 has the responsibility of determining the recurrence time in the
5507 "Attendee's" time zone.
5509 The repeating event starts on Tuesday, July 1, 1997 at 2:00pm PDT
5510 (UTC-7). "Attendee" B@example.fr is in France, where the local time
5511 on this date is 9 hours ahead of PDT, or 23:00 CEST (UTC+2).
5512 "Attendee" C@example.jp is in Japan, where local time is 16 hours
5513 ahead of PDT, or Wednesday, July 2 at 06:00 JST (UTC+9). The event
5514 repeats weekly on Tuesdays (in PST/PDT). The "RRULE" property
5515 results in 20 instances. The last instance falls on Tuesday,
5516 November 11, 1997 2:00pm PST. The "RDATE" property adds another
5517 instance: WED, 10-SEP-1997 2:00 PM PDT.
5519 There are also two exception dates to the recurrence rule. The first
5522 o TUE, 09-SEP-1997 14:00 PDT (UTC-7)
5524 o TUE, 09-SEP-1997 23:00 CEST (UTC+2)
5526 o WED, 10-SEP-1997 06:00 JST (UTC+9)
5531 o TUE, 28-OCT-1997 14:00 PST (UTC-8)
5533 o TUE, 28-OCT-1997 23:00 CET (UTC+1)
5535 o WED, 29-OCT-1997 07:00 JST (UTC+9)
5537 4.4.2. Modify a Recurring Instance
5539 In this example, the "Organizer" issues a recurring meeting. Later,
5540 the "Organizer" changes an instance of the event by changing the
5541 "DTSTART" property. Note the use of "RECURRENCE-ID" property and
5542 "SEQUENCE" property in the second request.
5546 Daboo Standards Track [Page 99]
5548 RFC 5546 iTIP December 2009
5555 PRODID:-//Example/ExampleCalendarClient//EN
5558 UID:guid-1@example.com
5560 RRULE:FREQ=MONTHLY;BYMONTHDAY=1;UNTIL=19980901T210000Z
5561 ORGANIZER:mailto:a@example.com
5562 ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:mailto:a@example.com
5563 ATTENDEE:mailto:b@example.com
5564 ATTENDEE:mailto:c@example.com
5565 ATTENDEE:mailto:d@example.com
5566 DESCRIPTION:IETF-C&S Conference Call
5568 SUMMARY:IETF Calendaring Working Group Meeting
5569 DTSTART:19970601T210000Z
5570 DTEND:19970601T220000Z
5571 LOCATION:Conference Call
5572 DTSTAMP:19970526T083000Z
5577 The event request below is to change the time of a specific instance.
5578 This changes the July 1st instance to July 3rd.
5582 PRODID:-//Example/ExampleCalendarClient//EN
5585 UID:guid-1@example.com
5586 RECURRENCE-ID:19970701T210000Z
5588 ORGANIZER:mailto:a@example.com
5589 ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:mailto:a@example.com
5590 ATTENDEE:mailto:b@example.com
5591 ATTENDEE:mailto:c@example.com
5592 ATTENDEE:mailto:d@example.com
5593 DESCRIPTION:IETF-C&S Conference Call
5595 SUMMARY:IETF Calendaring Working Group Meeting
5596 DTSTART:19970703T210000Z
5597 DTEND:19970703T220000Z
5598 LOCATION:Conference Call
5602 Daboo Standards Track [Page 100]
5604 RFC 5546 iTIP December 2009
5607 DTSTAMP:19970626T093000Z
5612 4.4.3. Cancel an Instance
5614 In this example, the "Organizer" of a recurring event deletes the
5615 August 1st instance.
5619 PRODID:-//Example/ExampleCalendarClient//EN
5622 UID:guid-1@example.com
5623 ORGANIZER:mailto:a@example.com
5624 ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:mailto:a@example.com
5625 ATTENDEE:mailto:b@example.com
5626 ATTENDEE:mailto:c@example.com
5627 ATTENDEE:mailto:d@example.com
5628 RECURRENCE-ID:19970801T210000Z
5631 DTSTAMP:19970721T093000Z
5635 4.4.4. Cancel a Recurring Event
5637 In this example, the "Organizer" wishes to cancel the entire
5638 recurring event and any exceptions.
5642 PRODID:-//Example/ExampleCalendarClient//EN
5645 UID:guid-1@example.com
5646 ORGANIZER:mailto:a@example.com
5647 ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:mailto:a@example.com
5648 ATTENDEE:mailto:b@example.com
5649 ATTENDEE:mailto:c@example.com
5650 ATTENDEE:mailto:d@example.com
5651 DTSTAMP:19970721T103000Z
5658 Daboo Standards Track [Page 101]
5660 RFC 5546 iTIP December 2009
5665 4.4.5. Change All Future Instances
5667 This example changes the meeting location from a conference call to
5668 Seattle, starting September 1 and extending to all future instances.
5672 PRODID:-//Example/ExampleCalendarClient//EN
5675 UID:guid-1@example.com
5676 RECURRENCE-ID;THISANDFUTURE:19970901T210000Z
5678 ORGANIZER:mailto:a@example.com
5679 ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:mailto:a@example.com
5680 ATTENDEE;RSVP=TRUE:mailto:b@example.com
5681 ATTENDEE;RSVP=TRUE:mailto:c@example.com
5682 ATTENDEE;RSVP=TRUE:mailto:d@example.com
5683 DESCRIPTION:IETF-C&S Discussion
5685 SUMMARY:IETF Calendaring Working Group Meeting
5686 DTSTART:19970901T210000Z
5687 DTEND:19970901T220000Z
5688 LOCATION:Building 32, Microsoft, Seattle, WA
5689 DTSTAMP:19970526T083000Z
5694 4.4.6. Add a New Instance to a Recurring Event
5696 This example adds a one-time additional instance to the recurring
5697 event. "Organizer" adds a second July meeting on the 15th.
5701 PRODID:-//Example/ExampleCalendarClient//EN
5704 UID:123456789@example.com
5706 ORGANIZER:mailto:a@example.com
5707 ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:mailto:a@example.com
5708 ATTENDEE;RSVP=TRUE:mailto:b@example.com
5709 ATTENDEE;RSVP=TRUE:mailto:c@example.com
5710 ATTENDEE;RSVP=TRUE:mailto:d@example.com
5714 Daboo Standards Track [Page 102]
5716 RFC 5546 iTIP December 2009
5719 DESCRIPTION:IETF-C&S Conference Call
5721 SUMMARY:IETF Calendaring Working Group Meeting
5722 DTSTART:19970715T210000Z
5723 DTEND:19970715T220000Z
5724 LOCATION:Conference Call
5725 DTSTAMP:19970629T093000Z
5730 4.4.7. Add a New Series of Instances to a Recurring Event
5732 The scenario for this example involves an ongoing meeting, originally
5733 set up to occur every Tuesday. The "Organizer" later decides that
5734 the meetings need to be on Tuesdays and Thursdays.
5740 PRODID:-//Example/ExampleCalendarClient//EN
5743 UID:123456789@example.com
5745 RRULE:WKST=SU;BYDAY=TU;FREQ=WEEKLY
5746 ORGANIZER:mailto:a@example.com
5747 ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:mailto:a@example.com
5748 ATTENDEE;RSVP=TRUE:mailto:b@example.com
5749 SUMMARY:Review Accounts
5750 DTSTART:19980303T210000Z
5751 DTEND:19980303T220000Z
5752 LOCATION:The White Room
5753 DTSTAMP:19980301T093000Z
5758 The entire event can be rescheduled using a "REQUEST". This is done
5759 by using the "UID" of the event to reschedule and including the
5760 modified "RRULE". Note that since this is an entire rescheduling of
5761 the event, any instance-specific information will be lost, unless
5762 explicitly included with the update "REQUEST".
5766 PRODID:-//Example/ExampleCalendarClient//EN
5770 Daboo Standards Track [Page 103]
5772 RFC 5546 iTIP December 2009
5777 UID:123456789@example.com
5779 RRULE:WKST=SU;BYDAY=TU,TH;FREQ=WEEKLY
5780 ORGANIZER:mailto:a@example.com
5781 ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:mailto:a@example.com
5782 ATTENDEE;RSVP=TRUE:mailto:b@example.com
5783 SUMMARY:Review Accounts
5784 DTSTART:19980303T210000Z
5785 DTEND:19980303T220000Z
5786 DTSTAMP:19980303T193000Z
5787 LOCATION:The White Room
5792 4.4.8. Refreshing a Recurring Event
5794 The next series of examples illustrate how an "Organizer" would
5795 respond to a "REFRESH" submitted by an "Attendee" after a series of
5796 instance-specific modifications. To convey all instance-specific
5797 changes, the "Organizer" must provide the latest event description
5798 and the relevant instances. The first three examples show the
5799 history, including the initial "VEVENT" request and subsequent
5800 instance changes, and finally the "REFRESH".
5806 PRODID:-//Example/ExampleCalendarClient//EN
5809 UID:123456789@example.com
5811 RDATE:19980304T180000Z
5812 RDATE:19980311T180000Z
5813 RDATE:19980318T180000Z
5814 ORGANIZER:mailto:a@example.com
5815 ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:mailto:a@example.com
5816 ATTENDEE;RSVP=TRUE:mailto:b@example.com
5817 SUMMARY:Review Accounts
5818 DTSTART:19980304T180000Z
5819 DTEND:19980304T200000Z
5820 DTSTAMP:19980303T193000Z
5821 LOCATION:Conference Room A
5826 Daboo Standards Track [Page 104]
5828 RFC 5546 iTIP December 2009
5834 Organizer changes 2nd instance location and time:
5838 PRODID:-//Example/ExampleCalendarClient//EN
5841 UID:123456789@example.com
5843 RECURRENCE-ID:19980311T180000Z
5844 ORGANIZER:mailto:a@example.com
5845 ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:mailto:a@example.com
5846 ATTENDEE;RSVP=TRUE:mailto:b@example.com
5847 SUMMARY:Review Accounts
5848 DTSTART:19980311T160000Z
5849 DTEND:19980311T180000Z
5850 DTSTAMP:19980306T193000Z
5851 LOCATION:The Small conference room
5856 Organizer adds a 4th instance of the meeting using the "ADD" method.
5860 PRODID:-//Example/ExampleCalendarClient//EN
5863 UID:123456789@example.com
5865 ORGANIZER:mailto:a@example.com
5866 ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:mailto:a@example.com
5867 ATTENDEE;RSVP=TRUE:mailto:b@example.com
5868 SUMMARY:Review Accounts
5869 DTSTART:19980315T180000Z
5870 DTEND:19980315T200000Z
5871 DTSTAMP:19980307T193000Z
5872 LOCATION:Conference Room A
5882 Daboo Standards Track [Page 105]
5884 RFC 5546 iTIP December 2009
5887 If "B" requests a "REFRESH", "A" responds with the following to
5888 capture all instance-specific data. In this case, both the initial
5889 request and an additional "VEVENT" that specifies the instance-
5890 specific data are included. Because these are both of the same type
5891 (they are both "VEVENTS"), they can be conveyed in the same iCalendar
5896 PRODID:-//Example/ExampleCalendarClient//EN
5899 UID:123456789@example.com
5901 RDATE:19980304T180000Z
5902 RDATE:19980311T160000Z
5903 RDATE:19980315T180000Z
5904 ORGANIZER:mailto:a@example.com
5905 ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:mailto:a@example.com
5906 ATTENDEE;RSVP=TRUE:mailto:b@example.com
5907 SUMMARY:Review Accounts
5908 DTSTART:19980304T180000Z
5909 DTEND:19980304T200000Z
5910 DTSTAMP:19980303T193000Z
5911 LOCATION:Conference Room A
5916 UID:123456789@example.com
5917 RECURRENCE-ID:19980311T160000Z
5918 ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:mailto:a@example.com
5919 ATTENDEE;RSVP=TRUE:mailto:b@example.com
5920 SUMMARY:Review Accounts
5921 DTSTART:19980311T160000Z
5922 DTEND:19980304T180000Z
5923 DTSTAMP:19980306T193000Z
5924 LOCATION:The Small conference room
5929 4.4.9. Counter an Instance of a Recurring Event
5931 In this example, one of the "Attendees" counters the "DTSTART"
5932 property of the proposed second July meeting.
5938 Daboo Standards Track [Page 106]
5940 RFC 5546 iTIP December 2009
5945 PRODID:-//Example/ExampleCalendarClient//EN
5948 UID:guid-1@example.com
5949 RECURRENCE-ID:19970715T210000Z
5951 ORGANIZER:mailto:a@example.com
5952 ATTENDEE;ROLE=CHAIR;RSVP=TRUE:mailto:a@example.com
5953 ATTENDEE;RSVP=TRUE:mailto:b@example.com
5954 ATTENDEE;RSVP=TRUE:mailto:c@example.com
5955 ATTENDEE;RSVP=TRUE:mailto:d@example.com
5956 DESCRIPTION:IETF-C&S Conference Call
5958 SUMMARY:IETF Calendaring Working Group Meeting
5959 DTSTART:19970715T220000Z
5960 DTEND:19970715T230000Z
5961 LOCATION:Conference Call
5962 COMMENT:May we bump this by an hour? I have a conflict
5963 DTSTAMP:19970629T094000Z
5967 4.4.10. Error Reply to a Request
5969 The following example illustrates a scenario where a meeting is
5970 proposed containing an unsupported property and a bad property.
5976 PRODID:-//Example/ExampleCalendarClient//EN
5979 UID:guid-1@example.com
5981 RRULE:FREQ=MONTHLY;BYMONTHDAY=1
5982 ORGANIZER:mailto:a@example.com
5983 ATTENDEE;ROLE=CHAIR:mailto:a@example.com
5984 ATTENDEE;RSVP=TRUE:mailto:b@example.com
5985 ATTENDEE;RSVP=TRUE:mailto:c@example.com
5986 ATTENDEE;RSVP=TRUE:mailto:d@example.com
5987 DESCRIPTION:IETF-C&S Conference Call
5989 SUMMARY:IETF Calendaring Working Group Meeting
5990 DTSTART:19970601T210000Z
5994 Daboo Standards Track [Page 107]
5996 RFC 5546 iTIP December 2009
5999 DTEND:19970601T220000Z
6000 DTSTAMP:19970602T094000Z
6001 LOCATION:Conference Call
6007 "B" responds to indicate that "RRULE" is not supported and that an
6008 unrecognized property was encountered.
6011 PRODID:-//Example/ExampleCalendarClient//EN
6015 ORGANIZER:mailto:a@example.com
6016 ATTENDEE:mailto:b@example.com
6017 REQUEST-STATUS:3.0;Invalid Property Name;FOO
6018 UID:guid-1@example.com
6020 DTSTAMP:19970603T094000Z
6024 4.5. Group To-Do Examples
6026 Individual "A" creates a group task in which individuals "A", "B",
6027 "C", and "D" will participate. Individual "B" confirms acceptance of
6028 the task. Individual "C" declines the task. Individual "D"
6029 tentatively accepts the task. The following table illustrates the
6030 sequence of messages that would be exchanged between these
6031 individuals. Individual "A" then issues a "REQUEST" method to obtain
6032 the status of the to-do from each participant. The response
6033 indicates the individual "Attendee's" completion status. The table
6034 below illustrates the message flow.
6050 Daboo Standards Track [Page 108]
6052 RFC 5546 iTIP December 2009
6055 +--------------+------------------------+---------------------------+
6056 | Action | Organizer | Attendee |
6057 +--------------+------------------------+---------------------------+
6058 | Initiate a | "A" sends a REQUEST | |
6059 | to-do | message to "B", "C", | |
6060 | request | and "D". | |
6062 | Accept the | | "B" sends a REPLY message |
6063 | to-do | | to "A" with its PARTSTAT |
6064 | request | | parameter set to |
6067 | Decline the | | "C" sends a REPLY message |
6068 | to-do | | to "A" with its PARTSTAT |
6069 | request | | parameter set to |
6072 | Tentatively | | "D" sends a REPLY message |
6073 | accept the | | to "A" with its PARTSTAT |
6074 | to-do | | parameter set to |
6075 | request | | TENTATIVE. |
6077 | Check | "A" sends a REQUEST | |
6078 | Attendee | message to "B" and "D" | |
6079 | completion | with current | |
6080 | status | information. | |
6082 | Attendee | | "B" sends a REPLY message |
6083 | indicates | | indicating percent |
6084 | percent | | complete. |
6087 | Attendee | | "D" sends a REPLY message |
6088 | indicates | | indicating completion. |
6090 +--------------+------------------------+---------------------------+
6092 4.5.1. A VTODO Request
6094 A sample "REQUEST" for a "VTODO" calendar component that "A" sends to
6098 PRODID:-//Example/ExampleCalendarClient//EN
6102 ORGANIZER:mailto:a@example.com
6106 Daboo Standards Track [Page 109]
6108 RFC 5546 iTIP December 2009
6111 ATTENDEE;ROLE=CHAIR:mailto:a@example.com
6112 ATTENDEE;RSVP=TRUE:mailto:b@example.com
6113 ATTENDEE;RSVP=TRUE:mailto:c@example.com
6114 ATTENDEE;RSVP=TRUE:mailto:d@example.com
6115 DTSTART:19970701T170000Z
6116 DUE:19970722T170000Z
6118 SUMMARY:Create the requirements document
6119 UID:calsrv.example.com-873970198738777-00@example.com
6121 DTSTAMP:19970717T200000Z
6126 4.5.2. A VTODO Reply
6128 "B" accepts the to-do.
6131 PRODID:-//Example/ExampleCalendarClient//EN
6135 ORGANIZER:mailto:a@example.com
6136 ATTENDEE;PARTSTAT=ACCEPTED:mailto:b@example.com
6137 UID:calsrv.example.com-873970198738777-00@example.com
6138 COMMENT:I'll send you my input by email
6140 DTSTAMP:19970717T203000Z
6141 REQUEST-STATUS:2.0;Success
6145 "B" could have declined the "VTODO" or indicated tentative acceptance
6146 by setting the "PARTSTAT" property parameter sequence to "DECLINED"
6147 or "TENTATIVE", respectively.
6149 4.5.3. A VTODO Request for Updated Status
6151 "A" requests status from all "Attendees".
6154 PRODID:-//Example/ExampleCalendarClient//EN
6158 ORGANIZER:mailto:a@example.com
6162 Daboo Standards Track [Page 110]
6164 RFC 5546 iTIP December 2009
6167 ATTENDEE;ROLE=CHAIR:mailto:a@example.com
6168 ATTENDEE;RSVP=TRUE;CUTYPE=INDIVIDUAL:mailto:b@example.com
6169 ATTENDEE;RSVP=TRUE;CUTYPE=INDIVIDUAL:mailto:d@example.com
6170 UID:calsrv.example.com-873970198738777-00@example.com
6171 SUMMARY:Create the requirements document
6175 DTSTART:19970701T170000Z
6176 DTSTAMP:19970717T230000Z
6180 4.5.4. A Reply: Percent-Complete
6182 A reply indicating the task being worked on and that "B" is 75%
6183 complete with "B's" part of the assignment.
6186 PRODID:-//Example/ExampleCalendarClient//EN
6190 ORGANIZER:mailto:a@example.com
6191 ATTENDEE;PARTSTAT=IN-PROCESS:mailto:b@example.com
6193 UID:calsrv.example.com-873970198738777-00@example.com
6194 DTSTAMP:19970717T233000Z
6199 4.5.5. A Reply: Completed
6201 A reply indicating that "D" completed "D's" part of the assignment.
6204 PRODID:-//Example/ExampleCalendarClient//EN
6208 ORGANIZER:mailto:a@example.com
6209 ATTENDEE;PARTSTAT=COMPLETED:mailto:d@example.com
6210 UID:calsrv.example.com-873970198738777-00@example.com
6211 DTSTAMP:19970717T233000Z
6218 Daboo Standards Track [Page 111]
6220 RFC 5546 iTIP December 2009
6223 4.5.6. An Updated VTODO Request
6225 "Organizer" "A" resends the "VTODO" calendar component. "A" sets the
6226 overall completion for the to-do at 40%.
6229 PRODID:-//Example/ExampleCalendarClient//EN
6233 ORGANIZER:mailto:a@example.com
6234 ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:mailto:a@example.com
6235 ATTENDEE;PARTSTAT=ACCEPTED;CUTYPE=INDIVIDUAL:mailto:b@example.com
6236 ATTENDEE;PARTSTAT=COMPLETED;CUTYPE=INDIVIDUAL:mailto:d@example.com
6237 DTSTART:19970701T170000Z
6238 DUE:19970722T170000Z
6240 SUMMARY:Create the requirements document
6241 UID:calsrv.example.com-873970198738777-00@example.com
6243 DTSTAMP:19970718T100000Z
6249 4.5.7. Recurring VTODOs
6251 The following examples relate to recurring "VTODO" calendar
6254 4.5.7.1. Request for a Recurring VTODO
6256 In this example, "A" sends a recurring "VTODO" calendar component to
6260 PRODID:-//Example/ExampleCalendarClient//EN
6264 ORGANIZER:mailto:a@example.com
6265 ATTENDEE;ROLE=CHAIR:mailto:a@example.com
6266 ATTENDEE;RSVP=TRUE;CUTYPE=INDIVIDUAL:mailto:b@example.com
6267 ATTENDEE;RSVP=TRUE;CUTYPE=INDIVIDUAL:mailto:d@example.com
6268 RRULE:FREQ=MONTHLY;COUNT=10;BYDAY=1FR
6269 DTSTART:19980101T100000Z
6270 DUE:19980103T100000Z
6274 Daboo Standards Track [Page 112]
6276 RFC 5546 iTIP December 2009
6279 SUMMARY:Send Status Reports to Area Managers
6280 UID:calsrv.example.com-873970198738777-00@example.com
6282 DTSTAMP:19970717T200000Z
6288 4.5.7.2. Replying to an Instance of a Recurring VTODO
6290 In this example, "B" updates "A" on a single instance of the "VTODO"
6294 PRODID:-//Example/ExampleCalendarClient//EN
6298 ATTENDEE;PARTSTAT=IN-PROCESS:mailto:b@example.com
6300 UID:calsrv.example.com-873970198738777-00@example.com
6301 DTSTAMP:19970717T233000Z
6302 RECURRENCE-ID:19980101T170000Z
6307 4.6. Journal Examples
6309 The iCalendar object below describes a single journal entry for
6310 October 2, 1997. The "RELATED-TO" property references the phone
6311 conference event for which minutes were taken.
6315 PRODID:-//Example/ExampleCalendarClient//EN
6318 DTSTART:19971002T200000Z
6319 DTSTAMP:19970717T233100Z
6320 ORGANIZER:mailto:a@example.com
6321 SUMMARY:Phone conference minutes
6322 DESCRIPTION:The editors meeting was held on October 1, 1997.
6323 Details are in the attached document.
6324 UID:0981234-1234234-2410@example.com
6325 RELATED-TO:0981234-1234234-2402-35@example.com
6326 ATTACH:ftp://ftp.example.com/pub/ed/minutes100197.txt
6330 Daboo Standards Track [Page 113]
6332 RFC 5546 iTIP December 2009
6340 4.7.1. Event Refresh
6342 Refresh the event with a "UID" property value of
6343 "guid-1-12345@example.com":
6346 PRODID:-//Example/ExampleCalendarClient//EN
6350 ORGANIZER:mailto:a@example.com
6351 ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:mailto:a@example.com
6352 ATTENDEE:mailto:b@example.com
6353 ATTENDEE:mailto:c@example.com
6354 ATTENDEE:mailto:d@example.com
6355 UID:guid-1-12345@example.com
6356 DTSTAMP:19970603T094000
6360 4.7.2. Bad RECURRENCE-ID
6362 Component instances are identified by the combination of "UID",
6363 "RECURRENCE-ID", and "SEQUENCE". When an "Organizer" sends an iTIP
6364 message to an "Attendee", there are three cases in which an instance
6365 cannot be found. They are:
6367 1. The component with the referenced "UID" and "RECURRENCE-ID" has
6368 been found but the "SEQUENCE" number in the calendar store does
6369 not match that of the iTIP message.
6371 2. The component with the referenced "UID" has been found, the
6372 "SEQUENCE" numbers match, but the "RECURRENCE-ID" cannot be
6375 3. The "UID" and "SEQUENCE" numbers are found but the CUA does not
6376 support recurrences.
6378 In case (1), two things can happen. If the "SEQUENCE" number of the
6379 "Attendee's" instance is larger than that in the "Organizer's"
6380 message, then the "Attendee" is receiving an out-of-sequence message
6381 and MUST ignore it. If the "SEQUENCE" number of the "Attendee's"
6382 instance is smaller, then the "Organizer" is sending out a newer
6386 Daboo Standards Track [Page 114]
6388 RFC 5546 iTIP December 2009
6391 version of the component and the "Attendee's" version needs to be
6392 updated. Since one or more updates have been missed, the "Attendee"
6393 SHOULD send a "REFRESH" message to the "Organizer" to get an updated
6394 version of the event.
6396 In case (2), something has gone wrong. Both the "Organizer" and the
6397 "Attendee" should have the same instances, but the "Attendee" does
6398 not have the referenced instance. In this case, the "Attendee"
6399 SHOULD send a "REFRESH" to the "Organizer" to get an updated version
6402 In case (3), the limitations of the "Attendee's" CUA makes it
6403 impossible to match an instance other than the single instance
6404 scheduled. In this case, the "Attendee" need not send a "REFRESH" to
6407 The example below shows a sequence in which an "Attendee" sends a
6408 "REFRESH" to the "Organizer".
6410 +-------------------------+--------------------+--------------------+
6411 | Action | Organizer | Attendee |
6412 +-------------------------+--------------------+--------------------+
6413 | Update an instance | "A" sends REQUEST | |
6414 | request | message to "B". | |
6416 | Attendee requests | | "B" sends a |
6417 | refresh because | | REFRESH message to |
6418 | RECURRENCE-ID was not | | "A". |
6421 | Refresh the entire | "A" sends the | |
6422 | event | latest copy of the | |
6423 | | event to "B" | |
6425 | Attendee handles the | | "B" updates to the |
6426 | request and updates the | | latest copy of the |
6427 | instance | | meeting. |
6428 +-------------------------+--------------------+--------------------+
6434 PRODID:-//Example/ExampleCalendarClient//EN
6437 UID:example-12345@example.com
6442 Daboo Standards Track [Page 115]
6444 RFC 5546 iTIP December 2009
6448 RDATE;VALUE=PERIOD:19970819T210000Z/199700819T220000Z
6449 ORGANIZER:mailto:a@example.com
6450 ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:mailto:a@example.com
6451 ATTENDEE:mailto:b@example.com
6452 DESCRIPTION:IETF-C&S Conference Call
6453 SUMMARY:IETF Calendaring Working Group Meeting
6454 DTSTART:19970801T210000Z
6455 DTEND:19970801T220000Z
6456 RECURRENCE-ID:19970809T210000Z
6457 DTSTAMP:19970726T083000
6462 "B" has the event with "UID" property "example-12345@example.com",
6463 but "B's" "SEQUENCE" property value is "1" and the event does not
6464 have an instance at the specified recurrence time. This means that
6465 "B" has missed at least one update and needs a new copy of the event.
6466 "B" requests the latest copy of the event with the following refresh
6470 PRODID:-//Example/ExampleCalendarClient//EN
6474 ORGANIZER:mailto:a@example.com
6475 ATTENDEE:mailto:b@example.com
6476 UID:example-12345@example.com
6477 DTSTAMP:19970603T094000
6481 5. Application Protocol Fallbacks
6483 5.1. Partial Implementation
6485 Applications that support this specification are not required to
6486 support the entire protocol. The following describes how methods and
6487 properties SHOULD "fallback" in applications that do not support the
6488 complete protocol. If a method or property is not addressed in this
6489 section, it may be ignored.
6498 Daboo Standards Track [Page 116]
6500 RFC 5546 iTIP December 2009
6503 5.1.1. Event-Related Fallbacks
6505 +----------------+--------------------------------------------------+
6506 | Method | Fallback |
6507 +----------------+--------------------------------------------------+
6508 | PUBLISH | Required |
6509 | REQUEST | PUBLISH |
6510 | REPLY | Required |
6511 | ADD | Required if recurrences supported; otherwise, |
6512 | | reply with a REQUEST-STATUS "2.8; Success, |
6513 | | repeating event ignored. Scheduled as a single |
6514 | | component", and schedule as a single component. |
6515 | CANCEL | Required |
6516 | REFRESH | Required |
6517 | COUNTER | Reply with "Not Supported". |
6518 | DECLINECOUNTER | Required if COUNTER is implemented for VEVENTs; |
6519 | | otherwise, reply with "Not Supported". |
6520 +----------------+--------------------------------------------------+
6522 +-----------------+-------------------------------------------------+
6523 | iCalendar | Fallback |
6525 +-----------------+-------------------------------------------------+
6526 | CALSCALE | Ignore - assume GREGORIAN. |
6528 | METHOD | Required as described in the Method list above. |
6529 | VERSION | Ignore |
6530 +-----------------+-------------------------------------------------+
6532 +-----------------+-------------------------------------------------+
6533 | Event-Related | Fallback |
6535 +-----------------+-------------------------------------------------+
6536 | VALARM | Reply with "Not Supported". |
6537 | VTIMEZONE | Required if any DateTime value refers to a time |
6539 +-----------------+-------------------------------------------------+
6554 Daboo Standards Track [Page 117]
6556 RFC 5546 iTIP December 2009
6559 +-----------------+-------------------------------------------------+
6560 | Component | Fallback |
6562 +-----------------+-------------------------------------------------+
6564 | ATTENDEE | Required if METHOD is REQUEST; otherwise, |
6566 | CATEGORIES | Ignore |
6568 | COMMENT | Ignore |
6569 | COMPLETED | Ignore |
6570 | CONTACT | Ignore |
6571 | CREATED | Ignore |
6572 | DESCRIPTION | Ignore |
6573 | DURATION | Required |
6574 | DTSTAMP | Required |
6575 | DTSTART | Required |
6576 | DTEND | Required |
6579 | LAST-MODIFIED | Ignore |
6580 | LOCATION | Required |
6581 | ORGANIZER | Required if METHOD is REQUEST; otherwise, |
6583 | PRIORITY | Ignore |
6584 | RELATED-TO | Ignore |
6586 | RRULE | Ignore - assume the first instance occurs on |
6587 | | the DTSTART property. If implemented, |
6588 | | VTIMEZONE MUST also be implemented. |
6589 | RECURRENCE-ID | Required if RRULE is implemented; otherwise, |
6591 | REQUEST-STATUS | Required |
6592 | RESOURCES | Ignore |
6593 | SEQUENCE | Required |
6595 | SUMMARY | Ignore |
6596 | TRANSP | Required if FREEBUSY is implemented; otherwise, |
6601 +-----------------+-------------------------------------------------+
6610 Daboo Standards Track [Page 118]
6612 RFC 5546 iTIP December 2009
6615 5.1.2. Free/Busy-Related Fallbacks
6617 +---------+---------------------------------------------------------+
6618 | Method | Fallback |
6619 +---------+---------------------------------------------------------+
6620 | PUBLISH | Required if freebusy lookups are supported; otherwise, |
6621 | | reply with a REQUEST-STATUS "3.14; Unsupported |
6623 | REQUEST | Required if freebusy lookups are supported; otherwise, |
6624 | | reply with a REQUEST-STATUS "3.14; Unsupported |
6626 | REPLY | Required if freebusy lookups are supported; otherwise, |
6627 | | reply with a REQUEST-STATUS "3.14; Unsupported |
6629 +---------+---------------------------------------------------------+
6631 +-----------------+-------------------------------------------------+
6632 | iCalendar | Fallback |
6634 +-----------------+-------------------------------------------------+
6635 | CALSCALE | Ignore - assume GREGORIAN. |
6637 | METHOD | Required as described in the Method list above. |
6638 | VERSION | Ignore |
6639 +-----------------+-------------------------------------------------+
6641 +-----------------+-------------------------------------------------+
6642 | Component | Fallback |
6644 +-----------------+-------------------------------------------------+
6645 | ATTENDEE | Required if METHOD is REQUEST; otherwise, |
6647 | COMMENT | Ignore |
6648 | CONTACT | Ignore |
6649 | DTEND | Required |
6650 | DTSTAMP | Required |
6651 | DTSTART | Required |
6652 | DURATION | Ignore |
6653 | FREEBUSY | Required |
6654 | ORGANIZER | Required if METHOD is REQUEST; otherwise, |
6656 | REQUEST-STATUS | Ignore |
6660 +-----------------+-------------------------------------------------+
6666 Daboo Standards Track [Page 119]
6668 RFC 5546 iTIP December 2009
6671 5.1.3. To-Do-Related Fallbacks
6673 +----------------+--------------------------------------------------+
6674 | Method | Fallback |
6675 +----------------+--------------------------------------------------+
6676 | PUBLISH | Required |
6677 | REQUEST | PUBLISH |
6678 | REPLY | Required |
6679 | ADD | Required if recurrences supported; otherwise, |
6680 | | reply with a REQUEST-STATUS "2.8; Success, |
6681 | | repeating event ignored. Scheduled as a single |
6682 | | component", and schedule as a single component. |
6683 | CANCEL | Required |
6684 | REFRESH | Required |
6685 | COUNTER | Reply with "Not Supported". |
6686 | DECLINECOUNTER | Required if COUNTER for VTODOs is implemented; |
6687 | | otherwise, reply with "Not Supported". |
6688 +----------------+--------------------------------------------------+
6690 +-----------------+-------------------------------------------------+
6691 | iCalendar | Fallback |
6693 +-----------------+-------------------------------------------------+
6694 | CALSCALE | Ignore - assume GREGORIAN. |
6696 | METHOD | Required as described in the Method list above. |
6697 | VERSION | Ignore |
6698 +-----------------+-------------------------------------------------+
6700 +-----------------+-------------------------------------------------+
6701 | To-Do-Related | Fallback |
6703 +-----------------+-------------------------------------------------+
6704 | VALARM | Reply with "Not Supported". |
6705 | VTIMEZONE | Required if any DateTime value refers to a time |
6707 +-----------------+-------------------------------------------------+
6722 Daboo Standards Track [Page 120]
6724 RFC 5546 iTIP December 2009
6727 +------------------+------------------------------------------------+
6728 | Component | Fallback |
6730 +------------------+------------------------------------------------+
6732 | ATTENDEE | Required if METHOD is REQUEST; otherwise, |
6734 | CATEGORIES | Ignore |
6736 | COMMENT | Ignore |
6737 | COMPLETED | Required |
6738 | CONTACT | Ignore |
6739 | CREATED | Ignore |
6740 | DESCRIPTION | Required if METHOD is REQUEST; otherwise, |
6743 | DURATION | Required |
6744 | DTSTAMP | Required |
6745 | DTSTART | Required |
6746 | EXDATE | Ignore - reply with "Not Supported". |
6747 | LAST-MODIFIED | Ignore |
6748 | LOCATION | Ignore |
6749 | ORGANIZER | Required if METHOD is REQUEST; otherwise, |
6751 | PERCENT-COMPLETE | Ignore |
6752 | PRIORITY | Required |
6753 | RECURRENCE-ID | Required if RRULE is implemented; otherwise, |
6755 | RELATED-TO | Ignore |
6756 | REQUEST-STATUS | Ignore |
6758 | RRULE | Ignore - assume the first instance occurs on |
6759 | | the DTSTART property. If implemented, |
6760 | | VTIMEZONE MUST also be implemented. |
6761 | RESOURCES | Ignore |
6762 | SEQUENCE | Required |
6763 | STATUS | Required |
6764 | SUMMARY | Ignore |
6768 +------------------+------------------------------------------------+
6778 Daboo Standards Track [Page 121]
6780 RFC 5546 iTIP December 2009
6783 5.1.4. Journal-Related Fallbacks
6785 +---------+---------------------------------------------------------+
6786 | Method | Fallback |
6787 +---------+---------------------------------------------------------+
6788 | PUBLISH | Implementations MAY ignore the METHOD type. The |
6789 | | REQUEST-STATUS "3.14; Unsupported capability" MUST be |
6791 | ADD | Implementations MAY ignore the METHOD type. The |
6792 | | REQUEST-STATUS "3.14; Unsupported capability" MUST be |
6794 | CANCEL | Implementations MAY ignore the METHOD type. The |
6795 | | REQUEST-STATUS "3.14; Unsupported capability" MUST be |
6797 +---------+---------------------------------------------------------+
6799 +-----------------+-------------------------------------------------+
6800 | iCalendar | Fallback |
6802 +-----------------+-------------------------------------------------+
6803 | CALSCALE | Ignore - assume GREGORIAN. |
6805 | METHOD | Required as described in the Method list above. |
6806 | VERSION | Ignore |
6807 +-----------------+-------------------------------------------------+
6809 +-----------------+-------------------------------------------------+
6810 | Journal-Related | Fallback |
6812 +-----------------+-------------------------------------------------+
6813 | VTIMEZONE | Required if any DateTime value refers to a time |
6815 +-----------------+-------------------------------------------------+
6834 Daboo Standards Track [Page 122]
6836 RFC 5546 iTIP December 2009
6839 +-----------------+-------------------------------------------------+
6840 | Component | Fallback |
6842 +-----------------+-------------------------------------------------+
6844 | ATTENDEE | Ignore |
6845 | CATEGORIES | Ignore |
6847 | COMMENT | Ignore |
6848 | CONTACT | Ignore |
6849 | CREATED | Ignore |
6850 | DESCRIPTION | Ignore |
6851 | DTSTAMP | Required |
6852 | DTSTART | Required |
6854 | LAST-MODIFIED | Ignore |
6855 | ORGANIZER | Ignore |
6856 | RECURRENCE-ID | Required if RRULE is implemented; otherwise, |
6858 | RELATED-TO | Ignore |
6860 | RRULE | Ignore - assume the first instance occurs on |
6861 | | the DTSTART property. If implemented, |
6862 | | VTIMEZONE MUST also be implemented. |
6863 | SEQUENCE | Required |
6865 | SUMMARY | Required |
6869 +-----------------+-------------------------------------------------+
6873 With a store-and-forward transport, it is possible for events to
6874 arrive out of sequence. That is, a "CANCEL" method may be received
6875 prior to receiving the associated "REQUEST" for the calendar
6876 component. This section discusses a few of these scenarios.
6878 5.2.1. Cancellation of an Unknown Calendar Component
6880 When a "CANCEL" method is received before the original "REQUEST"
6881 method, the calendar will be unable to correlate the "UID" property
6882 of the cancellation with an existing calendar component. It is
6883 suggested that messages that cannot be correlated and that also
6884 contain non-zero sequence numbers be held and not discarded.
6885 Implementations MAY age them out if no other messages arrive with the
6886 same "UID" property value and a lower sequence number.
6890 Daboo Standards Track [Page 123]
6892 RFC 5546 iTIP December 2009
6895 5.2.2. Unexpected Reply from an Unknown Delegate
6897 When an "Attendee" delegates an item to another CU, they MUST send a
6898 "REPLY" method to the "Organizer" using the "ATTENDEE" properties to
6899 indicate that the request was delegated and to whom. Hence, it is
6900 possible for an "Organizer" to receive a "REPLY" from a CU not listed
6901 as one of the original "Attendees". The resolution is left to the
6902 implementation, but it is expected that the calendaring software will
6903 either accept the reply or hold it until the related "REPLY" method
6904 is received from the "Delegator". If the version of the "REPLY"
6905 method is out of date, the "Organizer" SHOULD treat the message as a
6906 "REFRESH" message and update the "Delegate" with the correct version,
6907 provided that delegation to that delegate is acceptable.
6909 5.3. Sequence Number
6911 Under some conditions, a CUA may receive requests and replies with
6912 the same "SEQUENCE" property value. The "DTSTAMP" property is
6913 utilized as a tie-breaker when two items with the same "SEQUENCE"
6914 property value are evaluated.
6916 6. Security Considerations
6918 iTIP is an abstract transport protocol that will be bound to a real-
6919 time transport, a store-and-forward transport, and perhaps other
6920 transports. The transport protocol will be responsible for providing
6921 facilities for authentication and encryption using standard Internet
6922 mechanisms that are mutually understood between the sender and
6925 6.1. Security Threats
6927 6.1.1. Spoofing the Organizer
6929 In iTIP, the "Organizer" (or someone working on the "Organizer's"
6930 behalf) is the only person authorized to make changes to an existing
6931 "VEVENT", "VTODO", or "VJOURNAL" calendar component and republish it
6932 or redistribute updates to the "Attendees". An iCalendar object that
6933 maliciously changes or cancels an existing "VEVENT", "VTODO", or
6934 "VJOURNAL" calendar component may be constructed by someone other
6935 than the "Organizer" and republished or sent to the "Attendees".
6937 6.1.2. Spoofing the Attendee
6939 In iTIP, an "Attendee" of a "VEVENT" or "VTODO" calendar component
6940 (or someone working on the "Attendee's" behalf) is the only person
6941 authorized to update any parameter associated with their "ATTENDEE"
6946 Daboo Standards Track [Page 124]
6948 RFC 5546 iTIP December 2009
6951 property and send it to the "Organizer". An iCalendar object that
6952 maliciously changes the "ATTENDEE" parameters may be constructed by
6953 someone other than the real "Attendee" and sent to the "Organizer".
6955 6.1.3. Unauthorized Replacement of the Organizer
6957 There will be circumstances when "Attendees" of an event or to-do
6958 decide, using out-of-band mechanisms, that the "Organizer" must be
6959 replaced. When the new "Organizer" sends out the updated "VEVENT" or
6960 "VTODO", the "Attendee's" CUA will detect that the "Organizer" has
6961 been changed, but it has no way of knowing whether or not the change
6962 was mutually agreed upon.
6964 6.1.4. Eavesdropping and Data Integrity
6966 The iCalendar object is constructed with human-readable clear text.
6967 Any information contained in an iCalendar object may be read and/or
6968 changed by unauthorized persons while the object is in transit.
6970 6.1.5. Flooding a Calendar
6972 Implementations could provide a means to automatically incorporate
6973 "REQUEST" methods into a calendar. This presents the opportunity for
6974 a calendar to be flooded with requests, which effectively blocks all
6975 the calendar's free time.
6977 6.1.6. Unauthorized REFRESH Requests
6979 It is possible for an "Organizer" to receive a "REFRESH" request from
6980 someone who is not an "Attendee" of an event or to-do. Only
6981 "Attendees" of an event or to-do are authorized to receive replies to
6982 "REFRESH" requests. Replying to such requests to anyone who is not
6983 an "Attendee" may be a security problem.
6985 6.2. Recommendations
6987 For an application where the information is sensitive or critical and
6988 the network is subject to a high probability of attack, iTIP
6989 transactions SHOULD be encrypted and authenticated. This helps
6990 mitigate the threats of spoofing, eavesdropping, and malicious
6993 6.2.1. Securing iTIP transactions
6995 iTIP transport bindings MUST provide a mechanism to enable
6996 authentication of the sender's identity as well as privacy and
6997 integrity of the data being transmitted. This allows the receiver of
6998 a signed iCalendar object to verify the identity of the sender. This
7002 Daboo Standards Track [Page 125]
7004 RFC 5546 iTIP December 2009
7007 sender may then be correlated to an "ATTENDEE" property in the
7008 iCalendar object. If the correlation is made and the sender is
7009 authorized to make the requested change or update, then the operation
7010 may proceed. It also allows the message to be encrypted to prevent
7011 unauthorized reading of the message contents in transit. iTIP
7012 transport binding documents describe this process in detail.
7014 6.2.2. Implementation Controls
7016 The threat of unauthorized replacement of the "Organizer" SHOULD be
7017 mitigated by a calendar system that uses this protocol by providing
7018 controls or alerts that make "Calendar Users" aware of such
7019 "Organizer" changes and allowing them to decide whether or not the
7020 request should be honored.
7022 The threat of flooding a calendar SHOULD be mitigated by a calendar
7023 system that uses this protocol by providing controls that may be used
7024 to limit the acceptable sources for iTIP transactions, and perhaps
7025 the size of messages and volume of traffic, by source.
7027 The threat of unauthorized "REFRESH" requests SHOULD be mitigated by
7028 a calendar system that uses this protocol by providing controls or
7029 alerts that allow "Calendar Users" to decide whether or not the
7030 request should be honored. An implementation MAY decide to maintain,
7031 for audit or historical purposes, "Calendar Users" who were part of
7032 an "Attendee" list and who were subsequently uninvited. Similar
7033 controls or alerts should be provided when a "REFRESH" request is
7034 received from these "Calendar Users" as well.
7036 6.2.3. Access Controls and Filtering
7038 In many environments, there could be restrictions on who is allowed
7039 to schedule with whom and who the allowed delegates are for
7040 particular "Calendar Users".
7042 iTIP transport bindings SHOULD provide mechanisms for implementing
7043 access controls or filtering to ensure iTIP transactions only take
7044 place between authorized "Calendar Users". That would include
7045 preventing one "Calendar User" from scheduling with another or one
7046 "Calendar User" delegating to another.
7050 The "Organizer" might want to keep "Attendees" from knowing which
7051 other "Attendees" are participating in an event or to-do. The
7052 "Organizer" has the choice of sending single iTIP messages with a
7053 full list of "Attendees" or sending iTIP messages to each "Attendee"
7054 with only that "Attendee" listed.
7058 Daboo Standards Track [Page 126]
7060 RFC 5546 iTIP December 2009
7063 7. IANA Considerations
7065 7.1. Registration Template for REQUEST-STATUS Values
7067 This specification updates [RFC5545] by adding a "REQUEST-STATUS"
7068 value registry to the iCalendar Elements registry.
7070 A "REQUEST-STATUS" value is defined by completing the following
7073 Status Code: Hierarchical, numeric return status code, following
7074 the rules defined in Section 3.8.8.3 of [RFC5545].
7076 Status Description: Textual status description. A short but
7077 clear description of the error.
7079 Status Exception Data: Textual exception data. A short but clear
7080 description of what might appear in this field.
7082 Description: Describe the underlying cause for this status code
7085 7.2. Additions to iCalendar METHOD Registry
7087 This document defines the following values for the iCalendar "METHOD"
7088 property, using the values template from Section 8.2.6 of [RFC5545].
7089 These should be added to the Methods Registry defined in Section
7090 8.3.12 of [RFC5545]:
7092 7.2.1. METHOD:PUBLISH
7096 Purpose: Standard iTIP "METHOD" value.
7098 Conformance: Only used with the "METHOD" property.
7100 Examples: See this RFC.
7102 7.2.2. METHOD:REQUEST
7106 Purpose: Standard iTIP "METHOD" value.
7108 Conformance: Only used with the "METHOD" property.
7110 Examples: See this RFC.
7114 Daboo Standards Track [Page 127]
7116 RFC 5546 iTIP December 2009
7123 Purpose: Standard iTIP "METHOD" value.
7125 Conformance: Only used with the "METHOD" property.
7127 Examples: See this RFC.
7133 Purpose: Standard iTIP "METHOD" value.
7135 Conformance: Only used with the "METHOD" property.
7137 Examples: See this RFC.
7139 7.2.5. METHOD:CANCEL
7143 Purpose: Standard iTIP "METHOD" value.
7145 Conformance: Only used with the "METHOD" property.
7147 Examples: See this RFC.
7149 7.2.6. METHOD:REFRESH
7153 Purpose: Standard iTIP "METHOD" value.
7155 Conformance: Only used with the "METHOD" property.
7157 Examples: See this RFC.
7159 7.2.7. METHOD:COUNTER
7163 Purpose: Standard iTIP "METHOD" value.
7165 Conformance: Only used with the "METHOD" property.
7170 Daboo Standards Track [Page 128]
7172 RFC 5546 iTIP December 2009
7175 Examples: See this RFC.
7177 7.2.8. METHOD:DECLINECOUNTER
7179 Value: DECLINECOUNTER
7181 Purpose: Standard iTIP "METHOD" value.
7183 Conformance: Only used with the "METHOD" property.
7185 Examples: See this RFC.
7187 7.3. REQUEST-STATUS Value Registry
7189 New "REQUEST-STATUS" values can be registered using the process
7190 described in Section 8.2.1 of [RFC5545].
7192 The following table is to be used to initialize the "REQUEST-STATUS"
7226 Daboo Standards Track [Page 129]
7228 RFC 5546 iTIP December 2009
7231 +-------------+---------+--------------------------+
7232 | Status Code | Status | Reference |
7233 +-------------+---------+--------------------------+
7234 | 2.0 | Current | RFC 5546, Section 3.6.1 |
7235 | 2.1 | Current | RFC 5546, Section 3.6.2 |
7236 | 2.2 | Current | RFC 5546, Section 3.6.3 |
7237 | 2.3 | Current | RFC 5546, Section 3.6.4 |
7238 | 2.4 | Current | RFC 5546, Section 3.6.5 |
7239 | 2.5 | Current | RFC 5546, Section 3.6.6 |
7240 | 2.6 | Current | RFC 5546, Section 3.6.7 |
7241 | 2.7 | Current | RFC 5546, Section 3.6.8 |
7242 | 2.8 | Current | RFC 5546, Section 3.6.9 |
7243 | 2.9 | Current | RFC 5546, Section 3.6.10 |
7244 | 2.10 | Current | RFC 5546, Section 3.6.11 |
7245 | 2.11 | Current | RFC 5546, Section 3.6.12 |
7246 | 3.0 | Current | RFC 5546, Section 3.6.13 |
7247 | 3.1 | Current | RFC 5546, Section 3.6.14 |
7248 | 3.2 | Current | RFC 5546, Section 3.6.15 |
7249 | 3.3 | Current | RFC 5546, Section 3.6.16 |
7250 | 3.4 | Current | RFC 5546, Section 3.6.17 |
7251 | 3.5 | Current | RFC 5546, Section 3.6.18 |
7252 | 3.6 | Current | RFC 5546, Section 3.6.19 |
7253 | 3.7 | Current | RFC 5546, Section 3.6.20 |
7254 | 3.8 | Current | RFC 5546, Section 3.6.21 |
7255 | 3.9 | Current | RFC 5546, Section 3.6.22 |
7256 | 3.10 | Current | RFC 5546, Section 3.6.23 |
7257 | 3.11 | Current | RFC 5546, Section 3.6.24 |
7258 | 3.12 | Current | RFC 5546, Section 3.6.25 |
7259 | 3.13 | Current | RFC 5546, Section 3.6.26 |
7260 | 3.14 | Current | RFC 5546, Section 3.6.27 |
7261 | 4.0 | Current | RFC 5546, Section 3.6.28 |
7262 | 5.0 | Current | RFC 5546, Section 3.6.29 |
7263 | 5.1 | Current | RFC 5546, Section 3.6.30 |
7264 | 5.2 | Current | RFC 5546, Section 3.6.31 |
7265 | 5.3 | Current | RFC 5546, Section 3.6.32 |
7266 +-------------+---------+--------------------------+
7270 This is an update to the original iTIP document authored by S.
7271 Silverberg, S. Mansour, F. Dawson, and R. Hopson.
7273 This revision is the product of the Calsify IETF Working Group, and
7274 several participants have made important contributions to this
7275 specification, including Oliver Block, Bernard Desruisseaux, Mike
7276 Douglass, Tim Hare, Ciny Joy, Bruce Kahn, Reinhold Kainhofer, Eliot
7277 Lear, Jonathan Lennox, Andy Mabbett, Aki Niemi, John W. Noerenberg
7278 II, Robert Ransdell, and Caleb Richardson.
7282 Daboo Standards Track [Page 130]
7284 RFC 5546 iTIP December 2009
7289 9.1. Normative References
7291 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
7292 Requirement Levels", BCP 14, RFC 2119, March 1997.
7294 [RFC2368] Hoffman, P., Masinter, L., and J. Zawinski, "The mailto
7295 URL scheme", RFC 2368, July 1998.
7297 [RFC5545] Desruisseaux, B., "Internet Calendaring and Scheduling
7298 Core Object Specification (iCalendar)", RFC 5545,
7301 9.2. Informative References
7303 [iMIP] Melnikov, A., Ed., "iCalendar Message-Based
7304 Interoperability Protocol (iMIP)", Work in Progress,
7338 Daboo Standards Track [Page 131]
7340 RFC 5546 iTIP December 2009
7343 Appendix A. Differences from RFC 2446
7345 A.1. Changed Restrictions
7347 This specification now defines an allowed combination of "REQUEST-
7348 STATUS" codes when multiple iCalendar components are included in an
7351 This specification now restricts "RECURRENCE-ID" to only a single
7352 occurrence in any one iCalendar component in an iTIP message, as
7353 required by [RFC5545].
7355 Changed the "RECURRENCE-ID" entry in the component restriction table
7356 to "0 or 1" from "0+", to fall in line with [RFC5545].
7358 Changed the "FREEBUSY" entry in the "VFREEBUSY", "PUBLISH", and
7359 "REPLY" restriction tables to "0+" from "1+", to fall in line with
7362 Changed the "FREEBUSY" description in the "VFREEBUSY" and "REPLY"
7363 restriction tables to indicate that different "FBTYPE" ranges MUST
7366 Changed the "TZNAME" entry in the "VTIMEZONE" restriction table to
7367 "0+" from "0 or 1", to fall in line with [RFC5545].
7369 Changed the "COMMENT" entry in the component restriction tables to
7370 "0+" from "0 or 1", to fall in line with [RFC5545].
7372 Added the "ATTENDEE" entry in the "VALARM" restriction table to match
7373 the email alarm type in [RFC5545].
7375 Changed the "CATEGORIES" entry in the component restriction tables to
7376 "0+" from "0 or 1", to fall in line with [RFC5545].
7378 Changed the "RESOURCES" entry in the component restriction tables to
7379 "0+" from "0 or 1", to fall in line with [RFC5545].
7381 Changed the "CONTACT" entry in the "VFREEBUSY" restriction table to
7382 "0 or 1" from "0+", to fall in line with [RFC5545].
7384 Changed the "UID" entry in the "VFREEBUSY" and "PUBLISH" restriction
7385 tables to "1" from "0", to fall in line with [RFC5545].
7387 Added the "COMPLETED" entry in the "VTODO" restriction tables to fall
7388 in line with [RFC5545].
7394 Daboo Standards Track [Page 132]
7396 RFC 5546 iTIP December 2009
7399 Added the "REQUEST-STATUS" entry in the "VJOURNAL" restriction tables
7400 to fall in line with [RFC5545].
7402 A.2. Deprecated Features
7404 The "EXRULE" property was removed in [RFC5545] and references to that
7405 have been removed in this document too.
7407 The "PROCEDURE" value for the "ACTION" property was removed in
7408 [RFC5545] and references to that have been removed in this document
7411 The "THISANDPRIOR" option for the "RANGE" parameter was removed in
7412 [RFC5545] and references to that have been removed in this document
7417 Cyrus Daboo (editor)
7423 EMail: cyrus@daboo.name
7424 URI: http://www.apple.com/
7450 Daboo Standards Track [Page 133]
projects / friendica-addons.git / blob