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/