idnits 2.17.1 draft-ietf-calsify-2446bis-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 14. -- Found old boilerplate from RFC 3978, Section 5.5 on line 5269. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 5246. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 5253. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 5259. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- 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: +--------------------+----------+-----------------------------------+ | Component/Property | Presence | Comment | +--------------------+----------+-----------------------------------+ | METHOD | 1 | MUST be "REPLY" | | | | | | VFREEBUSY | 1 | | | ATTENDEE | 1 | (address of recipient replying) | | DTSTAMP | 1 | | | DTEND | 1 | DateTime values must be in UTC | | DTSTART | 1 | DateTime values must be in UTC | | FREEBUSY | 1+ | (values MUST all be of the same | | | | data type. Multiple instances | | | | are allowed. Multiple instances | | | | MUST be sorted in ascending | | | | order. Values MAY NOT overlap) | | ORGANIZER | 1 | MUST be the request originator's | | | | address | | UID | 1 | | | COMMENT | 0+ | | | CONTACT | 0 or 1 | | | REQUEST-STATUS | 0+ | | | URL | 0 or 1 | (specifies busy time URL) | | X-PROPERTY | 0+ | | | DURATION | 0 | | | SEQUENCE | 0 | | | | | | | X-COMPONENT | 0+ | | | | | | | VALARM | 0 | | | | | | | VEVENT | 0 | | | | | | | VTODO | 0 | | | | | | | VJOURNAL | 0 | | | | | | | VTIMEZONE | 0 | | +--------------------+----------+-----------------------------------+ -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (June 25, 2006) is 6507 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: 'US-ASCII' is mentioned on line 1529, but not defined == Outdated reference: A later version (-10) exists of draft-ietf-calsify-rfc2445bis-01 == Outdated reference: A later version (-11) exists of draft-ietf-calsify-rfc2447bis-02 ** Obsolete normative reference: RFC 2822 (Obsoleted by RFC 5322) Summary: 5 errors (**), 0 flaws (~~), 7 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group C. Daboo 3 Internet-Draft Editor 4 Expires: December 27, 2006 June 25, 2006 6 iCalendar Transport-Independent Interoperability Protocol (iTIP) 7 draft-ietf-calsify-2446bis-02 9 Status of this Memo 11 By submitting this Internet-Draft, each author represents that any 12 applicable patent or other IPR claims of which he or she is aware 13 have been or will be disclosed, and any of which he or she becomes 14 aware will be disclosed, in accordance with Section 6 of BCP 79. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 This Internet-Draft will expire on December 27, 2006. 34 Copyright Notice 36 Copyright (C) The Internet Society (2006). 38 Abstract 40 This document specifies a protocol using the iCalendar object 41 specification to provide scheduling interoperability between 42 different calendar systems. This is done without reference to a 43 specific transport protocol so as to allow multiple methods of 44 communication between systems. Subsequent documents will define 45 profiles of this protocol using specific interoperable methods of 46 communications between systems. 48 iTIP complements the iCalendar object specification by adding 49 semantics for group scheduling methods commonly available in current 50 calendar systems. These scheduling methods permit two or more 51 calendar systems to perform transactions such as publish, schedule, 52 reschedule, respond to scheduling requests, negotiation of changes or 53 cancel. 55 Change History (to be removed prior to publication as an RFC) 57 Changes in -02: 58 a. Tweaked abstract wording. 59 b. Fixed some improper references. 60 c. Removed bogus TZOFFSET entry from VTIMEZONE restriction table. 61 d. Changed TZNAME entry in VTIMEZONE restriction table to "0+" from 62 "0 or 1" to fall in line with 2445. 63 e. Changed COMMENT entry in component restriction tables to "0+" 64 from "0 or 1" to fall in line with 2445. 65 f. Added ATTENDEE entry in VALARM restriction table to match email 66 alarm type in 2445. 67 g. Changed CATEGORIES entry in component restriction tables to "0+" 68 from "0 or 1" to fall in line with 2445. 69 h. Changed RESOURCES entry in component restriction tables to "0+" 70 from "0 or 1" to fall in line with 2445. 71 i. Changed CONTACT entry in VFREEBUSY restriction table to "0 or 1" 72 from "0+" to fall in line with 2445. 73 j. Made UID required in VFREEBUSY publish. 74 k. Added COMPLETED entry in VTODO restriction tables to fall in line 75 with 2445. 76 l. Added REQUEST-STATUS entry in VJOURNAL restriction tables to fall 77 in line with 2445. 79 Changes in -01: 80 a. Updated to 2445bis and 2447bis references. 82 Changes in -00 (from RFC2446): 83 a. Updated to latest i-d boilerplate text. 84 b. Rewrote abstract and introduction. 85 c. Reformatted Formatting Conventions section. 86 d. Split ITIP Roles and Transactions into two sections 87 e. iTIP roles uses a table to describe different roles 88 f. Converted tables into xml2rfc format. 90 Table of Contents 92 1. Introduction and Overview . . . . . . . . . . . . . . . . . . 6 93 1.1. Formatting Conventions . . . . . . . . . . . . . . . . . 6 94 1.2. Related Documents . . . . . . . . . . . . . . . . . . . . 7 95 1.3. Roles . . . . . . . . . . . . . . . . . . . . . . . . . . 7 96 1.4. Methods . . . . . . . . . . . . . . . . . . . . . . . . . 8 97 2. Interoperability Models . . . . . . . . . . . . . . . . . . . 9 98 2.1. Application Protocol . . . . . . . . . . . . . . . . . . 10 99 2.1.1. Calendar Entry State . . . . . . . . . . . . . . . . 10 100 2.1.2. Delegation . . . . . . . . . . . . . . . . . . . . . 10 101 2.1.3. Acting on Behalf of other Calendar Users . . . . . . 11 102 2.1.4. Component Revisions . . . . . . . . . . . . . . . . . 11 103 2.1.5. Message Sequencing . . . . . . . . . . . . . . . . . 12 104 3. Application Protocol Elements . . . . . . . . . . . . . . . . 13 105 3.1. Common Component Restriction Tables . . . . . . . . . . . 13 106 3.2. Methods for VEVENT Calendar Components . . . . . . . . . 16 107 3.2.1. PUBLISH . . . . . . . . . . . . . . . . . . . . . . . 17 108 3.2.2. REQUEST . . . . . . . . . . . . . . . . . . . . . . . 18 109 3.2.3. REPLY . . . . . . . . . . . . . . . . . . . . . . . . 23 110 3.2.4. ADD . . . . . . . . . . . . . . . . . . . . . . . . . 25 111 3.2.5. CANCEL . . . . . . . . . . . . . . . . . . . . . . . 27 112 3.2.6. REFRESH . . . . . . . . . . . . . . . . . . . . . . . 29 113 3.2.7. COUNTER . . . . . . . . . . . . . . . . . . . . . . . 30 114 3.2.8. DECLINECOUNTER . . . . . . . . . . . . . . . . . . . 32 115 3.3. Methods For VFREEBUSY Components . . . . . . . . . . . . 33 116 3.3.1. PUBLISH . . . . . . . . . . . . . . . . . . . . . . . 35 117 3.3.2. REQUEST . . . . . . . . . . . . . . . . . . . . . . . 36 118 3.3.3. REPLY . . . . . . . . . . . . . . . . . . . . . . . . 37 119 3.4. Methods For VTODO Components . . . . . . . . . . . . . . 38 120 3.4.1. PUBLISH . . . . . . . . . . . . . . . . . . . . . . . 39 121 3.4.2. REQUEST . . . . . . . . . . . . . . . . . . . . . . . 41 122 3.4.3. REPLY . . . . . . . . . . . . . . . . . . . . . . . . 45 123 3.4.4. ADD . . . . . . . . . . . . . . . . . . . . . . . . . 47 124 3.4.5. CANCEL . . . . . . . . . . . . . . . . . . . . . . . 49 125 3.4.6. REFRESH . . . . . . . . . . . . . . . . . . . . . . . 51 126 3.4.7. COUNTER . . . . . . . . . . . . . . . . . . . . . . . 53 127 3.4.8. DECLINECOUNTER . . . . . . . . . . . . . . . . . . . 54 128 3.5. Methods For VJOURNAL Components . . . . . . . . . . . . . 56 129 3.5.1. PUBLISH . . . . . . . . . . . . . . . . . . . . . . . 56 130 3.5.2. ADD . . . . . . . . . . . . . . . . . . . . . . . . . 58 131 3.5.3. CANCEL . . . . . . . . . . . . . . . . . . . . . . . 60 132 3.6. Status Replies . . . . . . . . . . . . . . . . . . . . . 62 133 3.7. Implementation Considerations . . . . . . . . . . . . . . 64 134 3.7.1. Working With Recurrence Instances . . . . . . . . . . 64 135 3.7.2. Attendee Property Considerations . . . . . . . . . . 65 136 3.7.3. X-Tokens . . . . . . . . . . . . . . . . . . . . . . 66 137 4. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 66 138 4.1. Published Event Examples . . . . . . . . . . . . . . . . 66 139 4.1.1. A Minimal Published Event . . . . . . . . . . . . . . 67 140 4.1.2. Changing A Published Event . . . . . . . . . . . . . 67 141 4.1.3. Canceling A Published Event . . . . . . . . . . . . . 68 142 4.1.4. A Rich Published Event . . . . . . . . . . . . . . . 69 143 4.1.5. Anniversaries or Events attached to entire days . . . 70 144 4.2. Group Event Examples . . . . . . . . . . . . . . . . . . 70 145 4.2.1. A Group Event Request . . . . . . . . . . . . . . . . 71 146 4.2.2. Reply To A Group Event Request . . . . . . . . . . . 72 147 4.2.3. Update An Event . . . . . . . . . . . . . . . . . . . 72 148 4.2.4. Countering an Event Proposal . . . . . . . . . . . . 73 149 4.2.5. Delegating an Event . . . . . . . . . . . . . . . . . 75 150 4.2.6. Delegate Accepts the Meeting . . . . . . . . . . . . 78 151 4.2.7. Delegate Declines the Meeting . . . . . . . . . . . . 78 152 4.2.8. Forwarding an Event Request . . . . . . . . . . . . . 80 153 4.2.9. Cancel A Group Event . . . . . . . . . . . . . . . . 80 154 4.2.10. Removing Attendees . . . . . . . . . . . . . . . . . 81 155 4.2.11. Replacing the Organizer . . . . . . . . . . . . . . . 83 156 4.3. Busy Time Examples . . . . . . . . . . . . . . . . . . . 84 157 4.3.1. Request Busy Time . . . . . . . . . . . . . . . . . . 85 158 4.3.2. Reply To A Busy Time Request . . . . . . . . . . . . 85 159 4.4. Recurring Event and Time Zone Examples . . . . . . . . . 86 160 4.4.1. A Recurring Event Spanning Time Zones . . . . . . . . 86 161 4.4.2. Modify A Recurring Instance . . . . . . . . . . . . . 88 162 4.4.3. Cancel an Instance . . . . . . . . . . . . . . . . . 90 163 4.4.4. Cancel Recurring Event . . . . . . . . . . . . . . . 91 164 4.4.5. Change All Future Instances . . . . . . . . . . . . . 91 165 4.4.6. Add A New Instance To A Recurring Event . . . . . . . 92 166 4.4.7. Add A New Series of Instances To A Recurring Event . 93 167 4.4.8. Counter An Instance Of A Recurring Event . . . . . . 98 168 4.4.9. Error Reply To A Request . . . . . . . . . . . . . . 99 169 4.5. Group To-do Examples . . . . . . . . . . . . . . . . . . 100 170 4.5.1. A VTODO Request . . . . . . . . . . . . . . . . . . . 102 171 4.5.2. A VTODO Reply . . . . . . . . . . . . . . . . . . . . 102 172 4.5.3. A VTODO Request for Updated Status . . . . . . . . . 103 173 4.5.4. A Reply: Percent-Complete . . . . . . . . . . . . . . 103 174 4.5.5. A Reply: Completed . . . . . . . . . . . . . . . . . 103 175 4.5.6. An Updated VTODO Request . . . . . . . . . . . . . . 104 176 4.5.7. Recurring VTODOs . . . . . . . . . . . . . . . . . . 104 177 4.6. Journal Examples . . . . . . . . . . . . . . . . . . . . 106 178 4.7. Other Examples . . . . . . . . . . . . . . . . . . . . . 106 179 4.7.1. Event Refresh . . . . . . . . . . . . . . . . . . . . 106 180 4.7.2. Bad RECURRENCE-ID . . . . . . . . . . . . . . . . . . 107 181 5. Application Protocol Fallbacks . . . . . . . . . . . . . . . 109 182 5.1. Partial Implementation . . . . . . . . . . . . . . . . . 109 183 5.1.1. Event-Related Fallbacks . . . . . . . . . . . . . . . 110 184 5.1.2. Free/Busy-Related Fallbacks . . . . . . . . . . . . . 112 185 5.1.3. To-Do-Related Fallbacks . . . . . . . . . . . . . . . 113 186 5.1.4. Journal-Related Fallbacks . . . . . . . . . . . . . . 115 187 5.2. Latency Issues . . . . . . . . . . . . . . . . . . . . . 116 188 5.2.1. Cancellation of an Unknown Calendar Component. . . . 116 189 5.2.2. Unexpected Reply from an Unknown Delegate . . . . . . 117 190 5.3. Sequence Number . . . . . . . . . . . . . . . . . . . . . 117 191 6. Security Considerations . . . . . . . . . . . . . . . . . . . 117 192 6.1. Security Threats . . . . . . . . . . . . . . . . . . . . 117 193 6.1.1. Spoofing the "Organizer" . . . . . . . . . . . . . . 117 194 6.1.2. Spoofing the "Attendee" . . . . . . . . . . . . . . . 118 195 6.1.3. Unauthorized Replacement of the Organizer . . . . . . 118 196 6.1.4. Eavesdropping . . . . . . . . . . . . . . . . . . . . 118 197 6.1.5. Flooding a Calendar . . . . . . . . . . . . . . . . . 118 198 6.1.6. Procedural Alarms . . . . . . . . . . . . . . . . . . 118 199 6.1.7. Unauthorized REFRESH Requests . . . . . . . . . . . . 118 200 6.2. Recommendations . . . . . . . . . . . . . . . . . . . . . 119 201 6.2.1. Use of [RFC1847] to secure iTIP transactions . . . . 119 202 6.2.2. Implementation Controls . . . . . . . . . . . . . . . 119 203 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 120 204 7.1. Normative References . . . . . . . . . . . . . . . . . . 120 205 7.2. Informative References . . . . . . . . . . . . . . . . . 120 206 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 120 207 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 121 208 Intellectual Property and Copyright Statements . . . . . . . . . 122 210 1. Introduction and Overview 212 This document specifies how calendaring systems use iCalendar 213 [I-D.ietf-calsify-rfc2445bis] objects to interoperate with other 214 calendar systems. In particular, it specifies how to schedule 215 events, to-dos, or daily journal entries. It further specifies how 216 to search for available busy time information. It does so in a 217 general way without specifying how communication between different 218 systems actually takes place. Subsequent documents specify transport 219 bindings between systems that use this protocol. 221 This protocol is based on messages sent from an originator to one or 222 more recipients. For certain types of messages, a recipient may 223 reply, in order to update their status and may also return 224 transaction/request status information. The protocol supports the 225 ability for the message originator to modify or cancel the original 226 message. The protocol also supports the ability for recipients to 227 suggest changes to the originator of a message. The elements of the 228 protocol also define the user roles for its transactions. 230 1.1. Formatting Conventions 232 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 233 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY" and "OPTIONAL" in this 234 document are to be interpreted as described in [RFC2119] 236 Calendaring and scheduling roles are referred to in quoted-strings of 237 text with the first character of each word in upper case. For 238 example, "Organizer" refers to a role of a "Calendar User" (CU) 239 within the scheduling protocol. 241 Calendar components defined by [I-D.ietf-calsify-rfc2445bis] are 242 referred to with capitalized, quoted-strings of text. All calendar 243 components start with the letter "V". For example, "VEVENT" refers 244 to the event calendar component, "VTODO" refers to the to-do calendar 245 component and "VJOURNAL" refers to the daily journal calendar 246 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 [I-D.ietf-calsify-rfc2445bis] are referred to 255 with capitalized, quoted-strings of text, followed by the word 256 "property". For example, "ATTENDEE" property refers to the iCalendar 257 property used to convey the calendar address of a "Calendar User". 259 Property parameters defined by this memo are referred to with lower 260 case, quoted-strings of text, followed by the word "parameter". For 261 example, "value" parameter refers to the iCalendar property parameter 262 used to override the default data type for a property value. 264 Enumerated values defined by this memo are referred to with 265 capitalized text, either alone or followed by the word "value". 267 In tables, the quoted-string text is specified without quotes in 268 order to minimize the table length. 270 1.2. Related Documents 272 Implementers will need to be familiar with several other 273 specifications that, along with this one, describe the Internet 274 calendaring and scheduling standards. The related documents are: 276 [I-D.ietf-calsify-rfc2445bis] - specifies the objects, data types, 277 properties and property parameters used in the protocols, along 278 with the methods for representing and encoding them. 280 [I-D.ietf-calsify-rfc2447bis] specifies an Internet email binding 281 for iTIP. 283 This memo does not attempt to repeat the specification of concepts or 284 definitions from these other memos. Where possible, references are 285 made to the memo that provides for the specification of these 286 concepts or definitions. 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 one 292 of two 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 | The CUs asked to participate in the group meeting by | 302 | | the "Organizer" take on the role of "Attendee". | 303 +-----------+-------------------------------------------------------+ 305 Note that "ROLE" is also a descriptive parameter to the iCalendar 306 "ATTENDEE" property. Its use is to convey descriptive context to an 307 "Attendee" such as "chair", "required participant" or "non-required 308 participant" and has nothing to do with the calendaring workflow. 310 1.4. Methods 312 The ITIP methods are listed below and their usage and semantics are 313 defined in section 3 of this document. 315 +----------------+--------------------------------------------------+ 316 | Method | Description | 317 +----------------+--------------------------------------------------+ 318 | PUBLISH | Used to publish a calendar entry to one or more | 319 | | Calendar Users. There is no interactivity | 320 | | between the publisher and any other calendar | 321 | | user. An example might include a baseball team | 322 | | publishing its schedule to the public. | 323 | | | 324 | REQUEST | Used to schedule a calendar entry with other | 325 | | Calendar Users. Requests are interactive in | 326 | | that they require the receiver to respond using | 327 | | the Reply methods. Meeting Requests, Busy Time | 328 | | requests and the assignment of VTODOs to other | 329 | | Calendar Users are all examples. Requests are | 330 | | also used by the "Organizer" to update the | 331 | | status of a calendar entry. | 332 | | | 333 | REPLY | A Reply is used in response to a Request to | 334 | | convey "Attendee" status to the "Organizer". | 335 | | Replies are commonly used to respond to meeting | 336 | | and task requests. | 337 | | | 338 | ADD | Add one or more instances to an existing VEVENT, | 339 | | VTODO, or VJOURNAL. | 340 | | | 341 | CANCEL | Cancel one or more instances of an existing | 342 | | VEVENT, VTODO, or VJOURNAL. | 343 | | | 344 | REFRESH | The Refresh method is used by an "Attendee" to | 345 | | request the latest version of a calendar entry. | 346 | | | 347 | COUNTER | The Counter method is used by an "Attendee" to | 348 | | negotiate a change in the calendar entry. | 349 | | Examples include the request to change a | 350 | | proposed Event time or change the due date for a | 351 | | VTODO. | 352 | | | 353 | DECLINECOUNTER | Used by the "Organizer" to decline the proposed | 354 | | counter-proposal. | 355 +----------------+--------------------------------------------------+ 357 Group scheduling in iTIP is accomplished using the set of "request" 358 and "response" methods described above. The following table shows 359 the methods broken down by who can send them. 361 +------------+------------------------------------------------------+ 362 | Originator | Methods | 363 +------------+------------------------------------------------------+ 364 | Organizer | PUBLISH, REQUEST, ADD, CANCEL, DECLINECOUNTER | 365 | | | 366 | Attendee | REPLY, REFRESH, COUNTER, REQUEST only when | 367 | | delegating | 368 +------------+------------------------------------------------------+ 370 Note that for some calendar component types, the allowable methods 371 are a subset of the above set. 373 2. Interoperability Models 375 There are two distinct protocols relevant to interoperability: an 376 "Application Protocol" and a "Transport Protocol". The Application 377 Protocol defines the content of the iCalendar objects sent between 378 sender and receiver to accomplish the scheduling transactions listed 379 above. The Transport Protocol defines how the iCalendar objects are 380 sent between the sender and receiver. This document focuses on the 381 Application Protocol. Binding documents such as [I-D.ietf-calsify- 382 rfc2447bis] focus on the Transport Protocol. 384 The connection between Sender and Receiver in the diagram below 385 refers to the Application Protocol. The iCalendar objects passed 386 from the Sender to the Receiver are presented in Section 3, 387 Application Protocol Elements. 389 +----------+ +----------+ 390 | | iTIP | | 391 | Sender |<-------------------->| Receiver | 392 | | | | 393 +----------+ +----------+ 395 There are several variations of this diagram in which the Sender and 396 Receiver take on various roles of a "Calendar User Agent" (CUA) or a 397 "Calendar Service" (CS). 399 The architecture of iTIP is depicted in the diagram below. An 400 application written to this specification may work with bindings for 401 the store-and-forward transport, the real time transport, or both. 402 Also note that iTIP could be bound to other transports. 404 +-------------------+--------------------------+--------------------+ 405 | | iTIP | | 406 +-------------------+--------------------------+--------------------+ 407 | Real-time | Store-and-Forward | Other | 408 | Transport | Transport | Transports... | 409 +-------------------+--------------------------+--------------------+ 411 2.1. Application Protocol 413 In the iTIP model, a calendar entry is created and managed by an 414 "Organizer". The "Organizer" interacts with other CUs by sending one 415 or more of the iTIP messages listed above. "Attendees" use the 416 "REPLY" method to communicate their status. "Attendees" do not make 417 direct changes to the master calendar entry. They can, however, use 418 the "COUNTER" method to suggest changes to the "Organizer". In any 419 case, the "Organizer" has complete control over the master calendar 420 entry. 422 2.1.1. Calendar Entry State 424 There are two distinct states relevant to calendar entries: the 425 overall state of the entry and the state associated with an 426 "Attendee" to that entry. 428 The state of an entry is defined by the "STATUS" property and is 429 controlled by the "Organizer." There is no default value for the 430 "STATUS" property. The "Organizer" sets the "STATUS" property to the 431 appropriate value for each calendar entry. 433 The state of a particular "Attendee" relative to an entry is defined 434 by the "partstat" parameter in the "ATTENDEE" property for each 435 "Attendee". When an "Organizer" issues the initial entry, "Attendee" 436 status is unknown. The "Organizer" specifies this by setting the 437 "partstat" parameter to "NEEDS-ACTION". Each "Attendee" modifies 438 their "ATTENDEE" property "partstat" parameter to an appropriate 439 value as part of a "REPLY" message sent back to the "Organizer". 441 2.1.2. Delegation 443 Delegation is defined as the process by which an "Attendee" grants 444 another CU (or several CUs) the right to attend on their behalf. The 445 "Organizer" is made aware of this change because the delegating 446 "Attendee" informs the "Organizer". These steps are detailed in the 447 REQUEST method section. 449 2.1.3. Acting on Behalf of other Calendar Users 451 In many organizations one user will act on behalf of another to 452 organize and/or respond to meeting requests. ITIP provides two 453 mechanisms that support these activities. 455 First, the "Organizer" is treated as a special entity, separate from 456 "Attendees". All responses from "Attendees" flow to the "Organizer", 457 making it easy to separate a calendar user organizing a meeting from 458 calendar users attending the meeting. Additionally, iCalendar 459 provides descriptive roles for each "Attendee". For instance, a role 460 of "chair" may be ascribed to one or more "Attendees". The "chair" 461 and the "Organizer" may or may not be the same calendar user. This 462 maps well to scenarios where an assistant may manage meeting 463 logistics for another individual who chairs a meeting. 465 Second, a "sent-by" parameter may be specified in either the 466 "Organizer" or "Attendee" properties. When specified, the "sent-by" 467 parameter indicates that the responding CU acted on behalf of the 468 specified "Attendee" or "Organizer". 470 2.1.4. Component Revisions 472 The "SEQUENCE" property is used by the "Organizer" to indicate 473 revisions to the calendar component. The rules for incrementing the 474 "SEQUENCE" number are defined in [I-D.ietf-calsify-rfc2445bis]. For 475 clarity, these rules are paraphrased here in terms of how they are 476 applied in iTIP. For a given "UID" in a calendar component: 478 o For the "PUBLISH" and "REQUEST" methods, the "SEQUENCE" property 479 value is incremented according to the rules defined in [I-D.ietf- 480 calsify-rfc2445bis]. 482 o The "SEQUENCE" property value MUST be incremented each time the 483 "Organizer" uses the "ADD" or "CANCEL" methods. 485 o The "SEQUENCE" property value MUST NOT be incremented when using 486 "REPLY", "REFRESH", "COUNTER", "DECLINECOUNTER", or when sending a 487 delegation "REQUEST". 489 In some circumstances the "Organizer" may not have received responses 490 to the final revision sent out. In this situation, the "Organizer" 491 may wish to send an update "REQUEST", and set "RSVP=TRUE" for all 492 "Attendees", so that current responses can be collected. 494 The value of the "SEQUENCE" property contained in a response from an 495 "Attendee" may not always match the "Organizer's" revision. 496 Implementations may choose to have the CUA indicate to the CU that 497 the response is to an entry that has been revised and allow the CU to 498 decide whether or not to accept the response. 500 2.1.5. Message Sequencing 502 CUAs that handle the iTIP application protocol must often correlate a 503 component in a calendar store with a component received in the iTIP 504 message. For example, an event may be updated with a later revision 505 of the same event. To accomplish this, a CUA must correlate the 506 version of the event already in its calendar store with the version 507 sent in the iTIP message. In addition to this correlation, there are 508 several factors that can cause iTIP messages to arrive in an 509 unexpected order. That is, an "Organizer" could receive a reply to 510 an earlier revision of a component AFTER receiving a reply to a later 511 revision. 513 To maximize interoperability and to handle messages that arrive in an 514 unexpected order, use the following rules: 516 1. The primary key for referencing a particular iCalendar component 517 is the "UID" property value. To reference an instance of a 518 recurring component, the primary key is composed of the "UID" and 519 the "RECURRENCE-ID" properties. 521 2. The secondary key for referencing a component is the "SEQUENCE" 522 property value. For components where the "UID" is the same, the 523 component with the highest numeric value for the "SEQUENCE" 524 property obsoletes all other revisions of the component with 525 lower values. 527 3. "Attendees" send "REPLY" messages to the "Organizer". For 528 replies where the "UID" property value is the same, the value of 529 the "SEQUENCE" property indicates the revision of the component 530 to which the "Attendee" is replying. The reply with the highest 531 numeric value for the "SEQUENCE" property obsoletes all other 532 replies with lower values. 534 4. In situations where the "UID" and "SEQUENCE" properties match, 535 the "DTSTAMP" property is used as the tie-breaker. The component 536 with the latest "DTSTAMP" overrides all others. Similarly, for 537 "Attendee" responses where the "UID" property values match and 538 the "SEQUENCE" property values match, the response with the 539 latest "DTSTAMP" overrides all others. 541 Hence, CUAs must persist the following component properties: "UID", 542 "RECURRENCE-ID", "SEQUENCE", and "DTSTAMP". Furthermore, for each 543 "ATTENDEE" property of a component CUAs must persist the "SEQUENCE" 544 and "DTSTAMP" property values associated with the "Attendee's" 545 response. 547 3. Application Protocol Elements 549 ITIP messages are "text/calendar" MIME entities that contain 550 calendaring and scheduling information. The particular type of 551 iCalendar message is referred to as the "method type". Each method 552 type is identified by a "METHOD" property specified as part of the 553 "text/calendar" content type. The table below shows various 554 combinations of calendar components and the method types that this 555 memo supports. 557 +----------------+--------+-------+----------+-----------+ 558 | | VEVENT | VTODO | VJOURNAL | VFREEBUSY | 559 +----------------+--------+-------+----------+-----------+ 560 | PUBLISH | Yes | Yes | Yes | Yes | 561 | REQUEST | Yes | Yes | No | Yes | 562 | REFRESH | Yes | Yes | No | No | 563 | CANCEL | Yes | Yes | Yes | No | 564 | ADD | Yes | Yes | Yes | No | 565 | REPLY | Yes | Yes | No | Yes | 566 | COUNTER | Yes | Yes | No | No | 567 | DECLINECOUNTER | Yes | Yes | No | No | 568 +----------------+--------+-------+----------+-----------+ 570 Each method type is defined in terms of its associated components and 571 properties. Some components and properties are required, some are 572 optional and others are excluded. The restrictions are expressed in 573 this document using a simple "restriction table". The first column 574 indicates the name of a component or property. Properties of the 575 iCalendar object are not indented. Properties of a component are 576 indented. The second column contains "MUST" if the component or 577 property must be present, "MAY" if the component or property is 578 optional, and "NOT" if the component or property must not be present. 579 Entries in the second column sometimes contain comments for further 580 clarification. 582 3.1. Common Component Restriction Tables 584 The restriction table below applies to properties of the iCalendar 585 object. That is, the properties at the outermost scope. The 586 presence column uses the following values to assert whether a 587 property is required, is optional and the number of times it may 588 appear in the iCalendar object. 590 +----------------+--------------------------------------------------+ 591 | Presence Value | Description | 592 +----------------+--------------------------------------------------+ 593 | 1 | One instance MUST be present | 594 | 1+ | At least one instance MUST be present | 595 | 0 | Instances of this property Must NOT be present | 596 | 0+ | Multiple instances MAY be present | 597 | 0 or 1 | Up to 1 instance of this property MAY be present | 598 +----------------+--------------------------------------------------+ 600 The tables also call out "X-PROPERTY" and "X-COMPONENT" to show where 601 vendor-specific properties and components can appear. The tables do 602 not lay out the restrictions of property parameters. Those 603 restrictions are defined in [I-D.ietf-calsify-rfc2445bis]. 605 +--------------------+----------+---------------------+ 606 | Component/Property | Presence | Comment | 607 +--------------------+----------+---------------------+ 608 | CALSCALE | 0 or 1 | | 609 | PRODID | 1 | | 610 | VERSION | 1 | Value MUST be "2.0" | 611 | X-PROPERTY | 0+ | | 612 +--------------------+----------+---------------------+ 614 DateTime values MAY refer to a "VTIMEZONE" component. The property 615 restrictions in the table below apply to any "VTIMEZONE" component in 616 an ITIP message. 618 +--------------------+----------+-----------------------------------+ 619 | Component/Property | Presence | Comment | 620 +--------------------+----------+-----------------------------------+ 621 | VTIMEZONE | 0+ | MUST be present if any date/time | 622 | | | refers to timezone | 623 | DAYLIGHT | 0+ | MUST be one or more of either | 624 | | | STANDARD or DAYLIGHT | 625 | COMMENT | 0+ | | 626 | DTSTART | 1 | MUST be local time format | 627 | RDATE | 0+ | if present RRULE MUST NOT be | 628 | | | present | 629 | RRULE | 0+ | if present RDATE MUST NOT be | 630 | | | present | 631 | TZNAME | 0+ | | 632 | TZOFFSETFROM | 1 | | 633 | TZOFFSETTO | 1 | | 634 | X-PROPERTY | 0+ | | 635 | LAST-MODIFIED | 0 or 1 | | 636 | STANDARD | 0+ | MUST be one or more of either | 637 | | | STANDARD or DAYLIGHT | 638 | COMMENT | 0+ | | 639 | DTSTART | 1 | MUST be local time format | 640 | RDATE | 0+ | if present RRULE MUST NOT be | 641 | | | present | 642 | RRULE | 0+ | if present RDATE MUST NOT be | 643 | | | present | 644 | TZNAME | 0+ | | 645 | TZOFFSETFROM | 1 | | 646 | TZOFFSETTO | 1 | | 647 | X-PROPERTY | 0+ | | 648 | TZID | 1 | | 649 | TZURL | 0 or 1 | | 650 | X-PROPERTY | 0+ | | 651 +--------------------+----------+-----------------------------------+ 653 The property restrictions in the table below apply to any "VALARM" 654 component in an ITIP message. 656 +--------------------+----------+-----------------------------------+ 657 | Component/Property | Presence | Comment | 658 +--------------------+----------+-----------------------------------+ 659 | VALARM | 0+ | | 660 | ACTION | 1 | | 661 | ATTACH | 0+ | | 662 | ATTENDEE | 0+ | | 663 | DESCRIPTION | 0 or 1 | | 664 | DURATION | 0 or 1 | if present REPEAT MUST be present | 665 | REPEAT | 0 or 1 | if present DURATION MUST be | 666 | | | present | 667 | SUMMARY | 0 or 1 | | 668 | TRIGGER | 1 | | 669 | X-PROPERTY | 0+ | | 670 +--------------------+----------+-----------------------------------+ 672 3.2. Methods for VEVENT Calendar Components 674 This section defines the property set restrictions for the method 675 types that are applicable to the "VEVENT" calendar component. Each 676 method is defined using a table that clarifies the property 677 constraints that define the particular method. 679 The following summarizes the methods that are defined for the 680 "VEVENT" calendar component. 682 +----------------+--------------------------------------------------+ 683 | Method | Description | 684 +----------------+--------------------------------------------------+ 685 | PUBLISH | Post notification of an event. Used primarily | 686 | | as a method of advertising the existence of an | 687 | | event. | 688 | | | 689 | REQUEST | Make a request for an event. This is an | 690 | | explicit invitation to one or more "Attendees". | 691 | | Event Requests are also used to update or change | 692 | | an existing event. Clients that cannot handle | 693 | | REQUEST may degrade the event to view it as an | 694 | | PUBLISH. | 695 | | | 696 | REPLY | Reply to an event request. Clients may set | 697 | | their status ("partstat") to ACCEPTED, DECLINED, | 698 | | TENTATIVE, or DELEGATED. | 699 | | | 700 | ADD | Add one or more instances to an existing event. | 701 | | | 702 | CANCEL | Cancel one or more instances of an existing | 703 | | event. | 704 | | | 705 | REFRESH | A request is sent to an "Organizer" by an | 706 | | "Attendee" asking for the latest version of an | 707 | | event to be resent to the requester. | 708 | | | 709 | COUNTER | Counter a REQUEST with an alternative proposal, | 710 | | Sent by an "Attendee" to the "Organizer". | 711 | | | 712 | DECLINECOUNTER | Decline a counter proposal. Sent to an | 713 | | "Attendee" by the "Organizer". | 714 +----------------+--------------------------------------------------+ 716 3.2.1. PUBLISH 718 The "PUBLISH" method in a "VEVENT" calendar component is an 719 unsolicited posting of an iCalendar object. Any CU may add published 720 components to their calendar. The "Organizer" MUST be present in a 721 published iCalendar component. "Attendees" MUST NOT be present. Its 722 expected usage is for encapsulating an arbitrary event as an 723 iCalendar object. The "Organizer" may subsequently update (with 724 another "PUBLISH" method), add instances to (with an "ADD" method), 725 or cancel (with a "CANCEL" method) a previously published "VEVENT" 726 calendar component. 728 This method type is an iCalendar object that conforms to the 729 following property constraints: 731 +--------------------+----------+-----------------------------------+ 732 | Component/Property | Presence | Comment | 733 +--------------------+----------+-----------------------------------+ 734 | METHOD | 1 | MUST equal "PUBLISH" | 735 | | | | 736 | VEVENT | 1+ | | 737 | DTSTAMP | 1 | | 738 | DTSTART | 1 | | 739 | ORGANIZER | 1 | | 740 | SUMMARY | 1 | Can be null. | 741 | UID | 1 | | 742 | RECURRENCE-ID | 0 or 1 | Only if referring to an instance | 743 | | | of a recurring calendar | 744 | | | component. Otherwise it MUST NOT | 745 | | | be present. | 746 | SEQUENCE | 0 or 1 | MUST be present if value is | 747 | | | greater than 0, MAY be present if | 748 | | | 0 | 749 | ATTACH | 0+ | | 750 | CATEGORIES | 0+ | | 751 | CLASS | 0 or 1 | | 752 | COMMENT | 0+ | | 753 | CONTACT | 0 or 1 | | 754 | CREATED | 0 or 1 | | 755 | DESCRIPTION | 0 or 1 | Can be null | 756 | DTEND | 0 or 1 | If present DURATION MUST NOT be | 757 | | | present | 758 | DURATION | 0 or 1 | If present DTEND MUST NOT be | 759 | | | present | 760 | EXDATE | 0+ | | 761 | EXRULE | 0+ | | 762 | GEO | 0 or 1 | | 763 | LAST-MODIFIED | 0 or 1 | | 764 | LOCATION | 0 or 1 | | 765 | PRIORITY | 0 or 1 | | 766 | RDATE | 0+ | | 767 | RELATED-TO | 0+ | | 768 | RESOURCES | 0+ | | 769 | RRULE | 0+ | | 770 | STATUS | 0 or 1 | MAY be one of | 771 | | | TENTATIVE/CONFIRMED/CANCELLED | 772 | TRANSP | 0 or 1 | | 773 | URL | 0 or 1 | | 774 | X-PROPERTY | 0+ | | 775 | ATTENDEE | 0 | | 776 | REQUEST-STATUS | 0 | | 777 | | | | 778 | VALARM | 0+ | | 779 | | | | 780 | VFREEBUSY | 0 | | 781 | | | | 782 | VJOURNAL | 0 | | 783 | | | | 784 | VTODO | 0 | | 785 | | | | 786 | VTIMEZONE | 0+ | MUST be present if any date/time | 787 | | | refers to a timezone | 788 | | | | 789 | X-COMPONENT | 0+ | | 790 +--------------------+----------+-----------------------------------+ 792 3.2.2. REQUEST 794 The "REQUEST" method in a "VEVENT" component provides the following 795 scheduling functions: 797 o Invite "Attendees" to an event 798 o Reschedule an existing event 799 o Response to a REFRESH request 800 o Update the details of an existing event, without rescheduling it 801 o Update the status of "Attendees" of an existing event, without 802 rescheduling it 803 o Reconfirm an existing event, without rescheduling it 804 o Forward a "VEVENT" to another uninvited CU 805 o For an existing "VEVENT" calendar component, delegate the role of 806 "Attendee" to another CU 807 o For an existing "VEVENT" calendar component, changing the role of 808 "Organizer" to another CU 810 The "Organizer" originates the "REQUEST". The recipients of the 811 "REQUEST" method are the CUs invited to the event, the "Attendees". 812 "Attendees" use the "REPLY" method to convey attendance status to the 813 "Organizer". 815 The "UID" and "SEQUENCE" properties are used to distinguish the 816 various uses of the "REQUEST" method. If the "UID" property value in 817 the "REQUEST" is not found on the recipient's calendar, then the 818 "REQUEST" is for a new "VEVENT" calendar component. If the "UID" 819 property value is found on the recipient's calendar, then the 820 "REQUEST" is for a rescheduling, an update, or a reconfirm of the 821 "VEVENT" calendar component. 823 For the "REQUEST" method, multiple "VEVENT" components in a single 824 iCalendar object are only permitted when for components with the same 825 "UID" property. That is, a series of recurring events may have 826 instance-specific information. In this case, multiple "VEVENT" 827 components are needed to express the entire series. 829 This method type is an iCalendar object that conforms to the 830 following property constraints: 832 +--------------------+----------+-----------------------------------+ 833 | Component/Property | Presence | Comment | 834 +--------------------+----------+-----------------------------------+ 835 | METHOD | 1 | MUST be "REQUEST" | 836 | | | | 837 | VEVENT | 1+ | All components MUST have the same | 838 | | | UID | 839 | ATTENDEE | 1+ | | 840 | DTSTAMP | 1 | | 841 | DTSTART | 1 | | 842 | ORGANIZER | 1 | | 843 | SEQUENCE | 0 or 1 | MUST be present if value is | 844 | | | greater than 0, MAY be present if | 845 | | | 0 | 846 | SUMMARY | 1 | Can be null | 847 | UID | 1 | | 848 | ATTACH | 0+ | | 849 | CATEGORIES | 0+ | | 850 | CLASS | 0 or 1 | | 851 | COMMENT | 0+ | | 852 | CONTACT | 0+ | | 853 | CREATED | 0 or 1 | | 854 | DESCRIPTION | 0 or 1 | Can be null | 855 | DTEND | 0 or 1 | if present DURATION MUST NOT be | 856 | | | present | 857 | DURATION | 0 or 1 | if present DTEND MUST NOT be | 858 | | | present | 859 | EXDATE | 0+ | | 860 | EXRULE | 0+ | | 861 | GEO | 0 or 1 | | 862 | LAST-MODIFIED | 0 or 1 | | 863 | LOCATION | 0 or 1 | | 864 | PRIORITY | 0 or 1 | | 865 | RDATE | 0+ | | 866 | RECURRENCE-ID | 0 or 1 | only if referring to an instance | 867 | | | of a recurring calendar | 868 | | | component. Otherwise it MUST NOT | 869 | | | be present. | 870 | RELATED-TO | 0+ | | 871 | REQUEST-STATUS | 0+ | | 872 | RESOURCES | 0+ | | 873 | RRULE | 0+ | | 874 | STATUS | 0 or 1 | MAY be one of TENTATIVE/CONFIRMED | 875 | TRANSP | 0 or 1 | | 876 | URL | 0 or 1 | | 877 | X-PROPERTY | 0+ | | 878 | | | | 879 | VALARM | 0+ | | 880 | | | | 881 | VTIMEZONE | 0+ | MUST be present if any date/time | 882 | | | refers to a timezone | 883 | | | | 884 | X-COMPONENT | 0+ | | 885 | | | | 886 | VFREEBUSY | 0 | | 887 | | | | 888 | VJOURNAL | 0 | | 889 | | | | 890 | VTODO | 0 | | 891 +--------------------+----------+-----------------------------------+ 893 3.2.2.1. Rescheduling an Event 895 The "REQUEST" method may be used to reschedule an event. A 896 rescheduled event involves a change to the existing event in terms of 897 its time or recurrence intervals and possibly the location or 898 description. If the recipient CUA of a "REQUEST" method finds that 899 the "UID" property value already exists on the calendar, but that the 900 "SEQUENCE" (or "DTSTAMP") property value in the "REQUEST" method is 901 greater than the value for the existing event, then the "REQUEST" 902 method describes a rescheduling of the event. 904 3.2.2.2. Updating or Reconfirmation of an Event 906 The "REQUEST" method may be used to update or reconfirm an event. An 907 update to an existing event does not involve changes to the time or 908 recurrence intervals, and might not involve a change to the location 909 or description for the event. If the recipient CUA of a "REQUEST" 910 method finds that the "UID" property value already exists on the 911 calendar and that the "SEQUENCE" property value in the "REQUEST" is 912 the same as the value for the existing event, then the "REQUEST" 913 method describes an update of the event details, but no rescheduling 914 of the event. 916 The update "REQUEST" method is the appropriate response to a 917 "REFRESH" method sent from an "Attendee" to the "Organizer" of an 918 event. 920 The "Organizer" of an event may also send unsolicited "REQUEST" 921 methods. The unsolicited "REQUEST" methods may be used to update the 922 details of the event without rescheduling it, to update the 923 "partstat" parameter of "Attendees", or to reconfirm the event. 925 3.2.2.3. Delegating an Event to another CU 927 Some calendar and scheduling systems allow "Attendees" to delegate 928 their presence at an event to another calendar user. ITIP supports 929 this concept using the following workflow. Any "Attendee" may 930 delegate their right to participate in a calendar VEVENT to another 931 CU. The implication is that the delegate participates in lieu of the 932 original "Attendee"; NOT in addition to the "Attendee". The 933 delegator MUST notify the "Organizer" of this action using the steps 934 outlined below. Implementations may support or restrict delegation 935 as they see fit. For instance, some implementations may restrict a 936 delegate from delegating a "REQUEST" to another CU. 938 The "Delegator" of an event forwards the existing "REQUEST" to the 939 "Delegate". The "REQUEST" method MUST include an "ATTENDEE" property 940 with the calendar address of the "Delegate". The "Delegator" MUST 941 also send a "REPLY" method to the "Organizer" with the "Delegator's" 942 "ATTENDEE" property "partstat" parameter value set to "delegated". 943 In addition, the "delegated-to" parameter MUST be included with the 944 calendar address of the "Delegate". 946 In response to the request, the "Delegate" MUST send a "REPLY" method 947 to the "Organizer" and optionally, to the "Delegator". The "REPLY" 948 method " SHOULD include the "ATTENDEE" property with the "delegated- 949 from" parameter value of the "Delegator's" calendar address. 951 The "Delegator" may continue to receive updates to the event even 952 though they will not be attending. This is accomplished by the 953 "Delegator" setting their "role" attribute to " NON-PARTICIPANT" in 954 the "REPLY" to the "Organizer" 956 3.2.2.4. Changing the Organizer 958 The situation may arise where the "Organizer" of a VEVENT is no 959 longer able to perform the "Organizer" role and abdicates without 960 passing on the "Organizer" role to someone else. When this occurs 961 the "Attendees" of the VEVENT may use out-of-band mechanisms to 962 communicate the situation and agree upon a new "Organizer". The new 963 "Organizer" should then send out a new "REQUEST" with a modified 964 version of the VEVENT in which the "SEQUENCE" number has been 965 incremented and value of the "ORGANIZER" property has been changed to 966 the calendar address of the new "Organizer". 968 3.2.2.5. Sending on Behalf of the Organizer 970 There are a number of scenarios that support the need for a calendar 971 user to act on behalf of the "Organizer" without explicit role 972 changing. This might be the case if the CU designated as "Organizer" 973 was sick or unable to perform duties associated with that function. 974 In these cases iTIP supports the notion of one CU acting on behalf of 975 another. Using the "sent-by" parameter, a calendar user could send 976 an updated "VEVENT" REQUEST. In the case where one CU sends on 977 behalf of another CU, the "Attendee" responses are still directed 978 back towards the CU designated as "Organizer". 980 3.2.2.6. Forwarding to An Uninvited CU 982 An "Attendee" invited to an event may invite another uninvited CU to 983 the event. The invited "Attendee" accomplishes this by forwarding 984 the original "REQUEST" method to the uninvited CU. The "Organizer" 985 decides whether or not the uninvited CU is added to the attendee 986 list. If the "Organizer" decides not to add the uninvited CU no 987 further action is required, however the "Organizer" MAY send the 988 uninvited CU a "CANCEL" message. If the "Organizer" decides to add 989 an uninvited CU, a new "ATTENDEE" property is added for the uninvited 990 CU with its property parameters set as the "Organizer" deems 991 appropriate. When forwarding a "REQUEST" to another CU, the 992 forwarding "Attendee" MUST NOT make changes to the VEVENT property 993 set. 995 3.2.2.7. Updating Attendee Status 997 The "Organizer" of an event may also request updated status from one 998 or more "Attendees. The "Organizer" sends a "REQUEST" method to the 999 "Attendee" and sets the "ATTENDEE;RSVP=TRUE" property parameter. The 1000 "SEQUENCE" property for the event is not changed from its previous 1001 value. A recipient will determine that the only change in the 1002 "REQUEST" is that their "RSVP" property parameter indicates a request 1003 for updated status. The recipient SHOULD respond with a "REPLY" 1004 method indicating their current status with respect to the "REQUEST". 1006 3.2.3. REPLY 1008 The "REPLY" method in a "VEVENT" calendar component is used to 1009 respond (e.g., accept or decline) to a "REQUEST" or to reply to a 1010 delegation "REQUEST". When used to provide a delegation response, 1011 the "Delegator" SHOULD include the calendar address of the "Delegate" 1012 on the "delegated-to" property parameter of the "Delegator's" 1013 "ATTENDEE" property. The "Delegate" SHOULD include the calendar 1014 address of the "Delegator" on the "delegated-from" property parameter 1015 of the "Delegate's" "ATTENDEE" property. 1017 The "REPLY" method may also be used to respond to an unsuccessful 1018 "REQUEST" method. Depending on the value of the "REQUEST-STATUS" 1019 property no scheduling action may have been performed. 1021 The "Organizer" of an event may receive the "REPLY" method from a CU 1022 not in the original "REQUEST". For example, a "REPLY" may be 1023 received from a "Delegate" to an event. In addition, the "REPLY" 1024 method may be received from an unknown CU (a "Party Crasher"). This 1025 uninvited "Attendee" may be accepted, or the "Organizer" may cancel 1026 the event for the uninvited "Attendee" by sending a "CANCEL" method 1027 to the uninvited "Attendee". 1029 An "Attendee" can include a message to the "Organizer" using the 1030 "COMMENT" property. For example, if the user indicates tentative 1031 acceptance and wants to let the "Organizer" know why, the reason can 1032 be expressed in the "COMMENT" property value. 1034 The "Organizer" may also receive a "REPLY" from one CU on behalf of 1035 another. Like the scenario enumerated above for the "Organizer", 1036 "Attendees" may have another CU respond on their behalf. This is 1037 done using the "sent-by" parameter. 1039 The optional properties listed in the table below (those listed as 1040 "0+" or "0 or 1") MUST NOT be changed from those of the original 1041 request. If property changes are desired the COUNTER message must be 1042 used. 1044 This method type is an iCalendar object that conforms to the 1045 following property constraints: 1047 +--------------------+----------+-----------------------------------+ 1048 | Component/Property | Presence | Comment | 1049 +--------------------+----------+-----------------------------------+ 1050 | METHOD | 1 | MUST be "REPLY" | 1051 | | | | 1052 | VEVENT | 1+ | All components MUST have the same | 1053 | | | UID | 1054 | ATTENDEE | 1 | MUST be the address of the | 1055 | | | Attendee replying. | 1056 | DTSTAMP | 1 | | 1057 | ORGANIZER | 1 | | 1058 | RECURRENCE-ID | 0 or 1 | only if referring to an instance | 1059 | | | of a recurring calendar | 1060 | | | component. Otherwise it must NOT | 1061 | | | be present. | 1062 | UID | 1 | MUST be the UID of the original | 1063 | | | REQUEST | 1064 | SEQUENCE | 0 or 1 | MUST if non-zero, MUST be the | 1065 | | | sequence number of the original | 1066 | | | REQUEST. MAY be present if 0. | 1067 | ATTACH | 0+ | | 1068 | CATEGORIES | 0+ | | 1069 | CLASS | 0 or 1 | | 1070 | COMMENT | 0+ | | 1071 | CONTACT | 0+ | | 1072 | CREATED | 0 or 1 | | 1073 | DESCRIPTION | 0 or 1 | | 1074 | DTEND | 0 or 1 | if present DURATION MUST NOT be | 1075 | | | present | 1076 | DTSTART | 0 or 1 | | 1077 | DURATION | 0 or 1 | if present DTEND MUST NOT be | 1078 | | | present | 1079 | EXDATE | 0+ | | 1080 | EXRULE | 0+ | | 1081 | GEO | 0 or 1 | | 1082 | LAST-MODIFIED | 0 or 1 | | 1083 | LOCATION | 0 or 1 | | 1084 | PRIORITY | 0 or 1 | | 1085 | RDATE | 0+ | | 1086 | RELATED-TO | 0+ | | 1087 | RESOURCES | 0+ | | 1088 | REQUEST-STATUS | 0+ | | 1089 | RRULE | 0+ | | 1090 | STATUS | 0 or 1 | | 1091 | SUMMARY | 0 or 1 | | 1092 | TRANSP | 0 or 1 | | 1093 | URL | 0 or 1 | | 1094 | X-PROPERTY | 0+ | | 1095 | | | | 1096 | VTIMEZONE | 0 or 1 | MUST be present if any date/time | 1097 | | | refers to a timezone | 1098 | | | | 1099 | X-COMPONENT | 0+ | | 1100 | | | | 1101 | VALARM | 0 | | 1102 | | | | 1103 | VFREEBUSY | 0 | | 1104 | | | | 1105 | VJOURNAL | 0 | | 1106 | | | | 1107 | VTODO | 0 | | 1108 +--------------------+----------+-----------------------------------+ 1110 3.2.4. ADD 1112 The "ADD" method in a "VEVENT" calendar component is used to add one 1113 or more instances to an existing "VEVENT". Unlike the "REQUEST" 1114 method, when using issuing an "ADD" method, the "Organizer" does not 1115 send the full "VEVENT" description; only the new instance(s). The 1116 "ADD" method is especially useful if there are instance-specific 1117 properties to be preserved in a recurring "VEVENT". For instance, an 1118 "Organizer" may have originally scheduled a weekly Thursday meeting. 1119 At some point, several instances changed. Location or start time may 1120 have changed, or some instances may have unique "DESCRIPTION" 1121 properties. The "ADD" method allows the "Organizer" to add new 1122 instances to an existing event using a single ITIP message without 1123 redefining the entire recurring pattern. 1125 The "UID" must be that of the existing event. If the "UID" property 1126 value in the "ADD" is not found on the recipient's calendar, then the 1127 recipient SHOULD send a "REFRESH" to the "Organizer" in order to be 1128 updated with the latest version of the "VEVENT". If an "Attendee" 1129 implementation does not support the "ADD" method it should respond 1130 with a "REQUEST-STATUS" value of 3.14 and ask for a "REFRESH". 1132 This method type is an iCalendar object that conforms to the 1133 following property constraints: 1135 +--------------------+----------+-----------------------------------+ 1136 | Component/Property | Presence | Comment | 1137 +--------------------+----------+-----------------------------------+ 1138 | METHOD | 1 | MUST be "ADD" | 1139 | | | | 1140 | VEVENT | 1 | | 1141 | DTSTAMP | 1 | | 1142 | DTSTART | 1 | | 1143 | ORGANIZER | 1 | | 1144 | SEQUENCE | 1 | MUST be greater than 0 | 1145 | SUMMARY | 1 | Can be null | 1146 | UID | 1 | MUST match that of the original | 1147 | | | event | 1148 | ATTACH | 0+ | | 1149 | ATTENDEE | 0+ | | 1150 | CATEGORIES | 0+ | | 1151 | CLASS | 0 or 1 | | 1152 | COMMENT | 0+ | | 1153 | CONTACT | 0+ | | 1154 | CREATED | 0 or 1 | | 1155 | DESCRIPTION | 0 or 1 | Can be null | 1156 | DTEND | 0 or 1 | if present DURATION MUST NOT be | 1157 | | | present | 1158 | DURATION | 0 or 1 | if present DTEND MUST NOT be | 1159 | | | present | 1160 | EXDATE | 0+ | | 1161 | EXRULE | 0+ | | 1162 | GEO | 0 or 1 | | 1163 | LAST-MODIFIED | 0 or 1 | | 1164 | LOCATION | 0 or 1 | | 1165 | PRIORITY | 0 or 1 | | 1166 | RDATE | 0+ | | 1167 | RELATED-TO | 0+ | | 1168 | RESOURCES | 0+ | | 1169 | RRULE | 0+ | | 1170 | STATUS | 0 or 1 | MAY be one of TENTATIVE/CONFIRMED | 1171 | TRANSP | 0 or 1 | | 1172 | URL | 0 or 1 | | 1173 | X-PROPERTY | 0+ | | 1174 | RECURRENCE-ID | 0 | | 1175 | REQUEST-STATUS | 0 | | 1176 | | | | 1177 | VALARM | 0+ | | 1178 | | | | 1179 | VTIMEZONE | 0+ | MUST be present if any date/time | 1180 | | | refers to a timezone | 1181 | | | | 1182 | X-COMPONENT | 0+ | | 1183 | | | | 1184 | VFREEBUSY | 0 | | 1185 | | | | 1186 | VTODO | 0 | | 1187 | | | | 1188 | VJOURNAL | 0 | | 1189 +--------------------+----------+-----------------------------------+ 1191 3.2.5. CANCEL 1193 The "CANCEL" method in a "VEVENT" calendar component is used to send 1194 a cancellation notice of an existing event request to the 1195 "Attendees". The message is sent by the "Organizer" of the event. 1196 For a recurring event, either the whole event or instances of an 1197 event may be cancelled. To cancel the complete range of recurring 1198 event, the "UID" property value for the event MUST be specified and a 1199 "RECURRENCE-ID" MUST NOT be specified in the "CANCEL" method. In 1200 order to cancel an individual instance of the event, the 1201 "RECURRENCE-ID" property value for the event MUST be specified in the 1202 "CANCEL" method. 1204 There are two options for canceling a sequence of instances of a 1205 recurring "VEVENT" calendar component: 1207 a. the "RECURRENCE-ID" property for an instance in the sequence MUST 1208 be specified with the "RANGE" property parameter value of 1209 THISANDPRIOR (or THISANDFUTURE) to indicate cancellation of the 1210 specified "VEVENT" calendar component and all instances before 1211 (or after); or 1213 b. individual recurrence instances may be cancelled by specifying 1214 multiple "RECURRENCE-ID" properties corresponding to the 1215 instances to be cancelled. 1217 When a "VEVENT" is cancelled, the "SEQUENCE" property value MUST be 1218 incremented. 1220 This method type is an iCalendar object that conforms to the 1221 following property constraints: 1223 +--------------------+----------+-----------------------------------+ 1224 | Component/Property | Presence | Comment | 1225 +--------------------+----------+-----------------------------------+ 1226 | METHOD | 1 | MUST be "CANCEL" | 1227 | | | | 1228 | VEVENT | 1+ | All must have the same UID | 1229 | ATTENDEE | 0+ | MUST include all "Attendees" | 1230 | | | being removed the event. MUST | 1231 | | | include all "Attendees" if the | 1232 | | | entire event is cancelled. | 1233 | DTSTAMP | 1 | | 1234 | ORGANIZER | 1 | | 1235 | SEQUENCE | 1 | | 1236 | UID | 1 | MUST be the UID of the original | 1237 | | | REQUEST | 1238 | COMMENT | 0+ | | 1239 | ATTACH | 0+ | | 1240 | CATEGORIES | 0+ | | 1241 | CLASS | 0 or 1 | | 1242 | CONTACT | 0+ | | 1243 | CREATED | 0 or 1 | | 1244 | DESCRIPTION | 0 or 1 | | 1245 | DTEND | 0 or 1 | if present DURATION MUST NOT be | 1246 | | | present | 1247 | DTSTART | 0 or 1 | | 1248 | DURATION | 0 or 1 | if present DTEND MUST NOT be | 1249 | | | present | 1250 | EXDATE | 0+ | | 1251 | EXRULE | 0+ | | 1252 | GEO | 0 or 1 | | 1253 | LAST-MODIFIED | 0 or 1 | | 1254 | LOCATION | 0 or 1 | | 1255 | PRIORITY | 0 or 1 | | 1256 | RDATE | 0+ | | 1257 | RECURRENCE-ID | 0 or 1 | MUST be present if referring to | 1258 | | | one or more or more recurring | 1259 | | | instances. Otherwise it MUST NOT | 1260 | | | be present | 1261 | RELATED-TO | 0+ | | 1262 | RESOURCES | 0+ | | 1263 | RRULE | 0+ | | 1264 | STATUS | 0 or 1 | MUST be set to CANCELLED. If | 1265 | | | uninviting specific "Attendees" | 1266 | | | then MUST NOT be included. | 1267 | SUMMARY | 0 or 1 | | 1268 | TRANSP | 0 or 1 | | 1269 | URL | 0 or 1 | | 1270 | X-PROPERTY | 0+ | | 1271 | REQUEST-STATUS | 0 | | 1272 | | | | 1273 | VTIMEZONE | 0+ | MUST be present if any date/time | 1274 | | | refers to a timezone | 1275 | | | | 1276 | X-COMPONENT | 0+ | | 1277 | | | | 1278 | VTODO | 0 | | 1279 | | | | 1280 | VJOURNAL | 0 | | 1281 | | | | 1282 | VFREEBUSY | 0 | | 1283 | | | | 1284 | VALARM | 0 | | 1285 +--------------------+----------+-----------------------------------+ 1287 3.2.6. REFRESH 1289 The "REFRESH" method in a "VEVENT" calendar component is used by 1290 "Attendees" of an existing event to request an updated description 1291 from the event "Organizer". The "REFRESH" method must specify the 1292 "UID" property of the event to update. A recurrence instance of an 1293 event may be requested by specifying the "RECURRENCE-ID" property 1294 corresponding to the associated event. The "Organizer" responds with 1295 the latest description and version of the event. 1297 This method type is an iCalendar object that conforms to the 1298 following property constraints: 1300 +--------------------+----------+-----------------------------------+ 1301 | Component/Property | Presence | Comment | 1302 +--------------------+----------+-----------------------------------+ 1303 | METHOD | 1 | MUST be "REFRESH" | 1304 | | | | 1305 | VEVENT | 1 | | 1306 | ATTENDEE | 1 | MUST be the address of requester | 1307 | DTSTAMP | 1 | | 1308 | ORGANIZER | 1 | | 1309 | UID | 1 | MUST be the UID associated with | 1310 | | | original REQUEST | 1311 | COMMENT | 0+ | | 1312 | RECURRENCE-ID | 0 or 1 | MUST only if referring to an | 1313 | | | instance of a recurring calendar | 1314 | | | component. Otherwise it must NOT | 1315 | | | be present. | 1316 | X-PROPERTY | 0+ | | 1317 | ATTACH | 0 | | 1318 | CATEGORIES | 0 | | 1319 | CLASS | 0 | | 1320 | CONTACT | 0 | | 1321 | CREATED | 0 | | 1322 | DESCRIPTION | 0 | | 1323 | DTEND | 0 | | 1324 | DTSTART | 0 | | 1325 | DURATION | 0 | | 1326 | EXDATE | 0 | | 1327 | EXRULE | 0 | | 1328 | GEO | 0 | | 1329 | LAST-MODIFIED | 0 | | 1330 | LOCATION | 0 | | 1331 | PRIORITY | 0 | | 1332 | RDATE | 0 | | 1333 | RELATED-TO | 0 | | 1334 | REQUEST-STATUS | 0 | | 1335 | RESOURCES | 0 | | 1336 | RRULE | 0 | | 1337 | SEQUENCE | 0 | | 1338 | STATUS | 0 | | 1339 | SUMMARY | 0 | | 1340 | TRANSP | 0 | | 1341 | URL | 0 | | 1342 | | | | 1343 | X-COMPONENT | 0+ | | 1344 | | | | 1345 | VTODO | 0 | | 1346 | | | | 1347 | VJOURNAL | 0 | | 1348 | | | | 1349 | VFREEBUSY | 0 | | 1350 | | | | 1351 | VTIMEZONE | 0 | | 1352 | | | | 1353 | VALARM | 0 | | 1354 +--------------------+----------+-----------------------------------+ 1356 3.2.7. COUNTER 1358 The "COUNTER" method for a "VEVENT" calendar component is used by an 1359 "Attendee" of an existing event to submit to the "Organizer" a 1360 counter proposal to the event description. The "Attendee" sends this 1361 message to the "Organizer" of the event. 1363 The counter proposal is an iCalendar object consisting of a VEVENT 1364 calendar component describing the complete description of the 1365 alternate event. 1367 The "Organizer" rejects the counter proposal by sending the 1368 "Attendee" a VEVENT "DECLINECOUNTER" method. The "Organizer" accepts 1369 the counter proposal by rescheduling the event as described in 1370 section 3.2.2.1 Rescheduling an Event. 1372 This method type is an iCalendar object that conforms to the 1373 following property constraints: 1375 +--------------------+----------+-----------------------------------+ 1376 | Component/Property | Presence | Comment | 1377 +--------------------+----------+-----------------------------------+ 1378 | METHOD | 1 | MUST be "COUNTER" | 1379 | | | | 1380 | VEVENT | 1 | | 1381 | DTSTAMP | 1 | | 1382 | DTSTART | 1 | | 1383 | ORGANIZER | 1 | MUST be the "Organizer" of the | 1384 | | | original event | 1385 | SEQUENCE | 1 | MUST be present if value is | 1386 | | | greater than 0, MAY be present if | 1387 | | | 0 | 1388 | SUMMARY | 1 | Can be null | 1389 | UID | 1 | MUST be the UID associated with | 1390 | | | the REQUEST being countered | 1391 | ATTACH | 0+ | | 1392 | ATTENDEE | 0+ | Can also be used to propose other | 1393 | | | "Attendees" | 1394 | CATEGORIES | 0+ | | 1395 | CLASS | 0 or 1 | | 1396 | COMMENT | 0+ | | 1397 | CONTACT | 0+ | | 1398 | CREATED | 0 or 1 | | 1399 | DESCRIPTION | 0 or 1 | | 1400 | DTEND | 0 or 1 | if present DURATION MUST NOT be | 1401 | | | present | 1402 | DURATION | 0 or 1 | if present DTEND MUST NOT be | 1403 | | | present | 1404 | EXDATE | 0+ | | 1405 | EXRULE | 0+ | | 1406 | GEO | 0 or 1 | | 1407 | LAST-MODIFIED | 0 or 1 | | 1408 | LOCATION | 0 or 1 | | 1409 | PRIORITY | 0 or 1 | | 1410 | RDATE | 0+ | | 1411 | RECURRENCE-ID | 0 or 1 | MUST only if referring to an | 1412 | | | instance of a recurring calendar | 1413 | | | component. Otherwise it MUST NOT | 1414 | | | be present. | 1415 | RELATED-TO | 0+ | | 1416 | REQUEST-STATUS | 0+ | | 1417 | RESOURCES | 0+ | | 1418 | RRULE | 0+ | | 1419 | STATUS | 0 or 1 | Value must be one of | 1420 | | | CONFIRMED/TENATIVE/ CANCELLED | 1421 | TRANSP | 0 or 1 | | 1422 | URL | 0 or 1 | | 1423 | X-PROPERTY | 0+ | | 1424 | | | | 1425 | VALARM | 0+ | | 1426 | | | | 1427 | VTIMEZONE | 0+ | MUST be present if any date/time | 1428 | | | refers to a timezone | 1429 | | | | 1430 | X-COMPONENT | 0+ | | 1431 | | | | 1432 | VTODO | 0 | | 1433 | | | | 1434 | VJOURNAL | 0 | | 1435 | | | | 1436 | VFREEBUSY | 0 | | 1437 +--------------------+----------+-----------------------------------+ 1439 3.2.8. DECLINECOUNTER 1441 The "DECLINECOUNTER" method in a "VEVENT" calendar component is used 1442 by the "Organizer" of an event to reject a counter proposal submitted 1443 by an "Attendee". The "Organizer" must send the "DECLINECOUNTER" 1444 message to the "Attendee" that sent the "COUNTER" method to the 1445 "Organizer". 1447 This method type is an iCalendar object that conforms to the 1448 following property constraints: 1450 +--------------------+----------+-----------------------------------+ 1451 | Component/Property | Presence | Comment | 1452 +--------------------+----------+-----------------------------------+ 1453 | METHOD | 1 | MUST be "DECLINECOUNTER" | 1454 | | | | 1455 | VEVENT | 1 | | 1456 | DTSTAMP | 1 | | 1457 | ORGANIZER | 1 | | 1458 | UID | 1 | MUST, same UID specified in | 1459 | | | original REQUEST and subsequent | 1460 | | | COUNTER | 1461 | COMMENT | 0+ | | 1462 | RECURRENCE-ID | 0 or 1 | MUST only if referring to an | 1463 | | | instance of a recurring calendar | 1464 | | | component. Otherwise it MUST NOT | 1465 | | | be present. | 1466 | REQUEST-STATUS | 0+ | | 1467 | SEQUENCE | 0 or 1 | MUST be present if value is | 1468 | | | greater than 0, MAY be present if | 1469 | | | 0 | 1470 | X-PROPERTY | 0+ | | 1471 | ATTACH | 0 | | 1472 | ATTENDEE | 0 | | 1473 | CATEGORIES | 0 | | 1474 | CLASS | 0 | | 1475 | CONTACT | 0 | | 1476 | CREATED | 0 | | 1477 | DESCRIPTION | 0 | | 1478 | DTEND | 0 | | 1479 | DTSTART | 0 | | 1480 | DURATION | 0 | | 1481 | EXDATE | 0 | | 1482 | EXRULE | 0 | | 1483 | GEO | 0 | | 1484 | LAST-MODIFIED | 0 | | 1485 | LOCATION | 0 | | 1486 | PRIORITY | 0 | | 1487 | RDATE | 0 | | 1488 | RELATED-TO | 0 | | 1489 | RESOURCES | 0 | | 1490 | RRULE | 0 | | 1491 | STATUS | 0 | | 1492 | SUMMARY | 0 | | 1493 | TRANSP | 0 | | 1494 | URL | 0 | | 1495 | | | | 1496 | X-COMPONENT | 0+ | | 1497 | | | | 1498 | VTODO | 0 | | 1499 | | | | 1500 | VJOURNAL | 0 | | 1501 | | | | 1502 | VFREEBUSY | 0 | | 1503 | | | | 1504 | VTIMEZONE | 0 | | 1505 | | | | 1506 | VALARM | 0 | | 1507 +--------------------+----------+-----------------------------------+ 1509 3.3. Methods For VFREEBUSY Components 1511 This section defines the property set for the methods that are 1512 applicable to the "VFREEBUSY" calendar component. Each of the 1513 methods is defined using a restriction table. 1515 This document only addresses the transfer of busy time information. 1516 Applications desiring free time information MUST infer this from 1517 available busy time information. 1519 The busy time information within the iCalendar object MAY be grouped 1520 into more than one "VFREEBUSY" calendar component. This capability 1521 allows busy time periods to be grouped according to some common 1522 periodicity, such as a calendar week, month, or year. In this case, 1523 each "VFREEBUSY" calendar component MUST include the "ATTENDEE", 1524 "DTSTART" and "DTEND" properties in order to specify the source of 1525 the busy time information and the date and time interval over which 1526 the busy time information covers. 1528 The "FREEBUSY" property value MAY include a list of values, separated 1529 by the COMMA character ([US-ASCII] decimal 44). Alternately, 1530 multiple busy time periods MAY be specified with multiple instances 1531 of the "FREEBUSY" property. Both forms MUST be supported by 1532 implementations conforming to this document. Duplicate busy time 1533 periods SHOULD NOT be specified in an iCalendar object. However, two 1534 different busy time periods MAY overlap. 1536 "FREEBUSY" properties should be sorted such that their values are in 1537 ascending order, based on the start time, and then the end time, with 1538 the earliest periods first. For example, today's busy time 1539 information should appear after yesterday's busy time information. 1540 And the busy time for this half-hour should appear after the busy 1541 time for earlier today. 1543 Since events may span a day boundary, free busy time period may also 1544 span a day boundary. Individual "A" requests busy time from 1545 individuals "B", "C" and "D". Individual "B" and "C" replies with 1546 busy time data to individual "A". Individual "D" does not support 1547 busy time requests and does not reply with any data. If the 1548 transport binding supports exception messages, then individual "D" 1549 returns an "unsupported capability" message to individual "A4.34.3". 1551 The following summarizes the methods that are defined for the 1552 "VFREEBUSY" calendar component. 1554 +---------+-------------------------------------+ 1555 | Method | Description | 1556 +---------+-------------------------------------+ 1557 | PUBLISH | Publish unsolicited busy time data. | 1558 | | | 1559 | REQUEST | Request busy time data. | 1560 | | | 1561 | REPLY | Reply to a busy time request. | 1562 +---------+-------------------------------------+ 1564 3.3.1. PUBLISH 1566 The "PUBLISH" method in a "VFREEBUSY" calendar component is used to 1567 publish busy time data. The method may be sent from one CU to any 1568 other. The purpose of the method is to provide a message for sending 1569 unsolicited busy time data. That is, the busy time data is not being 1570 sent as a "REPLY" to the receipt of a "REQUEST" method. 1572 The "ATTENDEE" property must be specified in the busy time 1573 information. The value is the CU address of the originator of the 1574 busy time information. 1576 This method type is an iCalendar object that conforms to the 1577 following property constraints: 1579 +--------------------+----------+-----------------------------------+ 1580 | Component/Property | Presence | Comment | 1581 +--------------------+----------+-----------------------------------+ 1582 | METHOD | 1 | MUST be "PUBLISH" | 1583 | | | | 1584 | VFREEBUSY | 1+ | | 1585 | DTSTAMP | 1 | | 1586 | DTSTART | 1 | DateTime values must be in UTC | 1587 | DTEND | 1 | DateTime values must be in UTC | 1588 | FREEBUSY | 1+ | MUST be BUSYTIME. Multiple | 1589 | | | instances are allowed. Multiple | 1590 | | | instances must be sorted in | 1591 | | | ascending order | 1592 | ORGANIZER | 1 | MUST contain the address of | 1593 | | | originator of busy time data. | 1594 | UID | 1 | | 1595 | COMMENT | 0+ | | 1596 | CONTACT | 0 or 1 | | 1597 | X-PROPERTY | 0+ | | 1598 | URL | 0 or 1 | Specifies busy time URL | 1599 | ATTENDEE | 0 | | 1600 | DURATION | 0 | | 1601 | REQUEST-STATUS | 0 | | 1602 | | | | 1603 | X-COMPONENT | 0+ | | 1604 | | | | 1605 | VEVENT | 0 | | 1606 | | | | 1607 | VTODO | 0 | | 1608 | | | | 1609 | VJOURNAL | 0 | | 1610 | | | | 1611 | VTIMEZONE | 0 | | 1612 | | | | 1613 | VALARM | 0 | | 1614 +--------------------+----------+-----------------------------------+ 1616 3.3.2. REQUEST 1618 The "REQUEST" method in a "VFREEBUSY" calendar component is used to 1619 ask a "Calendar User" for their busy time information. The request 1620 may be for a busy time information bounded by a specific date and 1621 time interval. 1623 This message only permits requests for busy time information. The 1624 message is sent from a "Calendar User" requesting the busy time 1625 information to one or more intended recipients. 1627 If the originator of the "REQUEST" method is not authorized to make a 1628 busy time request on the recipient's calendar system, then an 1629 exception message SHOULD be returned in a "REPLY" method, but no busy 1630 time data need be returned. 1632 This method type is an iCalendar object that conforms to the 1633 following property constraints: 1635 +--------------------+----------+-----------------------------------+ 1636 | Component/Property | Presence | Comment | 1637 +--------------------+----------+-----------------------------------+ 1638 | METHOD | 1 | MUST be "REQUEST" | 1639 | | | | 1640 | VFREEBUSY | 1 | | 1641 | ATTENDEE | 1+ | contain the address of the | 1642 | | | calendar store | 1643 | DTEND | 1 | DateTime values must be in UTC | 1644 | DTSTAMP | 1 | | 1645 | DTSTART | 1 | DateTime values must be in UTC | 1646 | ORGANIZER | 1 | MUST be the request originator's | 1647 | | | address | 1648 | UID | 1 | | 1649 | COMMENT | 0+ | | 1650 | CONTACT | 0 or 1 | | 1651 | X-PROPERTY | 0+ | | 1652 | FREEBUSY | 0 | | 1653 | DURATION | 0 | | 1654 | REQUEST-STATUS | 0 | | 1655 | URL | 0 | | 1656 | | | | 1657 | X-COMPONENT | 0+ | | 1658 | | | | 1659 | VALARM | 0 | | 1660 | | | | 1661 | VEVENT | 0 | | 1662 | | | | 1663 | VTODO | 0 | | 1664 | | | | 1665 | VJOURNAL | 0 | | 1666 | | | | 1667 | VTIMEZONE | 0 | | 1668 +--------------------+----------+-----------------------------------+ 1670 3.3.3. REPLY 1672 The "REPLY" method in a "VFREEBUSY" calendar component is used to 1673 respond to a busy time request. The method is sent by the recipient 1674 of a busy time request to the originator of the request. 1676 The "REPLY" method may also be used to respond to an unsuccessful 1677 "REQUEST" method. Depending on the "REQUEST-STATUS" value, no busy 1678 time information may be returned. 1680 This method type is an iCalendar object that conforms to the 1681 following property constraints: 1683 +--------------------+----------+-----------------------------------+ 1684 | Component/Property | Presence | Comment | 1685 +--------------------+----------+-----------------------------------+ 1686 | METHOD | 1 | MUST be "REPLY" | 1687 | | | | 1688 | VFREEBUSY | 1 | | 1689 | ATTENDEE | 1 | (address of recipient replying) | 1690 | DTSTAMP | 1 | | 1691 | DTEND | 1 | DateTime values must be in UTC | 1692 | DTSTART | 1 | DateTime values must be in UTC | 1693 | FREEBUSY | 1+ | (values MUST all be of the same | 1694 | | | data type. Multiple instances | 1695 | | | are allowed. Multiple instances | 1696 | | | MUST be sorted in ascending | 1697 | | | order. Values MAY NOT overlap) | 1698 | ORGANIZER | 1 | MUST be the request originator's | 1699 | | | address | 1700 | UID | 1 | | 1701 | COMMENT | 0+ | | 1702 | CONTACT | 0 or 1 | | 1703 | REQUEST-STATUS | 0+ | | 1704 | URL | 0 or 1 | (specifies busy time URL) | 1705 | X-PROPERTY | 0+ | | 1706 | DURATION | 0 | | 1707 | SEQUENCE | 0 | | 1708 | | | | 1709 | X-COMPONENT | 0+ | | 1710 | | | | 1711 | VALARM | 0 | | 1712 | | | | 1713 | VEVENT | 0 | | 1714 | | | | 1715 | VTODO | 0 | | 1716 | | | | 1717 | VJOURNAL | 0 | | 1718 | | | | 1719 | VTIMEZONE | 0 | | 1720 +--------------------+----------+-----------------------------------+ 1722 3.4. Methods For VTODO Components 1724 This section defines the property set for the methods that are 1725 applicable to the "VTODO" calendar component. Each of the methods is 1726 defined using a restriction table that specifies the property 1727 constraints that define the particular method. 1729 The following summarizes the methods that are defined for the "VTODO" 1730 calendar component. 1732 +----------------+--------------------------------------------------+ 1733 | Method | Description | 1734 +----------------+--------------------------------------------------+ 1735 | PUBLISH | Post notification of a VTODO. Used primarily as | 1736 | | a method of advertising the existence of a | 1737 | | VTODO. | 1738 | | | 1739 | REQUEST | Assign a VTODO. This is an explicit assignment | 1740 | | to one or more Calendar Users. The REQUEST | 1741 | | method is also used to update or change an | 1742 | | existing VTODO. Clients that cannot handle | 1743 | | REQUEST MAY degrade the method to treat it as a | 1744 | | PUBLISH. | 1745 | | | 1746 | REPLY | Reply to a VTODO request. Attendees MAY set | 1747 | | PARTSTAT to ACCEPTED, DECLINED, TENTATIVE, | 1748 | | DELEGATED, PARTIAL, and COMPLETED. | 1749 | | | 1750 | ADD | Add one or more instances to an existing to-do. | 1751 | | | 1752 | CANCEL | Cancel one or more instances of an existing | 1753 | | to-do. | 1754 | | | 1755 | REFRESH | A request sent to a VTODO Organizer asking for | 1756 | | the latest version of a VTODO. | 1757 | | | 1758 | COUNTER | Counter a REQUEST with an alternative proposal. | 1759 | | | 1760 | DECLINECOUNTER | Decline a counter proposal by an Attendee. | 1761 +----------------+--------------------------------------------------+ 1763 3.4.1. PUBLISH 1765 The "PUBLISH" method in a "VTODO" calendar component has no 1766 associated response. It is simply a posting of an iCalendar object 1767 that maybe added to a calendar. It MUST have an "Organizer". It 1768 MUST NOT have "Attendees". Its expected usage is for encapsulating 1769 an arbitrary "VTODO" calendar component as an iCalendar object. The 1770 "Organizer" MAY subsequently update (with another "PUBLISH" method), 1771 add instances to (with an "ADD" method), or cancel (with a "CANCEL" 1772 method) a previously published "VTODO" calendar component. 1774 This method type is an iCalendar object that conforms to the 1775 following property constraints: 1777 +--------------------+----------+-----------------------------------+ 1778 | Component/Property | Presence | Comment | 1779 +--------------------+----------+-----------------------------------+ 1780 | METHOD | 1 | | 1781 | | | MUST be "PUBLISH" | 1782 | VTODO | 1+ | | 1783 | DTSTAMP | 1 | | 1784 | DTSTART | 1 | | 1785 | ORGANIZER | 1 | | 1786 | PRIORITY | 1 | | 1787 | SEQUENCE | 0 or 1 | MUST be present if value is | 1788 | | | greater than 0, MAY be present if | 1789 | | | 0 | 1790 | SUMMARY | 1 | Can be null. | 1791 | UID | 1 | | 1792 | ATTACH | 0+ | | 1793 | CATEGORIES | 0+ | | 1794 | CLASS | 0 or 1 | | 1795 | COMMENT | 0+ | | 1796 | COMPLETED | 0 or 1 | | 1797 | CONTACT | 0+ | | 1798 | CREATED | 0 or 1 | | 1799 | DESCRIPTION | 0 or 1 | Can be null | 1800 | DUE | 0 or 1 | If present DURATION MUST NOT be | 1801 | | | present | 1802 | DURATION | 0 or 1 | If present DUE MUST NOT be | 1803 | | | present | 1804 | EXDATE | 0+ | | 1805 | EXRULE | 0+ | | 1806 | GEO | 0 or 1 | | 1807 | LAST-MODIFIED | 0 or 1 | | 1808 | LOCATION | 0 or 1 | | 1809 | PERCENT-COMPLETE | 0 or 1 | | 1810 | RDATE | 0+ | | 1811 | RECURRENCE-ID | 0 or 1 | MUST only if referring to an | 1812 | | | instance of a recurring calendar | 1813 | | | component. Otherwise it MUST NOT | 1814 | | | be present. | 1815 | RELATED-TO | 0+ | | 1816 | RESOURCES | 0+ | | 1817 | RRULE | 0+ | | 1818 | STATUS | 0 or 1 | MAY be one of COMPLETED/NEEDS | 1819 | | | ACTION/IN- PROCESS/CANCELLED | 1820 | URL | 0 or 1 | | 1821 | X-PROPERTY | 0+ | | 1822 | ATTENDEE | 0 | | 1823 | REQUEST-STATUS | 0 | | 1824 | | | | 1825 | VTIMEZONE | 0+ | MUST be present if any date/time | 1826 | | | refers to a timezone | 1827 | | | | 1828 | VALARM | 0+ | | 1829 | | | | 1830 | X-COMPONENT | 0+ | | 1831 | | | | 1832 | VFREEBUSY | 0 | | 1833 | | | | 1834 | VEVENT | 0 | | 1835 | | | | 1836 | VJOURNAL | 0 | | 1837 +--------------------+----------+-----------------------------------+ 1839 3.4.2. REQUEST 1841 The "REQUEST" method in a "VTODO" calendar component provides the 1842 following scheduling functions: 1844 o Assign a to-do to one or more "Calendar Users" 1845 o Reschedule an existing to-do 1846 o Update the details of an existing to-do, without rescheduling it 1847 o Update the completion status of "Attendees" of an existing to-do, 1848 without rescheduling it 1849 o Reconfirm an existing to-do, without rescheduling it 1850 o Delegate/reassign an existing to-do to another "Calendar User" 1852 The assigned "Calendar Users" are identified in the "VTODO" calendar 1853 component by individual "ATTENDEE;ROLE=REQ-PARTICIPANT" property 1854 value sequences. 1856 The originator of a "REQUEST" is the "Organizer" of the to-do. The 1857 recipient of a "REQUEST" is the "Calendar User" assigned the to-do. 1858 The "Attendee" uses the "REPLY" method to convey their acceptance and 1859 completion status to the "Organizer" of the "REQUEST". 1861 The "UID", "SEQUENCE", and "DTSTAMP" properties are used to 1862 distinguish the various uses of the "REQUEST" method. If the "UID" 1863 property value in the "REQUEST" is not found on the recipient's 1864 calendar, then the "REQUEST" is for a new to-do. If the "UID" 1865 property value is found on the recipient's calendar, then the 1866 "REQUEST" is a rescheduling, an update, or a reconfirm of the "VTODO" 1867 calendar object. 1869 If the "Organizer" of the "REQUEST" method is not authorized to make 1870 a to-do request on the "Attendee's" calendar system, then an 1871 exception is returned in the "REQUEST-STATUS" property of a 1872 subsequent "REPLY" method, but no scheduling action is performed. 1874 For the "REQUEST" method, multiple "VTODO" components in a single 1875 iCalendar object are only permitted when for components with the same 1876 "UID" property. That is, a series of recurring events may have 1877 instance-specific information. In this case, multiple "VTODO" 1878 components are needed to express the entire series. 1880 This method type is an iCalendar object that conforms to the 1881 following property constraints: 1883 +--------------------+----------+-----------------------------------+ 1884 | Component/Property | Presence | Comment | 1885 +--------------------+----------+-----------------------------------+ 1886 | METHOD | 1 | MUST be "REQUEST" | 1887 | | | | 1888 | VTODO | 1+ | All components must have the same | 1889 | | | UID | 1890 | ATTENDEE | 1+ | | 1891 | DTSTAMP | 1 | | 1892 | DTSTART | 1 | | 1893 | ORGANIZER | 1 | | 1894 | PRIORITY | 1 | | 1895 | SEQUENCE | 0 or 1 | MUST be present if value is | 1896 | | | greater than 0, MAY be present if | 1897 | | | 0 | 1898 | SUMMARY | 1 | Can be null | 1899 | UID | 1 | | 1900 | ATTACH | 0+ | | 1901 | CATEGORIES | 0+ | | 1902 | CLASS | 0 or 1 | | 1903 | COMMENT | 0+ | | 1904 | COMPLETED | 0 or 1 | | 1905 | CONTACT | 0+ | | 1906 | CREATED | 0 or 1 | | 1907 | DESCRIPTION | 0 or 1 | Can be null | 1908 | DUE | 0 or 1 | If present DURATION MUST NOT be | 1909 | | | present | 1910 | DURATION | 0 or 1 | If present DUE MUST NOT be | 1911 | | | present | 1912 | EXDATE | 0+ | | 1913 | EXRULE | 0+ | | 1914 | GEO | 0 or 1 | | 1915 | LAST-MODIFIED | 0 or 1 | | 1916 | LOCATION | 0 or 1 | | 1917 | PERCENT-COMPLETE | 0 or 1 | | 1918 | RDATE | 0+ | | 1919 | RECURRENCE-ID | 0 or 1 | present if referring to an | 1920 | | | instance of a recurring calendar | 1921 | | | component. Otherwise it MUST NOT | 1922 | | | be present. | 1923 | RELATED-TO | 0+ | | 1924 | RESOURCES | 0+ | | 1925 | RRULE | 0+ | | 1926 | STATUS | 0 or 1 | MAY be one of COMPLETED/NEEDS | 1927 | | | ACTION/IN- PROCESS | 1928 | URL | 0 or 1 | | 1929 | X-PROPERTY | 0+ | | 1930 | REQUEST-STATUS | 0 | | 1931 | | | | 1932 | VALARM | 0+ | | 1933 | | | | 1934 | VTIMEZONE | 0+ | MUST be present if any date/time | 1935 | | | refers to a timezone | 1936 | | | | 1937 | X-COMPONENT | 0+ | | 1938 | | | | 1939 | VEVENT | 0 | | 1940 | | | | 1941 | VFREEBUSY | 0 | | 1942 | | | | 1943 | VJOURNAL | 0 | | 1944 +--------------------+----------+-----------------------------------+ 1946 3.4.2.1. REQUEST for Rescheduling a VTODO 1948 The "REQUEST" method may be used to reschedule a "VTODO" calendar 1949 component. 1951 Rescheduling a "VTODO" calendar component involves a change to the 1952 existing "VTODO" calendar component in terms of its start or due time 1953 or recurrence intervals and possibly the description. If the 1954 recipient CUA of a "REQUEST" method finds that the "UID" property 1955 value already exists on the calendar, but that the "SEQUENCE" 1956 property value in the "REQUEST" is greater than the value for the 1957 existing VTODO, then the "REQUEST" method describes a rescheduling of 1958 the "VTODO" calendar component. 1960 3.4.2.2. REQUEST for Update or Reconfirmation of a VTODO 1962 The "REQUEST" method may be used to update or reconfirm a "VTODO" 1963 calendar component. Reconfirmation is merely an update of "Attendee" 1964 completion status or overall "VTODO" calendar component status. 1966 An update to an existing "VTODO" calendar component does not involve 1967 changes to the start or due time or recurrence intervals, nor 1968 generally to the description for the "VTODO" calendar component. If 1969 the recipient CUA of a "REQUEST" method finds that the "UID" property 1970 value already exists on the calendar and that the "SEQUENCE" property 1971 value in the "REQUEST" is the same as the value for the existing 1972 event, then the "REQUEST" method describes an update of the "VTODO" 1973 calendar component details, but not a rescheduling of the "VTODO" 1974 calendar component. 1976 The update "REQUEST" is the appropriate response to a "REFRESH" 1977 method sent from an "Attendee" to the "Organizer" of a "VTODO" 1978 calendar component. 1980 Unsolicited "REQUEST" methods MAY be sent by the "Organizer" of a 1981 "VTODO" calendar component. The unsolicited "REQUEST" methods are 1982 used to update the details of the "VTODO" (without rescheduling it or 1983 updating the completion status of "Attendees") or the "VTODO" 1984 calendar component itself (i.e., reconfirm the "VTODO"). 1986 3.4.2.3. REQUEST for Delegating a VTODO 1988 The "REQUEST" method is also used to delegate or reassign ownership 1989 of a "VTODO" calendar component to another "Calendar User". For 1990 example, it may be used to delegate an "Attendee's" role (i.e. 1991 "chair", or "participant") for a "VTODO" calendar component. The 1992 "REQUEST" method is sent by one of the "Attendees" of an existing 1993 "VTODO" calendar component to some other individual. An "Attendee" 1994 of a "VTODO" calendar component MUST NOT delegate to the "Organizer" 1995 of the event. 1997 For the purposes of this description, the "Attendee" delegating the 1998 "VTODO" calendar component is referred to as the "Delegator". The 1999 "Attendee" receiving the delegation request is referred to as the 2000 "Delegate". 2002 The "Delegator" of a "VTODO" calendar component MUST forward the 2003 existing "REQUEST" method for a "VTODO" calendar component to the 2004 "Delegate". The "VTODO" calendar component description MUST include 2005 the "Delegator's" up-to-date "VTODO" calendar component definition. 2006 The "REQUEST" method MUST also include an "ATTENDEE" property with 2007 the calendar address of the "Delegate". The "Delegator" MUST also 2008 send a "REPLY" method back to the "Organizer" with the "Delegator's" 2009 "Attendee" property "partstat" parameter value set to "DELEGATED". 2010 In addition, the "delegated-to" parameter MUST be included with the 2011 calendar address of the "Delegate". A response to the delegation 2012 "REQUEST" is sent from the "Delegate" to the "Organizer" and 2013 optionally, to the "Delegator". The "REPLY" method from the 2014 "Delegate" SHOULD include the "ATTENDEE" property with their calendar 2015 address and the "delegated-from" parameter with the value of the 2016 "Delegator's" calendar address. 2018 The delegation "REQUEST" method MUST assign a value for the "RSVP" 2019 property parameter associated with the "Delegator's" "Attendee" 2020 property to that of the "Delegate's" "ATTENDEE" property. For 2021 example if the "Delegator's" "ATTENDEE" property specifies 2022 "RSVP=TRUE", then the "Delegate's" "ATTENDEE" property MUST specify 2023 "RSVP=TRUE". 2025 3.4.2.4. REQUEST Forwarded To An Uninvited Calendar User 2027 An "Attendee" assigned a "VTODO" calendar component may send the 2028 "VTODO" calendar component to another new CU, not previously 2029 associated with the "VTODO" calendar component. The current 2030 "Attendee" assigned the "VTODO" calendar component does this by 2031 forwarding the original "REQUEST" method to the new CU. The new CU 2032 can send a "REPLY" to the "Organizer" of the "VTODO" calendar 2033 component. The reply contains an "ATTENDEE" property for the new CU. 2035 The "Organizer" ultimately decides whether or not the new CU becomes 2036 part of the to-do and is not obligated to do anything with a "REPLY" 2037 from a new (uninvited) CU. If the "Organizer" does not want the new 2038 CU to be part of the to-do, the new "ATTENDEE" property is not added 2039 to the "VTODO" calendar component. The "Organizer" MAY send the CU a 2040 "CANCEL" message to indicate that they will not be added to the to- 2041 do. If the "Organizer" decides to add the new CU, the new "ATTENDEE" 2042 property is added to the "VTODO" calendar component. Furthermore, 2043 the "Organizer" is free to change any "ATTENDEE" property parameter 2044 from the values supplied by the new CU to something the "Organizer" 2045 considers appropriate. 2047 3.4.2.5. REQUEST Updated Attendee Status 2049 An "Organizer" of a "VTODO" may request an updated status from one or 2050 more "Attendees". The "Organizer" sends a "REQUEST" method to the 2051 "Attendee" with the "ATTENDEE;RSVP=TRUE" property sequence. The 2052 "SEQUENCE" property for the "VTODO" is not changed from its previous 2053 value. A recipient determines that the only change in the "REQUEST" 2054 is that their "RSVP" property parameter indicates a request for an 2055 updated status. The recipient SHOULD respond with a "REPLY" method 2056 indicating their current status with respect to the "REQUEST". 2058 3.4.3. REPLY 2060 The "REPLY" method in a "VTODO" calendar component is used to respond 2061 (e.g., accept or decline) to a request or to reply to a delegation 2062 request. It is also used by an "Attendee" to update their completion 2063 status. When used to provide a delegation response, the "Delegator" 2064 MUST include the calendar address of the "Delegate" in the 2065 "delegated-to" parameter of the "Delegator's" "ATTENDEE" property. 2066 The "Delegate" MUST include the calendar address of the "Delegator" 2067 on the "delegated-from" parameter of the "Delegate's" "ATTENDEE" 2068 property. 2070 The "REPLY" method MAY also be used to respond to an unsuccessful 2071 "VTODO" calendar component "REQUEST" method. Depending on the 2072 "REQUEST-STATUS" value, no scheduling action may have been performed. 2074 The "Organizer" of a "VTODO" calendar component MAY receive a "REPLY" 2075 method from a "Calendar User" not in the original "REQUEST". For 2076 example, a "REPLY" method MAY be received from a "Delegate" of a 2077 "VTODO" calendar component. In addition, the "REPLY" method MAY be 2078 received from an unknown "Calendar User", having been forwarded the 2079 "REQUEST" by an original "Attendee" of the "VTODO" calendar 2080 component. This uninvited "Attendee" MAY be accepted, or the 2081 "Organizer" MAY cancel the "VTODO" calendar component for the 2082 uninvited "Attendee" by sending them a "CANCEL" method. 2084 This method type is an iCalendar object that conforms to the 2085 following property constraints: 2087 +--------------------+----------+-----------------------------------+ 2088 | Component/Property | Presence | Comment | 2089 +--------------------+----------+-----------------------------------+ 2090 | METHOD | 1 | MUST be "REPLY" | 2091 | | | | 2092 | VTODO | 1+ | All component MUST have the same | 2093 | | | UID | 2094 | ATTENDEE | 1+ | | 2095 | DTSTAMP | 1 | | 2096 | ORGANIZER | 1 | | 2097 | REQUEST-STATUS | 1+ | | 2098 | UID | 1 | MUST must be the address of the | 2099 | | | replying attendee | 2100 | ATTACH | 0+ | | 2101 | CATEGORIES | 0+ | | 2102 | CLASS | 0 or 1 | | 2103 | COMMENT | 0+ | | 2104 | COMPLETED | 0 or 1 | | 2105 | CONTACT | 0+ | | 2106 | CREATED | 0 or 1 | | 2107 | DESCRIPTION | 0 or 1 | | 2108 | DTSTART | 0 or 1 | | 2109 | DUE | 0 or 1 | If present DURATION MUST NOT be | 2110 | | | present | 2111 | DURATION | 0 or 1 | If present DUE MUST NOT be | 2112 | | | present | 2113 | EXDATE | 0+ | | 2114 | EXRULE | 0+ | | 2115 | GEO | 0 or 1 | | 2116 | LAST-MODIFIED | 0 or 1 | | 2117 | LOCATION | 0 or 1 | | 2118 | PERCENT-COMPLETE | 0 or 1 | | 2119 | PRIORITY | 0 or 1 | | 2120 | RDATE | 0+ | | 2121 | RELATED-TO | 0+ | | 2122 | RESOURCES | 0+ | | 2123 | RRULE | 0+ | | 2124 | RECURRENCE-ID | 0 or 1 | MUST only if referring to an | 2125 | | | instance of a Recurring calendar | 2126 | | | component. Otherwise it MUST NOT | 2127 | | | be present | 2128 | SEQUENCE | 0 or 1 | MUST be the sequence number of | 2129 | | | the original REQUEST if greater | 2130 | | | than 0. MAY be present if 0. | 2131 | STATUS | 0 or 1 | | 2132 | SUMMARY | 0 or 1 | Can be null | 2133 | URL | 0 or 1 | | 2134 | X-PROPERTY | 0+ | | 2135 | | | | 2136 | VTIMEZONE | 0 or 1 | MUST be present if any date/time | 2137 | | | refers to a timezone | 2138 | | | | 2139 | X-COMPONENT | 0+ | | 2140 | | | | 2141 | VALARM | 0 | | 2142 | | | | 2143 | VEVENT | 0 | | 2144 | | | | 2145 | VFREEBUSY | 0 | | 2146 +--------------------+----------+-----------------------------------+ 2148 3.4.4. ADD 2150 The "ADD" method in a "VTODO" calendar component is used to add one 2151 or more instances to an existing to-do. 2153 If the "UID" property value in the "ADD" is not found on the 2154 recipient's calendar, then the recipient SHOULD send a "REFRESH" to 2155 the "Organizer" in order to be updated with the latest version of the 2156 "VTODO". If an "Attendee" implementation does not support the "ADD" 2157 method it should respond with a "REQUEST-STATUS" value of 5.3 and ask 2158 for a "REFRESH". 2160 The "SEQUENCE" property value is incremented as the sequence of to- 2161 dos has changed. 2163 This method type is an iCalendar object that conforms to the 2164 following property constraints: 2166 +--------------------+----------+-----------------------------------+ 2167 | Component/Property | Presence | Comment | 2168 +--------------------+----------+-----------------------------------+ 2169 | METHOD | 1 | MUST be "ADD" | 2170 | | | | 2171 | VTODO | 1 | | 2172 | DTSTAMP | 1 | | 2173 | ORGANIZER | 1 | | 2174 | PRIORITY | 1 | | 2175 | SEQUENCE | 1 | MUST be greater than 0 | 2176 | SUMMARY | 1 | Can be null | 2177 | UID | 1 | MUST match that of the original | 2178 | | | to-do | 2179 | ATTACH | 0+ | | 2180 | ATTENDEE | 0+ | | 2181 | CATEGORIES | 0+ | | 2182 | CLASS | 0 or 1 | | 2183 | COMMENT | 0+ | | 2184 | COMPLETED | 0 or 1 | | 2185 | CONTACT | 0+ | | 2186 | CREATED | 0 or 1 | | 2187 | DESCRIPTION | 0 or 1 | Can be null | 2188 | DTSTART | 0 or 1 | | 2189 | DUE | 0 or 1 | If present DURATION MUST NOT be | 2190 | | | present | 2191 | DURATION | 0 or 1 | If present DUE MUST NOT be | 2192 | | | present | 2193 | EXDATE | 0+ | | 2194 | EXRULE | 0+ | | 2195 | GEO | 0 or 1 | | 2196 | LAST-MODIFIED | 0 or 1 | | 2197 | LOCATION | 0 or 1 | | 2198 | PERCENT-COMPLETE | 0 or 1 | | 2199 | RDATE | 0+ | | 2200 | RELATED-TO | 0+ | | 2201 | RESOURCES | 0+ | | 2202 | RRULE | 0+ | | 2203 | STATUS | 0 or 1 | MAY be one of COMPLETED/NEEDS | 2204 | | | ACTION/IN- PROCESS | 2205 | URL | 0 or 1 | | 2206 | X-PROPERTY | 0+ | | 2207 | RECURRENCE-ID | 0 | | 2208 | REQUEST-STATUS | 0 | | 2209 | | | | 2210 | VALARM | 0+ | | 2211 | | | | 2212 | VTIMEZONE | 0+ | MUST be present if any date/time | 2213 | | | refers to a timezone | 2214 | | | | 2215 | X-COMPONENT | 0+ | | 2216 | | | | 2217 | VEVENT | 0 | | 2218 | | | | 2219 | VJOURNAL | 0 | | 2220 | | | | 2221 | VFREEBUSY | 0 | | 2222 +--------------------+----------+-----------------------------------+ 2224 3.4.5. CANCEL 2226 The "CANCEL" method in a "VTODO" calendar component is used to send a 2227 cancellation notice of an existing "VTODO" calendar request to the 2228 "Attendees". The message is sent by the "Organizer" of a "VTODO" 2229 calendar component to the "Attendees" of the "VTODO" calendar 2230 component. For a recurring "VTODO" calendar component, either the 2231 whole "VTODO" calendar component or instances of a "VTODO" calendar 2232 component may be cancelled. To cancel the complete range of a 2233 recurring "VTODO" calendar component, the "UID" property value for 2234 the "VTODO" calendar component MUST be specified and a "RECURRENCE- 2235 ID" MUST NOT be specified in the "CANCEL" method. In order to cancel 2236 an individual instance of a recurring "VTODO" calendar component, the 2237 "RECURRENCE-ID" property value for the "VTODO" calendar component 2238 MUST be specified in the "CANCEL" method. 2240 There are two options for canceling a sequence of instances of a 2241 recurring "VTODO" calendar component: 2243 a. the "RECURRENCE-ID" property for an instance in the sequence MUST 2244 be specified with the "RANGE" property parameter value of 2245 THISANDPRIOR (or THISANDFUTURE) to indicate cancellation of the 2246 specified "VTODO" calendar component and all instances before (or 2247 after) 2249 b. individual recurrence instances may be cancelled by specifying 2250 multiple "RECURRENCE-ID" properties corresponding to the 2251 instances to be cancelled 2253 When a "VTODO" is cancelled, the "SEQUENCE" property value MUST be 2254 incremented. 2256 This method type is an iCalendar object that conforms to the 2257 following property constraints: 2259 +--------------------+----------+-----------------------------------+ 2260 | Component/Property | Presence | Comment | 2261 +--------------------+----------+-----------------------------------+ 2262 | METHOD | 1 | MUST be "CANCEL" | 2263 | | | | 2264 | VTODO | 1 | | 2265 | ATTENDEE | 0+ | include all "Attendees" being | 2266 | | | removed from the todo. MUST | 2267 | | | include all "Attendees" if the | 2268 | | | entire todo is cancelled. | 2269 | UID | 1 | MUST echo original UID | 2270 | DTSTAMP | 1 | | 2271 | ORGANIZER | 1 | | 2272 | SEQUENCE | 1 | | 2273 | ATTACH | 0+ | | 2274 | CATEGORIES | 0+ | | 2275 | CLASS | 0 or 1 | | 2276 | COMMENT | 0+ | | 2277 | COMPLETED | 0 or 1 | | 2278 | CONTACT | 0+ | | 2279 | CREATED | 0 or 1 | | 2280 | DESCRIPTION | 0 or 1 | | 2281 | DTSTART | 0 or 1 | | 2282 | DUE | 0 or 1 | If present DURATION MUST NOT be | 2283 | | | present | 2284 | DURATION | 0 or 1 | If present DUE MUST NOT be | 2285 | | | present | 2286 | EXDATE | 0+ | | 2287 | EXRULE | 0+ | | 2288 | GEO | 0 or 1 | | 2289 | LAST-MODIFIED | 0 or 1 | | 2290 | LOCATION | 0 or 1 | | 2291 | PERCENT-COMPLETE | 0 or 1 | | 2292 | RDATE | 0+ | | 2293 | RECURRENCE-ID | 0 or 1 | MUST only if referring to one or | 2294 | | | more instances of a recurring | 2295 | | | calendar component. Otherwise it | 2296 | | | MUST NOT be present. | 2297 | RELATED-TO | 0+ | | 2298 | RESOURCES | 0+ | | 2299 | RRULE | 0+ | | 2300 | PRIORITY | 0 or 1 | | 2301 | STATUS | 0 or 1 | If present it MUST be set to | 2302 | | | "CANCELLED". MUST NOT be used if | 2303 | | | purpose is to remove "ATTENDEES" | 2304 | | | rather than cancel the entire | 2305 | | | VTODO. | 2306 | URL | 0 or 1 | | 2307 | X-PROPERTY | 0+ | | 2308 | REQUEST-STATUS | 0 | | 2309 | | | | 2310 | VTIMEZONE | 0 or 1 | MUST be present if any date/time | 2311 | | | refers to a timezone | 2312 | | | | 2313 | X-COMPONENT | 0+ | | 2314 | | | | 2315 | VALARM | 0 | | 2316 | | | | 2317 | VEVENT | 0 | | 2318 | | | | 2319 | VFREEBUSY | 0 | | 2320 +--------------------+----------+-----------------------------------+ 2322 3.4.6. REFRESH 2324 The "REFRESH" method in a "VTODO" calendar component is used by 2325 "Attendees" of an existing "VTODO" calendar component to request an 2326 updated description from the "Organizer" of the "VTODO" calendar 2327 component. The "Organizer" of the "VTODO" calendar component MAY use 2328 this method to request an updated status from the "Attendees". The 2329 "REFRESH" method MUST specify the "UID" property corresponding to the 2330 "VTODO" calendar component needing update. 2332 A refresh of a recurrence instance of a "VTODO" calendar component 2333 may be requested by specifying the "RECURRENCE-ID" property 2334 corresponding to the associated "VTODO" calendar component. The 2335 "Organizer" responds with the latest description and rendition of the 2336 "VTODO" calendar component. In most cases this will be a REQUEST 2337 unless the "VTODO" has been cancelled, in which case the ORGANIZER 2338 MUST send a "CANCEL". This method is intended to facilitate machine 2339 processing of requests for updates to a "VTODO" calendar component. 2341 This method type is an iCalendar object that conforms to the 2342 following property constraints: 2344 +--------------------+----------+-----------------------------------+ 2345 | Component/Property | Presence | Comment | 2346 +--------------------+----------+-----------------------------------+ 2347 | METHOD | 1 | MUST be "REFRESH" | 2348 | | | | 2349 | VTODO | 1 | | 2350 | ATTENDEE | 1 | | 2351 | DTSTAMP | 1 | | 2352 | UID | 1 | MUST echo original UID | 2353 | RECURRENCE-ID | 0 or 1 | MUST only if referring to an | 2354 | | | instance of a Recurring calendar | 2355 | | | component. Otherwise it MUST NOT | 2356 | | | be present | 2357 | X-PROPERTY | 0+ | | 2358 | ATTACH | 0 | | 2359 | CATEGORIES | 0 | | 2360 | CLASS | 0 | | 2361 | COMMENT | 0 | | 2362 | COMPLETED | 0 | | 2363 | CONTACT | 0 | | 2364 | CREATED | 0 | | 2365 | DESCRIPTION | 0 | | 2366 | DTSTART | 0 | | 2367 | DUE | 0 | | 2368 | DURATION | 0 | | 2369 | EXDATE | 0 | | 2370 | EXRULE | 0 | | 2371 | GEO | 0 | | 2372 | LAST-MODIFIED | 0 | | 2373 | LOCATION | 0 | | 2374 | ORGANIZER | 0 | | 2375 | PERCENT-COMPLETE | 0 | | 2376 | PRIORITY | 0 | | 2377 | RDATE | 0 | | 2378 | RELATED-TO | 0 | | 2379 | REQUEST-STATUS | 0 | | 2380 | RESOURCES | 0 | | 2381 | RRULE | 0 | | 2382 | SEQUENCE | 0 | | 2383 | STATUS | 0 | | 2384 | URL | 0 | | 2385 | | | | 2386 | X-COMPONENT | 0+ | | 2387 | | | | 2388 | VALARM | 0 | | 2389 | | | | 2390 | VEVENT | 0 | | 2391 | | | | 2392 | VFREEBUSY | 0 | | 2393 | | | | 2394 | VTIMEZONE | 0 | | 2395 +--------------------+----------+-----------------------------------+ 2397 3.4.7. COUNTER 2399 The "COUNTER" method in a "VTODO" calendar component is used by an 2400 "Attendee" of an existing "VTODO" calendar component to submit to the 2401 "Organizer" a counter proposal for the "VTODO" calendar component. 2402 The "Attendee" sends the message to the "Organizer" of the "VTODO" 2403 calendar component. 2405 The counter proposal is an iCalendar object consisting of a "VTODO" 2406 calendar component describing the complete description of the 2407 alternate "VTODO" calendar component. 2409 The "Organizer" rejects the counter proposal by sending the 2410 "Attendee" a "DECLINECOUNTER" method. The "Organizer" accepts the 2411 counter proposal by sending all of the "Attendees" of the "VTODO" 2412 calendar component a "REQUEST" method rescheduling the "VTODO" 2413 calendar component. In the latter case, the "Organizer" SHOULD reset 2414 the individual "RSVP" property parameter values to TRUE on each 2415 "ATTENDEE" property; in order to force a response by the "Attendees". 2417 This method type is an iCalendar object that conforms to the 2418 following property constraints: 2420 +--------------------+----------+-----------------------------------+ 2421 | Component/Property | Presence | Comment | 2422 +--------------------+----------+-----------------------------------+ 2423 | METHOD | 1 | MUST be "COUNTER" | 2424 | | | | 2425 | VTODO | 1 | | 2426 | ATTENDEE | 1+ | | 2427 | DTSTAMP | 1 | | 2428 | ORGANIZER | 1 | | 2429 | PRIORITY | 1 | | 2430 | SUMMARY | 1 | Can be null | 2431 | UID | 1 | | 2432 | ATTACH | 0+ | | 2433 | CATEGORIES | 0+ | | 2434 | CLASS | 0 or 1 | | 2435 | COMMENT | 0+ | | 2436 | COMPLETED | 0 or 1 | | 2437 | CONTACT | 0+ | | 2438 | CREATED | 0 or 1 | | 2439 | DESCRIPTION | 0 or 1 | Can be null | 2440 | DTSTART | 0 or 1 | | 2441 | DUE | 0 or 1 | If present DURATION MUST NOT be | 2442 | | | present | 2443 | DURATION | 0 or 1 | If present DUE MUST NOT be | 2444 | | | present | 2445 | EXDATE | 0+ | | 2446 | EXRULE | 0+ | | 2447 | GEO | 0 or 1 | | 2448 | LAST-MODIFIED | 0 or 1 | | 2449 | LOCATION | 0 or 1 | | 2450 | PERCENT-COMPLETE | 0 or 1 | | 2451 | RDATE | 0+ | | 2452 | RECURRENCE-ID | 0 or 1 | MUST only 3.5if referring to an | 2453 | | | instance of a recurring calendar | 2454 | | | component. Otherwise it MUST NOT | 2455 | | | be present. | 2456 | RELATED-TO | 0+ | | 2457 | REQUEST-STATUS | 0+ | | 2458 | RESOURCES | 0+ | | 2459 | RRULE | 0 or 1 | | 2460 | SEQUENCE | 0 or 1 | MUST echo the original SEQUENCE | 2461 | | | number. MUST be present if | 2462 | | | non-zero. MAY be present if | 2463 | | | zero. | 2464 | STATUS | 0 or 1 | MAY be one of COMPLETED/NEEDS | 2465 | | | ACTION/IN- PROCESS/CANCELLED | 2466 | URL | 0 or 1 | | 2467 | X-PROPERTY | 0+ | | 2468 | | | | 2469 | VALARM | 0+ | | 2470 | | | | 2471 | VTIMEZONE | 0 or 1 | MUST be present if any date/time | 2472 | | | refers to a timezone | 2473 | | | | 2474 | X-COMPONENT | 0+ | | 2475 | | | | 2476 | VEVENT | 0 | | 2477 | | | | 2478 | VFREEBUSY | 0 | | 2479 +--------------------+----------+-----------------------------------+ 2481 3.4.8. DECLINECOUNTER 2483 The "DECLINECOUNTER" method in a "VTODO" calendar component is used 2484 by an "Organizer" of "VTODO" calendar component to reject a counter 2485 proposal offered by one of the "Attendees". The "Organizer" sends 2486 the message to the "Attendee" that sent the "COUNTER" method to the 2487 "Organizer". 2489 This method type is an iCalendar object that conforms to the 2490 following property constraints: 2492 +--------------------+----------+-----------------------------------+ 2493 | Component/Property | Presence | Comment | 2494 +--------------------+----------+-----------------------------------+ 2495 | METHOD | 1 | MUST be "DECLINECOUNTER" | 2496 | | | | 2497 | VTODO | 1 | | 2498 | ATTENDEE | 1+ | MUST for all attendees | 2499 | DTSTAMP | 1 | | 2500 | ORGANIZER | 1 | | 2501 | SEQUENCE | 1 | MUST echo the original SEQUENCE | 2502 | | | number | 2503 | UID | 1 | MUST echo original UID | 2504 | ATTACH | 0+ | | 2505 | CATEGORIES | 0+ | | 2506 | CLASS | 0 or 1 | | 2507 | COMMENT | 0+ | | 2508 | COMPLETED | 0 or 1 | | 2509 | CONTACT | 0+ | | 2510 | CREATED | 0 or 1 | | 2511 | DESCRIPTION | 0 or 1 | | 2512 | DTSTART | 0 or 1 | | 2513 | DUE | 0 or 1 | If present DURATION MUST NOT be | 2514 | | | present | 2515 | DURATION | 0 or 1 | If present DUE MUST NOT be | 2516 | | | present | 2517 | EXDATE | 0+ | | 2518 | EXRULE | 0+ | | 2519 | GEO | 0 or 1 | | 2520 | LAST-MODIFIED | 0 or 1 | | 2521 | LOCATION | 0 or 1 | | 2522 | PERCENT-COMPLETE | 0 or 1 | | 2523 | PRIORITY | 0 or 1 | | 2524 | RDATE | 0+ | | 2525 | RECURRENCE-ID | 0 or 1 | MUST only if referring to an | 2526 | | | instance of a recurring calendar | 2527 | | | component. Otherwise it MUST NOT | 2528 | | | be present. | 2529 | RELATED-TO | 0+ | | 2530 | REQUEST-STATUS | 0+ | | 2531 | RESOURCES | 0+ | | 2532 | RRULE | 0+ | | 2533 | STATUS | 0 or 1 | MAY be one of COMPLETED/NEEDS | 2534 | | | ACTION/IN- PROCESS | 2535 | URL | 0 or 1 | | 2536 | X-PROPERTY | 0+ | | 2537 | | | | 2538 | VTIMEZONE | 0+ | MUST be present if any date/time | 2539 | | | refers to a timezone | 2540 | | | | 2541 | X-COMPONENT | 0+ | | 2542 | | | | 2543 | VALARM | 0 | | 2544 | | | | 2545 | VEVENT | 0 | | 2546 | | | | 2547 | VFREEBUSY | 0 | | 2548 +--------------------+----------+-----------------------------------+ 2550 3.5. Methods For VJOURNAL Components 2552 This section defines the property set for the methods that are 2553 applicable to the "VJOURNAL" calendar component. 2555 The following summarizes the methods that are defined for the 2556 "VJOURNAL" calendar component. 2558 +---------+---------------------------------------------------------+ 2559 | Method | Description | 2560 +---------+---------------------------------------------------------+ 2561 | PUBLISH | Post a journal entry. Used primarily as a method of | 2562 | | advertising the existence of a journal entry. | 2563 | | | 2564 | ADD | Add one or more instances to an existing journal entry. | 2565 | | | 2566 | CANCEL | Cancel one or more instances of an existing journal | 2567 | | entry. | 2568 +---------+---------------------------------------------------------+ 2570 3.5.1. PUBLISH 2572 The "PUBLISH" method in a "VJOURNAL" calendar component has no 2573 associated response. It is simply a posting of an iCalendar object 2574 that may be added to a calendar. It MUST have an "Organizer". It 2575 MUST NOT have "Attendees". The expected usage is for encapsulating 2576 an arbitrary journal entry as an iCalendar object. The "Organizer" 2577 MAY subsequently update (with another "PUBLISH" method) or cancel 2578 (with a "CANCEL" method) a previously published journal entry. 2580 This method type is an iCalendar object that conforms to the 2581 following property constraints: 2583 +--------------------+----------+-----------------------------------+ 2584 | Component/Property | Presence | Comment | 2585 +--------------------+----------+-----------------------------------+ 2586 | METHOD | 1 | MUST be "PUBLISH" | 2587 | | | | 2588 | VJOURNAL | 1+ | | 2589 | DESCRIPTION | 1 | Can be null. | 2590 | DTSTAMP | 1 | | 2591 | DTSTART | 1 | | 2592 | ORGANIZER | 1 | | 2593 | UID | 1 | | 2594 | ATTACH | 0+ | | 2595 | CATEGORIES | 0+ | | 2596 | CLASS | 0 or 1 | | 2597 | COMMENT | 0+ | | 2598 | CONTACT | 0+ | | 2599 | CREATED | 0 or 1 | | 2600 | EXDATE | 0+ | | 2601 | EXRULE | 0+ | | 2602 | LAST-MODIFIED | 0 or 1 | | 2603 | RDATE | 0+ | | 2604 | RECURRENCE-ID | 0 or 1 | MUST only if referring to an | 2605 | | | instance of a recurring calendar | 2606 | | | component. Otherwise it MUST NOT | 2607 | | | be present. | 2608 | RELATED-TO | 0+ | | 2609 | RRULE | 0+ | | 2610 | SEQUENCE | 0 or 1 | MUST echo the original SEQUENCE | 2611 | | | number. MUST be present if | 2612 | | | non-zero. MAY be present if | 2613 | | | zero. | 2614 | STATUS | 0 or 1 | MAY be one of | 2615 | | | DRAFT/FINAL/CANCELLED | 2616 | SUMMARY | 0 or 1 | Can be null | 2617 | URL | 0 or 1 | | 2618 | X-PROPERTY | 0+ | | 2619 | ATTENDEE | 0 | | 2620 | REQUEST-STATUS | 0 | | 2621 | | | | 2622 | VALARM | 0+ | | 2623 | | | | 2624 | VTIMEZONE | 0+ | MUST be present if any date/time | 2625 | | | refers to a timezone | 2626 | | | | 2627 | X-COMPONENT | 0+ | | 2628 | | | | 2629 | VEVENT | 0 | | 2630 | | | | 2631 | VFREEBUSY | 0 | | 2632 | | | | 2633 | VTODO | 0 | | 2634 +--------------------+----------+-----------------------------------+ 2636 3.5.2. ADD 2638 The "ADD" method in a "VJOURNAL" calendar component is used to add 2639 one or more instances to an existing "VJOURNAL" entry. There is no 2640 response to the "Organizer". 2642 If the "UID" property value in the "ADD" is not found on the 2643 recipient's calendar, then the recipient MAY treat the "ADD" as a 2644 "PUBLISH". 2646 This method type is an iCalendar object that conforms to the 2647 following property constraints: 2649 +--------------------+----------+-----------------------------------+ 2650 | Component/Property | Presence | Comment | 2651 +--------------------+----------+-----------------------------------+ 2652 | METHOD | 1 | MUST be "ADD" | 2653 | | | | 2654 | VJOURNAL | 1 | | 2655 | DESCRIPTION | 1 | Can be null | 2656 | DTSTAMP | 1 | | 2657 | DTSTART | 1 | | 2658 | ORGANIZER | 1 | | 2659 | SEQUENCE | 1 | MUST be greater than 0 | 2660 | UID | 1 | MUST match that of the original | 2661 | | | journal | 2662 | ATTACH | 0+ | | 2663 | CATEGORIES | 0+ | | 2664 | CLASS | 0 or 1 | | 2665 | COMMENT | 0+ | | 2666 | CONTACT | 0+ | | 2667 | CREATED | 0 or 1 | | 2668 | EXDATE | 0+ | | 2669 | EXRULE | 0+ | | 2670 | LAST-MODIFIED | 0 or 1 | | 2671 | RDATE | 0+ | | 2672 | RELATED-TO | 0+ | | 2673 | RRULE | 0+ | | 2674 | STATUS | 0 or 1 | MAY be one of | 2675 | | | DRAFT/FINAL/CANCELLED | 2676 | SUMMARY | 0 or 1 | Can be null | 2677 | URL | 0 or 1 | | 2678 | X-PROPERTY | 0+ | | 2679 | ATTENDEE | 0 | | 2680 | RECURRENCE-ID | 0 | | 2681 | REQUEST-STATUS | 0 | | 2682 | | | | 2683 | VALARM | 0+ | | 2684 | | | | 2685 | VTIMEZONE | 0 or 1 | MUST be present if any date/time | 2686 | | | refers to a timezone | 2687 | | | | 2688 | X-COMPONENT | 0+ | | 2689 | | | | 2690 | VEVENT | 0 | | 2691 | | | | 2692 | VFREEBUSY | 0 | | 2693 | | | | 2694 | VTODO | 0 | | 2695 +--------------------+----------+-----------------------------------+ 2697 3.5.3. CANCEL 2699 The "CANCEL" method in a "VJOURNAL" calendar component is used to 2700 send a cancellation notice of an existing journal entry. The message 2701 is sent by the "Organizer" of a journal entry. For a recurring 2702 journal entry, either the whole journal entry or instances of a 2703 journal entry may be cancelled. To cancel the complete range of a 2704 recurring journal entry, the "UID" property value for the journal 2705 entry MUST be specified and a "RECURRENCE-ID" property MUST NOT be 2706 specified in the "CANCEL" method. In order to cancel an individual 2707 instance of the journal entry, the "RECURRENCE-ID" property value for 2708 the journal entry MUST be specified in the "CANCEL" method. 2710 There are two options for canceling a sequence of instances of a 2711 recurring "VJOURNAL" calendar component: 2713 a. the "RECURRENCE-ID" property for an instance in the sequence MUST 2714 be specified with the "RANGE" property parameter value of 2715 THISANDPRIOR (or THISANDFUTURE) to indicate cancellation of the 2716 specified "VTODO" calendar component and all instances before (or 2717 after) 2719 b. individual recurrence instances may be cancelled by specifying 2720 multiple "RECURRENCE-ID" properties corresponding to the 2721 instances to be cancelled 2723 When a "VJOURNAL" is cancelled, the "SEQUENCE" property value MUST be 2724 incremented. 2726 This method type is an iCalendar object that conforms to the 2727 following property constraints: 2729 +--------------------+----------+-----------------------------------+ 2730 | Component/Property | Presence | Comment | 2731 +--------------------+----------+-----------------------------------+ 2732 | METHOD | 1 | MUST be "CANCEL" | 2733 | | | | 2734 | VJOURNAL | 1+ | All MUST have the same UID | 2735 | DTSTAMP | 1 | | 2736 | ORGANIZER | 1 | | 2737 | SEQUENCE | 1 | | 2738 | UID | 1 | MUST be the UID of the original | 2739 | | | REQUEST | 2740 | ATTACH | 0+ | | 2741 | ATTENDEE | 0+ | | 2742 | CATEGORIES | 0+ | | 2743 | CLASS | 0 or 1 | | 2744 | COMMENT | 0+ | | 2745 | CONTACT | 0+ | | 2746 | CREATED | 0 or 1 | | 2747 | DESCRIPTION | 0 or 1 | | 2748 | DTSTART | 0 or 1 | | 2749 | EXDATE | 0+ | | 2750 | EXRULE | 0+ | | 2751 | LAST-MODIFIED | 0 or 1 | | 2752 | RDATE | 0+ | | 2753 | RECURRENCE-ID | 0 or 1 | only if referring to an instance | 2754 | | | of a recurring calendar | 2755 | | | component. Otherwise it MUST NOT | 2756 | | | be present. | 2757 | RELATED-TO | 0+ | | 2758 | RRULE | 0+ | | 2759 | STATUS | 0 or 1 | MAY be present, must be | 2760 | | | "CANCELLED" if present | 2761 | SUMMARY | 0 or 1 | | 2762 | URL | 0 or 1 | | 2763 | X-PROPERTY | 0+ | | 2764 | REQUEST-STATUS | 0 | | 2765 | | | | 2766 | VTIMEZONE | 0+ | MUST be present if any date/time | 2767 | | | refers to a timezone | 2768 | | | | 2769 | X-COMPONENT | 0+ | | 2770 | | | | 2771 | VALARM | 0 | | 2772 | | | | 2773 | VEVENT | 0 | | 2774 | | | | 2775 | VFREEBUSY | 0 | | 2776 | | | | 2777 | VTODO | 0 | | 2778 +--------------------+----------+-----------------------------------+ 2780 3.6. Status Replies 2782 The "REQUEST-STATUS" property may include the following values: 2784 +---------+------------------------+--------------------------------+ 2785 | Short | Longer Return Status | Offending Data | 2786 | Return | Description | | 2787 | Status | | | 2788 | Code | | | 2789 +---------+------------------------+--------------------------------+ 2790 | 2.0 | Success. | None. | 2791 | | | | 2792 | 2.1 | Success but fallback | Property name and value MAY be | 2793 | | taken on one or more | specified. | 2794 | | property values. | | 2795 | | | | 2796 | 2.2 | Success, invalid | Property name MAY be | 2797 | | property ignored. | specified. | 2798 | | | | 2799 | 2.3 | Success, invalid | Property parameter name and | 2800 | | property parameter | value MAY be specified. | 2801 | | ignored. | | 2802 | | | | 2803 | 2.4 | Success, unknown | Non-standard property name MAY | 2804 | | non-standard property | be specified. | 2805 | | ignored. | | 2806 | | | | 2807 | 2.5 | Success, unknown | Property and non-standard | 2808 | | non-standard property | value MAY be specified. | 2809 | | value ignored. | | 2810 | | | | 2811 | 2.6 | Success, invalid | Calendar component sentinel | 2812 | | calendar component | (e.g., BEGIN:ALARM) MAY be | 2813 | | ignored. | specified. | 2814 | | | | 2815 | 2.7 | Success, request | Original and forwarded caluser | 2816 | | forwarded to Calendar | addresses MAY be specified. | 2817 | | User. | | 2818 | | | | 2819 | 2.8 | Success, repeating | RRULE or RDATE property name | 2820 | | event ignored. | and value MAY be specified. | 2821 | | Scheduled as a single | | 2822 | | component. | | 2823 | | | | 2824 | 2.9 | Success, truncated end | DTEND property value MAY be | 2825 | | date time to date | specified. | 2826 | | boundary. | | 2827 | | | | 2828 | 2.10 | Success, repeating | RRULE or RDATE property name | 2829 | | VTODO ignored. | and value MAY be specified. | 2830 | | Scheduled as a single | | 2831 | | VTODO. | | 2832 | | | | 2833 | 2.11 | Success, unbounded | RRULE property name and value | 2834 | | RRULE clipped at some | MAY be specified. Number of | 2835 | | finite number of | instances MAY also be | 2836 | | instances | specified. | 2837 | | | | 2838 | 3.0 | Invalid property name. | Property name MAY be | 2839 | | | specified. | 2840 | | | | 2841 | 3.1 | Invalid property | Property name and value MAY be | 2842 | | value. | specified. | 2843 | | | | 2844 | 3.2 | Invalid property | Property parameter name and | 2845 | | parameter. | value MAY be specified. | 2846 | | | | 2847 | 3.3 | Invalid property | Property parameter name and | 2848 | | parameter value. | value MAY be specified. | 2849 | | | | 2850 | 3.4 | Invalid calendar | Calendar component sentinel | 2851 | | component sequence. | MAY be specified (e.g., | 2852 | | | BEGIN:VTIMEZONE). | 2853 | | | | 2854 | 3.5 | Invalid date or time. | Date/time value(s) MAY be | 2855 | | | specified. | 2856 | | | | 2857 | 3.6 | Invalid rule. | Rule value MAY be specified. | 2858 | | | | 2859 | 3.7 | Invalid Calendar User. | Attendee property value MAY be | 2860 | | | specified. | 2861 | | | | 2862 | 3.8 | No authority. | METHOD and Attendee property | 2863 | | | values MAY be specified. | 2864 | | | | 2865 | 3.9 | Unsupported version. | VERSION property name and | 2866 | | | value MAY be specified. | 2867 | | | | 2868 | 3.10 | Request entity too | None. | 2869 | | large. | | 2870 | | | | 2871 | 3.11 | Required component or | Component or property name MAY | 2872 | | property missing. | be specified. | 2873 | | | | 2874 | 3.12 | Unknown component or | Component or property name MAY | 2875 | | property found | be specified | 2876 | | | | 2877 | 3.13 | Unsupported component | Component or property name MAY | 2878 | | or property found | be specified | 2879 | | | | 2880 | 3.14 | Unsupported capability | Method or action MAY be | 2881 | | | specified | 2882 | | | | 2883 | 4.0 | Event conflict. | DTSTART and DTEND property | 2884 | | Date/time is busy. | name and values MAY be | 2885 | | | specified. | 2886 | | | | 2887 | 5.0 | Request MAY supported. | Method property value MAY be | 2888 | | | specified. | 2889 | | | | 2890 | 5.1 | Service unavailable. | ATTENDEE property value MAY be | 2891 | | | specified. | 2892 | | | | 2893 | 5.2 | Invalid calendar | ATTENDEE property value MAY be | 2894 | | service. | specified. | 2895 | | | | 2896 | 5.3 | No scheduling support | ATTENDEE property value MAY be | 2897 | | for user. | specified. | 2898 +---------+------------------------+--------------------------------+ 2900 3.7. Implementation Considerations 2902 3.7.1. Working With Recurrence Instances 2904 iCalendar includes a recurrence grammar to represent recurring 2905 events. The benefit of such a grammar is the ability to represent a 2906 number of events in a single object. However, while this simplifies 2907 creation of a recurring event, meeting instances still need to be 2908 referenced. For instance, an "Attendee" may decline the third 2909 instance of a recurring Friday event. Similarly, the "Organizer" may 2910 change the time or location to a single instance of the recurring 2911 event. 2913 Since implementations may elect to store recurring events as either a 2914 single event object or a collection of discreet, related event 2915 objects, the protocol is designed so that each recurring instance may 2916 be both referenced and versioned. Hence, implementations that choose 2917 to maintain per-instance properties (such as "ATTENDEE" property 2918 "partstat" parameter) may do so. However, the protocol does not 2919 require per-instance recognition unless the instance itself must be 2920 renegotiated. 2922 The scenarios for recurrence instance referencing are listed below. 2923 For purposes of simplification a change to an event refers to a 2924 "trigger property." That is, a property that has a substantive 2925 effect on the meeting itself such as start time, location, due date 2926 (for "VTODO" calendar component components) and possibly description. 2928 "Organizer" initiated actions: 2930 o "Organizer" deletes or changes a single instance of a recurring 2931 event 2932 o "Organizer" makes changes that affect all future instances 2933 o "Organizer" makes changes that affect all previous instances 2934 o "Organizer" deletes or modifies a previously changed instance 2936 "Attendee" initiated actions: 2938 o "Attendee" changes status for a particular recurrence instance 2939 o "Attendee" sends Event-Counter for a particular recurrence 2940 instance 2942 An instance of a recurring event is assigned a unique identification, 2943 "RECURRENCE-ID" property, when that instance is renegotiated. 2944 Negotiation may be necessary when a substantive change to the event 2945 or to-do has be made (such as changing the start time, end time, due 2946 date or location). The "Organizer" can identify a specific 2947 recurrence instance using the "RECURRENCE-ID" property. The property 2948 value is equal to the date/time of the instance. If the "Organizer" 2949 wishes to change the "DTSTART", the original "DTSTART" value is used 2950 for "RECURRENCE-ID" property and the new "DTSTART" and "DTEND" values 2951 reflect the change. Note that after the change has occurred, the 2952 "RECURRENCE-ID" has changed to the new "DTSTART" value. 2954 3.7.2. Attendee Property Considerations 2956 The "ORGANIZER" property is required on published events, to-dos, and 2957 journal entries for two reasons. First, only the "Organizer" is 2958 allowed to update and redistribute an event or to-do component. It 2959 follows that the "ORGANIZER" property MUST be present in the event, 2960 to-do, or journal entry component so that the CUA has a basis for 2961 authorizing an update. Second, it is prudent to provide a point of 2962 contact for anyone who receives a published component in case of 2963 problems. 2965 There are valid [RFC2822] addresses that represent groups. Sending 2966 email to such an address results in mail being sent to multiple 2967 recipients. Such an address may be used as the value of an 2968 "ATTENDEE" property. Thus, it is possible that the recipient of a 2969 "REQUEST" does not appear explicitly in the list. 2971 It is recommended that the general approach to finding a "Calendar 2972 User" in an attendee list be as follows: 2974 1. Search for the "Calendar User" in the attendee list where 2975 "TYPE=INDIVIDUAL" 2977 2. Failing (1) look for attendees where "TYPE=GROUP" or 2978 'TYPE=UNKNOWN". The CUA then determines if the "Calendar User" 2979 is a member of one of these groups. If so, the "REPLY" method 2980 sent to the "Organizer" MUST contain a new "ATTENDEE" property in 2981 which: 2983 * the "type" property parameter is set to INDIVIDUAL 2984 * the "member" property parameter is set to the name of the 2985 group 2987 3. Failing (2) the CUA MAY ignore or accept the request as the 2988 "Calendar User" wishes. 2990 3.7.3. X-Tokens 2992 To make iCalendar objects extensible, new property types MAY be 2993 inserted into components. These properties are called X-Tokens as 2994 they are prefixed with "X-". A client is not required to make sense 2995 of X-Tokens. Clients are not required to save X-Tokens or use them 2996 in replies. 2998 4. Examples 3000 4.1. Published Event Examples 3002 In the calendaring and scheduling context, publication refers to the 3003 one way transfer of event information. Consumers of published events 3004 simply incorporate the event into a calendar. No reply is expected. 3005 Individual "A" publishes an event. Individual "B" reads the event 3006 and incorporates it into their calendar. Events are published in 3007 several ways including: embedding the event as an object in a web 3008 page, e- mailing the event to a distribution list, and posting the 3009 event to a newsgroup. 3011 The table below illustrates the sequence of events between the 3012 publisher and the consumers of a published event. 3014 +----------------+-----------------------+--------------------------+ 3015 | Action | Organizer | Receiver | 3016 +----------------+-----------------------+--------------------------+ 3017 | Publish an | "A" sends or posts a | "B" reads a published | 3018 | event | PUBLISH message | event | 3019 | | | | 3020 | Publish an | "A" sends or posts a | "B" reads the updated | 3021 | updated event | PUBLISH message | event | 3022 | | | | 3023 | Cancel a | "A" sends or posts a | "B" reads the canceled | 3024 | published | CANCEL message | event publication | 3025 | event | | | 3026 +----------------+-----------------------+--------------------------+ 3028 4.1.1. A Minimal Published Event 3030 The iCalendar object below describes a single event that begins on 3031 July 1, 1997 at 20:00 UTC. This event contains the minimum set of 3032 properties for a "PUBLISH" for a "VEVENT" calendar component. 3034 BEGIN:VCALENDAR 3035 METHOD:PUBLISH 3036 PRODID:-//ACME/DesktopCalendar//EN 3037 VERSION:2.0 3038 BEGIN:VEVENT 3039 ORGANIZER:mailto:a@example.com 3040 DTSTART:19970701T200000Z 3041 DTSTAMP:19970611T190000Z 3042 SUMMARY:ST. PAUL SAINTS -VS- DULUTH-SUPERIOR DUKES 3043 UID:0981234-1234234-23@example.com 3044 END:VEVENT 3045 END:VCALENDAR 3047 4.1.2. Changing A Published Event 3049 The iCalendar object below describes an update to the event described 3050 in 4.1.1, the time has been changed, an end time has been added, and 3051 the sequence number has been adjusted. 3053 BEGIN:VCALENDAR 3054 METHOD:PUBLISH 3055 VERSION:2.0 3056 PRODID:-//ACME/DesktopCalendar//EN 3057 BEGIN:VEVENT 3058 ORGANIZER:mailto:a@example.com 3059 DTSTAMP:19970612T190000Z 3060 DTSTART:19970701T210000Z 3061 DTEND:19970701T230000Z 3062 SEQUENCE:1 3063 UID:0981234-1234234-23@example.com 3064 SUMMARY:ST. PAUL SAINTS -VS- DULUTH-SUPERIOR DUKES 3065 END:VEVENT 3066 END:VCALENDAR 3068 The "UID" property is used by the client to identify the event. The 3069 "SEQUENCE" property indicates that this is a change to the event. 3070 The event with a matching UID and sequence number 0 is superseded by 3071 this event. 3073 The "SEQUENCE" property provides a reliable way to distinguish 3074 different versions of the same event. Each time an event is 3075 published, its sequence number is incremented. If a client receives 3076 an event with a sequence number 5 and finds it has the same event 3077 with sequence number 2, the event SHOULD be updated. However, if the 3078 client received an event with sequence number 2 and finds it already 3079 has sequence number 5 of the same event, the event MUST NOT be 3080 updated. 3082 4.1.3. Canceling A Published Event 3084 The iCalendar object below cancels the event described in 4.1.1. 3085 This cancels the event with "SEQUENCE" property of 0, 1, and 2. 3087 BEGIN:VCALENDAR 3088 METHOD:CANCEL 3089 VERSION:2.0 3090 PRODID:-//ACME/DesktopCalendar//EN 3091 BEGIN:VEVENT 3092 ORGANIZER:mailto:a@example.com 3093 COMMENT:DUKES forfeit the game 3094 SEQUENCE:2 3095 UID:0981234-1234234-23@example.com 3096 DTSTAMP:19970613T190000Z 3097 END:VEVENT 3098 END:VCALENDAR 3100 4.1.4. A Rich Published Event 3102 This example describes the same event as in 4.1.1, but in much 3103 greater detail. 3105 BEGIN:VCALENDAR 3106 PRODID:-//ACME/DesktopCalendar//EN 3107 METHOD:PUBLISH 3108 SCALE:GREGORIAN 3109 VERSION:2.0 3110 BEGIN:VTIMEZONE 3111 TZID:America-Chicago 3112 TZURL:http://zones.stds_r_us.net/tz/America-Chicago 3113 BEGIN:STANDARD 3114 DTSTART:19671029T020000 3115 RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=10 3116 TZOFFSETFROM:-0500 3117 TZOFFSETTO:-0600 3118 TZNAME:CST 3119 END:STANDARD 3120 BEGIN:DAYLIGHT 3121 DTSTART:19870405T020000 3122 RRULE:FREQ=YEARLY;BYDAY=1SU;BYMONTH=4 3123 TZOFFSETFROM:-0600 3124 TZOFFSETTO:-0500 3125 TZNAME:CDT 3126 END:DAYLIGHT 3127 END:VTIMEZONE 3128 BEGIN:VEVENT 3129 ORGANIZER:mailto:a@example.com 3130 ATTACH:http://www.dukes.com/ 3131 CATEGORIES:SPORTS EVENT,ENTERTAINMENT 3132 CLASS:PRIVATE 3133 DESCRIPTION:MIDWAY STADIUM\n 3134 Big time game. MUST see.\n 3135 Expected duration:2 hours\n 3136 DTEND;TZID=America-Chicago:19970701T180000 3137 DTSTART;TZID=America-Chicago:19970702T160000 3138 DTSTAMP:19970614T190000Z 3139 STATUS:CONFIRMED 3140 LOCATION;VALUE=URI:http://www.midwaystadium.com/ 3141 PRIORITY:2 3142 RESOURCES:SCOREBOARD 3143 SEQUENCE:3 3144 SUMMARY:ST. PAUL SAINTS -VS- DULUTH-SUPERIOR DUKES 3145 UID:0981234-1234234-23@example.com 3146 RELATED-TO:0981234-1234234-14@example.com 3147 BEGIN:VALARM 3148 TRIGGER:-PT2H 3149 ACTION:DISPLAY 3150 DESCRIPTION:You should be leaving for the game now. 3151 END:VALARM 3152 BEGIN:VALARM 3153 TRIGGER:-PT30M 3154 ACTION:AUDIO 3155 END:VALARM 3156 END:VEVENT 3157 END:VCALENDAR 3159 The "RELATED-TO" field contains the "UID" property of a related 3160 calendar event. The "SEQUENCE" property 3 indicates that this event 3161 supersedes versions 0, 1, and 2. 3163 4.1.5. Anniversaries or Events attached to entire days 3165 This example demonstrates the use of the "value" parameter to tie a 3166 "VEVENT" to day rather than a specific time. 3168 BEGIN:VCALENDAR 3169 PRODID:-//ACME/DesktopCalendar//EN 3170 METHOD:PUBLISH 3171 VERSION:2.0 3172 BEGIN:VEVENT 3173 ORGANIZER:mailto:a@example.com 3174 DTSTAMP:19970614T190000Z 3175 UID:0981234-1234234-23@example.com 3176 DTSTART;VALUE=DATE:19970714 3177 RRULE:FREQ=YEARLY;INTERVAL=1 3178 SUMMARY: Bastille Day 3179 END:VEVENT 3180 END:VCALENDAR 3182 4.2. Group Event Examples 3184 Group events are distinguished from published events in that they 3185 have "Attendees" and that there is interaction between the 3186 "Attendees" and the "Organizer" with respect to the event. 3187 Individual "A" requests a meeting between individuals "A", "B", "C" 3188 and "D". Individual "B" confirms attendance to the meeting. 3189 Individual "C" declines attendance. Individual "D" tentatively 3190 confirms attendance. The following table illustrates the the message 3191 flow between these individuals. A, the CU scheduling the meeting, is 3192 referenced as the "Organizer". 3194 +-------------+-----------------------+-----------------------------+ 3195 | Action | "Organizer" | Attendee | 3196 +-------------+-----------------------+-----------------------------+ 3197 | Initiate a | "A" sends a REQUEST | | 3198 | meeting | message to "B", "C", | | 3199 | request | and "D" | | 3200 | | | | 3201 | Accept the | | "B" sends a REPLY message | 3202 | meeting | | to "A" with its ATTENDEE | 3203 | request | | "partstat" para-set to | 3204 | | | "accepted" | 3205 | | | | 3206 | Decline the | | "C" sends a REPLY message | 3207 | meeting | | to "A" with its ATTENDEE | 3208 | request | | "partstat" para-set to | 3209 | | | "declined" | 3210 | | | | 3211 | Tentatively | | "D" sends a REPLY message | 3212 | accept the | | to "A" with its ATTENDEE | 3213 | meeting | | "partstat" para-set to | 3214 | request | | "tentative" | 3215 | | | | 3216 | Confirm | "A" sends a REQUEST | | 3217 | meeting | message to "B" and | | 3218 | status with | "D" with updated | | 3219 | attendees | information. | | 3220 +-------------+-----------------------+-----------------------------+ 3222 4.2.1. A Group Event Request 3224 A sample meeting request is sent from "A" to "B", "C", and "D". _E_ 3225 is also sent a copy of the request but is not expected to attend and 3226 need not reply. "E" illustrates how CUAs might implement an "FYI" 3227 type feature. Note the use of the "role" parameter. The default 3228 value for the "role" parameter is "req-participant" and it need not 3229 be enumerated. In this case we are using the value "non-participant" 3230 to indicate "E" is a non-attending CU. The parameter is not needed 3231 on other "Attendees" since "participant" is the default value. 3233 BEGIN:VCALENDAR 3234 PRODID:-//ACME/DesktopCalendar//EN 3235 METHOD:REQUEST 3236 VERSION:2.0 3237 BEGIN:VEVENT 3238 ORGANIZER:Mailto:A@example.com 3239 ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED;CN=A:Mailto:A@example.com 3240 ATTENDEE;RSVP=TRUE;TYPE=INDIVIDUAL;CN=B:Mailto:B@example.com 3241 ATTENDEE;RSVP=TRUE;TYPE=INDIVIDUAL;CN=C:Mailto:C@example.com 3242 ATTENDEE;RSVP=TRUE;TYPE=INDIVIDUAL;CN=Hal:Mailto:D@example.com 3243 ATTENDEE;RSVP=FALSE;TYPE=ROOM:conf_Big@example.com 3244 ATTENDEE;ROLE=NON-PARTICIPANT;RSVP=FALSE:Mailto:E@example.com 3245 DTSTAMP:19970611T190000Z 3246 DTSTART:19970701T200000Z 3247 DTEND:19970701T2000000Z 3248 SUMMARY:Conference 3249 UID:calsrv.example.com-873970198738777@example.com 3250 SEQUENCE:0 3251 STATUS:CONFIRMED 3252 END:VEVENT 3253 END:VCALENDAR 3255 4.2.2. Reply To A Group Event Request 3257 Attendee "B" accepts the meeting. 3259 BEGIN:VCALENDAR 3260 PRODID:-//ACME/DesktopCalendar//EN 3261 METHOD:REPLY 3262 VERSION:2.0 3263 BEGIN:VEVENT 3264 ATTENDEE;PARTSTAT=ACCEPTED:Mailto:B@example.com 3265 ORGANIZER:MAILTO:A@example.com 3266 UID:calsrv.example.com-873970198738777@example.com 3267 SEQUENCE:0 3268 REQUEST-STATUS:2.0;Success 3269 DTSTAMP:19970612T190000Z 3270 END:VEVENT 3271 END:VCALENDAR 3273 "B" could have declined the meeting or indicated tentative acceptance 3274 by setting the "ATTENDEE" "partstat" parameter to "declined" or 3275 "tentative", respectively. Also, "REQUEST-STATUS" is not required in 3276 successful transactions. 3278 4.2.3. Update An Event 3280 The event is moved to a different time. The combination of the "UID" 3281 property (unchanged) and the "SEQUENCE" (bumped to 1) properties 3282 indicate the update. 3284 BEGIN:VCALENDAR 3285 PRODID:-//ACME/DesktopCalendar//EN 3286 METHOD:REQUEST 3287 VERSION:2.0 3288 BEGIN:VEVENT 3289 ORGANIZER:Mailto:A@example.com 3290 ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:Mailto:A@example.com 3291 ATTENDEE;RSVP=TRUE;TYPE=INDIVIDUAL:Mailto:B@example.com 3292 ATTENDEE;RSVP=TRUE;TYPE=INDIVIDUAL:Mailto:C@example.com 3293 ATTENDEE;RSVP=TRUE;TYPE=INDIVIDUAL;CN=Hal:Mailto:D@example.com 3294 ATTENDEE;ROLE=NON-PARTICIPANT;RSVP=FALSE; 3295 CUTYPE=ROOM:Mailto:Conf@example.com 3296 ATTENDEE;ROLE=NON-PARTICIPANT;RSVP=FALSE:Mailto:E@example.com 3297 DTSTART:19970701T180000Z 3298 DTEND:19970701T190000Z 3299 SUMMARY:Phone Conference 3300 UID:calsrv.example.com-873970198738777@example.com 3301 SEQUENCE:1 3302 DTSTAMP:19970613T190000Z 3303 STATUS:CONFIRMED 3304 END:VEVENT 3305 END:VCALENDAR 3307 4.2.4. Countering an Event Proposal 3309 "A" sends a "REQUEST" to "B" and "C". "B" makes a counter-proposal 3310 to "A" to change the time and location. 3312 "A" sends the following "REQUEST": 3314 BEGIN:VCALENDAR 3315 PRODID:-//ACME/DesktopCalendar//EN 3316 METHOD:REQUEST 3317 VERSION:2.0 3318 BEGIN:VEVENT 3319 ORGANIZER:Mailto:A@example.com 3320 ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:Mailto:A@example.com 3321 ATTENDEE;RSVP=TRUE;TYPE=INDIVIDUAL:Mailto:B@example.com 3322 ATTENDEE;RSVP=TRUE;TYPE=INDIVIDUAL:Mailto:C@example.com 3323 DTSTART:19970701T190000Z 3324 DTEND:19970701T200000Z 3325 SUMMARY:Discuss the Merits of the election results 3326 LOCATION:Green Conference Room 3327 UID:calsrv.example.com-873970198738777a@example.com 3328 SEQUENCE:0 3329 DTSTAMP:19970611T190000Z 3330 STATUS:CONFIRMED 3331 END:VEVENT 3332 END:VCALENDAR 3334 "B" sends "COUNTER" to "A", requesting changes to time and place. 3335 "B" uses the "COMMENT" property to communicate a rationale for the 3336 change. Note that the "SEQUENCE" property is NOT incremented on a 3337 "COUNTER". 3339 BEGIN:VCALENDAR 3340 PRODID:-//ACME/DesktopCalendar//EN 3341 METHOD:COUNTER 3342 VERSION:2.0 3343 BEGIN:VEVENT 3344 ORGANIZER:Mailto:A@example.com 3345 ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:Mailto:A@example.com 3346 ATTENDEE;RSVP=TRUE;TYPE=INDIVIDUAL:Mailto:B@example.com 3347 ATTENDEE;RSVP=TRUE;TYPE=INDIVIDUAL:Mailto:C@example.com 3348 DTSTART:19970701T160000Z 3349 DTEND:19970701T190000Z 3350 DTSTAMP:19970612T190000Z 3351 SUMMARY:Discuss the Merits of the election results 3352 LOCATION:Green Conference Room 3353 COMMENT:This time works much better and I think the big conference 3354 room is too big 3355 UID:calsrv.example.com-873970198738777a@example.com 3356 SEQUENCE:0 3357 DTSTAMP:19970611T190000Z 3358 END:VEVENT 3359 END:VCALENDAR 3361 "A" accepts the changes from "B". To accept a counter-proposal, the 3362 "Organizer" sends a new event "REQUEST" with an incremented sequence 3363 number. 3365 BEGIN:VCALENDAR 3366 PRODID:-//ACME/DesktopCalendar//EN 3367 METHOD:REQUEST 3368 VERSION:2.0 3369 BEGIN:VEVENT 3370 ORGANIZER:Mailto:A@example.com 3371 ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:Mailto:A@example.com 3372 ATTENDEE;RSVP=TRUE;TYPE=INDIVIDUAL:Mailto:B@example.com 3373 ATTENDEE;RSVP=TRUE;TYPE=INDIVIDUAL:Mailto:C@example.com 3374 DTSTAMP:19970613T190000Z 3375 DTSTART:19970701T160000Z 3376 DTEND:19970701T190000Z 3377 SUMMARY:Discuss the Merits of the election results - changed to 3378 meet B's schedule 3379 LOCATION:Green Conference Room 3380 UID:calsrv.example.com-873970198738777@example.com 3381 SEQUENCE:1 3382 STATUS:CONFIRMED 3383 END:VEVENT 3384 END:VCALENDAR 3386 Instead, "A" rejects "B's" counter proposal 3388 BEGIN:VCALENDAR 3389 PRODID:-//ACME/DesktopCalendar//EN 3390 METHOD:DECLINECOUNTER 3391 VERSION:2.0 3392 BEGIN:VEVENT 3393 ORGANIZER:Mailto:A@example.com 3394 ATTENDEE;RSVP=TRUE;TYPE=INDIVIDUAL:Mailto:B@example.com 3395 COMMENT:Sorry, I cannot change this meeting time 3396 UID:calsrv.example.com-873970198738777@example.com 3397 SEQUENCE:0 3398 DTSTAMP:19970614T190000Z 3399 END:VEVENT 3400 END:VCALENDAR 3402 4.2.5. Delegating an Event 3404 When delegating an event request to another "Calendar User", the 3405 "Delegator" must both update the "Organizer" with a "REPLY" and send 3406 a request to the "Delegate". There is currently no protocol 3407 limitation to delegation depth. It is possible for the original 3408 delegate to delegate the meeting to someone else, and so on. When a 3409 request is delegated from one CUA to another there are a number of 3410 responsibilities required of the "Delegator". The "Delegator" MUST: 3412 o Send a "REPLY" to the "Organizer" with the following updates: 3414 o The "Delegator's" "ATTENDEE" property "partstat" parameter set to 3415 "delegated" and the "delegated-to" parameter is set to the address 3416 of the "Delegate" 3418 o Add an additional "ATTENDEE" property for the "Delegate" with the 3419 "delegated-from" property parameter set to the "Delegator" 3421 o Indicate whether they want to continue to receive updates when the 3422 "Organizer" sends out updated versions of the event. Setting the 3423 "rsvp" property parameter to "TRUE" will cause the updates to be 3424 sent, setting it to "FALSE" causes no further updates to be sent. 3425 Note that in either case, if the "Delegate" declines the 3426 invitation the "Delegator" will be notified. 3428 o The "Delegator" MUST also send a copy of the original "REQUEST" 3429 method to the "Delegate". 3431 It is not required that the "Delegate" include the "Delegator" in 3432 their "REPLY" method. However, it is strongly advised since this 3433 will inform the "Delegator" whether the "Delegate" plans to attend 3434 the meeting. [Editors note: How so?] If the "Delegate" declines the 3435 meeting, the "Delegator" may elect to delegate the "REQUEST" to 3436 another CUA. The process is the same. 3438 +----------------+-----------------+--------------------------------+ 3439 | Action | "Organizer" | Attendee | 3440 +----------------+-----------------+--------------------------------+ 3441 | Initiate a | "A" sends a | | 3442 | meeting | REQUEST message | | 3443 | request | to "B" and "C" | | 3444 | | | | 3445 | Delegate: "C" | | "C" sends a REPLY to "A" with | 3446 | delegates to | | the ATTENDEE "partstat" | 3447 | "E" | | parameter set to "delegated" | 3448 | | | and with a new "ATTENDEE" | 3449 | | | property for "E". "E's" | 3450 | | | ATTENDEE "delegated-from" | 3451 | | | param is set to "C". "C's" | 3452 | | | ATTENDEE "delegated-to" param | 3453 | | | is set to "E". "C" sends | 3454 | | | REQUEST message to "E" with | 3455 | | | the original meeting request | 3456 | | | information. The "partstat" | 3457 | | | property parameter for "C" is | 3458 | | | set to "delegated" and the | 3459 | | | "delegated-to" parameter is | 3460 | | | set to the address of "E". An | 3461 | | | "ATTENDEE" property is added | 3462 | | | for "E" and the | 3463 | | | "delegated-from" parameter is | 3464 | | | set to the address of "C". | 3465 | | | | 3466 | Confirm | | "E" sends REPLY message to "A" | 3467 | meeting | | and optionally "C" with its | 3468 | attendance | | "partstat" property parameter | 3469 | | | set to "ACCEPTED" | 3470 | | | | 3471 | Optional: | "A" sends | | 3472 | Redistribute | REQUEST message | | 3473 | meeting to | to "B", "C" and | | 3474 | attendees | "E". | | 3475 +----------------+-----------------+--------------------------------+ 3477 "C" responds to the "Organizer". 3479 BEGIN:VCALENDAR 3480 PRODID:-//ACME/DesktopCalendar//EN 3481 METHOD:REPLY 3482 VERSION:2.0 3483 BEGIN:VEVENT 3484 ORGANIZER:MAILTO:A@Example.com 3485 ATTENDEE;PARTSTAT=DELEGATED;DELEGATED- 3486 TO="Mailto:E@example.com":Mailto:C@example.com 3487 UID:calsrv.example.com-873970198738777@example.com 3488 SEQUENCE:0 3489 REQUEST-STATUS:2.0;Success 3490 DTSTAMP:19970611T190000Z 3491 END:VEVENT 3492 END:VCALENDAR 3494 Attendee "C" delegates presence at the meeting to "E". 3496 BEGIN:VCALENDAR 3497 PRODID:-//ACME/DesktopCalendar//EN 3498 METHOD:REQUEST 3499 VERSION:2.0 3500 BEGIN:VEVENT 3501 ORGANIZER:Mailto:A@example.com 3502 ATTENDEE;PARTSTAT=DELEGATED;DELEGATED- 3503 TO="Mailto:E@example.com":Mailto:C@example.com 3504 ATTENDEE;RSVP=TRUE; 3505 DELEGATED-FROM="Mailto:C@example.com":Mailto:E@example.com 3506 DTSTART:19970701T180000Z 3507 DTEND:19970701T200000Z 3508 SUMMARY:Phone Conference 3509 UID:calsrv.example.com-873970198738777@example.com 3510 SEQUENCE:0 3511 STATUS:CONFIRMED 3512 DTSTAMP:19970611T190000Z 3513 END:VEVENT 3514 END:VCALENDAR 3516 4.2.6. Delegate Accepts the Meeting 3518 To accept a delegated meeting, the delegate, "E", sends the following 3519 message to "A" and "C": 3521 BEGIN:VCALENDAR 3522 PRODID:-//ACME/DesktopCalendar//EN 3523 METHOD:REPLY 3524 VERSION:2.0 3525 BEGIN:VEVENT 3526 ORGANIZER:MAILTO:A@Example.com 3527 ATTENDEE;PARTSTAT=ACCEPTED;DELEGATED- 3528 FROM="Mailto:C@example.com":Mailto:E@example.com 3529 ATTENDEE;PARTSTAT=DELEGATED; 3530 DELEGATED-TO="Mailto:E@example.com":Mailto:C@example.com 3531 UID:calsrv.example.com-873970198738777@example.com 3532 SEQUENCE:0 3533 REQUEST-STATUS:2.0;Success 3534 DTSTAMP:19970614T190000Z 3535 END:VEVENT 3536 END:VCALENDAR 3538 4.2.7. Delegate Declines the Meeting 3540 In this example the "Delegate" declines the meeting request and sets 3541 the "ATTENDEE" property "partstat" parameter to "DECLINED". The 3542 "Organizer" SHOULD resend the "REQUEST" to "C" with the "partstat" 3543 parameter of the "Delegate" set to "declined". This lets the 3544 "Delegator" know that the "Delegate" has declined and provides an 3545 opportunity to the "Delegator" to either accept the request or 3546 delegate it to another CU. 3548 Response from "E" to "A" and "C". Note the use of the "COMMENT" 3549 property "E" uses to indicate why the delegation was declined. 3551 BEGIN:VCALENDAR 3552 PRODID:-//ACME/DesktopCalendar//EN 3553 METHOD:REPLY 3554 VERSION:2.0 3555 BEGIN:VEVENT 3556 ORGANIZER:MAILTO:A@Example.com 3557 ATTENDEE;PARTSTAT=DELEGATED; 3558 DELEGATED-TO="Mailto:E@example.com":Mailto:C@example.com 3559 ATTENDEE;PARTSTAT=DECLINED; 3560 DELEGATED-FROM="Mailto:C@example.com":Mailto:E@example.com 3561 COMMENT:Sorry, I will be out of town at that time. 3562 UID:calsrv.example.com-873970198738777@example.com 3563 SEQUENCE:0 3564 REQUEST-STATUS:2.0;Success 3565 DTSTAMP:19970614T190000Z 3566 END:VEVENT 3567 END:VCALENDAR 3569 "A" resends the "REQUEST" method to "C". "A" may also wish to 3570 express the fact that the item was delegated in the "COMMENT" 3571 property. 3573 BEGIN:VCALENDAR 3574 PRODID:-//ACME/DesktopCalendar//EN 3575 METHOD:REQUEST 3576 VERSION:2.0 3577 BEGIN:VEVENT 3578 ORGANIZER:MAILTO:A@Example.com 3579 ATTENDEE;PARTSTAT=DECLINED; 3580 DELEGATED-FROM="Mailto:C@example.com":Mailto:E@example.com 3581 ATTENDEE;RSVP=TRUE:Mailto:C@example.com 3582 UID:calsrv.example.com-873970198738777@example.com 3583 SEQUENCE:0 3584 SUMMARY:Phone Conference 3585 DTSTART:19970701T180000Z 3586 DTEND:19970701T200000Z 3587 DTSTAMP:19970614T200000Z 3588 COMMENT:DELEGATE (ATTENDEE Mailto:E@example.com) DECLINED YOUR 3589 INVITATION 3590 END:VEVENT 3591 END:VCALENDAR 3593 4.2.8. Forwarding an Event Request 3595 The protocol does not prevent an "Attendee" from "forwarding" an 3596 "VEVENT" calendar component to other "Calendar Users". Forwarding 3597 differs from delegation in that the forwarded "Calendar User" (often 3598 referred to as a "Party Crasher") does not replace the forwarding 3599 "Calendar User". Implementations are not required to add the "Party 3600 Crasher" to the "Attendee" list and hence there is no guarantee that 3601 a "Party Crasher" will receive additional updates to the Event. The 3602 forwarding "Calendar User" SHOULD NOT add the "Party Crasher" to the 3603 attendee list. The "Organizer" MAY add the forwarded "Calendar User" 3604 to the attendee list. 3606 4.2.9. Cancel A Group Event 3608 Individual "A" requests a meeting between individuals "A", "B", "C", 3609 and "D". Individual "B" declines attendance to the meeting. 3610 Individual "A" decides to cancel the meeting. The following table 3611 illustrates the sequence of messages that would be exchanged between 3612 these individuals. 3614 Messages related to a previously canceled event ("SEQUENCE" property 3615 value is less than the "SEQUENCE" property value of the "CANCEL" 3616 message) MUST be ignored. 3618 +------------+--------------------+---------------------------------+ 3619 | Action | "Organizer" | "Attendee" | 3620 +------------+--------------------+---------------------------------+ 3621 | Initiate a | "A" sends a | | 3622 | meeting | REQUEST message to | | 3623 | request | "B", "C", and "D" | | 3624 | | | | 3625 | Decline | | "B" sends a "REPLY" message to | 3626 | the | | "A" with its "partstat" | 3627 | meeting | | para-set to "declined". | 3628 | request | | | 3629 | | | | 3630 | Cancel the | "A" sends a CANCEL | | 3631 | meeting | message to "B", | | 3632 | | "C" and "D" | | 3633 +------------+--------------------+---------------------------------+ 3635 The example shows how "A" cancels the event. 3637 BEGIN:VCALENDAR 3638 PRODID:-//ACME/DesktopCalendar//EN 3639 METHOD:CANCEL 3640 VERSION:2.0 3641 BEGIN:VEVENT 3642 ORGANIZER:Mailto:A@example.com 3643 ATTENDEE;TYPE=INDIVIDUAL;Mailto:A@example.com 3644 ATTENDEE;TYPE=INDIVIDUAL:Mailto:B@example.com 3645 ATTENDEE;TYPE=INDIVIDUAL:Mailto:C@example.com 3646 ATTENDEE;TYPE=INDIVIDUAL:Mailto:D@example.com 3647 COMMENT:Mr. B cannot attend. It's raining. Lets cancel. 3648 UID:calsrv.example.com-873970198738777@example.com 3649 SEQUENCE:1 3650 STATUS:CANCELLED 3651 DTSTAMP:19970613T190000Z 3652 END:VEVENT 3653 END:VCALENDAR 3655 4.2.10. Removing Attendees 3657 "A" wants to remove "B" from a meeting. This is done by sending a 3658 "CANCEL" to "B" and removing "B" from the attendee list in the master 3659 copy of the event. 3661 +--------------------+---------------------------------+------------+ 3662 | Action | "Organizer" | "Attendee" | 3663 +--------------------+---------------------------------+------------+ 3664 | Remove an "B" as | "A" sends a CANCEL message to | | 3665 | an "Attendee" | "B" | | 3666 | | | | 3667 | Update the master | "A" sends the updated event to | | 3668 | copy of the event | the remaining "Attendees" | | 3669 +--------------------+---------------------------------+------------+ 3671 The original meeting includes "A", "B", "C", and "D". The example 3672 below shows the "CANCEL" that "A" sends to "B". Note that in the 3673 example below the "STATUS" property is omitted. This is used when 3674 the meeting itself is cancelled and not when the intent is to remove 3675 an "Attendee" from the Event. 3677 BEGIN:VCALENDAR 3678 PRODID:-//ACME/DesktopCalendar//EN 3679 METHOD:CANCEL 3680 VERSION:2.0 3681 BEGIN:VEVENT 3682 ORGANIZER:Mailto:A@example.com 3683 ATTENDEE:mailto:B@example.com 3684 COMMENT:You're off the hook for this meeting 3685 UID:calsrv.example.com-873970198738777@example.com 3686 DTSTAMP:19970613T193000Z 3687 SEQUENCE:1 3688 END:VEVENT 3689 END:VCALENDAR 3691 The updated master copy of the event is shown below. The "Organizer" 3692 MAY resend the updated event to the remaining "Attendees". Note that 3693 "B" has been removed. 3695 BEGIN:VCALENDAR 3696 PRODID:-//ACME/DesktopCalendar//EN 3697 METHOD:REQUEST 3698 VERSION:2.0 3699 BEGIN:VEVENT 3700 ORGANIZER:Mailto:A@example.com 3701 ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:Mailto:A@example.com 3702 ATTENDEE;TYPE=INDIVIDUAL:Mailto:C@example.com 3703 ATTENDEE;TYPE=INDIVIDUAL:Mailto:D@example.com 3704 ATTENDEE;TYPE=ROOM:CR_Big@example.com 3705 ATTENDEE;ROLE=NON-PARTICIPANT; 3706 RSVP=FALSE:Mailto:E@example.com 3707 DTSTAMP:19970611T190000Z 3708 DTSTART:19970701T200000Z 3709 DTEND:19970701T203000Z 3710 SUMMARY:Phone Conference 3711 UID:calsrv.example.com-873970198738777@example.com 3712 SEQUENCE:2 3713 STATUS:CONFIRMED 3714 END:VEVENT 3715 END:VCALENDAR 3717 4.2.11. Replacing the Organizer 3719 The scenario for this example begins with "A" as the "Organizer" for 3720 a recurring meeting with "B", "C", and "D". "A" receives a new job 3721 offer in another country and drops out of touch. "A" left no 3722 forwarding address or way to be reached. Using out-of-band 3723 communication, the other "Attendees" eventually learn what has 3724 happened and reach an agreement that "B" should become the new 3725 "Organizer" for the meeting. To do this, "B" sends out a new version 3726 of the event and the other "Attendees" agree to accept "B" as the new 3727 "Organizer". "B" also removes "A" from the event. 3729 When the "Organizer" is replaced, the "SEQUENCE" property value MUST 3730 be incremented. 3732 This is the message "B" sends to "C" and "D" 3733 BEGIN:VCALENDAR 3734 PRODID:-//ACME/DesktopCalendar//EN 3735 METHOD:REQUEST 3736 VERSION:2.0 3737 BEGIN:VEVENT 3738 ORGANIZER:Mailto:B@example.com 3739 ATTENDEE;ROLE=CHAIR;STATUS=ACCEPTED:Mailto:B@example.com 3740 ATTENDEE;TYPE=INDIVIDUAL:Mailto:C@example.com 3741 ATTENDEE;TYPE=INDIVIDUAL:Mailto:D@example.com 3742 DTSTAMP:19970611T190000Z 3743 DTSTART:19970701T200000Z 3744 DTEND:19970701T203000Z 3745 RRULE:FREQ=WEEKLY 3746 SUMMARY:Phone Conference 3747 UID:123456@example.com 3748 SEQUENCE:1 3749 STATUS:CONFIRMED 3750 END:VEVENT 3751 END:VCALENDAR 3753 4.3. Busy Time Examples 3755 Busy time objects can be used in several ways. First, a CU may 3756 request busy time from another CU for a specific range of time. That 3757 request can be answered with a busy time Reply. Additionally, a CU 3758 may simply publish their busy time for a given interval and point 3759 other CUs to the published location. The following examples outline 3760 both scenarios. 3762 Individual "A" publishes busy time for one week. 3764 BEGIN:VCALENDAR 3765 PRODID:-//ACME/DesktopCalendar//EN 3766 VERSION:2.0 3767 METHOD:PUBLISH 3768 BEGIN:VFREEBUSY 3769 DTSTAMP:19980101T124100Z 3770 ORGANIZER:MAILTO:A@Example.com 3771 DTSTART:19980101T124200Z 3772 DTEND:19980107T124200Z 3773 FREEBUSY:19980101T180000Z/19980101T190000Z 3774 FREEBUSY:19980103T020000Z/19980103T050000Z 3775 FREEBUSY:19980107T020000Z/19980107T050000Z 3776 FREEBUSY:19980113T000000Z/19980113T010000Z 3777 FREEBUSY:19980115T190000Z/19980115T200000Z 3778 FREEBUSY:19980115T220000Z/19980115T230000Z 3779 FREEBUSY:19980116T013000Z/19980116T043000Z 3780 END:VFREEBUSY 3781 END:VCALENDAR 3783 Individual "A" requests busy time from individuals "B", "C". 3784 Individual "B" and "C" replies with busy time data to individual "A". 3785 The following table illustrates the sequence of messages that would 3786 be exchanged between these individuals. 3788 +---------------------+--------------------+------------------------+ 3789 | Action | "Organizer" | Attendee | 3790 +---------------------+--------------------+------------------------+ 3791 | Initiate a busy | "A" sends | | 3792 | time request | "REQUEST" message | | 3793 | | to "B" and "C" | | 3794 | | | | 3795 | Reply to the "BUSY" | | "B" sends a "REPLY" | 3796 | request with "BUSY" | | message to "A" with | 3797 | time data | | busy time data | 3798 +---------------------+--------------------+------------------------+ 3800 4.3.1. Request Busy Time 3802 "A" sends a "BUSY-REQUEST" to "B" and "C" for busy time 3804 BEGIN:VCALENDAR 3805 PRODID:-//ACME/DesktopCalendar//EN 3806 METHOD:REQUEST 3807 VERSION:2.0 3808 BEGIN:VFREEBUSY 3809 ORGANIZER:Mailto:A@example.com 3810 ATTENDEE;ROLE=CHAIR:Mailto:A@example.com 3811 ATTENDEE:Mailto:B@example.com 3812 ATTENDEE:Mailto:C@example.com 3813 DTSTAMP:19970613T190000Z 3814 DTSTART:19970701T080000Z 3815 DTEND:19970701T200000 3816 UID:calsrv.example.com-873970198738777@example.com 3817 END:VFREEBUSY 3818 END:VCALENDAR 3820 4.3.2. Reply To A Busy Time Request 3822 "B" sends a "REPLY" method type of a "VFREEBUSY" calendar component 3823 to "A" 3824 BEGIN:VCALENDAR 3825 PRODID:-//ACME/DesktopCalendar//EN 3826 METHOD:REPLY 3827 VERSION:2.0 3828 BEGIN:VFREEBUSY 3829 ORGANIZER:MAILTO:A@example.com 3830 ATTENDEE:Mailto:B@example.com 3831 DTSTART:19970701T080000Z 3832 DTEND:19970701T200000Z 3833 UID:calsrv.example.com-873970198738777@example.com 3834 FREEBUSY:19970701T090000Z/PT1H,19970701T140000Z/PT30M 3835 DTSTAMP:19970613T190030Z 3836 END:VFREEBUSY 3837 END:VCALENDAR 3839 "B" is busy from 09:00 to 10:00 and from 14:00 to 14:30. 3841 4.4. Recurring Event and Time Zone Examples 3843 4.4.1. A Recurring Event Spanning Time Zones 3845 This event describes a weekly phone conference. The "Attendees" are 3846 each in a different time zone. 3848 BEGIN:VCALENDAR 3849 PRODID:-//ACME/DesktopCalendar//EN 3850 METHOD:REQUEST 3851 VERSION:2.0 3852 BEGIN:VTIMEZONE 3853 TZID:America-SanJose 3854 TZURL:http://zones.stds_r_us.net/tz/America-SanJose 3855 BEGIN:STANDARD 3856 DTSTART:19671029T020000 3857 RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=10 3858 TZOFFSETFROM:-0700 3859 TZOFFSETTO:-0800 3860 TZNAME:PST 3861 END:STANDARD 3862 BEGIN:DAYLIGHT 3863 DTSTART:19870405T020000 3864 RRULE:FREQ=YEARLY;BYDAY=1SU;BYMONTH=4 3865 TZOFFSETFROM:-0800 3866 TZOFFSETTO:-0700 3867 TZNAME:PDT 3868 END:DAYLIGHT 3869 END:VTIMEZONE 3870 BEGIN:VEVENT 3871 ORGANIZER:Mailto:A@example.com 3872 ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED; 3873 TYPE=INDIVIDUAL:A@example.COM 3874 ATTENDEE;RSVP=TRUE;TYPE=INDIVIDUAL:B@example.fr 3875 ATTENDEE;RSVP=TRUE;TYPE=INDIVIDUAL:c@example.jp 3876 DTSTAMP:19970613T190030Z 3877 DTSTART;TZID=America-SanJose:19970701T140000 3878 DTEND;TZID=America-SanJose:19970701T150000 3879 RRULE:FREQ=WEEKLY;INTERVAL=20;WKST=SU;BYDAY=TU 3880 RDATE;TZID=America-SanJose:19970910T140000 3881 EXDATE;TZID=America-SanJose:19970909T140000 3882 EXDATE;TZID=America-SanJose:19971028T140000 3883 SUMMARY:Weekly Phone Conference 3884 UID:calsrv.example.com-873970198738777@example.com 3885 SEQUENCE:0 3886 STATUS:CONFIRMED 3887 END:VEVENT 3888 END:VCALENDAR 3890 The first two components of this iCalendar object are the time zone 3891 components. The "DTSTART" date coincides with the first instance of 3892 the RRULE property. 3894 The recurring meeting is defined in a particular time zone, 3895 presumably that of the originator. The client for each "Attendee" 3896 has the responsibility of determining the recurrence time in the 3897 "Attendee's" time zone. 3899 The repeating event starts on Tuesday, July 1, 1997 at 2:00pm PDT. 3900 "Attendee" B@example.fr is in France where the local time on this 3901 date is 9 hours ahead of PDT or 23:00. "Attendee" C@example.jp is in 3902 Japan where local time is 8 hours ahead of UTC or Wednesday, July 2 3903 at 06:00. The event repeats weekly on Tuesdays (in PST/PDT). The 3904 "RRULE" property results in 20 instances. The last instance falls on 3905 Tuesday, November 11, 1997 2:00pm PDT. The "RDATE" property adds 3906 another instance: WED, 10-SEP-1997 2:00 PM PST. 3908 There are two exceptions to this recurring appointment. The first 3909 one is: 3911 o TUE, 09-SEP-1997 23:00 GMT 3912 o TUE, 09-SEP-1997 14:00 PDT 3913 o WED, 10-SEP-1997 06:00 JST 3915 and the second is: 3917 o TUE, 28-OCT-1997 23:00 GMT 3918 o TUE, 28-OCT-1997 14:00 PST 3919 o WED, 29-OCT-1997 06:00 JST 3921 4.4.2. Modify A Recurring Instance 3923 In this example the "Organizer" issues a recurring meeting. Later 3924 the "Organizer" changes an instance of the event by changing the 3925 "DTSTART" property. Note the use of "RECURRENCE-ID" property and 3926 "SEQUENCE" property in the second request. 3928 Original Request: 3930 BEGIN:VCALENDAR 3931 METHOD:REQUEST 3932 PRODID:-//RDU Software//NONSGML HandCal//EN 3933 VERSION:2.0 3934 BEGIN:VEVENT 3935 UID:guid-1@host1.com 3936 SEQUENCE:0 3937 RRULE:FREQ=MONTHLY;BYMONTHDAY=1;UNTIL=19980901T210000Z 3938 ORGANIZER:Mailto:A@example.com 3939 ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:Mailto:A@example.com 3940 ATTENDEE:Mailto:B@example.com 3941 ATTENDEE:Mailto:C@example.com 3942 ATTENDEE:Mailto:D@example.com 3943 DESCRIPTION:IETF-C&S Conference Call 3944 CLASS:PUBLIC 3945 SUMMARY:IETF Calendaring Working Group Meeting 3946 DTSTART:19970601T210000Z 3947 DTEND:19970601T220000Z 3948 LOCATION:Conference Call 3949 DTSTAMP:19970526T083000Z 3950 STATUS:CONFIRMED 3951 END:VEVENT 3952 END:VCALENDAR 3954 The event request below is to change the time of a specific instance. 3955 This changes the July 1st instance to July 3rd. 3957 BEGIN:VCALENDAR 3958 METHOD:REQUEST 3959 PRODID:-//RDU Software//NONSGML HandCal//EN 3960 VERSION:2.0 3961 BEGIN:VEVENT 3962 UID:guid-1@host1com 3963 RECURRENCE-ID:19970701T210000Z 3964 SEQUENCE:1 3965 ORGANIZER:Mailto:A@example.com 3966 ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:Mailto:A@example.com 3967 ATTENDEE:Mailto:B@example.com 3968 ATTENDEE:Mailto:C@example.com 3969 ATTENDEE:Mailto:D@example.com 3970 DESCRIPTION:IETF-C&S Conference Call 3971 CLASS:PUBLIC 3972 SUMMARY:IETF Calendaring Working Group Meeting 3973 DTSTART:19970703T210000Z 3974 DTEND:19970703T220000Z 3975 LOCATION:Conference Call 3976 DTSTAMP:19970626T093000Z 3977 STATUS:CONFIRMED 3978 END:VEVENT 3979 END:VCALENDAR 3981 4.4.3. Cancel an Instance 3983 In this example the "Organizer" of a recurring event deletes the 3984 August 1st instance. 3986 BEGIN:VCALENDAR 3987 METHOD:CANCEL 3988 PRODID:-//RDU Software//NONSGML HandCal//EN 3989 VERSION:2.0 3990 BEGIN:VEVENT 3991 UID:guid-1@host1.com 3992 ORGANIZER:Mailto:A@example.com 3993 ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:Mailto:A@example.com 3994 ATTENDEE:Mailto:B@example.com 3995 ATTENDEE:Mailto:C@example.com 3996 ATTENDEE:Mailto:D@example.com 3997 RECURRENCE-ID:19970801T210000Z 3998 SEQUENCE:2 3999 STATUS:CANCELLED 4000 DTSTAMP:19970721T093000Z 4001 END:VEVENT 4002 END:VCALENDAR 4004 4.4.4. Cancel Recurring Event 4006 In this example the "Organizer" wishes to cancel the entire recurring 4007 event and any exceptions. 4009 BEGIN:VCALENDAR 4010 METHOD:CANCEL 4011 PRODID:-//RDU Software//NONSGML HandCal//EN 4012 VERSION:2.0 4013 BEGIN:VEVENT 4014 UID:guid-1@host1.com 4015 ORGANIZER:Mailto:A@example.com 4016 ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:Mailto:A@example.com 4017 ATTENDEE:Mailto:B@example.com 4018 ATTENDEE:Mailto:C@example.com 4019 ATTENDEE:Mailto:D@example.com 4020 DTSTAMP:19970721T103000Z 4021 STATUS:CANCELLED 4022 SEQUENCE:3 4023 END:VEVENT 4024 END:VCALENDAR 4026 4.4.5. Change All Future Instances 4028 This example changes the meeting location from a conference call to 4029 Seattle starting September 1 and extends to all future instances. 4031 BEGIN:VCALENDAR 4032 METHOD:REQUEST 4033 PRODID:-//RDU Software//NONSGML HandCal//EN 4034 VERSION:2.0 4035 BEGIN:VEVENT 4036 UID:guid-1@host1.com 4037 RECURRENCE-ID;THISANDFUTURE:19970901T210000Z 4038 SEQUENCE:3 4039 ORGANIZER:Mailto:A@example.com 4040 ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:Mailto:A@example.com 4041 ATTENDEE;RSVP=TRUE:Mailto:B@example.com 4042 ATTENDEE;RSVP=TRUE:Mailto:C@example.com 4043 ATTENDEE;RSVP=TRUE:Mailto:D@example.com 4044 DESCRIPTION:IETF-C&S Discussion 4045 CLASS:PUBLIC 4046 SUMMARY:IETF Calendaring Working Group Meeting 4047 DTSTART:19970901T210000Z 4048 DTEND:19970901T220000Z 4049 LOCATION:Building 32, Microsoft, Seattle, WA 4050 DTSTAMP:19970526T083000Z 4051 STATUS:CONFIRMED 4052 END:VEVENT 4053 END:VCALENDAR 4055 4.4.6. Add A New Instance To A Recurring Event 4057 This example adds a one-time additional instance to the recurring 4058 event. "Organizer" adds a second July meeting on the 15th. 4060 BEGIN:VCALENDAR 4061 METHOD:ADD 4062 PRODID:-//RDU Software//NONSGML HandCal//EN 4063 VERSION:2.0 4064 BEGIN:VEVENT 4065 UID:123456789@host1.com 4066 SEQUENCE:4 4067 ORGANIZER:Mailto:A@example.com 4068 ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:Mailto:A@example.com 4069 ATTENDEE;RSVP=TRUE:Mailto:B@example.com 4070 ATTENDEE;RSVP=TRUE:Mailto:C@example.com 4071 ATTENDEE;RSVP=TRUE:Mailto:D@example.com 4072 DESCRIPTION:IETF-C&S Conference Call 4073 CLASS:PUBLIC 4074 SUMMARY:IETF Calendaring Working Group Meeting 4075 DTSTART:19970715T210000Z 4076 DTEND:19970715T220000Z 4077 LOCATION:Conference Call 4078 DTSTAMP:19970629T093000Z 4079 STATUS:CONFIRMED 4080 END:VEVENT 4081 END:VCALENDAR 4083 4.4.7. Add A New Series of Instances To A Recurring Event 4085 The scenario for this example involves an ongoing meeting, originally 4086 set up to occur every Tuesday. The "Organizer" later decides that 4087 the meetings need to be on Tuesdays and Thursdays, but does not want 4088 to reschedule the entire meeting or lose any of the per-instance 4089 information already collected. 4091 The original event: 4093 BEGIN:VCALENDAR 4094 METHOD:REQUEST 4095 PRODID:-//RDU Software//NONSGML HandCal//EN 4096 VERSION:2.0 4097 BEGIN:VEVENT 4098 UID:123456789@host1.com 4099 SEQUENCE:0 4100 RRULE:WKST=SU;BYDAY=TU;FREQ=WEEKLY 4101 ORGANIZER:Mailto:A@example.com 4102 ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:Mailto:A@example.com 4103 ATTENDEE;RSVP=TRUE:Mailto:B@example.com 4104 SUMMARY:Review Accounts 4105 DTSTART:19980303T210000Z 4106 DTEND:19980303T220000Z 4107 LOCATION:The White Room 4108 DTSTAMP:19980301T093000Z 4109 STATUS:CONFIRMED 4110 END:VEVENT 4111 END:VCALENDAR 4113 Assume that many other updates happen to this event and that a lot of 4114 instance-specific information exists in the recurring series. The 4115 "SEQUENCE" property value is 7 for the next update. Now the 4116 "Organizer" wants to add Thursdays to the event: 4118 BEGIN:VCALENDAR 4119 METHOD:ADD 4120 PRODID:-//RDU Software//NONSGML HandCal//EN 4121 VERSION:2.0 4122 BEGIN:VEVENT 4123 UID:123456789@host1.com 4124 SEQUENCE:7 4125 RRULE:WKST=SU;BYDAY=TH;FREQ=WEEKLY 4126 ORGANIZER:Mailto:A@example.com 4127 ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:Mailto:A@example.com 4128 ATTENDEE;RSVP=TRUE:Mailto:B@example.com 4129 SUMMARY:Review Accounts 4130 DTSTART:19980303T210000Z 4131 DTEND:19980303T220000Z 4132 DTSTAMP:19980303T193000Z 4133 LOCATION:The Usual conference room 4134 STATUS:CONFIRMED 4135 END:VEVENT 4136 END:VCALENDAR 4138 Alternatively, if the "Organizer" is not concerned with per-instance 4139 updates, the entire event can be rescheduled using a "REQUEST". This 4140 is done by using the "UID" of the event to reschedule and including 4141 the modified "RRULE". Note, that since this is an entire 4142 rescheduling of the event, any instance-specific information will be 4143 lost. 4145 BEGIN:VCALENDAR 4146 METHOD:REQUEST 4147 PRODID:-//RDU Software//NONSGML HandCal//EN 4148 VERSION:2.0 4149 BEGIN:VEVENT 4150 UID:123456789@host1.com 4151 SEQUENCE:7 4152 RRULE:WKST=SU;BYDAY=TU,TH;FREQ=WEEKLY 4153 ORGANIZER:Mailto:A@example.com 4154 ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:Mailto:A@example.com 4155 ATTENDEE;RSVP=TRUE:Mailto:B@example.com 4156 SUMMARY:Review Accounts 4157 DTSTART:19980303T210000Z 4158 DTEND:19980303T220000Z 4159 DTSTAMP:19980303T193000Z 4160 LOCATION:The White Room 4161 STATUS:CONFIRMED 4162 END:VEVENT 4163 END:VCALENDAR 4165 The next series of examples illustrate how an "Organizer" would 4166 respond to a "REFRESH" submitted by an "Attendee" after a series of 4167 instance-specific modifications. To convey all instance-specific 4168 changes, the "Organizer" must provide the latest event description 4169 and the relevant instances. The first three examples show the 4170 history including the initial "VEVENT" request and subsequent 4171 instance changes and finally the "REFRESH". 4173 Original Request: 4175 BEGIN:VCALENDAR 4176 METHOD:REQUEST 4177 PRODID:-//RDU Software//NONSGML HandCal//EN 4178 VERSION:2.0 4179 BEGIN:VEVENT 4180 UID:123456789@host1.com 4181 SEQUENCE:0 4182 RDATE:19980304T180000Z 4183 RDATE:19980311T180000Z 4184 RDATE:19980318T180000Z 4185 ORGANIZER:Mailto:A@example.com 4186 ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:Mailto:A@example.com 4187 ATTENDEE;RSVP=TRUE:Mailto:B@example.com 4188 SUMMARY:Review Accounts 4189 DTSTART:19980304T180000Z 4190 DTEND:19980304T200000Z 4191 DTSTAMP:19980303T193000Z 4192 LOCATION:Conference Room A 4193 STATUS:CONFIRMED 4194 END:VEVENT 4195 END:VCALENDAR 4197 Organizer changes 2nd instance Location and Time: 4199 BEGIN:VCALENDAR 4200 METHOD:REQUEST 4201 PRODID:-//RDU Software//NONSGML HandCal//EN 4202 VERSION:2.0 4203 BEGIN:VEVENT 4204 UID:123456789@host1.com 4205 SEQUENCE:1 4206 RECURRENCE-ID:19980311T180000Z 4207 ORGANIZER:Mailto:A@example.com 4208 ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:Mailto:A@example.com 4209 ATTENDEE;RSVP=TRUE:Mailto:B@example.com 4210 SUMMARY:Review Accounts 4211 DTSTART:19980311T160000Z 4212 DTEND:19980311T180000Z 4213 DTSTAMP:19980306T193000Z 4214 LOCATION:The Small conference room 4215 STATUS:CONFIRMED 4216 END:VEVENT 4217 END:VCALENDAR 4219 Organizer adds a 4th instance of the meeting using the "ADD" method 4220 BEGIN:VCALENDAR 4221 METHOD:ADD 4222 PRODID:-//RDU Software//NONSGML HandCal//EN 4223 VERSION:2.0 4224 BEGIN:VEVENT 4225 UID:123456789@host1.com 4226 SEQUENCE:2 4227 ORGANIZER:Mailto:A@example.com 4228 ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:Mailto:A@example.com 4229 ATTENDEE;RSVP=TRUE:Mailto:B@example.com 4230 SUMMARY:Review Accounts 4231 DTSTART:19980315T180000Z 4232 DTEND:19980315T200000Z 4233 DTSTAMP:19980307T193000Z 4234 LOCATION:Conference Room A 4235 STATUS:CONFIRMED 4236 END:VEVENT 4237 END:VCALENDAR 4239 If "B" requests a "REFRESH", "A" responds with the following to 4240 capture all instance-specific data. In this case both the initial 4241 request and an additional "VEVENT" that specifies the instance- 4242 specific data are included. Because these are both of the same type 4243 (they are both "VEVENTS"), they can be conveyed in the same iCalendar 4244 object. 4246 BEGIN:VCALENDAR 4247 METHOD:REQUEST 4248 PRODID:-//RDU Software//NONSGML HandCal//EN 4249 VERSION:2.0 4250 BEGIN:VEVENT 4251 UID:123456789@host1.com 4252 SEQUENCE:2 4253 RDATE:19980304T180000Z 4254 RDATE:19980311T160000Z 4255 RDATE:19980315T180000Z 4256 Error! Bookmark not defined. 4257 ORGANIZER:Mailto:A@example.com 4258 ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:Mailto:A@example.com 4259 ATTENDEE;RSVP=TRUE:Mailto:B@example.com 4260 SUMMARY:Review Accounts 4261 DTSTART:19980304T180000Z 4262 DTEND:19980304T200000Z 4263 DTSTAMP:19980303T193000Z 4264 LOCATION:Conference Room A 4265 STATUS:CONFIRMED 4266 END:VEVENT 4267 BEGIN:VEVENT 4268 Error! Bookmark not defined. 4269 SEQUENCE:2 4270 RECURRENCE-ID:19980311T160000Z 4271 Error! Bookmark not defined. 4272 ATTENDEE;ROLE=CHAIR;Error! Bookmark not defined. 4273 ATTENDEE;Error! Bookmark not defined. 4274 SUMMARY:Review Accounts 4275 DTSTART:19980311T160000Z 4276 DTEND:19980304T180000Z 4277 DTSTAMP:19980306T193000Z 4278 LOCATION:The Small conference room 4279 STATUS:CONFIRMED 4280 END:VEVENT 4281 END:VCALENDAR 4283 4.4.8. Counter An Instance Of A Recurring Event 4285 In this example one of the "Attendees" counters the "DTSTART" 4286 property of the proposed second July meeting. 4288 BEGIN:VCALENDAR 4289 METHOD:COUNTER 4290 PRODID:-//RDU Software//NONSGML HandCal//EN 4291 VERSION:2.0 4292 BEGIN:VEVENT 4293 UID:guid-1@host1.com 4294 RECURRENCE-ID:19970715T210000Z 4295 SEQUENCE:4 4296 ORGANIZER:Mailto:A@example.com 4297 ATTENDEE;ROLE=CHAIR;RSVP=TRUE:Mailto:A@example.com 4298 ATTENDEE;RSVP=TRUE:Mailto:B@example.com 4299 ATTENDEE;RSVP=TRUE:Mailto:C@example.com 4300 ATTENDEE;RSVP=TRUE:Mailto:D@example.com 4301 DESCRIPTION:IETF-C&S Conference Call 4302 CLASS:PUBLIC 4303 SUMMARY:IETF Calendaring Working Group Meeting 4304 DTSTART:19970715T220000Z 4305 DTEND:19970715T230000Z 4306 LOCATION:Conference Call 4307 COMMENT:May we bump this by an hour? I have a conflict 4308 DTSTAMP:19970629T094000Z 4309 END:VEVENT 4310 END:VCALENDAR 4312 4.4.9. Error Reply To A Request 4314 The following example illustrates a scenario where a meeting is 4315 proposed containing an unsupported property and a bad property. 4317 Original Request 4318 BEGIN:VCALENDAR 4319 METHOD:REQUEST 4320 PRODID:-//RDU Software//NONSGML HandCal//EN 4321 VERSION:2.0 4322 BEGIN:VEVENT 4323 UID:guid-1@host1.com 4324 SEQUENCE:0 4325 RRULE:FREQ=MONTHLY;BYMONTHDAY=1 4326 ORGANIZER:Mailto:A@example.com 4327 ATTENDEE;ROLE=CHAIR:Mailto:A@example.com 4328 ATTENDEE;RSVP=TRUE:Mailto:B@example.com 4329 ATTENDEE;RSVP=TRUE:Mailto:C@example.com 4330 ATTENDEE;RSVP=TRUE:Mailto:D@example.com 4331 DESCRIPTION:IETF-C&S Conference Call 4332 CLASS:PUBLIC 4333 SUMMARY:IETF Calendaring Working Group Meeting 4334 DTSTART:19970601T210000Z 4335 DTEND:19970601T220000Z 4336 DTSTAMP:19970602T094000Z 4337 LOCATION:Conference Call 4338 STATUS:CONFIRMED 4339 FOO:BAR 4340 END:VEVENT 4341 END:VCALENDAR 4343 Response from "B" to indicate that RRULE is not supported and an 4344 unrecognized property was encountered 4346 BEGIN:VCALENDAR 4347 PRODID:-//RDU Software//NONSGML HandCal//EN 4348 METHOD:REPLY 4349 VERSION:2.0 4350 BEGIN:VEVENT 4351 ORGANIZER:Mailto:A@example.com 4352 ATTENDEE:Mailto:B@example.com 4353 REQUEST-STATUS:2.8;Repeating event ignored. Scheduled as a single 4354 event;RRULE 4355 REQUEST-STATUS:3.0;Invalid Property Name;FOO 4356 UID:guid-1@host1.com 4357 SEQUENCE:0 4358 DTSTAMP:19970603T094000Z 4359 END:VEVENT 4360 END:VCALENDAR 4362 4.5. Group To-do Examples 4364 Individual "A" creates a group task in which individuals "A", "B", 4365 "C" and "D" will participate. Individual "B" confirms acceptance of 4366 the task. Individual "C" declines the task. Individual "D" 4367 tentatively accepts the task. The following table illustrates the 4368 sequence of messages that would be exchanged between these 4369 individuals. Individual "A" then issues a "REQUEST" method to obtain 4370 the status of the to-do from each participant. The response 4371 indicates the individual "Attendee's" completion status. The table 4372 below illustrates the message flow. 4374 +-------------+-----------------------+-----------------------------+ 4375 | Action | "Organizer" | Attendee | 4376 +-------------+-----------------------+-----------------------------+ 4377 | Initiate a | "A" sends a REQUEST | | 4378 | to-do | message to "B", "C", | | 4379 | request | and "D" | | 4380 | | | | 4381 | Accept the | | "B" sends a "REPLY" message | 4382 | to-do | | to "A" with its "partstat" | 4383 | request | | parameter set to | 4384 | | | "accepted". | 4385 | | | | 4386 | Decline the | | "C" sends a REPLY message | 4387 | to-do | | to "A" with its "partstat" | 4388 | request | | parameter set to | 4389 | | | "declined". | 4390 | | | | 4391 | Tentatively | | "D" sends a REPLY message | 4392 | accept the | | to "A" with its "partstat" | 4393 | to-do | | parameter set to | 4394 | request | | "tentative". | 4395 | | | | 4396 | Check | "A" sends a REQUEST | | 4397 | attendee | message to "B" and | | 4398 | completion | "D" with current | | 4399 | status | information. | | 4400 | | | | 4401 | Attendee | | "B" sends a "REPLY" message | 4402 | indicates | | indicating percent complete | 4403 | percent | | | 4404 | complete | | | 4405 | | | | 4406 | Attendee | | "D" sends a "REPLY" message | 4407 | indicates | | indicating completion | 4408 | completion | | | 4409 +-------------+-----------------------+-----------------------------+ 4411 4.5.1. A VTODO Request 4413 A sample "REQUEST" for a "VTODO" calendar component that "A" sends to 4414 "B", "C", and "D". 4416 BEGIN:VCALENDAR 4417 PRODID:-//ACME/DesktopCalendar//EN 4418 METHOD:REQUEST 4419 VERSION:2.0 4420 BEGIN:VTODO 4421 ORGANIZER:Mailto:A@example.com 4422 ATTENDEE;ROLE=CHAIR:Mailto:A@example.com 4423 ATTENDEE;RSVP=TRUE:Mailto:B@example.com 4424 ATTENDEE;RSVP=TRUE:Mailto:C@example.com 4425 ATTENDEE;RSVP=TRUE:Mailto:D@example.com 4426 DTSTART:19970701T170000Z 4427 DUE:19970722T170000Z 4428 PRIORITY:1 4429 SUMMARY:Create the requirements document 4430 UID:calsrv.example.com-873970198738777-00@example.com 4431 SEQUENCE:0 4432 DTSTAMP:19970717T200000Z 4433 STATUS:Needs Action 4434 END:VTODO 4435 END:VCALENDAR 4437 4.5.2. A VTODO Reply 4439 "B" accepts the to-do. 4441 BEGIN:VCALENDAR 4442 PRODID:-//ACME/DesktopCalendar//EN 4443 METHOD:REPLY 4444 VERSION:2.0 4445 BEGIN:VTODO 4446 ORGANIZER:Mailto:A@example.com 4447 ATTENDEE;PARTSTAT=ACCEPTED:Mailto:B@example.com 4448 UID:calsrv.example.com-873970198738777-00@example.com 4449 COMMENT:I'll send you my input by e-mail 4450 SEQUENCE:0 4451 DTSTAMP:19970717T203000Z 4452 REQUEST-STATUS:2.0;Success 4453 END:VTODO 4454 END:VCALENDAR 4456 "B" could have declined the TODO or indicated tentative acceptance by 4457 setting the "partstat" property parameter sequence to "declined" or 4458 "tentative", respectively. 4460 4.5.3. A VTODO Request for Updated Status 4462 "A" requests status from all "Attendees". 4464 BEGIN:VCALENDAR 4465 PRODID:-//ACME/DesktopCalendar//EN 4466 METHOD:REQUEST 4467 VERSION:2.0 4468 BEGIN:VTODO 4469 ORGANIZER:Mailto:A@example.com 4470 ATTENDEE;ROLE=CHAIR:Mailto:A@example.com 4471 ATTENDEE;RSVP=TRUE;TYPE=INDIVIDUAL:Mailto:B@example.com 4472 ATTENDEE;RSVP=TRUE;TYPE=INDIVIDUAL:Mailto:D@example.com 4473 UID:calsrv.example.com-873970198738777-00@example.com 4474 SUMMARY:Create the requirements document 4475 PRIORITY:1 4476 SEQUENCE:0 4477 STATUS:IN-PROCESS 4478 DTSTART:19970701T170000Z 4479 DTSTAMP:19970717T230000Z 4480 END:VTODO 4481 END:VCALENDAR 4483 4.5.4. A Reply: Percent-Complete 4485 A reply indicating the task being worked on and that "B" is 75% 4486 complete with "B's" part of the assignment. 4488 BEGIN:VCALENDAR 4489 PRODID:-//ACME/DesktopCalendar//EN 4490 METHOD:REPLY 4491 VERSION:2.0 4492 BEGIN:VTODO 4493 ORGANIZER:MAILTO:A@example.com 4494 ATTENDEE;PARTSTAT=IN-PROCESS:Mailto:B@example.com 4495 PERCENT-COMPLETE:75 4496 UID:calsrv.example.com-873970198738777-00@example.com 4497 DTSTAMP:19970717T233000Z 4498 SEQUENCE:0 4499 END:VTODO 4500 END:VCALENDAR 4502 4.5.5. A Reply: Completed 4504 A reply indicating that "D" completed "D's" part of the assignment. 4506 BEGIN:VCALENDAR 4507 PRODID:-//ACME/DesktopCalendar//EN 4508 METHOD:REPLY 4509 VERSION:2.0 4510 BEGIN:VTODO 4511 ORGANIZER:MAILTO:A@example.com 4512 ATTENDEE;PARTSTAT=COMPLETED:Mailto:D@example.com 4513 UID:calsrv.example.com-873970198738777-00@example.com 4514 DTSTAMP:19970717T233000Z 4515 SEQUENCE:0 4516 END:VTODO 4517 END:VCALENDAR 4519 4.5.6. An Updated VTODO Request 4521 Organizer "A" resends the "VTODO" calendar component. "A" sets the 4522 overall completion for the to-do at 40%. 4524 BEGIN:VCALENDAR 4525 PRODID:-//ACME/DesktopCalendar//EN 4526 METHOD:REQUEST 4527 VERSION:2.0 4528 BEGIN:VTODO 4529 ORGANIZER:Mailto:A@example.com 4530 ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:Mailto:A@example.com 4531 ATTENDEE;PARTSTAT=ACCEPTED;TYPE=INDIVIDUAL:Mailto:B@example.com 4532 ATTENDEE;PARTSTAT=IN-PROCESS;TYPE=INDIVIDUAL:Mailto:D@example.com 4533 DTSTART:19970701T170000Z 4534 DUE:19970722T170000Z 4535 PRIORITY:1 4536 SUMMARY:Create the requirements document 4537 UID:calsrv.example.com-873970198738777-00@example.com 4538 SEQUENCE:1 4539 DTSTAMP:19970718T100000Z 4540 STATUS:IN-PROGRESS 4541 PERCENT-COMPLETE:40 4542 END:VTODO 4543 END:VCALENDAR 4545 4.5.7. Recurring VTODOs 4547 The following examples relate to recurring "VTODO" calendar 4548 components. 4550 4.5.7.1. Request for a Recurring VTODO 4552 In this example "A" sends a recurring "VTODO" calendar component to 4553 "B" and "D". 4555 BEGIN:VCALENDAR 4556 PRODID:-//ACME/DesktopCalendar//EN 4557 METHOD:REQUEST 4558 VERSION:2.0 4559 BEGIN:VTODO 4560 ORGANIZER:Mailto:A@example.com 4561 ATTENDEE;ROLE=CHAIR:Mailto:A@example.com 4562 ATTENDEE;RSVP=TRUE;TYPE=INDIVIDUAL:Mailto:B@example.com 4563 ATTENDEE;RSVP=TRUE;TYPE=INDIVIDUAL:Mailto:D@example.com 4564 RRULE:FREQ=MONTHLY;COUNT=10;BYDAY=1FR 4565 DTSTART:19980101T100000-0700 4566 DUE:19980103T100000-0700 4567 SUMMARY:Send Status Reports to Area Managers 4568 UID:calsrv.example.com-873970198738777-00@example.com 4569 SEQUENCE:0 4570 DTSTAMP:19970717T200000Z 4571 STATUS:NEEDS ACTION 4572 PRIORITY:1 4573 END:VTODO 4574 END:VCALENDAR 4576 4.5.7.2. Calculating due dates in recurring VTODOs 4578 The due date in a recurring "VTODO" calendar component is either a 4579 fixed interval specified in the "REQUEST" method or specified using 4580 the "RECURRENCE-ID" property. The former is calculated by applying 4581 the difference between "DTSTART" and "DUE" properties and applying it 4582 to each of the start of each recurring instance. Hence, if the 4583 initial "VTODO" calendar component specifies a "DTSTART" property 4584 value of "19970701T190000Z" and a "DUE" property value of 4585 "19970801T190000Z" the interval of one day which is applied to each 4586 recurring instance of the "VTODO" calendar component to determine the 4587 "DUE" date of the instance. 4589 4.5.7.3. Replying to an instance of a recurring VTODO 4591 In this example "B" updates "A" on a single instance of the "VTODO" 4592 calendar component. 4594 BEGIN:VCALENDAR 4595 PRODID:-//ACME/DesktopCalendar//EN 4596 METHOD:REPLY 4597 VERSION:2.0 4598 BEGIN:VTODO 4599 ATTENDEE;PARTSTAT=IN-PROCESS:Mailto:B@example.com 4600 PERCENT-COMPLETE:75 4601 UID:calsrv.example.com-873970198738777-00@example.com 4602 DTSTAMP:19970717T233000Z 4603 RECURRENCE-ID:19980101T170000Z 4604 SEQUENCE:1 4605 END:VTODO 4606 END:VCALENDAR 4608 4.6. Journal Examples 4610 The iCalendar object below describes a single journal entry for 4611 October 2, 1997. The "RELATED-TO" property references the phone 4612 conference event for which minutes were taken. 4614 BEGIN:VCALENDAR 4615 METHOD:PUBLISH 4616 PRODID:-//ACME/DesktopCalendar//EN 4617 VERSION:2.0 4618 BEGIN:VJOURNAL 4619 DTSTART:19971002T200000Z 4620 ORGANIZER:MAILTO:A@Example.com 4621 SUMMARY:Phone conference minutes 4622 DESCRIPTION:The editors meeting was held on October 1, 1997. 4623 Details are in the attached document. 4624 UID:0981234-1234234-2410@example.com 4625 RELATED-TO:0981234-1234234-2402-35@example.com 4626 ATTACH:ftp://ftp.example.com/pub/ed/minutes100197.txt 4627 END:VJOURNAL 4628 END:VCALENDAR 4630 4.7. Other Examples 4632 4.7.1. Event Refresh 4634 Refresh the event with "UID" property value of "guid-1- 4635 12345@host1.com": 4637 BEGIN:VCALENDAR 4638 PRODID:-//RDU Software//NONSGML HandCal//EN 4639 METHOD:REFRESH 4640 VERSION:2.0 4641 BEGIN:VEVENT 4642 ORGANIZER:Mailto:A@example.com 4643 ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:Mailto:A@example.com 4644 ATTENDEE:Mailto:B@example.com 4645 ATTENDEE:Mailto:C@example.com 4646 ATTENDEE:Mailto:D@example.com 4647 UID: guid-1-12345@host1.com 4648 DTSTAMP:19970603T094000 4649 END:VEVENT 4650 END:VCALENDAR 4652 4.7.2. Bad RECURRENCE-ID 4654 Component instances are identified by the combination of "UID", 4655 "RECURRENCE-ID", and "SEQUENCE". When an "Organizer" sends a request 4656 to an "Attendee", there are three cases in which an instance cannot 4657 be found. They are: 4659 1. The component with the referenced "UID" and "RECURRENCE-ID" has 4660 been found but the "SEQUENCE" number in the calendar store does 4661 not match that of the ITIP message. 4663 2. The component with the referenced "UID" has been found, the 4664 "SEQUENCE" numbers match, but the "RECURRENCE-ID" cannot be 4665 found. 4667 3. The "UID" and "SEQUENCE" numbers are found but the CUA does not 4668 support recurrences. 4670 In case (1), two things can happen. If the "SEQUENCE" number of the 4671 "Attendee's" instance is larger than that in the "Organizer's" 4672 message then the "Attendee" is receiving an out-of-sequence message 4673 and MUST ignore it. If the "SEQUENCE" number of the "Attendee's" 4674 instance is smaller, then the "Organizer" is sending out a newer 4675 version of the component and the "Attendee's" version needs to be 4676 updated. Since one or more updates have been missed, the "Attendee" 4677 SHOULD send a "REFRESH" message to the "Organizer" to get an updated 4678 version of the event. 4680 In case (2), something has gone wrong. Both the "Organizer" and the 4681 "Attendee" should have the same instances, but the "Attendee" does 4682 not have the referenced instance. In this case the "Attendee" SHOULD 4683 send a "REFRESH" to the "Organizer" to get an updated version of the 4684 event. 4686 In case (3), the limitations of the "Attendee's" CUA makes it 4687 impossible to match an instance other than the single instance 4688 scheduled. In this case, the "Attendee" need not send a "REFRESH" to 4689 the "Organizer". 4691 The example below shows a sequence in which an "Attendee" sends a 4692 "REFRESH" to the "Organizer". 4694 +--------------------------+-------------------+--------------------+ 4695 | Action | "Organizer" | Attendee | 4696 +--------------------------+-------------------+--------------------+ 4697 | Update an instance | "A" sends | | 4698 | request | "REQUEST" message | | 4699 | | to "B" | | 4700 | | | | 4701 | Attendee requests | | "B" sends a | 4702 | refresh because | | "REFRESH" message | 4703 | "RECURRENCE-ID" was not | | to "A" | 4704 | found | | | 4705 | | | | 4706 | Refresh the entire Event | "A" sends the | | 4707 | | latest copy of | | 4708 | | the Event to "B" | | 4709 | | | | 4710 | Attendee handles the | | "B" updates to the | 4711 | request and updates the | | latest copy of the | 4712 | instance | | meeting. | 4713 +--------------------------+-------------------+--------------------+ 4715 Request from "A": 4717 BEGIN:VCALENDAR 4718 METHOD:REQUEST 4719 PRODID:-//RDU Software//NONSGML HandCal//EN 4720 VERSION:2.0 4721 BEGIN:VEVENT 4722 UID:acme-12345@host1.com 4723 SEQUENCE:3 4724 RRULE:FREQ=WEEKLY 4725 RDATE;VALUE=PERIOD:19970819T210000Z/199700819T220000Z 4726 ORGANIZER:Mailto:A@example.com 4727 ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:Mailto:A@example.com 4728 ATTENDEE:Mailto:B@example.com 4729 DESCRIPTION:IETF-C&S Conference Call 4730 SUMMARY:IETF Calendaring Working Group Meeting 4731 DTSTART:19970801T210000Z 4732 DTEND:19970801T220000Z 4733 RECURRENCE-ID:19970809T210000Z 4734 DTSTAMP:19970726T083000 4735 STATUS:CONFIRMED 4736 END:VEVENT 4737 END:VCALENDAR 4739 "B" has the event with "UID" property "acme-12345@host1.com" but 4740 "B's" "SEQUENCE" property value is "1" and the event does not have an 4741 instance at the specified recurrence time. This means that "B" has 4742 missed at least one update and needs a new copy of the event. "B" 4743 requests the latest copy of the event with the following refresh 4744 message: 4746 BEGIN:VCALENDAR 4747 PRODID:-//RDU Software//NONSGML HandCal//EN 4748 METHOD:REFRESH 4749 VERSION:2.0 4750 BEGIN:VEVENT 4751 ORGANIZER:Mailto:A@example.com 4752 ATTENDEE:Mailto:B@example.com 4753 UID:acme-12345@host1.com 4754 DTSTAMP:19970603T094000 4755 END:VEVENT 4756 END:VCALENDAR 4758 5. Application Protocol Fallbacks 4760 5.1. Partial Implementation 4762 Applications that support this memo are not required to support the 4763 entire protocol. The following describes how methods and properties 4764 SHOULD "fallback" in applications that do not support the complete 4765 protocol. If a method or property is not addressed in this section, 4766 it may be ignored. 4768 5.1.1. Event-Related Fallbacks 4770 +----------------+--------------------------------------------------+ 4771 | Method | Fallback | 4772 +----------------+--------------------------------------------------+ 4773 | PUBLISH | Required | 4774 | REQUEST | PUBLISH | 4775 | REPLY | Required | 4776 | ADD | Required | 4777 | CANCEL | Required | 4778 | REFRESH | Required | 4779 | COUNTER | Reply with Not Supported | 4780 | DECLINECOUNTER | Required if EVENT-COUNTER is implemented; | 4781 | | otherwise reply with Not Supported | 4782 +----------------+--------------------------------------------------+ 4784 +-----------------+-------------------------------------------------+ 4785 | iCalendar | Fallback | 4786 | Property | | 4787 +-----------------+-------------------------------------------------+ 4788 | CALSCALE | Ignore; assume GREGORIAN | 4789 | PRODID | Ignore | 4790 | METHOD | Required as described in the Method list above | 4791 | VERSION | Ignore | 4792 +-----------------+-------------------------------------------------+ 4794 +-----------------+-------------------------------------------------+ 4795 | Event-Related | Fallback | 4796 | Components | | 4797 +-----------------+-------------------------------------------------+ 4798 | VALARM | Reply with Not Supported | 4799 | VTIMEZONE | Required if any DateTime value refers to a time | 4800 | | zone. | 4801 +-----------------+-------------------------------------------------+ 4802 +-----------------+-------------------------------------------------+ 4803 | Component | Fallback | 4804 | Property | | 4805 +-----------------+-------------------------------------------------+ 4806 | ATTACH | Ignore | 4807 | ATTENDEE | Required if EVENT-REQUEST is not implemented; | 4808 | | otherwise reply with Not Supported | 4809 | CATEGORIES | Ignore | 4810 | CLASS | Ignore | 4811 | COMMENT | Ignore | 4812 | COMPLETED | Ignore | 4813 | CONTACT | Ignore | 4814 | CREATED | Ignore | 4815 | DESCRIPTION | Required | 4816 | DURATION | Reply with Not Supported | 4817 | DTSTAMP | Required | 4818 | DTSTART | Required | 4819 | DTEND | Required | 4820 | EXDATE | Ignore | 4821 | EXRULE | Ignore Reply with Not Supported. If | 4822 | | implemented, VTIMEZONE MUST also be | 4823 | | implemented. | 4824 | GEO | Ignore | 4825 | LAST-MODIFIED | Ignore | 4826 | LOCATION | Required | 4827 | ORGANIZER | Ignore | 4828 | PRIORITY | Ignore | 4829 | RELATED-TO | Ignore | 4830 | RDATE | Ignore | 4831 | RRULE | Ignore. The first instance occurs on the | 4832 | | DTStart property. If implemented, VTIMEZONE | 4833 | | MUST also be implemented. | 4834 | RECURRENCE-ID | Required if RRULE is implemented; otherwise | 4835 | | Ignore | 4836 | REQUEST-STATUS | Required | 4837 | RESOURCES | Ignore | 4838 | SEQUENCE | Required | 4839 | STATUS | Ignore | 4840 | SUMMARY | Ignore | 4841 | TRANSP | Required if FREEBUSY is implemented; otherwise | 4842 | | Ignore | 4843 | URL | Ignore | 4844 | UID | Required | 4845 | X- | Ignore | 4846 +-----------------+-------------------------------------------------+ 4848 5.1.2. Free/Busy-Related Fallbacks 4850 +---------+---------------------------------------------------------+ 4851 | Method | Fallback | 4852 +---------+---------------------------------------------------------+ 4853 | PUBLISH | Implementations MAY ignore the METHOD type. The | 4854 | | REQUEST-STATUS "3.14;Unsupported capability" MUST be | 4855 | | returned. | 4856 | REQUEST | Implementations MAY ignore the METHOD type. The | 4857 | | REQUEST-STATUS "3.14;Unsupported capability" MUST be | 4858 | | returned. | 4859 | REPLY | Implementations MAY ignore the METHOD type. The | 4860 | | REQUEST-STATUS "3.14;Unsupported capability" MUST be | 4861 | | returned. | 4862 +---------+---------------------------------------------------------+ 4864 +-----------------+-------------------------------------------------+ 4865 | iCalendar | Fallback | 4866 | Property | | 4867 +-----------------+-------------------------------------------------+ 4868 | CALSCALE | Ignore; assume GREGORIAN. | 4869 | PRODID | Ignore | 4870 | METHOD | Required as described in the Method list above. | 4871 | VERSION | Ignore | 4872 +-----------------+-------------------------------------------------+ 4874 +-----------------+-------------------------------------------------+ 4875 | Component | Fallback | 4876 | Property | | 4877 +-----------------+-------------------------------------------------+ 4878 | COMMENT | Ignore | 4879 | CONTACT | Ignore | 4880 | DTEND | Required | 4881 | DTSTAMP | Required | 4882 | DTSTART | Required | 4883 | DURATION | Required | 4884 | FREEBUSY | Required | 4885 | ORGANIZER | Ignore | 4886 | REQUEST-STATUS | Ignore | 4887 | UID | Required | 4888 | URL | Ignore | 4889 | X- | Ignore | 4890 +-----------------+-------------------------------------------------+ 4892 5.1.3. To-Do-Related Fallbacks 4894 +----------------+--------------------------------------------------+ 4895 | Method | Fallback | 4896 +----------------+--------------------------------------------------+ 4897 | PUBLISH | Required | 4898 | REQUEST | PUBLISH | 4899 | REPLY | Required | 4900 | ADD | Required | 4901 | CANCEL | Required | 4902 | REFRESH | Required | 4903 | COUNTER | Reply with Not Supported | 4904 | DECLINECOUNTER | Required if VTODO - COUNTER is implemented; | 4905 | | otherwise reply with Not Supported | 4906 +----------------+--------------------------------------------------+ 4908 +-----------------+-------------------------------------------------+ 4909 | iCalendar | Fallback | 4910 | Property | | 4911 +-----------------+-------------------------------------------------+ 4912 | CALSCALE | Ignore; assume GREGORIAN. | 4913 | PRODID | Ignore | 4914 | METHOD | Required as described in the Method list above. | 4915 | VERSION | Ignore | 4916 +-----------------+-------------------------------------------------+ 4918 +-----------------+-------------------------------------------------+ 4919 | To-Do-Related | Fallback | 4920 | Components | | 4921 +-----------------+-------------------------------------------------+ 4922 | VALARM | Reply with Not Supported | 4923 | VTIMEZONE | Required if any DateTime value refers to a time | 4924 | | zone. | 4925 +-----------------+-------------------------------------------------+ 4926 +------------------+------------------------------------------------+ 4927 | Component | Fallback | 4928 | Property | | 4929 +------------------+------------------------------------------------+ 4930 | ATTACH | Ignore | 4931 | ATTENDEE | Required if REQUEST is not implemented; | 4932 | | otherwise ignore | 4933 | CATEGORIES | Ignore | 4934 | CLASS | Ignore | 4935 | COMMENT | Ignore | 4936 | COMPLETED | Required | 4937 | CONTACT | Ignore | 4938 | CREATED | Ignore | 4939 | DESCRIPTION | Required | 4940 | DUE | Required | 4941 | DURATION | Ignore Reply with Not Supported | 4942 | DTSTAMP | Required | 4943 | DTSTART | Required | 4944 | EXDATE | Ignore Reply with Not Supported | 4945 | EXRULE | Ignore Reply with Not Supported. If | 4946 | | implemented, VTIMEZONE MUST also be | 4947 | | implemented. | 4948 | LAST-MODIFIED | Ignore | 4949 | LOCATION | Ignore | 4950 | ORGANIZER | Ignore | 4951 | PERCENT-COMPLETE | Ignore | 4952 | PRIORITY | Required | 4953 | RECURRENCE-ID | Ignore | 4954 | RELATED-TO | Ignore | 4955 | REQUEST-STATUS | Ignore | 4956 | RDATE | Ignore | 4957 | RRULE | Ignore. The first instance occurs on the | 4958 | | DTSTART property. If implemented, VTIMEZONE | 4959 | | MUST also be implemented. | 4960 | RESOURCES | Ignore | 4961 | SEQUENCE | Required | 4962 | STATUS | Required | 4963 | SUMMARY | Ignore | 4964 | URL | Ignore | 4965 | UID | Required | 4966 | X- | Ignore | 4967 +------------------+------------------------------------------------+ 4969 5.1.4. Journal-Related Fallbacks 4971 +---------+---------------------------------------------------------+ 4972 | Method | Fallback | 4973 +---------+---------------------------------------------------------+ 4974 | PUBLISH | Implementations MAY ignore the METHOD type. The | 4975 | | REQUEST-STATUS "3.14;Unsupported capability" MUST be | 4976 | | returned. | 4977 | ADD | Implementations MAY ignore the METHOD type. The | 4978 | | REQUEST-STATUS "3.14;Unsupported capability" MUST be | 4979 | | returned. | 4980 | CANCEL | Implementations MAY ignore the METHOD type. The | 4981 | | REQUEST-STATUS "3.14;Unsupported capability" MUST be | 4982 | | returned. | 4983 +---------+---------------------------------------------------------+ 4985 +-----------------+-------------------------------------------------+ 4986 | iCalendar | Fallback | 4987 | Property | | 4988 +-----------------+-------------------------------------------------+ 4989 | CALSCALE | Ignore; assume GREGORIAN. | 4990 | PRODID | Ignore | 4991 | METHOD | Required as described in the Method list above. | 4992 | VERSION | Ignore | 4993 +-----------------+-------------------------------------------------+ 4995 +-----------------+-------------------------------------------------+ 4996 | Journal-Related | Fallback | 4997 | Components | | 4998 +-----------------+-------------------------------------------------+ 4999 | VTIMEZONE | Required if any DateTime value refers to a time | 5000 | | zone | 5001 +-----------------+-------------------------------------------------+ 5002 +-----------------+-------------------------------------------------+ 5003 | Component | Fallback | 5004 | Property | | 5005 +-----------------+-------------------------------------------------+ 5006 | ATTACH | Ignore | 5007 | ATTENDEE | Required if JOURNAL-REQUEST is implemented; | 5008 | | otherwise ignore | 5009 | CATEGORIES | Ignore | 5010 | CLASS | Ignore | 5011 | COMMENT | Ignore | 5012 | CONTACT | Ignore | 5013 | CREATED | Ignore | 5014 | DESCRIPTION | Required | 5015 | DTSTAMP | Required | 5016 | DTSTART | Required | 5017 | EXDATE | Ignore | 5018 | EXRULE | Ignore Reply with Not Supported. If | 5019 | | implemented, VTIMEZONE MUST also be | 5020 | | implemented. | 5021 | LAST-MODIFIED | Ignore | 5022 | ORGANIZER | Ignore | 5023 | RECURRENCE-ID | Ignore | 5024 | RELATED-TO | Ignore | 5025 | RDATE | Ignore. | 5026 | RRULE | Ignore. The first instance occurs on the | 5027 | | DTSTART property. If implemented, VTIMEZONE | 5028 | | MUST also be implemented. | 5029 | SEQUENCE | Required | 5030 | STATUS | Ignore | 5031 | SUMMARY | Required | 5032 | URL | Ignore | 5033 | UID | Required | 5034 | X- | Ignore | 5035 +-----------------+-------------------------------------------------+ 5037 5.2. Latency Issues 5039 With a store-and-forward transport, it is possible for events to 5040 arrive out of sequence. That is, a "CANCEL" method may be received 5041 prior to receiving the associated "REQUEST" for the calendar 5042 component. This section discusses a few of these scenarios. 5044 5.2.1. Cancellation of an Unknown Calendar Component. 5046 When a "CANCEL" method is received before the original "REQUEST" 5047 method the calendar will be unable to correlate the "UID" property of 5048 the cancellation with an existing calendar component. It is 5049 suggested that messages that can not be correlated that also contain 5050 non-zero sequence numbers be held and not discarded. Implementations 5051 MAY age them out if no other messages arrive with the same "UID" 5052 property value and a lower sequence number. 5054 5.2.2. Unexpected Reply from an Unknown Delegate 5056 When an "Attendee" delegates an item to another CU they MUST send a 5057 "REPLY" method to the "Organizer" using the "ATTENDEE" properties to 5058 indicate that the request was delegated and to whom. Hence, it is 5059 possible for an "Organizer" to receive an "REPLY" from a CU not 5060 listed as one of the original "Attendees". The resolution is left to 5061 the implementation but it is expected that the calendaring software 5062 will either accept the reply or hold it until the related "REPLY" 5063 method is received from the "Delegator". If the version of the 5064 "REPLY" method is out of date the "Organizer" SHOULD treat the 5065 message as a "REFRESH" message and update the delegate with the 5066 correct version. 5068 5.3. Sequence Number 5070 Under some conditions, a CUA may receive requests and replies with 5071 the same "SEQUENCE" property value. The "DTSTAMP" property is 5072 utilized as a tie-breaker when two items with the same "SEQUENCE" 5073 property value are evaluated. 5075 6. Security Considerations 5077 ITIP is an abstract transport protocol which will be bound to a real- 5078 time transport, a store-and-forward transport, and perhaps other 5079 transports. The transport protocol will be responsible for providing 5080 facilities for authentication and encryption using standard Internet 5081 mechanisms that are mutually understood between the sender and 5082 receiver. 5084 6.1. Security Threats 5086 6.1.1. Spoofing the "Organizer" 5088 In iTIP, the "Organizer" (or someone working on the "Organizer's" 5089 behalf) is the only person authorized to make changes to an existing 5090 "VEVENT", "VTODO", "VJOURNAL" calendar component and republish it or 5091 redistribute updates to the "Attendees". An iCalendar object that 5092 maliciously changes or cancels an existing "VEVENT", "VTODO" or 5093 "VJOURNAL" calendar component may be constructed by someone other 5094 than the "Organizer" and republished or sent to the "Attendees". 5096 6.1.2. Spoofing the "Attendee" 5098 In iTIP, an "Attendee" of a "VEVENT" or "VTODO" calendar component 5099 (or someone working on the "Attendee's" behalf) is the only person 5100 authorized to update any parameter associated with their "ATTENDEE" 5101 property and send it to the "Organizer". An iCalendar object that 5102 maliciously changes the "ATTENDEE" parameters may be constructed by 5103 someone other than the real "Attendee" and sent to the "Organizer". 5105 6.1.3. Unauthorized Replacement of the Organizer 5107 There will be circumstances when "Attendees" of an event or to-do 5108 decide, using out-of-band mechanisms, that the "Organizer" must be 5109 replaced. When the new "Organizer" sends out the updated "VEVENT" or 5110 "VTODO" the "Attendee's" CUA will detect that the "Organizer" has 5111 been changed, but it has no way of knowing whether or not the change 5112 was mutually agreed upon. 5114 6.1.4. Eavesdropping 5116 The iCalendar object is constructed with human-readable clear text. 5117 Any information contained in an iCalendar object may be read and/or 5118 changed by unauthorized persons while the object is in transit. 5120 6.1.5. Flooding a Calendar 5122 Implementations MAY provide a means to automatically incorporate 5123 "REQUEST" methods into a calendar. This presents the opportunity for 5124 a calendar to be flooded with requests, which effectively block all 5125 the calendar's free time. 5127 6.1.6. Procedural Alarms 5129 The "REQUEST" methods for "VEVENT" and "VTODO" calendar components 5130 MAY contain "VALARM" calendar components. The "VALARM" calendar 5131 component may be of type "PROCEDURE" and MAY have an attachment 5132 containing an executable program. Implementations that incorporate 5133 these types of alarms are subject to any virus or malicious attack 5134 that may occur as a result of executing the attachment. 5136 6.1.7. Unauthorized REFRESH Requests 5138 It is possible for an "Organizer" to receive a "REFRESH" request from 5139 someone who is not an "Attendee" of an event or to-do. Only 5140 "Attendee's" of an event or to-do are authorized to receive replies 5141 to "REFRESH" requests. Replying to such requests to anyone who is 5142 not an "Attendee" may be a security problem. 5144 6.2. Recommendations 5146 For an application where the information is sensitive or critical and 5147 the network is subject is subject to a high probability of attack, 5148 iTIP transactions SHOULD be encrypted. This may be accomplished 5149 using public key technology, specifically Security Multiparts for 5150 MIME [RFC1847] in the iTIP transport binding. This helps mitigate 5151 the threats of spoofing, eavesdropping and malicious changes in 5152 transit. 5154 6.2.1. Use of [RFC1847] to secure iTIP transactions 5156 iTIP transport bindings MUST provide a mechanism based on Security 5157 Multiparts for MIME [RFC1847] to enable authentication of the 5158 sender's identity, and privacy and integrity of the data being 5159 transmitted. This allows the receiver of a signed iCalendar object 5160 to verify the identity of the sender. This sender may then be 5161 correlated to an "ATTENDEE" property in the iCalendar object. If the 5162 correlation is made and the sender is authorized to make the 5163 requested change or update then the operation may proceed. It also 5164 allows the message to be encrypted to prevent unauthorized reading of 5165 the message contents in transit. iTIP transport binding documents 5166 describe this process in detail. 5168 Implementations MAY provide controls for users to disable this 5169 capability. 5171 6.2.2. Implementation Controls 5173 The threat of unauthorized replacement of the "Organizer" SHOULD be 5174 mitigated by a calendar system that uses this protocol by providing 5175 controls or alerts that make "Calendar Users" aware of such 5176 "Organizer" changes and allowing them to decide whether or not the 5177 request should be honored. 5179 The threat of flooding a calendar SHOULD be mitigated by a calendar 5180 system that uses this protocol by providing controls that may be used 5181 to limit the acceptable sources for iTIP transactions, and perhaps 5182 the size of messages and volume of traffic, by source. 5184 The threat of malicious procedural alarms SHOULD be mitigated by a 5185 calendar system that uses this protocol by providing controls that 5186 may be used to disallow procedural alarms in iTIP transactions and/or 5187 remove all alarms from the object before delivery to the recipient. 5189 The threat of unauthorized "REFRESH" requests SHOULD be mitigated by 5190 a calendar system that uses this protocol by providing controls or 5191 alerts that allow "Calendar User" to decide whether or not the 5192 request should be honored. An implementation MAY decide to maintain, 5193 for audit or historical purposes, "Calendar Users" who were part of 5194 an attendee list and who were subsequently uninvited. Similar 5195 controls or alerts should be provided when a "REFRESH" request is 5196 received from these "Calendar Users" as well. 5198 7. References 5200 7.1. Normative References 5202 [I-D.ietf-calsify-rfc2445bis] 5203 Desruisseaux, B., "Internet Calendaring and Scheduling 5204 Core Object Specification (iCalendar)", 5205 draft-ietf-calsify-rfc2445bis-01 (work in progress), 5206 June 2006. 5208 [I-D.ietf-calsify-rfc2447bis] 5209 Melnikov, A., "iCalendar Message-Based Interoperability 5210 Protocol(iMIP)", draft-ietf-calsify-rfc2447bis-02 (work in 5211 progress), June 2006. 5213 [RFC1847] Galvin, J., Murphy, S., Crocker, S., and N. Freed, 5214 "Security Multiparts for MIME: Multipart/Signed and 5215 Multipart/Encrypted", RFC 1847, October 1995. 5217 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 5218 Requirement Levels", BCP 14, RFC 2119, March 1997. 5220 [RFC2822] Resnick, P., "Internet Message Format", RFC 2822, 5221 April 2001. 5223 7.2. Informative References 5225 Appendix A. Acknowledgments 5227 This is an update to the original iTIP document authored by 5228 S.Silverberg, S. Mansour, F. Dawson and R. Hopson. 5230 Author's Address 5232 Cyrus Daboo 5233 Editor 5235 Email: cyrus@daboo.name 5237 Intellectual Property Statement 5239 The IETF takes no position regarding the validity or scope of any 5240 Intellectual Property Rights or other rights that might be claimed to 5241 pertain to the implementation or use of the technology described in 5242 this document or the extent to which any license under such rights 5243 might or might not be available; nor does it represent that it has 5244 made any independent effort to identify any such rights. Information 5245 on the procedures with respect to rights in RFC documents can be 5246 found in BCP 78 and BCP 79. 5248 Copies of IPR disclosures made to the IETF Secretariat and any 5249 assurances of licenses to be made available, or the result of an 5250 attempt made to obtain a general license or permission for the use of 5251 such proprietary rights by implementers or users of this 5252 specification can be obtained from the IETF on-line IPR repository at 5253 http://www.ietf.org/ipr. 5255 The IETF invites any interested party to bring to its attention any 5256 copyrights, patents or patent applications, or other proprietary 5257 rights that may cover technology that may be required to implement 5258 this standard. Please address the information to the IETF at 5259 ietf-ipr@ietf.org. 5261 Disclaimer of Validity 5263 This document and the information contained herein are provided on an 5264 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 5265 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 5266 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 5267 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 5268 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 5269 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 5271 Copyright Statement 5273 Copyright (C) The Internet Society (2006). This document is subject 5274 to the rights, licenses and restrictions contained in BCP 78, and 5275 except as set forth therein, the authors retain all their rights. 5277 Acknowledgment 5279 Funding for the RFC Editor function is currently provided by the 5280 Internet Society.