idnits 2.17.1
draft-calext-vpoll-00.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 :
----------------------------------------------------------------------------
No issues found here.
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;
-- The document date (May 23, 2019) is 1800 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: 'RFC8174' is defined on line 2526, but no explicit
reference was found in the text
== Unused Reference: 'RFC3552' is defined on line 2536, but no explicit
reference was found in the text
== Unused Reference: 'RFC4918' is defined on line 2541, but no explicit
reference was found in the text
== Unused Reference: 'RFC5378' is defined on line 2546, but no explicit
reference was found in the text
** Obsolete normative reference: RFC 2518 (Obsoleted by RFC 4918)
Summary: 1 error (**), 0 flaws (~~), 6 warnings (==), 1 comment (--).
Run idnits with the --verbose option for more detailed information about
the items above.
--------------------------------------------------------------------------------
2 Network Working Group E. York
3 Internet-Draft California Things, Inc
4 Intended status: Standards Track C. Daboo
5 Expires: November 24, 2019 Apple Inc.
6 M. Douglass
7 Spherical Cow Group
8 May 23, 2019
10 VPOLL: Consensus Scheduling Component for iCalendar
11 draft-calext-vpoll-00
13 Abstract
15 This specification introduces a new iCalendar component which allows
16 for consensus scheduling, that is, voting on a number of alternative
17 meeting or task alternatives.
19 Status of This Memo
21 This Internet-Draft is submitted in full conformance with the
22 provisions of BCP 78 and BCP 79.
24 Internet-Drafts are working documents of the Internet Engineering
25 Task Force (IETF). Note that other groups may also distribute
26 working documents as Internet-Drafts. The list of current Internet-
27 Drafts is at https://datatracker.ietf.org/drafts/current/.
29 Internet-Drafts are draft documents valid for a maximum of six months
30 and may be updated, replaced, or obsoleted by other documents at any
31 time. It is inappropriate to use Internet-Drafts as reference
32 material or to cite them other than as "work in progress."
34 This Internet-Draft will expire on November 24, 2019.
36 Copyright Notice
38 Copyright (c) 2019 IETF Trust and the persons identified as the
39 document authors. All rights reserved.
41 This document is subject to BCP 78 and the IETF Trust's Legal
42 Provisions Relating to IETF Documents
43 (https://trustee.ietf.org/license-info) in effect on the date of
44 publication of this document. Please review these documents
45 carefully, as they describe your rights and restrictions with respect
46 to this document. Code Components extracted from this document must
47 include Simplified BSD License text as described in Section 4.e of
48 the Trust Legal Provisions and are provided without warranty as
49 described in the Simplified BSD License.
51 Table of Contents
53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
54 2. Terms and definitions . . . . . . . . . . . . . . . . . . . . 4
55 2.1. consensus scheduling . . . . . . . . . . . . . . . . . . 4
56 2.2. active Vpoll . . . . . . . . . . . . . . . . . . . . . . 5
57 2.3. voter . . . . . . . . . . . . . . . . . . . . . . . . . . 5
58 3. Simple Consensus Scheduling . . . . . . . . . . . . . . . . . 5
59 3.1. The VPOLL Component: An Overview . . . . . . . . . . . . 5
60 3.2. The VPOLL Subcomponents: An Overview . . . . . . . . . . 7
61 3.3. VPOLL responses . . . . . . . . . . . . . . . . . . . . . 8
62 3.4. VPOLL updates . . . . . . . . . . . . . . . . . . . . . . 9
63 3.5. VPOLL Completion . . . . . . . . . . . . . . . . . . . . 11
64 3.6. Other Responses . . . . . . . . . . . . . . . . . . . . . 11
65 4. iCalendar Extensions . . . . . . . . . . . . . . . . . . . . 12
66 4.1. Updated Relation Type Value . . . . . . . . . . . . . . . 12
67 4.2. Updated Status Value . . . . . . . . . . . . . . . . . . 12
68 4.3. New Property Parameters . . . . . . . . . . . . . . . . . 13
69 4.3.1. Required . . . . . . . . . . . . . . . . . . . . . . 13
70 4.3.2. Stay-Informed . . . . . . . . . . . . . . . . . . . . 13
71 4.4. New Properties . . . . . . . . . . . . . . . . . . . . . 14
72 4.4.1. Accept-Response . . . . . . . . . . . . . . . . . . . 14
73 4.4.2. Poll-Completion . . . . . . . . . . . . . . . . . . . 15
74 4.4.3. Poll-Item-Id . . . . . . . . . . . . . . . . . . . . 16
75 4.4.4. Poll-Mode . . . . . . . . . . . . . . . . . . . . . . 16
76 4.4.5. Poll-properties . . . . . . . . . . . . . . . . . . . 17
77 4.4.6. Poll-Winner . . . . . . . . . . . . . . . . . . . . . 18
78 4.4.7. Reply-URL . . . . . . . . . . . . . . . . . . . . . . 18
79 4.4.8. Response . . . . . . . . . . . . . . . . . . . . . . 19
80 4.4.9. Voter . . . . . . . . . . . . . . . . . . . . . . . . 20
81 4.5. New Components . . . . . . . . . . . . . . . . . . . . . 21
82 4.5.1. VPOLL Component . . . . . . . . . . . . . . . . . . . 21
83 4.5.2. VVOTER Component . . . . . . . . . . . . . . . . . . 24
84 4.5.3. VOTE Component . . . . . . . . . . . . . . . . . . . 25
85 5. Poll Modes . . . . . . . . . . . . . . . . . . . . . . . . . 26
86 5.1. POLL-MODE:BASIC . . . . . . . . . . . . . . . . . . . . . 26
87 5.1.1. Property restrictions . . . . . . . . . . . . . . . . 27
88 5.1.2. Outcome reporting . . . . . . . . . . . . . . . . . . 27
89 6. iTIP Extensions . . . . . . . . . . . . . . . . . . . . . . . 27
90 6.1. Methods . . . . . . . . . . . . . . . . . . . . . . . . . 27
91 6.2. Interoperability Models . . . . . . . . . . . . . . . . . 28
92 6.2.1. Delegation . . . . . . . . . . . . . . . . . . . . . 28
93 6.2.2. Acting on Behalf of Other Calendar Users . . . . . . 29
94 6.2.3. Component Revisions . . . . . . . . . . . . . . . . . 29
95 6.2.4. Message Sequencing . . . . . . . . . . . . . . . . . 29
97 6.3. Application Protocol Elements . . . . . . . . . . . . . . 29
98 6.3.1. Methods for VPOLL Calendar Components . . . . . . . . 29
99 6.3.2. Method: PUBLISH . . . . . . . . . . . . . . . . . . . 30
100 6.3.3. Method: REQUEST . . . . . . . . . . . . . . . . . . . 32
101 6.3.3.1. Rescheduling a poll . . . . . . . . . . . . . . . 35
102 6.3.3.2. Updating or Reconfirmation of a Poll . . . . . . 35
103 6.3.3.3. Confirmation of a Poll . . . . . . . . . . . . . 35
104 6.3.3.4. Closing a Poll . . . . . . . . . . . . . . . . . 35
105 6.3.3.5. Delegating a Poll to Another CU . . . . . . . . . 36
106 6.3.3.6. Changing the Organizer . . . . . . . . . . . . . 36
107 6.3.3.7. Sending on Behalf of the Organizer . . . . . . . 37
108 6.3.3.8. Forwarding to an Uninvited CU . . . . . . . . . . 37
109 6.3.3.9. Updating Voter Status . . . . . . . . . . . . . . 37
110 6.3.4. Method: REPLY . . . . . . . . . . . . . . . . . . . . 38
111 6.3.5. Method: CANCEL . . . . . . . . . . . . . . . . . . . 40
112 6.3.6. Method: REFRESH . . . . . . . . . . . . . . . . . . . 42
113 6.3.7. Method: POLLSTATUS . . . . . . . . . . . . . . . . . 43
114 7. CalDAV Extensions . . . . . . . . . . . . . . . . . . . . . . 44
115 7.1. Calendar Collection Properties . . . . . . . . . . . . . 45
116 7.1.1. CALDAV:supported-vpoll-component-sets . . . . . . . . 45
117 7.1.2. CALDAV:vpoll-max-items . . . . . . . . . . . . . . . 46
118 7.1.3. CALDAV:vpoll-max-active . . . . . . . . . . . . . . . 47
119 7.1.4. CALDAV:vpoll-max-voters . . . . . . . . . . . . . . . 48
120 7.1.5. CalDAV:even-more-properties . . . . . . . . . . . . . 49
121 7.1.6. Extensions to CalDAV scheduling . . . . . . . . . . . 49
122 7.2. Additional Preconditions for PUT, COPY, and MOVE . . . . 49
123 7.3. CalDAV:calendar-query Report . . . . . . . . . . . . . . 50
124 7.3.1. Example: Partial Retrieval of VPOLL . . . . . . . . . 50
125 7.4. CalDAV time ranges . . . . . . . . . . . . . . . . . . . 52
126 8. Security Considerations . . . . . . . . . . . . . . . . . . . 53
127 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 53
128 9.1. Parameter Registrations . . . . . . . . . . . . . . . . . 54
129 9.2. Property Registrations . . . . . . . . . . . . . . . . . 54
130 9.3. POLL-MODE Registration Template . . . . . . . . . . . . . 54
131 9.4. POLL-MODE Registrations . . . . . . . . . . . . . . . . . 54
132 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 55
133 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 55
134 11.1. Normative References . . . . . . . . . . . . . . . . . . 55
135 11.2. Informative References . . . . . . . . . . . . . . . . . 56
136 Appendix A. Open issues . . . . . . . . . . . . . . . . . . . . 56
137 Appendix B. Change log . . . . . . . . . . . . . . . . . . . . . 58
138 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 59
140 1. Introduction
142 The currently existing approach to agreeing on meeting times using
143 iTip [RFC5546] and/or iMip [RFC6047] has some significant failings.
144 There is no useful bargaining or suggestion mechanism in iTip, only
145 the ability for a potential attendee to accept or refuse or to
146 counter with a time of their own choosing.
148 Part of the problem is that for many potential attendees, their
149 freebusy is not an accurate representation of their availability. In
150 fact, when trying to schedule conference calls across different
151 organizations, attendees may not be allowed to provide freebusy
152 information or availability as this may reveal something of the
153 organizations internal activities.
155 A number of studies have shown that large amounts of time are spent
156 trying to come to an agreement - up to and beyond 20 working hours
157 per meeting. Many organizers fall back on other approaches such as
158 phone calls and email to determine a suitable time.
160 Online services have appeared as a result and these allow
161 participants to vote on a number of alternatives without revealing or
162 using freebusy or availability. When agreement is reached a
163 conventional scheduling message may be sent to the attendees. This
164 approach appears to reach consensus fairly rapidly. Peer pressure
165 may have some bearing on this as all voters are usually able to see
166 the current state of the voting and may adjust their own meeting
167 schedules to make themselves available for a popular choice.
169 The component and properties defined in this specification provide a
170 standardized structure for this process and allow calendar clients
171 and servers and web based services to interact.
173 These structures also have uses beyond the relatively simple needs of
174 most meeting organizers. The process of coming to consensus can also
175 be viewed as a bidding process.
177 2. Terms and definitions
179 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
180 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
181 "OPTIONAL" in this document are to be interpreted as described in
182 [RFC2119].
184 Additionally the following terms are used:
186 2.1. consensus scheduling
188 The process whereby users come to some agreement on meeting or task
189 alternatives and then book that meeting or task.
191 2.2. active Vpoll
193 A VPoll may have a DTSTART, DTEND and DURATION which may define the
194 start and end of the active voting period
196 2.3. voter
198 A participant who votes on the alternatives. A voter need not be an
199 attendee of any of the alternatives presented.
201 3. Simple Consensus Scheduling
203 This specification defines components and properties which can be
204 used for simple consensus scheduling but also have the generality to
205 handle more complex cases. To provide an easy (and for many -
206 sufficient) introduction to consensus scheduling and VPOLL we will
207 outline the flow of information for the simple case of voting on a
208 number of meeting alternatives which differ only in time. In
209 addition the voters will all be potential attendees.
211 This specification not only defines data structures but adds a new
212 iTip method used when consensus has been reached. This document will
213 show how a VPOLL object is used to inform voters of the state of a
214 simple vote on some alternatives.
216 3.1. The VPOLL Component: An Overview
218 The VPOLL component acts as a wrapper for a number of alternatives to
219 be voted on, together with some properties and a new component used
220 to maintain the state of the voting. For our simple example the
221 following VPOLL properties and sub-components are either required or
222 appropriate:
224 DTSTAMP
225 The usual [RFC5545] property.
227 SEQUENCE
228 The usual [RFC5545] property. See below for SEQUENCE behavior.
230 UID
231 The usual [RFC5545] property.
233 ORGANIZER
234 The usual [RFC5545] property. In general this need not be an
235 organizer of any of the alternatives. In this simple outline we
236 assume it is the same.
238 SUMMARY
239 The usual [RFC5545] property. This optional but recommended
240 property provides the a short title to the poll.
242 DESCRIPTION
243 The usual [RFC5545] property. This optional property provides
244 more details.
246 DTEND
247 The usual [RFC5545] property. This optional property provides a
248 poll closing time and date after which the VPOLL is no longer
249 active.
251 POLL-MODE
252 A new property which defines how the votes are used to obtain a
253 result. For our use case it will take the value "BASIC" meaning
254 one event will be chosen from the alternatives.
256 POLL-COMPLETION
257 A new property which defines who (server or client) chooses and/or
258 submits the winning choice. In our example the value is "SERVER-
259 SUBMIT" which means the client chooses the winner but the server
260 will submit the winning choice.
262 POLL-PROPERTIES
263 A new property which defines which icalendar properties are being
264 voted on. For our use case it will take the value "DTSTART,
265 LOCATION" meaning only those properties are significant for
266 voting. Other properties in the events may differ but are not
267 considered significant for the voting process.
269 VVOTER
270 A new component. There is one of these for each voter and it
271 contains a VOTER property to identify the voter and one VOTE
272 component for each item being voted on.
274 VOTE
275 A new component. There is one of these for each voter and choice.
276 It usually contains at least a POLL-ITEM-ID property to identify
277 the choice and a RESPONSE property to provide a vote. For more
278 complex poll modes it may contain other information such as cost
279 or estimated duration.
281 VOTER
282 A new property. There is one of these for each voter and it is
283 similar to the [RFC5545] ATTENDEE property. It identifies the
284 VVOTER component to show who is taking part in the voting and
285 their results.
287 VEVENT
288 In our simple use case there will be multiple VEVENT sub-
289 components defining the alternatives. Each will have a different
290 date and or time for the meeting.
292 VPOLL with 3 voters and 3 alternative meetings:
294 BEGIN:VCALENDAR
295 VERSION:2.0
296 PRODID:-//Example//Example
297 METHOD:REQUEST
298 BEGIN:VPOLL
299 POLL-MODE:BASIC
300 POLL-COMPLETION:SERVER-SUBMIT
301 POLL-PROPERTIES:DTSTART,LOCATION
302 ORGANIZER:mailto:mike@example.com
303 UID:sched01-1234567890
304 DTSTAMP:20120101T000000Z
305 SUMMARY:What to do this week
306 DTEND:20120101T000000Z
307 BEGIN: VVOTER
308 VOTER:mailto:cyrus@example.com
309 END VVOTER
310 BEGIN: VVOTER
311 VOTER:mailto:eric@example.com
312 END VVOTER
313 BEGIN: VVOTER
314 VOTER:mailto:mike@example.com
315 END VVOTER
316 BEGIN:VEVENT.......(with a poll-item-id=1)
317 END:VEVENT
318 BEGIN:VEVENT.......(with a poll-item-id=2)
319 END:VEVENT
320 BEGIN:VEVENT.......(with a poll-item-id=3)
321 END:VEVENT
322 END:VPOLL
323 END:VCALENDAR
325 As can be seen in the example above, there is an iTip METHOD property
326 with the value REQUEST. The VPOLL object will be distributed to all
327 the voters, either through iMip or through some VPOLL enabled
328 service.
330 3.2. The VPOLL Subcomponents: An Overview
332 Within the VPOLL component we have the alternatives to vote on. In
333 many respects these are standard [RFC5545] components. For our
334 simple use case they are all VEVENT components. In addition to the
335 usual [RFC5545] properties some extra properties are used for a
336 VPOLL.
338 POLL-ITEM-ID
339 This provides a unique reference to the sub-component within the
340 VPOLL. It's value SHOULD be a small integer.
342 3.3. VPOLL responses
344 Upon receipt of a VPOLL REQUEST the voter will reply with a VPOLL
345 component containing their vote. In our simple case it will have the
346 following properties and components:
348 DTSTAMP
349 The usual [RFC5545] property.
351 SEQUENCE
352 The usual [RFC5545] property. See below for SEQUENCE behavior.
354 UID
355 Same as the request.
357 ORGANIZER
358 Same as the request.
360 SUMMARY
361 Same as the request.
363 VVOTER
364 One only.
366 VOTER
367 One only inside the VVOTER component - the voter replying.
369 VOTE
370 One per item being voted on. There does not need to be one for
371 each choice.
373 POLL-ITEM-ID
374 One inside each VOTE component to identify the choice.
376 RESPONSE
377 One inside each VOTE component to specify the vote.
379 Note that a voter can send a number of REPLYs for each REQUEST sent
380 by the organizer. Each REPLY completely replaces the voting record
381 for that voter for all components being voted on. In our example, if
382 Eric responds and votes for items 1 and 2 and then responds again
383 with a vote for only item 3, the final outcome is one vote on item 3.
385 REPLY VPOLL from Cyrus:
387 BEGIN:VCALENDAR
388 VERSION:2.0
389 PRODID:-//Example//Example
390 METHOD: REPLY
391 BEGIN:VPOLL
392 ORGANIZER:mailto:mike@example.com
393 UID:sched01-1234567890
394 DTSTAMP:20120101T010000Z
395 SUMMARY:What to do this week
396 BEGIN:VVOTER
397 VOTER:mailto:cyrus@example.com
398 BEGIN:VOTE
399 POLL-ITEM-ID:1
400 RESPONSE:50
401 COMMENT:Work on iTIP
402 END:VOTE
403 BEGIN:VOTE
404 POLL-ITEM-ID:2
405 RESPONSE:100
406 COMMENT:Work on WebDAV
407 END:VOTE
408 BEGIN:VOTE
409 POLL-ITEM-ID:3
410 RESPONSE:0
411 END:VOTE
412 END:VVOTER
413 END:VPOLL
414 END:VCALENDAR
416 3.4. VPOLL updates
418 When the organizer receives a response from one or more voters the
419 current state of the poll is sent to all voters. The new iTip method
420 POLLSTATUS is used. The VPOLL can contain a reduced set of
421 properties but MUST contain DTSTAMP, SEQUENCE (if not 0), UID,
422 ORGANIZER and one or more VVOTER components each populated with a
423 VOTER property and zero or more VOTE components.
425 BEGIN:VCALENDAR
426 VERSION:2.0
427 PRODID:-//Example//Example
428 METHOD: POLLSTATUS
429 BEGIN:VPOLL
430 ORGANIZER:mailto:mike@example.com
431 UID:sched01-1234567890
432 DTSTAMP:20120101T020000Z
433 SEQUENCE:0
434 SUMMARY:What to do this week
435 BEGIN:VVOTER
436 VOTER:mailto:cyrus@example.com
437 BEGIN: VOTE
438 POLL-ITEM-ID:1
439 RESPONSE:50
440 COMMENT:Work on iTIP
441 END:VOTE
442 BEGIN:VOTE
443 POLL-ITEM-ID:2
444 RESPONSE:100
445 COMMENT:Work on WebDAV
446 END:VOTE
447 BEGIN:VOTE
448 POLL-ITEM-ID:3
449 RESPONSE:0
450 END:VOTE
451 END:VVOTER
452 BEGIN:VVOTER
453 VOTER:mailto:eric@example.com
454 BEGIN:VOTE
455 POLL-ITEM-ID:1
456 RESPONSE:100
457 END:VOTE
458 BEGIN:VOTE
459 POLL-ITEM-ID:2
460 RESPONSE:100
461 END:VOTE
462 BEGIN:VOTE
463 POLL-ITEM-ID:3
464 RESPONSE:0
465 END:VOTE
466 END:VVOTER
467 END:VPOLL
468 END:VCALENDAR
470 3.5. VPOLL Completion
472 After a number of REPLY messages have been received the poll will be
473 considered complete. If there is a DTEND on the poll the system may
474 automatically close the poll, or the organizer may, at any time,
475 consider the poll complete. A VPOLL can be completed (and
476 effectively closed for voting) by sending an iTip REQUEST message
477 with the VPOLL STATUS property set to COMPLETED.
479 The poll winner is confirmed by sending a final iTip REQUEST message
480 with the VPOLL STATUS property set to CONFIRMED. In this case the
481 VPOLL component contains all the events being voted on along with a
482 POLL-WINNER property to identify the winning event. As the POLL-
483 COMPLETION property is set to SERVER-SUBMIT the server will submit
484 the winning choice and when it has done so set the STATUS to
485 "SUBMITTED".
487 VPOLL confirmation:
489 BEGIN:VCALENDAR
490 VERSION:2.0
491 PRODID:-//Example//Example
492 METHOD: REQUEST
493 BEGIN:VPOLL
494 ORGANIZER:mailto:douglm@example.com
495 UID:sched01-1234567890
496 DTSTAMP:20120101T030000Z
497 COMPLETED:20120101T030000Z
498 POLL-COMPLETION:SERVER-SUBMIT
499 SEQUENCE:0
500 SUMMARY:What to do this week
501 STATUS:CONFIRMED
502 POLL-WINNER:3
503 BEGIN:VEVENT.......(with a poll-item-id=1)
504 END:VEVENT
505 BEGIN:VEVENT.......(with a poll-item-id=2)
506 END:VEVENT
507 BEGIN:VEVENT.......(with a poll-item-id=3)
508 END:VEVENT
509 END:VPOLL
510 END:VCALENDAR
512 3.6. Other Responses
514 A voter being asked to choose between a number of ORGANIZER supplied
515 alternatives may find none of them acceptable or may simply not care.
517 An alternative response, which may be disallowed by the ORGANIZER, is
518 to send back the respondees availability or freebusy or even one or
519 more new, alternative choices.
521 This is accomplished by responding with a VOTE component which has no
522 POLL-ITEM-ID property. In this case it MUST contain some alternative
523 information. What form this takes depends on the poll mode in
524 effect.
526 4. iCalendar Extensions
528 4.1. Updated Relation Type Value
530 Relationship parameter type values are defined in section 3.2.15. of
531 [RFC5545]. This specification updates that type to include the new
532 relationship value POLL to provide a link to the VPOLL component in
533 which the current component appears.
535 Format Definition
536 This property parameter is redefined by the following notation:
538 reltypeparam /= "RELTYPE" "=" "POLL"
539 ; Property value is a VPOLL uid
541 Description
542 This parameter can be specified on a property that references
543 another related calendar component. The new parameter value
544 indicates that the associated property references a VPOLL
545 component which contains the current component.
547 4.2. Updated Status Value
549 Status property values are defined in section 3.8.1.11. of [RFC5545].
550 This specification updates that type to define valid VPOLL status
551 values.
553 Format Definition
554 This property parameter is redefined by the following notation:
556 statvalue /= statvalue-poll
557 ; Status values for "VPOLL".
558 statvalue-poll = "IN-PROCESS"
559 / "COMPLETED" ; Poll has closed,
560 ; nothing has been chosen yet
561 / "CONFIRMED" ; Poll has closed and
562 ; winning items confirmed
563 / "SUBMITTED" ; The winning item has been
564 ; submitted
565 / "CANCELLED"
567 Description
568 These values allow clients and servers to handle the choosing and
569 submission of winning choices.
571 If the client is choosing and the server submitting then the
572 client should set the POLL-WINNER property, set the status to
573 CONFIRMED and save the poll. When the server submits the winning
574 choice it will set the status to SUBMITTED.
576 4.3. New Property Parameters
578 4.3.1. Required
580 Parameter name
581 REQUIRED
583 Purpose
584 To specify whether the associated property is required in the
585 current context.
587 Format Definition
588 This parameter is defined by the following notation:
590 requirededparam = "REQUIRED" "=" ("TRUE" / "FALSE")
591 ; Default is FALSE
593 Description
594 This parameter MAY be specified on REPLY-URL and, if the value is
595 TRUE, indicates the organizer requires all replies to be made via
596 the specified service rather than iTip replies.
598 4.3.2. Stay-Informed
600 Parameter name
601 STAY-INFORMED
603 Purpose
604 To specify the voter also wants to be added as an ATTENDEE when
605 the poll is confirmed.
607 Format Definition
608 This parameter is defined by the following notation:
610 stayinformedparam = "STAY-INFORMED" "=" ("TRUE" / "FALSE")
611 ; Default is FALSE
613 Description
614 This parameter MAY be specified on VOTER and, if the value is
615 TRUE, indicates the voter wishes to be added to the final choice
616 as a non participant.
618 4.4. New Properties
620 4.4.1. Accept-Response
622 Property name
623 ACCEPT-RESPONSE
625 Purpose
626 This property is used in VPOLL to indicate the types of component
627 that may be supplied in a response.
629 Property Parameters
630 Non-standard or iana parameters can be specified on this property.
632 Conformance
633 This property MAY be specified in a VPOLL component.
635 Description
636 When used in a VPOLL this property indicates what allowable
637 component types may be returned in a reply. Typically this would
638 allow a voter to respond with their freebusy or availability
639 rather than choosing one of the presented alternatives.
641 If this property is not present voters are only allowed to respond
642 to the choices in the request.
644 Format Definition
645 This property is defined by the following notation:
647 acceptresponse = "ACCEPT-RESPONSE" acceptresponseparams ":"
648 iana-token ("," iana-token) CRLF
650 acceptresponseparams = *(";" other-param)
652 4.4.2. Poll-Completion
654 Property name
655 POLL-COMPLETION
657 Purpose
658 This property is used in VPOLL to indicate whether the client or
659 server is responsible for choosing and/or submitting the
660 winner(s).
662 Description
663 When a VPOLL is stored on a server which is capable of handling
664 choosing and submission of winning choices a value of SERVER
665 indicates that the server should close the poll, choose the winner
666 and submit whenever it is appropriate to do so.
668 For example, in BASIC poll-mode, reaching the DTEND of the poll
669 could trigger this server side action.
670 Server initiated submission requires that the submitted choice
671 MUST be a valid calendaring component.
672 POLL-COMPLETION=SERVER-SUBMIT allows the client to set the poll-
673 winner, set the status to CONFIRMED and then store the poll on the
674 server. The server will then submit the winning choice and set
675 the status to SUBMITTED.
677 Format Definition
678 This property is defined by the following notation:
680 poll-completion = "POLL-COMPLETION" pcparam ":" pcvalue CRLF
682 pcparam = *(";" other-param)
684 pcvalue = "SERVER" ; The server is responsible for both choosing and
685 ; submitting the winner(s)
686 / "SERVER-SUBMIT" ; The server is responsible for
687 ; submitting the winner(s). The client chooses.
688 / "SERVER-CHOICE" ; The server is responsible for
689 ; choosing the winner(s). The client will submit.
690 / "CLIENT" ; The client is responsible for both choosing and
691 ; submitting the winner(s)
692 / iana-token
693 / x-name
694 ;Default is CLIENT
696 Example
697 The following is an example of this property:
699 POLL-COMPLETION: SERVER-SUBMIT
701 4.4.3. Poll-Item-Id
703 Property name
704 POLL-ITEM-ID
706 Purpose
707 This property is used in VPOLL child components as an identifier.
709 Value type
710 INTEGER
712 Property Parameters
713 Non-standard parameters can be specified on this property.
715 Conformance
716 This property MUST be specified in a VOTE component and in VPOLL
717 choice items.
719 Description
720 In a METHOD:REQUEST each choice component MUST have a POLL-ITEM-ID
721 property. Each set of components with the same POLL- ITEM-ID
722 value represents one overall set of items to be voted on.
724 POLL-ITEM-ID SHOULD be a unique small integer for each component
725 or set of components. If it remains the same between REQUESTs
726 then the previous response for that component MAY be re-used. To
727 force a re-vote on a component due to a significant change, the
728 POLL-ITEM-ID MUST change.
730 Format Definition
731 This property is defined by the following notation:
733 pollitemid = "POLL-ITEM-ID" pollitemdparams ":"
734 integer CRLF
736 pollitemidparams = *(
737 (";" other-param)
738 )
740 4.4.4. Poll-Mode
742 Property name
743 POLL-MODE
745 Purpose
746 This property is used in VPOLL to indicate what voting mode is to
747 be applied.
749 Property Parameters
750 Non-standard or iana parameters can be specified on this property.
752 Conformance
753 This property MAY be specified in a VPOLL component or its sub-
754 components.
756 Description
757 The poll mode defines how the votes are applied to obtain a
758 result. BASIC mode, the default, means that the voters are
759 selecting one component (or group of components) with a given
760 POLL=ITEM-ID.
762 Other polling modes may be defined in updates to this
763 specification. These may allow for such modes as ranking or task
764 assignment.
766 Format Definition
767 This property is defined by the following notation:
769 pollmode = "POLL-MODE" pollmodeparams ":"
770 ("BASIC" / iana-token / other-token) CRLF
772 pollmodeparams = *(";" other-param)
774 4.4.5. Poll-properties
776 Property name
777 POLL-PROPERTIES
779 Purpose
780 This property is used in VPOLL to define which icalendar
781 properties are being voted on.
783 Property Parameters
784 Non-standard or iana parameters can be specified on this property.
786 Conformance
787 This property MAY be specified in a VPOLL component.
789 Description
790 This property defines which icalendar properties are significant
791 in the voting process. It may not be clear to voters which
792 properties are varying in a significant manner. Clients may use
793 this property to highlight those listed properties.
795 Format Definition
796 This property is defined by the following notation:
798 pollproperties = "POLL-PROPERTIES" pollpropparams ":"
799 text *("," text) CRLF
801 pollpropparams = *(";" other-param)
803 4.4.6. Poll-Winner
805 Property name
806 POLL-WINNER
808 Purpose
809 This property is used in a basic mode VPOLL to indicate which of
810 the VPOLL sub-components won.
812 Value type
813 INTEGER
815 Property Parameters
816 Non-standard parameters can be specified on this property.
818 Conformance
819 This property MAY be specified in a VPOLL component.
821 Description
822 For poll confirmation each child component MUST have a POLL-ITEM-
823 ID property. For basic mode the VPOLL component SHOULD have a
824 POLL-WINNER property which MUST correspond to one of the POLL-
825 ITEM-ID properties and indicates which sub-component was the
826 winner.
828 Format Definition
829 This property is defined by the following notation:
831 pollwinner = "POLL-WINNER" pollwinnerparams ":"
832 integer CRLF
834 pollwinnerparams = *(";" other-param)
836 ; Used with a STATUS:CONFIRMED VPOLL to indicate which
837 ; components have been confirmed
839 4.4.7. Reply-URL
841 Property name
842 REPLY-URL
844 Purpose
845 This property may be used in scheduling messages to indicate
846 additional reply methods, for example a web-service.
848 Property Parameters
849 Non-standard, required or iana parameters can be specified on this
850 property.
852 Conformance
853 This property MAY be specified in a VPOLL component.
855 Description
856 When used in a scheduling message this property indicates
857 additional or required services that can be used to reply.
858 Typically this would be a web service of some form.
860 Format Definition
861 This property is defined by the following notation:
863 reply-url = "REPLY-URL" reply-urlparams ":" uri CRLF
865 reply-urlparams = *(
866 (";" requiredparam) /
867 (";" other-param)
868 )
870 4.4.8. Response
872 Property name
873 RESPONSE
875 Purpose
876 To specify a response vote.
878 Value type
879 INTEGER
881 Format Definition
882 This property is defined by the following notation:
884 response = "RESPONSE" response-params ":" integer CRLF
885 ; integer value 0..100
887 responseparams = *(";" other-param)
889 Description
890 This parameter can be specified on the POLL-ITEM-ID property to
891 provide the value of the voters response. This parameter allows
892 for fine grained responses which are appropriate to some
893 applications. For the case of individuals voting for a choice of
894 events, client applications SHOULD conform to the following
895 convention:
897 * 0 - 39 A "NO vote"
899 * 40 - 79 A "MAYBE" vote
901 * 80 - 89 A "YES - but not preferred vote"
903 * 90-100 A "YES" vote.
904 Clients MUST preserve the response value when there is no
905 change from the user even if they have a UI with fixed states
906 (e.g. yes/no/maybe).
908 4.4.9. Voter
910 Property name
911 VOTER
913 Purpose
914 This property is used in VVOTER components to indicate recipients
915 of the poll and to identify that component as containing the
916 voters responses.
918 Value type
919 The value type for this property is cal-address.
921 Property Parameters
922 Non-standard, cutype, member, role, rsvp, delto, delfrom, sentby,
923 cn, dir, lang or stayinformed parameters can be specified on this
924 property.
926 Conformance
927 This property MAY be specified in a VPOLL component or its sub-
928 components.
930 Description
931 This property appears in the VVOTER component only and indicates a
932 recipient of the poll and their responses.
934 Format Definition
935 This property is defined by the following notation:
937 voter = "VOTER" voterparams ":" cal-address CRLF
939 voterparam = *(
940 ;
941 ; The following are OPTIONAL,
942 ; but MUST NOT occur more than once.
943 ;
944 (";" cutypeparam) / (";" memberparam) /
945 (";" roleparam) /
946 (";" rsvpparam) / (";" deltoparam) /
947 (";" delfromparam) / (";" sentbyparam) /
948 (";" cnparam) / (";" dirparam) /
949 (";" languageparam) /
950 (";" stayinformedparam) /
952 ;
953 ; The following are OPTIONAL, but MUST NOT occur
954 ; more than once. They are defined in RFC6638
955 ;
956 (";" scheduleagentparam) /
957 (";" scheduleforcesendparam) /
958 (";" schedulestatusparam) /
960 ;
961 ; The following is OPTIONAL,
962 ; and MAY occur more than once.
963 ;
964 (";" other-param)
965 ;
966 )
968 Note 1
969 "RSVP=TRUE" MAY be used by the organizer to force the voter to
970 reset their state and re-vote.
972 Note 2
973 "scheduleagentparam", "scheduleforcesendparam" and
974 "schedulestatusparam" are all related to CalDAV scheduling and are
975 defined in [RFC6638]. Their semantics are exactly as defined in
976 that specification.
978 4.5. New Components
980 4.5.1. VPOLL Component
982 Component name
983 VPOLL
985 Purpose
986 This component provides a mechanism by which voters can vote on
987 provided choices.
989 Format Definition
990 This property is defined by the following notation:
992 pollc = "BEGIN" ":" "VPOLL" CRLF
993 pollprop
994 *voterc *eventc *todoc *journalc *freebusyc
995 *availabilityc *alarmc *iana-comp *x-comp
996 "END" ":" "VPOLL" CRLF
998 pollprop = *(
999 ;
1000 ; The following are REQUIRED,
1001 ; but MUST NOT occur more than once.
1002 ;
1003 dtstamp / uid / organizer /
1004 ;
1005 ; The following are OPTIONAL,
1006 ; but MUST NOT occur more than once.
1007 ;
1008 acceptresponse / class / created / completed /
1009 description / dtstart / last-mod / pollmode /
1010 pollproperties / priority / seq / status /
1011 summary / url /
1012 ;
1013 ; Either 'dtend' or 'duration' MAY appear in
1014 ; a 'pollprop', but 'dtend' and 'duration'
1015 ; MUST NOT occur in the same 'pollprop'.
1016 ; 'duration' MUST only occur when 'dtstart'
1017 ; is present
1018 ;
1019 dtend / duration /
1020 ;
1021 ; The following are OPTIONAL,
1022 ; and MAY occur more than once.
1023 ;
1024 attach / categories / comment /
1025 contact / rstatus / related /
1026 resources / x-prop / iana-prop
1027 ;
1028 ; The following is OPTIONAL, it SHOULD appear
1029 ; once for the confirmation of a BASIC mode
1030 ; VPOLL. Other modes may define differing
1031 ; requirements.
1032 ;
1033 pollwinner /
1034 ;
1035 )
1037 Description
1038 This component provides a mechanism by which voters can vote on
1039 provided choices. The outcome depends upon the POLL-MODE in
1040 effect.
1042 The VVOTER components in VPOLL requests provide information on
1043 each recipient who will be voting - both their identity through
1044 the VOTER property and their votes through the VOTE components.
1046 If specified, the "DTSTART" property defines the start or opening
1047 of the poll active period. If absent the poll is presumed to have
1048 started when created.
1050 If "DTSTART" is present "DURATION" MAY be specified and indicates
1051 the duration, and hence the ending, of the poll. The value of the
1052 property MUST be a positive duration.
1054 "DTEND" MAY be specified with or without "DTSTART" and indicates
1055 the ending of the poll. If DTEND is specified it MUST be later
1056 than the DTSTART or CREATED property.
1058 If one or more VALARM components are included in the VPOLL they
1059 are not components to be voted on and MUST NOT contain a POLL-
1060 ITEM-ID property. VALARM sub-components may be used to provide
1061 warnings to the user when polls are due to start or end.
1063 TODO: Need some text to describe what relative alarms are relative
1064 to.
1066 4.5.2. VVOTER Component
1068 Component name
1069 VPOLL
1071 Purpose
1072 This component contains identification of the recipient and voter
1073 and their responses.
1075 Format Definition
1076 This property is defined by the following notation:
1078 voterc = "BEGIN" ":" "VVOTER" CRLF
1079 voterprop
1080 *votec *iana-comp *x-comp
1081 "END" ":" "VVOTER" CRLF
1083 voterprop = *(
1084 ;
1085 ; The following are REQUIRED,
1086 ; but MUST NOT occur more than once.
1087 ;
1088 dtstamp / voter /
1089 ;
1090 ; The following are OPTIONAL,
1091 ; but MUST NOT occur more than once.
1092 ;
1093 created / description / last-mod / seq /
1094 status / summary / url /
1095 ;
1096 ; The following are OPTIONAL,
1097 ; and MAY occur more than once.
1098 ;
1099 attach / categories / comment /
1100 contact / rstatus / related /
1101 resources / x-prop / iana-prop
1102 ;
1103 )
1105 Description
1106 This component contains a VOTER property identifying a recipient
1107 and voter and zero or more VOTE components containing their
1108 responses.
1110 The VOTER property in VVOTER objects refers to a recipient who
1111 will be voting - RSVP=TRUE is used by the organizer to force the
1112 voter to reset their state and re-vote
1114 4.5.3. VOTE Component
1116 Component name
1117 VPOLL
1119 Purpose
1120 This component provides a mechanism by which voters can vote on
1121 provided choices.
1123 Format Definition
1124 This property is defined by the following notation:
1126 votec = "BEGIN" ":" "VOTE" CRLF
1127 voteprop
1128 *eventc *todoc *journalc *freebusyc
1129 *availabilityc *alarmc *iana-comp *x-comp
1130 "END" ":" "VOTE" CRLF
1132 voteprop = *(
1133 ;
1134 ; The following are REQUIRED,
1135 ; but MUST NOT occur more than once.
1136 ;
1137 pollitemid / response /
1138 ;
1139 ; The following are OPTIONAL,
1140 ; and MAY occur more than once.
1141 ;
1142 comment / x-prop / iana-prop
1143 ;
1144 )
1146 Description
1147 This component identifies voters and contains their responses.
1149 The required and optional properties and their meanings depend
1150 upon the POLL-MODE in effect.
1152 For any POLL-MODE, POLL-ITEM-ID is used to associate the
1153 information to a choice supplied by the organizer.
1155 If allowed by the POLL-MODE a VOTE component without a POLL-ITEM-
1156 ID may be provided in a REPLY to indicate a possible new choice or
1157 to provide information to the ORGANIZER - such as the respondees
1158 availability.
1160 5. Poll Modes
1162 The VPOLL component is intended to allow for various forms of
1163 polling. The particular form in efffect is indicated by the POLL-
1164 MODE property.
1166 New poll modes can be registered by including a completed POLL-MODE
1167 Registration Template (see Section 9.3) in a published RFC.
1169 5.1. POLL-MODE:BASIC
1171 BASIC poll mode is the form of voting in which one possible outcome
1172 is chosen from a set of possibilities. Usually this will be
1173 represented as a number of possible event objects one of which will
1174 be selected.
1176 5.1.1. Property restrictions
1178 This poll mode has the following property requirements:
1180 POLL-ITEM-ID
1181 Each contained sub-component that is being voted upon MUST contain
1182 a POLL-ITEM_ID property which is unique within the context of the
1183 POLL. The value MUST NOT be reused when events are removed and/or
1184 added to the poll.
1186 POLL-WINNER
1187 On confirmation of the poll this property MUST be present and
1188 identifies the winning component.
1190 5.1.2. Outcome reporting
1192 To confirm the winner the POLL-WINNER property MUST be present and
1193 the STATUS MUST be set to CONFIRMED.
1195 When the winning VEVENT or VTODO is not a scheduled entity, that is,
1196 it has no ORGANIZER or ATTENDEES it MUST be assigned an ORGANIZER
1197 property and a list of non-participating ATTENDEEs. This allows the
1198 winning entity to be distributed to the participants through iTip or
1199 some other protocol.
1201 6. iTIP Extensions
1203 This specification introduces a number of extensions to [RFC5546].
1204 In group scheduling the parties involved are organizer and attendees.
1205 In VPOLL the parties are organizer and voters.
1207 For many of the iTip processing rules the voters take the place of
1208 attendees.
1210 6.1. Methods
1212 There are some extensions to the behavior of iTip methods for a VPOLL
1213 object and two new methods are defined.
1215 +----------------+--------------------------------------------------+
1216 | Method | Description |
1217 +----------------+--------------------------------------------------+
1218 | PUBLISH | No changes (yet) |
1219 | REQUEST | Each child component MUST have a POLL-ITEM-ID |
1220 | | property. Each set of components with the same |
1221 | | POLL-ITEM-ID value represents one overall set of |
1222 | | items to be voted on. |
1223 | REPLY | There MUST be a single VPOLL component which |
1224 | | MUST have: either one or more POLL-ITEM-ID |
1225 | | properties with a RESPONSE param matching that |
1226 | | from a REQUEST or a VFREEBUSY or VAVAILABILITY |
1227 | | child component showing overall busy/available |
1228 | | time. The VPOLL MUST have one VOTER only. |
1229 | ADD | Not supported for VPOLL. |
1230 | CANCEL | There MUST be a single VPOLL component with UID |
1231 | | matching that of the poll being cancelled. |
1232 | REFRESH | The organizer returns a METHOD:REQUEST with the |
1233 | | current full state, or a METHOD:CANCEL or an |
1234 | | error if no matching poll is found. |
1235 | COUNTER | Not supported for VPOLL. |
1236 | DECLINECOUNTER | Not supported for VPOLL. |
1237 | POLLSTATUS | Used to send the current state of the poll to |
1238 | | all voters. The VPOLL can contain a reduced set |
1239 | | of properties but MUST contain DTSTAMP, SEQUENCE |
1240 | | (if not 0), UID, ORGANIZER and VOTER. |
1241 +----------------+--------------------------------------------------+
1243 The following table shows the above methods broken down by who can
1244 send them with VPOLL components.
1246 +------------+------------------------------------------------+
1247 | Originator | Methods |
1248 +------------+------------------------------------------------+
1249 | Organizer | CANCEL, PUBLISH, REQUEST, POLLSTATUS |
1250 | Voter | REPLY, REFRESH, REQUEST (only when delegating) |
1251 +------------+------------------------------------------------+
1253 6.2. Interoperability Models
1255 Most of the standard iTip specification applies with respect to
1256 organizer and voters.
1258 6.2.1. Delegation
1260 TBD
1262 6.2.2. Acting on Behalf of Other Calendar Users
1264 TBD
1266 6.2.3. Component Revisions
1268 o Need to talk about what a change in SEQUENCE means
1270 o Sequence change forces a revote.
1272 o New voter - no sequence change
1274 o Add another poll set or change poll item ids or any change to a
1275 child
1277 o component - bump sequence
1279 6.2.4. Message Sequencing
1281 TBD
1283 6.3. Application Protocol Elements
1285 6.3.1. Methods for VPOLL Calendar Components
1287 This section defines the property set restrictions for the method
1288 types that are applicable to the "VPOLL" calendar component. Each
1289 method is defined using a table that clarifies the property
1290 constraints that define the particular method.
1292 The presence column uses the following values to assert whether a
1293 property is required or optional, and the number of times it may
1294 appear in the iCalendar object.
1296 +----------------+--------------------------------------------------+
1297 | Presence Value | Description |
1298 +----------------+--------------------------------------------------+
1299 | 1 | One instance MUST be present. |
1300 | 1+ | At least one instance MUST be present. |
1301 | 0 | Instances of this property MUST NOT be present. |
1302 | 0+ | Multiple instances MAY be present. |
1303 | 0 or 1 | Up to 1 instance of this property MAY be |
1304 | | present. |
1305 +----------------+--------------------------------------------------+
1307 The following summarizes the methods that are defined for the "VPOLL"
1308 calendar component.
1310 +------------+------------------------------------------------------+
1311 | Method | Description |
1312 +------------+------------------------------------------------------+
1313 | PUBLISH | Post notification of an poll. Used primarily as a |
1314 | | method of advertising the existence of a poll. |
1315 | REQUEST | To make a request for a poll. This is an explicit |
1316 | | invitation to one or more voters. Poll requests are |
1317 | | also used to update, change or confirm an existing |
1318 | | poll. Clients that cannot handle REQUEST MAY degrade |
1319 | | the poll to view it as a PUBLISH. REQUEST SHOULD NOT |
1320 | | be used just to set the status of the poll - |
1321 | | POLLSTATUS provides a more compact approach. |
1322 | REPLY | Reply to a poll request. Voters may set their |
1323 | | RESPONSE parameter to supply the current vote in the |
1324 | | range 0 to 100. |
1325 | CANCEL | Cancel a poll. |
1326 | REFRESH | A request is sent to an Organizer by a Voter asking |
1327 | | for the latest version of a poll to be resent to the |
1328 | | requester. |
1329 | POLLSTATUS | Used to send the current state of the poll to all |
1330 | | voters. The VPOLL can contain a reduced set of |
1331 | | properties but MUST contain DTSTAMP, SEQUENCE (if |
1332 | | not 0), UID, ORGANIZER and VOTER. |
1333 +------------+------------------------------------------------------+
1335 6.3.2. Method: PUBLISH
1337 The "PUBLISH" method in a "VPOLL" calendar component is an
1338 unsolicited posting of an iCalendar object. Any CU may add published
1339 components to their calendar. The "Organizer" MUST be present in a
1340 published iCalendar component. "Voters" MUST NOT be present. Its
1341 expected usage is for encapsulating an arbitrary poll as an iCalendar
1342 object. The "Organizer" may subsequently update (with another
1343 "PUBLISH" method) or cancel (with a "CANCEL" method) a previously
1344 published "VPOLL" calendar component.
1346 This method type is an iCalendar object that conforms to the
1347 following property constraints:
1349 +--------------------+----------+-----------------------------------+
1350 | Component/Property | Presence | Comment |
1351 +--------------------+----------+-----------------------------------+
1352 | METHOD | 1 | MUST equal PUBLISH. |
1353 | VPOLL | 1+ | |
1354 | DTSTAMP | 1 | |
1355 | DTSTART | 0 or 1 | If present defines the start of |
1356 | | | the poll. Otherwise the poll |
1357 | | | starts when it is created and |
1358 | | | distributed. |
1359 | ORGANIZER | 1 | |
1360 | SUMMARY | 1 | Can be null. |
1361 | UID | 1 | |
1362 | SEQUENCE | 0 or 1 | MUST be present if value is |
1363 | | | greater than 0; MAY be present if |
1364 | | | 0. |
1365 | ACCEPT-RESPONSE | 0 or 1 | |
1366 | ATTACH | 0+ | |
1367 | CATEGORIES | 0+ | |
1368 | CLASS | 0 or 1 | |
1369 | COMMENT | 0+ | |
1370 | COMPLETED | 0 or 1 | |
1371 | CONTACT | 0 or 1 | |
1372 | CREATED | 0 or 1 | |
1373 | DESCRIPTION | 0 or 1 | Can be null. |
1374 | DTEND | 0 or 1 | If present, DURATION MUST NOT be |
1375 | | | present. |
1376 | DURATION | 0 or 1 | If present, DTEND MUST NOT be |
1377 | | | present. |
1378 | LAST-MODIFIED | 0 or 1 | |
1379 | POLL-ITEM-ID | 0 | |
1380 | POLL-MODE | 0 or 1 | |
1381 | POLL-PROPERTIES | 0 or 1 | |
1382 | PRIORITY | 0 or 1 | |
1383 | RELATED-TO | 0+ | |
1384 | RESOURCES | 0+ | |
1385 | STATUS | 0 or 1 | MAY be one of |
1386 | | | COMPLETED/CONFIRMED/CANCELLED. |
1387 | URL | 0 or 1 | |
1388 | IANA-PROPERTY | 0+ | |
1389 | X-PROPERTY | 0+ | |
1390 | VOTER | 0 | |
1391 | REQUEST-STATUS | 0 | |
1392 | VALARM | 0+ | |
1393 | VEVENT | 0+ | Depending upon the poll mode in |
1394 | | | effect there MAY be candidate |
1395 | | | components included in the poll |
1396 | | | component. If voting has already |
1397 | | | taken place, these components |
1398 | | | MUST include the VOTER property |
1399 | | | to indicate each voters current |
1400 | | | response. |
1401 | VFREEBUSY | 0 | |
1402 | VJOURNAL | 0+ | Depending upon the poll mode in |
1403 | | | effect there MAY be candidate |
1404 | | | components included in the poll |
1405 | | | component. If voting has already |
1406 | | | taken place, these components |
1407 | | | MUST include the VOTER property |
1408 | | | to indicate each voters current |
1409 | | | response. |
1410 | VTODO | 0+ | Depending upon the poll mode in |
1411 | | | effect there MAY be candidate |
1412 | | | components included in the poll |
1413 | | | component. If voting has already |
1414 | | | taken place, these components |
1415 | | | MUST include the VOTER property |
1416 | | | to indicate each voters current |
1417 | | | response. |
1418 | VTIMEZONE | 0+ | MUST be present if any date/time |
1419 | | | refers to a timezone. |
1420 | IANA-COMPONENT | 0+ | |
1421 | X-COMPONENT | 0+ | |
1422 +--------------------+----------+-----------------------------------+
1424 Constraints for a METHOD:PUBLISH of a VPOLL
1426 6.3.3. Method: REQUEST
1428 The "REQUEST" method in a "VPOLL" component provides the following
1429 scheduling functions:
1431 o Invite "Voters" to respond to the poll.
1433 o Change the items being voted upon.
1435 o Complete or confirm the poll.
1437 o Response to a "REFRESH" request.
1439 o Update the details of an existing vpoll.
1441 o Update the status of "Voters".
1443 o Forward a "VPOLL" to another uninvited CU.
1445 o For an existing "VPOLL" calendar component, delegate the role of
1446 "Voter" to another CU.
1448 o For an existing "VPOLL" calendar component, change the role of
1449 "Organizer" to another CU.
1451 The "Organizer" originates the "REQUEST". The recipients of the
1452 "REQUEST" method are the CUs voting in the poll, the "Voters".
1453 "Voters" use the "REPLY" method to convey votes to the "Organizer".
1455 The "UID" and "SEQUENCE" properties are used to distinguish the
1456 various uses of the "REQUEST" method. If the "UID" property value in
1457 the "REQUEST" is not found on the recipient's calendar, then the
1458 "REQUEST" is for a new "VPOLL" calendar component. If the "UID"
1459 property value is found on the recipient's calendar, then the
1460 "REQUEST" is for an update, or a reconfirmation of the "VPOLL"
1461 calendar component.
1463 For the "REQUEST" method only a single iCalendar object is permitted.
1465 This method type is an iCalendar object that conforms to the
1466 following property constraints:
1468 +--------------------+----------+-----------------------------------+
1469 | Component/Property | Presence | Comment |
1470 +--------------------+----------+-----------------------------------+
1471 | METHOD | 1 | MUST be REQUEST. |
1472 | VPOLL | 1 | |
1473 | VOTER | 1+ | |
1474 | DTSTAMP | 1 | |
1475 | DTSTART | 0 or 1 | If present defines the start of |
1476 | | | the poll. Otherwise the poll |
1477 | | | starts when it is created and |
1478 | | | distributed. |
1479 | ORGANIZER | 1 | |
1480 | SEQUENCE | 0 or 1 | MUST be present if value is |
1481 | | | greater than 0; MAY be present if |
1482 | | | 0. |
1483 | SUMMARY | 1 | Can be null. |
1484 | UID | 1 | |
1485 | ACCEPT-RESPONSE | 0 or 1 | |
1486 | ATTACH | 0+ | |
1487 | CATEGORIES | 0+ | |
1488 | CLASS | 0 or 1 | |
1489 | COMMENT | 0+ | |
1490 | COMPLETED | 0 or 1 | |
1491 | CONTACT | 0+ | |
1492 | CREATED | 0 or 1 | |
1493 | DESCRIPTION | 0 or 1 | Can be null. |
1494 | DTEND | 0 or 1 | If present, DURATION MUST NOT be |
1495 | | | present. |
1496 | DURATION | 0 or 1 | If present, DTEND MUST NOT be |
1497 | | | present. |
1498 | GEO | 0 or 1 | |
1499 | LAST-MODIFIED | 0 or 1 | |
1500 | LOCATION | 0 or 1 | |
1501 | POLL-ITEM-ID | 0 | |
1502 | POLL-MODE | 0 or 1 | |
1503 | POLL-PROPERTIES | 0 or 1 | |
1504 | PRIORITY | 0 or 1 | |
1505 | RELATED-TO | 0+ | |
1506 | REQUEST-STATUS | 0 | |
1507 | RESOURCES | 0+ | |
1508 | STATUS | 0 or 1 | MAY be one of |
1509 | | | COMPLETED/CONFIRMED/CANCELLED. |
1510 | TRANSP | 0 or 1 | |
1511 | URL | 0 or 1 | |
1512 | IANA-PROPERTY | 0+ | |
1513 | X-PROPERTY | 0+ | |
1514 | VALARM | 0+ | |
1515 | VTIMEZONE | 0+ | MUST be present if any date/time |
1516 | | | refers to a timezone. |
1517 | IANA-COMPONENT | 0+ | |
1518 | X-COMPONENT | 0+ | |
1519 | VEVENT | 0+ | Depending upon the poll mode in |
1520 | | | effect there MAY be candidate |
1521 | | | components included in the poll |
1522 | | | component. If voting has already |
1523 | | | taken place, these components |
1524 | | | MUST include the VOTER property |
1525 | | | to indicate each voters current |
1526 | | | response. |
1527 | VFREEBUSY | 0 | |
1528 | VJOURNAL | 0+ | Depending upon the poll mode in |
1529 | | | effect there MAY be candidate |
1530 | | | components included in the poll |
1531 | | | component. If voting has already |
1532 | | | taken place, these components |
1533 | | | MUST include the VOTER property |
1534 | | | to indicate each voters current |
1535 | | | response. |
1536 | VTODO | 0+ | Depending upon the poll mode in |
1537 | | | effect there MAY be candidate |
1538 | | | components included in the poll |
1539 | | | component. If voting has already |
1540 | | | taken place, these components |
1541 | | | MUST include the VOTER property |
1542 | | | to indicate each voters current |
1543 | | | response. |
1544 +--------------------+----------+-----------------------------------+
1546 Constraints for a METHOD:REQUEST of a VPOLL
1548 6.3.3.1. Rescheduling a poll
1550 The "REQUEST" method may be used to reschedule a poll, that is force
1551 a revote. A rescheduled poll involves a change to the existing poll
1552 in terms of its time the components being voted on may have changed.
1553 If the recipient CUA of a "REQUEST" method finds that the "UID"
1554 property value already exists on the calendar but that the "SEQUENCE"
1555 (or "DTSTAMP") property value in the "REQUEST" method is greater than
1556 the value for the existing poll, then the "REQUEST" method describes
1557 a rescheduling of the poll.
1559 6.3.3.2. Updating or Reconfirmation of a Poll
1561 The "REQUEST" method may be used to update or reconfirm a poll. An
1562 update to an existing poll does not involve changes to the time or
1563 candidates, and might not involve a change to the location or
1564 description for the poll. If the recipient CUA of a "REQUEST" method
1565 finds that the "UID" property value already exists on the calendar
1566 and that the "SEQUENCE" property value in the "REQUEST" is the same
1567 as the value for the existing poll, then the "REQUEST" method
1569 describes an update of the poll details, but not a rescheduling of
1570 the POLL.
1572 The update "REQUEST" method is the appropriate response to a
1573 "REFRESH" method sent from a "Voter" to the "Organizer" of a poll.
1575 The "Organizer" of a poll may also send unsolicited "REQUEST"
1576 methods. The unsolicited "REQUEST" methods may be used to update the
1577 details of the poll without rescheduling it, to update the "RESPONSE"
1578 parameter of "Voters", or to reconfirm the poll.
1580 6.3.3.3. Confirmation of a Poll
1582 The "REQUEST" method may be used to confirm a poll, that is announce
1583 the winner in BASIC mode. The STATUS MUST be set to CONFIRMED and
1584 for BASIC mode a VPOLL POLL-WINNER property must be provided with the
1585 poll-id of the winning component.
1587 6.3.3.4. Closing a Poll
1589 The "REQUEST" method may be used to close a poll, that is indicate
1590 voting is completed. The STATUS MUST be set to COMPLETED.
1592 6.3.3.5. Delegating a Poll to Another CU
1594 Some calendar and scheduling systems allow "Voters" to delegate the
1595 vote to another "Calendar User". iTIP supports this concept using the
1596 following workflow. Any "Voter" may delegate their right to vote in
1597 a poll to another CU. The implication is that the delegate
1598 participates in lieu of the original "Voter", NOT in addition to the
1599 "Voter". The delegator MUST notify the "Organizer" of this action
1600 using the steps outlined below. Implementations may support or
1601 restrict delegation as they see fit. For instance, some
1602 implementations may restrict a delegate from delegating a "REQUEST"
1603 to another CU.
1605 The "Delegator" of a poll forwards the existing "REQUEST" to the
1606 "Delegate". The "REQUEST" method MUST include a "Voter" property
1607 with the calendar address of the "Delegate". The "Delegator" MUST
1608 also send a "REPLY" method to the "Organizer" with the "Delegator's"
1609 "Voter" property "DELEGATED-TO" parameter set to the calendar address
1610 of the "Delegate". Also, a new "Voter" property for the "Delegate"
1611 MUST be included and must specify the calendar user address set in
1612 the "DELEGATED-TO" parameter, as above.
1614 In response to the request, the "Delegate" MUST send a "REPLY" method
1615 to the "Organizer", and optionally to the "Delegator". The "REPLY"
1617 method SHOULD include the "Voter" property with the "DELEGATED-FROM"
1618 parameter value of the "Delegator's" calendar address.
1620 The "Delegator" may continue to receive updates to the poll even
1621 though they will not be attending. This is accomplished by the
1622 "Delegator" setting their "role" attribute to "NON-PARTICIPANT" in
1623 the "REPLY" to the "Organizer".
1625 6.3.3.6. Changing the Organizer
1627 The situation may arise where the "Organizer" of a "VPOLL" is no
1628 longer able to perform the "Organizer" role and abdicates without
1629 passing on the "Organizer" role to someone else. When this occurs,
1630 the "Voters" of the "VPOLL" may use out-of-band mechanisms to
1631 communicate the situation and agree upon a new "Organizer". The new
1632 "Organizer" should then send out a new "REQUEST" with a modified
1633 version of the "VPOLL" in which the "SEQUENCE" number has been
1634 incremented and the "ORGANIZER" property has been changed to the new
1635 "Organizer".
1637 6.3.3.7. Sending on Behalf of the Organizer
1639 There are a number of scenarios that support the need for a "Calendar
1640 User" to act on behalf of the "Organizer" without explicit role
1641 changing. This might be the case if the CU designated as "Organizer"
1642 is sick or unable to perform duties associated with that function.
1643 In these cases, iTIP supports the notion of one CU acting on behalf
1644 of another. Using the "SENT-BY" parameter, a "Calendar User" could
1645 send an updated "VPOLL" "REQUEST". In the case where one CU sends on
1646 behalf of another CU, the "Voter" responses are still directed back
1647 towards the CU designated as "Organizer".
1649 6.3.3.8. Forwarding to an Uninvited CU
1651 A "Voter" invited to a "VPOLL" calendar component may send the
1652 "VPOLL" calendar component to another new CU not previously
1653 associated with the "VPOLL" calendar component. The current "Voter"
1654 participating in the "VPOLL" calendar component does this by
1655 forwarding the original "REQUEST" method to the new CU. The new CU
1656 can send a "REPLY" to the "Organizer" of the "VPOLL" calendar
1657 component. The reply contains a "Voter" property for the new CU.
1659 The "Organizer" ultimately decides whether or not the new CU becomes
1660 part of the poll and is not obligated to do anything with a "REPLY"
1661 from a new (uninvited) CU. If the "Organizer" does not want the new
1662 CU to be part of the poll, the new "Voter" property is not added to
1663 the "VPOLL" calendar component. The "Organizer" MAY send the CU a
1664 "CANCEL" message to indicate that they will not be added to the poll.
1666 If the "Organizer" decides to add the new CU, the new "Voter"
1667 property is added to the "VPOLL" calendar component. Furthermore,
1668 the "Organizer" is free to change any "Voter" property parameter from
1669 the values supplied by the new CU to something the "Organizer"
1670 considers appropriate. The "Organizer" SHOULD send the new CU a
1671 "REQUEST" message to inform them that they have been added.
1673 When forwarding a "REQUEST" to another CU, the forwarding "Voter"
1674 MUST NOT make changes to the original message.
1676 6.3.3.9. Updating Voter Status
1678 The "Organizer" of an poll may also request updated status from one
1679 or more "Voters". The "Organizer" sends a "REQUEST" method to the
1680 "Voter" and sets the "VOTER;RSVP=TRUE" property parameter. The
1681 "SEQUENCE" property for the poll is not changed from its previous
1682 value. A recipient will determine that the only change in the
1683 "REQUEST" is that their "RSVP" property parameter indicates a request
1684 for updated status. The recipient SHOULD respond with a "REPLY"
1685 method indicating their current vote with respect to the "REQUEST".
1687 6.3.4. Method: REPLY
1689 The "REPLY" method in a "VPOLL" calendar component is used to respond
1690 (e.g., accept or decline) to a "REQUEST" or to reply to a delegation
1691 "REQUEST". When used to provide a delegation response, the
1692 "Delegator" SHOULD include the calendar address of the "Delegate" on
1693 the "DELEGATED-TO" property parameter of the "Delegator's" "Voter"
1694 property. The "Delegate" SHOULD include the calendar address of the
1695 "Delegator" on the "DELEGATED-FROM" property parameter of the
1696 "Delegate's" "Voter" property.
1698 The "REPLY" method is also used when processing of a "REQUEST" fails.
1699 Depending on the value of the "REQUEST-STATUS" property, no action
1700 may have been performed.
1702 The "Organizer" of a poll may receive the "REPLY" method from a CU
1703 not in the original "REQUEST". For example, a "REPLY" may be
1704 received from a "Delegate" to a poll. In addition, the "REPLY"
1705 method may be received from an unknown CU (a "Party Crasher"). This
1706 uninvited "Voter" may be accepted, or the "Organizer" may cancel the
1707 poll for the uninvited "Voter" by sending a "CANCEL" method to the
1708 uninvited "Voter".
1710 A "Voter" MAY include a message to the "Organizer" using the
1711 "COMMENT" property. For example, if the user indicates a low
1712 interest and wants to let the "Organizer" know why, the reason can be
1713 expressed in the "COMMENT" property value.
1715 The "Organizer" may also receive a "REPLY" from one CU on behalf of
1716 another. Like the scenario enumerated above for the "Organizer",
1717 "Voters" may have another CU respond on their behalf. This is done
1718 using the "SENT-BY" parameter.
1720 The optional properties listed in the table below (those listed as
1721 "0+" or "0 or 1") MUST NOT be changed from those of the original
1722 request. (But see comments on VFREEBUSY and VAVAILABILITY)
1724 This method type is an iCalendar object that conforms to the
1725 following property constraints:
1727 +--------------------+----------+-----------------------------------+
1728 | Component/Property | Presence | Comment |
1729 +--------------------+----------+-----------------------------------+
1730 | METHOD | 1 | MUST be REPLY. |
1731 | VPOLL | 1+ | All components MUST have the same |
1732 | | | UID. |
1733 | VOTER | 1 | MUST be the address of the Voter |
1734 | | | replying. |
1735 | DTSTAMP | 1 | |
1736 | ORGANIZER | 1 | |
1737 | UID | 1 | MUST be the UID of the original |
1738 | | | REQUEST. |
1739 | SEQUENCE | 0 or 1 | If non-zero, MUST be the sequence |
1740 | | | number of the original REQUEST. |
1741 | | | MAY be present if 0. |
1742 | ACCEPT-RESPONSE | 0 or 1 | |
1743 | ATTACH | 0+ | |
1744 | CATEGORIES | 0+ | |
1745 | CLASS | 0 or 1 | |
1746 | COMMENT | 0+ | |
1747 | COMPLETED | 0 or 1 | |
1748 | CONTACT | 0+ | |
1749 | CREATED | 0 or 1 | |
1750 | DESCRIPTION | 0 or 1 | |
1751 | DTEND | 0 or 1 | If present, DURATION MUST NOT be |
1752 | | | present. |
1753 | DTSTART | 0 or 1 | |
1754 | DURATION | 0 or 1 | If present, DTEND MUST NOT be |
1755 | | | present. |
1756 | GEO | 0 or 1 | |
1757 | LAST-MODIFIED | 0 or 1 | |
1758 | LOCATION | 0 or 1 | |
1759 | POLL-ITEM-ID | 1+ | One per item being voted on. |
1760 | POLL-MODE | 0 | |
1761 | POLL-PROPERTIES | 0 | |
1762 | PRIORITY | 0 or 1 | |
1763 | RELATED-TO | 0+ | |
1764 | RESOURCES | 0+ | |
1765 | REQUEST-STATUS | 0+ | |
1766 | STATUS | 0 or 1 | |
1767 | SUMMARY | 0 or 1 | |
1768 | TRANSP | 0 or 1 | |
1769 | URL | 0 or 1 | |
1770 | IANA-PROPERTY | 0+ | |
1771 | X-PROPERTY | 0+ | |
1772 | VALARM | 0 | |
1773 | VTIMEZONE | 0 or 1 | MUST be present if any date/time |
1774 | | | refers to a timezone. |
1775 | IANA-COMPONENT | 0+ | |
1776 | X-COMPONENT | 0+ | |
1777 | VEVENT | 0 | |
1778 | VFREEBUSY | 0 or 1 | A voter may respond with a |
1779 | | | VFREEBUSY component indicating |
1780 | | | that the ORGANIZER may select |
1781 | | | some other time which is not |
1782 | | | marked as busy. |
1783 | VAVAILABILITY | 0 | A voter may respond with a |
1784 | | | VAVAILABILITY component |
1785 | | | indicating that the ORGANIZER may |
1786 | | | select some other time which is |
1787 | | | shown as available. |
1788 | VJOURNAL | 0 | |
1789 | VTODO | 0 | |
1790 +--------------------+----------+-----------------------------------+
1792 Constraints for a METHOD:REPLY of a VPOLL
1794 6.3.5. Method: CANCEL
1796 The "CANCEL" method in a "VPOLL" calendar component is used to send a
1797 cancellation notice of an existing poll request to the affected
1798 "Voters". The message is sent by the "Organizer" of the poll.
1800 The "Organizer" MUST send a "CANCEL" message to each "Voter" affected
1801 by the cancellation. This can be done using a single "CANCEL"
1802 message for all "Voters" or by using multiple messages with different
1803 subsets of the affected "Voters" in each.
1805 When a "VPOLL" is cancelled, the "SEQUENCE" property value MUST be
1806 incremented as described in Section 6.2.3.
1808 Once a CANCEL message has been sent to all voters no further voting
1809 may take place. The poll is considered closed.
1811 This method type is an iCalendar object that conforms to the
1812 following property constraints:
1814 +--------------------+----------+-----------------------------------+
1815 | Component/Property | Presence | Comment |
1816 +--------------------+----------+-----------------------------------+
1817 | METHOD | 1 | MUST be CANCEL. |
1818 | VPOLL | 1+ | All must have the same UID. |
1819 | VOTER | 0+ | MUST include some or all Voters |
1820 | | | being removed from the poll. MUST |
1821 | | | include some or all Voters if the |
1822 | | | entire poll is cancelled. |
1823 | UID | 1 | MUST be the UID of the original |
1824 | | | REQUEST. |
1825 | DTSTAMP | 1 | |
1826 | ORGANIZER | 1 | |
1827 | SEQUENCE | 1 | |
1828 | ATTACH | 0+ | |
1829 | ACCEPT-RESPONSE | 0 | |
1830 | COMMENT | 0+ | |
1831 | COMPLETED | 0 or 1 | |
1832 | CATEGORIES | 0+ | |
1833 | CLASS | 0 or 1 | |
1834 | CONTACT | 0+ | |
1835 | CREATED | 0 or 1 | |
1836 | DESCRIPTION | 0 or 1 | |
1837 | DTEND | 0 or 1 | If present, DURATION MUST NOT be |
1838 | | | present. |
1839 | DTSTART | 0 or 1 | |
1840 | DURATION | 0 or 1 | If present, DTEND MUST NOT be |
1841 | | | present. |
1842 | GEO | 0 or 1 | |
1843 | LAST-MODIFIED | 0 or 1 | |
1844 | LOCATION | 0 or 1 | |
1845 | POLL-ITEM-ID | 0 | |
1846 | POLL-MODE | 0 | |
1847 | POLL-PROPERTIES | 0 | |
1848 | PRIORITY | 0 or 1 | |
1849 | RELATED-TO | 0+ | |
1850 | RESOURCES | 0+ | |
1851 | STATUS | 0 or 1 | MUST be set to CANCELLED to |
1852 | | | cancel the entire event. If |
1853 | | | uninviting specific Attendees, |
1854 | | | then MUST NOT be included. |
1855 | SUMMARY | 0 or 1 | |
1856 | TRANSP | 0 or 1 | |
1857 | URL | 0 or 1 | |
1858 | IANA-PROPERTY | 0+ | |
1859 | X-PROPERTY | 0+ | |
1860 | REQUEST-STATUS | 0 | |
1861 | VALARM | 0 | |
1862 | VTIMEZONE | 0+ | MUST be present if any date/time |
1863 | | | refers to a timezone. |
1864 | IANA-COMPONENT | 0+ | |
1865 | X-COMPONENT | 0+ | |
1866 | VTODO | 0 | |
1867 | VJOURNAL | 0 | |
1868 | VEVENT | 0 | |
1869 | VFREEBUSY | 0 | |
1870 +--------------------+----------+-----------------------------------+
1872 Constraints for a METHOD:CANCEL of a VPOLL
1874 6.3.6. Method: REFRESH
1876 The "REFRESH" method in a "VPOLL" calendar component is used by
1877 "Voters" of an existing event to request an updated description from
1878 the poll "Organizer". The "REFRESH" method must specify the "UID"
1879 property of the poll to update. The "Organizer" responds with the
1880 latest description and version of the poll.
1882 This method type is an iCalendar object that conforms to the
1883 following property constraints:
1885 +--------------------+----------+-----------------------------------+
1886 | Component/Property | Presence | Comment |
1887 +--------------------+----------+-----------------------------------+
1888 | METHOD | 1 | MUST be REFRESH. |
1889 | VPOLL | 1 | |
1890 | VOTER | 1 | MUST be the address of requester. |
1891 | DTSTAMP | 1 | |
1892 | ORGANIZER | 1 | |
1893 | UID | 1 | MUST be the UID associated with |
1894 | | | original REQUEST. |
1895 | COMMENT | 0+ | |
1896 | COMPLETED | 0 | |
1897 | IANA-PROPERTY | 0+ | |
1898 | X-PROPERTY | 0+ | |
1899 | ACCEPT-RESPONSE | 0 | |
1900 | ATTACH | 0 | |
1901 | CATEGORIES | 0 | |
1902 | CLASS | 0 | |
1903 | CONTACT | 0 | |
1904 | CREATED | 0 | |
1905 | DESCRIPTION | 0 | |
1906 | DTEND | 0 | |
1907 | DTSTART | 0 | |
1908 | DURATION | 0 | |
1909 | GEO | 0 | |
1910 | LAST-MODIFIED | 0 | |
1911 | LOCATION | 0 | |
1912 | POLL-ITEM-ID | 0 | |
1913 | POLL-MODE | 0 | |
1914 | POLL-PROPERTIES | 0 | |
1915 | PRIORITY | 0 | |
1916 | RELATED-TO | 0 | |
1917 | REQUEST-STATUS | 0 | |
1918 | RESOURCES | 0 | |
1919 | SEQUENCE | 0 | |
1920 | STATUS | 0 | |
1921 | SUMMARY | 0 | |
1922 | URL | 0 | |
1923 | VALARM | 0 | |
1924 | VTIMEZONE | 0+ | |
1925 | IANA-COMPONENT | 0+ | |
1926 | X-COMPONENT | 0+ | |
1927 | VTODO | 0 | |
1928 | VJOURNAL | 0 | |
1929 | VEVENT | 0 | |
1930 | VFREEBUSY | 0 | |
1931 +--------------------+----------+-----------------------------------+
1933 Constraints for a METHOD:REFRESH of a VPOLL
1935 6.3.7. Method: POLLSTATUS
1937 The "POLLSTATUS" method in a "VPOLL" calendar component is used to
1938 inform recipients of the current status of the poll in a compact
1939 manner. The "Organizer" MUST be present in the confirmed poll
1940 component. "Voters" MUST NOT be present. The selected component(s)
1941 according to the poll mode MUST also be present in the poll
1942 component. Clients receiving this message may store the confirmed
1943 items in their calendars.
1945 This method type is an iCalendar object that conforms to the
1946 following property constraints:
1948 +--------------------+----------+-----------------------------------+
1949 | Component/Property | Presence | Comment |
1950 +--------------------+----------+-----------------------------------+
1951 | METHOD | 1 | MUST equal POLLSTATUS. |
1952 | VPOLL | 1+ | |
1953 | COMPLETED | 0 or 1 | Only present for a completed poll |
1954 | DTSTAMP | 1 | |
1955 | DTSTART | 0 or 1 | |
1956 | ORGANIZER | 1 | |
1957 | SUMMARY | 1 | Can be null. |
1958 | VOTER | 1+ | |
1959 | UID | 1 | |
1960 | SEQUENCE | 0 or 1 | MUST be present if value is |
1961 | | | greater than 0; MAY be present if |
1962 | | | 0. |
1963 | ACCEPT-RESPONSE | 0 | |
1964 | ATTACH | 0 | |
1965 | CATEGORIES | 0 | |
1966 | CLASS | 0 | |
1967 | COMMENT | 0+ | |
1968 | CONTACT | 0 | |
1969 | CREATED | 0 or 1 | |
1970 | DESCRIPTION | 0 or 1 | Can be null. |
1971 | DTEND | 0 or 1 | If present, DURATION MUST NOT be |
1972 | | | present. |
1973 | DURATION | 0 or 1 | If present, DTEND MUST NOT be |
1974 | | | present. |
1975 | LAST-MODIFIED | 0 or 1 | |
1976 | POLL-ITEM-ID | 0 | |
1977 | POLL-MODE | 0 or 1 | |
1978 | POLL-PROPERTIES | 0 | |
1979 | PRIORITY | 0 or 1 | |
1980 | RELATED-TO | 0+ | |
1981 | RESOURCES | 0+ | |
1982 | STATUS | 0 or 1 | MAY be one of |
1983 | | | TENTATIVE/CONFIRMED/CANCELLED. |
1984 | URL | 0 or 1 | |
1985 | IANA-PROPERTY | 0+ | |
1986 | X-PROPERTY | 0+ | |
1987 | REQUEST-STATUS | 0 | |
1988 | VALARM | 0+ | |
1989 | VEVENT | 0+ | All candidate components MUST be |
1990 | | | present but in a reduced form |
1991 | | | sufficient to provide the voting |
1992 | | | status. |
1993 | VFREEBUSY | 0 | |
1994 | VJOURNAL | 0+ | All candidate components MUST be |
1995 | | | present but in a reduced form |
1996 | | | sufficient to provide the voting |
1997 | | | status. |
1998 | VTODO | 0+ | All candidate components MUST be |
1999 | | | present but in a reduced form |
2000 | | | sufficient to provide the voting |
2001 | | | status. |
2002 | VTIMEZONE | 0+ | MUST be present if any date/time |
2003 | | | refers to a timezone. |
2004 | IANA-COMPONENT | 0+ | |
2005 | X-COMPONENT | 0+ | |
2006 +--------------------+----------+-----------------------------------+
2008 Constraints for a METHOD:POLLSTATUS of a VPOLL
2010 7. CalDAV Extensions
2012 This specification extends [RFC4791] in that it defines a new
2013 component and new iCalendar properties to be supported and requires
2014 extra definitions related to time-ranges and reports.
2016 Additionally, it extends [RFC6638] as it a VPOLL component is a
2017 schedulable entity.
2019 7.1. Calendar Collection Properties
2021 This section defines new CalDAV properties for calendar collections.
2023 7.1.1. CALDAV:supported-vpoll-component-sets
2025 Name
2026 supported-vpoll-component-sets
2028 Namespace
2029 urn:ietf:params:xml:ns:caldav
2031 Purpose
2032 Specifies the calendar component types (e.g., VEVENT, VTODO, etc.)
2033 and combination of types that may be included in a VPOLL
2034 component.
2036 Conformance
2037 This property MAY be defined on any calendar collection. If
2038 defined, it MUST be protected and SHOULD NOT be returned by a
2039 PROPFIND DAV:allprop request (as defined in section=12.14.1
2040 [RFC2518]).
2042 Description
2043 The CALDAV:supported-vpoll-component-sets property is used to
2044 specify restrictions on the calendar component types that VPOLL
2045 components may contain in a calendar collection.
2047 It also specifies the combination of allowed component types.
2049 Any attempt by the client to store VPOLL components with component
2050 types or combinations of types not listed in this property, if it
2051 exists, MUST result in an error, with the "CALDAV:supported-vpoll-
2052 component-sets" precondition Section 7.2 being violated. Since
2053 this property is protected, it cannot be changed by clients using
2054 a PROPPATCH request. However, clients can initialize the value of
2055 this property when creating a new calendar collection with
2056 MKCALENDAR. In the absence of this property, the server MUST
2057 accept all component types, and the client can assume that all
2058 component types are accepted.
2060 Definition
2062
2065
2066
2069
2070
2071
2072
2073
2074
2076
2077
2078
2079
2080
2082
2083
2084
2085
2087
2088
2089
2090
2091
2093 7.1.2. CALDAV:vpoll-max-items
2095 Name
2096 vpoll-max-items
2098 Namespace
2099 urn:ietf:params:xml:ns:caldav
2101 Purpose
2102 Provides a numeric value indicating the maximum number of items
2103 that may be contained in any instance of a VPOLL calendar object
2104 resource stored in the calendar collection.
2106 Conformance
2107 This property MAY be defined on any calendar collection. If
2108 defined, it MUST be protected and SHOULD NOT be returned by a
2109 PROPFIND DAV:allprop request (as defined in section=12.14.1
2110 [RFC2518]).
2112 Description
2113 The CALDAV:vpoll-max-items is used to specify a numeric value that
2114 indicates the maximum number of iCalendar components in any one
2115 instance of a VPOLL calendar object resource stored in a calendar
2116 collection. Any attempt to store a calendar object resource with
2117 more components per instance than this value MUST result in an
2118 error, with the CALDAV: vpoll-max-items precondition Section 7.2
2119 being violated. In the absence of this property, the client can
2120 assume that the server can handle any number of items in a VPOLL
2121 calendar component.
2123 Definition
2125
2126 PCDATA value: a numeric value (integer greater than zero)
2128 25
2131 7.1.3. CALDAV:vpoll-max-active
2133 Name
2134 vpoll-max-active
2136 Namespace
2137 urn:ietf:params:xml:ns:caldav
2139 Purpose
2140 Provides a numeric value indicating the maximum number of active
2141 vpolls at any one time.
2143 Conformance
2144 This property MAY be defined on any calendar collection. If
2145 defined, it MUST be protected and SHOULD NOT be returned by a
2146 PROPFIND DAV:allprop request (as defined in section=12.14.1
2147 [RFC2518]).
2149 Description
2150 The CALDAV:vpoll-max-active is used to specify a numeric value
2151 that indicates the maximum number of active VPOLLs at any one
2152 time. Any attempt to store a new active VPOLL calendar object
2153 resource which results in exceeding this limit MUST result in an
2154 error, with the "CALDAV:vpoll-max-active" precondition Section 7.2
2155 being violated. In the absence of this property, the client can
2156 assume that the server can handle any number of active VPOLLs.
2158 Definition
2159
2160 PCDATA value: a numeric value (integer greater than zero)
2162 25
2165 7.1.4. CALDAV:vpoll-max-voters
2167 Name
2168 "vpoll-max-voters"
2170 Namespace
2171 "urn:ietf:params:xml:ns:caldav"
2173 Purpose
2174 Provides a numeric value indicating the maximum number of voters
2175 for any instance of a VPOLL calendar object resource stored in the
2176 calendar collection.
2178 Conformance
2179 This property MAY be defined on any calendar collection. If
2180 defined, it MUST be protected and SHOULD NOT be returned by a
2181 PROPFIND "DAV:allprop" request (as defined in section=12.14.1
2182 [RFC2518]).
2184 Description
2185 The "CALDAV:vpoll-max-voters" is used to specify a numeric value
2186 that indicates the maximum number of VOTER properties for any one
2187 instance of a VPOLL calendar object resource stored in a calendar
2188 collection. Any attempt to store a calendar object resource with
2189 more VOTER properties per instance than this value MUST result in
2190 an error, with the CALDAV: "vpoll-max-voters" precondition
2191 Section 7.2 being violated. In the absence of this property, the
2192 client can assume that the server can handle any number of voters
2193 in a VPOLL calendar component.
2195 Definition
2197
2198 PCDATA value: a numeric value (integer greater than zero)
2200 25
2203 7.1.5. CalDAV:even-more-properties
2205 TODO: vpoll-supported-mode poll options - e.g "vpoll-basic"
2207 7.1.6. Extensions to CalDAV scheduling
2209 This specification extends [RFC6638].
2211 Each section of Appendix A "Scheduling Privileges Summary" is
2212 extended to include VPOLL.
2214 Any reference to the ATTENDEE property should be read to include the
2215 VOTER property. That is, for scheduling purposes the VOTER property
2216 is handled in exactly the same manner as the ATTENDEE property.
2218 7.2. Additional Preconditions for PUT, COPY, and MOVE
2220 This specification creates additional Preconditions for PUT, COPY,
2221 and MOVE methods. These preconditions apply when a PUT operation of
2222 a VPOLL calendar object resource into a calendar collection occurs,
2223 or when a COPY or MOVE operation of a calendar object resource into a
2224 calendar collection occurs, or when a COPY or MOVE operation occurs
2225 on a calendar collection.
2227 The new preconditions are:
2229 (CALDAV:supported-vpoll-component-sets)
2230 The VPOLL resource submitted in the PUT request, or targeted by a
2231 COPY or MOVE request, MUST contain a type or combination of
2232 calendar component that is supported in the targeted calendar
2233 collection;
2235 (CALDAV:vpoll-max-items)
2236 The VPOLL resource submitted in the PUT request, or targeted by a
2237 COPY or MOVE request, MUST have a number of sub-components
2238 (excluding VTIMEZONE) less than or equal to the value of the
2239 "CALDAV:vpoll-max-items" property value Section 7.1.2 on the
2240 calendar collection where the resource will be stored;
2242 (CALDAV:vpoll-max-active)
2243 The PUT request, or COPY or MOVE request, MUST not result in the
2244 number of active VPOLLs being greater than the value of the
2245 "CALDAV:vpoll-max-active" property value Section 7.1.3 on the
2246 calendar collection where the resource will be stored;
2248 (CALDAV:vpoll-max-voters)
2249 The VPOLL resource submitted in the PUT request, or targeted by a
2250 COPY or MOVE request, MUST have a number of VOTER properties less
2251 than or equal to the value of the "CALDAV:vpoll-max-voters"
2252 property value Section 7.1.4 on the calendar collection where the
2253 resource will be stored;
2255 7.3. CalDAV:calendar-query Report
2257 This allows the retrieval of VPOLLs and their included components.
2258 The query specification allows queries to be directed at the
2259 contained sub-components. For VPOLL queries this feature is
2260 disallowed. Time-range queries can only target the vpoll component
2261 itself.
2263 7.3.1. Example: Partial Retrieval of VPOLL
2265 In this example, the client requests the server to return specific
2266 components and properties of the VPOLL components that overlap the
2267 time range from December 4, 2012, at 00:00:00 A.M. UTC to December
2268 5, 2012, at 00:00:00 A.M. UTC. In addition, the "DAV:getetag"
2269 property is also requested and returned as part of the response.
2270 Note that due to the CALDAV: calendar-data element restrictions, the
2271 DTSTAMP property in VPOLL components has not been returned, and the
2272 only property returned in the VCALENDAR object is VERSION.
2274 >> Request <<
2276 REPORT /cyrus/work/ HTTP/1.1
2277 Host: cal.example.com
2278 Depth: 1
2279 Content-Type: application/xml; charset="utf-8"
2280 Content-Length: xxxx
2282
2283
2285
2286
2287
2288
2289
2290
2291
2292
2293
2294
2295
2296
2298
2300
2301
2302
2303
2304
2305
2307
2308
2309
2310
2312 >> Response <<
2314 HTTP/1.1 207 Multi-Status
2315 Date: Sat, 11 Nov 2012 09:32:12 GMT
2316 Content-Type: application/xml; charset="utf-8"
2317 Content-Length: xxxx
2319
2320
2322
2323 http://cal.example.com/cyrus/work/poll2.ics
2324
2325
2326 "fffff-abcd2"
2327 BEGIN:VCALENDAR
2328 VERSION:2.0
2329 BEGIN:VPOLL
2330 DTSTART;TZID=US/Eastern:20121202T120000
2331 DURATION:PT4D
2332 SUMMARY:Poll #2
2333 UID:00959BC664CA650E933C892C@example.com
2334 END:VPOLL
2335 END:VCALENDAR
2336
2337
2338 HTTP/1.1 200 OK
2339
2340
2341
2342 http://cal.example.com/cyrus/work/poll3.ics
2343
2344
2345 "fffff-abcd3"
2346 BEGIN:VCALENDAR
2348 VERSION:2.0
2349 PRODID:-//Example Corp.//CalDAV Client//EN
2350 BEGIN:VPOLL
2351 DTSTART;TZID=US/Eastern:20121204T100000
2352 DURATION:PT4D
2353 SUMMARY:Poll #3
2354 UID:DC6C50A017428C5216A2F1CD@example.com
2355 END:VPOLL
2356 END:VCALENDAR
2357
2358
2359 HTTP/1.1 200 OK
2360
2361
2362
2364 7.4. CalDAV time ranges
2366 "CALDAV:time-range XML Element" in section=9.9 [RFC4791] describes
2367 how to specify time ranges to limit the set of calendar components
2368 returned by the server. This specification extends [RFC4791] to
2369 describe the meaning of time ranges for VPOLL
2371 A VPOLL component is said to overlap a given time range if the
2372 condition for the corresponding component state specified in the
2373 table below is satisfied. The conditions depend on the presence of
2374 the DTSTART, DURATION, DTEND, COMPLETED and CREATED properties in the
2375 VPOLL component. Note that, as specified above, the DTEND value MUST
2376 be a DATE-TIME value equal to or after the DTSTART value if
2377 specified.
2379 +-------------------------------------------------------------------+
2380 | VPOLL has the DTSTART property? |
2381 | +---------------------------------------------------------------+
2382 | | VPOLL has the DURATION property? |
2383 | | +-----------------------------------------------------------+
2384 | | | VPOLL has the DTEND property? |
2385 | | | +-------------------------------------------------------+
2386 | | | | VPOLL has the COMPLETED property? |
2387 | | | | +---------------------------------------------------+
2388 | | | | | VPOLL has the CREATED property? |
2389 | | | | | +-----------------------------------------------+
2390 | | | | | | Condition to evaluate |
2391 +---+---+---+---+---+-----------------------------------------------+
2392 | Y | Y | N | * | * | (start <= DTSTART+DURATION) AND |
2393 | | | | | | ((end > DTSTART) OR |
2394 | | | | | | (end >= DTSTART+DURATION)) |
2395 +---+---+---+---+---+-----------------------------------------------+
2396 | Y | N | Y | * | * | ((start < DTEND) OR (start <= DTSTART)) |
2397 | | | | | | AND |
2398 | | | | | | ((end > DTSTART) OR (end >= DTEND)) |
2399 +---+---+---+---+---+-----------------------------------------------+
2400 | Y | N | N | * | * | (start <= DTSTART) AND (end > DTSTART) |
2401 +---+---+---+---+---+-----------------------------------------------+
2402 | N | N | Y | * | * | (start < DTEND) AND (end >= DTEND) |
2403 +---+---+---+---+---+-----------------------------------------------+
2404 | N | N | N | Y | Y | ((start <= CREATED) OR (start <= COMPLETED))|
2405 | | | | | | AND |
2406 | | | | | | ((end >= CREATED) OR (end >= COMPLETED))|
2407 +---+---+---+---+---+-----------------------------------------------+
2408 | N | N | N | Y | N | (start <= COMPLETED) AND (end >= COMPLETED) |
2409 +---+---+---+---+---+-----------------------------------------------+
2410 | N | N | N | N | Y | (end > CREATED) |
2411 +---+---+---+---+---+-----------------------------------------------+
2412 | N | N | N | N | N | TRUE |
2413 +---+---+---+---+---+-----------------------------------------------+
2415 8. Security Considerations
2417 Applications using these property need to be aware of the risks
2418 entailed in using the URIs provided as values. See [RFC3986] for a
2419 discussion of the security considerations relating to URIs.
2421 9. IANA Considerations
2422 9.1. Parameter Registrations
2424 This document defines the following new iCalendar property parameters
2425 to be added to the registry defined in section=8.2.4 [RFC5545]:
2427 +--------------------+---------+----------------+
2428 | Property Parameter | Status | Reference |
2429 +--------------------+---------+----------------+
2430 | REQUIRED | Current | Section 4.3.1 |
2431 | STAY-INFORMED | Current | Section 4.3.2 |
2432 +--------------------+---------+----------------+
2434 9.2. Property Registrations
2436 This document defines the following new iCalendar properties to be
2437 added to the registry defined in section=8.2.3 [RFC5545]:
2439 +-----------------+---------+----------------+
2440 | Property | Status | Reference |
2441 +-----------------+---------+----------------+
2442 | ACCEPT-RESPONSE | Current | Section 4.4.7 |
2443 | POLL-ITEM-ID | Current | Section 4.4.3 |
2444 | POLL-MODE | Current | Section 4.4.4 |
2445 | POLL-PROPERTIES | Current | Section 4.4.5 |
2446 | POLL-WINNER | Current | Section 4.4.6 |
2447 | RESPONSE | Current | Section 4.4.8 |
2448 | VOTER | Current | Section 4.4.9 |
2449 +-----------------+---------+----------------+
2451 9.3. POLL-MODE Registration Template
2453 A poll mode is defined by completing the following template.
2455 Poll mode name
2456 The name of the poll mode.
2458 Purpose
2459 The purpose of the poll mode. Give a short but clear description.
2461 Reference
2462 A reference to the RFC in which the poll mode is defined
2464 9.4. POLL-MODE Registrations
2466 This document defines the following registered poll modes.
2468 +----------+--------------------------------------------+-----------+
2469 | Poll | Purpose | Reference |
2470 | mode | | |
2471 | name | | |
2472 +----------+--------------------------------------------+-----------+
2473 | BASIC | To provide simple voting for a single | Current |
2474 | | outcome from a number of candidates. | |
2475 +----------+--------------------------------------------+-----------+
2477 10. Acknowledgements
2479 The authors would like to thank the members of the Calendaring and
2480 Scheduling Consortium (CalConnect) for contributing their ideas and
2481 support.
2483 11. References
2485 11.1. Normative References
2487 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
2488 Requirement Levels", BCP 14, RFC 2119,
2489 DOI 10.17487/RFC2119, March 1997,
2490 .
2492 [RFC2518] Goland, Y., Whitehead, E., Faizi, A., Carter, S., and D.
2493 Jensen, "HTTP Extensions for Distributed Authoring --
2494 WEBDAV", RFC 2518, DOI 10.17487/RFC2518, February 1999,
2495 .
2497 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
2498 Resource Identifier (URI): Generic Syntax", STD 66,
2499 RFC 3986, DOI 10.17487/RFC3986, January 2005,
2500 .
2502 [RFC4791] Daboo, C., Desruisseaux, B., and L. Dusseault,
2503 "Calendaring Extensions to WebDAV (CalDAV)", RFC 4791,
2504 DOI 10.17487/RFC4791, March 2007,
2505 .
2507 [RFC5545] Desruisseaux, B., Ed., "Internet Calendaring and
2508 Scheduling Core Object Specification (iCalendar)",
2509 RFC 5545, DOI 10.17487/RFC5545, September 2009,
2510 .
2512 [RFC5546] Daboo, C., Ed., "iCalendar Transport-Independent
2513 Interoperability Protocol (iTIP)", RFC 5546,
2514 DOI 10.17487/RFC5546, December 2009,
2515 .
2517 [RFC6047] Melnikov, A., Ed., "iCalendar Message-Based
2518 Interoperability Protocol (iMIP)", RFC 6047,
2519 DOI 10.17487/RFC6047, December 2010,
2520 .
2522 [RFC6638] Daboo, C. and B. Desruisseaux, "Scheduling Extensions to
2523 CalDAV", RFC 6638, DOI 10.17487/RFC6638, June 2012,
2524 .
2526 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2527 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
2528 May 2017, .
2530 11.2. Informative References
2532 [IETF.TLP]
2533 IETF, "IETF Trust Legal Provisions (TLP)", April 2018,
2534 .
2536 [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC
2537 Text on Security Considerations", BCP 72, RFC 3552,
2538 DOI 10.17487/RFC3552, July 2003,
2539 .
2541 [RFC4918] Dusseault, L., Ed., "HTTP Extensions for Web Distributed
2542 Authoring and Versioning (WebDAV)", RFC 4918,
2543 DOI 10.17487/RFC4918, June 2007,
2544 .
2546 [RFC5378] Bradner, S., Ed. and J. Contreras, Ed., "Rights
2547 Contributors Provide to the IETF Trust", BCP 78, RFC 5378,
2548 DOI 10.17487/RFC5378, November 2008,
2549 .
2551 Appendix A. Open issues
2553 Notifications: Need to do a section on what Notifications to support.
2554 A. VPOLL is about to end and you haven't voted on it yet. Instead
2555 reuse VALARMS to notify the user?
2557 Future: Restarting a confirmed/completed VPOLL What to do with
2558 changes to STATUS:CONFIRMED? Allow them or not? What do to that
2559 poll had a winning event or todo. Stress VPOLL UID MUST be unique
2560 Changing status back from CONFIRMED MUST adjust status of any events
2561 booked as a result of confirmation. MUST winning event be cancelled
2562 for POLL-MODE basic? No - VOTER has indicated now unable to attend -
2563 want to revote
2564 Future: Voting on a confirmed/completed VPOLL Can a VOTER vote after
2565 completion? May be unable to attend and wants to indicate. Requires
2566 retention of VPOLL retention period Removed status
2568 ORGANIZER/ATTENDEE validity Can a user create a poll with scheduled
2569 events where that user's isn't the organizer of the poll? So is
2570 there a requirement that the account that poll is on is able to
2571 create each one of the resources in the poll? i.e. I can't create a
2572 poll with a set of events where I am just the attendee of the events.
2573 Are there any other restrictions for components in a VPOLL? Add to
2574 security consideration
2576 Update to existing event after poll confirm When voting on existing
2577 event - winning properties ONLY are merged in to the real event.
2579 Need to write down what isn't valid in a VPOLL a. Can't change POLL-
2580 MODE
2582 Guide for ATTENDEE roles chair, NON-PARTICIPANT etc
2584 ? - some iTip notes On confirm - send itip if appropriate (PUBLISH) -
2585 all non-participating - shared - feeds Organizer can specify where
2586 result is? Confirm can specify that itip is sent - ITIP / NONE -
2587 parameter ? on POLL-WINNER
2589 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 Calext V00: 2019-05-17 MD
2611 First calext version. Moved source to metanorma. No changes to
2612 specification.
2614 V03: 2014-10-28 MD
2616 * Add VVOTER and VOTE components.
2618 * Add RESPONSE property.
2620 * Remove RESPONSE parameter from VOTER.
2622 V03: 2014-05-12 MD
2624 * Add reply-url property and required parameter.
2626 * Fix ACCEPT-RESPONSE definition.
2628 V02: 2014-05-12 MD
2630 * Typos fixed, clarifications made.
2632 * Removed spurious COMMENT param. Switched some to PUBLIC-
2633 COMMENT
2635 * Changed STAY-INFORMED to remove boolean value type and state
2636 explicit TRUE/FALSE values.
2638 * iTip: Allow VPOLL DTSTART to be optional and allow
2639 VAVAILABILITY as subcomponent
2641 * iTip: fix broken table cells
2643 * Add POLL-PROPERTIES, POLL-WINNER to 5545 extensions table
2645 * Added Caldav scheduling section
2647 V01: 2013-08-07 MD
2649 * Removed method CONFIRM
2651 * Removed pollitemid from VPOLL abnf. Added text for pollwinner
2653 * Added POLL-WINNER and verbiage
2655 * Added STATUS values
2656 * Added RELTYPE=POLL
2658 * Added supported-vpoll-component-sets
2660 * Added CalDAV related parameters to VOTER
2662 * Removed bad CalDAV query example. State that queries cannot
2663 target the sub-components.
2665 Initial version: 2012-11-02 MD
2667 Authors' Addresses
2669 Eric York
2670 California Things, Inc
2671 650 Main Street
2672 Redwood City 94063
2673 United States of America
2675 Email: eric.york@gmail.com
2676 URI: www.linkedin.com/in/eryork
2678 Cyrus Daboo
2679 Apple Inc.
2680 1 Infinite Loop
2681 Cupertino 95014
2682 United States of America
2684 Email: cyrus@daboo.name
2685 URI: https://www.apple.com
2687 Michael Douglass
2688 Spherical Cow Group
2689 226 3rd Street
2690 Troy 12180
2691 United States of America
2693 Email: mikeadouglass@gmail.com
2694 URI: https://sphericalcowgroup.com/