idnits 2.17.1 draft-york-vpoll-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- -- The draft header indicates that this document updates RFC5545, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: (CALDAV:vpoll-max-active): The PUT request, or COPY or MOVE request, MUST not result in the number of active VPOLLs being greater than the value of the CALDAV:vpoll-max-active property value Section 7.1.3 on the calendar collection where the resource will be stored; (Using the creation date from RFC5545, updated by this document, for RFC5378 checks: 2005-10-26) -- 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 (February 14, 2017) is 2599 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) == Unused Reference: 'I-D.daboo-icalendar-extensions' is defined on line 2481, but no explicit reference was found in the text == Unused Reference: 'RFC2434' is defined on line 2490, but no explicit reference was found in the text == Unused Reference: 'RFC3688' is defined on line 2500, but no explicit reference was found in the text == Unused Reference: 'RFC4589' is defined on line 2509, but no explicit reference was found in the text -- Possible downref: Normative reference to a draft: ref. 'I-D.daboo-icalendar-extensions' ** Obsolete normative reference: RFC 2434 (Obsoleted by RFC 5226) ** Obsolete normative reference: RFC 2518 (Obsoleted by RFC 4918) Summary: 2 errors (**), 0 flaws (~~), 6 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group E. York, Ed. 3 Internet-Draft C. Daboo, Ed. 4 Updates: 5545 (if approved) Apple Inc. 5 Intended status: Standards Track M. Douglass, Ed. 6 Expires: August 18, 2017 RPI 7 February 14, 2017 9 VPOLL: Consensus Scheduling Component for iCalendar 10 draft-york-vpoll-04 12 Abstract 14 This specification introduces a new iCalendar component which allows 15 for consensus scheduling, that is, voting on a number of alternative 16 meeting or task alternatives. 18 Status of This Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at http://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on August 18, 2017. 35 Copyright Notice 37 Copyright (c) 2017 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (http://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 53 2. Conventions and Terms Used in This Document . . . . . . . . . 4 54 3. Simple Consensus Scheduling . . . . . . . . . . . . . . . . . 5 55 3.1. The VPOLL Component: An Overview . . . . . . . . . . . . 5 56 3.2. The VPOLL Subcomponents: An Overview . . . . . . . . . . 7 57 3.3. VPOLL responses . . . . . . . . . . . . . . . . . . . . . 8 58 3.4. VPOLL updates . . . . . . . . . . . . . . . . . . . . . . 9 59 3.5. VPOLL Completion . . . . . . . . . . . . . . . . . . . . 11 60 3.6. Other Responses . . . . . . . . . . . . . . . . . . . . . 11 61 4. iCalendar Extensions . . . . . . . . . . . . . . . . . . . . 12 62 4.1. Updated Relation Type Value . . . . . . . . . . . . . . . 12 63 4.2. Updated Status Value . . . . . . . . . . . . . . . . . . 12 64 4.3. New Property Parameters . . . . . . . . . . . . . . . . . 13 65 4.3.1. Required . . . . . . . . . . . . . . . . . . . . . . 13 66 4.3.2. Stay-Informed . . . . . . . . . . . . . . . . . . . . 13 67 4.4. New Properties . . . . . . . . . . . . . . . . . . . . . 14 68 4.4.1. Accept-Response . . . . . . . . . . . . . . . . . . . 14 69 4.4.2. Poll-Completion . . . . . . . . . . . . . . . . . . . 14 70 4.4.3. Poll-Item-Id . . . . . . . . . . . . . . . . . . . . 16 71 4.4.4. Poll-Mode . . . . . . . . . . . . . . . . . . . . . . 16 72 4.4.5. Poll-properties . . . . . . . . . . . . . . . . . . . 17 73 4.4.6. Poll-Winner . . . . . . . . . . . . . . . . . . . . . 18 74 4.4.7. Reply-URL . . . . . . . . . . . . . . . . . . . . . . 18 75 4.4.8. Response . . . . . . . . . . . . . . . . . . . . . . 19 76 4.4.9. Voter . . . . . . . . . . . . . . . . . . . . . . . . 20 77 4.5. New Components . . . . . . . . . . . . . . . . . . . . . 21 78 4.5.1. VPOLL Component . . . . . . . . . . . . . . . . . . . 22 79 4.5.2. VVOTER Component . . . . . . . . . . . . . . . . . . 24 80 4.5.3. VOTE Component . . . . . . . . . . . . . . . . . . . 25 81 5. Poll Modes . . . . . . . . . . . . . . . . . . . . . . . . . 26 82 5.1. POLL-MODE:BASIC . . . . . . . . . . . . . . . . . . . . . 27 83 5.1.1. Property restrictions . . . . . . . . . . . . . . . . 27 84 5.1.2. Outcome reporting . . . . . . . . . . . . . . . . . . 27 85 6. iTip Extensions . . . . . . . . . . . . . . . . . . . . . . . 27 86 6.1. Methods . . . . . . . . . . . . . . . . . . . . . . . . . 27 87 6.2. Interoperability Models . . . . . . . . . . . . . . . . . 29 88 6.2.1. Delegation . . . . . . . . . . . . . . . . . . . . . 29 89 6.2.2. Acting on Behalf of Other Calendar Users . . . . . . 29 90 6.2.3. Component Revisions . . . . . . . . . . . . . . . . . 29 91 6.2.4. Message Sequencing . . . . . . . . . . . . . . . . . 29 92 6.3. Application Protocol Elements . . . . . . . . . . . . . . 29 93 6.3.1. Methods for VPOLL Calendar Components . . . . . . . . 29 94 6.3.1.1. PUBLISH . . . . . . . . . . . . . . . . . . . . . 30 95 6.3.1.2. REQUEST . . . . . . . . . . . . . . . . . . . . . 32 96 6.3.1.2.1. Rescheduling a poll . . . . . . . . . . . . . 35 97 6.3.1.2.2. Updating or Reconfirmation of a Poll . . . . 35 98 6.3.1.2.3. Confirmation of a Poll . . . . . . . . . . . 36 99 6.3.1.2.4. Closing a Poll . . . . . . . . . . . . . . . 36 100 6.3.1.2.5. Delegating a POll to Another CU . . . . . . . 36 101 6.3.1.2.6. Changing the Organizer . . . . . . . . . . . 37 102 6.3.1.2.7. Sending on Behalf of the Organizer . . . . . 37 103 6.3.1.2.8. Forwarding to an Uninvited CU . . . . . . . . 37 104 6.3.1.2.9. Updating Voter Status . . . . . . . . . . . . 38 105 6.3.1.3. REPLY . . . . . . . . . . . . . . . . . . . . . . 38 106 6.3.1.4. CANCEL . . . . . . . . . . . . . . . . . . . . . 40 107 6.3.1.5. REFRESH . . . . . . . . . . . . . . . . . . . . . 42 108 6.3.1.6. POLLSTATUS . . . . . . . . . . . . . . . . . . . 44 109 7. CalDAV Extensions . . . . . . . . . . . . . . . . . . . . . . 46 110 7.1. Calendar Collection Properties . . . . . . . . . . . . . 46 111 7.1.1. CALDAV:supported-vpoll-component-sets . . . . . . . . 46 112 7.1.2. CALDAV:vpoll-max-items . . . . . . . . . . . . . . . 47 113 7.1.3. CALDAV:vpoll-max-active . . . . . . . . . . . . . . . 48 114 7.1.4. CALDAV:vpoll-max-voters . . . . . . . . . . . . . . . 49 115 7.1.5. CalDAV:even-more-properties . . . . . . . . . . . . . 50 116 7.1.6. Extensions to CalDAV scheduling . . . . . . . . . . . 50 117 7.2. Additional Preconditions for PUT, COPY, and MOVE . . . . 50 118 7.3. CalDAV:calendar-query Report . . . . . . . . . . . . . . 51 119 7.3.1. Example: Partial Retrieval of VPOLL . . . . . . . . . 51 120 7.4. CalDAV time ranges . . . . . . . . . . . . . . . . . . . 53 121 8. Security Considerations . . . . . . . . . . . . . . . . . . . 54 122 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 54 123 9.1. Parameter Registrations . . . . . . . . . . . . . . . . . 55 124 9.2. Property Registrations . . . . . . . . . . . . . . . . . 55 125 9.3. POLL-MODE Registration Template . . . . . . . . . . . . . 55 126 9.4. POLL-MODE Registrations . . . . . . . . . . . . . . . . . 55 127 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 56 128 11. Normative References . . . . . . . . . . . . . . . . . . . . 56 129 Appendix A. Open issues . . . . . . . . . . . . . . . . . . . . 57 130 Appendix B. Change log . . . . . . . . . . . . . . . . . . . . . 59 131 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 60 133 1. Introduction 135 The currently existing approach to agreeing on meeting times using 136 iTip [RFC5546] and/or iMip [RFC6047] has some significant failings. 137 There is no useful bargaining or suggestion mechanism in iTip, only 138 the ability for a potential attendee to accept or refuse or to 139 counter with a time of their own choosing. 141 Part of the problem is that for many potential attendees, their 142 freebusy is not an accurate representation of their availability. In 143 fact, when trying to schedule conference calls across different 144 organizations, attendees may not be allowed to provide freebusy 145 information or availability as this may reveal something of the 146 organizations internal activities. 148 A number of studies have shown that large amounts of time are spent 149 trying to come to an agreement - up to and beyond 20 working hours 150 per meeting. Many organizers fall back on other approaches such as 151 phone calls and email to determine a suitable time. 153 Online services have appeared as a result and these allow 154 participants to vote on a number of alternatives without revealing or 155 using freebusy or availability. When agreement is reached a 156 conventional scheduling message may be sent to the attendees. This 157 approach appears to reach consensus fairly rapidly. Peer pressure 158 may have some bearing on this as all voters are usually able to see 159 the current state of the voting and may adjust their own meeting 160 schedules to make themselves available for a popular choice. 162 The component and properties defined in this specification provide a 163 standardized structure for this process and allow calendar clients 164 and servers and web based services to interact. 166 These structures also have uses beyond the relatively simple needs of 167 most meeting organizers. The process of coming to consensus can also 168 be viewed as a bidding process. 170 2. Conventions and Terms Used in This Document 172 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 173 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 174 "OPTIONAL" in this document are to be interpreted as described in 175 [RFC2119]. 177 Additionally we will use the following terms: 179 Consensus Scheduling: The process whereby we come to some agreement 180 on meeting or task alternatives and then book that meeting or 181 task. 183 Active Vpoll: A vpoll may have a DTSTART, DTEND and DURATION which 184 may define the start and end of the active voting period. 186 Voter: A participant who votes on the alternatives. A voter need 187 not be an attendee of any of the alternatives presented. 189 3. Simple Consensus Scheduling 191 This specification defines components and properties which can be 192 used for simple consensus scheduling but also have the generality to 193 handle more complex cases. To provide an easy (and for many - 194 sufficient) introduction to consensus scheduling and VPOLL we will 195 outline the flow of information for the simple case of voting on a 196 number of meeting alternatives which differ only in time. In 197 addition the voters will all be potential attendees. 199 This specification not only defines data structures but adds a new 200 iTip method used when consensus has been reached. This document will 201 show how a VPOLL object is used to inform voters of the state of a 202 simple vote on some alternatives. 204 3.1. The VPOLL Component: An Overview 206 The VPOLL component acts as a wrapper for a number of alternatives to 207 be voted on, together with some properties and a new component used 208 to maintain the state of the voting. For our simple example the 209 following VPOLL properties and sub-components are either required or 210 appropriate: 212 DTSTAMP: The usual [RFC5545] property. 214 SEQUENCE: The usual [RFC5545] property. See below for SEQUENCE 215 behavior. 217 UID: The usual [RFC5545] property. 219 ORGANIZER: The usual [RFC5545] property. In general this need not 220 be an organizer of any of the alternatives. In this simple 221 outline we assume it is the same. 223 SUMMARY: The usual [RFC5545] property. This optional but 224 recommended property provides the a short title to the poll. 226 DESCRIPTION: The usual [RFC5545] property. This optional property 227 provides more details. 229 DTEND: The usual [RFC5545] property. This optional property 230 provides a poll closing time and date after which the VPOLL is no 231 longer active. 233 POLL-MODE: A new property which defines how the votes are used to 234 obtain a result. For our use case it will take the value "BASIC" 235 meaning one event will be chosen from the alternatives. 237 POLL-COMPLETION: A new property which defines who (server or client) 238 chooses and/or submits the winning choice. In our example the 239 value is "SERVER-SUBMIT" which means the client chooses the winner 240 but the server will submit the winning choice. 242 POLL-PROPERTIES: A new property which defines which icalendar 243 properties are being voted on. For our use case it will take the 244 value "DTSTART, LOCATION" meaning only those properties are 245 significant for voting. Other properties in the events may differ 246 but are not considered significant for the voting process. 248 VVOTER: A new component. There is one of these for each voter and 249 it contains a VOTER property to identify the voter and one VOTE 250 component for each item being voted on. 252 VOTE: A new component. There is one of these for each voter and 253 choice. It usually contains at least a POLL-ITEM-ID property to 254 identify the choice and a RESPONSE property to provide a vote. 255 For more complex poll modes it may contain other information such 256 as cost or estimated duration. 258 VOTER: A new property. There is one of these for each voter and it 259 is similar to the [RFC5545] ATTENDEE property. It identifies the 260 VVOTER component to show who is taking part in the voting and 261 their results. 263 VEVENT: In our simple use case there will be multiple VEVENT sub- 264 components defining the alternatives. Each will have a different 265 date and or time for the meeting. 267 Putting that together we can construct an example VPOLL with 3 voters 268 and 3 alternative meetings: 270 BEGIN:VCALENDAR 271 VERSION:2.0 272 PRODID:-//Example//Example 273 METHOD:REQUEST 274 BEGIN:VPOLL 275 POLL-MODE:BASIC 276 POLL-COMPLETION:SERVER-SUBMIT 277 POLL-PROPERTIES:DTSTART,LOCATION 278 ORGANIZER:mailto:mike@example.com 279 UID:sched01-1234567890 280 DTSTAMP:20120101T000000Z 281 SUMMARY:What to do this week 282 DTEND:20120101T000000Z 283 BEGIN: VVOTER 284 VOTER:mailto:cyrus@example.com 285 END VVOTER 286 BEGIN: VVOTER 287 VOTER:mailto:eric@example.com 288 END VVOTER 289 BEGIN: VVOTER 290 VOTER:mailto:mike@example.com 291 END VVOTER 292 BEGIN:VEVENT.......(with a poll-item-id=1) 293 END:VEVENT 294 BEGIN:VEVENT.......(with a poll-item-id=2) 295 END:VEVENT 296 BEGIN:VEVENT.......(with a poll-item-id=3) 297 END:VEVENT 298 END:VPOLL 299 END:VCALENDAR 301 As can be seen in the example above, there is an iTip METHOD property 302 with the value REQUEST. The VPOLL object will be distributed to all 303 the voters, either through iMip or through some VPOLL enabled 304 service. 306 3.2. The VPOLL Subcomponents: An Overview 308 Within the VPOLL component we have the alternatives to vote on. In 309 many respects these are standard [RFC5545] components. For our 310 simple use case they are all VEVENT components. In addition to the 311 usual [RFC5545] properties some extra properties are used for a 312 VPOLL. 314 POLL-ITEM-ID: This provides a unique reference to the sub-component 315 within the VPOLL. It's value SHOULD be a small integer. 317 3.3. VPOLL responses 319 Upon receipt of a VPOLL REQUEST the voter will reply with a VPOLL 320 component containing their vote. In our simple case it will have the 321 following properties and components: 323 DTSTAMP: The usual [RFC5545] property. 325 SEQUENCE: The usual [RFC5545] property. See below for SEQUENCE 326 behavior. 328 UID: Same as the request. 330 ORGANIZER: Same as the request. 332 SUMMARY: Same as the request. 334 VVOTER: One only. 336 VOTER: One only inside the VVOTER component - the voter replying. 338 VOTE: One per item being voted on. There does not need to be one 339 for each choice. 341 POLL-ITEM-ID: One inside each VOTE component to identify the choice. 343 RESPONSE: One inside each VOTE component to specify the vote. 345 Note that a voter can send a number of REPLYs for each REQUEST sent 346 by the organizer. Each REPLY completely replaces the voting record 347 for that voter for all components being voted on. In our example, if 348 Eric responds and votes for items 1 and 2 and then responds again 349 with a vote for only item 3, the final outcome is one vote on item 3. 351 Putting this together we can construct an example REPLY VPOLL from 352 Cyrus: 354 BEGIN:VCALENDAR 355 VERSION:2.0 356 PRODID:-//Example//Example 357 METHOD: REPLY 358 BEGIN:VPOLL 359 ORGANIZER:mailto:mike@example.com 360 UID:sched01-1234567890 361 DTSTAMP:20120101T010000Z 362 SUMMARY:What to do this week 363 BEGIN:VVOTER 364 VOTER:mailto:cyrus@example.com 365 BEGIN:VOTE 366 POLL-ITEM-ID:1 367 RESPONSE:50 368 COMMENT:Work on iTIP 369 END:VOTE 370 BEGIN:VOTE 371 POLL-ITEM-ID:2 372 RESPONSE:100 373 COMMENT:Work on WebDAV 374 END:VOTE 375 BEGIN:VOTE 376 POLL-ITEM-ID:3 377 RESPONSE:0 378 END:VOTE 379 END:VVOTER 380 END:VPOLL 381 END:VCALENDAR 383 3.4. VPOLL updates 385 When the organizer receives a response from one or more voters the 386 current state of the poll is sent to all voters. The new iTip method 387 POLLSTATUS is used. The VPOLL can contain a reduced set of 388 properties but MUST contain DTSTAMP, SEQUENCE (if not 0), UID, 389 ORGANIZER and one or more VVOTER components each populated with a 390 VOTER property and zero or more VOTE components. 392 An example: 394 BEGIN:VCALENDAR 395 VERSION:2.0 396 PRODID:-//Example//Example 397 METHOD: POLLSTATUS 398 BEGIN:VPOLL 399 ORGANIZER:mailto:mike@example.com 400 UID:sched01-1234567890 401 DTSTAMP:20120101T020000Z 402 SEQUENCE:0 403 SUMMARY:What to do this week 404 BEGIN:VVOTER 405 VOTER:mailto:cyrus@example.com 406 BEGIN: VOTE 407 POLL-ITEM-ID:1 408 RESPONSE:50 409 COMMENT:Work on iTIP 410 END:VOTE 411 BEGIN:VOTE 412 POLL-ITEM-ID:2 413 RESPONSE:100 414 COMMENT:Work on WebDAV 415 END:VOTE 416 BEGIN:VOTE 417 POLL-ITEM-ID:3 418 RESPONSE:0 419 END:VOTE 420 END:VVOTER 421 BEGIN:VVOTER 422 VOTER:mailto:eric@example.com 423 BEGIN:VOTE 424 POLL-ITEM-ID:1 425 RESPONSE:100 426 END:VOTE 427 BEGIN:VOTE 428 POLL-ITEM-ID:2 429 RESPONSE:100 430 END:VOTE 431 BEGIN:VOTE 432 POLL-ITEM-ID:3 433 RESPONSE:0 434 END:VOTE 435 END:VVOTER 436 END:VPOLL 437 END:VCALENDAR 439 3.5. VPOLL Completion 441 After a number of REPLY messages have been received the poll will be 442 considered complete. If there is a DTEND on the poll the system may 443 automatically close the poll, or the organizer may, at any time, 444 consider the poll complete. A VPOLL can be completed (and 445 effectively closed for voting) by sending an iTip REQUEST message 446 with the VPOLL STATUS property set to COMPLETED. 448 The poll winner is confirmed by sending a final iTip REQUEST message 449 with the VPOLL STATUS property set to CONFIRMED. In this case the 450 VPOLL component contains all the events being voted on along with a 451 POLL-WINNER property to identify the winning event. As the POLL- 452 COMPLETION property is set to SERVER-SUBMIT the server will submit 453 the winning choice and when it has done so set the STATUS to 454 "SUBMITTED". 456 The VPOLL confirmation example: 458 BEGIN:VCALENDAR 459 VERSION:2.0 460 PRODID:-//Example//Example 461 METHOD: REQUEST 462 BEGIN:VPOLL 463 ORGANIZER:mailto:douglm@example.com 464 UID:sched01-1234567890 465 DTSTAMP:20120101T030000Z 466 COMPLETED:20120101T030000Z 467 POLL-COMPLETION:SERVER-SUBMIT 468 SEQUENCE:0 469 SUMMARY:What to do this week 470 STATUS:CONFIRMED 471 POLL-WINNER:3 472 BEGIN:VEVENT.......(with a poll-item-id=1) 473 END:VEVENT 474 BEGIN:VEVENT.......(with a poll-item-id=2) 475 END:VEVENT 476 BEGIN:VEVENT.......(with a poll-item-id=3) 477 END:VEVENT 478 END:VPOLL 479 END:VCALENDAR 481 3.6. Other Responses 483 A voter being asked to choose between a number of ORGANIZER supplied 484 alternatives may find none of them acceptable or may simply not care. 486 An alternative response, which may be disallowed by the ORGANIZER, is 487 to send back the respondees availability or freebusy or even one or 488 more new, alternative choices. 490 This is accomplished by responding with a VOTE component which has no 491 POLL-ITEM-ID property. In this case it MUST contain some alternative 492 information. What form this takes depends on the poll mode in 493 effect. 495 4. iCalendar Extensions 497 4.1. Updated Relation Type Value 499 Relationship parameter type values are defined in section 3.2.15. of 500 [RFC5545]. This specification updates that type to include the new 501 relationship value POLL to provide a link to the VPOLL component in 502 which the current component appears. 504 Format Definition: 506 This property parameter is redefined by the following notation: 508 reltypeparam /= "RELTYPE" "=" "POLL" 509 ; Property value is a VPOLL uid 511 Description: This parameter can be specified on a property that 512 references another related calendar component. The new parameter 513 value indicates that the associated property references a VPOLL 514 component which contains the current component. 516 4.2. Updated Status Value 518 Status property values are defined in section 3.8.1.11. of [RFC5545]. 519 This specification updates that type to define valid VPOLL status 520 values. 522 Format Definition: 524 This property parameter is redefined by the following notation: 526 statvalue /= statvalue-poll 527 ; Status values for "VPOLL". 528 statvalue-poll = "IN-PROCESS" 529 / "COMPLETED" ; Poll has closed, 530 ; nothing has been chosen yet 531 / "CONFIRMED" ; Poll has closed and 532 ; winning items confirmed 533 / "SUBMITTED" ; The winning item has been 534 ; submitted 535 / "CANCELLED" 537 Description: These values allow clients and servers to handle the 538 choosing and submission of winning choices. 540 If the client is choosing and the server submitting then the 541 client should set the POLL-WINNER property, set the status to 542 CONFIRMED and save the poll. When the server submits the winning 543 choice it will set the status to SUBMITTED. 545 4.3. New Property Parameters 547 4.3.1. Required 549 Parameter name: REQUIRED 551 Purpose: To specify whether the associated property is required in 552 the current context. 554 Format Definition: 556 This parameter is defined by the following notation: 558 requirededparam = "REQUIRED" "=" ("TRUE" / "FALSE") 559 ; Default is FALSE 561 Description: This parameter MAY be specified on REPLY-URL and, if 562 the value is TRUE, indicates the organizer requires all replies to 563 be made via the specified service rather than iTip replies. 565 4.3.2. Stay-Informed 567 Parameter name: STAY-INFORMED 569 Purpose: To specify the voter also wants to be added as an ATTENDEE 570 when the poll is confirmed. 572 Format Definition: 574 This parameter is defined by the following notation: 576 stayinformedparam = "STAY-INFORMED" "=" ("TRUE" / "FALSE") 577 ; Default is FALSE 579 Description: This parameter MAY be specified on VOTER and, if the 580 value is TRUE, indicates the voter wishes to be added to the final 581 choice as a non participant. 583 4.4. New Properties 585 4.4.1. Accept-Response 587 Property name: ACCEPT-RESPONSE 589 Purpose: This property is used in VPOLL to indicate the types of 590 component that may be supplied in a response. 592 Property Parameters: Non-standard or iana parameters can be 593 specified on this property. 595 Conformance: This property MAY be specified in a VPOLL component. 597 Description: When used in a VPOLL this property indicates what 598 allowable component types may be returned in a reply. Typically 599 this would allow a voter to respond with their freebusy or 600 availability rather than choosing one of the presented 601 alternatives 603 If this property is not present voters are only allowed to respond 604 to the choices in the request. 606 Format Definition: 608 This property is defined by the following notation: 610 acceptresponse = "ACCEPT-RESPONSE" acceptresponseparams ":" 611 iana-token ("," iana-token) CRLF 613 acceptresponseparams = *(";" other-param) 615 4.4.2. Poll-Completion 617 Property name: POLL-COMPLETION 618 Purpose: This property is used in VPOLL to indicate whether the 619 client or server is responsible for choosing and/or submitting the 620 winner(s). 622 Description: When a VPOLL is stored on a server which is capable of 623 handling choosing and submission of winning choices a value of 624 SERVER indicates that the server should close the poll, choose the 625 winner and submit whenever it is appropriate to do so. 627 For example, in BASIC poll-mode, reaching the DTEND of the poll 628 could trigger this server side action. 630 Server initiated submission requires that the submitted choice 631 MUST be a valid calendaring component. 633 POLL-COMPLETION=SERVER-SUBMIT allows the client to set the poll- 634 winner, set the status to CONFIRMED and then store the poll on the 635 server. The server will then submit the winning choice and set 636 the status to SUBMITTED. 638 Format Definition: 640 This property is defined by the following notation: 642 poll-completion = "POLL-COMPLETION" pcparam ":" pcvalue CRLF 644 pcparam = *(";" other-param) 646 pcvalue = "SERVER" ; The server is responsible for both choosing and 647 ; submitting the winner(s) 648 / "SERVER-SUBMIT" ; The server is responsible for 649 ; submitting the winner(s). The client chooses. 650 / "SERVER-CHOICE" ; The server is responsible for 651 ; choosing the winner(s). The client will submit. 652 / "CLIENT" ; The client is responsible for both choosing and 653 ; submitting the winner(s) 654 / iana-token 655 / x-name 656 ;Default is CLIENT 658 Example: 660 The following is an example of this property: 662 POLL-COMPLETION: SERVER-SUBMIT 664 4.4.3. Poll-Item-Id 666 Property name: POLL-ITEM-ID 668 Purpose: This property is used in VPOLL child components as an 669 identifier. 671 Value type: INTEGER 673 Property Parameters: Non-standard parameters can be specified on 674 this property. 676 Conformance: This property MUST be specified in a VOTE component and 677 in VPOLL choice items. 679 Description: In a METHOD:REQUEST each choice component MUST have a 680 POLL-ITEM-ID property. Each set of components with the same POLL- 681 ITEM-ID value represents one overall set of items to be voted on. 683 POLL-ITEM-ID SHOULD be a unique small integer for each component 684 or set of components. If it remains the same between REQUESTs 685 then the previous response for that component MAY be re-used. To 686 force a re-vote on a component due to a significant change, the 687 POLL-ITEM-ID MUST change. 689 Format Definition: 691 This property is defined by the following notation: 693 pollitemid = "POLL-ITEM-ID" pollitemdparams ":" 694 integer CRLF 696 pollitemidparams = *( 697 (";" other-param) 698 ) 700 4.4.4. Poll-Mode 702 Property name: POLL-MODE 704 Purpose: This property is used in VPOLL to indicate what voting mode 705 is to be applied. 707 Property Parameters: Non-standard or iana parameters can be 708 specified on this property. 710 Conformance: This property MAY be specified in a VPOLL component or 711 its sub-components. 713 Description: The poll mode defines how the votes are applied to 714 obtain a result. BASIC mode, the default, means that the voters 715 are selecting one component (or group of components) with a given 716 POLL=ITEM-ID. 718 Other polling modes may be defined in updates to this 719 specification. These may allow for such modes as ranking or task 720 assignment. 722 Format Definition: 724 This property is defined by the following notation: 726 pollmode = "POLL-MODE" pollmodeparams ":" 727 ("BASIC" / iana-token / other-token) CRLF 729 pollmodeparams = *(";" other-param) 731 4.4.5. Poll-properties 733 Property name: POLL-PROPERTIES 735 Purpose: This property is used in VPOLL to define which icalendar 736 properties are being voted on. 738 Property Parameters: Non-standard or iana parameters can be 739 specified on this property. 741 Conformance: This property MAY be specified in a VPOLL component. 743 Description: This property defines which icalendar properties are 744 significant in the voting process. It may not be clear to voters 745 which properties are varying in a significant manner. Clients may 746 use this property to highlight those listed properties. 748 Format Definition: 750 This property is defined by the following notation: 752 pollproperties = "POLL-PROPERTIES" pollpropparams ":" 753 text *("," text) CRLF 755 pollpropparams = *(";" other-param) 757 4.4.6. Poll-Winner 759 Property name: POLL-WINNER 761 Purpose: This property is used in a basic mode VPOLL to indicate 762 which of the VPOLL sub-components won. 764 Value type: INTEGER 766 Property Parameters: Non-standard parameters can be specified on 767 this property. 769 Conformance: This property MAY be specified in a VPOLL component. 771 Description: For poll confirmation each child component MUST have a 772 POLL-ITEM-ID property. For basic mode the VPOLL component SHOULD 773 have a POLL-WINNER property which MUST correspond to one of the 774 POLL-ITEM-ID properties and indicates which sub-component was the 775 winner. 777 Format Definition: 779 This property is defined by the following notation: 781 pollwinner = "POLL-WINNER" pollwinnerparams ":" 782 integer CRLF 784 pollwinnerparams = *(";" other-param) 786 ; Used with a STATUS:CONFIRMED VPOLL to indicate which 787 ; components have been confirmed 789 4.4.7. Reply-URL 791 Property name: REPLY-URL 793 Purpose: This property may be used in scheduling messages to 794 indicate additional reply methods, for example a web-service. 796 Property Parameters: Non-standard, required or iana parameters can 797 be specified on this property. 799 Conformance: This property MAY be specified in a VPOLL component. 801 Description: When used in a scheduling message this property 802 indicates additional or required services that can be used to 803 reply. Typically this would be a web service of some form. 805 Format Definition: 807 This property is defined by the following notation: 809 reply-url = "REPLY-URL" reply-urlparams ":" uri CRLF 811 reply-urlparams = *( 812 (";" requiredparam) / 813 (";" other-param) 814 ) 816 4.4.8. Response 818 Property name: RESPONSE 820 Purpose: To specify a response vote. 822 Value type: INTEGER 824 Format Definition: 826 This property is defined by the following notation: 828 response = "RESPONSE" response-params ":" integer CRLF 829 ; integer value 0..100 831 responseparams = *(";" other-param) 833 Description: This parameter can be specified on the POLL-ITEM-ID 834 property to provide the value of the voters response. This 835 parameter allows for fine grained responses which are appropriate 836 to some applications. For the case of individuals voting for a 837 choice of events, client applications SHOULD conform to the 838 following convention: 840 * 0 - 39 A "NO vote". 842 * 40 - 79 A "MAYBE" vote 844 * 80 - 89 A "YES - but not preferred vote" 846 * 90-100 A "YES" vote. 848 Clients MUST preserve the response value when there is no change 849 from the user even if they have a UI with fixed states (e.g. 850 yes/no/maybe). 852 4.4.9. Voter 854 Property name: VOTER 856 Purpose: This property is used in VVOTER components to indicate 857 recipients of the poll and to identify that component as 858 containing the voters responses. 860 Value type: The value type for this property is cal-address. 862 Property Parameters: Non-standard, cutype, member, role, rsvp, 863 delto, delfrom, sentby, cn, dir, lang or stayinformed parameters 864 can be specified on this property. 866 Conformance: This property MAY be specified in a VPOLL component or 867 its sub-components. 869 Description: This property appears in the VVOTER component only and 870 indicates a recipient of the poll and their responses. 872 Format Definition: 874 This property is defined by the following notation: 876 voter = "VOTER" voterparams ":" cal-address CRLF 878 voterparam = *( 879 ; 880 ; The following are OPTIONAL, 881 ; but MUST NOT occur more than once. 882 ; 883 (";" cutypeparam) / (";" memberparam) / 884 (";" roleparam) / 885 (";" rsvpparam) / (";" deltoparam) / 886 (";" delfromparam) / (";" sentbyparam) / 887 (";" cnparam) / (";" dirparam) / 888 (";" languageparam) / 889 (";" stayinformedparam) / 891 ; 892 ; The following are OPTIONAL, but MUST NOT occur 893 ; more than once. They are defined in RFC6638 894 ; 895 (";" scheduleagentparam) / 896 (";" scheduleforcesendparam) / 897 (";" schedulestatusparam) / 899 ; 900 ; The following is OPTIONAL, 901 ; and MAY occur more than once. 902 ; 903 (";" other-param) 904 ; 905 ) 907 Note 1 RSVP=TRUE MAY be used by the organizer to force the voter to 908 reset their state and re-vote. 910 Note 2 scheduleagentparam, scheduleforcesendparam and 911 schedulestatusparam are all related to CalDAV scheduling and are 912 defined in [RFC6638]. Their semantics are exactly as defined in 913 that specification. 915 4.5. New Components 916 4.5.1. VPOLL Component 918 Component name: VPOLL 920 Purpose: This component provides a mechanism by which voters can 921 vote on provided choices. 923 Format Definition: 925 This property is defined by the following notation: 927 pollc = "BEGIN" ":" "VPOLL" CRLF 928 pollprop 929 *voterc *eventc *todoc *journalc *freebusyc 930 *availabilityc *alarmc *iana-comp *x-comp 931 "END" ":" "VPOLL" CRLF 933 pollprop = *( 934 ; 935 ; The following are REQUIRED, 936 ; but MUST NOT occur more than once. 937 ; 938 dtstamp / uid / organizer / 939 ; 940 ; The following are OPTIONAL, 941 ; but MUST NOT occur more than once. 942 ; 943 acceptresponse / class / created / completed / 944 description / dtstart / last-mod / pollmode / 945 pollproperties / priority / seq / status / 946 summary / url / 947 ; 948 ; Either 'dtend' or 'duration' MAY appear in 949 ; a 'pollprop', but 'dtend' and 'duration' 950 ; MUST NOT occur in the same 'pollprop'. 951 ; 'duration' MUST only occur when 'dtstart' 952 ; is present 953 ; 954 dtend / duration / 955 ; 956 ; The following are OPTIONAL, 957 ; and MAY occur more than once. 958 ; 959 attach / categories / comment / 960 contact / rstatus / related / 961 resources / x-prop / iana-prop 962 ; 963 ; The following is OPTIONAL, it SHOULD appear 964 ; once for the confirmation of a BASIC mode 965 ; VPOLL. Other modes may define differing 966 ; requirements. 967 ; 968 pollwinner / 969 ; 970 ) 972 Description: This component provides a mechanism by which voters can 973 vote on provided choices. The outcome depends upon the POLL-MODE 974 in effect. 976 The VVOTER components in VPOLL requests provide information on 977 each recipient who will be voting - both their identity through 978 the VOTER property and their votes through the VOTE components. 980 If specified, the "DTSTART" property defines the start or opening 981 of the poll active period. If absent the poll is presumed to have 982 started when created. 984 If "DTSTART" is present "DURATION" MAY be specified and indicates 985 the duration, and hence the ending, of the poll. The value of the 986 property MUST be a positive duration. 988 "DTEND" MAY be specified with or without "DTSTART" and indicates 989 the ending of the poll. If DTEND is specified it MUST be later 990 than the DTSTART or CREATED property. 992 If one or more VALARM components are included in the VPOLL they 993 are not components to be voted on and MUST NOT contain a POLL- 994 ITEM-ID property. VALARM sub-components may be used to provide 995 warnings to the user when polls are due to start or end. 997 Need some text to describe what relative alarms are relative to. 999 4.5.2. VVOTER Component 1001 Component name: VPOLL 1003 Purpose: This component contains identification of the recipient and 1004 voter and their responses. 1006 Format Definition: 1008 This property is defined by the following notation: 1010 voterc = "BEGIN" ":" "VVOTER" CRLF 1011 voterprop 1012 *votec *iana-comp *x-comp 1013 "END" ":" "VVOTER" CRLF 1015 voterprop = *( 1016 ; 1017 ; The following are REQUIRED, 1018 ; but MUST NOT occur more than once. 1019 ; 1020 dtstamp / voter / 1021 ; 1022 ; The following are OPTIONAL, 1023 ; but MUST NOT occur more than once. 1024 ; 1025 created / description / last-mod / seq / 1026 status / summary / url / 1027 ; 1028 ; The following are OPTIONAL, 1029 ; and MAY occur more than once. 1030 ; 1031 attach / categories / comment / 1032 contact / rstatus / related / 1033 resources / x-prop / iana-prop 1034 ; 1035 ) 1037 Description: This component contains a VOTER property identifying a 1038 recipient and voter and zero or more VOTE components containing 1039 their responses. 1041 The VOTER property in VVOTER objects refers to a recipient who 1042 will be voting - RSVP=TRUE is used by the organizer to force the 1043 voter to reset their state and re-vote 1045 4.5.3. VOTE Component 1047 Component name: VPOLL 1049 Purpose: This component provides a mechanism by which voters can 1050 vote on provided choices. 1052 Format Definition: 1054 This property is defined by the following notation: 1056 votec = "BEGIN" ":" "VOTE" CRLF 1057 voteprop 1058 *eventc *todoc *journalc *freebusyc 1059 *availabilityc *alarmc *iana-comp *x-comp 1060 "END" ":" "VOTE" CRLF 1062 voteprop = *( 1063 ; 1064 ; The following are REQUIRED, 1065 ; but MUST NOT occur more than once. 1066 ; 1067 pollitemid / response / 1068 ; 1069 ; The following are OPTIONAL, 1070 ; and MAY occur more than once. 1071 ; 1072 comment / x-prop / iana-prop 1073 ; 1074 ) 1076 Description: This component identifies voters and contains their 1077 responses. 1079 The required and optional properties and their meanings depend 1080 upon the POLL-MODE in effect. 1082 For any POLL-MODE, POLL-ITEM-ID is used to associate the 1083 information to a choice supplied by the organizer. 1085 If allowed by the POLL-MODE a VOTE component without a POLL-ITEM- 1086 ID may be provided in a REPLY to indicate a possible new choice or 1087 to provide information to the ORGANIZER - such as the respondees 1088 availability. 1090 5. Poll Modes 1092 The VPOLL component is intended to allow for various forms of 1093 polling. The particular form in efffect is indicated by the POLL- 1094 MODE property. 1096 New poll modes can be registered by including a completed POLL-MODE 1097 Registration Template (see Section 9.3) in a published RFC. 1099 5.1. POLL-MODE:BASIC 1101 BASIC poll mode is the form of voting in which one possible outcome 1102 is chosen from a set of possibilities. Usually this will be 1103 represented as a number of possible event objects one of which will 1104 be selected. 1106 5.1.1. Property restrictions 1108 This poll mode has the following property requirements: 1110 POLL-ITEM-ID: Each contained sub-component that is being voted upon 1111 MUST contain a POLL-ITEM_ID property which is unique within the 1112 context of the POLL. The value MUST NOT be reused when events are 1113 removed and/or added to the poll. 1115 POLL-WINNER: On confirmation of the poll this property MUST be 1116 present and identifies the winning component. 1118 5.1.2. Outcome reporting 1120 To confirm the winner the POLL-WINNER property MUST be present and 1121 the STATUS MUST be set to CONFIRMED. 1123 When the winning VEVENT or VTODO is not a scheduled entity, that is, 1124 it has no ORGANIZER or ATTENDEES it MUST be assigned an ORGANIZER 1125 property and a list of non-participating ATTENDEEs. This allows the 1126 winning entity to be distributed to the participants through iTip or 1127 some other protocol. 1129 6. iTip Extensions 1131 This specification introduces a number of extensions to [RFC5546]. 1132 In group scheduling the parties involved are organizer and attendees. 1133 In VPOLL the parties are organizer and voters. 1135 For many of the iTip processing rules the voters take the place of 1136 attendees. 1138 6.1. Methods 1140 There are some extensions to the behavior of iTip methods for a VPOLL 1141 object and two new methods are defined. 1143 +----------------+--------------------------------------------------+ 1144 | Method | Description | 1145 +----------------+--------------------------------------------------+ 1146 | PUBLISH | No changes (yet) | 1147 | | | 1148 | REQUEST | Each child component MUST have a POLL-ITEM-ID | 1149 | | property. Each set of components with the same | 1150 | | POLL-ITEM-ID value represents one overall set of | 1151 | | items to be voted on. | 1152 | | | 1153 | REPLY | There MUST be a single VPOLL component which | 1154 | | MUST have: either one or more POLL-ITEM-ID | 1155 | | properties with a RESPONSE param matching that | 1156 | | from a REQUEST or a VFREEBUSY or VAVAILABILITY | 1157 | | child component showing overall busy/available | 1158 | | time. The VPOLL MUST have one VOTER only. | 1159 | | | 1160 | ADD | Not supported for VPOLL. | 1161 | | | 1162 | CANCEL | There MUST be a single VPOLL component with UID | 1163 | | matching that of the poll being cancelled. | 1164 | | | 1165 | REFRESH | The organizer returns a METHOD:REQUEST with the | 1166 | | current full state, or a METHOD:CANCEL or an | 1167 | | error if no matching poll is found. | 1168 | | | 1169 | COUNTER | Not supported for VPOLL. | 1170 | | | 1171 | DECLINECOUNTER | Not supported for VPOLL. | 1172 | | | 1173 | POLLSTATUS | Used to send the current state of the poll to | 1174 | | all voters. The VPOLL can contain a reduced set | 1175 | | of properties but MUST contain DTSTAMP, SEQUENCE | 1176 | | (if not 0), UID, ORGANIZER and VOTER. | 1177 | | | 1178 +----------------+--------------------------------------------------+ 1180 The following table shows the above methods broken down by who can 1181 send them with VPOLL components. 1183 +-------------+-------------------------------------------------+ 1184 | Originator | Methods | 1185 +-------------+-------------------------------------------------+ 1186 | Organizer | CANCEL, PUBLISH, REQUEST, POLLSTATUS | 1187 | | | 1188 | Voter | REPLY, REFRESH, REQUEST (only when delegating) | 1189 +-------------+-------------------------------------------------+ 1191 6.2. Interoperability Models 1193 Most of the standard iTip specification applies with respect to 1194 organizer and voters. 1196 6.2.1. Delegation 1198 TBD 1200 6.2.2. Acting on Behalf of Other Calendar Users 1202 TBD 1204 6.2.3. Component Revisions 1206 Need to talk about what a change in SEQUENCE means 1207 Sequence change forces a revote. 1208 New voter - no sequence change 1209 Add another poll set or change poll item ids or any change to a child 1210 component - bump sequence 1212 6.2.4. Message Sequencing 1214 TBD 1216 6.3. Application Protocol Elements 1218 6.3.1. Methods for VPOLL Calendar Components 1220 This section defines the property set restrictions for the method 1221 types that are applicable to the "VPOLL" calendar component. Each 1222 method is defined using a table that clarifies the property 1223 constraints that define the particular method. 1225 The presence column uses the following values to assert whether a 1226 property is required or optional, and the number of times it may 1227 appear in the iCalendar object. 1229 +-----------------+-------------------------------------------------+ 1230 | Presence Value | Description | 1231 +-----------------+-------------------------------------------------+ 1232 | 1 | One instance MUST be present. | 1233 | 1+ | At least one instance MUST be present. | 1234 | 0 | Instances of this property MUST NOT be present. | 1235 | 0+ | Multiple instances MAY be present. | 1236 | 0 or 1 | Up to 1 instance of this property MAY be | 1237 | | present. | 1238 +-----------------+-------------------------------------------------+ 1239 The following summarizes the methods that are defined for the "VPOLL" 1240 calendar component. 1242 +------------+------------------------------------------------------+ 1243 | Method | Description | 1244 +------------+------------------------------------------------------+ 1245 | PUBLISH | Post notification of an poll. Used primarily as a | 1246 | | method of advertising the existence of a poll. | 1247 | | | 1248 | REQUEST | To make a request for a poll. This is an explicit | 1249 | | invitation to one or more voters. Poll requests are | 1250 | | also used to update, change or confirm an existing | 1251 | | poll. Clients that cannot handle REQUEST MAY degrade | 1252 | | the poll to view it as a PUBLISH. REQUEST SHOULD NOT | 1253 | | be used just to set the status of the poll - | 1254 | | POLLSTATUS provides a more compact approach. | 1255 | | | 1256 | REPLY | Reply to a poll request. Voters may set their | 1257 | | RESPONSE parameter to supply the current vote in the | 1258 | | range 0 to 100. | 1259 | | | 1260 | CANCEL | Cancel a poll. | 1261 | | | 1262 | REFRESH | A request is sent to an Organizer by a Voter asking | 1263 | | for the latest version of a poll to be resent to the | 1264 | | requester. | 1265 | | | 1266 | POLLSTATUS | Used to send the current state of the poll to all | 1267 | | voters. The VPOLL can contain a reduced set of | 1268 | | properties but MUST contain DTSTAMP, SEQUENCE (if | 1269 | | not 0), UID, ORGANIZER and VOTER. | 1270 | | | 1271 +------------+------------------------------------------------------+ 1273 6.3.1.1. PUBLISH 1275 The "PUBLISH" method in a "VPOLL" calendar component is an 1276 unsolicited posting of an iCalendar object. Any CU may add published 1277 components to their calendar. The "Organizer" MUST be present in a 1278 published iCalendar component. "Voters" MUST NOT be present. Its 1279 expected usage is for encapsulating an arbitrary poll as an iCalendar 1280 object. The "Organizer" may subsequently update (with another 1281 "PUBLISH" method) or cancel (with a "CANCEL" method) a previously 1282 published "VPOLL" calendar component. 1284 This method type is an iCalendar object that conforms to the 1285 following property constraints: 1287 +----------------------------------------------+ 1288 | Constraints for a METHOD:PUBLISH of a VPOLL | 1289 +----------------------------------------------+ 1290 +----------------------------------------------+ 1292 +--------------------+----------+-----------------------------------+ 1293 | Component/Property | Presence | Comment | 1294 +--------------------+----------+-----------------------------------+ 1295 | METHOD | 1 | MUST equal PUBLISH. | 1296 | | | | 1297 | VPOLL | 1+ | | 1298 | DTSTAMP | 1 | | 1299 | DTSTART | 0 or 1 | If present defines the start of | 1300 | | | the poll. Otherwise the poll | 1301 | | | starts when it is created and | 1302 | | | distributed. | 1303 | ORGANIZER | 1 | | 1304 | SUMMARY | 1 | Can be null. | 1305 | UID | 1 | | 1306 | SEQUENCE | 0 or 1 | MUST be present if value is | 1307 | | | greater than 0; MAY be present if | 1308 | | | 0. | 1309 | ACCEPT-RESPONSE | 0 or 1 | | 1310 | ATTACH | 0+ | | 1311 | CATEGORIES | 0+ | | 1312 | CLASS | 0 or 1 | | 1313 | COMMENT | 0+ | | 1314 | COMPLETED | 0 or 1 | | 1315 | CONTACT | 0 or 1 | | 1316 | CREATED | 0 or 1 | | 1317 | DESCRIPTION | 0 or 1 | Can be null. | 1318 | DTEND | 0 or 1 | If present, DURATION MUST NOT be | 1319 | | | present. | 1320 | DURATION | 0 or 1 | If present, DTEND MUST NOT be | 1321 | | | present. | 1322 | LAST-MODIFIED | 0 or 1 | | 1323 | POLL-ITEM-ID | 0 | | 1324 | POLL-MODE | 0 or 1 | | 1325 | POLL-PROPERTIES | 0 or 1 | | 1326 | PRIORITY | 0 or 1 | | 1327 | RELATED-TO | 0+ | | 1328 | RESOURCES | 0+ | | 1329 | STATUS | 0 or 1 | MAY be one of | 1330 | | | COMPLETED/CONFIRMED/CANCELLED. | 1331 | URL | 0 or 1 | | 1332 | IANA-PROPERTY | 0+ | | 1333 | X-PROPERTY | 0+ | | 1334 | VOTER | 0 | | 1335 | REQUEST-STATUS | 0 | | 1336 | | | | 1337 | VALARM | 0+ | | 1338 | | | | 1339 | VEVENT | 0+ | Depending upon the poll mode in | 1340 | | | effect there MAY be candidate | 1341 | | | components included in the poll | 1342 | | | component. If voting has already | 1343 | | | taken place, these components | 1344 | | | MUST include the VOTER property | 1345 | | | to indicate each voters current | 1346 | | | response. | 1347 | | | | 1348 | VFREEBUSY | 0 | | 1349 | | | | 1350 | VJOURNAL | 0+ | Depending upon the poll mode in | 1351 | | | effect there MAY be candidate | 1352 | | | components included in the poll | 1353 | | | component. If voting has already | 1354 | | | taken place, these components | 1355 | | | MUST include the VOTER property | 1356 | | | to indicate each voters current | 1357 | | | response. | 1358 | | | | 1359 | VTODO | 0+ | Depending upon the poll mode in | 1360 | | | effect there MAY be candidate | 1361 | | | components included in the poll | 1362 | | | component. If voting has already | 1363 | | | taken place, these components | 1364 | | | MUST include the VOTER property | 1365 | | | to indicate each voters current | 1366 | | | response. | 1367 | | | | 1368 | VTIMEZONE | 0+ | MUST be present if any date/time | 1369 | | | refers to a timezone. | 1370 | | | | 1371 | IANA-COMPONENT | 0+ | | 1372 | X-COMPONENT | 0+ | | 1373 +--------------------+----------+-----------------------------------+ 1375 6.3.1.2. REQUEST 1377 The "REQUEST" method in a "VPOLL" component provides the following 1378 scheduling functions: 1380 o Invite "Voters" to respond to the poll. 1382 o Change the items being voted upon. 1384 o Complete or confirm the poll. 1386 o Response to a "REFRESH" request. 1388 o Update the details of an existing vpoll. 1390 o Update the status of "Voters". 1392 o Forward a "VPOLL" to another uninvited CU. 1394 o For an existing "VPOLL" calendar component, delegate the role of 1395 "Voter" to another CU. 1397 o For an existing "VPOLL" calendar component, change the role of 1398 "Organizer" to another CU. 1400 The "Organizer" originates the "REQUEST". The recipients of the 1401 "REQUEST" method are the CUs voting in the poll, the "Voters". 1402 "Voters" use the "REPLY" method to convey votes to the "Organizer". 1404 The "UID" and "SEQUENCE" properties are used to distinguish the 1405 various uses of the "REQUEST" method. If the "UID" property value in 1406 the "REQUEST" is not found on the recipient's calendar, then the 1407 "REQUEST" is for a new "VPOLL" calendar component. If the "UID" 1408 property value is found on the recipient's calendar, then the 1409 "REQUEST" is for an update, or a reconfirmation of the "VPOLL" 1410 calendar component. 1412 For the "REQUEST" method only a single iCalendar object is permitted. 1414 This method type is an iCalendar object that conforms to the 1415 following property constraints: 1417 +----------------------------------------------+ 1418 | Constraints for a METHOD:REQUEST of a VPOLL | 1419 +----------------------------------------------+ 1420 +----------------------------------------------+ 1422 +--------------------+----------+-----------------------------------+ 1423 | Component/Property | Presence | Comment | 1424 +--------------------+----------+-----------------------------------+ 1425 | METHOD | 1 | MUST be REQUEST. | 1426 | | | | 1427 | VPOLL | 1 | | 1428 | VOTER | 1+ | | 1429 | DTSTAMP | 1 | | 1430 | DTSTART | 0 or 1 | If present defines the start of | 1431 | | | the poll. Otherwise the poll | 1432 | | | starts when it is created and | 1433 | | | distributed. | 1434 | ORGANIZER | 1 | | 1435 | SEQUENCE | 0 or 1 | MUST be present if value is | 1436 | | | greater than 0; MAY be present if | 1437 | | | 0. | 1438 | SUMMARY | 1 | Can be null. | 1439 | UID | 1 | | 1440 | ACCEPT-RESPONSE | 0 or 1 | | 1441 | ATTACH | 0+ | | 1442 | CATEGORIES | 0+ | | 1443 | CLASS | 0 or 1 | | 1444 | COMMENT | 0+ | | 1445 | COMPLETED | 0 or 1 | | 1446 | CONTACT | 0+ | | 1447 | CREATED | 0 or 1 | | 1448 | DESCRIPTION | 0 or 1 | Can be null. | 1449 | DTEND | 0 or 1 | If present, DURATION MUST NOT be | 1450 | | | present. | 1451 | DURATION | 0 or 1 | If present, DTEND MUST NOT be | 1452 | | | present. | 1453 | GEO | 0 or 1 | | 1454 | LAST-MODIFIED | 0 or 1 | | 1455 | LOCATION | 0 or 1 | | 1456 | POLL-ITEM-ID | 0 | | 1457 | POLL-MODE | 0 or 1 | | 1458 | POLL-PROPERTIES | 0 or 1 | | 1459 | PRIORITY | 0 or 1 | | 1460 | RELATED-TO | 0+ | | 1461 | REQUEST-STATUS | 0 | | 1462 | RESOURCES | 0+ | | 1463 | STATUS | 0 or 1 | MAY be one of | 1464 | | | COMPLETED/CONFIRMED/CANCELLED. | 1465 | TRANSP | 0 or 1 | | 1466 | URL | 0 or 1 | | 1467 | IANA-PROPERTY | 0+ | | 1468 | X-PROPERTY | 0+ | | 1469 | | | | 1470 | VALARM | 0+ | | 1471 | | | | 1472 | VTIMEZONE | 0+ | MUST be present if any date/time | 1473 | | | refers to a timezone. | 1474 | | | | 1475 | IANA-COMPONENT | 0+ | | 1476 | X-COMPONENT | 0+ | | 1477 | | | | 1478 | VEVENT | 0+ | Depending upon the poll mode in | 1479 | | | effect there MAY be candidate | 1480 | | | components included in the poll | 1481 | | | component. If voting has already | 1482 | | | taken place, these components | 1483 | | | MUST include the VOTER property | 1484 | | | to indicate each voters current | 1485 | | | response. | 1486 | | | | 1487 | VFREEBUSY | 0 | | 1488 | | | | 1489 | VJOURNAL | 0+ | Depending upon the poll mode in | 1490 | | | effect there MAY be candidate | 1491 | | | components included in the poll | 1492 | | | component. If voting has already | 1493 | | | taken place, these components | 1494 | | | MUST include the VOTER property | 1495 | | | to indicate each voters current | 1496 | | | response. | 1497 | | | | 1498 | VTODO | 0+ | Depending upon the poll mode in | 1499 | | | effect there MAY be candidate | 1500 | | | components included in the poll | 1501 | | | component. If voting has already | 1502 | | | taken place, these components | 1503 | | | MUST include the VOTER property | 1504 | | | to indicate each voters current | 1505 | | | response. | 1506 +--------------------+----------+-----------------------------------+ 1508 6.3.1.2.1. Rescheduling a poll 1510 The "REQUEST" method may be used to reschedule a poll, that is force 1511 a revote. A rescheduled poll involves a change to the existing poll 1512 in terms of its time the components being voted on may have changed. 1513 If the recipient CUA of a "REQUEST" method finds that the "UID" 1514 property value already exists on the calendar but that the "SEQUENCE" 1515 (or "DTSTAMP") property value in the "REQUEST" method is greater than 1516 the value for the existing poll, then the "REQUEST" method describes 1517 a rescheduling of the poll. 1519 6.3.1.2.2. Updating or Reconfirmation of a Poll 1521 The "REQUEST" method may be used to update or reconfirm a poll. An 1522 update to an existing poll does not involve changes to the time or 1523 candidates, and might not involve a change to the location or 1524 description for the poll. If the recipient CUA of a "REQUEST" method 1525 finds that the "UID" property value already exists on the calendar 1526 and that the "SEQUENCE" property value in the "REQUEST" is the same 1527 as the value for the existing poll, then the "REQUEST" method 1528 describes an update of the poll details, but not a rescheduling of 1529 the POLL. 1531 The update "REQUEST" method is the appropriate response to a 1532 "REFRESH" method sent from a "Voter" to the "Organizer" of a poll. 1534 The "Organizer" of a poll may also send unsolicited "REQUEST" 1535 methods. The unsolicited "REQUEST" methods may be used to update the 1536 details of the poll without rescheduling it, to update the "RESPONSE" 1537 parameter of "Voters", or to reconfirm the poll. 1539 6.3.1.2.3. Confirmation of a Poll 1541 The "REQUEST" method may be used to confirm a poll, that is announce 1542 the winner in BASIC mode. The STATUS MUST be set to CONFIRMED and 1543 for BASIC mode a VPOLL POLL-WINNER property must be provided with the 1544 poll-id of the winning component. 1546 6.3.1.2.4. Closing a Poll 1548 The "REQUEST" method may be used to close a poll, that is indicate 1549 voting is completed. The STATUS MUST be set to COMPLETED. 1551 6.3.1.2.5. Delegating a POll to Another CU 1553 Some calendar and scheduling systems allow "Voters" to delegate the 1554 vote to another "Calendar User". iTIP supports this concept using the 1555 following workflow. Any "Voter" may delegate their right to vote in 1556 a poll to another CU. The implication is that the delegate 1557 participates in lieu of the original "Voter", NOT in addition to the 1558 "Voter". The delegator MUST notify the "Organizer" of this action 1559 using the steps outlined below. Implementations may support or 1560 restrict delegation as they see fit. For instance, some 1561 implementations may restrict a delegate from delegating a "REQUEST" 1562 to another CU. 1564 The "Delegator" of a poll forwards the existing "REQUEST" to the 1565 "Delegate". The "REQUEST" method MUST include a "Voter" property 1566 with the calendar address of the "Delegate". The "Delegator" MUST 1567 also send a "REPLY" method to the "Organizer" with the "Delegator's" 1568 "Voter" property "DELEGATED-TO" parameter set to the calendar address 1569 of the "Delegate". Also, a new "Voter" property for the "Delegate" 1570 MUST be included and must specify the calendar user address set in 1571 the "DELEGATED-TO" parameter, as above. 1573 In response to the request, the "Delegate" MUST send a "REPLY" method 1574 to the "Organizer", and optionally to the "Delegator". The "REPLY" 1575 method SHOULD include the "Voter" property with the "DELEGATED-FROM" 1576 parameter value of the "Delegator's" calendar address. 1578 The "Delegator" may continue to receive updates to the poll even 1579 though they will not be attending. This is accomplished by the 1580 "Delegator" setting their "role" attribute to "NON-PARTICIPANT" in 1581 the "REPLY" to the "Organizer". 1583 6.3.1.2.6. Changing the Organizer 1585 The situation may arise where the "Organizer" of a "VPOLL" is no 1586 longer able to perform the "Organizer" role and abdicates without 1587 passing on the "Organizer" role to someone else. When this occurs, 1588 the "Voters" of the "VPOLL" may use out-of-band mechanisms to 1589 communicate the situation and agree upon a new "Organizer". The new 1590 "Organizer" should then send out a new "REQUEST" with a modified 1591 version of the "VPOLL" in which the "SEQUENCE" number has been 1592 incremented and the "ORGANIZER" property has been changed to the new 1593 "Organizer". 1595 6.3.1.2.7. Sending on Behalf of the Organizer 1597 There are a number of scenarios that support the need for a "Calendar 1598 User" to act on behalf of the "Organizer" without explicit role 1599 changing. This might be the case if the CU designated as "Organizer" 1600 is sick or unable to perform duties associated with that function. 1601 In these cases, iTIP supports the notion of one CU acting on behalf 1602 of another. Using the "SENT-BY" parameter, a "Calendar User" could 1603 send an updated "VPOLL" "REQUEST". In the case where one CU sends on 1604 behalf of another CU, the "Voter" responses are still directed back 1605 towards the CU designated as "Organizer". 1607 6.3.1.2.8. Forwarding to an Uninvited CU 1609 A "Voter" invited to a "VPOLL" calendar component may send the 1610 "VPOLL" calendar component to another new CU not previously 1611 associated with the "VPOLL" calendar component. The current "Voter" 1612 participating in the "VPOLL" calendar component does this by 1613 forwarding the original "REQUEST" method to the new CU. The new CU 1614 can send a "REPLY" to the "Organizer" of the "VPOLL" calendar 1615 component. The reply contains a "Voter" property for the new CU. 1617 The "Organizer" ultimately decides whether or not the new CU becomes 1618 part of the poll and is not obligated to do anything with a "REPLY" 1619 from a new (uninvited) CU. If the "Organizer" does not want the new 1620 CU to be part of the poll, the new "Voter" property is not added to 1621 the "VPOLL" calendar component. The "Organizer" MAY send the CU a 1622 "CANCEL" message to indicate that they will not be added to the poll. 1624 If the "Organizer" decides to add the new CU, the new "Voter" 1625 property is added to the "VPOLL" calendar component. Furthermore, 1626 the "Organizer" is free to change any "Voter" property parameter from 1627 the values supplied by the new CU to something the "Organizer" 1628 considers appropriate. The "Organizer" SHOULD send the new CU a 1629 "REQUEST" message to inform them that they have been added. 1631 When forwarding a "REQUEST" to another CU, the forwarding "Voter" 1632 MUST NOT make changes to the original message. 1634 6.3.1.2.9. Updating Voter Status 1636 The "Organizer" of an poll may also request updated status from one 1637 or more "Voters". The "Organizer" sends a "REQUEST" method to the 1638 "Voter" and sets the "VOTER;RSVP=TRUE" property parameter. The 1639 "SEQUENCE" property for the poll is not changed from its previous 1640 value. A recipient will determine that the only change in the 1641 "REQUEST" is that their "RSVP" property parameter indicates a request 1642 for updated status. The recipient SHOULD respond with a "REPLY" 1643 method indicating their current vote with respect to the "REQUEST". 1645 6.3.1.3. REPLY 1647 The "REPLY" method in a "VPOLL" calendar component is used to respond 1648 (e.g., accept or decline) to a "REQUEST" or to reply to a delegation 1649 "REQUEST". When used to provide a delegation response, the 1650 "Delegator" SHOULD include the calendar address of the "Delegate" on 1651 the "DELEGATED-TO" property parameter of the "Delegator's" "Voter" 1652 property. The "Delegate" SHOULD include the calendar address of the 1653 "Delegator" on the "DELEGATED-FROM" property parameter of the 1654 "Delegate's" "Voter" property. 1656 The "REPLY" method is also used when processing of a "REQUEST" fails. 1657 Depending on the value of the "REQUEST-STATUS" property, no action 1658 may have been performed. 1660 The "Organizer" of a poll may receive the "REPLY" method from a CU 1661 not in the original "REQUEST". For example, a "REPLY" may be 1662 received from a "Delegate" to a poll. In addition, the "REPLY" 1663 method may be received from an unknown CU (a "Party Crasher"). This 1664 uninvited "Voter" may be accepted, or the "Organizer" may cancel the 1665 poll for the uninvited "Voter" by sending a "CANCEL" method to the 1666 uninvited "Voter". 1668 A "Voter" MAY include a message to the "Organizer" using the 1669 "COMMENT" property. For example, if the user indicates a low 1670 interest and wants to let the "Organizer" know why, the reason can be 1671 expressed in the "COMMENT" property value. 1673 The "Organizer" may also receive a "REPLY" from one CU on behalf of 1674 another. Like the scenario enumerated above for the "Organizer", 1675 "Voters" may have another CU respond on their behalf. This is done 1676 using the "SENT-BY" parameter. 1678 The optional properties listed in the table below (those listed as 1679 "0+" or "0 or 1") MUST NOT be changed from those of the original 1680 request. (But see comments on VFREEBUSY and VAVAILABILITY) 1682 This method type is an iCalendar object that conforms to the 1683 following property constraints: 1685 +--------------------------------------------+ 1686 | Constraints for a METHOD:REPLY of a VPOLL | 1687 +--------------------------------------------+ 1688 +--------------------------------------------+ 1690 +--------------------+----------+-----------------------------------+ 1691 | Component/Property | Presence | Comment | 1692 +--------------------+----------+-----------------------------------+ 1693 | METHOD | 1 | MUST be REPLY. | 1694 | | | | 1695 | VPOLL | 1+ | All components MUST have the same | 1696 | | | UID. | 1697 | VOTER | 1 | MUST be the address of the Voter | 1698 | | | replying. | 1699 | DTSTAMP | 1 | | 1700 | ORGANIZER | 1 | | 1701 | UID | 1 | MUST be the UID of the original | 1702 | | | REQUEST. | 1703 | SEQUENCE | 0 or 1 | If non-zero, MUST be the sequence | 1704 | | | number of the original REQUEST. | 1705 | | | MAY be present if 0. | 1706 | ACCEPT-RESPONSE | 0 or 1 | | 1707 | ATTACH | 0+ | | 1708 | CATEGORIES | 0+ | | 1709 | CLASS | 0 or 1 | | 1710 | COMMENT | 0+ | | 1711 | COMPLETED | 0 or 1 | | 1712 | CONTACT | 0+ | | 1713 | CREATED | 0 or 1 | | 1714 | DESCRIPTION | 0 or 1 | | 1715 | DTEND | 0 or 1 | If present, DURATION MUST NOT be | 1716 | | | present. | 1717 | DTSTART | 0 or 1 | | 1718 | DURATION | 0 or 1 | If present, DTEND MUST NOT be | 1719 | | | present. | 1720 | GEO | 0 or 1 | | 1721 | LAST-MODIFIED | 0 or 1 | | 1722 | LOCATION | 0 or 1 | | 1723 | POLL-ITEM-ID | 1+ | One per item being voted on. | 1724 | POLL-MODE | 0 | | 1725 | POLL-PROPERTIES | 0 | | 1726 | PRIORITY | 0 or 1 | | 1727 | RELATED-TO | 0+ | | 1728 | RESOURCES | 0+ | | 1729 | REQUEST-STATUS | 0+ | | 1730 | STATUS | 0 or 1 | | 1731 | SUMMARY | 0 or 1 | | 1732 | TRANSP | 0 or 1 | | 1733 | URL | 0 or 1 | | 1734 | IANA-PROPERTY | 0+ | | 1735 | X-PROPERTY | 0+ | | 1736 | | | | 1737 | VALARM | 0 | | 1738 | | | | 1739 | VTIMEZONE | 0 or 1 | MUST be present if any date/time | 1740 | | | refers to a timezone. | 1741 | | | | 1742 | IANA-COMPONENT | 0+ | | 1743 | X-COMPONENT | 0+ | | 1744 | | | | 1745 | VEVENT | 0 | | 1746 | | | | 1747 | VFREEBUSY | 0 or 1 | A voter may respond with a | 1748 | | | VFREEBUSY component indicating | 1749 | | | that the ORGANIZER may select | 1750 | | | some other time which is not | 1751 | | | marked as busy. | 1752 | | | | 1753 | VAVAILABILITY | 0 | A voter may respond with a | 1754 | | | VAVAILABILITY component | 1755 | | | indicating that the ORGANIZER may | 1756 | | | select some other time which is | 1757 | | | shown as available. | 1758 | | | | 1759 | VJOURNAL | 0 | | 1760 | | | | 1761 | VTODO | 0 | | 1762 +--------------------+----------+-----------------------------------+ 1764 6.3.1.4. CANCEL 1766 The "CANCEL" method in a "VPOLL" calendar component is used to send a 1767 cancellation notice of an existing poll request to the affected 1768 "Voters". The message is sent by the "Organizer" of the poll. 1770 The "Organizer" MUST send a "CANCEL" message to each "Voter" affected 1771 by the cancellation. This can be done using a single "CANCEL" 1772 message for all "Voters" or by using multiple messages with different 1773 subsets of the affected "Voters" in each. 1775 When a "VPOLL" is cancelled, the "SEQUENCE" property value MUST be 1776 incremented as described in Section 6.2.3. 1778 Once a CANCEL message has been sent to all voters no further voting 1779 may take place. The poll is considered closed. 1781 This method type is an iCalendar object that conforms to the 1782 following property constraints: 1784 +---------------------------------------------+ 1785 | Constraints for a METHOD:CANCEL of a VPOLL | 1786 +---------------------------------------------+ 1787 +---------------------------------------------+ 1789 +--------------------+----------+-----------------------------------+ 1790 | Component/Property | Presence | Comment | 1791 +--------------------+----------+-----------------------------------+ 1792 | METHOD | 1 | MUST be CANCEL. | 1793 | | | | 1794 | VPOLL | 1+ | All must have the same UID. | 1795 | VOTER | 0+ | MUST include some or all Voters | 1796 | | | being removed from the poll. | 1797 | | | MUST include some or all Voters | 1798 | | | if the entire poll is cancelled. | 1799 | UID | 1 | MUST be the UID of the original | 1800 | | | REQUEST. | 1801 | DTSTAMP | 1 | | 1802 | ORGANIZER | 1 | | 1803 | SEQUENCE | 1 | | 1804 | ATTACH | 0+ | | 1805 | ACCEPT-RESPONSE | 0 | | 1806 | COMMENT | 0+ | | 1807 | COMPLETED | 0 or 1 | | 1808 | CATEGORIES | 0+ | | 1809 | CLASS | 0 or 1 | | 1810 | CONTACT | 0+ | | 1811 | CREATED | 0 or 1 | | 1812 | DESCRIPTION | 0 or 1 | | 1813 | DTEND | 0 or 1 | If present, DURATION MUST NOT be | 1814 | | | present. | 1815 | DTSTART | 0 or 1 | | 1816 | DURATION | 0 or 1 | If present, DTEND MUST NOT be | 1817 | | | present. | 1818 | GEO | 0 or 1 | | 1819 | LAST-MODIFIED | 0 or 1 | | 1820 | LOCATION | 0 or 1 | | 1821 | POLL-ITEM-ID | 0 | | 1822 | POLL-MODE | 0 | | 1823 | POLL-PROPERTIES | 0 | | 1824 | PRIORITY | 0 or 1 | | 1825 | RELATED-TO | 0+ | | 1826 | RESOURCES | 0+ | | 1827 | STATUS | 0 or 1 | MUST be set to CANCELLED to | 1828 | | | cancel the entire event. If | 1829 | | | uninviting specific Attendees, | 1830 | | | then MUST NOT be included. | 1831 | SUMMARY | 0 or 1 | | 1832 | TRANSP | 0 or 1 | | 1833 | URL | 0 or 1 | | 1834 | IANA-PROPERTY | 0+ | | 1835 | X-PROPERTY | 0+ | | 1836 | REQUEST-STATUS | 0 | | 1837 | | | | 1838 | VALARM | 0 | | 1839 | | | | 1840 | VTIMEZONE | 0+ | MUST be present if any date/time | 1841 | | | refers to a timezone. | 1842 | | | | 1843 | IANA-COMPONENT | 0+ | | 1844 | X-COMPONENT | 0+ | | 1845 | | | | 1846 | VTODO | 0 | | 1847 | | | | 1848 | VJOURNAL | 0 | | 1849 | | | | 1850 | VEVENT | 0 | | 1851 | | | | 1852 | VFREEBUSY | 0 | | 1853 +--------------------+----------+-----------------------------------+ 1855 6.3.1.5. REFRESH 1857 The "REFRESH" method in a "VPOLL" calendar component is used by 1858 "Voters" of an existing event to request an updated description from 1859 the poll "Organizer". The "REFRESH" method must specify the "UID" 1860 property of the poll to update. The "Organizer" responds with the 1861 latest description and version of the poll. 1863 This method type is an iCalendar object that conforms to the 1864 following property constraints: 1866 +----------------------------------------------+ 1867 | Constraints for a METHOD:REFRESH of a VPOLL | 1868 +----------------------------------------------+ 1869 +----------------------------------------------+ 1871 +--------------------+----------+-----------------------------------+ 1872 | Component/Property | Presence | Comment | 1873 +--------------------+----------+-----------------------------------+ 1874 | METHOD | 1 | MUST be REFRESH. | 1875 | | | | 1876 | VPOLL | 1 | | 1877 | VOTER | 1 | MUST be the address of requester. | 1878 | DTSTAMP | 1 | | 1879 | ORGANIZER | 1 | | 1880 | UID | 1 | MUST be the UID associated with | 1881 | | | original REQUEST. | 1882 | COMMENT | 0+ | | 1883 | COMPLETED | 0 | | 1884 | IANA-PROPERTY | 0+ | | 1885 | X-PROPERTY | 0+ | | 1886 | ACCEPT-RESPONSE | 0 | | 1887 | ATTACH | 0 | | 1888 | CATEGORIES | 0 | | 1889 | CLASS | 0 | | 1890 | CONTACT | 0 | | 1891 | CREATED | 0 | | 1892 | DESCRIPTION | 0 | | 1893 | DTEND | 0 | | 1894 | DTSTART | 0 | | 1895 | DURATION | 0 | | 1896 | GEO | 0 | | 1897 | LAST-MODIFIED | 0 | | 1898 | LOCATION | 0 | | 1899 | POLL-ITEM-ID | 0 | | 1900 | POLL-MODE | 0 | | 1901 | POLL-PROPERTIES | 0 | | 1902 | PRIORITY | 0 | | 1903 | RELATED-TO | 0 | | 1904 | REQUEST-STATUS | 0 | | 1905 | RESOURCES | 0 | | 1906 | SEQUENCE | 0 | | 1907 | STATUS | 0 | | 1908 | SUMMARY | 0 | | 1909 | URL | 0 | | 1910 | | | | 1911 | VALARM | 0 | | 1912 | | | | 1913 | VTIMEZONE | 0+ | | 1914 | | | | 1915 | IANA-COMPONENT | 0+ | | 1916 | X-COMPONENT | 0+ | | 1917 | | | | 1918 | VTODO | 0 | | 1919 | | | | 1920 | VJOURNAL | 0 | | 1921 | | | | 1922 | VEVENT | 0 | | 1923 | | | | 1924 | VFREEBUSY | 0 | | 1925 +--------------------+----------+-----------------------------------+ 1927 6.3.1.6. POLLSTATUS 1929 The "POLLSTATUS" method in a "VPOLL" calendar component is used to 1930 inform recipients of the current status of the poll in a compact 1931 manner. The "Organizer" MUST be present in the confirmed poll 1932 component. "Voters" MUST NOT be present. The selected component(s) 1933 according to the poll mode MUST also be present in the poll 1934 component. Clients receiving this message may store the confirmed 1935 items in their calendars. 1937 This method type is an iCalendar object that conforms to the 1938 following property constraints: 1940 +-------------------------------------------------+ 1941 | Constraints for a METHOD:POLLSTATUS of a VPOLL | 1942 +-------------------------------------------------+ 1943 +-------------------------------------------------+ 1945 +--------------------+----------+-----------------------------------+ 1946 | Component/Property | Presence | Comment | 1947 +--------------------+----------+-----------------------------------+ 1948 | METHOD | 1 | MUST equal POLLSTATUS. | 1949 | | | | 1950 | VPOLL | 1+ | | 1951 | COMPLETED | 0 or 1 | Only present for a completed poll | 1952 | DTSTAMP | 1 | | 1953 | DTSTART | 0 or 1 | | 1954 | ORGANIZER | 1 | | 1955 | SUMMARY | 1 | Can be null. | 1956 | VOTER | 1+ | | 1957 | UID | 1 | | 1958 | SEQUENCE | 0 or 1 | MUST be present if value is | 1959 | | | greater than 0; MAY be present if | 1960 | | | 0. | 1961 | ACCEPT-RESPONSE | 0 | | 1962 | ATTACH | 0 | | 1963 | CATEGORIES | 0 | | 1964 | CLASS | 0 | | 1965 | COMMENT | 0+ | | 1966 | CONTACT | 0 | | 1967 | CREATED | 0 or 1 | | 1968 | DESCRIPTION | 0 or 1 | Can be null. | 1969 | DTEND | 0 or 1 | If present, DURATION MUST NOT be | 1970 | | | present. | 1971 | DURATION | 0 or 1 | If present, DTEND MUST NOT be | 1972 | | | present. | 1973 | LAST-MODIFIED | 0 or 1 | | 1974 | POLL-ITEM-ID | 0 | | 1975 | POLL-MODE | 0 or 1 | | 1976 | POLL-PROPERTIES | 0 | | 1977 | PRIORITY | 0 or 1 | | 1978 | RELATED-TO | 0+ | | 1979 | RESOURCES | 0+ | | 1980 | STATUS | 0 or 1 | MAY be one of | 1981 | | | TENTATIVE/CONFIRMED/CANCELLED. | 1982 | URL | 0 or 1 | | 1983 | IANA-PROPERTY | 0+ | | 1984 | X-PROPERTY | 0+ | | 1985 | REQUEST-STATUS | 0 | | 1986 | | | | 1987 | VALARM | 0+ | | 1988 | | | | 1989 | VEVENT | 0+ | All candidate components MUST be | 1990 | | | present but in a reduced form | 1991 | | | sufficient to provide the voting | 1992 | | | status. | 1993 | | | | 1994 | VFREEBUSY | 0 | | 1995 | | | | 1996 | VJOURNAL | 0+ | All candidate components MUST be | 1997 | | | present but in a reduced form | 1998 | | | sufficient to provide the voting | 1999 | | | status. | 2000 | | | | 2001 | VTODO | 0+ | All candidate components MUST be | 2002 | | | present but in a reduced form | 2003 | | | sufficient to provide the voting | 2004 | | | status. | 2005 | | | | 2006 | VTIMEZONE | 0+ | MUST be present if any date/time | 2007 | | | refers to a timezone. | 2008 | | | | 2009 | IANA-COMPONENT | 0+ | | 2010 | X-COMPONENT | 0+ | | 2011 +--------------------+----------+-----------------------------------+ 2013 7. CalDAV Extensions 2015 This specification extends [RFC4791] in that it defines a new 2016 component and new iCalendar properties to be supported and requires 2017 extra definitions related to time-ranges and reports. 2019 Additionally, it extends [RFC6638] as it a VPOLL component is a 2020 schedulable entity. 2022 7.1. Calendar Collection Properties 2024 This section defines new CalDAV properties for calendar collections. 2026 7.1.1. CALDAV:supported-vpoll-component-sets 2028 Name: supported-vpoll-component-sets 2030 Namespace: urn:ietf:params:xml:ns:caldav 2032 Purpose: Specifies the calendar component types (e.g., VEVENT, 2033 VTODO, etc.) and combination of types that may be included in a 2034 VPOLL component. 2036 Conformance: This property MAY be defined on any calendar 2037 collection. If defined, it MUST be protected and SHOULD NOT be 2038 returned by a PROPFIND DAV:allprop request (as defined in 2039 Section 12.14.1 of [RFC2518]). 2041 Description: The CALDAV:supported-vpoll-component-sets property is 2042 used to specify restrictions on the calendar component types that 2043 VPOLL components may contain in a calendar collection. 2045 It also specifies the combination of allowed component types. 2047 Any attempt by the client to store VPOLL components with component 2048 types or combinations of types not listed in this property, if it 2049 exists, MUST result in an error, with the CALDAV:supported-vpoll- 2050 component-sets precondition Section 7.2 being violated. Since 2051 this property is protected, it cannot be changed by clients using 2052 a PROPPATCH request. However, clients can initialize the value of 2053 this property when creating a new calendar collection with 2054 MKCALENDAR. In the absence of this property, the server MUST 2055 accept all component types, and the client can assume that all 2056 component types are accepted. 2058 Definition: 2060 2063 2065 Example: 2067 2070 2071 2072 2073 2074 2075 2077 2078 2079 2080 2081 2083 2084 2085 2086 2088 2089 2090 2091 2092 2094 7.1.2. CALDAV:vpoll-max-items 2096 Name: vpoll-max-items 2098 Namespace: urn:ietf:params:xml:ns:caldav 2100 Purpose: Provides a numeric value indicating the maximum number of 2101 items that may be contained in any instance of a VPOLL calendar 2102 object resource stored in the calendar collection. 2104 Conformance: This property MAY be defined on any calendar 2105 collection. If defined, it MUST be protected and SHOULD NOT be 2106 returned by a PROPFIND DAV:allprop request (as defined in 2107 Section 12.14.1 of [RFC2518]). 2109 Description: The CALDAV:vpoll-max-items is used to specify a numeric 2110 value that indicates the maximum number of iCalendar components in 2111 any one instance of a VPOLL calendar object resource stored in a 2112 calendar collection. Any attempt to store a calendar object 2113 resource with more components per instance than this value MUST 2114 result in an error, with the CALDAV: vpoll-max-items precondition 2115 Section 7.2 being violated. In the absence of this property, the 2116 client can assume that the server can handle any number of items 2117 in a VPOLL calendar component. 2119 Definition: 2121 2122 PCDATA value: a numeric value (integer greater than zero) 2124 Example: 2126 25 2130 7.1.3. CALDAV:vpoll-max-active 2132 Name: vpoll-max-active 2134 Namespace: urn:ietf:params:xml:ns:caldav 2136 Purpose: Provides a numeric value indicating the maximum number of 2137 active vpolls at any one time. 2139 Conformance: This property MAY be defined on any calendar 2140 collection. If defined, it MUST be protected and SHOULD NOT be 2141 returned by a PROPFIND DAV:allprop request (as defined in 2142 Section 12.14.1 of [RFC2518]). 2144 Description: The CALDAV:vpoll-max-active is used to specify a 2145 numeric value that indicates the maximum number of active VPOLLs 2146 at any one time. Any attempt to store a new active VPOLL calendar 2147 object resource which results in exceeding this limit MUST result 2148 in an error, with the CALDAV: vpoll-max-active precondition 2149 Section 7.2 being violated. In the absence of this property, the 2150 client can assume that the server can handle any number of active 2151 VPOLLs. 2153 Definition: 2155 2156 PCDATA value: a numeric value (integer greater than zero) 2158 Example: 2160 25 2164 7.1.4. CALDAV:vpoll-max-voters 2166 Name: vpoll-max-voters 2168 Namespace: urn:ietf:params:xml:ns:caldav 2170 Purpose: Provides a numeric value indicating the maximum number of 2171 voters for any instance of a VPOLL calendar object resource stored 2172 in the calendar collection. 2174 Conformance: This property MAY be defined on any calendar 2175 collection. If defined, it MUST be protected and SHOULD NOT be 2176 returned by a PROPFIND DAV:allprop request (as defined in 2177 Section 12.14.1 of [RFC2518]). 2179 Description: The CALDAV:vpoll-max-voters is used to specify a 2180 numeric value that indicates the maximum number of VOTER 2181 properties for any one instance of a VPOLL calendar object 2182 resource stored in a calendar collection. Any attempt to store a 2183 calendar object resource with more VOTER properties per instance 2184 than this value MUST result in an error, with the CALDAV: vpoll- 2185 max-voters precondition Section 7.2 being violated. In the 2186 absence of this property, the client can assume that the server 2187 can handle any number of voters in a VPOLL calendar component. 2189 Definition: 2191 2192 PCDATA value: a numeric value (integer greater than zero) 2194 Example: 2196 25 2200 7.1.5. CalDAV:even-more-properties 2202 1. vpoll-supported-mode poll options - e.g "vpoll-basic" 2204 7.1.6. Extensions to CalDAV scheduling 2206 This specification extends [RFC6638]. 2208 Each section of Appendix A "Scheduling Privileges Summary" is 2209 extended to include VPOLL. 2211 Any reference to the ATTENDEE property should be read to include the 2212 VOTER property. That is, for scheduling purposes the VOTER property 2213 is handled in exactly the same manner as the ATTENDEE property. 2215 7.2. Additional Preconditions for PUT, COPY, and MOVE 2217 This specification creates additional Preconditions for PUT, COPY, 2218 and MOVE methods. These preconditions apply when a PUT operation of 2219 a VPOLL calendar object resource into a calendar collection occurs, 2220 or when a COPY or MOVE operation of a calendar object resource into a 2221 calendar collection occurs, or when a COPY or MOVE operation occurs 2222 on a calendar collection. 2224 The new preconditions are: 2226 (CALDAV:supported-vpoll-component-sets): The VPOLL resource 2227 submitted in the PUT request, or targeted by a COPY or MOVE 2228 request, MUST contain a type or combination of calendar component 2229 that is supported in the targeted calendar collection; 2231 (CALDAV:vpoll-max-items): The VPOLL resource submitted in the PUT 2232 request, or targeted by a COPY or MOVE request, MUST have a number 2233 of sub-components (excluding VTIMEZONE) less than or equal to the 2234 value of the CALDAV:vpoll-max-items property value Section 7.1.2 2235 on the calendar collection where the resource will be stored; 2237 (CALDAV:vpoll-max-active): The PUT request, or COPY or MOVE request, 2238 MUST not result in the number of active VPOLLs being greater than 2239 the value of the CALDAV:vpoll-max-active property value 2240 Section 7.1.3 on the calendar collection where the resource will 2241 be stored; 2243 (CALDAV:vpoll-max-voters): The VPOLL resource submitted in the PUT 2244 request, or targeted by a COPY or MOVE request, MUST have a number 2245 of VOTER properties less than or equal to the value of the 2246 CALDAV:vpoll-max-voters property value Section 7.1.4 on the 2247 calendar collection where the resource will be stored; 2249 7.3. CalDAV:calendar-query Report 2251 This allows the retrieval of VPOLLs and their included components. 2252 The query specification allows queries to be directed at the 2253 contained sub-components. For VPOLL queries this feature is 2254 disallowed. Time-range queries can only target the vpoll component 2255 itself. 2257 7.3.1. Example: Partial Retrieval of VPOLL 2259 In this example, the client requests the server to return specific 2260 components and properties of the VPOLL components that overlap the 2261 time range from December 4, 2012, at 00:00:00 A.M. UTC to December 2262 5, 2012, at 00:00:00 A.M. UTC. In addition, the DAV:getetag 2263 property is also requested and returned as part of the response. 2264 Note that due to the CALDAV: calendar-data element restrictions, the 2265 DTSTAMP property in VPOLL components has not been returned, and the 2266 only property returned in the VCALENDAR object is VERSION. 2268 >> Request << 2270 REPORT /cyrus/work/ HTTP/1.1 2271 Host: cal.example.com 2272 Depth: 1 2273 Content-Type: application/xml; charset="utf-8" 2274 Content-Length: xxxx 2276 2277 2279 2280 2281 2282 2283 2284 2285 2286 2287 2288 2289 2290 2292 2293 2294 2295 2296 2297 2298 2300 2301 2302 2303 2305 >> Response << 2307 HTTP/1.1 207 Multi-Status 2308 Date: Sat, 11 Nov 2012 09:32:12 GMT 2309 Content-Type: application/xml; charset="utf-8" 2310 Content-Length: xxxx 2312 2313 2315 2316 http://cal.example.com/cyrus/work/poll2.ics 2317 2318 2319 "fffff-abcd2" 2320 BEGIN:VCALENDAR 2321 VERSION:2.0 2322 BEGIN:VPOLL 2323 DTSTART;TZID=US/Eastern:20121202T120000 2324 DURATION:PT4D 2325 SUMMARY:Poll #2 2326 UID:00959BC664CA650E933C892C@example.com 2327 END:VPOLL 2328 END:VCALENDAR 2329 2330 2331 HTTP/1.1 200 OK 2332 2333 2334 2335 http://cal.example.com/cyrus/work/poll3.ics 2336 2337 2338 "fffff-abcd3" 2339 BEGIN:VCALENDAR 2341 VERSION:2.0 2342 PRODID:-//Example Corp.//CalDAV Client//EN 2343 BEGIN:VPOLL 2344 DTSTART;TZID=US/Eastern:20121204T100000 2345 DURATION:PT4D 2346 SUMMARY:Poll #3 2347 UID:DC6C50A017428C5216A2F1CD@example.com 2348 END:VPOLL 2349 END:VCALENDAR 2350 2351 2352 HTTP/1.1 200 OK 2353 2354 2355 2357 7.4. CalDAV time ranges 2359 Section 9.9 "CALDAV:time-range XML Element" in [RFC4791] describes 2360 how to specify time ranges to limit the set of calendar components 2361 returned by the server. This specification extends [RFC4791] to 2362 describe the meaning of time ranges for VPOLL 2364 A VPOLL component is said to overlap a given time range if the 2365 condition for the corresponding component state specified in the 2366 table below is satisfied. The conditions depend on the presence of 2367 the DTSTART, DURATION, DTEND, COMPLETED and CREATED properties in the 2368 VPOLL component. Note that, as specified above, the DTEND value MUST 2369 be a DATE-TIME value equal to or after the DTSTART value if 2370 specified. 2372 +-------------------------------------------------------------------+ 2373 | VPOLL has the DTSTART property? | 2374 | +---------------------------------------------------------------+ 2375 | | VPOLL has the DURATION property? | 2376 | | +-----------------------------------------------------------+ 2377 | | | VPOLL has the DTEND property? | 2378 | | | +-------------------------------------------------------+ 2379 | | | | VPOLL has the COMPLETED property? | 2380 | | | | +---------------------------------------------------+ 2381 | | | | | VPOLL has the CREATED property? | 2382 | | | | | +-----------------------------------------------+ 2383 | | | | | | Condition to evaluate | 2384 +---+---+---+---+---+-----------------------------------------------+ 2385 | Y | Y | N | * | * | (start <= DTSTART+DURATION) AND | 2386 | | | | | | ((end > DTSTART) OR | 2387 | | | | | | (end >= DTSTART+DURATION)) | 2388 +---+---+---+---+---+-----------------------------------------------+ 2389 | Y | N | Y | * | * | ((start < DTEND) OR (start <= DTSTART)) | 2390 | | | | | | AND | 2391 | | | | | | ((end > DTSTART) OR (end >= DTEND)) | 2392 +---+---+---+---+---+-----------------------------------------------+ 2393 | Y | N | N | * | * | (start <= DTSTART) AND (end > DTSTART) | 2394 +---+---+---+---+---+-----------------------------------------------+ 2395 | N | N | Y | * | * | (start < DTEND) AND (end >= DTEND) | 2396 +---+---+---+---+---+-----------------------------------------------+ 2397 | N | N | N | Y | Y | ((start <= CREATED) OR (start <= COMPLETED))| 2398 | | | | | | AND | 2399 | | | | | | ((end >= CREATED) OR (end >= COMPLETED))| 2400 +---+---+---+---+---+-----------------------------------------------+ 2401 | N | N | N | Y | N | (start <= COMPLETED) AND (end >= COMPLETED) | 2402 +---+---+---+---+---+-----------------------------------------------+ 2403 | N | N | N | N | Y | (end > CREATED) | 2404 +---+---+---+---+---+-----------------------------------------------+ 2405 | N | N | N | N | N | TRUE | 2406 +---+---+---+---+---+-----------------------------------------------+ 2408 8. Security Considerations 2410 Applications using these property need to be aware of the risks 2411 entailed in using the URIs provided as values. See [RFC3986] for a 2412 discussion of the security considerations relating to URIs. 2414 9. IANA Considerations 2415 9.1. Parameter Registrations 2417 This document defines the following new iCalendar property parameters 2418 to be added to the registry defined in Section 8.2.4 of [RFC5545]: 2420 +--------------------+---------+------------------------+ 2421 | Property Parameter | Status | Reference | 2422 +--------------------+---------+------------------------+ 2423 | REQUIRED | Current | RFCXXXX, Section 4.3.1 | 2424 | STAY-INFORMED | Current | RFCXXXX, Section 4.3.2 | 2425 +--------------------+---------+------------------------+ 2427 9.2. Property Registrations 2429 This document defines the following new iCalendar properties to be 2430 added to the registry defined in Section 8.2.3 of [RFC5545]: 2432 +-----------------+---------+------------------------+ 2433 | Property | Status | Reference | 2434 +-----------------+---------+------------------------+ 2435 | ACCEPT-RESPONSE | Current | RFCXXXX, Section 4.4.1 | 2436 | POLL-ITEM-ID | Current | RFCXXXX, Section 4.4.3 | 2437 | POLL-MODE | Current | RFCXXXX, Section 4.4.4 | 2438 | POLL-PROPERTIES | Current | RFCXXXX, Section 4.4.5 | 2439 | POLL-WINNER | Current | RFCXXXX, Section 4.4.6 | 2440 | RESPONSE | Current | RFCXXXX, Section 4.4.8 | 2441 | VOTER | Current | RFCXXXX, Section 4.4.9 | 2442 +-----------------+---------+------------------------+ 2444 9.3. POLL-MODE Registration Template 2446 A poll mode is defined by completing the following template. 2448 Poll mode name: The name of the poll mode. 2450 Purpose: The purpose of the poll mode. Give a short but clear 2451 description. 2453 Reference: A reference to the RFC in which the poll mode is defined 2455 9.4. POLL-MODE Registrations 2457 This document defines the following registered poll modes. 2459 +----------+--------------------------------------------+-----------+ 2460 | Poll | Purpose | Reference | 2461 | mode | | | 2462 | name | | | 2463 +----------+--------------------------------------------+-----------+ 2464 | BASIC | To provide simple voting for a single | Current | 2465 | | outcome from a number of candidates. | | 2466 +----------+--------------------------------------------+-----------+ 2468 10. Acknowledgements 2470 The authors would like to thank the members of the Calendaring and 2471 Scheduling Consortium Freebusy technical committee and the following 2472 individuals for contributing their ideas and support: 2474 ... 2476 The authors would also like to thank the Calendaring and Scheduling 2477 Consortium for advice with this specification. 2479 11. Normative References 2481 [I-D.daboo-icalendar-extensions] 2482 Daboo, C., "New Properties for iCalendar", draft-daboo- 2483 icalendar-extensions-09 (work in progress), July 2014. 2485 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2486 Requirement Levels", BCP 14, RFC 2119, 2487 DOI 10.17487/RFC2119, March 1997, 2488 . 2490 [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an 2491 IANA Considerations Section in RFCs", RFC 2434, 2492 DOI 10.17487/RFC2434, October 1998, 2493 . 2495 [RFC2518] Goland, Y., Whitehead, E., Faizi, A., Carter, S., and D. 2496 Jensen, "HTTP Extensions for Distributed Authoring -- 2497 WEBDAV", RFC 2518, DOI 10.17487/RFC2518, February 1999, 2498 . 2500 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 2501 DOI 10.17487/RFC3688, January 2004, 2502 . 2504 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 2505 Resource Identifier (URI): Generic Syntax", STD 66, 2506 RFC 3986, DOI 10.17487/RFC3986, January 2005, 2507 . 2509 [RFC4589] Schulzrinne, H. and H. Tschofenig, "Location Types 2510 Registry", RFC 4589, DOI 10.17487/RFC4589, July 2006, 2511 . 2513 [RFC4791] Daboo, C., Desruisseaux, B., and L. Dusseault, 2514 "Calendaring Extensions to WebDAV (CalDAV)", RFC 4791, 2515 DOI 10.17487/RFC4791, March 2007, 2516 . 2518 [RFC5545] Desruisseaux, B., Ed., "Internet Calendaring and 2519 Scheduling Core Object Specification (iCalendar)", 2520 RFC 5545, DOI 10.17487/RFC5545, September 2009, 2521 . 2523 [RFC5546] Daboo, C., Ed., "iCalendar Transport-Independent 2524 Interoperability Protocol (iTIP)", RFC 5546, 2525 DOI 10.17487/RFC5546, December 2009, 2526 . 2528 [RFC6047] Melnikov, A., Ed., "iCalendar Message-Based 2529 Interoperability Protocol (iMIP)", RFC 6047, 2530 DOI 10.17487/RFC6047, December 2010, 2531 . 2533 [RFC6638] Daboo, C. and B. Desruisseaux, "Scheduling Extensions to 2534 CalDAV", RFC 6638, DOI 10.17487/RFC6638, June 2012, 2535 . 2537 [W3C.REC-xml-20060816] 2538 Bray, T., Paoli, J., Sperberg-McQueen, M., Maler, E., and 2539 F. Yergeau, "Extensible Markup Language (XML) 1.0 (Fourth 2540 Edition)", World Wide Web Consortium Recommendation REC- 2541 xml-20060816, August 2006, 2542 . 2544 Appendix A. Open issues 2546 Notifications: Need to do a section on what Notifications to 2547 support. 2548 A. VPOLL is about to end and you haven't voted on it yet. 2549 Instead reuse VALARMS to notify the user? 2551 Future: Restarting a confirmed/completed VPOLL What to do with 2552 changes to STATUS:CONFIRMED? Allow them or not? What do to that 2553 poll had a winning event or todo. 2554 Stress VPOLL UID MUST be unique 2555 Changing status back from CONFIRMED MUST adjust status of any 2556 events booked as a result of confirmation. 2557 MUST winning event be cancelled for POLL-MODE basic? No - VOTER 2558 has indicated now unable to attend - want to revote 2560 Future: Voting on a confirmed/completed VPOLL Can a VOTER vote after 2561 completion? May be unable to attend and wants to indicate. 2562 Requires retention of VPOLL 2563 retention period 2564 Removed status 2566 ORGANIZER/ATTENDEE validity Can a user create a poll with scheduled 2567 events where that user's isn't the organizer of the poll? So is 2568 there a requirement that the account that poll is on is able to 2569 create each one of the resources in the poll? i.e. I can't create 2570 a poll with a set of events where I am just the attendee of the 2571 events. Are there any other restrictions for components in a 2572 VPOLL? 2573 Add to security consideration 2575 Update to existing event after poll confirm When voting on existing 2576 event - winning properties ONLY are merged in to the real event. 2578 Need to write down what isn't valid in a VPOLL 2579 a. Can't change POLL-MODE 2581 Guide for ATTENDEE roles 2582 chair, NON-PARTICIPANT etc 2584 ? - some iTip notes On confirm - send itip if appropriate (PUBLISH) 2585 - all non-participating - shared - feeds 2586 Organizer can specify where result is? 2587 Confirm can specify that itip is sent - ITIP / NONE - parameter ? 2588 on POLL-WINNER 2590 Need to add example of freebusy in response 2591 BEGIN:VCALENDAR 2592 VERSION:2.0 2593 PRODID:-//BedeworkCaldavTest//BedeworkCaldavTest 2594 METHOD: REPLY 2595 BEGIN:VPOLL 2596 ORGANIZER:mailto:douglm@mysite.edu 2597 VOTER:mailto:eric@example.com 2598 UID:sched01-1234567890 2599 DTSTAMP:20120101T010000Z 2600 SEQUENCE:0 2601 SUMMARY:What to do this week 2602 BEGIN:VFREEBUSY 2603 ....... 2604 END:VFREEBUSY 2605 END:VPOLL 2606 END:VCALENDAR 2608 Appendix B. Change log 2610 V03: 2014-10-28 MD 2612 o Add VVOTER and VOTE components. 2614 o Add RESPONSE property. 2616 o Remove RESPONSE parameter from VOTER. 2618 V03: 2014-05-12 MD 2620 o Add reply-url property and required parameter. 2622 o Fix ACCEPT-RESPONSE definition. 2624 V02: 2014-05-12 MD 2626 o Typos fixed, clarifications made. 2628 o Removed spurious COMMENT param. Switched some to PUBLIC-COMMENT 2630 o Changed STAY-INFORMED to remove boolean value type and state 2631 explicit TRUE/FALSE values. 2633 o iTip: Allow VPOLL DTSTART to be optional and allow VAVAILABILITY 2634 as subcomponent 2636 o iTip: fix broken table cells 2638 o Add POLL-PROPERTIES, POLL-WINNER to 5545 extensions table 2639 o Added Caldav scheduling section 2641 V01: 2013-08-07 MD 2643 o Removed method CONFIRM 2645 o Removed pollitemid from VPOLL abnf. Added text for pollwinner 2647 o Added POLL-WINNER and verbiage 2649 o Added STATUS values 2651 o Added RELTYPE=POLL 2653 o Added supported-vpoll-component-sets 2655 o Added CalDAV related parameters to VOTER 2657 o Removed bad CalDAV query example. State that queries cannot 2658 target the sub-components. 2660 2012-11-02 MD Initial version 2662 Authors' Addresses 2664 Eric York (editor) 2665 Apple Inc. 2666 1 Infinite Loop 2667 Cupertino, CA 95014 2668 USA 2670 Email: eyork@apple.com 2671 URI: http://www.apple.com/ 2673 Cyrus Daboo (editor) 2674 Apple Inc. 2675 1 Infinite Loop 2676 Cupertino, CA 95014 2677 USA 2679 Email: cyrus@daboo.name 2680 URI: http://www.apple.com/ 2681 Michael Douglass (editor) 2682 Rensselaer Polytechnic Institute 2683 110 8th Street 2684 Troy, NY 12180 2685 USA 2687 Email: douglm@rpi.edu 2688 URI: http://www.rpi.edu/