idnits 2.17.1 draft-ietf-calsify-2446bis-10.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.i or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 2 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. -- The draft header indicates that this document obsoletes RFC2446, but the abstract doesn't seem to mention this, which it should. -- The draft header indicates that this document updates RFC5545, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The exact meaning of the all-uppercase expression 'MAY NOT' is not defined in RFC 2119. If it is intended as a requirements expression, it should be rewritten using one of the combinations defined in RFC 2119; otherwise it should not be all-uppercase. == The expression 'MAY NOT', while looking like RFC 2119 requirements text, is not defined in RFC 2119, and should not be used. Consider using 'MUST NOT' instead (if that is what you mean). Found 'MAY NOT' in this paragraph: Changes in -04: a. Added empty IANA Considerations section - to be done. b. Formatting fixes. c. Changed VEVENT, VTODO, VJOURNAL cancel descriptions that incorrectly implied RECURRENCE-ID could appear multiple times in a single component. d. [Issue91] FREEBUSY properties changed to '0+' from '1+' in VFREEBUSY PUBLISH and REPLY tables. e. [Issue89] Description for VEVENT ADD method simplified for clarity. f. Fixed some iCalendar property/parameter/value capitalization issues. g. MAY NOT -> MUST NOT in VFREEBUSY FREEBUSY response type. -- The document seems to contain a disclaimer for pre-RFC5378 work, and may have content which was first submitted before 10 November 2008. The disclaimer is necessary when there are original authors that you have been unable to contact, or if some do not wish to grant the BCP78 rights to the IETF Trust. If you are able to get all authors (current and original) to grant those rights, you can and should remove the disclaimer; otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 4, 2009) is 5317 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'Issue91' is mentioned on line 5864, but not defined == Missing Reference: 'Issue89' is mentioned on line 5866, but not defined ** Obsolete normative reference: RFC 2368 (Obsoleted by RFC 6068) == Outdated reference: A later version (-11) exists of draft-ietf-calsify-rfc2447bis-06 Summary: 2 errors (**), 0 flaws (~~), 6 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group C. Daboo, Ed. 3 Internet-Draft Apple Inc. 4 Obsoletes: 2446 (if approved) October 4, 2009 5 Updates: 5545 (if approved) 6 Intended status: Standards Track 7 Expires: April 7, 2010 9 iCalendar Transport-Independent Interoperability Protocol (iTIP) 10 draft-ietf-calsify-2446bis-10 12 Status of this Memo 14 This Internet-Draft is submitted to IETF in full conformance with the 15 provisions of BCP 78 and BCP 79. This document may contain material 16 from IETF Documents or IETF Contributions published or made publicly 17 available before November 10, 2008. The person(s) controlling the 18 copyright in some of this material may not have granted the IETF 19 Trust the right to allow modifications of such material outside the 20 IETF Standards Process. Without obtaining an adequate license from 21 the person(s) controlling the copyright in such materials, this 22 document may not be modified outside the IETF Standards Process, and 23 derivative works of it may not be created outside the IETF Standards 24 Process, except to format it for publication as an RFC or to 25 translate it into languages other than English. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF), its areas, and its working groups. Note that 29 other groups may also distribute working documents as Internet- 30 Drafts. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 The list of current Internet-Drafts can be accessed at 38 http://www.ietf.org/ietf/1id-abstracts.txt. 40 The list of Internet-Draft Shadow Directories can be accessed at 41 http://www.ietf.org/shadow.html. 43 This Internet-Draft will expire on April 7, 2010. 45 Copyright Notice 47 Copyright (c) 2009 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents in effect on the date of 52 publication of this document (http://trustee.ietf.org/license-info). 53 Please review these documents carefully, as they describe your rights 54 and restrictions with respect to this document. 56 Abstract 58 This document specifies a protocol using the iCalendar object 59 specification to provide scheduling interoperability between 60 different calendaring systems. This is done without reference to a 61 specific transport protocol so as to allow multiple methods of 62 communication between systems. Subsequent documents will define 63 profiles of this protocol using specific interoperable methods of 64 communications between systems. 66 iTIP complements the iCalendar object specification by adding 67 semantics for group scheduling methods commonly available in current 68 calendaring systems. These scheduling methods permit two or more 69 calendaring systems to perform transactions such as publish, 70 schedule, reschedule, respond to scheduling requests, negotiation of 71 changes or cancel. 73 Table of Contents 75 1. Introduction and Overview . . . . . . . . . . . . . . . . . . 6 76 1.1. Formatting Conventions . . . . . . . . . . . . . . . . . 6 77 1.2. Related Documents . . . . . . . . . . . . . . . . . . . . 7 78 1.3. Roles . . . . . . . . . . . . . . . . . . . . . . . . . . 7 79 1.4. Methods . . . . . . . . . . . . . . . . . . . . . . . . . 8 80 2. Interoperability Models . . . . . . . . . . . . . . . . . . . 9 81 2.1. Application Protocol . . . . . . . . . . . . . . . . . . 10 82 2.1.1. Scheduling State . . . . . . . . . . . . . . . . . . 10 83 2.1.2. Delegation . . . . . . . . . . . . . . . . . . . . . 11 84 2.1.3. Acting on Behalf of other Calendar Users . . . . . . 11 85 2.1.4. Component Revisions . . . . . . . . . . . . . . . . . 11 86 2.1.5. Message Sequencing . . . . . . . . . . . . . . . . . 13 87 3. Application Protocol Elements . . . . . . . . . . . . . . . . 14 88 3.1. Common Component Restriction Tables . . . . . . . . . . . 15 89 3.1.1. VCALENDAR . . . . . . . . . . . . . . . . . . . . . . 15 90 3.1.2. VTIMEZONE . . . . . . . . . . . . . . . . . . . . . . 15 91 3.1.3. VALARM . . . . . . . . . . . . . . . . . . . . . . . 16 92 3.2. Methods for VEVENT Calendar Components . . . . . . . . . 17 93 3.2.1. PUBLISH . . . . . . . . . . . . . . . . . . . . . . . 18 94 3.2.2. REQUEST . . . . . . . . . . . . . . . . . . . . . . . 20 95 3.2.3. REPLY . . . . . . . . . . . . . . . . . . . . . . . . 24 96 3.2.4. ADD . . . . . . . . . . . . . . . . . . . . . . . . . 27 97 3.2.5. CANCEL . . . . . . . . . . . . . . . . . . . . . . . 28 98 3.2.6. REFRESH . . . . . . . . . . . . . . . . . . . . . . . 31 99 3.2.7. COUNTER . . . . . . . . . . . . . . . . . . . . . . . 32 100 3.2.8. DECLINECOUNTER . . . . . . . . . . . . . . . . . . . 34 101 3.3. Methods For VFREEBUSY Components . . . . . . . . . . . . 36 102 3.3.1. PUBLISH . . . . . . . . . . . . . . . . . . . . . . . 36 103 3.3.2. REQUEST . . . . . . . . . . . . . . . . . . . . . . . 38 104 3.3.3. REPLY . . . . . . . . . . . . . . . . . . . . . . . . 40 105 3.4. Methods For VTODO Components . . . . . . . . . . . . . . 41 106 3.4.1. PUBLISH . . . . . . . . . . . . . . . . . . . . . . . 42 107 3.4.2. REQUEST . . . . . . . . . . . . . . . . . . . . . . . 44 108 3.4.3. REPLY . . . . . . . . . . . . . . . . . . . . . . . . 49 109 3.4.4. ADD . . . . . . . . . . . . . . . . . . . . . . . . . 51 110 3.4.5. CANCEL . . . . . . . . . . . . . . . . . . . . . . . 53 111 3.4.6. REFRESH . . . . . . . . . . . . . . . . . . . . . . . 55 112 3.4.7. COUNTER . . . . . . . . . . . . . . . . . . . . . . . 57 113 3.4.8. DECLINECOUNTER . . . . . . . . . . . . . . . . . . . 58 114 3.5. Methods For VJOURNAL Components . . . . . . . . . . . . . 60 115 3.5.1. PUBLISH . . . . . . . . . . . . . . . . . . . . . . . 60 116 3.5.2. ADD . . . . . . . . . . . . . . . . . . . . . . . . . 63 117 3.5.3. CANCEL . . . . . . . . . . . . . . . . . . . . . . . 65 118 3.6. Status Replies . . . . . . . . . . . . . . . . . . . . . 67 119 3.7. Implementation Considerations . . . . . . . . . . . . . . 74 120 3.7.1. Working With Recurrence Instances . . . . . . . . . . 74 121 3.7.2. Attendee Property Considerations . . . . . . . . . . 75 122 3.7.3. Extension Tokens . . . . . . . . . . . . . . . . . . 75 123 4. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 76 124 4.1. Published Event Examples . . . . . . . . . . . . . . . . 76 125 4.1.1. A Minimal Published Event . . . . . . . . . . . . . . 76 126 4.1.2. Changing A Published Event . . . . . . . . . . . . . 77 127 4.1.3. Canceling A Published Event . . . . . . . . . . . . . 77 128 4.1.4. A Rich Published Event . . . . . . . . . . . . . . . 78 129 4.1.5. Anniversaries or Events attached to entire days . . . 79 130 4.2. Group Event Examples . . . . . . . . . . . . . . . . . . 80 131 4.2.1. A Group Event Request . . . . . . . . . . . . . . . . 81 132 4.2.2. Reply To A Group Event Request . . . . . . . . . . . 81 133 4.2.3. Update An Event . . . . . . . . . . . . . . . . . . . 82 134 4.2.4. Countering an Event Proposal . . . . . . . . . . . . 83 135 4.2.5. Delegating an Event . . . . . . . . . . . . . . . . . 85 136 4.2.6. Delegate Accepts the Meeting . . . . . . . . . . . . 87 137 4.2.7. Delegate Declines the Meeting . . . . . . . . . . . . 88 138 4.2.8. Forwarding an Event Request . . . . . . . . . . . . . 89 139 4.2.9. Cancel A Group Event . . . . . . . . . . . . . . . . 89 140 4.2.10. Removing Attendees . . . . . . . . . . . . . . . . . 91 141 4.2.11. Replacing the Organizer . . . . . . . . . . . . . . . 92 142 4.3. Busy Time Examples . . . . . . . . . . . . . . . . . . . 93 143 4.3.1. Publish Busy Time . . . . . . . . . . . . . . . . . . 93 144 4.3.2. Request Busy Time . . . . . . . . . . . . . . . . . . 94 145 4.3.3. Reply To A Busy Time Request . . . . . . . . . . . . 95 146 4.4. Recurring Event and Time Zone Examples . . . . . . . . . 95 147 4.4.1. A Recurring Event Spanning Time Zones . . . . . . . . 95 148 4.4.2. Modify A Recurring Instance . . . . . . . . . . . . . 97 149 4.4.3. Cancel an Instance . . . . . . . . . . . . . . . . . 99 150 4.4.4. Cancel Recurring Event . . . . . . . . . . . . . . . 100 151 4.4.5. Change All Future Instances . . . . . . . . . . . . . 100 152 4.4.6. Add A New Instance To A Recurring Event . . . . . . . 101 153 4.4.7. Add A New Series of Instances To A Recurring Event . 102 154 4.4.8. Refreshing A Recurring Event . . . . . . . . . . . . 104 155 4.4.9. Counter An Instance Of A Recurring Event . . . . . . 106 156 4.4.10. Error Reply To A Request . . . . . . . . . . . . . . 107 157 4.5. Group To-do Examples . . . . . . . . . . . . . . . . . . 109 158 4.5.1. A VTODO Request . . . . . . . . . . . . . . . . . . . 110 159 4.5.2. A VTODO Reply . . . . . . . . . . . . . . . . . . . . 110 160 4.5.3. A VTODO Request for Updated Status . . . . . . . . . 111 161 4.5.4. A Reply: Percent-Complete . . . . . . . . . . . . . . 111 162 4.5.5. A Reply: Completed . . . . . . . . . . . . . . . . . 112 163 4.5.6. An Updated VTODO Request . . . . . . . . . . . . . . 112 164 4.5.7. Recurring VTODOs . . . . . . . . . . . . . . . . . . 113 165 4.6. Journal Examples . . . . . . . . . . . . . . . . . . . . 114 166 4.7. Other Examples . . . . . . . . . . . . . . . . . . . . . 114 167 4.7.1. Event Refresh . . . . . . . . . . . . . . . . . . . . 114 168 4.7.2. Bad RECURRENCE-ID . . . . . . . . . . . . . . . . . . 115 170 5. Application Protocol Fallbacks . . . . . . . . . . . . . . . 118 171 5.1. Partial Implementation . . . . . . . . . . . . . . . . . 118 172 5.1.1. Event-Related Fallbacks . . . . . . . . . . . . . . . 118 173 5.1.2. Free/Busy-Related Fallbacks . . . . . . . . . . . . . 120 174 5.1.3. To-Do-Related Fallbacks . . . . . . . . . . . . . . . 121 175 5.1.4. Journal-Related Fallbacks . . . . . . . . . . . . . . 123 176 5.2. Latency Issues . . . . . . . . . . . . . . . . . . . . . 124 177 5.2.1. Cancellation of an Unknown Calendar Component. . . . 124 178 5.2.2. Unexpected Reply from an Unknown Delegate . . . . . . 125 179 5.3. Sequence Number . . . . . . . . . . . . . . . . . . . . . 125 180 6. Security Considerations . . . . . . . . . . . . . . . . . . . 125 181 6.1. Security Threats . . . . . . . . . . . . . . . . . . . . 125 182 6.1.1. Spoofing the "Organizer" . . . . . . . . . . . . . . 125 183 6.1.2. Spoofing the "Attendee" . . . . . . . . . . . . . . . 125 184 6.1.3. Unauthorized Replacement of the Organizer . . . . . . 126 185 6.1.4. Eavesdropping and Data Integrity . . . . . . . . . . 126 186 6.1.5. Flooding a Calendar . . . . . . . . . . . . . . . . . 126 187 6.1.6. Unauthorized REFRESH Requests . . . . . . . . . . . . 126 188 6.2. Recommendations . . . . . . . . . . . . . . . . . . . . . 126 189 6.2.1. Securing iTIP transactions . . . . . . . . . . . . . 126 190 6.2.2. Implementation Controls . . . . . . . . . . . . . . . 127 191 6.2.3. Access Controls and Filtering . . . . . . . . . . . . 127 192 6.3. Privacy Issues . . . . . . . . . . . . . . . . . . . . . 127 193 7. IANA Consideration . . . . . . . . . . . . . . . . . . . . . 128 194 7.1. Registration Template for REQUEST-STATUS Values . . . . . 128 195 7.2. Additions to iCalendar METHOD Registry . . . . . . . . . 128 196 7.3. REQUEST-STATUS Value Registry . . . . . . . . . . . . . . 129 197 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 130 198 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 131 199 9.1. Normative References . . . . . . . . . . . . . . . . . . 131 200 9.2. Informative References . . . . . . . . . . . . . . . . . 131 201 Appendix A. Differences from RFC 2446 . . . . . . . . . . . . . 131 202 A.1. Changed Restrictions . . . . . . . . . . . . . . . . . . 131 203 A.2. Deprecated features . . . . . . . . . . . . . . . . . . . 132 204 Appendix B. Change History (to be removed prior to 205 publication as an RFC) . . . . . . . . . . . . . . . 132 206 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 135 208 1. Introduction and Overview 210 This document specifies how calendaring systems use iCalendar 211 [RFC5545] objects to interoperate with other calendaring systems. In 212 particular, it specifies how to schedule events, to-dos, or daily 213 journal entries. It further specifies how to search for available 214 busy time information. It does so in a general way without 215 specifying how communication between different systems actually takes 216 place. Subsequent documents specify transport bindings between 217 systems that use this protocol. 219 This protocol is based on messages sent from an originator to one or 220 more recipients. For certain types of messages, a recipient may 221 reply, in order to update their status and may also return 222 transaction/request status information. The protocol supports the 223 ability for the message originator to modify or cancel the original 224 message. The protocol also supports the ability for recipients to 225 suggest changes to the originator of a message. The elements of the 226 protocol also define the user roles for its transactions. 228 This specification obsoletes RFC 2446 - a list of important changes 229 is provided in Appendix A. 231 1.1. Formatting Conventions 233 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 234 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 235 document are to be interpreted as described in [RFC2119]. 237 Calendaring and scheduling roles are referred to in quoted-strings of 238 text with the first character of each word in upper case. For 239 example, "Organizer" refers to a role of a "Calendar User" (CU) 240 within the scheduling protocol. 242 Calendar components defined by [RFC5545] are referred to with 243 capitalized, quoted-strings of text. All calendar components start 244 with the letter "V". For example, "VEVENT" refers to the event 245 calendar component, "VTODO" refers to the to-do calendar component 246 and "VJOURNAL" refers to the daily journal calendar component. 248 Scheduling methods are referred to with capitalized, quoted-strings 249 of text. For example, "REQUEST" refers to the method for requesting 250 a scheduling calendar component be created or modified, "REPLY" 251 refers to the method a recipient of a request uses to update their 252 status with the "Organizer" of the calendar component. 254 Properties defined by [RFC5545] are referred to with capitalized, 255 quoted-strings of text, followed by the word "property". For 256 example, "ATTENDEE" property refers to the iCalendar property used to 257 convey the calendar address of a "Calendar User". 259 Property parameters defined by this specification are referred to 260 with capitalized, quoted-strings of text, followed by the word 261 "parameter". For example, "VALUE" parameter refers to the iCalendar 262 property parameter used to override the default data type for a 263 property value. 265 Enumerated values defined by this specification are referred to with 266 capitalized text, either alone or followed by the word "value". 268 In tables, the quoted-string text is specified without quotes in 269 order to minimize the table length. 271 1.2. Related Documents 273 Implementers will need to be familiar with several other 274 specifications that, along with this one, describe the Internet 275 calendaring and scheduling standards. The related documents are: 277 [RFC5545] - specifies the objects, data types, properties and 278 property parameters used in the protocols, along with the methods 279 for representing and encoding them. 281 [I-D.ietf-calsify-rfc2447bis] specifies an Internet email binding 282 for iTIP. 284 This specification does not attempt to repeat the concepts or 285 definitions from these other specifications. Where possible, 286 explicit references are made to the other specifications. 288 1.3. Roles 290 Exchanges of iCalendar objects for the purposes of group calendaring 291 and scheduling occur between "Calendar Users" (CUs). CUs take on 292 several roles in iTIP: 294 +-----------+-------------------------------------------------------+ 295 | Role | Description | 296 +-----------+-------------------------------------------------------+ 297 | Organizer | The CU who initiates an exchange takes on the role of | 298 | | "Organizer". For example, the CU who proposes a | 299 | | group meeting is the "Organizer". | 300 | | | 301 | Attendee | CUs who are included in the scheduling message as | 302 | | possible recipients of that scheduling message. For | 303 | | example, the CUs asked to participate in a group | 304 | | meeting by the "Organizer" take on the role of | 305 | | "Attendee". | 306 | | | 307 | Other CU | A CU that is not explicitly included in a scheduling | 308 | | message, i.e., not the "Organizer" or an "Attendee". | 309 +-----------+-------------------------------------------------------+ 311 Note that "ROLE" is also a descriptive parameter to the iCalendar 312 "ATTENDEE" property. Its use is to convey descriptive context about 313 an "Attendee" such as "chair", "required participant" or "non- 314 required participant" and has nothing to do with the calendaring 315 workflow. 317 1.4. Methods 319 The iTIP methods are listed below and their usage and semantics are 320 defined in section 3 of this document. 322 +----------------+--------------------------------------------------+ 323 | Method | Description | 324 +----------------+--------------------------------------------------+ 325 | PUBLISH | Used to publish an iCalendar object to one or | 326 | | more Calendar Users. There is no interactivity | 327 | | between the publisher and any other calendar | 328 | | user. An example might include a baseball team | 329 | | publishing its schedule to the public. | 330 | | | 331 | REQUEST | Used to schedule an iCalendar object with other | 332 | | Calendar Users. Requests are interactive in | 333 | | that they require the receiver to respond using | 334 | | the reply methods. Meeting requests, busy time | 335 | | requests and the assignment of tasks to other | 336 | | Calendar Users are all examples. Requests are | 337 | | also used by the "Organizer" to update the | 338 | | status of an iCalendar object. | 339 | | | 340 | REPLY | A reply is used in response to a request to | 341 | | convey "Attendee" status to the "Organizer". | 342 | | Replies are commonly used to respond to meeting | 343 | | and task requests. | 344 | | | 345 | ADD | Add one or more new instances to an existing | 346 | | recurring iCalendar object. | 347 | | | 348 | CANCEL | Cancel one or more instances of an existing | 349 | | iCalendar object. | 350 | | | 351 | REFRESH | The Refresh method is used by an "Attendee" to | 352 | | request the latest version of an iCalendar | 353 | | object. | 354 | | | 355 | COUNTER | The Counter method is used by an "Attendee" to | 356 | | negotiate a change in an iCalendar object. | 357 | | Examples include the request to change a | 358 | | proposed event time or change the due date for a | 359 | | task. | 360 | | | 361 | DECLINECOUNTER | Used by the "Organizer" to decline the proposed | 362 | | counter-proposal. | 363 +----------------+--------------------------------------------------+ 365 Group scheduling in iTIP is accomplished using the set of "request" 366 and "response" methods described above. The following table shows 367 the methods broken down by who can send them. 369 +------------+------------------------------------------------------+ 370 | Originator | Methods | 371 +------------+------------------------------------------------------+ 372 | Organizer | PUBLISH, REQUEST, ADD, CANCEL, DECLINECOUNTER | 373 | | | 374 | Attendee | REPLY, REFRESH, COUNTER, REQUEST (only when | 375 | | delegating) | 376 +------------+------------------------------------------------------+ 378 Note that for some calendar component types, the allowable methods 379 are a subset of the above set. In addition, apart from "VTIMEZONE" 380 iCalendar components, only one component type is allowed in a single 381 iTIP message. 383 2. Interoperability Models 385 There are two distinct protocols relevant to interoperability: an 386 "Application Protocol" and a "Transport Protocol". The Application 387 Protocol defines the content of the iCalendar objects sent between 388 sender and receiver to accomplish the scheduling transactions listed 389 above. The Transport Protocol defines how the iCalendar objects are 390 sent between the sender and receiver. This document focuses on the 391 Application Protocol. Binding documents such as 392 [I-D.ietf-calsify-rfc2447bis] focus on the Transport Protocol. 394 The connection between Sender and Receiver in the diagram below 395 refers to the Application Protocol. The iCalendar objects passed 396 from the Sender to the Receiver are presented in Section 3, 397 Application Protocol Elements. 399 +----------+ +----------+ 400 | | iTIP | | 401 | Sender |<-------------->| Receiver | 402 | | | | 403 +----------+ +----------+ 405 There are several variations of this diagram in which the Sender and 406 Receiver take on various roles of a "Calendar User Agent" (CUA) or a 407 "Calendar Service" (CS). 409 The architecture of iTIP is depicted in the diagram below. An 410 application written to this specification may work with bindings for 411 the store-and-forward transport, the real time transport, or both. 412 Also note that iTIP could be bound to other transports. 414 +--------------------------------------------------------+ 415 | iTIP Protocol | 416 +--------------------------------------------------------+ 417 | Transport | 418 + - - - - - + - - - - - - + - - - - - + 419 | Real-time | Store-and-Forward | Others | 420 +-----------------+--------------------+-----------------+ 422 2.1. Application Protocol 424 In the iTIP model, an iCalendar object is created and managed by an 425 "Organizer". The "Organizer" interacts with other CUs by sending one 426 or more of the iTIP messages listed above. "Attendees" use the 427 "REPLY" method to communicate their status. "Attendees" do not make 428 direct changes to the master iCalendar object. They can, however, 429 use the "COUNTER" method to suggest changes to the "Organizer". In 430 any case, the "Organizer" has complete control over the master 431 iCalendar object. 433 2.1.1. Scheduling State 435 There are two distinct states relevant to iCalendar objects used in 436 scheduling: the overall state of the iCalendar object and the state 437 associated with an "Attendee" in that iCalendar object. 439 The state of an iCalendar object is defined by the "STATUS" property 440 and is controlled by the "Organizer." There is no default value for 441 the "STATUS" property. The "Organizer" sets the "STATUS" property to 442 the appropriate value for each iCalendar object. 444 The state of a particular "Attendee" relative to a iCalendar object 445 used for scheduling is defined by the "PARTSTAT" parameter in the 446 "ATTENDEE" property for each "Attendee". When an "Organizer" issues 447 the initial iCalendar object, "Attendee" status is typically unknown. 448 The "Organizer" specifies this by setting the "PARTSTAT" parameter to 449 "NEEDS-ACTION". Each "Attendee" modifies their "ATTENDEE" property 450 "PARTSTAT" parameter to an appropriate value as part of a "REPLY" 451 message sent back to the "Organizer". 453 2.1.2. Delegation 455 Delegation is defined as the process by which an "Attendee" grants 456 another CU (or several CUs) the right to attend on their behalf. The 457 "Organizer" is made aware of this change because the delegating 458 "Attendee" informs the "Organizer". These steps are detailed in the 459 REQUEST method section. 461 2.1.3. Acting on Behalf of other Calendar Users 463 In many organizations one user will act on behalf of another to 464 organize and/or respond to meeting requests. iTIP provides two 465 mechanisms that support these activities. 467 First, the "Organizer" is treated as a special entity, separate from 468 "Attendees". All responses from "Attendees" flow to the "Organizer", 469 making it easy to separate a calendar user organizing a meeting from 470 calendar users attending the meeting. Additionally, iCalendar 471 provides descriptive roles for each "Attendee". For instance, a role 472 of "chair" may be ascribed to one or more "Attendees". The "chair" 473 and the "Organizer" may or may not be the same calendar user. This 474 maps well to scenarios where an assistant may manage meeting 475 logistics for another individual who chairs a meeting. 477 Second, a "SENT-BY" parameter may be specified in either the 478 "Organizer" or "Attendee" properties. When specified, the "SENT-BY" 479 parameter indicates that the responding CU acted on behalf of the 480 specified "Attendee" or "Organizer". 482 2.1.4. Component Revisions 484 The "SEQUENCE" property is used by the "Organizer" to indicate 485 revisions to the calendar component. When the "Organizer" makes 486 changes to one of the following properties, the sequence number MUST 487 be incremented: 489 o "DTSTART" 490 o "DTEND" 491 o "DURATION" 492 o "DUE" 493 o "RRULE" 494 o "RDATE" 495 o "EXDATE" 496 o "STATUS" 498 In addition, changes made by the "Organizer" to other properties MAY 499 also require the sequence number to be incremented. The "Organizer" 500 CUA MUST increment the sequence number whenever it makes changes to 501 properties in the calendar component that the "Organizer" deems will 502 jeopardize the validity of the participation status of the 503 "Attendees". For example, changing the location of a meeting from 504 one location to another distant location could effectively impact the 505 participation status of the "Attendees". 507 Depending on the "METHOD", the "SEQUENCE" property MUST follow these 508 rules in the context of iTIP: 510 o For the "PUBLISH" and "REQUEST" methods, the "SEQUENCE" property 511 value is incremented according to the rules stated above. 513 o The "SEQUENCE" property value MUST be incremented each time the 514 "Organizer" uses the "ADD" or "CANCEL" methods. 516 o The "SEQUENCE" property value MUST NOT be incremented when using 517 "REPLY", "REFRESH", "COUNTER", "DECLINECOUNTER", or when sending a 518 delegation "REQUEST". 520 In some circumstances the "Organizer" may not have received responses 521 to the final revision sent out. In this situation, the "Organizer" 522 may wish to send an update "REQUEST", and set "RSVP=TRUE" for all 523 "Attendees", so that current responses can be collected. 525 The value of the "SEQUENCE" property contained in a response from an 526 "Attendee" may not always match the "Organizer's" revision. 527 Implementations may choose to have the CUA indicate to the CU that 528 the response is to an iCalendar object that has been revised and 529 allow the CU to decide whether or not to accept the response. 531 Whilst a change in sequence number is indicative of a significant 532 change to a previously scheduled item, "Attendee" CUAs SHOULD NOT 533 rely solely on a change in sequence number as a means of detecting a 534 significant change. Instead CUAs SHOULD compare the old and new 535 versions of the calendar components and determine the exact nature of 536 the changes and make decisions, possibly based on calendar user 537 preferences, as to whether the user needs to be explicitly informed 538 of the change. 540 2.1.5. Message Sequencing 542 CUAs that handle the iTIP application protocol must often correlate a 543 component in a calendar store with a component received in the iTIP 544 message. For example, an event may be updated with a later revision 545 of the same event. To accomplish this, a CUA must correlate the 546 version of the event already in its calendar store with the version 547 sent in the iTIP message. In addition to this correlation, there are 548 several factors that can cause iTIP messages to arrive in an 549 unexpected order. That is, an "Organizer" could receive a reply to 550 an earlier revision of a component AFTER receiving a reply to a later 551 revision. 553 To maximize interoperability and to handle messages that arrive in an 554 unexpected order, use the following rules: 556 1. The primary key for referencing a particular iCalendar component 557 is the "UID" property value. To reference an instance of a 558 recurring component, the primary key is composed of the "UID" and 559 the "RECURRENCE-ID" properties. 561 2. The secondary key for referencing a component is the "SEQUENCE" 562 property value. For components where the "UID" and 563 "RECURRENCE-ID" property values are the same, the component with 564 the highest numeric value for the "SEQUENCE" property obsoletes 565 all other revisions of the component with lower values. 567 3. "Attendees" send "REPLY" messages to the "Organizer". For 568 replies where the "UID" and "RECURRENCE-ID" property values are 569 the same, the value of the "SEQUENCE" property indicates the 570 revision of the component to which the "Attendee" is replying. 571 The reply with the highest numeric value for the "SEQUENCE" 572 property obsoletes all other replies with lower values. 574 4. In situations where the "UID", "RECURRENCE-ID", and "SEQUENCE" 575 property values match, the "DTSTAMP" property is used as the tie- 576 breaker. The component with the latest "DTSTAMP" overrides all 577 others. Similarly, for "Attendee" responses where the "UID", 578 "RECURRENCE-ID", and "SEQUENCE" property values match, the 579 response with the latest "DTSTAMP" overrides all others. 581 Hence, CUAs will need to persist the following component properties 582 in order to correctly process iTIP messages: "UID", "RECURRENCE-ID", 583 "SEQUENCE", and "DTSTAMP". Furthermore, for each "ATTENDEE" property 584 of a component, "Organizer" CUAs will need to persist the "SEQUENCE" 585 and "DTSTAMP" property values associated with the "Attendee's" last 586 response, so that any earlier responses from an "Attendee" that are 587 received out of order (e.g., due to a delay in the transport) can be 588 correctly discarded. 590 3. Application Protocol Elements 592 iTIP messages are "text/calendar" MIME entities that contain 593 calendaring and scheduling information. The particular type of 594 iCalendar message is referred to as the "method type". Each method 595 type is identified by a "METHOD" property specified as part of the 596 "text/calendar" content type. The table below shows various 597 combinations of calendar components and the method types that this 598 specification supports. 600 +----------------+--------+-------+----------+-----------+ 601 | | VEVENT | VTODO | VJOURNAL | VFREEBUSY | 602 +----------------+--------+-------+----------+-----------+ 603 | PUBLISH | Yes | Yes | Yes | Yes | 604 | REQUEST | Yes | Yes | No | Yes | 605 | REFRESH | Yes | Yes | No | No | 606 | CANCEL | Yes | Yes | Yes | No | 607 | ADD | Yes | Yes | Yes | No | 608 | REPLY | Yes | Yes | No | Yes | 609 | COUNTER | Yes | Yes | No | No | 610 | DECLINECOUNTER | Yes | Yes | No | No | 611 +----------------+--------+-------+----------+-----------+ 613 Each method type is defined in terms of its associated components and 614 properties. Some components and properties are required, some are 615 optional and others are excluded. The restrictions are expressed in 616 this document using a simple "restriction table". The first column 617 indicates the name of a component or property. Properties of the 618 iCalendar object are not indented. Properties of a component are 619 indented. The second column (the "Presence" column) indicates 620 whether a component or property should be present or not, and if 621 present how many times it can occur. The third column contains 622 comments for further clarification. 624 The presence column uses the following values to assert whether a 625 property is required, is optional and the number of times it may 626 appear in the iCalendar object. 628 +----------------+--------------------------------------------------+ 629 | Presence Value | Description | 630 +----------------+--------------------------------------------------+ 631 | 1 | One instance MUST be present | 632 | 1+ | At least one instance MUST be present | 633 | 0 | Instances of this property MUST NOT be present | 634 | 0+ | Multiple instances MAY be present | 635 | 0 or 1 | Up to 1 instance of this property MAY be present | 636 +----------------+--------------------------------------------------+ 638 The tables also call out "IANA-PROPERTY", "X-PROPERTY", "IANA- 639 COMPONENT" and "X-COMPONENT" to show where registered and vendor- 640 specific property and component extensions can appear. The tables do 641 not lay out the restrictions of property parameters. Those 642 restrictions are defined in [RFC5545]. 644 3.1. Common Component Restriction Tables 646 3.1.1. VCALENDAR 648 The restriction table below applies to properties of the iCalendar 649 object. That is, the properties at the outermost scope. 651 +-----------------------------------------------------+ 652 | Constraints for properties in a VCALENDAR Component | 653 +-----------------------------------------------------+ 655 +--------------------+----------+---------------------+ 656 | Component/Property | Presence | Comment | 657 +--------------------+----------+---------------------+ 658 | CALSCALE | 0 or 1 | | 659 | PRODID | 1 | | 660 | VERSION | 1 | Value MUST be "2.0" | 661 | IANA-PROPERTY | 0+ | | 662 | X-PROPERTY | 0+ | | 663 +--------------------+----------+---------------------+ 665 3.1.2. VTIMEZONE 667 "VTIMEZONE" components may be referred to by other components via a 668 "TZID" parameter on a "DATETIME" value type. The property 669 restrictions in the table below apply to any "VTIMEZONE" component in 670 an iTIP message. 672 +--------------------------------------+ 673 | Constraints for VTIMEZONE Components | 674 +--------------------------------------+ 676 +--------------------+----------+-----------------------------------+ 677 | Component/Property | Presence | Comment | 678 +--------------------+----------+-----------------------------------+ 679 | VTIMEZONE | 0+ | MUST be present if any date/time | 680 | | | refers to timezone | 681 | DAYLIGHT | 0+ | MUST be one or more of either | 682 | | | STANDARD or DAYLIGHT | 683 | COMMENT | 0+ | | 684 | DTSTART | 1 | MUST be local time format | 685 | RDATE | 0+ | | 686 | RRULE | 0 or 1 | | 687 | TZNAME | 0+ | | 688 | TZOFFSETFROM | 1 | | 689 | TZOFFSETTO | 1 | | 690 | IANA-PROPERTY | 0+ | | 691 | X-PROPERTY | 0+ | | 692 | LAST-MODIFIED | 0 or 1 | | 693 | STANDARD | 0+ | MUST be one or more of either | 694 | | | STANDARD or DAYLIGHT | 695 | COMMENT | 0+ | | 696 | DTSTART | 1 | MUST be local time format | 697 | RDATE | 0+ | if present RRULE MUST NOT be | 698 | | | present | 699 | RRULE | 0 or 1 | if present RDATE MUST NOT be | 700 | | | present | 701 | TZNAME | 0+ | | 702 | TZOFFSETFROM | 1 | | 703 | TZOFFSETTO | 1 | | 704 | IANA-PROPERTY | 0+ | | 705 | X-PROPERTY | 0+ | | 706 | TZID | 1 | | 707 | TZURL | 0 or 1 | | 708 | IANA-PROPERTY | 0+ | | 709 | X-PROPERTY | 0+ | | 710 +--------------------+----------+-----------------------------------+ 712 3.1.3. VALARM 714 The property restrictions in the table below apply to any "VALARM" 715 component in an iTIP message. 717 +-----------------------------------+ 718 | Constraints for VALARM Components | 719 +-----------------------------------+ 721 +--------------------+----------+-----------------------------------+ 722 | Component/Property | Presence | Comment | 723 +--------------------+----------+-----------------------------------+ 724 | VALARM | 0+ | | 725 | ACTION | 1 | | 726 | ATTACH | 0+ | | 727 | ATTENDEE | 0+ | | 728 | DESCRIPTION | 0 or 1 | | 729 | DURATION | 0 or 1 | if present REPEAT MUST be present | 730 | REPEAT | 0 or 1 | if present DURATION MUST be | 731 | | | present | 732 | SUMMARY | 0 or 1 | | 733 | TRIGGER | 1 | | 734 | IANA-PROPERTY | 0+ | | 735 | X-PROPERTY | 0+ | | 736 +--------------------+----------+-----------------------------------+ 738 3.2. Methods for VEVENT Calendar Components 740 This section defines the property set restrictions for the method 741 types that are applicable to the "VEVENT" calendar component. Each 742 method is defined using a table that clarifies the property 743 constraints that define the particular method. 745 The following summarizes the methods that are defined for the 746 "VEVENT" calendar component. 748 +----------------+--------------------------------------------------+ 749 | Method | Description | 750 +----------------+--------------------------------------------------+ 751 | PUBLISH | Post notification of an event. Used primarily | 752 | | as a method of advertising the existence of an | 753 | | event. | 754 | | | 755 | REQUEST | Make a request for an event. This is an | 756 | | explicit invitation to one or more "Attendees". | 757 | | Event requests are also used to update or change | 758 | | an existing event. Clients that cannot handle | 759 | | REQUEST MAY degrade the event to view it as an | 760 | | PUBLISH. | 761 | | | 762 | REPLY | Reply to an event request. Clients may set | 763 | | their status ("PARTSTAT") to ACCEPTED, DECLINED, | 764 | | TENTATIVE, or DELEGATED. | 765 | | | 766 | ADD | Add one or more instances to an existing event. | 767 | | | 768 | CANCEL | Cancel one or more instances of an existing | 769 | | event. | 770 | | | 771 | REFRESH | A request is sent to an "Organizer" by an | 772 | | "Attendee" asking for the latest version of an | 773 | | event to be resent to the requester. | 774 | | | 775 | COUNTER | Counter a REQUEST with an alternative proposal, | 776 | | Sent by an "Attendee" to the "Organizer". | 777 | | | 778 | DECLINECOUNTER | Decline a counter proposal. Sent to an | 779 | | "Attendee" by the "Organizer". | 780 +----------------+--------------------------------------------------+ 782 3.2.1. PUBLISH 784 The "PUBLISH" method in a "VEVENT" calendar component is an 785 unsolicited posting of an iCalendar object. Any CU may add published 786 components to their calendar. The "Organizer" MUST be present in a 787 published iCalendar component. "Attendees" MUST NOT be present. Its 788 expected usage is for encapsulating an arbitrary event as an 789 iCalendar object. The "Organizer" may subsequently update (with 790 another "PUBLISH" method), add instances to (with an "ADD" method), 791 or cancel (with a "CANCEL" method) a previously published "VEVENT" 792 calendar component. 794 This method type is an iCalendar object that conforms to the 795 following property constraints: 797 +----------------------------------------------+ 798 | Constraints for a METHOD:PUBLISH of a VEVENT | 799 +----------------------------------------------+ 801 +--------------------+----------+-----------------------------------+ 802 | Component/Property | Presence | Comment | 803 +--------------------+----------+-----------------------------------+ 804 | METHOD | 1 | MUST equal "PUBLISH" | 805 | | | | 806 | VEVENT | 1+ | | 807 | DTSTAMP | 1 | | 808 | DTSTART | 1 | | 809 | ORGANIZER | 1 | | 810 | SUMMARY | 1 | Can be null. | 811 | UID | 1 | | 812 | RECURRENCE-ID | 0 or 1 | Only if referring to an instance | 813 | | | of a recurring calendar | 814 | | | component. Otherwise it MUST NOT | 815 | | | be present. | 816 | SEQUENCE | 0 or 1 | MUST be present if value is | 817 | | | greater than 0, MAY be present if | 818 | | | 0 | 819 | ATTACH | 0+ | | 820 | CATEGORIES | 0+ | | 821 | CLASS | 0 or 1 | | 822 | COMMENT | 0+ | | 823 | CONTACT | 0 or 1 | | 824 | CREATED | 0 or 1 | | 825 | DESCRIPTION | 0 or 1 | Can be null | 826 | DTEND | 0 or 1 | If present DURATION MUST NOT be | 827 | | | present | 828 | DURATION | 0 or 1 | If present DTEND MUST NOT be | 829 | | | present | 830 | EXDATE | 0+ | | 831 | GEO | 0 or 1 | | 832 | LAST-MODIFIED | 0 or 1 | | 833 | LOCATION | 0 or 1 | | 834 | PRIORITY | 0 or 1 | | 835 | RDATE | 0+ | | 836 | RELATED-TO | 0+ | | 837 | RESOURCES | 0+ | | 838 | RRULE | 0 or 1 | | 839 | STATUS | 0 or 1 | MAY be one of | 840 | | | TENTATIVE/CONFIRMED/CANCELLED | 841 | TRANSP | 0 or 1 | | 842 | URL | 0 or 1 | | 843 | IANA-PROPERTY | 0+ | | 844 | X-PROPERTY | 0+ | | 845 | ATTENDEE | 0 | | 846 | REQUEST-STATUS | 0 | | 847 | | | | 848 | VALARM | 0+ | | 849 | | | | 850 | VFREEBUSY | 0 | | 851 | | | | 852 | VJOURNAL | 0 | | 853 | | | | 854 | VTODO | 0 | | 855 | | | | 856 | VTIMEZONE | 0+ | MUST be present if any date/time | 857 | | | refers to a timezone | 858 | | | | 859 | IANA-COMPONENT | 0+ | | 860 | X-COMPONENT | 0+ | | 861 +--------------------+----------+-----------------------------------+ 863 3.2.2. REQUEST 865 The "REQUEST" method in a "VEVENT" component provides the following 866 scheduling functions: 868 o Invite "Attendees" to an event 869 o Reschedule an existing event 870 o Response to a REFRESH request 871 o Update the details of an existing event, without rescheduling it 872 o Update the status of "Attendees" of an existing event, without 873 rescheduling it 874 o Reconfirm an existing event, without rescheduling it 875 o Forward a "VEVENT" to another uninvited CU 876 o For an existing "VEVENT" calendar component, delegate the role of 877 "Attendee" to another CU 878 o For an existing "VEVENT" calendar component, changing the role of 879 "Organizer" to another CU 881 The "Organizer" originates the "REQUEST". The recipients of the 882 "REQUEST" method are the CUs invited to the event, the "Attendees". 883 "Attendees" use the "REPLY" method to convey attendance status to the 884 "Organizer". 886 The "UID" and "SEQUENCE" properties are used to distinguish the 887 various uses of the "REQUEST" method. If the "UID" property value in 888 the "REQUEST" is not found on the recipient's calendar, then the 889 "REQUEST" is for a new "VEVENT" calendar component. If the "UID" 890 property value is found on the recipient's calendar, then the 891 "REQUEST" is for a rescheduling, an update, or a reconfirm of the 892 "VEVENT" calendar component. 894 For the "REQUEST" method, multiple "VEVENT" components in a single 895 iCalendar object are only permitted when for components with the same 896 "UID" property. That is, a series of recurring events may have 897 instance-specific information. In this case, multiple "VEVENT" 898 components are needed to express the entire series. 900 This method type is an iCalendar object that conforms to the 901 following property constraints: 903 +----------------------------------------------+ 904 | Constraints for a METHOD:REQUEST of a VEVENT | 905 +----------------------------------------------+ 907 +--------------------+----------+-----------------------------------+ 908 | Component/Property | Presence | Comment | 909 +--------------------+----------+-----------------------------------+ 910 | METHOD | 1 | MUST be "REQUEST" | 911 | | | | 912 | VEVENT | 1+ | All components MUST have the same | 913 | | | UID | 914 | ATTENDEE | 1+ | | 915 | DTSTAMP | 1 | | 916 | DTSTART | 1 | | 917 | ORGANIZER | 1 | | 918 | SEQUENCE | 0 or 1 | MUST be present if value is | 919 | | | greater than 0, MAY be present if | 920 | | | 0 | 921 | SUMMARY | 1 | Can be null | 922 | UID | 1 | | 923 | ATTACH | 0+ | | 924 | CATEGORIES | 0+ | | 925 | CLASS | 0 or 1 | | 926 | COMMENT | 0+ | | 927 | CONTACT | 0+ | | 928 | CREATED | 0 or 1 | | 929 | DESCRIPTION | 0 or 1 | Can be null | 930 | DTEND | 0 or 1 | if present DURATION MUST NOT be | 931 | | | present | 932 | DURATION | 0 or 1 | if present DTEND MUST NOT be | 933 | | | present | 934 | EXDATE | 0+ | | 935 | GEO | 0 or 1 | | 936 | LAST-MODIFIED | 0 or 1 | | 937 | LOCATION | 0 or 1 | | 938 | PRIORITY | 0 or 1 | | 939 | RDATE | 0+ | | 940 | RECURRENCE-ID | 0 or 1 | Only if referring to an instance | 941 | | | of a recurring calendar | 942 | | | component. Otherwise it MUST NOT | 943 | | | be present. | 944 | RELATED-TO | 0+ | | 945 | REQUEST-STATUS | 0 | | 946 | RESOURCES | 0+ | | 947 | RRULE | 0 or 1 | | 948 | STATUS | 0 or 1 | MAY be one of TENTATIVE/CONFIRMED | 949 | TRANSP | 0 or 1 | | 950 | URL | 0 or 1 | | 951 | IANA-PROPERTY | 0+ | | 952 | X-PROPERTY | 0+ | | 953 | | | | 954 | VALARM | 0+ | | 955 | | | | 956 | VTIMEZONE | 0+ | MUST be present if any date/time | 957 | | | refers to a timezone | 958 | | | | 959 | IANA-COMPONENT | 0+ | | 960 | X-COMPONENT | 0+ | | 961 | | | | 962 | VFREEBUSY | 0 | | 963 | | | | 964 | VJOURNAL | 0 | | 965 | | | | 966 | VTODO | 0 | | 967 +--------------------+----------+-----------------------------------+ 969 3.2.2.1. Rescheduling an Event 971 The "REQUEST" method may be used to reschedule an event. A 972 rescheduled event involves a change to the existing event in terms of 973 its time or recurrence intervals and possibly the location or 974 description. If the recipient CUA of a "REQUEST" method finds that 975 the "UID" property value already exists on the calendar, but that the 976 "SEQUENCE" (or "DTSTAMP") property value in the "REQUEST" method is 977 greater than the value for the existing event, then the "REQUEST" 978 method describes a rescheduling of the event. 980 3.2.2.2. Updating or Reconfirmation of an Event 982 The "REQUEST" method may be used to update or reconfirm an event. An 983 update to an existing event does not involve changes to the time or 984 recurrence intervals, and might not involve a change to the location 985 or description for the event. If the recipient CUA of a "REQUEST" 986 method finds that the "UID" property value already exists on the 987 calendar and that the "SEQUENCE" property value in the "REQUEST" is 988 the same as the value for the existing event, then the "REQUEST" 989 method describes an update of the event details, but no rescheduling 990 of the event. 992 The update "REQUEST" method is the appropriate response to a 993 "REFRESH" method sent from an "Attendee" to the "Organizer" of an 994 event. 996 The "Organizer" of an event may also send unsolicited "REQUEST" 997 methods. The unsolicited "REQUEST" methods may be used to update the 998 details of the event without rescheduling it, to update the 999 "PARTSTAT" parameter of "Attendees", or to reconfirm the event. 1001 3.2.2.3. Delegating an Event to another CU 1003 Some calendar and scheduling systems allow "Attendees" to delegate 1004 their presence at an event to another calendar user. iTIP supports 1005 this concept using the following workflow. Any "Attendee" may 1006 delegate their right to participate in a calendar VEVENT to another 1007 CU. The implication is that the delegate participates in lieu of the 1008 original "Attendee"; NOT in addition to the "Attendee". The 1009 delegator MUST notify the "Organizer" of this action using the steps 1010 outlined below. Implementations may support or restrict delegation 1011 as they see fit. For instance, some implementations may restrict a 1012 delegate from delegating a "REQUEST" to another CU. 1014 The "Delegator" of an event forwards the existing "REQUEST" to the 1015 "Delegate". The "REQUEST" method MUST include an "ATTENDEE" property 1016 with the calendar address of the "Delegate". The "Delegator" MUST 1017 also send a "REPLY" method to the "Organizer" with the "Delegator's" 1018 "ATTENDEE" property "PARTSTAT" parameter value set to "DELEGATED". 1019 In addition, the "DELEGATED-TO" parameter MUST be included with the 1020 calendar address of the "Delegate". Also, a new "ATTENDEE" property 1021 for the "Delegate" MUST be included and must specify the calendar 1022 user address set in the "DELEGATED-TO" parameter, as above. 1024 In response to the request, the "Delegate" MUST send a "REPLY" method 1025 to the "Organizer" and optionally, to the "Delegator". The "REPLY" 1026 method SHOULD include the "ATTENDEE" property with the "DELEGATED- 1027 FROM" parameter value of the "Delegator's" calendar address. 1029 The "Delegator" may continue to receive updates to the event even 1030 though they will not be attending. This is accomplished by the 1031 "Delegator" setting their "role" attribute to "NON-PARTICIPANT" in 1032 the "REPLY" to the "Organizer" 1034 3.2.2.4. Changing the Organizer 1036 The situation may arise where the "Organizer" of a VEVENT is no 1037 longer able to perform the "Organizer" role and abdicates without 1038 passing on the "Organizer" role to someone else. When this occurs 1039 the "Attendees" of the VEVENT may use out-of-band mechanisms to 1040 communicate the situation and agree upon a new "Organizer". The new 1041 "Organizer" should then send out a new "REQUEST" with a modified 1042 version of the VEVENT in which the "SEQUENCE" number has been 1043 incremented and the "ORGANIZER" property has been changed to the new 1044 "Organizer". 1046 3.2.2.5. Sending on Behalf of the Organizer 1048 There are a number of scenarios that support the need for a calendar 1049 user to act on behalf of the "Organizer" without explicit role 1050 changing. This might be the case if the CU designated as "Organizer" 1051 was sick or unable to perform duties associated with that function. 1052 In these cases iTIP supports the notion of one CU acting on behalf of 1053 another. Using the "SENT-BY" parameter, a calendar user could send 1054 an updated "VEVENT" REQUEST. In the case where one CU sends on 1055 behalf of another CU, the "Attendee" responses are still directed 1056 back towards the CU designated as "Organizer". 1058 3.2.2.6. Forwarding to An Uninvited CU 1060 An "Attendee" invited to a "VEVENT" calendar component may send the 1061 "VEVENT" calendar component to another new CU, not previously 1062 associated with the "VEVENT" calendar component. The current 1063 "Attendee" invited to the "VEVENT" calendar component does this by 1064 forwarding the original "REQUEST" method to the new CU. The new CU 1065 can send a "REPLY" to the "Organizer" of the "VEVENT" calendar 1066 component. The reply contains an "ATTENDEE" property for the new CU. 1068 The "Organizer" ultimately decides whether or not the new CU becomes 1069 part of the event and is not obligated to do anything with a "REPLY" 1070 from a new (uninvited) CU. If the "Organizer" does not want the new 1071 CU to be part of the event, the new "ATTENDEE" property is not added 1072 to the "VEVENT" calendar component. The "Organizer" MAY send the CU 1073 a "CANCEL" message to indicate that they will not be added to the 1074 event. If the "Organizer" decides to add the new CU, the new 1075 "ATTENDEE" property is added to the "VEVENT" calendar component. 1076 Furthermore, the "Organizer" is free to change any "ATTENDEE" 1077 property parameter from the values supplied by the new CU to 1078 something the "Organizer" considers appropriate. The "Organizer" 1079 SHOULD send the new CU a "REQUEST" message to inform them that they 1080 have been added. 1082 When forwarding a "REQUEST" to another CU, the forwarding "Attendee" 1083 MUST NOT make changes to the original message. 1085 3.2.2.7. Updating Attendee Status 1087 The "Organizer" of an event may also request updated status from one 1088 or more "Attendees. The "Organizer" sends a "REQUEST" method to the 1089 "Attendee" and sets the "ATTENDEE;RSVP=TRUE" property parameter. The 1090 "SEQUENCE" property for the event is not changed from its previous 1091 value. A recipient will determine that the only change in the 1092 "REQUEST" is that their "RSVP" property parameter indicates a request 1093 for updated status. The recipient SHOULD respond with a "REPLY" 1094 method indicating their current status with respect to the "REQUEST". 1096 3.2.3. REPLY 1098 The "REPLY" method in a "VEVENT" calendar component is used to 1099 respond (e.g., accept or decline) to a "REQUEST" or to reply to a 1100 delegation "REQUEST". When used to provide a delegation response, 1101 the "Delegator" SHOULD include the calendar address of the "Delegate" 1102 on the "DELEGATED-TO" property parameter of the "Delegator's" 1103 "ATTENDEE" property. The "Delegate" SHOULD include the calendar 1104 address of the "Delegator" on the "DELEGATED-FROM" property parameter 1105 of the "Delegate's" "ATTENDEE" property. 1107 The "REPLY" method is also used when processing of a "REQUEST" fails. 1108 Depending on the value of the "REQUEST-STATUS" property no scheduling 1109 action may have been performed. 1111 The "Organizer" of an event may receive the "REPLY" method from a CU 1112 not in the original "REQUEST". For example, a "REPLY" may be 1113 received from a "Delegate" to an event. In addition, the "REPLY" 1114 method may be received from an unknown CU (a "Party Crasher"). This 1115 uninvited "Attendee" may be accepted, or the "Organizer" may cancel 1116 the event for the uninvited "Attendee" by sending a "CANCEL" method 1117 to the uninvited "Attendee". 1119 An "Attendee" MAY include a message to the "Organizer" using the 1120 "COMMENT" property. For example, if the user indicates tentative 1121 acceptance and wants to let the "Organizer" know why, the reason can 1122 be expressed in the "COMMENT" property value. 1124 The "Organizer" may also receive a "REPLY" from one CU on behalf of 1125 another. Like the scenario enumerated above for the "Organizer", 1126 "Attendees" may have another CU respond on their behalf. This is 1127 done using the "SENT-BY" parameter. 1129 The optional properties listed in the table below (those listed as 1130 "0+" or "0 or 1") MUST NOT be changed from those of the original 1131 request. If property changes are desired the COUNTER message must be 1132 used. 1134 This method type is an iCalendar object that conforms to the 1135 following property constraints: 1137 +--------------------------------------------+ 1138 | Constraints for a METHOD:REPLY of a VEVENT | 1139 +--------------------------------------------+ 1141 +--------------------+----------+-----------------------------------+ 1142 | Component/Property | Presence | Comment | 1143 +--------------------+----------+-----------------------------------+ 1144 | METHOD | 1 | MUST be "REPLY" | 1145 | | | | 1146 | VEVENT | 1+ | All components MUST have the same | 1147 | | | UID | 1148 | ATTENDEE | 1 | MUST be the address of the | 1149 | | | Attendee replying. | 1150 | DTSTAMP | 1 | | 1151 | ORGANIZER | 1 | | 1152 | RECURRENCE-ID | 0 or 1 | Only if referring to an instance | 1153 | | | of a recurring calendar | 1154 | | | component. Otherwise it MUST NOT | 1155 | | | be present. | 1156 | UID | 1 | MUST be the UID of the original | 1157 | | | REQUEST | 1158 | SEQUENCE | 0 or 1 | MUST if non-zero, MUST be the | 1159 | | | sequence number of the original | 1160 | | | REQUEST. MAY be present if 0. | 1161 | ATTACH | 0+ | | 1162 | CATEGORIES | 0+ | | 1163 | CLASS | 0 or 1 | | 1164 | COMMENT | 0+ | | 1165 | CONTACT | 0+ | | 1166 | CREATED | 0 or 1 | | 1167 | DESCRIPTION | 0 or 1 | | 1168 | DTEND | 0 or 1 | if present DURATION MUST NOT be | 1169 | | | present | 1170 | DTSTART | 0 or 1 | | 1171 | DURATION | 0 or 1 | if present DTEND MUST NOT be | 1172 | | | present | 1173 | EXDATE | 0+ | | 1174 | GEO | 0 or 1 | | 1175 | LAST-MODIFIED | 0 or 1 | | 1176 | LOCATION | 0 or 1 | | 1177 | PRIORITY | 0 or 1 | | 1178 | RDATE | 0+ | | 1179 | RELATED-TO | 0+ | | 1180 | RESOURCES | 0+ | | 1181 | REQUEST-STATUS | 0+ | | 1182 | RRULE | 0 or 1 | | 1183 | STATUS | 0 or 1 | | 1184 | SUMMARY | 0 or 1 | | 1185 | TRANSP | 0 or 1 | | 1186 | URL | 0 or 1 | | 1187 | IANA-PROPERTY | 0+ | | 1188 | X-PROPERTY | 0+ | | 1189 | | | | 1190 | VALARM | 0 | | 1191 | | | | 1192 | VTIMEZONE | 0 or 1 | MUST be present if any date/time | 1193 | | | refers to a timezone | 1194 | | | | 1195 | IANA-COMPONENT | 0+ | | 1196 | X-COMPONENT | 0+ | | 1197 | | | | 1198 | VFREEBUSY | 0 | | 1199 | | | | 1200 | VJOURNAL | 0 | | 1201 | | | | 1202 | VTODO | 0 | | 1203 +--------------------+----------+-----------------------------------+ 1205 3.2.4. ADD 1207 The "ADD" method allows the "Organizer" to add one or more new 1208 instances to an existing "VEVENT" using a single iTIP message without 1209 having to send the entire "VEVENT" with all the existing instance 1210 data, as it would have to do if the "REQUEST" method were used. 1212 The "UID" must be that of the existing event. If the "UID" property 1213 value in the "ADD" is not found on the recipient's calendar, then the 1214 recipient SHOULD send a "REFRESH" to the "Organizer" in order to be 1215 updated with the latest version of the "VEVENT". If an "Attendee" 1216 implementation does not support the "ADD" method it should respond 1217 with a "REQUEST-STATUS" value of 3.14 and ask for a "REFRESH". 1219 When handling an "ADD" message, the "Attendee" treats each component 1220 in the "ADD" message as if it were referenced via an "RDATE"in the 1221 main component. 1223 This method type is an iCalendar object that conforms to the 1224 following property constraints: 1226 +------------------------------------------+ 1227 | Constraints for a METHOD:ADD of a VEVENT | 1228 +------------------------------------------+ 1230 +--------------------+----------+-----------------------------------+ 1231 | Component/Property | Presence | Comment | 1232 +--------------------+----------+-----------------------------------+ 1233 | METHOD | 1 | MUST be "ADD" | 1234 | | | | 1235 | VEVENT | 1 | | 1236 | DTSTAMP | 1 | | 1237 | DTSTART | 1 | | 1238 | ORGANIZER | 1 | | 1239 | SEQUENCE | 1 | MUST be greater than 0 | 1240 | SUMMARY | 1 | Can be null | 1241 | UID | 1 | MUST match that of the original | 1242 | | | event | 1243 | ATTACH | 0+ | | 1244 | ATTENDEE | 0+ | | 1245 | CATEGORIES | 0+ | | 1246 | CLASS | 0 or 1 | | 1247 | COMMENT | 0+ | | 1248 | CONTACT | 0+ | | 1249 | CREATED | 0 or 1 | | 1250 | DESCRIPTION | 0 or 1 | Can be null | 1251 | DTEND | 0 or 1 | if present DURATION MUST NOT be | 1252 | | | present | 1253 | DURATION | 0 or 1 | if present DTEND MUST NOT be | 1254 | | | present | 1255 | GEO | 0 or 1 | | 1256 | LAST-MODIFIED | 0 or 1 | | 1257 | LOCATION | 0 or 1 | | 1258 | PRIORITY | 0 or 1 | | 1259 | RELATED-TO | 0+ | | 1260 | RESOURCES | 0+ | | 1261 | STATUS | 0 or 1 | MAY be one of TENTATIVE/CONFIRMED | 1262 | TRANSP | 0 or 1 | | 1263 | URL | 0 or 1 | | 1264 | IANA-PROPERTY | 0+ | | 1265 | X-PROPERTY | 0+ | | 1266 | EXDATE | 0 | | 1267 | RECURRENCE-ID | 0 | | 1268 | REQUEST-STATUS | 0 | | 1269 | RDATE | 0 | | 1270 | RRULE | 0 | | 1271 | | | | 1272 | VALARM | 0+ | | 1273 | | | | 1274 | VTIMEZONE | 0+ | MUST be present if any date/time | 1275 | | | refers to a timezone | 1276 | | | | 1277 | IANA-COMPONENT | 0+ | | 1278 | X-COMPONENT | 0+ | | 1279 | | | | 1280 | VFREEBUSY | 0 | | 1281 | | | | 1282 | VTODO | 0 | | 1283 | | | | 1284 | VJOURNAL | 0 | | 1285 +--------------------+----------+-----------------------------------+ 1287 3.2.5. CANCEL 1289 The "CANCEL" method in a "VEVENT" calendar component is used to send 1290 a cancellation notice of an existing event request to the affected 1291 "Attendees". The message is sent by the "Organizer" of the event. 1292 For a recurring event, either the whole event or instances of an 1293 event may be cancelled. To cancel the complete range of recurring 1294 event, the "UID" property value for the event MUST be specified and a 1295 "RECURRENCE-ID" MUST NOT be specified in the "CANCEL" method. In 1296 order to cancel an individual instance of the event, the 1297 "RECURRENCE-ID" property value for the event MUST be specified in the 1298 "CANCEL" method. 1300 There are two options for canceling a sequence of instances of a 1301 recurring "VEVENT" calendar component: 1303 a. the "RECURRENCE-ID" property for an instance in the sequence MUST 1304 be specified with the "RANGE" property parameter value of 1305 "THISANDFUTURE" to indicate cancellation of the specified 1306 "VEVENT" calendar component and all instances after; or 1307 b. individual recurrence instances may be cancelled by specifying 1308 multiple "VEVENT" components each with a "RECURRENCE-ID" property 1309 corresponding to one of the instances to be cancelled. 1311 The "Organizer" MUST send a "CANCEL" message to each "Attendee" 1312 affected by the cancellation. This can be done using a single 1313 "CANCEL" message for all "Attendees", or multiple messages with 1314 different subsets of the affected "Attendees" in each. 1316 When a "VEVENT" is cancelled, the "SEQUENCE" property value MUST be 1317 incremented as described in Section 2.1.4. 1319 This method type is an iCalendar object that conforms to the 1320 following property constraints: 1322 +---------------------------------------------+ 1323 | Constraints for a METHOD:CANCEL of a VEVENT | 1324 +---------------------------------------------+ 1326 +--------------------+----------+-----------------------------------+ 1327 | Component/Property | Presence | Comment | 1328 +--------------------+----------+-----------------------------------+ 1329 | METHOD | 1 | MUST be "CANCEL" | 1330 | | | | 1331 | VEVENT | 1+ | All must have the same UID | 1332 | ATTENDEE | 0+ | MUST include some or all | 1333 | | | "Attendees" being removed from | 1334 | | | the event. MUST include some or | 1335 | | | all "Attendees" if the entire | 1336 | | | event is cancelled. | 1337 | DTSTAMP | 1 | | 1338 | ORGANIZER | 1 | | 1339 | SEQUENCE | 1 | | 1340 | UID | 1 | MUST be the UID of the original | 1341 | | | REQUEST | 1342 | COMMENT | 0+ | | 1343 | ATTACH | 0+ | | 1344 | CATEGORIES | 0+ | | 1345 | CLASS | 0 or 1 | | 1346 | CONTACT | 0+ | | 1347 | CREATED | 0 or 1 | | 1348 | DESCRIPTION | 0 or 1 | | 1349 | DTEND | 0 or 1 | if present DURATION MUST NOT be | 1350 | | | present | 1351 | DTSTART | 0 or 1 | | 1352 | DURATION | 0 or 1 | if present DTEND MUST NOT be | 1353 | | | present | 1354 | EXDATE | 0+ | | 1355 | GEO | 0 or 1 | | 1356 | LAST-MODIFIED | 0 or 1 | | 1357 | LOCATION | 0 or 1 | | 1358 | PRIORITY | 0 or 1 | | 1359 | RDATE | 0+ | | 1360 | RECURRENCE-ID | 0 or 1 | Only if referring to an instance | 1361 | | | of a recurring calendar | 1362 | | | component. Otherwise it MUST NOT | 1363 | | | be present. | 1364 | RELATED-TO | 0+ | | 1365 | RESOURCES | 0+ | | 1366 | RRULE | 0 or 1 | | 1367 | STATUS | 0 or 1 | MUST be set to CANCELLED to | 1368 | | | cancel the entire event. If | 1369 | | | uninviting specific "Attendees" | 1370 | | | then MUST NOT be included. | 1371 | SUMMARY | 0 or 1 | | 1372 | TRANSP | 0 or 1 | | 1373 | URL | 0 or 1 | | 1374 | IANA-PROPERTY | 0+ | | 1375 | X-PROPERTY | 0+ | | 1376 | REQUEST-STATUS | 0 | | 1377 | | | | 1378 | VALARM | 0 | | 1379 | | | | 1380 | VTIMEZONE | 0+ | MUST be present if any date/time | 1381 | | | refers to a timezone | 1382 | | | | 1383 | IANA-COMPONENT | 0+ | | 1384 | X-COMPONENT | 0+ | | 1385 | | | | 1386 | VTODO | 0 | | 1387 | | | | 1388 | VJOURNAL | 0 | | 1389 | | | | 1390 | VFREEBUSY | 0 | | 1391 +--------------------+----------+-----------------------------------+ 1393 3.2.6. REFRESH 1395 The "REFRESH" method in a "VEVENT" calendar component is used by 1396 "Attendees" of an existing event to request an updated description 1397 from the event "Organizer". The "REFRESH" method must specify the 1398 "UID" property of the event to update. A recurrence instance of an 1399 event may be requested by specifying the "RECURRENCE-ID" property 1400 corresponding to the associated event. The "Organizer" responds with 1401 the latest description and version of the event. 1403 This method type is an iCalendar object that conforms to the 1404 following property constraints: 1406 +----------------------------------------------+ 1407 | Constraints for a METHOD:REFRESH of a VEVENT | 1408 +----------------------------------------------+ 1410 +--------------------+----------+-----------------------------------+ 1411 | Component/Property | Presence | Comment | 1412 +--------------------+----------+-----------------------------------+ 1413 | METHOD | 1 | MUST be "REFRESH" | 1414 | | | | 1415 | VEVENT | 1 | | 1416 | ATTENDEE | 1 | MUST be the address of requester | 1417 | DTSTAMP | 1 | | 1418 | ORGANIZER | 1 | | 1419 | UID | 1 | MUST be the UID associated with | 1420 | | | original REQUEST | 1421 | COMMENT | 0+ | | 1422 | RECURRENCE-ID | 0 or 1 | Only if referring to an instance | 1423 | | | of a recurring calendar | 1424 | | | component. Otherwise it MUST NOT | 1425 | | | be present. | 1426 | IANA-PROPERTY | 0+ | | 1427 | X-PROPERTY | 0+ | | 1428 | ATTACH | 0 | | 1429 | CATEGORIES | 0 | | 1430 | CLASS | 0 | | 1431 | CONTACT | 0 | | 1432 | CREATED | 0 | | 1433 | DESCRIPTION | 0 | | 1434 | DTEND | 0 | | 1435 | DTSTART | 0 | | 1436 | DURATION | 0 | | 1437 | EXDATE | 0 | | 1438 | GEO | 0 | | 1439 | LAST-MODIFIED | 0 | | 1440 | LOCATION | 0 | | 1441 | PRIORITY | 0 | | 1442 | RDATE | 0 | | 1443 | RELATED-TO | 0 | | 1444 | REQUEST-STATUS | 0 | | 1445 | RESOURCES | 0 | | 1446 | RRULE | 0 | | 1447 | SEQUENCE | 0 | | 1448 | STATUS | 0 | | 1449 | SUMMARY | 0 | | 1450 | TRANSP | 0 | | 1451 | URL | 0 | | 1452 | | | | 1453 | VALARM | 0 | | 1454 | | | | 1455 | VTIMEZONE | 0+ | | 1456 | | | | 1457 | IANA-COMPONENT | 0+ | | 1458 | X-COMPONENT | 0+ | | 1459 | | | | 1460 | VTODO | 0 | | 1461 | | | | 1462 | VJOURNAL | 0 | | 1463 | | | | 1464 | VFREEBUSY | 0 | | 1465 +--------------------+----------+-----------------------------------+ 1467 3.2.7. COUNTER 1469 The "COUNTER" method for a "VEVENT" calendar component is used by an 1470 "Attendee" of an existing event to submit to the "Organizer" a 1471 counter proposal to the event. The "Attendee" sends this message to 1472 the "Organizer" of the event. 1474 The counter proposal is an iCalendar object consisting of a VEVENT 1475 calendar component describing the complete description of the 1476 alternate event. 1478 The "Organizer" rejects the counter proposal by sending the 1479 "Attendee" a "DECLINECOUNTER" method. The "Organizer" accepts the 1480 counter proposal by rescheduling the event as described in section 1481 3.2.2.1 Rescheduling an Event. The "Organizers" CUA SHOULD send a 1482 "REQUEST" message to all "Attendees" affected by any change triggered 1483 by an accepted "COUNTER". 1485 This method type is an iCalendar object that conforms to the 1486 following property constraints: 1488 +----------------------------------------------+ 1489 | Constraints for a METHOD:COUNTER of a VEVENT | 1490 +----------------------------------------------+ 1492 +--------------------+----------+-----------------------------------+ 1493 | Component/Property | Presence | Comment | 1494 +--------------------+----------+-----------------------------------+ 1495 | METHOD | 1 | MUST be "COUNTER" | 1496 | | | | 1497 | VEVENT | 1 | | 1498 | DTSTAMP | 1 | | 1499 | DTSTART | 1 | | 1500 | ORGANIZER | 1 | MUST be the "Organizer" of the | 1501 | | | original event | 1502 | SEQUENCE | 1 | MUST echo the original SEQUENCE | 1503 | | | number. MUST be present if | 1504 | | | non-zero. MAY be present if | 1505 | | | zero. | 1506 | SUMMARY | 1 | Can be null | 1507 | UID | 1 | MUST be the UID associated with | 1508 | | | the REQUEST being countered | 1509 | ATTACH | 0+ | | 1510 | ATTENDEE | 0+ | Can also be used to propose other | 1511 | | | "Attendees" | 1512 | CATEGORIES | 0+ | | 1513 | CLASS | 0 or 1 | | 1514 | COMMENT | 0+ | | 1515 | CONTACT | 0+ | | 1516 | CREATED | 0 or 1 | | 1517 | DESCRIPTION | 0 or 1 | | 1518 | DTEND | 0 or 1 | if present DURATION MUST NOT be | 1519 | | | present | 1520 | DURATION | 0 or 1 | if present DTEND MUST NOT be | 1521 | | | present | 1522 | EXDATE | 0+ | | 1523 | GEO | 0 or 1 | | 1524 | LAST-MODIFIED | 0 or 1 | | 1525 | LOCATION | 0 or 1 | | 1526 | PRIORITY | 0 or 1 | | 1527 | RDATE | 0+ | | 1528 | RECURRENCE-ID | 0 or 1 | Only if referring to an instance | 1529 | | | of a recurring calendar | 1530 | | | component. Otherwise it MUST NOT | 1531 | | | be present. | 1532 | RELATED-TO | 0+ | | 1533 | REQUEST-STATUS | 0+ | | 1534 | RESOURCES | 0+ | | 1535 | RRULE | 0 or 1 | | 1536 | STATUS | 0 or 1 | Value must be one of | 1537 | | | CONFIRMED/TENATIVE/CANCELLED | 1538 | TRANSP | 0 or 1 | | 1539 | URL | 0 or 1 | | 1540 | IANA-PROPERTY | 0+ | | 1541 | X-PROPERTY | 0+ | | 1542 | | | | 1543 | VALARM | 0+ | | 1544 | | | | 1545 | VTIMEZONE | 0+ | MUST be present if any date/time | 1546 | | | refers to a timezone | 1547 | | | | 1548 | IANA-COMPONENT | 0+ | | 1549 | X-COMPONENT | 0+ | | 1550 | | | | 1551 | VTODO | 0 | | 1552 | | | | 1553 | VJOURNAL | 0 | | 1554 | | | | 1555 | VFREEBUSY | 0 | | 1556 +--------------------+----------+-----------------------------------+ 1558 3.2.8. DECLINECOUNTER 1560 The "DECLINECOUNTER" method in a "VEVENT" calendar component is used 1561 by the "Organizer" of an event to reject a counter proposal submitted 1562 by an "Attendee". The "Organizer" must send the "DECLINECOUNTER" 1563 message to the "Attendee" that sent the "COUNTER" method to the 1564 "Organizer". 1566 This method type is an iCalendar object that conforms to the 1567 following property constraints: 1569 +-----------------------------------------------------+ 1570 | Constraints for a METHOD:DECLINECOUNTER of a VEVENT | 1571 +-----------------------------------------------------+ 1573 +--------------------+----------+-----------------------------------+ 1574 | Component/Property | Presence | Comment | 1575 +--------------------+----------+-----------------------------------+ 1576 | METHOD | 1 | MUST be "DECLINECOUNTER" | 1577 | | | | 1578 | VEVENT | 1+ | All components MUST have the same | 1579 | | | UID | 1580 | ATTENDEE | 1+ | MUST for all attendees | 1581 | DTSTAMP | 1 | | 1582 | ORGANIZER | 1 | | 1583 | SEQUENCE | 1 | MUST echo the original SEQUENCE | 1584 | | | number | 1585 | UID | 1 | MUST echo original UID | 1586 | ATTACH | 0+ | | 1587 | CATEGORIES | 0+ | | 1588 | CLASS | 0 or 1 | | 1589 | COMMENT | 0+ | | 1590 | CONTACT | 0+ | | 1591 | CREATED | 0 or 1 | | 1592 | DESCRIPTION | 0 or 1 | Can be null | 1593 | DTSTART | 0 or 1 | | 1594 | DTEND | 0 or 1 | if present DURATION MUST NOT be | 1595 | | | present | 1596 | DURATION | 0 or 1 | if present DTEND MUST NOT be | 1597 | | | present | 1598 | EXDATE | 0+ | | 1599 | GEO | 0 or 1 | | 1600 | LAST-MODIFIED | 0 or 1 | | 1601 | LOCATION | 0 or 1 | | 1602 | PRIORITY | 0 or 1 | | 1603 | RDATE | 0+ | | 1604 | RECURRENCE-ID | 0 or 1 | Only if referring to an instance | 1605 | | | of a recurring calendar | 1606 | | | component. Otherwise it MUST NOT | 1607 | | | be present. | 1608 | RELATED-TO | 0+ | | 1609 | REQUEST-STATUS | 0+ | | 1610 | RESOURCES | 0+ | | 1611 | RRULE | 0 or 1 | | 1612 | STATUS | 0 or 1 | MAY be one of TENTATIVE/CONFIRMED | 1613 | SUMMARY | 0 or 1 | Can be null | 1614 | TRANSP | 0 or 1 | | 1615 | URL | 0 or 1 | | 1616 | IANA-PROPERTY | 0+ | | 1617 | X-PROPERTY | 0+ | | 1618 | | | | 1619 | | | | 1620 | VTIMEZONE | 0+ | MUST be present if any date/time | 1621 | | | refers to a timezone | 1622 | | | | 1623 | IANA-COMPONENT | 0+ | | 1624 | X-COMPONENT | 0+ | | 1625 | | | | 1626 | VALARM | 0 | | 1627 | VFREEBUSY | 0 | | 1628 | | | | 1629 | VJOURNAL | 0 | | 1630 | | | | 1631 | VTODO | 0 | | 1632 +--------------------+----------+-----------------------------------+ 1634 3.3. Methods For VFREEBUSY Components 1636 This section defines the property set for the methods that are 1637 applicable to the "VFREEBUSY" calendar component. Each of the 1638 methods is defined using a restriction table. 1640 This document only addresses the transfer of busy time information. 1641 Applications desiring free time information MUST infer this from 1642 available busy time information. 1644 The "FREEBUSY" property value MAY include a list of values, separated 1645 by the COMMA character (US-ASCII decimal 44). Alternately, multiple 1646 busy time periods MAY be specified with multiple instances of the 1647 "FREEBUSY" property. Both forms MUST be supported by implementations 1648 conforming to this document. Duplicate busy time periods SHOULD NOT 1649 be specified in an iCalendar object. However, two different busy 1650 time periods MAY overlap. 1652 "FREEBUSY" properties SHOULD be sorted such that their values are in 1653 ascending order, based on the start time, and then the end time, with 1654 the earliest periods first. For example, today's busy time 1655 information should appear after yesterday's busy time information. 1656 And the busy time for this half-hour should appear after the busy 1657 time for earlier today. Busy time periods can also span a day 1658 boundary. 1660 The following summarizes the methods that are defined for the 1661 "VFREEBUSY" calendar component. 1663 +---------+-------------------------------------+ 1664 | Method | Description | 1665 +---------+-------------------------------------+ 1666 | PUBLISH | Publish unsolicited busy time data. | 1667 | | | 1668 | REQUEST | Request busy time data. | 1669 | | | 1670 | REPLY | Reply to a busy time request. | 1671 +---------+-------------------------------------+ 1673 3.3.1. PUBLISH 1675 The "PUBLISH" method in a "VFREEBUSY" calendar component is used to 1676 publish busy time data. The method may be sent from one CU to any 1677 other. The purpose of the method is to provide a way to send 1678 unsolicited busy time data. That is, the busy time data is not being 1679 sent as a "REPLY" to the receipt of a "REQUEST" method. 1681 The "ORGANIZER" property MUST be specified in the busy time 1682 information. The value is the CU address of the originator of the 1683 busy time information. 1685 The busy time information within the iCalendar object MAY be grouped 1686 into more than one "VFREEBUSY" calendar component. This capability 1687 allows busy time periods to be grouped according to some common 1688 periodicity, such as a calendar week, month, or year. In this case, 1689 each "VFREEBUSY" calendar component MUST include the "ORGANIZER", 1690 "DTSTART" and "DTEND" properties in order to specify the source of 1691 the busy time information and the date and time interval over which 1692 the busy time information covers. 1694 This method type is an iCalendar object that conforms to the 1695 following property constraints: 1697 +-------------------------------------------------+ 1698 | Constraints for a METHOD:PUBLISH of a VFREEBUSY | 1699 +-------------------------------------------------+ 1701 +--------------------+----------+-----------------------------------+ 1702 | Component/Property | Presence | Comment | 1703 +--------------------+----------+-----------------------------------+ 1704 | METHOD | 1 | MUST be "PUBLISH" | 1705 | | | | 1706 | VFREEBUSY | 1+ | | 1707 | DTSTAMP | 1 | | 1708 | DTSTART | 1 | DateTime values must be in UTC | 1709 | DTEND | 1 | DateTime values must be in UTC | 1710 | FREEBUSY | 0+ | MUST be BUSYTIME. Multiple | 1711 | | | instances are allowed. Multiple | 1712 | | | instances SHOULD be sorted in | 1713 | | | ascending order | 1714 | ORGANIZER | 1 | MUST contain the address of | 1715 | | | originator of busy time data. | 1716 | UID | 1 | | 1717 | COMMENT | 0+ | | 1718 | CONTACT | 0 or 1 | | 1719 | IANA-PROPERTY | 0+ | | 1720 | X-PROPERTY | 0+ | | 1721 | URL | 0 or 1 | Specifies busy time URL | 1722 | ATTENDEE | 0 | | 1723 | DURATION | 0 | | 1724 | REQUEST-STATUS | 0 | | 1725 | | | | 1726 | VALARM | 0 | | 1727 | | | | 1728 | IANA-COMPONENT | 0+ | | 1729 | X-COMPONENT | 0+ | | 1730 | | | | 1731 | VEVENT | 0 | | 1732 | | | | 1733 | VTODO | 0 | | 1734 | | | | 1735 | VJOURNAL | 0 | | 1736 | | | | 1737 | VTIMEZONE | 0 | | 1738 +--------------------+----------+-----------------------------------+ 1740 3.3.2. REQUEST 1742 The "REQUEST" method in a "VFREEBUSY" calendar component is used to 1743 ask a "Calendar User" for their busy time information. The request 1744 may be for a busy time information bounded by a specific date and 1745 time interval. 1747 This message only permits requests for busy time information. The 1748 message is sent from a "Calendar User" requesting the busy time 1749 information to one or more intended recipients. 1751 If the originator of the "REQUEST" method is not authorized to make a 1752 busy time request on the recipient's calendar system, then an 1753 exception message SHOULD be returned in a "REPLY" method, but no busy 1754 time data need be returned. 1756 This method type is an iCalendar object that conforms to the 1757 following property constraints: 1759 +-------------------------------------------------+ 1760 | Constraints for a METHOD:REQUEST of a VFREEBUSY | 1761 +-------------------------------------------------+ 1763 +--------------------+----------+-----------------------------------+ 1764 | Component/Property | Presence | Comment | 1765 +--------------------+----------+-----------------------------------+ 1766 | METHOD | 1 | MUST be "REQUEST" | 1767 | | | | 1768 | VFREEBUSY | 1 | | 1769 | ATTENDEE | 1+ | contains the calendar user | 1770 | | | addresses of the calendar users | 1771 | | | whose freebusy is being requested | 1772 | DTEND | 1 | DateTime values must be in UTC | 1773 | DTSTAMP | 1 | | 1774 | DTSTART | 1 | DateTime values must be in UTC | 1775 | ORGANIZER | 1 | MUST be the request originator's | 1776 | | | address | 1777 | UID | 1 | | 1778 | COMMENT | 0+ | | 1779 | CONTACT | 0 or 1 | | 1780 | IANA-PROPERTY | 0+ | | 1781 | X-PROPERTY | 0+ | | 1782 | FREEBUSY | 0 | | 1783 | DURATION | 0 | | 1784 | REQUEST-STATUS | 0 | | 1785 | URL | 0 | | 1786 | | | | 1787 | VALARM | 0 | | 1788 | | | | 1789 | IANA-COMPONENT | 0+ | | 1790 | X-COMPONENT | 0+ | | 1791 | | | | 1792 | VEVENT | 0 | | 1793 | | | | 1794 | VTODO | 0 | | 1795 | | | | 1796 | VJOURNAL | 0 | | 1797 | | | | 1798 | VTIMEZONE | 0 | | 1799 +--------------------+----------+-----------------------------------+ 1801 3.3.3. REPLY 1803 The "REPLY" method in a "VFREEBUSY" calendar component is used to 1804 respond to a busy time request. The method is sent by the recipient 1805 of a busy time request to the originator of the request. 1807 The "REPLY" method may also be used to respond to an unsuccessful 1808 "REQUEST" method. Depending on the "REQUEST-STATUS" value, no busy 1809 time information may be returned. 1811 This method type is an iCalendar object that conforms to the 1812 following property constraints: 1814 +-----------------------------------------------+ 1815 | Constraints for a METHOD:REPLY of a VFREEBUSY | 1816 +-----------------------------------------------+ 1818 +--------------------+----------+-----------------------------------+ 1819 | Component/Property | Presence | Comment | 1820 +--------------------+----------+-----------------------------------+ 1821 | METHOD | 1 | MUST be "REPLY" | 1822 | | | | 1823 | VFREEBUSY | 1 | | 1824 | ATTENDEE | 1 | MUST be the address of the | 1825 | | | Attendee replying. | 1826 | DTSTAMP | 1 | | 1827 | DTEND | 1 | DateTime values must be in UTC | 1828 | DTSTART | 1 | DateTime values must be in UTC | 1829 | FREEBUSY | 0+ | MUST be BUSYTIME. Multiple | 1830 | | | instances are allowed. Multiple | 1831 | | | instances SHOULD be sorted in | 1832 | | | ascending order | 1833 | ORGANIZER | 1 | MUST be the request originator's | 1834 | | | address | 1835 | UID | 1 | MUST be the UID of the original | 1836 | | | REQUEST | 1837 | COMMENT | 0+ | | 1838 | CONTACT | 0 or 1 | | 1839 | REQUEST-STATUS | 0+ | | 1840 | URL | 0 or 1 | specifies busy time URL | 1841 | IANA-PROPERTY | 0+ | | 1842 | X-PROPERTY | 0+ | | 1843 | DURATION | 0 | | 1844 | SEQUENCE | 0 | | 1845 | | | | 1846 | VALARM | 0 | | 1847 | | | | 1848 | IANA-COMPONENT | 0+ | | 1849 | X-COMPONENT | 0+ | | 1850 | | | | 1851 | VEVENT | 0 | | 1852 | | | | 1853 | VTODO | 0 | | 1854 | | | | 1855 | VJOURNAL | 0 | | 1856 | | | | 1857 | VTIMEZONE | 0 | | 1858 +--------------------+----------+-----------------------------------+ 1860 3.4. Methods For VTODO Components 1862 This section defines the property set for the methods that are 1863 applicable to the "VTODO" calendar component. Each of the methods is 1864 defined using a restriction table that specifies the property 1865 constraints that define the particular method. 1867 The following summarizes the methods that are defined for the "VTODO" 1868 calendar component. 1870 +----------------+--------------------------------------------------+ 1871 | Method | Description | 1872 +----------------+--------------------------------------------------+ 1873 | PUBLISH | Post notification of a VTODO. Used primarily as | 1874 | | a method of advertising the existence of a | 1875 | | VTODO. | 1876 | | | 1877 | REQUEST | Assign a VTODO. This is an explicit assignment | 1878 | | to one or more Calendar Users. The REQUEST | 1879 | | method is also used to update or change an | 1880 | | existing VTODO. Clients that cannot handle | 1881 | | REQUEST MAY degrade the method to treat it as a | 1882 | | PUBLISH. | 1883 | | | 1884 | REPLY | Reply to a VTODO request. Attendees MAY set | 1885 | | PARTSTAT to ACCEPTED, DECLINED, TENTATIVE, | 1886 | | DELEGATED, PARTIAL, and COMPLETED. | 1887 | | | 1888 | ADD | Add one or more instances to an existing to-do. | 1889 | | | 1890 | CANCEL | Cancel one or more instances of an existing | 1891 | | to-do. | 1892 | | | 1893 | REFRESH | A request sent to a VTODO Organizer asking for | 1894 | | the latest version of a VTODO. | 1895 | | | 1896 | COUNTER | Counter a REQUEST with an alternative proposal. | 1897 | | | 1898 | DECLINECOUNTER | Decline a counter proposal by an Attendee. | 1899 +----------------+--------------------------------------------------+ 1901 3.4.1. PUBLISH 1903 The "PUBLISH" method in a "VTODO" calendar component has no 1904 associated response. It is simply a posting of an iCalendar object 1905 that maybe added to a calendar. It MUST have an "Organizer". It 1906 MUST NOT have "Attendees". Its expected usage is for encapsulating 1907 an arbitrary "VTODO" calendar component as an iCalendar object. The 1908 "Organizer" MAY subsequently update (with another "PUBLISH" method), 1909 add instances to (with an "ADD" method), or cancel (with a "CANCEL" 1910 method) a previously published "VTODO" calendar component. 1912 This method type is an iCalendar object that conforms to the 1913 following property constraints: 1915 +---------------------------------------------+ 1916 | Constraints for a METHOD:PUBLISH of a VTODO | 1917 +---------------------------------------------+ 1919 +--------------------+----------+-----------------------------------+ 1920 | Component/Property | Presence | Comment | 1921 +--------------------+----------+-----------------------------------+ 1922 | METHOD | 1 | MUST be "PUBLISH" | 1923 | | | | 1924 | VTODO | 1+ | | 1925 | DTSTAMP | 1 | | 1926 | DTSTART | 1 | | 1927 | ORGANIZER | 1 | | 1928 | PRIORITY | 1 | | 1929 | SEQUENCE | 0 or 1 | MUST be present if value is | 1930 | | | greater than 0, MAY be present if | 1931 | | | 0 | 1932 | SUMMARY | 1 | Can be null. | 1933 | UID | 1 | | 1934 | ATTACH | 0+ | | 1935 | CATEGORIES | 0+ | | 1936 | CLASS | 0 or 1 | | 1937 | COMMENT | 0+ | | 1938 | COMPLETED | 0 or 1 | | 1939 | CONTACT | 0+ | | 1940 | CREATED | 0 or 1 | | 1941 | DESCRIPTION | 0 or 1 | Can be null | 1942 | DUE | 0 or 1 | If present DURATION MUST NOT be | 1943 | | | present | 1944 | DURATION | 0 or 1 | If present DUE MUST NOT be | 1945 | | | present | 1946 | EXDATE | 0+ | | 1947 | GEO | 0 or 1 | | 1948 | LAST-MODIFIED | 0 or 1 | | 1949 | LOCATION | 0 or 1 | | 1950 | PERCENT-COMPLETE | 0 or 1 | | 1951 | RDATE | 0+ | | 1952 | RECURRENCE-ID | 0 or 1 | Only if referring to an instance | 1953 | | | of a recurring calendar | 1954 | | | component. Otherwise it MUST NOT | 1955 | | | be present. | 1956 | RELATED-TO | 0+ | | 1957 | RESOURCES | 0+ | | 1958 | RRULE | 0 or 1 | | 1959 | STATUS | 0 or 1 | MAY be one of | 1960 | | | COMPLETED/NEEDS-ACTION/ | 1961 | | | IN-PROCESS/CANCELLED | 1962 | URL | 0 or 1 | | 1963 | IANA-PROPERTY | 0+ | | 1964 | X-PROPERTY | 0+ | | 1965 | ATTENDEE | 0 | | 1966 | REQUEST-STATUS | 0 | | 1967 | | | | 1968 | VALARM | 0+ | | 1969 | | | | 1970 | VTIMEZONE | 0+ | MUST be present if any date/time | 1971 | | | refers to a timezone | 1972 | | | | 1973 | IANA-COMPONENT | 0+ | | 1974 | X-COMPONENT | 0+ | | 1975 | | | | 1976 | VFREEBUSY | 0 | | 1977 | | | | 1978 | VEVENT | 0 | | 1979 | | | | 1980 | VJOURNAL | 0 | | 1981 +--------------------+----------+-----------------------------------+ 1983 3.4.2. REQUEST 1985 The "REQUEST" method in a "VTODO" calendar component provides the 1986 following scheduling functions: 1988 o Assign a to-do to one or more "Calendar Users" 1989 o Reschedule an existing to-do 1990 o Update the details of an existing to-do, without rescheduling it 1991 o Update the completion status of "Attendees" of an existing to-do, 1992 without rescheduling it 1993 o Reconfirm an existing to-do, without rescheduling it 1994 o Delegate/reassign an existing to-do to another "Calendar User" 1996 The assigned "Calendar Users" are identified in the "VTODO" calendar 1997 component by individual "ATTENDEE;ROLE=REQ-PARTICIPANT" property 1998 value sequences. 2000 Typically the originator of a "REQUEST" is the "Organizer" of the 2001 to-do, and the recipient of a "REQUEST" is the "Calendar User" 2002 assigned the to-do. The "Attendee" uses the "REPLY" method to convey 2003 their acceptance and completion status to the "Organizer" of the 2004 "REQUEST". 2006 The "UID", "SEQUENCE", and "DTSTAMP" properties are used to 2007 distinguish the various uses of the "REQUEST" method. If the "UID" 2008 property value in the "REQUEST" is not found on the recipient's 2009 calendar, then the "REQUEST" is for a new to-do. If the "UID" 2010 property value is found on the recipient's calendar, then the 2011 "REQUEST" is a rescheduling, an update, or a reconfirm of the "VTODO" 2012 calendar object. 2014 If the "Organizer" of the "REQUEST" method is not authorized to make 2015 a to-do request on the "Attendee's" calendar system, then an 2016 exception is returned in the "REQUEST-STATUS" property of a 2017 subsequent "REPLY" method, but no scheduling action is performed. 2019 For the "REQUEST" method, multiple "VTODO" components in a single 2020 iCalendar object are only permitted when for components with the same 2021 "UID" property. That is, a series of recurring events may have 2022 instance-specific information. In this case, multiple "VTODO" 2023 components are needed to express the entire series. 2025 This method type is an iCalendar object that conforms to the 2026 following property constraints: 2028 +---------------------------------------------+ 2029 | Constraints for a METHOD:REQUEST of a VTODO | 2030 +---------------------------------------------+ 2032 +--------------------+----------+-----------------------------------+ 2033 | Component/Property | Presence | Comment | 2034 +--------------------+----------+-----------------------------------+ 2035 | METHOD | 1 | MUST be "REQUEST" | 2036 | | | | 2037 | VTODO | 1+ | All components must have the same | 2038 | | | UID | 2039 | ATTENDEE | 1+ | | 2040 | DTSTAMP | 1 | | 2041 | DTSTART | 1 | | 2042 | ORGANIZER | 1 | | 2043 | PRIORITY | 1 | | 2044 | SEQUENCE | 0 or 1 | MUST be present if value is | 2045 | | | greater than 0, MAY be present if | 2046 | | | 0 | 2047 | SUMMARY | 1 | Can be null | 2048 | UID | 1 | | 2049 | ATTACH | 0+ | | 2050 | CATEGORIES | 0+ | | 2051 | CLASS | 0 or 1 | | 2052 | COMMENT | 0+ | | 2053 | COMPLETED | 0 or 1 | | 2054 | CONTACT | 0+ | | 2055 | CREATED | 0 or 1 | | 2056 | DESCRIPTION | 0 or 1 | Can be null | 2057 | DUE | 0 or 1 | If present DURATION MUST NOT be | 2058 | | | present | 2059 | DURATION | 0 or 1 | If present DUE MUST NOT be | 2060 | | | present | 2061 | EXDATE | 0+ | | 2062 | GEO | 0 or 1 | | 2063 | LAST-MODIFIED | 0 or 1 | | 2064 | LOCATION | 0 or 1 | | 2065 | PERCENT-COMPLETE | 0 or 1 | | 2066 | RDATE | 0+ | | 2067 | RECURRENCE-ID | 0 or 1 | Only if referring to an instance | 2068 | | | of a recurring calendar | 2069 | | | component. Otherwise it MUST NOT | 2070 | | | be present. | 2071 | RELATED-TO | 0+ | | 2072 | RESOURCES | 0+ | | 2073 | RRULE | 0 or 1 | | 2074 | STATUS | 0 or 1 | MAY be one of | 2075 | | | COMPLETED/NEEDS-ACTION/ | 2076 | | | IN-PROCESS | 2077 | URL | 0 or 1 | | 2078 | IANA-PROPERTY | 0+ | | 2079 | X-PROPERTY | 0+ | | 2080 | REQUEST-STATUS | 0 | | 2081 | | | | 2082 | VALARM | 0+ | | 2083 | | | | 2084 | VTIMEZONE | 0+ | MUST be present if any date/time | 2085 | | | refers to a timezone | 2086 | | | | 2087 | IANA-COMPONENT | 0+ | | 2088 | X-COMPONENT | 0+ | | 2089 | | | | 2090 | VEVENT | 0 | | 2091 | | | | 2092 | VFREEBUSY | 0 | | 2093 | | | | 2094 | VJOURNAL | 0 | | 2095 +--------------------+----------+-----------------------------------+ 2097 3.4.2.1. REQUEST for Rescheduling a VTODO 2099 The "REQUEST" method may be used to reschedule a "VTODO" calendar 2100 component. 2102 Rescheduling a "VTODO" calendar component involves a change to the 2103 existing "VTODO" calendar component in terms of its start or due time 2104 or recurrence intervals and possibly the description. If the 2105 recipient CUA of a "REQUEST" method finds that the "UID" property 2106 value already exists on the calendar, but that the "SEQUENCE" 2107 property value in the "REQUEST" is greater than the value for the 2108 existing VTODO, then the "REQUEST" method describes a rescheduling of 2109 the "VTODO" calendar component. 2111 3.4.2.2. REQUEST for Update or Reconfirmation of a VTODO 2113 The "REQUEST" method may be used to update or reconfirm a "VTODO" 2114 calendar component. Reconfirmation is merely an update of "Attendee" 2115 completion status or overall "VTODO" calendar component status. 2117 An update to an existing "VTODO" calendar component does not involve 2118 changes to the start or due time or recurrence intervals, nor 2119 generally to the description for the "VTODO" calendar component. If 2120 the recipient CUA of a "REQUEST" method finds that the "UID" property 2121 value already exists on the calendar and that the "SEQUENCE" property 2122 value in the "REQUEST" is the same as the value for the existing 2123 event, then the "REQUEST" method describes an update of the "VTODO" 2124 calendar component details, but not a rescheduling of the "VTODO" 2125 calendar component. 2127 The update "REQUEST" is the appropriate response to a "REFRESH" 2128 method sent from an "Attendee" to the "Organizer" of a "VTODO" 2129 calendar component. 2131 Unsolicited "REQUEST" methods MAY be sent by the "Organizer" of a 2132 "VTODO" calendar component. The unsolicited "REQUEST" methods are 2133 used to update the details of the "VTODO" (without rescheduling it or 2134 updating the completion status of "Attendees") or the "VTODO" 2135 calendar component itself (i.e., reconfirm the "VTODO"). 2137 3.4.2.3. REQUEST for Delegating a VTODO 2139 The "REQUEST" method is also used to delegate or reassign ownership 2140 of a "VTODO" calendar component to another "Calendar User". For 2141 example, it may be used to delegate an "Attendee's" role (i.e. 2142 "chair", or "participant") for a "VTODO" calendar component. The 2143 "REQUEST" method is sent by one of the "Attendees" of an existing 2144 "VTODO" calendar component to some other individual. 2146 For the purposes of this description, the "Attendee" delegating the 2147 "VTODO" calendar component is referred to as the "Delegator". The 2148 "Attendee" receiving the delegation request is referred to as the 2149 "Delegate". 2151 The "Delegator" of a "VTODO" calendar component MUST forward the 2152 existing "REQUEST" method for a "VTODO" calendar component to the 2153 "Delegate". The "VTODO" calendar component description MUST include 2154 the "Delegator's" up-to-date "VTODO" calendar component definition. 2156 The "REQUEST" method MUST also include an "ATTENDEE" property with 2157 the calendar address of the "Delegate". The "Delegator" MUST also 2158 send a "REPLY" method back to the "Organizer" with the "Delegator's" 2159 "Attendee" property "PARTSTAT" parameter value set to "DELEGATED". 2160 In addition, the "DELEGATED-TO" parameter MUST be included with the 2161 calendar address of the "Delegate". A response to the delegation 2162 "REQUEST" is sent from the "Delegate" to the "Organizer" and 2163 optionally, to the "Delegator". The "REPLY" method from the 2164 "Delegate" SHOULD include the "ATTENDEE" property with their calendar 2165 address and the "DELEGATED-FROM" parameter with the value of the 2166 "Delegator's" calendar address. 2168 The delegation "REQUEST" method MUST assign a value for the "RSVP" 2169 property parameter associated with the "Delegator's" "Attendee" 2170 property to that of the "Delegate's" "ATTENDEE" property. For 2171 example if the "Delegator's" "ATTENDEE" property specifies 2172 "RSVP=TRUE", then the "Delegate's" "ATTENDEE" property MUST specify 2173 "RSVP=TRUE". 2175 3.4.2.4. REQUEST Forwarded To An Uninvited Calendar User 2177 An "Attendee" assigned a "VTODO" calendar component may send the 2178 "VTODO" calendar component to another new CU, not previously 2179 associated with the "VTODO" calendar component. The current 2180 "Attendee" assigned the "VTODO" calendar component does this by 2181 forwarding the original "REQUEST" method to the new CU. The new CU 2182 can send a "REPLY" to the "Organizer" of the "VTODO" calendar 2183 component. The reply contains an "ATTENDEE" property for the new CU. 2185 The "Organizer" ultimately decides whether or not the new CU becomes 2186 part of the to-do and is not obligated to do anything with a "REPLY" 2187 from a new (uninvited) CU. If the "Organizer" does not want the new 2188 CU to be part of the to-do, the new "ATTENDEE" property is not added 2189 to the "VTODO" calendar component. The "Organizer" MAY send the CU a 2190 "CANCEL" message to indicate that they will not be added to the to- 2191 do. If the "Organizer" decides to add the new CU, the new "ATTENDEE" 2192 property is added to the "VTODO" calendar component. Furthermore, 2193 the "Organizer" is free to change any "ATTENDEE" property parameter 2194 from the values supplied by the new CU to something the "Organizer" 2195 considers appropriate. The "Organizer" SHOULD send the new attendee 2196 a "REQUEST" message to inform them that they have been added. 2198 When forwarding a "REQUEST" to another CU, the forwarding "Attendee" 2199 MUST NOT make changes to the original message. 2201 3.4.2.5. REQUEST Updated Attendee Status 2203 An "Organizer" of a "VTODO" may request an updated status from one or 2204 more "Attendees". The "Organizer" sends a "REQUEST" method to the 2205 "Attendee" with the "ATTENDEE;RSVP=TRUE" property sequence. The 2206 "SEQUENCE" property for the "VTODO" is not changed from its previous 2207 value. A recipient determines that the only change in the "REQUEST" 2208 is that their "RSVP" property parameter indicates a request for an 2209 updated status. The recipient SHOULD respond with a "REPLY" method 2210 indicating their current status with respect to the "REQUEST". 2212 3.4.3. REPLY 2214 The "REPLY" method in a "VTODO" calendar component is used to respond 2215 (e.g., accept or decline) to a request or to reply to a delegation 2216 request. It is also used by an "Attendee" to update their completion 2217 status. When used to provide a delegation response, the "Delegator" 2218 MUST include the calendar address of the "Delegate" in the 2219 "DELEGATED-TO" parameter of the "Delegator's" "ATTENDEE" property. 2220 The "Delegate" MUST include the calendar address of the "Delegator" 2221 on the "DELEGATED-FROM" parameter of the "Delegate's" "ATTENDEE" 2222 property. 2224 The "REPLY" method MAY also be used to respond to an unsuccessful 2225 "VTODO" calendar component "REQUEST" method. Depending on the 2226 "REQUEST-STATUS" value, no scheduling action may have been performed. 2228 The "Organizer" of a "VTODO" calendar component MAY receive a "REPLY" 2229 method from a "Calendar User" not in the original "REQUEST". For 2230 example, a "REPLY" method MAY be received from a "Delegate" of a 2231 "VTODO" calendar component. In addition, the "REPLY" method MAY be 2232 received from an unknown "Calendar User", having been forwarded the 2233 "REQUEST" by an original "Attendee" of the "VTODO" calendar 2234 component. This uninvited "Attendee" MAY be accepted, or the 2235 "Organizer" MAY cancel the "VTODO" calendar component for the 2236 uninvited "Attendee" by sending them a "CANCEL" method. 2238 This method type is an iCalendar object that conforms to the 2239 following property constraints: 2241 +-------------------------------------------+ 2242 | Constraints for a METHOD:REPLY of a VTODO | 2243 +-------------------------------------------+ 2245 +--------------------+----------+-----------------------------------+ 2246 | Component/Property | Presence | Comment | 2247 +--------------------+----------+-----------------------------------+ 2248 | METHOD | 1 | MUST be "REPLY" | 2249 | | | | 2250 | VTODO | 1+ | All component MUST have the same | 2251 | | | UID | 2252 | ATTENDEE | 1 | MUST be the address of the | 2253 | | | Attendee replying. | 2254 | DTSTAMP | 1 | | 2255 | ORGANIZER | 1 | | 2256 | REQUEST-STATUS | 0+ | | 2257 | UID | 1 | MUST be the UID of the original | 2258 | | | REQUEST | 2259 | ATTACH | 0+ | | 2260 | CATEGORIES | 0+ | | 2261 | CLASS | 0 or 1 | | 2262 | COMMENT | 0+ | | 2263 | COMPLETED | 0 or 1 | | 2264 | CONTACT | 0+ | | 2265 | CREATED | 0 or 1 | | 2266 | DESCRIPTION | 0 or 1 | | 2267 | DTSTART | 0 or 1 | | 2268 | DUE | 0 or 1 | If present DURATION MUST NOT be | 2269 | | | present | 2270 | DURATION | 0 or 1 | If present DUE MUST NOT be | 2271 | | | present | 2272 | EXDATE | 0+ | | 2273 | GEO | 0 or 1 | | 2274 | LAST-MODIFIED | 0 or 1 | | 2275 | LOCATION | 0 or 1 | | 2276 | PERCENT-COMPLETE | 0 or 1 | | 2277 | PRIORITY | 0 or 1 | | 2278 | RDATE | 0+ | | 2279 | RELATED-TO | 0+ | | 2280 | RESOURCES | 0+ | | 2281 | RRULE | 0 or 1 | | 2282 | RECURRENCE-ID | 0 or 1 | Only if referring to an instance | 2283 | | | of a recurring calendar | 2284 | | | component. Otherwise it MUST NOT | 2285 | | | be present. | 2286 | SEQUENCE | 0 or 1 | MUST be the sequence number of | 2287 | | | the original REQUEST if greater | 2288 | | | than 0. MAY be present if 0. | 2289 | STATUS | 0 or 1 | | 2290 | SUMMARY | 0 or 1 | Can be null | 2291 | URL | 0 or 1 | | 2292 | IANA-PROPERTY | 0+ | | 2293 | X-PROPERTY | 0+ | | 2294 | | | | 2295 | VALARM | 0 | | 2296 | | | | 2297 | VTIMEZONE | 0 or 1 | MUST be present if any date/time | 2298 | | | refers to a timezone | 2299 | | | | 2300 | IANA-COMPONENT | 0+ | | 2301 | X-COMPONENT | 0+ | | 2302 | | | | 2303 | VEVENT | 0 | | 2304 | | | | 2305 | VFREEBUSY | 0 | | 2306 +--------------------+----------+-----------------------------------+ 2308 3.4.4. ADD 2310 The "ADD" method allows the "Organizer" to add one or more new 2311 instances to an existing "VTODO" using a single iTIP message without 2312 having to send the entire "VTODO" with all the existing instance 2313 data, as it would have to do if the "REQUEST" method were used. 2315 The "UID" must be that of the existing to-do. If the "UID" property 2316 value in the "ADD" is not found on the recipient's calendar, then the 2317 recipient SHOULD send a "REFRESH" to the "Organizer" in order to be 2318 updated with the latest version of the "VTODO". If an "Attendee" 2319 implementation does not support the "ADD" method it should respond 2320 with a "REQUEST-STATUS" value of 3.14 and ask for a "REFRESH". 2322 When handling an "ADD" message, the "Attendee" treats each component 2323 in the "ADD" message as if it were referenced via an "RDATE"in the 2324 main component. 2326 The "SEQUENCE" property value is incremented as the sequence of to- 2327 dos has changed. 2329 This method type is an iCalendar object that conforms to the 2330 following property constraints: 2332 +-----------------------------------------+ 2333 | Constraints for a METHOD:ADD of a VTODO | 2334 +-----------------------------------------+ 2336 +--------------------+----------+-----------------------------------+ 2337 | Component/Property | Presence | Comment | 2338 +--------------------+----------+-----------------------------------+ 2339 | METHOD | 1 | MUST be "ADD" | 2340 | | | | 2341 | VTODO | 1 | | 2342 | DTSTAMP | 1 | | 2343 | ORGANIZER | 1 | | 2344 | PRIORITY | 1 | | 2345 | SEQUENCE | 1 | MUST be greater than 0 | 2346 | SUMMARY | 1 | Can be null | 2347 | UID | 1 | MUST match that of the original | 2348 | | | to-do | 2349 | ATTACH | 0+ | | 2350 | ATTENDEE | 0+ | | 2351 | CATEGORIES | 0+ | | 2352 | CLASS | 0 or 1 | | 2353 | COMMENT | 0+ | | 2354 | COMPLETED | 0 or 1 | | 2355 | CONTACT | 0+ | | 2356 | CREATED | 0 or 1 | | 2357 | DESCRIPTION | 0 or 1 | Can be null | 2358 | DTSTART | 0 or 1 | | 2359 | DUE | 0 or 1 | If present DURATION MUST NOT be | 2360 | | | present | 2361 | DURATION | 0 or 1 | If present DUE MUST NOT be | 2362 | | | present | 2363 | GEO | 0 or 1 | | 2364 | LAST-MODIFIED | 0 or 1 | | 2365 | LOCATION | 0 or 1 | | 2366 | PERCENT-COMPLETE | 0 or 1 | | 2367 | RELATED-TO | 0+ | | 2368 | RESOURCES | 0+ | | 2369 | STATUS | 0 or 1 | MAY be one of | 2370 | | | COMPLETED/NEEDS-ACTION/ | 2371 | | | IN-PROCESS | 2372 | URL | 0 or 1 | | 2373 | IANA-PROPERTY | 0+ | | 2374 | X-PROPERTY | 0+ | | 2375 | EXDATE | 0 | | 2376 | RECURRENCE-ID | 0 | | 2377 | REQUEST-STATUS | 0 | | 2378 | RDATE | 0 | | 2379 | RRULE | 0 | | 2380 | | | | 2381 | VALARM | 0+ | | 2382 | | | | 2383 | VTIMEZONE | 0+ | MUST be present if any date/time | 2384 | | | refers to a timezone | 2385 | | | | 2386 | IANA-COMPONENT | 0+ | | 2387 | X-COMPONENT | 0+ | | 2388 | | | | 2389 | VEVENT | 0 | | 2390 | | | | 2391 | VJOURNAL | 0 | | 2392 | | | | 2393 | VFREEBUSY | 0 | | 2394 +--------------------+----------+-----------------------------------+ 2396 3.4.5. CANCEL 2398 The "CANCEL" method in a "VTODO" calendar component is used to send a 2399 cancellation notice of an existing "VTODO" calendar request to the 2400 affected "Attendees". The message is sent by the "Organizer" of a 2401 "VTODO" calendar component to the "Attendees" of the "VTODO" calendar 2402 component. For a recurring "VTODO" calendar component, either the 2403 whole "VTODO" calendar component or instances of a "VTODO" calendar 2404 component may be cancelled. To cancel the complete range of a 2405 recurring "VTODO" calendar component, the "UID" property value for 2406 the "VTODO" calendar component MUST be specified and a "RECURRENCE- 2407 ID" MUST NOT be specified in the "CANCEL" method. In order to cancel 2408 an individual instance of a recurring "VTODO" calendar component, the 2409 "RECURRENCE-ID" property value for the "VTODO" calendar component 2410 MUST be specified in the "CANCEL" method. 2412 There are two options for canceling a sequence of instances of a 2413 recurring "VTODO" calendar component: 2415 a. the "RECURRENCE-ID" property for an instance in the sequence MUST 2416 be specified with the "RANGE" property parameter value of 2417 "THISANDFUTURE" to indicate cancellation of the specified "VTODO" 2418 calendar component and all instances after 2419 b. individual recurrence instances may be cancelled by specifying 2420 multiple "VTODO" components with a "RECURRENCE-ID" property 2421 corresponding to one of the instances to be cancelled 2423 The "Organizer" MUST send a "CANCEL" message to each "Attendee" 2424 affected by the cancellation. This can be done using a single 2425 "CANCEL" message for all "Attendees", or multiple messages with 2426 different subsets of the affected "Attendees" in each. 2428 When a "VTODO" is cancelled, the "SEQUENCE" property value MUST be 2429 incremented as described in Section 2.1.4. 2431 This method type is an iCalendar object that conforms to the 2432 following property constraints: 2434 +--------------------------------------------+ 2435 | Constraints for a METHOD:CANCEL of a VTODO | 2436 +--------------------------------------------+ 2438 +--------------------+----------+-----------------------------------+ 2439 | Component/Property | Presence | Comment | 2440 +--------------------+----------+-----------------------------------+ 2441 | METHOD | 1 | MUST be "CANCEL" | 2442 | | | | 2443 | VTODO | 1+ | | 2444 | ATTENDEE | 0+ | MUST include some or all | 2445 | | | "Attendees" being removed from | 2446 | | | the to-do. MUST include some or | 2447 | | | all "Attendees" if the entire | 2448 | | | to-do is cancelled. | 2449 | UID | 1 | MUST echo original UID | 2450 | DTSTAMP | 1 | | 2451 | ORGANIZER | 1 | | 2452 | SEQUENCE | 1 | | 2453 | ATTACH | 0+ | | 2454 | CATEGORIES | 0+ | | 2455 | CLASS | 0 or 1 | | 2456 | COMMENT | 0+ | | 2457 | COMPLETED | 0 or 1 | | 2458 | CONTACT | 0+ | | 2459 | CREATED | 0 or 1 | | 2460 | DESCRIPTION | 0 or 1 | | 2461 | DTSTART | 0 or 1 | | 2462 | DUE | 0 or 1 | If present DURATION MUST NOT be | 2463 | | | present | 2464 | DURATION | 0 or 1 | If present DUE MUST NOT be | 2465 | | | present | 2466 | EXDATE | 0+ | | 2467 | GEO | 0 or 1 | | 2468 | LAST-MODIFIED | 0 or 1 | | 2469 | LOCATION | 0 or 1 | | 2470 | PERCENT-COMPLETE | 0 or 1 | | 2471 | RDATE | 0+ | | 2472 | RECURRENCE-ID | 0 or 1 | Only if referring to an instance | 2473 | | | of a recurring calendar | 2474 | | | component. Otherwise it MUST NOT | 2475 | | | be present. | 2476 | RELATED-TO | 0+ | | 2477 | RESOURCES | 0+ | | 2478 | RRULE | 0 or 1 | | 2479 | PRIORITY | 0 or 1 | | 2480 | STATUS | 0 or 1 | MUST be set to CANCELLED to | 2481 | | | cancel the entire VTODO. If | 2482 | | | removing specific "Attendees" | 2483 | | | then MUST NOT be included. | 2484 | URL | 0 or 1 | | 2485 | IANA-PROPERTY | 0+ | | 2486 | X-PROPERTY | 0+ | | 2487 | REQUEST-STATUS | 0 | | 2488 | | | | 2489 | VALARM | 0 | | 2490 | | | | 2491 | VTIMEZONE | 0 or 1 | MUST be present if any date/time | 2492 | | | refers to a timezone | 2493 | | | | 2494 | IANA-COMPONENT | 0+ | | 2495 | X-COMPONENT | 0+ | | 2496 | | | | 2497 | VEVENT | 0 | | 2498 | | | | 2499 | VFREEBUSY | 0 | | 2500 +--------------------+----------+-----------------------------------+ 2502 3.4.6. REFRESH 2504 The "REFRESH" method in a "VTODO" calendar component is used by 2505 "Attendees" of an existing "VTODO" calendar component to request an 2506 updated description from the "Organizer" of the "VTODO" calendar 2507 component. The "Organizer" of the "VTODO" calendar component MAY use 2508 this method to request an updated status from the "Attendees". The 2509 "REFRESH" method MUST specify the "UID" property corresponding to the 2510 "VTODO" calendar component needing update. 2512 A refresh of a recurrence instance of a "VTODO" calendar component 2513 may be requested by specifying the "RECURRENCE-ID" property 2514 corresponding to the associated "VTODO" calendar component. The 2515 "Organizer" responds with the latest description and rendition of the 2516 "VTODO" calendar component. In most cases this will be a REQUEST 2517 unless the "VTODO" has been cancelled, in which case the ORGANIZER 2518 MUST send a "CANCEL". This method is intended to facilitate machine 2519 processing of requests for updates to a "VTODO" calendar component. 2521 This method type is an iCalendar object that conforms to the 2522 following property constraints: 2524 +---------------------------------------------+ 2525 | Constraints for a METHOD:REFRESH of a VTODO | 2526 +---------------------------------------------+ 2528 +--------------------+----------+-----------------------------------+ 2529 | Component/Property | Presence | Comment | 2530 +--------------------+----------+-----------------------------------+ 2531 | METHOD | 1 | MUST be "REFRESH" | 2532 | | | | 2533 | VTODO | 1 | | 2534 | ATTENDEE | 1 | | 2535 | DTSTAMP | 1 | | 2536 | UID | 1 | MUST echo original UID | 2537 | RECURRENCE-ID | 0 or 1 | Only if referring to an instance | 2538 | | | of a recurring calendar | 2539 | | | component. Otherwise it MUST NOT | 2540 | | | be present. | 2541 | IANA-PROPERTY | 0+ | | 2542 | X-PROPERTY | 0+ | | 2543 | ATTACH | 0 | | 2544 | CATEGORIES | 0 | | 2545 | CLASS | 0 | | 2546 | COMMENT | 0 | | 2547 | COMPLETED | 0 | | 2548 | CONTACT | 0 | | 2549 | CREATED | 0 | | 2550 | DESCRIPTION | 0 | | 2551 | DTSTART | 0 | | 2552 | DUE | 0 | | 2553 | DURATION | 0 | | 2554 | EXDATE | 0 | | 2555 | GEO | 0 | | 2556 | LAST-MODIFIED | 0 | | 2557 | LOCATION | 0 | | 2558 | ORGANIZER | 0 | | 2559 | PERCENT-COMPLETE | 0 | | 2560 | PRIORITY | 0 | | 2561 | RDATE | 0 | | 2562 | RELATED-TO | 0 | | 2563 | REQUEST-STATUS | 0 | | 2564 | RESOURCES | 0 | | 2565 | RRULE | 0 | | 2566 | SEQUENCE | 0 | | 2567 | STATUS | 0 | | 2568 | URL | 0 | | 2569 | | | | 2570 | VALARM | 0 | | 2571 | | | | 2572 | VTIMEZONE | 0+ | | 2573 | | | | 2574 | IANA-COMPONENT | 0+ | | 2575 | X-COMPONENT | 0+ | | 2576 | | | | 2577 | VEVENT | 0 | | 2578 | | | | 2579 | VFREEBUSY | 0 | | 2580 +--------------------+----------+-----------------------------------+ 2582 3.4.7. COUNTER 2584 The "COUNTER" method in a "VTODO" calendar component is used by an 2585 "Attendee" of an existing "VTODO" calendar component to submit to the 2586 "Organizer" a counter proposal for the "VTODO" calendar component. 2588 The counter proposal is an iCalendar object consisting of a "VTODO" 2589 calendar component describing the complete description of the 2590 alternate "VTODO" calendar component. 2592 The "Organizer" rejects the counter proposal by sending the 2593 "Attendee" a "DECLINECOUNTER" method. The "Organizer" accepts the 2594 counter proposal by rescheduling the to-do as described in section 2595 3.4.2.1 Rescheduling a To-Do. The "Organizers" CUA SHOULD send a 2596 "REQUEST" message to all "Attendees" affected by any change triggered 2597 by an accepted "COUNTER". 2599 This method type is an iCalendar object that conforms to the 2600 following property constraints: 2602 +---------------------------------------------+ 2603 | Constraints for a METHOD:COUNTER of a VTODO | 2604 +---------------------------------------------+ 2606 +--------------------+----------+-----------------------------------+ 2607 | Component/Property | Presence | Comment | 2608 +--------------------+----------+-----------------------------------+ 2609 | METHOD | 1 | MUST be "COUNTER" | 2610 | | | | 2611 | VTODO | 1 | | 2612 | ATTENDEE | 1+ | | 2613 | DTSTAMP | 1 | | 2614 | ORGANIZER | 1 | | 2615 | PRIORITY | 1 | | 2616 | SUMMARY | 1 | Can be null | 2617 | UID | 1 | | 2618 | ATTACH | 0+ | | 2619 | CATEGORIES | 0+ | | 2620 | CLASS | 0 or 1 | | 2621 | COMMENT | 0+ | | 2622 | COMPLETED | 0 or 1 | | 2623 | CONTACT | 0+ | | 2624 | CREATED | 0 or 1 | | 2625 | DESCRIPTION | 0 or 1 | Can be null | 2626 | DTSTART | 0 or 1 | | 2627 | DUE | 0 or 1 | If present DURATION MUST NOT be | 2628 | | | present | 2629 | DURATION | 0 or 1 | If present DUE MUST NOT be | 2630 | | | present | 2631 | EXDATE | 0+ | | 2632 | GEO | 0 or 1 | | 2633 | LAST-MODIFIED | 0 or 1 | | 2634 | LOCATION | 0 or 1 | | 2635 | PERCENT-COMPLETE | 0 or 1 | | 2636 | RDATE | 0+ | | 2637 | RECURRENCE-ID | 0 or 1 | Only if referring to an instance | 2638 | | | of a recurring calendar | 2639 | | | component. Otherwise it MUST NOT | 2640 | | | be present. | 2641 | RELATED-TO | 0+ | | 2642 | REQUEST-STATUS | 0+ | | 2643 | RESOURCES | 0+ | | 2644 | RRULE | 0 or 1 | | 2645 | SEQUENCE | 0 or 1 | MUST echo the original SEQUENCE | 2646 | | | number. MUST be present if | 2647 | | | non-zero. MAY be present if | 2648 | | | zero. | 2649 | STATUS | 0 or 1 | MAY be one of | 2650 | | | COMPLETED/NEEDS-ACTION/ | 2651 | | | IN-PROCESS/CANCELLED | 2652 | URL | 0 or 1 | | 2653 | IANA-PROPERTY | 0+ | | 2654 | X-PROPERTY | 0+ | | 2655 | | | | 2656 | VALARM | 0+ | | 2657 | | | | 2658 | VTIMEZONE | 0 or 1 | MUST be present if any date/time | 2659 | | | refers to a timezone | 2660 | | | | 2661 | IANA-COMPONENT | 0+ | | 2662 | X-COMPONENT | 0+ | | 2663 | | | | 2664 | VEVENT | 0 | | 2665 | | | | 2666 | VFREEBUSY | 0 | | 2667 +--------------------+----------+-----------------------------------+ 2669 3.4.8. DECLINECOUNTER 2671 The "DECLINECOUNTER" method in a "VTODO" calendar component is used 2672 by an "Organizer" of "VTODO" calendar component to reject a counter 2673 proposal offered by one of the "Attendees". The "Organizer" sends 2674 the message to the "Attendee" that sent the "COUNTER" method to the 2675 "Organizer". 2677 This method type is an iCalendar object that conforms to the 2678 following property constraints: 2680 +----------------------------------------------------+ 2681 | Constraints for a METHOD:DECLINECOUNTER of a VTODO | 2682 +----------------------------------------------------+ 2684 +--------------------+----------+-----------------------------------+ 2685 | Component/Property | Presence | Comment | 2686 +--------------------+----------+-----------------------------------+ 2687 | METHOD | 1 | MUST be "DECLINECOUNTER" | 2688 | | | | 2689 | VTODO | 1 | | 2690 | ATTENDEE | 1+ | MUST for all attendees | 2691 | DTSTAMP | 1 | | 2692 | ORGANIZER | 1 | | 2693 | SEQUENCE | 1 | MUST echo the original SEQUENCE | 2694 | | | number | 2695 | UID | 1 | MUST echo original UID | 2696 | ATTACH | 0+ | | 2697 | CATEGORIES | 0+ | | 2698 | CLASS | 0 or 1 | | 2699 | COMMENT | 0+ | | 2700 | COMPLETED | 0 or 1 | | 2701 | CONTACT | 0+ | | 2702 | CREATED | 0 or 1 | | 2703 | DESCRIPTION | 0 or 1 | | 2704 | DTSTART | 0 or 1 | | 2705 | DUE | 0 or 1 | If present DURATION MUST NOT be | 2706 | | | present | 2707 | DURATION | 0 or 1 | If present DUE MUST NOT be | 2708 | | | present | 2709 | EXDATE | 0+ | | 2710 | GEO | 0 or 1 | | 2711 | LAST-MODIFIED | 0 or 1 | | 2712 | LOCATION | 0 or 1 | | 2713 | PERCENT-COMPLETE | 0 or 1 | | 2714 | PRIORITY | 0 or 1 | | 2715 | RDATE | 0+ | | 2716 | RECURRENCE-ID | 0 or 1 | Only if referring to an instance | 2717 | | | of a recurring calendar | 2718 | | | component. Otherwise it MUST NOT | 2719 | | | be present. | 2720 | RELATED-TO | 0+ | | 2721 | REQUEST-STATUS | 0+ | | 2722 | RESOURCES | 0+ | | 2723 | RRULE | 0 or 1 | | 2724 | STATUS | 0 or 1 | MAY be one of | 2725 | | | COMPLETED/NEEDS-ACTION/ | 2726 | | | IN-PROCESS | 2727 | URL | 0 or 1 | | 2728 | IANA-PROPERTY | 0+ | | 2729 | X-PROPERTY | 0+ | | 2730 | | | | 2731 | VALARM | 0 | | 2732 | | | | 2733 | VTIMEZONE | 0+ | MUST be present if any date/time | 2734 | | | refers to a timezone | 2735 | | | | 2736 | IANA-COMPONENT | 0+ | | 2737 | X-COMPONENT | 0+ | | 2738 | | | | 2739 | VEVENT | 0 | | 2740 | | | | 2741 | VFREEBUSY | 0 | | 2742 +--------------------+----------+-----------------------------------+ 2744 3.5. Methods For VJOURNAL Components 2746 This section defines the property set for the methods that are 2747 applicable to the "VJOURNAL" calendar component. 2749 The following summarizes the methods that are defined for the 2750 "VJOURNAL" calendar component. 2752 +---------+---------------------------------------------------------+ 2753 | Method | Description | 2754 +---------+---------------------------------------------------------+ 2755 | PUBLISH | Post a journal entry. Used primarily as a method of | 2756 | | advertising the existence of a journal entry. | 2757 | | | 2758 | ADD | Add one or more instances to an existing journal entry. | 2759 | | | 2760 | CANCEL | Cancel one or more instances of an existing journal | 2761 | | entry. | 2762 +---------+---------------------------------------------------------+ 2764 3.5.1. PUBLISH 2766 The "PUBLISH" method in a "VJOURNAL" calendar component has no 2767 associated response. It is simply a posting of an iCalendar object 2768 that may be added to a calendar. It MUST have an "Organizer". It 2769 MUST NOT have "Attendees". The expected usage is for encapsulating 2770 an arbitrary journal entry as an iCalendar object. The "Organizer" 2771 MAY subsequently update (with another "PUBLISH" method) or cancel 2772 (with a "CANCEL" method) a previously published journal entry. 2774 This method type is an iCalendar object that conforms to the 2775 following property constraints: 2777 +------------------------------------------------+ 2778 | Constraints for a METHOD:PUBLISH of a VJOURNAL | 2779 +------------------------------------------------+ 2781 +--------------------+----------+-----------------------------------+ 2782 | Component/Property | Presence | Comment | 2783 +--------------------+----------+-----------------------------------+ 2784 | METHOD | 1 | MUST be "PUBLISH" | 2785 | | | | 2786 | VJOURNAL | 1+ | | 2787 | DESCRIPTION | 1 | Can be null. | 2788 | DTSTAMP | 1 | | 2789 | DTSTART | 1 | | 2790 | ORGANIZER | 1 | | 2791 | UID | 1 | | 2792 | ATTACH | 0+ | | 2793 | CATEGORIES | 0+ | | 2794 | CLASS | 0 or 1 | | 2795 | COMMENT | 0+ | | 2796 | CONTACT | 0+ | | 2797 | CREATED | 0 or 1 | | 2798 | EXDATE | 0+ | | 2799 | LAST-MODIFIED | 0 or 1 | | 2800 | RDATE | 0+ | | 2801 | RECURRENCE-ID | 0 or 1 | Only if referring to an instance | 2802 | | | of a recurring calendar | 2803 | | | component. Otherwise it MUST NOT | 2804 | | | be present. | 2805 | RELATED-TO | 0+ | | 2806 | RRULE | 0 or 1 | | 2807 | SEQUENCE | 0 or 1 | MUST be present if non-zero. MAY | 2808 | | | be present if zero. | 2809 | STATUS | 0 or 1 | MAY be one of | 2810 | | | DRAFT/FINAL/CANCELLED | 2811 | SUMMARY | 0 or 1 | Can be null | 2812 | URL | 0 or 1 | | 2813 | IANA-PROPERTY | 0+ | | 2814 | X-PROPERTY | 0+ | | 2815 | ATTENDEE | 0 | | 2816 | REQUEST-STATUS | 0 | | 2817 | | | | 2818 | VALARM | 0+ | | 2819 | | | | 2820 | VTIMEZONE | 0+ | MUST be present if any date/time | 2821 | | | refers to a timezone | 2822 | | | | 2823 | IANA-COMPONENT | 0+ | | 2824 | X-COMPONENT | 0+ | | 2825 | | | | 2826 | VEVENT | 0 | | 2827 | | | | 2828 | VFREEBUSY | 0 | | 2829 | | | | 2830 | VTODO | 0 | | 2831 +--------------------+----------+-----------------------------------+ 2833 3.5.2. ADD 2835 The "ADD" method allows the "Organizer" to add one or more new 2836 instances to an existing "VJOURNAL" using a single iTIP message 2837 without having to send the entire "VJOURNAL" with all the existing 2838 instance data, as it would have to do if the "REQUEST" method were 2839 used. 2841 The "UID" must be that of the existing journal entry. If the "UID" 2842 property value in the "ADD" is not found on the recipient's calendar, 2843 then the recipient MAY treat the "ADD" as a "PUBLISH". 2845 When handling an "ADD" message, the "Attendee" treats each component 2846 in the "ADD" message as if it were referenced via an "RDATE"in the 2847 main component. There is no response to the "Organizer". 2849 This method type is an iCalendar object that conforms to the 2850 following property constraints: 2852 +--------------------------------------------+ 2853 | Constraints for a METHOD:ADD of a VJOURNAL | 2854 +--------------------------------------------+ 2856 +--------------------+----------+-----------------------------------+ 2857 | Component/Property | Presence | Comment | 2858 +--------------------+----------+-----------------------------------+ 2859 | METHOD | 1 | MUST be "ADD" | 2860 | | | | 2861 | VJOURNAL | 1 | | 2862 | DESCRIPTION | 1 | Can be null | 2863 | DTSTAMP | 1 | | 2864 | DTSTART | 1 | | 2865 | ORGANIZER | 1 | | 2866 | SEQUENCE | 1 | MUST be greater than 0 | 2867 | UID | 1 | MUST match that of the original | 2868 | | | journal | 2869 | ATTACH | 0+ | | 2870 | CATEGORIES | 0+ | | 2871 | CLASS | 0 or 1 | | 2872 | COMMENT | 0+ | | 2873 | CONTACT | 0+ | | 2874 | CREATED | 0 or 1 | | 2875 | LAST-MODIFIED | 0 or 1 | | 2876 | RELATED-TO | 0+ | | 2877 | STATUS | 0 or 1 | MAY be one of | 2878 | | | DRAFT/FINAL/CANCELLED | 2879 | SUMMARY | 0 or 1 | Can be null | 2880 | URL | 0 or 1 | | 2881 | IANA-PROPERTY | 0+ | | 2882 | X-PROPERTY | 0+ | | 2883 | ATTENDEE | 0 | | 2884 | EXDATE | 0 | | 2885 | RECURRENCE-ID | 0 | | 2886 | REQUEST-STATUS | 0 | | 2887 | RDATE | 0 | | 2888 | RRULE | 0 | | 2889 | | | | 2890 | VALARM | 0+ | | 2891 | | | | 2892 | VTIMEZONE | 0 or 1 | MUST be present if any date/time | 2893 | | | refers to a timezone | 2894 | | | | 2895 | IANA-COMPONENT | 0+ | | 2896 | X-COMPONENT | 0+ | | 2897 | | | | 2898 | VEVENT | 0 | | 2899 | | | | 2900 | VFREEBUSY | 0 | | 2901 | | | | 2902 | VTODO | 0 | | 2903 +--------------------+----------+-----------------------------------+ 2905 3.5.3. CANCEL 2907 The "CANCEL" method in a "VJOURNAL" calendar component is used to 2908 send a cancellation notice of an existing journal entry. The message 2909 is sent by the "Organizer" of a journal entry. For a recurring 2910 journal entry, either the whole journal entry or instances of a 2911 journal entry may be cancelled. To cancel the complete range of a 2912 recurring journal entry, the "UID" property value for the journal 2913 entry MUST be specified and a "RECURRENCE-ID" property MUST NOT be 2914 specified in the "CANCEL" method. In order to cancel an individual 2915 instance of the journal entry, the "RECURRENCE-ID" property value for 2916 the journal entry MUST be specified in the "CANCEL" method. 2918 There are two options for canceling a sequence of instances of a 2919 recurring "VJOURNAL" calendar component: 2921 a. the "RECURRENCE-ID" property for an instance in the sequence MUST 2922 be specified with the "RANGE" property parameter value of 2923 "THISANDFUTURE" to indicate cancellation of the specified "VTODO" 2924 calendar component and all instances after 2925 b. individual recurrence instances may be cancelled by specifying 2926 multiple "VJOURNAL" components with a "RECURRENCE-ID" property 2927 corresponding to one of the instances to be cancelled 2929 When a "VJOURNAL" is cancelled, the "SEQUENCE" property value MUST be 2930 incremented as described in Section 2.1.4. 2932 This method type is an iCalendar object that conforms to the 2933 following property constraints: 2935 +-----------------------------------------------+ 2936 | Constraints for a METHOD:CANCEL of a VJOURNAL | 2937 +-----------------------------------------------+ 2939 +--------------------+----------+-----------------------------------+ 2940 | Component/Property | Presence | Comment | 2941 +--------------------+----------+-----------------------------------+ 2942 | METHOD | 1 | MUST be "CANCEL" | 2943 | | | | 2944 | VJOURNAL | 1+ | All MUST have the same UID | 2945 | DTSTAMP | 1 | | 2946 | ORGANIZER | 1 | | 2947 | SEQUENCE | 1 | | 2948 | UID | 1 | MUST be the UID of the original | 2949 | | | REQUEST | 2950 | ATTACH | 0+ | | 2951 | ATTENDEE | 0 | | 2952 | CATEGORIES | 0+ | | 2953 | CLASS | 0 or 1 | | 2954 | COMMENT | 0+ | | 2955 | CONTACT | 0+ | | 2956 | CREATED | 0 or 1 | | 2957 | DESCRIPTION | 0 or 1 | | 2958 | DTSTART | 0 or 1 | | 2959 | EXDATE | 0+ | | 2960 | LAST-MODIFIED | 0 or 1 | | 2961 | RDATE | 0+ | | 2962 | RECURRENCE-ID | 0 or 1 | Only if referring to an instance | 2963 | | | of a recurring calendar | 2964 | | | component. Otherwise it MUST NOT | 2965 | | | be present. | 2966 | RELATED-TO | 0+ | | 2967 | RRULE | 0 or 1 | | 2968 | STATUS | 0 or 1 | MAY be present, must be | 2969 | | | "CANCELLED" if present | 2970 | SUMMARY | 0 or 1 | | 2971 | URL | 0 or 1 | | 2972 | IANA-PROPERTY | 0+ | | 2973 | X-PROPERTY | 0+ | | 2974 | REQUEST-STATUS | 0 | | 2975 | | | | 2976 | VALARM | 0 | | 2977 | | | | 2978 | VTIMEZONE | 0+ | MUST be present if any date/time | 2979 | | | refers to a timezone | 2980 | | | | 2981 | IANA-COMPONENT | 0+ | | 2982 | X-COMPONENT | 0+ | | 2983 | | | | 2984 | VEVENT | 0 | | 2985 | | | | 2986 | VFREEBUSY | 0 | | 2987 | | | | 2988 | VTODO | 0 | | 2989 +--------------------+----------+-----------------------------------+ 2991 3.6. Status Replies 2993 The "REQUEST-STATUS" property is used to convey status information 2994 about a REPLY, COUNTER or DECLINECOUNTER iTIP message. The codes 2995 listed in the table below SHOULD be used. If the "REQUEST-STATUS" 2996 property is not present in one of these iTIP messages, then a status 2997 code of "2.0" (success) MUST be assumed. 2999 This specification adds a new IANA registry for REQUEST-STATUS 3000 values, as defined in Section 7, which includes a new registration 3001 template for defining the specific components of the REQUEST-STATUS 3002 value. Additional codes MAY be used provided the process described 3003 in Section 8.2.1 of [RFC5545] is used to register them. 3005 This specification allows for multiple "REQUEST-STATUS" properties to 3006 be returned in iCalendar components in the appropriate iTIP messages. 3007 When multiple "REQUEST-STATUS" properties are present, the following 3008 restrictions apply: 3010 1. Within any one component, the "top-level" numeric value of the 3011 "short return status code" MUST be the same for all REQUEST- 3012 STATUS properties. i.e. there cannot be a mixture of e.g., 2.xx 3013 and 5.xx codes within a single component. 3014 2. Across all components in the iTIP message, the following applies: 3015 A. If any one component would have a 5.xx code, then all 3016 components MUST have a code in that range or "REQUEST-STATUS" 3017 MUST NOT be present in the other components if a 5.xx code is 3018 not appropriate for those components. 3019 B. Otherwise, if any one component would have a 3.xx code, then 3020 all components MUST have a code in that range or "REQUEST- 3021 STATUS" MUST NOT be present in the other components if a 3.xx 3022 code is not appropriate for those components. 3023 C. 2.xx and 4.xx codes can be used in different components 3024 provided that each component follows the restriction in (1) 3025 above. 3027 The following "REQUEST-STATUS" codes are defined (any "Offending 3028 Data" MAY be specified in the "REQUEST-STATUS" value as the extdata 3029 field): 3031 3.6.1. Status Code 2.0 3032 Status Code: 2.0 3033 Status Description: Success. 3034 Status Exception Data: None. 3035 Description: iTIP operation succeeded. 3037 3.6.2. Status Code 2.1 3039 Status Code: 2.1 3040 Status Description: Success but fallback taken on one or more 3041 property values. 3042 Status Exception Data: Property name and value MAY be specified. 3043 Description: iTIP operation succeeded with fallback on one or more 3044 property values. 3046 3.6.3. Status Code 2.2 3048 Status Code: 2.2 3049 Status Description: Success, invalid property ignored. 3050 Status Exception Data: Property name MAY be specified. 3051 Description: iTIP operation succeeded but a property was ignored. 3053 3.6.4. Status Code 2.3 3055 Status Code: 2.3 3056 Status Description: Success, invalid property parameter ignored. 3057 Status Exception Data: Property parameter name and value MAY be 3058 specified. 3059 Description: iTIP operation succeeded but a property parameter was 3060 ignored because it was invalid. 3062 3.6.5. Status Code 2.4 3064 Status Code: 2.4 3065 Status Description: Success, unknown non-standard property ignored. 3066 Status Exception Data: Non-standard property name MAY be specified. 3067 Description: iTIP operation succeeded but a property parameter was 3068 ignored because it was unknown. 3070 3.6.6. Status Code 2.5 3072 Status Code: 2.5 3073 Status Description: Success, unknown non-standard property value 3074 ignored. 3075 Status Exception Data: Property and non-standard value MAY be 3076 specified. 3078 Description: iTIP operation succeeded but a property was ignored 3079 because its value was unknown. 3081 3.6.7. Status Code 2.6 3083 Status Code: 2.6 3084 Status Description: Success, invalid calendar component ignored. 3085 Status Exception Data: Calendar component sentinel (e.g., BEGIN: 3086 ALARM) MAY be specified. 3087 Description: iTIP operation succeeded but a component was ignored 3088 because it was invalid. 3090 3.6.8. Status Code 2.7 3092 Status Code: 2.7 3093 Status Description: Success, request forwarded to Calendar User. 3094 Status Exception Data: Original and forwarded calendar user 3095 addresses MAY be specified. 3096 Description: iTIP operation succeeded, and the request was forwarded 3097 to another calendar user. 3099 3.6.9. Status Code 2.8 3101 Status Code: 2.8 3102 Status Description: Success, repeating event ignored. Scheduled as 3103 a single component. 3104 Status Exception Data: RRULE or RDATE property name and value MAY be 3105 specified. 3106 Description: iTIP operation succeeded, but a repeating event was 3107 truncated to a single instance. 3109 3.6.10. Status Code 2.9 3111 Status Code: 2.9 3112 Status Description: Success, truncated end date time to date 3113 boundary. 3114 Status Exception Data: DTEND property value MAY be specified. 3115 Description: iTIP operation succeeded, but the end time was 3116 truncated to a date boundary. 3118 3.6.11. Status Code 2.10 3120 Status Code: 2.10 3121 Status Description: Success, repeating VTODO ignored. Scheduled as 3122 a single VTODO. 3124 Status Exception Data: RRULE or RDATE property name and value MAY be 3125 specified. 3126 Description: iTIP operation succeeded, but a repeating todo was 3127 truncated to a single instance. 3129 3.6.12. Status Code 2.11 3131 Status Code: 2.11 3132 Status Description: Success, unbounded RRULE clipped at some finite 3133 number of instances. 3134 Status Exception Data: RRULE property name and value MAY be 3135 specified. Number of instances MAY also be specified. 3136 Description: iTIP operation succeeded, but an unbounded repeating 3137 object was clipped to a finite number of instances. 3139 3.6.13. Status Code 3.0 3141 Status Code: 3.0 3142 Status Description: Invalid property name. 3143 Status Exception Data: Property name MAY be specified. 3144 Description: iTIP operation failed because of an invalid property 3145 name. 3147 3.6.14. Status Code 3.1 3149 Status Code: 3.1 3150 Status Description: Invalid property value. 3151 Status Exception Data: Property name and value MAY be specified. 3152 Description: iTIP operation failed because of an invalid property 3153 value. 3155 3.6.15. Status Code 3.2 3157 Status Code: 3.2 3158 Status Description: Invalid property parameter. 3159 Status Exception Data: Property parameter name and value MAY be 3160 specified. 3161 Description: iTIP operation failed because of an invalid property 3162 parameter. 3164 3.6.16. Status Code 3.3 3166 Status Code: 3.3 3167 Status Description: Invalid property parameter value. 3169 Status Exception Data: Property parameter name and value MAY be 3170 specified. 3171 Description: iTIP operation failed because of an invalid property 3172 parameter value. 3174 3.6.17. Status Code 3.4 3176 Status Code: 3.4 3177 Status Description: Invalid calendar component sequence. 3178 Status Exception Data: Calendar component sentinel MAY be specified 3179 (e.g., BEGIN:VTIMEZONE). 3180 Description: iTIP operation failed because of an invalid component. 3182 3.6.18. Status Code 3.5 3184 Status Code: 3.5 3185 Status Description: Invalid date or time. 3186 Status Exception Data: Date/time value(s) MAY be specified. 3187 Description: iTIP operation failed because of an invalid date or 3188 time property. 3190 3.6.19. Status Code 3.6 3192 Status Code: 3.6 3193 Status Description: Invalid rule. 3194 Status Exception Data: Rule value MAY be specified. 3195 Description: iTIP operation failed because of an invalid rule 3196 property. 3198 3.6.20. Status Code 3.7 3200 Status Code: 3.7 3201 Status Description: Invalid Calendar User. 3202 Status Exception Data: Attendee property value MAY be specified. 3203 Description: iTIP operation failed because of an invalid Attendee 3204 property. 3206 3.6.21. Status Code 3.8 3208 Status Code: 3.8 3209 Status Description: No authority. 3210 Status Exception Data: METHOD and Attendee property values MAY be 3211 specified. 3212 Description: iTIP operation failed because an Attendee does not have 3213 suitable privileges for the operation. 3215 3.6.22. Status Code 3.9 3217 Status Code: 3.9 3218 Status Description: Unsupported version. 3219 Status Exception Data: VERSION property name and value MAY be 3220 specified. 3221 Description: iTIP operation failed because the calendar data version 3222 is not supported. 3224 3.6.23. Status Code 3.10 3226 Status Code: 3.10 3227 Status Description: Request entity too large. 3228 Status Exception Data: Request entity too large. 3229 Description: iTIP operation failed because the calendar data was too 3230 large. 3232 3.6.24. Status Code 3.11 3234 Status Code: 3.11 3235 Status Description: Required component or property missing. 3236 Status Exception Data: Component or property name MAY be specified. 3237 Description: iTIP operation failed because the calendar data did not 3238 contain a required property or component. 3240 3.6.25. Status Code 3.12 3242 Status Code: 3.12 3243 Status Description: Unknown component or property found. 3244 Status Exception Data: Component or property name MAY be specified. 3245 Description: iTIP operation failed because the calendar data 3246 contained an unknown property or component. 3248 3.6.26. Status Code 3.13 3250 Status Code: 3.13 3251 Status Description: Unsupported component or property found. 3252 Status Exception Data: Component or property name MAY be specified. 3253 Description: iTIP operation failed because the calendar data 3254 contained an unsupported property or component. 3256 3.6.27. Status Code 3.14 3258 Status Code: 3.14 3259 Status Description: Unsupported capability. 3260 Status Exception Data: METHOD or action MAY be specified. 3261 Description: iTIP operation failed because the operation is not 3262 supported. 3264 3.6.28. Status Code 4.0 3266 Status Code: 4.0 3267 Status Description: Event conflict. Date/time is busy. 3268 Status Exception Data: DTSTART and DTEND property name and values 3269 MAY be specified. 3270 Description: iTIP operation failed because the event overlaps the 3271 date and time of another event. 3273 3.6.29. Status Code 5.0 3275 Status Code: 5.0 3276 Status Description: Request not supported. 3277 Status Exception Data: METHOD property value MAY be specified. 3278 Description: iTIP operation failed because the operation is not 3279 supported. 3281 3.6.30. Status Code 5.1 3283 Status Code: 5.1 3284 Status Description: Service unavailable. 3285 Status Exception Data: ATTENDEE property value MAY be specified. 3286 Description: iTIP operation failed because scheduling is not active. 3288 3.6.31. Status Code 5.2 3290 Status Code: 5.2 3291 Status Description: Invalid calendar service. 3292 Status Exception Data: ATTENDEE property value MAY be specified. 3293 Description: iTIP operation failed because there is no scheduling 3294 capability. 3296 3.6.32. Status Code 5.3 3298 Status Code: 5.3 3299 Status Description: No scheduling support for user. 3300 Status Exception Data: ATTENDEE property value MAY be specified. 3301 Description: iTIP operation failed because scheduling is not enabled 3302 for an Attendee. 3304 3.7. Implementation Considerations 3306 3.7.1. Working With Recurrence Instances 3308 iCalendar includes a recurrence grammar to represent recurring 3309 events. The benefit of such a grammar is the ability to represent a 3310 number of events in a single object. However, while this simplifies 3311 creation of a recurring event, meeting instances still need to be 3312 referenced. For instance, an "Attendee" may decline the third 3313 instance of a recurring Friday event. Similarly, the "Organizer" may 3314 change the time or location to a single instance of the recurring 3315 event. 3317 Since implementations may elect to store recurring events as either a 3318 single event object or a collection of discrete, related event 3319 objects, the protocol is designed so that each recurring instance may 3320 be both referenced and versioned. Hence, implementations that choose 3321 to maintain per-instance properties (such as "ATTENDEE" property 3322 "PARTSTAT" parameter) may do so. However, the protocol does not 3323 require per-instance recognition unless the instance itself must be 3324 renegotiated. 3326 The scenarios for recurrence instance referencing are listed below. 3327 For purposes of simplification a change to an event refers to a 3328 "trigger property." That is, a property that has a substantive 3329 effect on the meeting itself such as start time, location, due date 3330 (for "VTODO" calendar component components) and possibly description. 3332 "Organizer" initiated actions: 3334 o "Organizer" deletes or changes a single instance of a recurring 3335 event 3336 o "Organizer" makes changes that affect all future instances 3337 o "Organizer" makes changes that affect all previous instances 3338 o "Organizer" deletes or modifies a previously changed instance 3340 "Attendee" initiated actions: 3342 o "Attendee" changes status for a particular recurrence instance 3343 o "Attendee" sends event-Counter for a particular recurrence 3344 instance 3346 An instance of a recurring event is assigned a unique identification, 3347 "RECURRENCE-ID" property, when that instance is renegotiated. 3348 Negotiation may be necessary when a substantive change to the event 3349 or to-do has been made (such as changing the start time, end time, 3350 due date or location). The "Organizer" can identify a specific 3351 recurrence instance using the "RECURRENCE-ID" property. The property 3352 value is equal to the date/time of the instance. If the "Organizer" 3353 wishes to change the "DTSTART", the original unmodified "DTSTART" 3354 value of the instance is used as the value "RECURRENCE-ID" property 3355 and the new "DTSTART" and "DTEND" values reflect the change. 3357 3.7.2. Attendee Property Considerations 3359 The "ORGANIZER" property is required on published events, to-dos, and 3360 journal entries for two reasons. First, only the "Organizer" is 3361 allowed to update and redistribute an event or to-do component. It 3362 follows that the "ORGANIZER" property MUST be present in the event, 3363 to-do, or journal entry component so that the CUA has a basis for 3364 authorizing an update. Second, it is prudent to provide a point of 3365 contact for anyone who receives a published component in case of 3366 problems. 3368 Email addresses that correspond to groups of calendar users could be 3369 specified as a mailto: URI [RFC2368] calendar user address. Sending 3370 email to such an address results in email being sent to multiple 3371 recipients. Such an address may be used as the value of an 3372 "ATTENDEE" property. Thus, it is possible that the recipient of a 3373 "REQUEST" does not appear explicitly in the list. 3375 It is recommended that the general approach to finding a "Calendar 3376 User" in an attendee list be as follows: 3378 1. Search for the "Calendar User" in the attendee list where 3379 "CUTYPE=INDIVIDUAL" 3380 2. Failing (1) look for attendees where "CUTYPE=GROUP" or 3381 'CUTYPE=UNKNOWN". The CUA then determines if the "Calendar User" 3382 is a member of one of these groups. If so, the "REPLY" method 3383 sent to the "Organizer" MUST contain a new "ATTENDEE" property in 3384 which: 3385 3. 3386 * the "TYPE" property parameter is set to INDIVIDUAL 3387 * the "MEMBER" property parameter is set to the name of the 3388 group 3389 4. Failing (2) the CUA MAY ignore or accept the request as the 3390 "Calendar User" wishes. 3392 3.7.3. Extension Tokens 3394 To make iCalendar objects extensible, new component, property or 3395 property parameters can be used. Two types of extension exist: IANA 3396 registered tokens and X- vendor-specific tokens. A client SHOULD 3397 save IANA tokens and MAY use them in replies. A client MAY save X- 3398 Tokens and MAY use them in replies. When delegating or forwarding 3399 messages to other CUs, a client SHOULD include IANA and X- tokens. 3401 4. Examples 3403 4.1. Published Event Examples 3405 In the calendaring and scheduling context, publication refers to the 3406 one way transfer of event information. Consumers of published events 3407 simply incorporate the event into a calendar. No reply is expected. 3408 Individual "A" publishes an event. Individual "B" reads the event 3409 and incorporates it into their calendar. Events are published in 3410 several ways including: embedding the event as an object in a web 3411 page, e-mailing the event to a distribution list, or posting the 3412 event to a newsgroup. 3414 The table below illustrates the sequence of events between the 3415 publisher and the consumers of a published event. 3417 +-----------------+-----------------------+-------------------------+ 3418 | Action | Organizer | Receiver | 3419 +-----------------+-----------------------+-------------------------+ 3420 | Publish an | "A" sends or posts a | "B" reads a published | 3421 | event | PUBLISH message | event | 3422 | | | | 3423 | Publish an | "A" sends or posts a | "B" reads the updated | 3424 | updated event | PUBLISH message | event | 3425 | | | | 3426 | Cancel a | "A" sends or posts a | "B" reads the canceled | 3427 | published event | CANCEL message | event publication | 3428 +-----------------+-----------------------+-------------------------+ 3430 4.1.1. A Minimal Published Event 3432 The iCalendar object below describes a single event that begins on 3433 July 1, 1997 at 20:00 UTC. This event contains the minimum set of 3434 properties for a "PUBLISH" for a "VEVENT" calendar component. 3436 BEGIN:VCALENDAR 3437 METHOD:PUBLISH 3438 PRODID:-//Example/ExampleCalendarClient//EN 3439 VERSION:2.0 3440 BEGIN:VEVENT 3441 ORGANIZER:mailto:a@example.com 3442 DTSTART:19970701T200000Z 3443 DTSTAMP:19970611T190000Z 3444 SUMMARY:ST. PAUL SAINTS -VS- DULUTH-SUPERIOR DUKES 3445 UID:0981234-1234234-23@example.com 3446 END:VEVENT 3447 END:VCALENDAR 3449 4.1.2. Changing A Published Event 3451 The iCalendar object below describes an update to the event described 3452 in 4.1.1, the time has been changed, an end time has been added, and 3453 the sequence number has been adjusted. 3455 BEGIN:VCALENDAR 3456 METHOD:PUBLISH 3457 VERSION:2.0 3458 PRODID:-//Example/ExampleCalendarClient//EN 3459 BEGIN:VEVENT 3460 ORGANIZER:mailto:a@example.com 3461 DTSTAMP:19970612T190000Z 3462 DTSTART:19970701T210000Z 3463 DTEND:19970701T230000Z 3464 SEQUENCE:1 3465 UID:0981234-1234234-23@example.com 3466 SUMMARY:ST. PAUL SAINTS -VS- DULUTH-SUPERIOR DUKES 3467 END:VEVENT 3468 END:VCALENDAR 3470 The "UID" property is used by the client to identify the event. The 3471 "SEQUENCE" property indicates that this is a change to the event. 3472 The event with a matching UID and sequence number 0 is superseded by 3473 this event. 3475 The "SEQUENCE" property provides a reliable way to distinguish 3476 different versions of the same event. Each time an event is 3477 published, its sequence number is incremented. If a client receives 3478 an event with a sequence number 5 and finds it has the same event 3479 with sequence number 2, the event SHOULD be updated. However, if the 3480 client received an event with sequence number 2 and finds it already 3481 has sequence number 5 of the same event, the event MUST NOT be 3482 updated. 3484 4.1.3. Canceling A Published Event 3486 The iCalendar object below cancels the event described in 4.1.1. 3487 This cancels the event with "SEQUENCE" property of 0, 1, and 2. 3489 BEGIN:VCALENDAR 3490 METHOD:CANCEL 3491 VERSION:2.0 3492 PRODID:-//Example/ExampleCalendarClient//EN 3493 BEGIN:VEVENT 3494 ORGANIZER:mailto:a@example.com 3495 COMMENT:DUKES forfeit the game 3496 SEQUENCE:2 3497 UID:0981234-1234234-23@example.com 3498 DTSTAMP:19970613T190000Z 3499 END:VEVENT 3500 END:VCALENDAR 3502 4.1.4. A Rich Published Event 3504 This example describes the same event as in 4.1.1, but in much 3505 greater detail. 3507 BEGIN:VCALENDAR 3508 PRODID:-//Example/ExampleCalendarClient//EN 3509 METHOD:PUBLISH 3510 SCALE:GREGORIAN 3511 VERSION:2.0 3512 BEGIN:VTIMEZONE 3513 TZID:America-Chicago 3514 TZURL:http://example.com/tz/America-Chicago 3515 BEGIN:STANDARD 3516 DTSTART:19671029T020000 3517 RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=10 3518 TZOFFSETFROM:-0500 3519 TZOFFSETTO:-0600 3520 TZNAME:CST 3521 END:STANDARD 3522 BEGIN:DAYLIGHT 3523 DTSTART:19870405T020000 3524 RRULE:FREQ=YEARLY;BYDAY=1SU;BYMONTH=4 3525 TZOFFSETFROM:-0600 3526 TZOFFSETTO:-0500 3527 TZNAME:CDT 3528 END:DAYLIGHT 3529 END:VTIMEZONE 3530 BEGIN:VEVENT 3531 ORGANIZER:mailto:a@example.com 3532 ATTACH:http://www.example.com/ 3533 CATEGORIES:SPORTS EVENT,ENTERTAINMENT 3534 CLASS:PRIVATE 3535 DESCRIPTION:MIDWAY STADIUM\n 3536 Big time game. MUST see.\n 3537 Expected duration:2 hours\n 3538 DTEND;TZID=America-Chicago:19970701T180000 3539 DTSTART;TZID=America-Chicago:19970702T160000 3540 DTSTAMP:19970614T190000Z 3541 STATUS:CONFIRMED 3542 LOCATION;VALUE=URI:http://stadium.example.com/ 3543 PRIORITY:2 3544 RESOURCES:SCOREBOARD 3545 SEQUENCE:3 3546 SUMMARY:ST. PAUL SAINTS -VS- DULUTH-SUPERIOR DUKES 3547 UID:0981234-1234234-23@example.com 3548 RELATED-TO:0981234-1234234-14@example.com 3549 BEGIN:VALARM 3550 TRIGGER:-PT2H 3551 ACTION:DISPLAY 3552 DESCRIPTION:You should be leaving for the game now. 3553 END:VALARM 3554 BEGIN:VALARM 3555 TRIGGER:-PT30M 3556 ACTION:AUDIO 3557 END:VALARM 3558 END:VEVENT 3559 END:VCALENDAR 3561 The "RELATED-TO" field contains the "UID" property of a related 3562 calendar event. The "SEQUENCE" property 3 indicates that this event 3563 supersedes versions 0, 1, and 2. 3565 4.1.5. Anniversaries or Events attached to entire days 3567 This example demonstrates the use of the "VALUE" parameter to tie a 3568 "VEVENT" to day rather than a specific time. 3570 BEGIN:VCALENDAR 3571 PRODID:-//Example/ExampleCalendarClient//EN 3572 METHOD:PUBLISH 3573 VERSION:2.0 3574 BEGIN:VEVENT 3575 ORGANIZER:mailto:a@example.com 3576 DTSTAMP:19970614T190000Z 3577 UID:0981234-1234234-23@example.com 3578 DTSTART;VALUE=DATE:19970714 3579 RRULE:FREQ=YEARLY;INTERVAL=1 3580 SUMMARY: Bastille Day 3581 END:VEVENT 3582 END:VCALENDAR 3584 4.2. Group Event Examples 3586 Group events are distinguished from published events in that they 3587 have "Attendees" and that there is interaction between the 3588 "Attendees" and the "Organizer" with respect to the event. 3589 Individual "A" requests a meeting between individuals "A", "B", "C" 3590 and "D". Individual "B" confirms attendance to the meeting. 3591 Individual "C" declines attendance. Individual "D" tentatively 3592 confirms attendance. The following table illustrates the the message 3593 flow between these individuals. A, the CU scheduling the meeting, is 3594 referenced as the "Organizer". 3596 +--------------+-----------------------+----------------------------+ 3597 | Action | "Organizer" | Attendee | 3598 +--------------+-----------------------+----------------------------+ 3599 | Initiate a | "A" sends a REQUEST | | 3600 | meeting | message to "B", "C", | | 3601 | request | and "D" | | 3602 | | | | 3603 | Accept the | | "B" sends a REPLY message | 3604 | meeting | | to "A" with its ATTENDEE | 3605 | request | | "PARTSTAT" parameter set | 3606 | | | to "ACCEPTED" | 3607 | | | | 3608 | Decline the | | "C" sends a REPLY message | 3609 | meeting | | to "A" with its ATTENDEE | 3610 | request | | "PARTSTAT" parameter set | 3611 | | | to "DECLINED" | 3612 | | | | 3613 | Tentatively | | "D" sends a REPLY message | 3614 | accept the | | to "A" with its ATTENDEE | 3615 | meeting | | "PARTSTAT" parameter set | 3616 | request | | to "TENTATIVE" | 3617 | | | | 3618 | Confirm | "A" sends a REQUEST | | 3619 | meeting | message to "B" and | | 3620 | status with | "D" with updated | | 3621 | attendees | information. | | 3622 +--------------+-----------------------+----------------------------+ 3624 4.2.1. A Group Event Request 3626 A sample meeting request is sent from "A" to "B", "C", and "D". "E" 3627 is also sent a copy of the request but is not expected to attend and 3628 need not reply. "E" illustrates how CUAs might implement an "FYI" 3629 type feature. Note the use of the "ROLE" parameter. The default 3630 value for the "ROLE" parameter is "REQ-PARTICIPANT" and it need not 3631 be enumerated. In this case we are using the value "NON-PARTICIPANT" 3632 to indicate "E" is a non-attending CU. The parameter is not needed 3633 on other "Attendees" since "PARTICIPANT" is the default value. 3635 BEGIN:VCALENDAR 3636 PRODID:-//Example/ExampleCalendarClient//EN 3637 METHOD:REQUEST 3638 VERSION:2.0 3639 BEGIN:VEVENT 3640 ORGANIZER:mailto:a@example.com 3641 ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED;CN=A:mailto:a@example.com 3642 ATTENDEE;RSVP=TRUE;CUTYPE=INDIVIDUAL;CN=B:mailto:b@example.com 3643 ATTENDEE;RSVP=TRUE;CUTYPE=INDIVIDUAL;CN=C:mailto:c@example.com 3644 ATTENDEE;RSVP=TRUE;CUTYPE=INDIVIDUAL;CN=Hal:mailto:d@example.com 3645 ATTENDEE;RSVP=FALSE;CUTYPE=ROOM:conf_big@example.com 3646 ATTENDEE;ROLE=NON-PARTICIPANT;RSVP=FALSE:mailto:e@example.com 3647 DTSTAMP:19970611T190000Z 3648 DTSTART:19970701T200000Z 3649 DTEND:19970701T2100000Z 3650 SUMMARY:Conference 3651 UID:calsrv.example.com-873970198738777@example.com 3652 SEQUENCE:0 3653 STATUS:CONFIRMED 3654 END:VEVENT 3655 END:VCALENDAR 3657 4.2.2. Reply To A Group Event Request 3659 Attendee "B" accepts the meeting. 3661 BEGIN:VCALENDAR 3662 PRODID:-//Example/ExampleCalendarClient//EN 3663 METHOD:REPLY 3664 VERSION:2.0 3665 BEGIN:VEVENT 3666 ATTENDEE;PARTSTAT=ACCEPTED:mailto:b@example.com 3667 ORGANIZER:mailto:a@example.com 3668 UID:calsrv.example.com-873970198738777@example.com 3669 SEQUENCE:0 3670 REQUEST-STATUS:2.0;Success 3671 DTSTAMP:19970612T190000Z 3672 END:VEVENT 3673 END:VCALENDAR 3675 "B" could have declined the meeting or indicated tentative acceptance 3676 by setting the "ATTENDEE" "PARTSTAT" parameter to "DECLINED" or 3677 "TENTATIVE", respectively. Also, "REQUEST-STATUS" is not required in 3678 successful transactions. 3680 4.2.3. Update An Event 3682 The event is moved to a different time. The combination of the "UID" 3683 property (unchanged) and the "SEQUENCE" (bumped to 1) properties 3684 indicate the update. 3686 BEGIN:VCALENDAR 3687 PRODID:-//Example/ExampleCalendarClient//EN 3688 METHOD:REQUEST 3689 VERSION:2.0 3690 BEGIN:VEVENT 3691 ORGANIZER:mailto:a@example.com 3692 ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:mailto:a@example.com 3693 ATTENDEE;RSVP=TRUE;CUTYPE=INDIVIDUAL:mailto:b@example.com 3694 ATTENDEE;RSVP=TRUE;CUTYPE=INDIVIDUAL:mailto:c@example.com 3695 ATTENDEE;RSVP=TRUE;CUTYPE=INDIVIDUAL;CN=Hal:mailto:d@example.com 3696 ATTENDEE;ROLE=NON-PARTICIPANT;RSVP=FALSE; 3697 CUTYPE=ROOM:mailto:conf@example.com 3698 ATTENDEE;ROLE=NON-PARTICIPANT;RSVP=FALSE:mailto:e@example.com 3699 DTSTART:19970701T180000Z 3700 DTEND:19970701T190000Z 3701 SUMMARY:Phone Conference 3702 UID:calsrv.example.com-873970198738777@example.com 3703 SEQUENCE:1 3704 DTSTAMP:19970613T190000Z 3705 STATUS:CONFIRMED 3706 END:VEVENT 3707 END:VCALENDAR 3709 4.2.4. Countering an Event Proposal 3711 "A" sends a "REQUEST" to "B" and "C". "B" makes a counter-proposal 3712 to "A" to change the time and location. 3714 "A" sends the following "REQUEST": 3716 BEGIN:VCALENDAR 3717 PRODID:-//Example/ExampleCalendarClient//EN 3718 METHOD:REQUEST 3719 VERSION:2.0 3720 BEGIN:VEVENT 3721 ORGANIZER:mailto:a@example.com 3722 ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:mailto:a@example.com 3723 ATTENDEE;RSVP=TRUE;CUTYPE=INDIVIDUAL:mailto:b@example.com 3724 ATTENDEE;RSVP=TRUE;CUTYPE=INDIVIDUAL:mailto:c@example.com 3725 DTSTART:19970701T190000Z 3726 DTEND:19970701T200000Z 3727 SUMMARY:Discuss the Merits of the election results 3728 LOCATION:Green Conference Room 3729 UID:calsrv.example.com-873970198738777a@example.com 3730 SEQUENCE:0 3731 DTSTAMP:19970611T190000Z 3732 STATUS:CONFIRMED 3733 END:VEVENT 3734 END:VCALENDAR 3736 "B" sends "COUNTER" to "A", requesting changes to time and place. 3737 "B" uses the "COMMENT" property to communicate a rationale for the 3738 change. Note that the "SEQUENCE" property is NOT incremented on a 3739 "COUNTER". 3741 BEGIN:VCALENDAR 3742 PRODID:-//Example/ExampleCalendarClient//EN 3743 METHOD:COUNTER 3744 VERSION:2.0 3745 BEGIN:VEVENT 3746 ORGANIZER:mailto:a@example.com 3747 ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:mailto:a@example.com 3748 ATTENDEE;RSVP=TRUE;CUTYPE=INDIVIDUAL:mailto:b@example.com 3749 ATTENDEE;RSVP=TRUE;CUTYPE=INDIVIDUAL:mailto:c@example.com 3750 DTSTART:19970701T160000Z 3751 DTEND:19970701T170000Z 3752 DTSTAMP:19970612T190000Z 3753 SUMMARY:Discuss the Merits of the election results 3754 LOCATION:Blue Conference Room 3755 COMMENT:This time works much better and I think the big conference 3756 room is too big 3757 UID:calsrv.example.com-873970198738777a@example.com 3758 SEQUENCE:0 3759 END:VEVENT 3760 END:VCALENDAR 3762 "A" accepts the changes from "B". To accept a counter-proposal, the 3763 "Organizer" sends a new event "REQUEST" with an incremented sequence 3764 number. 3766 BEGIN:VCALENDAR 3767 PRODID:-//Example/ExampleCalendarClient//EN 3768 METHOD:REQUEST 3769 VERSION:2.0 3770 BEGIN:VEVENT 3771 ORGANIZER:mailto:a@example.com 3772 ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:mailto:a@example.com 3773 ATTENDEE;RSVP=TRUE;CUTYPE=INDIVIDUAL:mailto:b@example.com 3774 ATTENDEE;RSVP=TRUE;CUTYPE=INDIVIDUAL:mailto:c@example.com 3775 DTSTAMP:19970613T190000Z 3776 DTSTART:19970701T160000Z 3777 DTEND:19970701T170000Z 3778 SUMMARY:Discuss the Merits of the election results - changed to 3779 meet B's schedule 3780 LOCATION:Blue Conference Room 3781 UID:calsrv.example.com-873970198738777@example.com 3782 SEQUENCE:1 3783 STATUS:CONFIRMED 3784 END:VEVENT 3785 END:VCALENDAR 3787 Instead, "A" rejects "B's" counter proposal 3789 BEGIN:VCALENDAR 3790 PRODID:-//Example/ExampleCalendarClient//EN 3791 METHOD:DECLINECOUNTER 3792 VERSION:2.0 3793 BEGIN:VEVENT 3794 ORGANIZER:mailto:a@example.com 3795 ATTENDEE;RSVP=TRUE;CUTYPE=INDIVIDUAL:mailto:b@example.com 3796 COMMENT:Sorry, I cannot change this meeting time 3797 UID:calsrv.example.com-873970198738777@example.com 3798 SEQUENCE:0 3799 DTSTAMP:19970614T190000Z 3800 END:VEVENT 3801 END:VCALENDAR 3803 4.2.5. Delegating an Event 3805 When delegating an event request to another "Calendar User", the 3806 "Delegator" must both update the "Organizer" with a "REPLY" and send 3807 a request to the "Delegate". There is currently no protocol 3808 limitation to delegation depth. It is possible for the original 3809 delegate to delegate the meeting to someone else, and so on. When a 3810 request is delegated from one CUA to another there are a number of 3811 responsibilities required of the "Delegator". The "Delegator" MUST: 3813 o Send a "REPLY" to the "Organizer" with the following updates: 3814 A. The "Delegator's" "ATTENDEE" property "PARTSTAT" parameter set 3815 to "DELEGATED" and the "DELEGATED-TO" parameter is set to the 3816 address of the "Delegate" 3817 B. Add an additional "ATTENDEE" property for the "Delegate" with 3818 the "DELEGATED-FROM" property parameter set to the "Delegator" 3819 C. Indicate whether they want to continue to receive updates when 3820 the "Organizer" sends out updated versions of the event. 3821 Setting the "RSVP" property parameter to "TRUE" will cause the 3822 updates to be sent, setting it to "FALSE" causes no further 3823 updates to be sent. Note that in either case, if the 3824 "Delegate" declines the invitation the "Delegator" will be 3825 notified. 3826 o The "Delegator" MUST also send a copy of the original "REQUEST" 3827 method to the "Delegate", with changes (A) and (B) as detailed 3828 above applied. 3830 If the "Delegate" declines the meeting, the "Organizer" MUST send an 3831 update "REQUEST" to the "Delegator" so that the "Delegator" may elect 3832 to delegate the "REQUEST" to another CUA. 3834 +-----------------+----------------+--------------------------------+ 3835 | Action | "Organizer" | Attendee | 3836 +-----------------+----------------+--------------------------------+ 3837 | Initiate a | "A" sends a | | 3838 | meeting request | REQUEST | | 3839 | | message to "B" | | 3840 | | and "C" | | 3841 | | | | 3842 | Delegate: "C" | | "C" sends a REPLY to "A" with | 3843 | delegates to | | the ATTENDEE "PARTSTAT" | 3844 | "E" | | parameter set to "DELEGATED" | 3845 | | | and with a new "ATTENDEE" | 3846 | | | property for "E". "E's" | 3847 | | | ATTENDEE "DELEGATED-FROM" | 3848 | | | parameter is set to "C". | 3849 | | | "C's" ATTENDEE "DELEGATED-TO" | 3850 | | | parameter is set to "E". "C" | 3851 | | | sends REQUEST message to "E" | 3852 | | | with the original meeting | 3853 | | | request information. The | 3854 | | | "PARTSTAT" property parameter | 3855 | | | for "C" is set to "DELEGATED" | 3856 | | | and the "DELEGATED-TO" | 3857 | | | parameter is set to the | 3858 | | | address of "E". An "ATTENDEE" | 3859 | | | property is added for "E" and | 3860 | | | the "DELEGATED-FROM" parameter | 3861 | | | is set to the address of "C". | 3862 | | | | 3863 | Confirm meeting | | "E" sends REPLY message to "A" | 3864 | attendance | | and optionally "C" with its | 3865 | | | "PARTSTAT" property parameter | 3866 | | | set to "ACCEPTED" | 3867 | | | | 3868 | Optional: | "A" sends | | 3869 | Redistribute | REQUEST | | 3870 | meeting to | message to | | 3871 | attendees | "B", "C" and | | 3872 | | "E". | | 3873 +-----------------+----------------+--------------------------------+ 3875 "C" responds to the "Organizer". 3877 BEGIN:VCALENDAR 3878 PRODID:-//Example/ExampleCalendarClient//EN 3879 METHOD:REPLY 3880 VERSION:2.0 3881 BEGIN:VEVENT 3882 ORGANIZER:mailto:a@example.com 3883 ATTENDEE;PARTSTAT=DELEGATED;DELEGATED- 3884 TO="mailto:e@example.com":mailto:c@example.com 3885 UID:calsrv.example.com-873970198738777@example.com 3886 SEQUENCE:0 3887 REQUEST-STATUS:2.0;Success 3888 DTSTAMP:19970611T190000Z 3889 END:VEVENT 3890 END:VCALENDAR 3892 Attendee "C" delegates presence at the meeting to "E". 3894 BEGIN:VCALENDAR 3895 PRODID:-//Example/ExampleCalendarClient//EN 3896 METHOD:REQUEST 3897 VERSION:2.0 3898 BEGIN:VEVENT 3899 ORGANIZER:mailto:a@example.com 3900 ATTENDEE;PARTSTAT=DELEGATED;DELEGATED- 3901 TO="mailto:e@example.com":mailto:c@example.com 3902 ATTENDEE;RSVP=TRUE; 3903 DELEGATED-FROM="mailto:c@example.com":mailto:e@example.com 3904 DTSTART:19970701T180000Z 3905 DTEND:19970701T200000Z 3906 SUMMARY:Phone Conference 3907 UID:calsrv.example.com-873970198738777@example.com 3908 SEQUENCE:0 3909 STATUS:CONFIRMED 3910 DTSTAMP:19970611T190000Z 3911 END:VEVENT 3912 END:VCALENDAR 3914 4.2.6. Delegate Accepts the Meeting 3916 To accept a delegated meeting, the delegate, "E", sends the following 3917 message to "A" and "C": 3919 BEGIN:VCALENDAR 3920 PRODID:-//Example/ExampleCalendarClient//EN 3921 METHOD:REPLY 3922 VERSION:2.0 3923 BEGIN:VEVENT 3924 ORGANIZER:mailto:a@example.com 3925 ATTENDEE;PARTSTAT=ACCEPTED;DELEGATED- 3926 FROM="mailto:c@example.com":mailto:e@example.com 3927 ATTENDEE;PARTSTAT=DELEGATED; 3928 DELEGATED-TO="mailto:e@example.com":mailto:c@example.com 3929 UID:calsrv.example.com-873970198738777@example.com 3930 SEQUENCE:0 3931 REQUEST-STATUS:2.0;Success 3932 DTSTAMP:19970614T190000Z 3933 END:VEVENT 3934 END:VCALENDAR 3936 4.2.7. Delegate Declines the Meeting 3938 In this example the "Delegate" declines the meeting request and sets 3939 the "ATTENDEE" property "PARTSTAT" parameter to "DECLINED". The 3940 "Organizer" SHOULD resend the "REQUEST" to "C" with the "PARTSTAT" 3941 parameter of the "Delegate" set to "DECLINED". This lets the 3942 "Delegator" know that the "Delegate" has declined and provides an 3943 opportunity to the "Delegator" to either accept the request or 3944 delegate it to another CU. 3946 Response from "E" to "A" and "C". Note the use of the "COMMENT" 3947 property "E" uses to indicate why the delegation was declined. 3949 BEGIN:VCALENDAR 3950 PRODID:-//Example/ExampleCalendarClient//EN 3951 METHOD:REPLY 3952 VERSION:2.0 3953 BEGIN:VEVENT 3954 ORGANIZER:mailto:a@example.com 3955 ATTENDEE;PARTSTAT=DELEGATED; 3956 DELEGATED-TO="mailto:e@example.com":mailto:c@example.com 3957 ATTENDEE;PARTSTAT=DECLINED; 3958 DELEGATED-FROM="mailto:c@example.com":mailto:e@example.com 3959 COMMENT:Sorry, I will be out of town at that time. 3960 UID:calsrv.example.com-873970198738777@example.com 3961 SEQUENCE:0 3962 REQUEST-STATUS:2.0;Success 3963 DTSTAMP:19970614T190000Z 3964 END:VEVENT 3965 END:VCALENDAR 3967 "A" resends the "REQUEST" method to "C". "A" may also wish to 3968 express the fact that the item was delegated in the "COMMENT" 3969 property. 3971 BEGIN:VCALENDAR 3972 PRODID:-//Example/ExampleCalendarClient//EN 3973 METHOD:REQUEST 3974 VERSION:2.0 3975 BEGIN:VEVENT 3976 ORGANIZER:mailto:a@example.com 3977 ATTENDEE;PARTSTAT=DECLINED; 3978 DELEGATED-FROM="mailto:c@example.com":mailto:e@example.com 3979 ATTENDEE;RSVP=TRUE:mailto:c@example.com 3980 UID:calsrv.example.com-873970198738777@example.com 3981 SEQUENCE:0 3982 SUMMARY:Phone Conference 3983 DTSTART:19970701T180000Z 3984 DTEND:19970701T200000Z 3985 DTSTAMP:19970614T200000Z 3986 COMMENT:DELEGATE (ATTENDEE mailto:e@example.com) DECLINED YOUR 3987 INVITATION 3988 END:VEVENT 3989 END:VCALENDAR 3991 4.2.8. Forwarding an Event Request 3993 The protocol does not prevent an "Attendee" from "forwarding" an 3994 "VEVENT" calendar component to other "Calendar Users". Forwarding 3995 differs from delegation in that the forwarded "Calendar User" (often 3996 referred to as a "Party Crasher") does not replace the forwarding 3997 "Calendar User". Implementations are not required to add the "Party 3998 Crasher" to the "Attendee" list and hence there is no guarantee that 3999 a "Party Crasher" will receive additional updates to the event. The 4000 forwarding "Calendar User" SHOULD NOT add the "Party Crasher" to the 4001 attendee list. The "Organizer" MAY add the forwarded "Calendar User" 4002 to the attendee list. 4004 4.2.9. Cancel A Group Event 4006 Individual "A" requests a meeting between individuals "A", "B", "C", 4007 and "D". Individual "B" declines attendance to the meeting. 4008 Individual "A" decides to cancel the meeting. The following table 4009 illustrates the sequence of messages that would be exchanged between 4010 these individuals. 4012 Messages related to a previously canceled event ("SEQUENCE" property 4013 value is less than the "SEQUENCE" property value of the "CANCEL" 4014 message) MUST be ignored. 4016 +-------------+--------------------+--------------------------------+ 4017 | Action | "Organizer" | "Attendee" | 4018 +-------------+--------------------+--------------------------------+ 4019 | Initiate a | "A" sends a | | 4020 | meeting | REQUEST message to | | 4021 | request | "B", "C", and "D" | | 4022 | | | | 4023 | Decline the | | "B" sends a "REPLY" message to | 4024 | meeting | | "A" with its "PARTSTAT" | 4025 | request | | parameter set to "DECLINED". | 4026 | | | | 4027 | Cancel the | "A" sends a CANCEL | | 4028 | meeting | message to "B", | | 4029 | | "C" and "D" | | 4030 +-------------+--------------------+--------------------------------+ 4032 The example shows how "A" cancels the event. 4034 BEGIN:VCALENDAR 4035 PRODID:-//Example/ExampleCalendarClient//EN 4036 METHOD:CANCEL 4037 VERSION:2.0 4038 BEGIN:VEVENT 4039 ORGANIZER:mailto:a@example.com 4040 ATTENDEE;CUTYPE=INDIVIDUAL;mailto:a@example.com 4041 ATTENDEE;CUTYPE=INDIVIDUAL:mailto:b@example.com 4042 ATTENDEE;CUTYPE=INDIVIDUAL:mailto:c@example.com 4043 ATTENDEE;CUTYPE=INDIVIDUAL:mailto:d@example.com 4044 COMMENT:Mr. B cannot attend. It's raining. Lets cancel. 4045 UID:calsrv.example.com-873970198738777@example.com 4046 SEQUENCE:1 4047 STATUS:CANCELLED 4048 DTSTAMP:19970613T190000Z 4049 END:VEVENT 4050 END:VCALENDAR 4052 4.2.10. Removing Attendees 4054 "A" wants to remove "B" from a meeting. This is done by sending a 4055 "CANCEL" to "B" and removing "B" from the attendee list in the master 4056 copy of the event. 4058 +-------------------+----------------------------------+------------+ 4059 | Action | "Organizer" | "Attendee" | 4060 +-------------------+----------------------------------+------------+ 4061 | Remove "B" as an | "A" sends a CANCEL message to | | 4062 | "Attendee" | "B" | | 4063 | | | | 4064 | Update the master | "A" optionally sends the updated | | 4065 | copy of the event | event to the remaining | | 4066 | | "Attendees" | | 4067 +-------------------+----------------------------------+------------+ 4069 The original meeting includes "A", "B", "C", and "D". The example 4070 below shows the "CANCEL" that "A" sends to "B". Note that in the 4071 example below the "STATUS" property is omitted. This is used when 4072 the meeting itself is cancelled and not when the intent is to remove 4073 an "Attendee" from the event. 4075 BEGIN:VCALENDAR 4076 PRODID:-//Example/ExampleCalendarClient//EN 4077 METHOD:CANCEL 4078 VERSION:2.0 4079 BEGIN:VEVENT 4080 ORGANIZER:mailto:a@example.com 4081 ATTENDEE:mailto:b@example.com 4082 COMMENT:You're off the hook for this meeting 4083 UID:calsrv.example.com-873970198738777@example.com 4084 DTSTAMP:19970613T193000Z 4085 SEQUENCE:1 4086 END:VEVENT 4087 END:VCALENDAR 4089 The updated master copy of the event is shown below. The "Organizer" 4090 MAY resend the updated event to the remaining "Attendees". Note that 4091 "B" has been removed. 4093 BEGIN:VCALENDAR 4094 PRODID:-//Example/ExampleCalendarClient//EN 4095 METHOD:REQUEST 4096 VERSION:2.0 4097 BEGIN:VEVENT 4098 ORGANIZER:mailto:a@example.com 4099 ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:mailto:a@example.com 4100 ATTENDEE;CUTYPE=INDIVIDUAL:mailto:c@example.com 4101 ATTENDEE;CUTYPE=INDIVIDUAL:mailto:d@example.com 4102 ATTENDEE;CUTYPE=ROOM:mailto:cr_big@example.com 4103 ATTENDEE;ROLE=NON-PARTICIPANT; 4104 RSVP=FALSE:mailto:e@example.com 4105 DTSTAMP:19970611T190000Z 4106 DTSTART:19970701T200000Z 4107 DTEND:19970701T203000Z 4108 SUMMARY:Phone Conference 4109 UID:calsrv.example.com-873970198738777@example.com 4110 SEQUENCE:2 4111 STATUS:CONFIRMED 4112 END:VEVENT 4113 END:VCALENDAR 4115 4.2.11. Replacing the Organizer 4117 The scenario for this example begins with "A" as the "Organizer" for 4118 a recurring meeting with "B", "C", and "D". "A" receives a new job 4119 offer in another country and drops out of touch. "A" left no 4120 forwarding address or way to be reached. Using out-of-band 4121 communication, the other "Attendees" eventually learn what has 4122 happened and reach an agreement that "B" should become the new 4123 "Organizer" for the meeting. To do this, "B" sends out a new version 4124 of the event and the other "Attendees" agree to accept "B" as the new 4125 "Organizer". "B" also removes "A" from the event. 4127 When the "Organizer" is replaced, the "SEQUENCE" property value MUST 4128 be incremented. 4130 This is the message "B" sends to "C" and "D" 4131 BEGIN:VCALENDAR 4132 PRODID:-//Example/ExampleCalendarClient//EN 4133 METHOD:REQUEST 4134 VERSION:2.0 4135 BEGIN:VEVENT 4136 ORGANIZER:mailto:b@example.com 4137 ATTENDEE;ROLE=CHAIR;STATUS=ACCEPTED:mailto:b@example.com 4138 ATTENDEE;CUTYPE=INDIVIDUAL:mailto:c@example.com 4139 ATTENDEE;CUTYPE=INDIVIDUAL:mailto:d@example.com 4140 DTSTAMP:19970611T190000Z 4141 DTSTART:19970701T200000Z 4142 DTEND:19970701T203000Z 4143 RRULE:FREQ=WEEKLY 4144 SUMMARY:Phone Conference 4145 UID:123456@example.com 4146 SEQUENCE:1 4147 STATUS:CONFIRMED 4148 END:VEVENT 4149 END:VCALENDAR 4151 4.3. Busy Time Examples 4153 Busy time objects can be used in several ways. First, a CU may 4154 request busy time from another CU for a specific range of time. That 4155 request can be answered with a busy time Reply. Additionally, a CU 4156 may simply publish their busy time for a given interval and point 4157 other CUs to the published location. The following examples outline 4158 both scenarios. 4160 4.3.1. Publish Busy Time 4162 Individual "A" publishes busy time for one week. 4164 BEGIN:VCALENDAR 4165 PRODID:-//Example/ExampleCalendarClient//EN 4166 VERSION:2.0 4167 METHOD:PUBLISH 4168 BEGIN:VFREEBUSY 4169 DTSTAMP:19980101T124100Z 4170 ORGANIZER:mailto:a@example.com 4171 DTSTART:19980101T124200Z 4172 DTEND:19980108T124200Z 4173 FREEBUSY:19980101T180000Z/19980101T190000Z 4174 FREEBUSY:19980103T020000Z/19980103T050000Z 4175 FREEBUSY:19980107T020000Z/19980107T050000Z 4176 FREEBUSY:19980113T000000Z/19980113T010000Z 4177 FREEBUSY:19980115T190000Z/19980115T200000Z 4178 FREEBUSY:19980115T220000Z/19980115T230000Z 4179 FREEBUSY:19980116T013000Z/19980116T043000Z 4180 END:VFREEBUSY 4181 END:VCALENDAR 4183 4.3.2. Request Busy Time 4185 Individual "A" requests busy time from individuals "B", "C". 4186 Individual "B" and "C" replies with busy time data to individual "A". 4187 The following table illustrates the sequence of messages that would 4188 be exchanged between these individuals. 4190 +----------------------+--------------------+-----------------------+ 4191 | Action | "Organizer" | Attendee | 4192 +----------------------+--------------------+-----------------------+ 4193 | Initiate a busy time | "A" sends | | 4194 | request | "REQUEST" message | | 4195 | | to "B" and "C" | | 4196 | | | | 4197 | Reply to the "BUSY" | | "B" sends a "REPLY" | 4198 | request with "BUSY" | | message to "A" with | 4199 | time data | | busy time data | 4200 +----------------------+--------------------+-----------------------+ 4202 "A" sends a "BUSY-REQUEST" to "B" and "C" for busy time 4203 BEGIN:VCALENDAR 4204 PRODID:-//Example/ExampleCalendarClient//EN 4205 METHOD:REQUEST 4206 VERSION:2.0 4207 BEGIN:VFREEBUSY 4208 ORGANIZER:mailto:a@example.com 4209 ATTENDEE;ROLE=CHAIR:mailto:a@example.com 4210 ATTENDEE:mailto:b@example.com 4211 ATTENDEE:mailto:c@example.com 4212 DTSTAMP:19970613T190000Z 4213 DTSTART:19970701T080000Z 4214 DTEND:19970701T200000 4215 UID:calsrv.example.com-873970198738777@example.com 4216 END:VFREEBUSY 4217 END:VCALENDAR 4219 4.3.3. Reply To A Busy Time Request 4221 "B" sends a "REPLY" method type of a "VFREEBUSY" calendar component 4222 to "A" 4224 BEGIN:VCALENDAR 4225 PRODID:-//Example/ExampleCalendarClient//EN 4226 METHOD:REPLY 4227 VERSION:2.0 4228 BEGIN:VFREEBUSY 4229 ORGANIZER:mailto:a@example.com 4230 ATTENDEE:mailto:b@example.com 4231 DTSTART:19970701T080000Z 4232 DTEND:19970701T200000Z 4233 UID:calsrv.example.com-873970198738777@example.com 4234 FREEBUSY:19970701T090000Z/PT1H,19970701T140000Z/PT30M 4235 DTSTAMP:19970613T190030Z 4236 END:VFREEBUSY 4237 END:VCALENDAR 4239 "B" is busy from 09:00 to 10:00 and from 14:00 to 14:30. 4241 4.4. Recurring Event and Time Zone Examples 4243 4.4.1. A Recurring Event Spanning Time Zones 4245 This event describes a weekly phone conference. The "Attendees" are 4246 each in a different time zone. 4248 BEGIN:VCALENDAR 4249 PRODID:-//Example/ExampleCalendarClient//EN 4250 METHOD:REQUEST 4251 VERSION:2.0 4252 BEGIN:VTIMEZONE 4253 TZID:America-SanJose 4254 TZURL:http://example.com/tz/America-SanJose 4255 BEGIN:STANDARD 4256 DTSTART:19671029T020000 4257 RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=10 4258 TZOFFSETFROM:-0700 4259 TZOFFSETTO:-0800 4260 TZNAME:PST 4261 END:STANDARD 4262 BEGIN:DAYLIGHT 4263 DTSTART:19870405T020000 4264 RRULE:FREQ=YEARLY;BYDAY=1SU;BYMONTH=4 4265 TZOFFSETFROM:-0800 4266 TZOFFSETTO:-0700 4267 TZNAME:PDT 4268 END:DAYLIGHT 4269 END:VTIMEZONE 4270 BEGIN:VEVENT 4271 ORGANIZER:mailto:a@example.com 4272 ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED; 4273 CUTYPE=INDIVIDUAL:a@example.com 4274 ATTENDEE;RSVP=TRUE;CUTYPE=INDIVIDUAL:b@example.fr 4275 ATTENDEE;RSVP=TRUE;CUTYPE=INDIVIDUAL:c@example.jp 4276 DTSTAMP:19970613T190030Z 4277 DTSTART;TZID=America-SanJose:19970701T140000 4278 DTEND;TZID=America-SanJose:19970701T150000 4279 RRULE:FREQ=WEEKLY;COUNT=20;WKST=SU;BYDAY=TU 4280 RDATE;TZID=America-SanJose:19970910T140000 4281 EXDATE;TZID=America-SanJose:19970909T140000 4282 EXDATE;TZID=America-SanJose:19971028T140000 4283 SUMMARY:Weekly Phone Conference 4284 UID:calsrv.example.com-873970198738777@example.com 4285 SEQUENCE:0 4286 STATUS:CONFIRMED 4287 END:VEVENT 4288 END:VCALENDAR 4290 The first component of this iCalendar object is the time zone 4291 component. The "DTSTART" date coincides with the first instance of 4292 the RRULE property. 4294 The recurring meeting is defined in a particular time zone, 4295 presumably that of the originator. The client for each "Attendee" 4296 has the responsibility of determining the recurrence time in the 4297 "Attendee's" time zone. 4299 The repeating event starts on Tuesday, July 1, 1997 at 2:00pm PDT 4300 (UTC-7). "Attendee" B@example.fr is in France where the local time 4301 on this date is 9 hours ahead of PDT or 23:00 CEST (UTC+2). 4302 "Attendee" C@example.jp is in Japan where local time is 16 hours 4303 ahead of PDT or Wednesday, July 2 at 06:00 JST (UTC+9). The event 4304 repeats weekly on Tuesdays (in PST/PDT). The "RRULE" property 4305 results in 20 instances. The last instance falls on Tuesday, 4306 November 11, 1997 2:00pm PST. The "RDATE" property adds another 4307 instance: WED, 10-SEP-1997 2:00 PM PDT. 4309 There are also two exception dates to the recurrence rule. The first 4310 one is: 4312 o TUE, 09-SEP-1997 14:00 PDT (UTC-7) 4313 o TUE, 09-SEP-1997 23:00 CEST (UTC+2) 4314 o WED, 10-SEP-1997 06:00 JST (UTC+9) 4316 and the second is: 4318 o TUE, 28-OCT-1997 14:00 PST (UTC-8) 4319 o TUE, 28-OCT-1997 23:00 CET (UTC+1) 4320 o WED, 29-OCT-1997 07:00 JST (UTC+9) 4322 4.4.2. Modify A Recurring Instance 4324 In this example the "Organizer" issues a recurring meeting. Later 4325 the "Organizer" changes an instance of the event by changing the 4326 "DTSTART" property. Note the use of "RECURRENCE-ID" property and 4327 "SEQUENCE" property in the second request. 4329 Original Request: 4331 BEGIN:VCALENDAR 4332 METHOD:REQUEST 4333 PRODID:-//Example/ExampleCalendarClient//EN 4334 VERSION:2.0 4335 BEGIN:VEVENT 4336 UID:guid-1@example.com 4337 SEQUENCE:0 4338 RRULE:FREQ=MONTHLY;BYMONTHDAY=1;UNTIL=19980901T210000Z 4339 ORGANIZER:mailto:a@example.com 4340 ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:mailto:a@example.com 4341 ATTENDEE:mailto:b@example.com 4342 ATTENDEE:mailto:c@example.com 4343 ATTENDEE:mailto:d@example.com 4344 DESCRIPTION:IETF-C&S Conference Call 4345 CLASS:PUBLIC 4346 SUMMARY:IETF Calendaring Working Group Meeting 4347 DTSTART:19970601T210000Z 4348 DTEND:19970601T220000Z 4349 LOCATION:Conference Call 4350 DTSTAMP:19970526T083000Z 4351 STATUS:CONFIRMED 4352 END:VEVENT 4353 END:VCALENDAR 4355 The event request below is to change the time of a specific instance. 4356 This changes the July 1st instance to July 3rd. 4358 BEGIN:VCALENDAR 4359 METHOD:REQUEST 4360 PRODID:-//Example/ExampleCalendarClient//EN 4361 VERSION:2.0 4362 BEGIN:VEVENT 4363 UID:guid-1@example.com 4364 RECURRENCE-ID:19970701T210000Z 4365 SEQUENCE:1 4366 ORGANIZER:mailto:a@example.com 4367 ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:mailto:a@example.com 4368 ATTENDEE:mailto:b@example.com 4369 ATTENDEE:mailto:c@example.com 4370 ATTENDEE:mailto:d@example.com 4371 DESCRIPTION:IETF-C&S Conference Call 4372 CLASS:PUBLIC 4373 SUMMARY:IETF Calendaring Working Group Meeting 4374 DTSTART:19970703T210000Z 4375 DTEND:19970703T220000Z 4376 LOCATION:Conference Call 4377 DTSTAMP:19970626T093000Z 4378 STATUS:CONFIRMED 4379 END:VEVENT 4380 END:VCALENDAR 4382 4.4.3. Cancel an Instance 4384 In this example the "Organizer" of a recurring event deletes the 4385 August 1st instance. 4387 BEGIN:VCALENDAR 4388 METHOD:CANCEL 4389 PRODID:-//Example/ExampleCalendarClient//EN 4390 VERSION:2.0 4391 BEGIN:VEVENT 4392 UID:guid-1@example.com 4393 ORGANIZER:mailto:a@example.com 4394 ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:mailto:a@example.com 4395 ATTENDEE:mailto:b@example.com 4396 ATTENDEE:mailto:c@example.com 4397 ATTENDEE:mailto:d@example.com 4398 RECURRENCE-ID:19970801T210000Z 4399 SEQUENCE:2 4400 STATUS:CANCELLED 4401 DTSTAMP:19970721T093000Z 4402 END:VEVENT 4403 END:VCALENDAR 4405 4.4.4. Cancel Recurring Event 4407 In this example the "Organizer" wishes to cancel the entire recurring 4408 event and any exceptions. 4410 BEGIN:VCALENDAR 4411 METHOD:CANCEL 4412 PRODID:-//Example/ExampleCalendarClient//EN 4413 VERSION:2.0 4414 BEGIN:VEVENT 4415 UID:guid-1@example.com 4416 ORGANIZER:mailto:a@example.com 4417 ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:mailto:a@example.com 4418 ATTENDEE:mailto:b@example.com 4419 ATTENDEE:mailto:c@example.com 4420 ATTENDEE:mailto:d@example.com 4421 DTSTAMP:19970721T103000Z 4422 STATUS:CANCELLED 4423 SEQUENCE:3 4424 END:VEVENT 4425 END:VCALENDAR 4427 4.4.5. Change All Future Instances 4429 This example changes the meeting location from a conference call to 4430 Seattle starting September 1 and extends to all future instances. 4432 BEGIN:VCALENDAR 4433 METHOD:REQUEST 4434 PRODID:-//Example/ExampleCalendarClient//EN 4435 VERSION:2.0 4436 BEGIN:VEVENT 4437 UID:guid-1@example.com 4438 RECURRENCE-ID;THISANDFUTURE:19970901T210000Z 4439 SEQUENCE:3 4440 ORGANIZER:mailto:a@example.com 4441 ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:mailto:a@example.com 4442 ATTENDEE;RSVP=TRUE:mailto:b@example.com 4443 ATTENDEE;RSVP=TRUE:mailto:c@example.com 4444 ATTENDEE;RSVP=TRUE:mailto:d@example.com 4445 DESCRIPTION:IETF-C&S Discussion 4446 CLASS:PUBLIC 4447 SUMMARY:IETF Calendaring Working Group Meeting 4448 DTSTART:19970901T210000Z 4449 DTEND:19970901T220000Z 4450 LOCATION:Building 32, Microsoft, Seattle, WA 4451 DTSTAMP:19970526T083000Z 4452 STATUS:CONFIRMED 4453 END:VEVENT 4454 END:VCALENDAR 4456 4.4.6. Add A New Instance To A Recurring Event 4458 This example adds a one-time additional instance to the recurring 4459 event. "Organizer" adds a second July meeting on the 15th. 4461 BEGIN:VCALENDAR 4462 METHOD:ADD 4463 PRODID:-//Example/ExampleCalendarClient//EN 4464 VERSION:2.0 4465 BEGIN:VEVENT 4466 UID:123456789@example.com 4467 SEQUENCE:4 4468 ORGANIZER:mailto:a@example.com 4469 ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:mailto:a@example.com 4470 ATTENDEE;RSVP=TRUE:mailto:b@example.com 4471 ATTENDEE;RSVP=TRUE:mailto:c@example.com 4472 ATTENDEE;RSVP=TRUE:mailto:d@example.com 4473 DESCRIPTION:IETF-C&S Conference Call 4474 CLASS:PUBLIC 4475 SUMMARY:IETF Calendaring Working Group Meeting 4476 DTSTART:19970715T210000Z 4477 DTEND:19970715T220000Z 4478 LOCATION:Conference Call 4479 DTSTAMP:19970629T093000Z 4480 STATUS:CONFIRMED 4481 END:VEVENT 4482 END:VCALENDAR 4484 4.4.7. Add A New Series of Instances To A Recurring Event 4486 The scenario for this example involves an ongoing meeting, originally 4487 set up to occur every Tuesday. The "Organizer" later decides that 4488 the meetings need to be on Tuesdays and Thursdays. 4490 The original event: 4492 BEGIN:VCALENDAR 4493 METHOD:REQUEST 4494 PRODID:-//Example/ExampleCalendarClient//EN 4495 VERSION:2.0 4496 BEGIN:VEVENT 4497 UID:123456789@example.com 4498 SEQUENCE:0 4499 RRULE:WKST=SU;BYDAY=TU;FREQ=WEEKLY 4500 ORGANIZER:mailto:a@example.com 4501 ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:mailto:a@example.com 4502 ATTENDEE;RSVP=TRUE:mailto:b@example.com 4503 SUMMARY:Review Accounts 4504 DTSTART:19980303T210000Z 4505 DTEND:19980303T220000Z 4506 LOCATION:The White Room 4507 DTSTAMP:19980301T093000Z 4508 STATUS:CONFIRMED 4509 END:VEVENT 4510 END:VCALENDAR 4512 The entire event can be rescheduled using a "REQUEST". This is done 4513 by using the "UID" of the event to reschedule and including the 4514 modified "RRULE". Note, that since this is an entire rescheduling of 4515 the event, any instance-specific information will be lost, unless 4516 explicitly included with the update "REQUEST". 4518 BEGIN:VCALENDAR 4519 METHOD:REQUEST 4520 PRODID:-//Example/ExampleCalendarClient//EN 4521 VERSION:2.0 4522 BEGIN:VEVENT 4523 UID:123456789@example.com 4524 SEQUENCE:7 4525 RRULE:WKST=SU;BYDAY=TU,TH;FREQ=WEEKLY 4526 ORGANIZER:mailto:a@example.com 4527 ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:mailto:a@example.com 4528 ATTENDEE;RSVP=TRUE:mailto:b@example.com 4529 SUMMARY:Review Accounts 4530 DTSTART:19980303T210000Z 4531 DTEND:19980303T220000Z 4532 DTSTAMP:19980303T193000Z 4533 LOCATION:The White Room 4534 STATUS:CONFIRMED 4535 END:VEVENT 4536 END:VCALENDAR 4538 4.4.8. Refreshing A Recurring Event 4540 The next series of examples illustrate how an "Organizer" would 4541 respond to a "REFRESH" submitted by an "Attendee" after a series of 4542 instance-specific modifications. To convey all instance-specific 4543 changes, the "Organizer" must provide the latest event description 4544 and the relevant instances. The first three examples show the 4545 history including the initial "VEVENT" request and subsequent 4546 instance changes and finally the "REFRESH". 4548 Original Request: 4550 BEGIN:VCALENDAR 4551 METHOD:REQUEST 4552 PRODID:-//Example/ExampleCalendarClient//EN 4553 VERSION:2.0 4554 BEGIN:VEVENT 4555 UID:123456789@example.com 4556 SEQUENCE:0 4557 RDATE:19980304T180000Z 4558 RDATE:19980311T180000Z 4559 RDATE:19980318T180000Z 4560 ORGANIZER:mailto:a@example.com 4561 ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:mailto:a@example.com 4562 ATTENDEE;RSVP=TRUE:mailto:b@example.com 4563 SUMMARY:Review Accounts 4564 DTSTART:19980304T180000Z 4565 DTEND:19980304T200000Z 4566 DTSTAMP:19980303T193000Z 4567 LOCATION:Conference Room A 4568 STATUS:CONFIRMED 4569 END:VEVENT 4570 END:VCALENDAR 4572 Organizer changes 2nd instance Location and Time: 4574 BEGIN:VCALENDAR 4575 METHOD:REQUEST 4576 PRODID:-//Example/ExampleCalendarClient//EN 4577 VERSION:2.0 4578 BEGIN:VEVENT 4579 UID:123456789@example.com 4580 SEQUENCE:1 4581 RECURRENCE-ID:19980311T180000Z 4582 ORGANIZER:mailto:a@example.com 4583 ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:mailto:a@example.com 4584 ATTENDEE;RSVP=TRUE:mailto:b@example.com 4585 SUMMARY:Review Accounts 4586 DTSTART:19980311T160000Z 4587 DTEND:19980311T180000Z 4588 DTSTAMP:19980306T193000Z 4589 LOCATION:The Small conference room 4590 STATUS:CONFIRMED 4591 END:VEVENT 4592 END:VCALENDAR 4594 Organizer adds a 4th instance of the meeting using the "ADD" method 4596 BEGIN:VCALENDAR 4597 METHOD:ADD 4598 PRODID:-//Example/ExampleCalendarClient//EN 4599 VERSION:2.0 4600 BEGIN:VEVENT 4601 UID:123456789@example.com 4602 SEQUENCE:2 4603 ORGANIZER:mailto:a@example.com 4604 ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:mailto:a@example.com 4605 ATTENDEE;RSVP=TRUE:mailto:b@example.com 4606 SUMMARY:Review Accounts 4607 DTSTART:19980315T180000Z 4608 DTEND:19980315T200000Z 4609 DTSTAMP:19980307T193000Z 4610 LOCATION:Conference Room A 4611 STATUS:CONFIRMED 4612 END:VEVENT 4613 END:VCALENDAR 4615 If "B" requests a "REFRESH", "A" responds with the following to 4616 capture all instance-specific data. In this case both the initial 4617 request and an additional "VEVENT" that specifies the instance- 4618 specific data are included. Because these are both of the same type 4619 (they are both "VEVENTS"), they can be conveyed in the same iCalendar 4620 object. 4622 BEGIN:VCALENDAR 4623 METHOD:REQUEST 4624 PRODID:-//Example/ExampleCalendarClient//EN 4625 VERSION:2.0 4626 BEGIN:VEVENT 4627 UID:123456789@example.com 4628 SEQUENCE:2 4629 RDATE:19980304T180000Z 4630 RDATE:19980311T160000Z 4631 RDATE:19980315T180000Z 4632 ORGANIZER:mailto:a@example.com 4633 ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:mailto:a@example.com 4634 ATTENDEE;RSVP=TRUE:mailto:b@example.com 4635 SUMMARY:Review Accounts 4636 DTSTART:19980304T180000Z 4637 DTEND:19980304T200000Z 4638 DTSTAMP:19980303T193000Z 4639 LOCATION:Conference Room A 4640 STATUS:CONFIRMED 4641 END:VEVENT 4642 BEGIN:VEVENT 4643 SEQUENCE:2 4644 RECURRENCE-ID:19980311T160000Z 4645 ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:mailto:a@example.com 4646 ATTENDEE;RSVP=TRUE:mailto:b@example.com 4647 SUMMARY:Review Accounts 4648 DTSTART:19980311T160000Z 4649 DTEND:19980304T180000Z 4650 DTSTAMP:19980306T193000Z 4651 LOCATION:The Small conference room 4652 STATUS:CONFIRMED 4653 END:VEVENT 4654 END:VCALENDAR 4656 4.4.9. Counter An Instance Of A Recurring Event 4658 In this example one of the "Attendees" counters the "DTSTART" 4659 property of the proposed second July meeting. 4661 BEGIN:VCALENDAR 4662 METHOD:COUNTER 4663 PRODID:-//Example/ExampleCalendarClient//EN 4664 VERSION:2.0 4665 BEGIN:VEVENT 4666 UID:guid-1@example.com 4667 RECURRENCE-ID:19970715T210000Z 4668 SEQUENCE:4 4669 ORGANIZER:mailto:a@example.com 4670 ATTENDEE;ROLE=CHAIR;RSVP=TRUE:mailto:a@example.com 4671 ATTENDEE;RSVP=TRUE:mailto:b@example.com 4672 ATTENDEE;RSVP=TRUE:mailto:c@example.com 4673 ATTENDEE;RSVP=TRUE:mailto:d@example.com 4674 DESCRIPTION:IETF-C&S Conference Call 4675 CLASS:PUBLIC 4676 SUMMARY:IETF Calendaring Working Group Meeting 4677 DTSTART:19970715T220000Z 4678 DTEND:19970715T230000Z 4679 LOCATION:Conference Call 4680 COMMENT:May we bump this by an hour? I have a conflict 4681 DTSTAMP:19970629T094000Z 4682 END:VEVENT 4683 END:VCALENDAR 4685 4.4.10. Error Reply To A Request 4687 The following example illustrates a scenario where a meeting is 4688 proposed containing an unsupported property and a bad property. 4690 Original Request 4691 BEGIN:VCALENDAR 4692 METHOD:REQUEST 4693 PRODID:-//Example/ExampleCalendarClient//EN 4694 VERSION:2.0 4695 BEGIN:VEVENT 4696 UID:guid-1@example.com 4697 SEQUENCE:0 4698 RRULE:FREQ=MONTHLY;BYMONTHDAY=1 4699 ORGANIZER:mailto:a@example.com 4700 ATTENDEE;ROLE=CHAIR:mailto:a@example.com 4701 ATTENDEE;RSVP=TRUE:mailto:b@example.com 4702 ATTENDEE;RSVP=TRUE:mailto:c@example.com 4703 ATTENDEE;RSVP=TRUE:mailto:d@example.com 4704 DESCRIPTION:IETF-C&S Conference Call 4705 CLASS:PUBLIC 4706 SUMMARY:IETF Calendaring Working Group Meeting 4707 DTSTART:19970601T210000Z 4708 DTEND:19970601T220000Z 4709 DTSTAMP:19970602T094000Z 4710 LOCATION:Conference Call 4711 STATUS:CONFIRMED 4712 FOO:BAR 4713 END:VEVENT 4714 END:VCALENDAR 4716 Response from "B" to indicate that RRULE is not supported and an 4717 unrecognized property was encountered 4719 BEGIN:VCALENDAR 4720 PRODID:-//Example/ExampleCalendarClient//EN 4721 METHOD:REPLY 4722 VERSION:2.0 4723 BEGIN:VEVENT 4724 ORGANIZER:mailto:a@example.com 4725 ATTENDEE:mailto:b@example.com 4726 REQUEST-STATUS:3.0;Invalid Property Name;FOO 4727 UID:guid-1@example.com 4728 SEQUENCE:0 4729 DTSTAMP:19970603T094000Z 4730 END:VEVENT 4731 END:VCALENDAR 4733 4.5. Group To-do Examples 4735 Individual "A" creates a group task in which individuals "A", "B", 4736 "C" and "D" will participate. Individual "B" confirms acceptance of 4737 the task. Individual "C" declines the task. Individual "D" 4738 tentatively accepts the task. The following table illustrates the 4739 sequence of messages that would be exchanged between these 4740 individuals. Individual "A" then issues a "REQUEST" method to obtain 4741 the status of the to-do from each participant. The response 4742 indicates the individual "Attendee's" completion status. The table 4743 below illustrates the message flow. 4745 +--------------+------------------------+---------------------------+ 4746 | Action | "Organizer" | Attendee | 4747 +--------------+------------------------+---------------------------+ 4748 | Initiate a | "A" sends a REQUEST | | 4749 | to-do | message to "B", "C", | | 4750 | request | and "D" | | 4751 | | | | 4752 | Accept the | | "B" sends a "REPLY" | 4753 | to-do | | message to "A" with its | 4754 | request | | "PARTSTAT" parameter set | 4755 | | | to "ACCEPTED". | 4756 | | | | 4757 | Decline the | | "C" sends a REPLY message | 4758 | to-do | | to "A" with its | 4759 | request | | "PARTSTAT" parameter set | 4760 | | | to "DECLINED". | 4761 | | | | 4762 | Tentatively | | "D" sends a REPLY message | 4763 | accept the | | to "A" with its | 4764 | to-do | | "PARTSTAT" parameter set | 4765 | request | | to "TENTATIVE". | 4766 | | | | 4767 | Check | "A" sends a REQUEST | | 4768 | attendee | message to "B" and "D" | | 4769 | completion | with current | | 4770 | status | information. | | 4771 | | | | 4772 | Attendee | | "B" sends a "REPLY" | 4773 | indicates | | message indicating | 4774 | percent | | percent complete | 4775 | complete | | | 4776 | | | | 4777 | Attendee | | "D" sends a "REPLY" | 4778 | indicates | | message indicating | 4779 | completion | | completion | 4780 +--------------+------------------------+---------------------------+ 4782 4.5.1. A VTODO Request 4784 A sample "REQUEST" for a "VTODO" calendar component that "A" sends to 4785 "B", "C", and "D". 4787 BEGIN:VCALENDAR 4788 PRODID:-//Example/ExampleCalendarClient//EN 4789 METHOD:REQUEST 4790 VERSION:2.0 4791 BEGIN:VTODO 4792 ORGANIZER:mailto:a@example.com 4793 ATTENDEE;ROLE=CHAIR:mailto:a@example.com 4794 ATTENDEE;RSVP=TRUE:mailto:b@example.com 4795 ATTENDEE;RSVP=TRUE:mailto:c@example.com 4796 ATTENDEE;RSVP=TRUE:mailto:d@example.com 4797 DTSTART:19970701T170000Z 4798 DUE:19970722T170000Z 4799 PRIORITY:1 4800 SUMMARY:Create the requirements document 4801 UID:calsrv.example.com-873970198738777-00@example.com 4802 SEQUENCE:0 4803 DTSTAMP:19970717T200000Z 4804 STATUS:NEEDS-ACTION 4805 END:VTODO 4806 END:VCALENDAR 4808 4.5.2. A VTODO Reply 4810 "B" accepts the to-do. 4812 BEGIN:VCALENDAR 4813 PRODID:-//Example/ExampleCalendarClient//EN 4814 METHOD:REPLY 4815 VERSION:2.0 4816 BEGIN:VTODO 4817 ORGANIZER:mailto:a@example.com 4818 ATTENDEE;PARTSTAT=ACCEPTED:mailto:b@example.com 4819 UID:calsrv.example.com-873970198738777-00@example.com 4820 COMMENT:I'll send you my input by e-mail 4821 SEQUENCE:0 4822 DTSTAMP:19970717T203000Z 4823 REQUEST-STATUS:2.0;Success 4824 END:VTODO 4825 END:VCALENDAR 4827 "B" could have declined the TODO or indicated tentative acceptance by 4828 setting the "PARTSTAT" property parameter sequence to "DECLINED" or 4829 "TENTATIVE", respectively. 4831 4.5.3. A VTODO Request for Updated Status 4833 "A" requests status from all "Attendees". 4835 BEGIN:VCALENDAR 4836 PRODID:-//Example/ExampleCalendarClient//EN 4837 METHOD:REQUEST 4838 VERSION:2.0 4839 BEGIN:VTODO 4840 ORGANIZER:mailto:a@example.com 4841 ATTENDEE;ROLE=CHAIR:mailto:a@example.com 4842 ATTENDEE;RSVP=TRUE;CUTYPE=INDIVIDUAL:mailto:b@example.com 4843 ATTENDEE;RSVP=TRUE;CUTYPE=INDIVIDUAL:mailto:d@example.com 4844 UID:calsrv.example.com-873970198738777-00@example.com 4845 SUMMARY:Create the requirements document 4846 PRIORITY:1 4847 SEQUENCE:0 4848 STATUS:IN-PROCESS 4849 DTSTART:19970701T170000Z 4850 DTSTAMP:19970717T230000Z 4851 END:VTODO 4852 END:VCALENDAR 4854 4.5.4. A Reply: Percent-Complete 4856 A reply indicating the task being worked on and that "B" is 75% 4857 complete with "B's" part of the assignment. 4859 BEGIN:VCALENDAR 4860 PRODID:-//Example/ExampleCalendarClient//EN 4861 METHOD:REPLY 4862 VERSION:2.0 4863 BEGIN:VTODO 4864 ORGANIZER:mailto:a@example.com 4865 ATTENDEE;PARTSTAT=IN-PROCESS:mailto:b@example.com 4866 PERCENT-COMPLETE:75 4867 UID:calsrv.example.com-873970198738777-00@example.com 4868 DTSTAMP:19970717T233000Z 4869 SEQUENCE:0 4870 END:VTODO 4871 END:VCALENDAR 4873 4.5.5. A Reply: Completed 4875 A reply indicating that "D" completed "D's" part of the assignment. 4877 BEGIN:VCALENDAR 4878 PRODID:-//Example/ExampleCalendarClient//EN 4879 METHOD:REPLY 4880 VERSION:2.0 4881 BEGIN:VTODO 4882 ORGANIZER:mailto:a@example.com 4883 ATTENDEE;PARTSTAT=COMPLETED:mailto:d@example.com 4884 UID:calsrv.example.com-873970198738777-00@example.com 4885 DTSTAMP:19970717T233000Z 4886 SEQUENCE:0 4887 END:VTODO 4888 END:VCALENDAR 4890 4.5.6. An Updated VTODO Request 4892 Organizer "A" resends the "VTODO" calendar component. "A" sets the 4893 overall completion for the to-do at 40%. 4895 BEGIN:VCALENDAR 4896 PRODID:-//Example/ExampleCalendarClient//EN 4897 METHOD:REQUEST 4898 VERSION:2.0 4899 BEGIN:VTODO 4900 ORGANIZER:mailto:a@example.com 4901 ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:mailto:a@example.com 4902 ATTENDEE;PARTSTAT=ACCEPTED;CUTYPE=INDIVIDUAL:mailto:b@example.com 4903 ATTENDEE;PARTSTAT=COMPLETED;CUTYPE=INDIVIDUAL:mailto:d@example.com 4904 DTSTART:19970701T170000Z 4905 DUE:19970722T170000Z 4906 PRIORITY:1 4907 SUMMARY:Create the requirements document 4908 UID:calsrv.example.com-873970198738777-00@example.com 4909 SEQUENCE:1 4910 DTSTAMP:19970718T100000Z 4911 STATUS:IN-PROCESS 4912 PERCENT-COMPLETE:40 4913 END:VTODO 4914 END:VCALENDAR 4916 4.5.7. Recurring VTODOs 4918 The following examples relate to recurring "VTODO" calendar 4919 components. 4921 4.5.7.1. Request for a Recurring VTODO 4923 In this example "A" sends a recurring "VTODO" calendar component to 4924 "B" and "D". 4926 BEGIN:VCALENDAR 4927 PRODID:-//Example/ExampleCalendarClient//EN 4928 METHOD:REQUEST 4929 VERSION:2.0 4930 BEGIN:VTODO 4931 ORGANIZER:mailto:a@example.com 4932 ATTENDEE;ROLE=CHAIR:mailto:a@example.com 4933 ATTENDEE;RSVP=TRUE;CUTYPE=INDIVIDUAL:mailto:b@example.com 4934 ATTENDEE;RSVP=TRUE;CUTYPE=INDIVIDUAL:mailto:d@example.com 4935 RRULE:FREQ=MONTHLY;COUNT=10;BYDAY=1FR 4936 DTSTART:19980101T100000Z 4937 DUE:19980103T100000Z 4938 SUMMARY:Send Status Reports to Area Managers 4939 UID:calsrv.example.com-873970198738777-00@example.com 4940 SEQUENCE:0 4941 DTSTAMP:19970717T200000Z 4942 STATUS:NEEDS-ACTION 4943 PRIORITY:1 4944 END:VTODO 4945 END:VCALENDAR 4947 4.5.7.2. Replying to an instance of a recurring VTODO 4949 In this example "B" updates "A" on a single instance of the "VTODO" 4950 calendar component. 4952 BEGIN:VCALENDAR 4953 PRODID:-//Example/ExampleCalendarClient//EN 4954 METHOD:REPLY 4955 VERSION:2.0 4956 BEGIN:VTODO 4957 ATTENDEE;PARTSTAT=IN-PROCESS:mailto:b@example.com 4958 PERCENT-COMPLETE:75 4959 UID:calsrv.example.com-873970198738777-00@example.com 4960 DTSTAMP:19970717T233000Z 4961 RECURRENCE-ID:19980101T170000Z 4962 SEQUENCE:1 4963 END:VTODO 4964 END:VCALENDAR 4966 4.6. Journal Examples 4968 The iCalendar object below describes a single journal entry for 4969 October 2, 1997. The "RELATED-TO" property references the phone 4970 conference event for which minutes were taken. 4972 BEGIN:VCALENDAR 4973 METHOD:PUBLISH 4974 PRODID:-//Example/ExampleCalendarClient//EN 4975 VERSION:2.0 4976 BEGIN:VJOURNAL 4977 DTSTART:19971002T200000Z 4978 DTSTAMP:19970717T233100Z 4979 ORGANIZER:mailto:a@example.com 4980 SUMMARY:Phone conference minutes 4981 DESCRIPTION:The editors meeting was held on October 1, 1997. 4982 Details are in the attached document. 4983 UID:0981234-1234234-2410@example.com 4984 RELATED-TO:0981234-1234234-2402-35@example.com 4985 ATTACH:ftp://ftp.example.com/pub/ed/minutes100197.txt 4986 END:VJOURNAL 4987 END:VCALENDAR 4989 4.7. Other Examples 4991 4.7.1. Event Refresh 4993 Refresh the event with "UID" property value of 4994 "guid-1-12345@example.com": 4996 BEGIN:VCALENDAR 4997 PRODID:-//Example/ExampleCalendarClient//EN 4998 METHOD:REFRESH 4999 VERSION:2.0 5000 BEGIN:VEVENT 5001 ORGANIZER:mailto:a@example.com 5002 ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:mailto:a@example.com 5003 ATTENDEE:mailto:b@example.com 5004 ATTENDEE:mailto:c@example.com 5005 ATTENDEE:mailto:d@example.com 5006 UID:guid-1-12345@example.com 5007 DTSTAMP:19970603T094000 5008 END:VEVENT 5009 END:VCALENDAR 5011 4.7.2. Bad RECURRENCE-ID 5013 Component instances are identified by the combination of "UID", 5014 "RECURRENCE-ID", and "SEQUENCE". When an "Organizer" sends an iTIP 5015 message to an "Attendee", there are three cases in which an instance 5016 cannot be found. They are: 5018 1. The component with the referenced "UID" and "RECURRENCE-ID" has 5019 been found but the "SEQUENCE" number in the calendar store does 5020 not match that of the iTIP message. 5021 2. The component with the referenced "UID" has been found, the 5022 "SEQUENCE" numbers match, but the "RECURRENCE-ID" cannot be 5023 found. 5024 3. The "UID" and "SEQUENCE" numbers are found but the CUA does not 5025 support recurrences. 5027 In case (1), two things can happen. If the "SEQUENCE" number of the 5028 "Attendee's" instance is larger than that in the "Organizer's" 5029 message then the "Attendee" is receiving an out-of-sequence message 5030 and MUST ignore it. If the "SEQUENCE" number of the "Attendee's" 5031 instance is smaller, then the "Organizer" is sending out a newer 5032 version of the component and the "Attendee's" version needs to be 5033 updated. Since one or more updates have been missed, the "Attendee" 5034 SHOULD send a "REFRESH" message to the "Organizer" to get an updated 5035 version of the event. 5037 In case (2), something has gone wrong. Both the "Organizer" and the 5038 "Attendee" should have the same instances, but the "Attendee" does 5039 not have the referenced instance. In this case the "Attendee" SHOULD 5040 send a "REFRESH" to the "Organizer" to get an updated version of the 5041 event. 5043 In case (3), the limitations of the "Attendee's" CUA makes it 5044 impossible to match an instance other than the single instance 5045 scheduled. In this case, the "Attendee" need not send a "REFRESH" to 5046 the "Organizer". 5048 The example below shows a sequence in which an "Attendee" sends a 5049 "REFRESH" to the "Organizer". 5051 +-------------------------+--------------------+--------------------+ 5052 | Action | "Organizer" | Attendee | 5053 +-------------------------+--------------------+--------------------+ 5054 | Update an instance | "A" sends | | 5055 | request | "REQUEST" message | | 5056 | | to "B" | | 5057 | | | | 5058 | Attendee requests | | "B" sends a | 5059 | refresh because | | "REFRESH" message | 5060 | "RECURRENCE-ID" was not | | to "A" | 5061 | found | | | 5062 | | | | 5063 | Refresh the entire | "A" sends the | | 5064 | event | latest copy of the | | 5065 | | event to "B" | | 5066 | | | | 5067 | Attendee handles the | | "B" updates to the | 5068 | request and updates the | | latest copy of the | 5069 | instance | | meeting. | 5070 +-------------------------+--------------------+--------------------+ 5072 Request from "A": 5074 BEGIN:VCALENDAR 5075 METHOD:REQUEST 5076 PRODID:-//Example/ExampleCalendarClient//EN 5077 VERSION:2.0 5078 BEGIN:VEVENT 5079 UID:example-12345@example.com 5080 SEQUENCE:3 5081 RRULE:FREQ=WEEKLY 5082 RDATE;VALUE=PERIOD:19970819T210000Z/199700819T220000Z 5083 ORGANIZER:mailto:a@example.com 5084 ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:mailto:a@example.com 5085 ATTENDEE:mailto:b@example.com 5086 DESCRIPTION:IETF-C&S Conference Call 5087 SUMMARY:IETF Calendaring Working Group Meeting 5088 DTSTART:19970801T210000Z 5089 DTEND:19970801T220000Z 5090 RECURRENCE-ID:19970809T210000Z 5091 DTSTAMP:19970726T083000 5092 STATUS:CONFIRMED 5093 END:VEVENT 5094 END:VCALENDAR 5096 "B" has the event with "UID" property "example-12345@example.com" but 5097 "B's" "SEQUENCE" property value is "1" and the event does not have an 5098 instance at the specified recurrence time. This means that "B" has 5099 missed at least one update and needs a new copy of the event. "B" 5100 requests the latest copy of the event with the following refresh 5101 message: 5103 BEGIN:VCALENDAR 5104 PRODID:-//Example/ExampleCalendarClient//EN 5105 METHOD:REFRESH 5106 VERSION:2.0 5107 BEGIN:VEVENT 5108 ORGANIZER:mailto:a@example.com 5109 ATTENDEE:mailto:b@example.com 5110 UID:example-12345@example.com 5111 DTSTAMP:19970603T094000 5112 END:VEVENT 5113 END:VCALENDAR 5115 5. Application Protocol Fallbacks 5117 5.1. Partial Implementation 5119 Applications that support this specification are not required to 5120 support the entire protocol. The following describes how methods and 5121 properties SHOULD "fallback" in applications that do not support the 5122 complete protocol. If a method or property is not addressed in this 5123 section, it may be ignored. 5125 5.1.1. Event-Related Fallbacks 5127 +----------------+--------------------------------------------------+ 5128 | Method | Fallback | 5129 +----------------+--------------------------------------------------+ 5130 | PUBLISH | Required | 5131 | REQUEST | PUBLISH | 5132 | REPLY | Required | 5133 | ADD | Required if recurrences supported, otherwise | 5134 | | reply with a REQUEST-STATUS "2.8;Success, | 5135 | | repeating event ignored. Scheduled as a single | 5136 | | component." and schedule as a single component. | 5137 | CANCEL | Required | 5138 | REFRESH | Required | 5139 | COUNTER | Reply with "Not Supported" | 5140 | DECLINECOUNTER | Required if COUNTER is implemented for VEVENTs, | 5141 | | otherwise reply with "Not Supported" | 5142 +----------------+--------------------------------------------------+ 5144 +-----------------+-------------------------------------------------+ 5145 | iCalendar | Fallback | 5146 | Property | | 5147 +-----------------+-------------------------------------------------+ 5148 | CALSCALE | Ignore - assume GREGORIAN | 5149 | PRODID | Ignore | 5150 | METHOD | Required as described in the Method list above | 5151 | VERSION | Ignore | 5152 +-----------------+-------------------------------------------------+ 5154 +-----------------+-------------------------------------------------+ 5155 | Event-Related | Fallback | 5156 | Components | | 5157 +-----------------+-------------------------------------------------+ 5158 | VALARM | Reply with "Not Supported" | 5159 | VTIMEZONE | Required if any DateTime value refers to a time | 5160 | | zone. | 5161 +-----------------+-------------------------------------------------+ 5162 +-----------------+-------------------------------------------------+ 5163 | Component | Fallback | 5164 | Property | | 5165 +-----------------+-------------------------------------------------+ 5166 | ATTACH | Ignore | 5167 | ATTENDEE | Required if METHOD is REQUEST, otherwise ignore | 5168 | CATEGORIES | Ignore | 5169 | CLASS | Ignore | 5170 | COMMENT | Ignore | 5171 | COMPLETED | Ignore | 5172 | CONTACT | Ignore | 5173 | CREATED | Ignore | 5174 | DESCRIPTION | Ignore | 5175 | DURATION | Required | 5176 | DTSTAMP | Required | 5177 | DTSTART | Required | 5178 | DTEND | Required | 5179 | EXDATE | Ignore | 5180 | GEO | Ignore | 5181 | LAST-MODIFIED | Ignore | 5182 | LOCATION | Required | 5183 | ORGANIZER | Required if METHOD is REQUEST, otherwise ignore | 5184 | PRIORITY | Ignore | 5185 | RELATED-TO | Ignore | 5186 | RDATE | Ignore | 5187 | RRULE | Ignore - assume the first instance occurs on | 5188 | | the DTSTART property. If implemented, | 5189 | | VTIMEZONE MUST also be implemented. | 5190 | RECURRENCE-ID | Required if RRULE is implemented, otherwise | 5191 | | Ignore | 5192 | REQUEST-STATUS | Required | 5193 | RESOURCES | Ignore | 5194 | SEQUENCE | Required | 5195 | STATUS | Ignore | 5196 | SUMMARY | Ignore | 5197 | TRANSP | Required if FREEBUSY is implemented, otherwise | 5198 | | Ignore | 5199 | URL | Ignore | 5200 | UID | Required | 5201 | X- | Ignore | 5202 +-----------------+-------------------------------------------------+ 5204 5.1.2. Free/Busy-Related Fallbacks 5206 +---------+---------------------------------------------------------+ 5207 | Method | Fallback | 5208 +---------+---------------------------------------------------------+ 5209 | PUBLISH | Required if freebusy lookups are supported, otherwise | 5210 | | reply with a REQUEST-STATUS "3.14;Unsupported | 5211 | | capability" | 5212 | REQUEST | Required if freebusy lookups are supported, otherwise | 5213 | | reply with a REQUEST-STATUS "3.14;Unsupported | 5214 | | capability" | 5215 | REPLY | Required if freebusy lookups are supported, otherwise | 5216 | | reply with a REQUEST-STATUS "3.14;Unsupported | 5217 | | capability" | 5218 +---------+---------------------------------------------------------+ 5220 +-----------------+-------------------------------------------------+ 5221 | iCalendar | Fallback | 5222 | Property | | 5223 +-----------------+-------------------------------------------------+ 5224 | CALSCALE | Ignore - assume GREGORIAN. | 5225 | PRODID | Ignore | 5226 | METHOD | Required as described in the Method list above. | 5227 | VERSION | Ignore | 5228 +-----------------+-------------------------------------------------+ 5230 +-----------------+-------------------------------------------------+ 5231 | Component | Fallback | 5232 | Property | | 5233 +-----------------+-------------------------------------------------+ 5234 | ATTENDEE | Required if METHOD is REQUEST, otherwise ignore | 5235 | COMMENT | Ignore | 5236 | CONTACT | Ignore | 5237 | DTEND | Required | 5238 | DTSTAMP | Required | 5239 | DTSTART | Required | 5240 | DURATION | Ignore | 5241 | FREEBUSY | Required | 5242 | ORGANIZER | Required if METHOD is REQUEST, otherwise ignore | 5243 | REQUEST-STATUS | Ignore | 5244 | UID | Required | 5245 | URL | Ignore | 5246 | X- | Ignore | 5247 +-----------------+-------------------------------------------------+ 5249 5.1.3. To-Do-Related Fallbacks 5251 +----------------+--------------------------------------------------+ 5252 | Method | Fallback | 5253 +----------------+--------------------------------------------------+ 5254 | PUBLISH | Required | 5255 | REQUEST | PUBLISH | 5256 | REPLY | Required | 5257 | ADD | Required if recurrences supported, otherwise | 5258 | | reply with a REQUEST-STATUS "2.8;Success, | 5259 | | repeating event ignored. Scheduled as a single | 5260 | | component." and schedule as a single component. | 5261 | CANCEL | Required | 5262 | REFRESH | Required | 5263 | COUNTER | Reply with "Not Supported" | 5264 | DECLINECOUNTER | Required if COUNTER for VTODOs is implemented, | 5265 | | otherwise reply with "Not Supported" | 5266 +----------------+--------------------------------------------------+ 5268 +-----------------+-------------------------------------------------+ 5269 | iCalendar | Fallback | 5270 | Property | | 5271 +-----------------+-------------------------------------------------+ 5272 | CALSCALE | Ignore - assume GREGORIAN. | 5273 | PRODID | Ignore | 5274 | METHOD | Required as described in the Method list above. | 5275 | VERSION | Ignore | 5276 +-----------------+-------------------------------------------------+ 5278 +-----------------+-------------------------------------------------+ 5279 | To-Do-Related | Fallback | 5280 | Components | | 5281 +-----------------+-------------------------------------------------+ 5282 | VALARM | Reply with "Not Supported" | 5283 | VTIMEZONE | Required if any DateTime value refers to a time | 5284 | | zone. | 5285 +-----------------+-------------------------------------------------+ 5286 +------------------+------------------------------------------------+ 5287 | Component | Fallback | 5288 | Property | | 5289 +------------------+------------------------------------------------+ 5290 | ATTACH | Ignore | 5291 | ATTENDEE | Required if METHOD is REQUEST, otherwise | 5292 | | ignore | 5293 | CATEGORIES | Ignore | 5294 | CLASS | Ignore | 5295 | COMMENT | Ignore | 5296 | COMPLETED | Required | 5297 | CONTACT | Ignore | 5298 | CREATED | Ignore | 5299 | DESCRIPTION | Required if METHOD is REQUEST, otherwise | 5300 | | ignore | 5301 | DUE | Required | 5302 | DURATION | Required | 5303 | DTSTAMP | Required | 5304 | DTSTART | Required | 5305 | EXDATE | Ignore - reply with "Not Supported" | 5306 | LAST-MODIFIED | Ignore | 5307 | LOCATION | Ignore | 5308 | ORGANIZER | Required if METHOD is REQUEST, otherwise | 5309 | | ignore | 5310 | PERCENT-COMPLETE | Ignore | 5311 | PRIORITY | Required | 5312 | RECURRENCE-ID | Required if RRULE is implemented, otherwise | 5313 | | Ignore | 5314 | RELATED-TO | Ignore | 5315 | REQUEST-STATUS | Ignore | 5316 | RDATE | Ignore | 5317 | RRULE | Ignore - assume the first instance occurs on | 5318 | | the DTSTART property. If implemented, | 5319 | | VTIMEZONE MUST also be implemented. | 5320 | RESOURCES | Ignore | 5321 | SEQUENCE | Required | 5322 | STATUS | Required | 5323 | SUMMARY | Ignore | 5324 | URL | Ignore | 5325 | UID | Required | 5326 | X- | Ignore | 5327 +------------------+------------------------------------------------+ 5329 5.1.4. Journal-Related Fallbacks 5331 +---------+---------------------------------------------------------+ 5332 | Method | Fallback | 5333 +---------+---------------------------------------------------------+ 5334 | PUBLISH | Implementations MAY ignore the METHOD type. The | 5335 | | REQUEST-STATUS "3.14;Unsupported capability" MUST be | 5336 | | returned. | 5337 | ADD | Implementations MAY ignore the METHOD type. The | 5338 | | REQUEST-STATUS "3.14;Unsupported capability" MUST be | 5339 | | returned. | 5340 | CANCEL | Implementations MAY ignore the METHOD type. The | 5341 | | REQUEST-STATUS "3.14;Unsupported capability" MUST be | 5342 | | returned. | 5343 +---------+---------------------------------------------------------+ 5345 +-----------------+-------------------------------------------------+ 5346 | iCalendar | Fallback | 5347 | Property | | 5348 +-----------------+-------------------------------------------------+ 5349 | CALSCALE | Ignore - assume GREGORIAN. | 5350 | PRODID | Ignore | 5351 | METHOD | Required as described in the Method list above. | 5352 | VERSION | Ignore | 5353 +-----------------+-------------------------------------------------+ 5355 +-----------------+-------------------------------------------------+ 5356 | Journal-Related | Fallback | 5357 | Components | | 5358 +-----------------+-------------------------------------------------+ 5359 | VTIMEZONE | Required if any DateTime value refers to a time | 5360 | | zone | 5361 +-----------------+-------------------------------------------------+ 5362 +-----------------+-------------------------------------------------+ 5363 | Component | Fallback | 5364 | Property | | 5365 +-----------------+-------------------------------------------------+ 5366 | ATTACH | Ignore | 5367 | ATTENDEE | Ignore | 5368 | CATEGORIES | Ignore | 5369 | CLASS | Ignore | 5370 | COMMENT | Ignore | 5371 | CONTACT | Ignore | 5372 | CREATED | Ignore | 5373 | DESCRIPTION | Ignore | 5374 | DTSTAMP | Required | 5375 | DTSTART | Required | 5376 | EXDATE | Ignore | 5377 | LAST-MODIFIED | Ignore | 5378 | ORGANIZER | Ignore | 5379 | RECURRENCE-ID | Required if RRULE is implemented, otherwise | 5380 | | Ignore | 5381 | RELATED-TO | Ignore | 5382 | RDATE | Ignore. | 5383 | RRULE | Ignore - assume the first instance occurs on | 5384 | | the DTSTART property. If implemented, | 5385 | | VTIMEZONE MUST also be implemented. | 5386 | SEQUENCE | Required | 5387 | STATUS | Ignore | 5388 | SUMMARY | Required | 5389 | URL | Ignore | 5390 | UID | Required | 5391 | X- | Ignore | 5392 +-----------------+-------------------------------------------------+ 5394 5.2. Latency Issues 5396 With a store-and-forward transport, it is possible for events to 5397 arrive out of sequence. That is, a "CANCEL" method may be received 5398 prior to receiving the associated "REQUEST" for the calendar 5399 component. This section discusses a few of these scenarios. 5401 5.2.1. Cancellation of an Unknown Calendar Component. 5403 When a "CANCEL" method is received before the original "REQUEST" 5404 method the calendar will be unable to correlate the "UID" property of 5405 the cancellation with an existing calendar component. It is 5406 suggested that messages that can not be correlated that also contain 5407 non-zero sequence numbers be held and not discarded. Implementations 5408 MAY age them out if no other messages arrive with the same "UID" 5409 property value and a lower sequence number. 5411 5.2.2. Unexpected Reply from an Unknown Delegate 5413 When an "Attendee" delegates an item to another CU they MUST send a 5414 "REPLY" method to the "Organizer" using the "ATTENDEE" properties to 5415 indicate that the request was delegated and to whom. Hence, it is 5416 possible for an "Organizer" to receive an "REPLY" from a CU not 5417 listed as one of the original "Attendees". The resolution is left to 5418 the implementation but it is expected that the calendaring software 5419 will either accept the reply or hold it until the related "REPLY" 5420 method is received from the "Delegator". If the version of the 5421 "REPLY" method is out of date the "Organizer" SHOULD treat the 5422 message as a "REFRESH" message and update the delegate with the 5423 correct version provided that delegation to that delegate is 5424 acceptable. 5426 5.3. Sequence Number 5428 Under some conditions, a CUA may receive requests and replies with 5429 the same "SEQUENCE" property value. The "DTSTAMP" property is 5430 utilized as a tie-breaker when two items with the same "SEQUENCE" 5431 property value are evaluated. 5433 6. Security Considerations 5435 iTIP is an abstract transport protocol which will be bound to a real- 5436 time transport, a store-and-forward transport, and perhaps other 5437 transports. The transport protocol will be responsible for providing 5438 facilities for authentication and encryption using standard Internet 5439 mechanisms that are mutually understood between the sender and 5440 receiver. 5442 6.1. Security Threats 5444 6.1.1. Spoofing the "Organizer" 5446 In iTIP, the "Organizer" (or someone working on the "Organizer's" 5447 behalf) is the only person authorized to make changes to an existing 5448 "VEVENT", "VTODO", "VJOURNAL" calendar component and republish it or 5449 redistribute updates to the "Attendees". An iCalendar object that 5450 maliciously changes or cancels an existing "VEVENT", "VTODO" or 5451 "VJOURNAL" calendar component may be constructed by someone other 5452 than the "Organizer" and republished or sent to the "Attendees". 5454 6.1.2. Spoofing the "Attendee" 5456 In iTIP, an "Attendee" of a "VEVENT" or "VTODO" calendar component 5457 (or someone working on the "Attendee's" behalf) is the only person 5458 authorized to update any parameter associated with their "ATTENDEE" 5459 property and send it to the "Organizer". An iCalendar object that 5460 maliciously changes the "ATTENDEE" parameters may be constructed by 5461 someone other than the real "Attendee" and sent to the "Organizer". 5463 6.1.3. Unauthorized Replacement of the Organizer 5465 There will be circumstances when "Attendees" of an event or to-do 5466 decide, using out-of-band mechanisms, that the "Organizer" must be 5467 replaced. When the new "Organizer" sends out the updated "VEVENT" or 5468 "VTODO" the "Attendee's" CUA will detect that the "Organizer" has 5469 been changed, but it has no way of knowing whether or not the change 5470 was mutually agreed upon. 5472 6.1.4. Eavesdropping and Data Integrity 5474 The iCalendar object is constructed with human-readable clear text. 5475 Any information contained in an iCalendar object may be read and/or 5476 changed by unauthorized persons while the object is in transit. 5478 6.1.5. Flooding a Calendar 5480 Implementations could provide a means to automatically incorporate 5481 "REQUEST" methods into a calendar. This presents the opportunity for 5482 a calendar to be flooded with requests, which effectively block all 5483 the calendar's free time. 5485 6.1.6. Unauthorized REFRESH Requests 5487 It is possible for an "Organizer" to receive a "REFRESH" request from 5488 someone who is not an "Attendee" of an event or to-do. Only 5489 "Attendee's" of an event or to-do are authorized to receive replies 5490 to "REFRESH" requests. Replying to such requests to anyone who is 5491 not an "Attendee" may be a security problem. 5493 6.2. Recommendations 5495 For an application where the information is sensitive or critical and 5496 the network is subject to a high probability of attack, iTIP 5497 transactions SHOULD be encrypted and authenticated. This helps 5498 mitigate the threats of spoofing, eavesdropping and malicious changes 5499 in transit. 5501 6.2.1. Securing iTIP transactions 5503 iTIP transport bindings MUST provide a mechanism to enable 5504 authentication of the sender's identity, and privacy and integrity of 5505 the data being transmitted. This allows the receiver of a signed 5506 iCalendar object to verify the identity of the sender. This sender 5507 may then be correlated to an "ATTENDEE" property in the iCalendar 5508 object. If the correlation is made and the sender is authorized to 5509 make the requested change or update then the operation may proceed. 5510 It also allows the message to be encrypted to prevent unauthorized 5511 reading of the message contents in transit. iTIP transport binding 5512 documents describe this process in detail. 5514 6.2.2. Implementation Controls 5516 The threat of unauthorized replacement of the "Organizer" SHOULD be 5517 mitigated by a calendar system that uses this protocol by providing 5518 controls or alerts that make "Calendar Users" aware of such 5519 "Organizer" changes and allowing them to decide whether or not the 5520 request should be honored. 5522 The threat of flooding a calendar SHOULD be mitigated by a calendar 5523 system that uses this protocol by providing controls that may be used 5524 to limit the acceptable sources for iTIP transactions, and perhaps 5525 the size of messages and volume of traffic, by source. 5527 The threat of unauthorized "REFRESH" requests SHOULD be mitigated by 5528 a calendar system that uses this protocol by providing controls or 5529 alerts that allow "Calendar User" to decide whether or not the 5530 request should be honored. An implementation MAY decide to maintain, 5531 for audit or historical purposes, "Calendar Users" who were part of 5532 an attendee list and who were subsequently uninvited. Similar 5533 controls or alerts should be provided when a "REFRESH" request is 5534 received from these "Calendar Users" as well. 5536 6.2.3. Access Controls and Filtering 5538 In many environments there could be restrictions on who is allowed to 5539 scheduled with whom, and who allowed delegates are for particular 5540 calendar users. 5542 iTIP transport bindings SHOULD provide mechanisms for implementing 5543 access controls or filtering to ensure iTIP transactions only take 5544 place between authorized calendar users. That would include 5545 preventing one calendar user from scheduling with another, or a 5546 calendar user delegating to another. 5548 6.3. Privacy Issues 5550 The "Organizer" might want to keep "Attendees" from knowing which 5551 other "Attendees" are participating in an event or to-do. The 5552 "Organizer" has the choice of sending single iTIP messages with a 5553 full list of "Attendees" or sending iTIP messages to each "Attendee" 5554 with only that "Attendee" listed. 5556 7. IANA Consideration 5558 7.1. Registration Template for REQUEST-STATUS Values 5560 This specification updates [RFC5545] by adding a "REQUEST-STATUS" 5561 value registry to the iCalendar Elements registry. 5563 A "REQUEST-STATUS" value is defined by completing the following 5564 template. 5565 Status Code: Hierarchical, numeric return status code, following the 5566 rules defined in Section 3.8.8.3 of [RFC5545]. 5567 Status Description: Textual status description. A short but clear 5568 description of the error. 5569 Status Exception Data: Textual exception data. A short but clear 5570 description of what might appear in this field. 5571 Description: Describe the underlying cause for this status code 5572 value. 5574 7.2. Additions to iCalendar METHOD Registry 5576 This documents defines the following values for the iCalendar 5577 "METHOD" property using the values template from Section 8.2.6 of 5578 [RFC5545]. These should be added to the Methods Registry defined in 5579 Section 8.3.12 of [RFC5545]: 5581 7.2.1. METHOD:PUBLISH 5583 Value: PUBLISH 5584 Purpose: Standard iTIP "METHOD" value. 5585 Conformance: Only used with the "METHOD" property. 5586 Examples: See this RFC. 5588 7.2.2. METHOD:REQUEST 5590 Value: REQUEST 5591 Purpose: Standard iTIP "METHOD" value. 5592 Conformance: Only used with the "METHOD" property. 5593 Examples: See this RFC. 5595 7.2.3. METHOD:REPLY 5596 Value: REPLY 5597 Purpose: Standard iTIP "METHOD" value. 5598 Conformance: Only used with the "METHOD" property. 5599 Examples: See this RFC. 5601 7.2.4. METHOD:ADD 5603 Value: ADD 5604 Purpose: Standard iTIP "METHOD" value. 5605 Conformance: Only used with the "METHOD" property. 5606 Examples: See this RFC. 5608 7.2.5. METHOD:CANCEL 5610 Value: CANCEL 5611 Purpose: Standard iTIP "METHOD" value. 5612 Conformance: Only used with the "METHOD" property. 5613 Examples: See this RFC. 5615 7.2.6. METHOD:REFRESH 5617 Value: REFRESH 5618 Purpose: Standard iTIP "METHOD" value. 5619 Conformance: Only used with the "METHOD" property. 5620 Examples: See this RFC. 5622 7.2.7. METHOD:COUNTER 5624 Value: COUNTER 5625 Purpose: Standard iTIP "METHOD" value. 5626 Conformance: Only used with the "METHOD" property. 5627 Examples: See this RFC. 5629 7.2.8. METHOD:DECLINECOUNTER 5631 Value: DECLINECOUNTER 5632 Purpose: Standard iTIP "METHOD" value. 5633 Conformance: Only used with the "METHOD" property. 5634 Examples: See this RFC. 5636 7.3. REQUEST-STATUS Value Registry 5638 The following table is to be used to initialize the "REQUEST-STATUS" 5639 value registry. 5641 +-------------+---------+-------------------------+ 5642 | Status Code | Status | Reference | 5643 +-------------+---------+-------------------------+ 5644 | 2.0 | Current | RFCXXXX, Section 3.6.1 | 5645 | 2.1 | Current | RFCXXXX, Section 3.6.2 | 5646 | 2.2 | Current | RFCXXXX, Section 3.6.3 | 5647 | 2.3 | Current | RFCXXXX, Section 3.6.4 | 5648 | 2.4 | Current | RFCXXXX, Section 3.6.5 | 5649 | 2.5 | Current | RFCXXXX, Section 3.6.6 | 5650 | 2.6 | Current | RFCXXXX, Section 3.6.7 | 5651 | 2.7 | Current | RFCXXXX, Section 3.6.8 | 5652 | 2.8 | Current | RFCXXXX, Section 3.6.9 | 5653 | 2.9 | Current | RFCXXXX, Section 3.6.10 | 5654 | 2.10 | Current | RFCXXXX, Section 3.6.11 | 5655 | 2.11 | Current | RFCXXXX, Section 3.6.12 | 5656 | 3.0 | Current | RFCXXXX, Section 3.6.13 | 5657 | 3.1 | Current | RFCXXXX, Section 3.6.14 | 5658 | 3.2 | Current | RFCXXXX, Section 3.6.15 | 5659 | 3.3 | Current | RFCXXXX, Section 3.6.16 | 5660 | 3.4 | Current | RFCXXXX, Section 3.6.17 | 5661 | 3.5 | Current | RFCXXXX, Section 3.6.18 | 5662 | 3.6 | Current | RFCXXXX, Section 3.6.19 | 5663 | 3.7 | Current | RFCXXXX, Section 3.6.20 | 5664 | 3.8 | Current | RFCXXXX, Section 3.6.21 | 5665 | 3.9 | Current | RFCXXXX, Section 3.6.22 | 5666 | 3.10 | Current | RFCXXXX, Section 3.6.23 | 5667 | 3.11 | Current | RFCXXXX, Section 3.6.24 | 5668 | 3.12 | Current | RFCXXXX, Section 3.6.25 | 5669 | 3.13 | Current | RFCXXXX, Section 3.6.26 | 5670 | 3.14 | Current | RFCXXXX, Section 3.6.27 | 5671 | 4.0 | Current | RFCXXXX, Section 3.6.28 | 5672 | 5.0 | Current | RFCXXXX, Section 3.6.29 | 5673 | 5.1 | Current | RFCXXXX, Section 3.6.30 | 5674 | 5.2 | Current | RFCXXXX, Section 3.6.31 | 5675 | 5.3 | Current | RFCXXXX, Section 3.6.32 | 5676 +-------------+---------+-------------------------+ 5678 8. Acknowledgments 5680 This is an update to the original iTIP document authored by S. 5681 Silverberg, S. Mansour, F. Dawson and R. Hopson. 5683 This revision is the product of the Calsify IETF Working Group, and 5684 several participants have made important contributions to this 5685 specification, including: Oliver Block, Bernard Desruisseaux, Mike 5686 Douglass, Tim Hare, Ciny Joy, Bruce Kahn, Reinhold Kainhofer, Eliot 5687 Lear, Jonathan Lennox, Andy Mabbett, Aki Niemi, John W. Noerenberg 5688 II, Robert Ransdell, Caleb Richardson. 5690 9. References 5692 9.1. Normative References 5694 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 5695 Requirement Levels", BCP 14, RFC 2119, March 1997. 5697 [RFC2368] Hoffman, P., Masinter, L., and J. Zawinski, "The mailto 5698 URL scheme", RFC 2368, July 1998. 5700 [RFC5545] Desruisseaux, B., "Internet Calendaring and Scheduling 5701 Core Object Specification (iCalendar)", RFC 5545, 5702 September 2009. 5704 9.2. Informative References 5706 [I-D.ietf-calsify-rfc2447bis] 5707 Melnikov, A., "iCalendar Message-Based Interoperability 5708 Protocol (iMIP)", draft-ietf-calsify-rfc2447bis-06 (work 5709 in progress), September 2009. 5711 Appendix A. Differences from RFC 2446 5713 A.1. Changed Restrictions 5715 This specification now defines an allowed combination of "REQUEST- 5716 STATUS" codes when multiple iCalendar components are included in an 5717 iTIP message. 5719 This specification now restricts "RECURRENCE-ID" to only a single 5720 occurrence in any one iCalendar component in an iTIP message as 5721 required by [RFC5545]. 5723 Changed "RECURRENCE-ID" entry in component restriction table to "0 or 5724 1" from "0+" to fall in line with [RFC5545]. 5726 Changed "FREEBUSY" entry in "VFREEBUSY" "PUBLISH" and "REPLY" 5727 restriction table to "0+" from "1+" to fall in line with [RFC5545]. 5729 Changed "FREEBUSY" description in "VFREEBUSY" "REPLY" restriction 5730 table to indicate that different "FBTYPE" ranges MUST NOT overlap. 5732 Changed "TZNAME" entry in "VTIMEZONE" restriction table to "0+" from 5733 "0 or 1" to fall in line with [RFC5545]. 5735 Changed "COMMENT" entry in component restriction tables to "0+" from 5736 "0 or 1" to fall in line with [RFC5545]. 5738 Added "ATTENDEE" entry in "VALARM" restriction table to match email 5739 alarm type in [RFC5545]. 5741 Changed "CATEGORIES" entry in component restriction tables to "0+" 5742 from "0 or 1" to fall in line with [RFC5545]. 5744 Changed "RESOURCES" entry in component restriction tables to "0+" 5745 from "0 or 1" to fall in line with [RFC5545]. 5747 Changed "CONTACT" entry in "VFREEBUSY" restriction table to "0 or 1" 5748 from "0+" to fall in line with [RFC5545]. 5750 Changed "UID" entry in "VFREEBUSY" "PUBLISH" restriction table to "1" 5751 from "0" to fall in line with [RFC5545]. 5753 Added "COMPLETED" entry in "VTODO" restriction tables to fall in line 5754 with [RFC5545]. 5756 Added "REQUEST-STATUS" entry in "VJOURNAL" restriction tables to fall 5757 in line with [RFC5545]. 5759 A.2. Deprecated features 5761 The "EXRULE" property was removed in [RFC5545] and references to that 5762 have been removed in this document too. 5764 The "PROCEDURE" value for the "ACTION" property was removed in 5765 [RFC5545] and references to that have been removed in this document 5766 too. 5768 The "THISANDPRIOR" option for the "RANGE" parameter was removed in 5769 [RFC5545] and references to that have been removed in this document 5770 too. 5772 Appendix B. Change History (to be removed prior to publication as an 5773 RFC) 5775 Changes in -10: 5776 a. Gen-ART: changed section title "Eavesdropping" to "Eavesdropping 5777 and Data Integrity". 5778 b. SecDir: changed "encrypted" to "encrypted and authenticated" in 5779 6.2. 5781 c. SecDir: removed S/MIME reference and changed text to just talk 5782 about "generic" authentication and encryption. 5783 d. SecDir: added access controls and filtering section. 5784 e. IESG: fixed "THISANDFUTURE" -> "THISANDPRIOR" in A.2. 5785 f. IESG: 2447bis is now an informative reference. 5786 g. IESG: Changed text about email groups to reference mailto URI. 5787 h. IESG: tweaked fallback text for free/busy methods. 5788 i. IESG: fallback for DURATION in events and to-dos now required. 5789 j. IESG: removed last sentence in 6.2.1. 5790 k. IESG: added reference to values template section in 2445bis in 5791 IANA section. 5792 l. IESG: clarified that 2.0 is the default REQUEST-STATUS if the 5793 property is not present. 5794 m. IANA: added registry for REQUEST-STATUS codes. 5795 n. Updated to RFC 5545 reference! 5796 o. Fixed minor typos. 5798 Changes in -09: 5799 a. Updated to RFC5322 reference. 5800 b. Fixed more issues from Reinhold Kainhofer review being tracked on 5801 the WG wiki. 5803 Changes in -08: 5804 a. AD review: Changed "calendar entry" to "iCalendar object". 5805 b. AD review: Added extra captions above restriction tables for more 5806 clarity. 5807 c. AD review: Added missing step of uninvited CU replying to 5808 Organizer in description of event forwarding. 5809 d. AD review: Clarified text about "unsuccessful" REQUEST 5810 processing. 5811 e. AD review: VFREEBUSY text about allowing multiple components 5812 moved into description of PUBLISH method. 5813 f. AD review: VTODO description changed to reflect fact that 5814 originator is not always the Organizer. 5815 g. AD review: Changed VTODO ADD description to use proper 3.14 code 5816 instead of 5.3. 5817 h. AD review: Changed short description on 5.0 status code. 5818 i. AD review: Added IANA-PROPERTY/COMPONENT items to restrictions 5819 tables and changed 3.7.3 to better reflect requirements on 5820 handling extensions. 5821 j. AD review: Fixed example in 4.2.4. 5822 k. AD review: Clarified who is responsible for updating the 5823 delegator in 4.2.5. 5824 l. AD review: Fixed PARTSTAT in example in 4.2.6. 5825 m. AD review: Added reference to IANA methods registry in 2445bis in 5826 IANA section. 5828 n. Removed section on calculating recurring due dates as that is 5829 covered in 2445bis. 5830 o. Fixed lots of issues from Reinhold Kainhofer review being tracked 5831 on the WG wiki. 5832 p. Fixed DECLINE-COUNTER -> DECLINECOUNTER. 5834 Changes in -07: 5835 a. IANA considerations now registers METHOD values. 5836 b. Added Appendix with key 2446 changes and text to the introduction 5837 pointing to that. 5839 Changes in -06: 5840 a. Added text to SEQUENCE number description about detecting a 5841 significant change. 5842 b. Added text to REQUEST-STATUS section describing the allowed 5843 combinations of codes. 5844 c. Added text to REQUEST-STATUS section to require new codes to be 5845 defined in a standard or experimental RFC. 5846 d. Removed THISANDFUTURE. 5847 e. Cleaned up some examples. 5849 Changes in -05: 5850 a. Changed "memo" to "specification". 5851 b. Removed EXRULE as it is no longer in 2445bis. 5852 c. Removed section on PROCEDURE alarms since those are no longer in 5853 2445bis. 5854 d. Changed TYPE= to CUTYPE=. 5855 e. Fixed formatting of examples. 5856 f. Use lowercase mailto everywhere. 5858 Changes in -04: 5859 a. Added empty IANA Considerations section - to be done. 5860 b. Formatting fixes. 5861 c. Changed VEVENT, VTODO, VJOURNAL cancel descriptions that 5862 incorrectly implied RECURRENCE-ID could appear multiple times in 5863 a single component. 5864 d. [Issue91] FREEBUSY properties changed to '0+' from '1+' in 5865 VFREEBUSY PUBLISH and REPLY tables. 5866 e. [Issue89] Description for VEVENT ADD method simplified for 5867 clarity. 5868 f. Fixed some iCalendar property/parameter/value capitalization 5869 issues. 5870 g. MAY NOT -> MUST NOT in VFREEBUSY FREEBUSY response type. 5872 Changes in -03: 5873 a. Added empty IANA Considerations section - to be done. 5875 Changes in -02: 5877 a. Tweaked abstract wording. 5878 b. Fixed some improper references. 5879 c. Removed bogus TZOFFSET entry from VTIMEZONE restriction table. 5880 d. Changed TZNAME entry in VTIMEZONE restriction table to "0+" from 5881 "0 or 1" to fall in line with 2445. 5882 e. Changed COMMENT entry in component restriction tables to "0+" 5883 from "0 or 1" to fall in line with 2445. 5884 f. Added ATTENDEE entry in VALARM restriction table to match email 5885 alarm type in 2445. 5886 g. Changed CATEGORIES entry in component restriction tables to "0+" 5887 from "0 or 1" to fall in line with 2445. 5888 h. Changed RESOURCES entry in component restriction tables to "0+" 5889 from "0 or 1" to fall in line with 2445. 5890 i. Changed CONTACT entry in VFREEBUSY restriction table to "0 or 1" 5891 from "0+" to fall in line with 2445. 5892 j. Made UID required in VFREEBUSY publish. 5893 k. Added COMPLETED entry in VTODO restriction tables to fall in line 5894 with 2445. 5895 l. Added REQUEST-STATUS entry in VJOURNAL restriction tables to fall 5896 in line with 2445. 5898 Changes in -01: 5899 a. Updated to 2445bis and 2447bis references. 5901 Changes in -00 (from RFC2446): 5902 a. Updated to latest i-d boilerplate text. 5903 b. Rewrote abstract and introduction. 5904 c. Reformatted Formatting Conventions section. 5905 d. Split iTIP Roles and Transactions into two sections 5906 e. iTIP roles uses a table to describe different roles 5907 f. Converted tables into xml2rfc format. 5909 Author's Address 5911 Cyrus Daboo (editor) 5912 Apple Inc. 5913 1 Infinite Loop 5914 Cupertino, CA 95014 5915 USA 5917 Email: cyrus@daboo.name 5918 URI: http://www.apple.com/