idnits 2.17.1
draft-ietf-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 (November 21, 2019) is 1618 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 2417, but no explicit
reference was found in the text
== Unused Reference: 'RFC3552' is defined on line 2427, but no explicit
reference was found in the text
== Unused Reference: 'RFC4918' is defined on line 2432, but no explicit
reference was found in the text
== Unused Reference: 'RFC5378' is defined on line 2437, but no explicit
reference was found in the text
== Outdated reference: A later version (-19) exists of
draft-ietf-calext-eventpub-extensions-15
** Obsolete normative reference: RFC 2518 (Obsoleted by RFC 4918)
Summary: 1 error (**), 0 flaws (~~), 7 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: May 24, 2020 Apple Inc.
6 M. Douglass
7 Spherical Cow Group
8 November 21, 2019
10 VPOLL: Consensus Scheduling Component for iCalendar
11 draft-ietf-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 May 24, 2020.
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 Alternative Choices: 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 Participant Type Value . . . . . . . . . . . . . 12
67 4.2. Updated Relation Type Value . . . . . . . . . . . . . . . 12
68 4.3. Updated Status Value . . . . . . . . . . . . . . . . . . 13
69 4.4. New Property Parameters . . . . . . . . . . . . . . . . . 13
70 4.4.1. Required . . . . . . . . . . . . . . . . . . . . . . 13
71 4.4.2. Stay-Informed . . . . . . . . . . . . . . . . . . . . 14
72 4.5. New Properties . . . . . . . . . . . . . . . . . . . . . 14
73 4.5.1. Accept-Response . . . . . . . . . . . . . . . . . . . 14
74 4.5.2. Poll-Completion . . . . . . . . . . . . . . . . . . . 15
75 4.5.3. Poll-Item-Id . . . . . . . . . . . . . . . . . . . . 16
76 4.5.4. Poll-Mode . . . . . . . . . . . . . . . . . . . . . . 17
77 4.5.5. Poll-properties . . . . . . . . . . . . . . . . . . . 18
78 4.5.6. Poll-Winner . . . . . . . . . . . . . . . . . . . . . 18
79 4.5.7. Reply-URL . . . . . . . . . . . . . . . . . . . . . . 19
80 4.5.8. Response . . . . . . . . . . . . . . . . . . . . . . 20
81 4.6. New Components . . . . . . . . . . . . . . . . . . . . . 20
82 4.6.1. VPOLL Component . . . . . . . . . . . . . . . . . . . 20
83 4.6.2. VOTE Component . . . . . . . . . . . . . . . . . . . 23
84 5. Poll Modes . . . . . . . . . . . . . . . . . . . . . . . . . 24
85 5.1. POLL-MODE:BASIC . . . . . . . . . . . . . . . . . . . . . 25
86 5.1.1. Property restrictions . . . . . . . . . . . . . . . . 25
87 5.1.2. Outcome reporting . . . . . . . . . . . . . . . . . . 25
88 6. iTIP Extensions . . . . . . . . . . . . . . . . . . . . . . . 25
89 6.1. Methods . . . . . . . . . . . . . . . . . . . . . . . . . 25
90 6.2. Interoperability Models . . . . . . . . . . . . . . . . . 26
91 6.2.1. Delegation . . . . . . . . . . . . . . . . . . . . . 26
92 6.2.2. Acting on Behalf of Other Calendar Users . . . . . . 27
93 6.2.3. Component Revisions . . . . . . . . . . . . . . . . . 27
94 6.2.4. Message Sequencing . . . . . . . . . . . . . . . . . 27
95 6.3. Application Protocol Elements . . . . . . . . . . . . . . 27
96 6.3.1. Methods for VPOLL Calendar Components . . . . . . . . 27
97 6.3.2. Method: PUBLISH . . . . . . . . . . . . . . . . . . . 28
98 6.3.3. Method: REQUEST . . . . . . . . . . . . . . . . . . . 30
99 6.3.3.1. Rescheduling a poll . . . . . . . . . . . . . . . 32
100 6.3.3.2. Updating or Reconfirmation of a Poll . . . . . . 32
101 6.3.3.3. Confirmation of a Poll . . . . . . . . . . . . . 33
102 6.3.3.4. Closing a Poll . . . . . . . . . . . . . . . . . 33
103 6.3.3.5. Delegating a Poll to Another CU . . . . . . . . . 33
104 6.3.3.6. Changing the Organizer . . . . . . . . . . . . . 34
105 6.3.3.7. Sending on Behalf of the Organizer . . . . . . . 34
106 6.3.3.8. Forwarding to an Uninvited CU . . . . . . . . . . 34
107 6.3.3.9. Updating Voter Status . . . . . . . . . . . . . . 35
108 6.3.4. Method: REPLY . . . . . . . . . . . . . . . . . . . . 35
109 6.3.5. Method: CANCEL . . . . . . . . . . . . . . . . . . . 37
110 6.3.6. Method: REFRESH . . . . . . . . . . . . . . . . . . . 39
111 6.3.7. Method: POLLSTATUS . . . . . . . . . . . . . . . . . 40
112 7. CalDAV Extensions . . . . . . . . . . . . . . . . . . . . . . 42
113 7.1. Calendar Collection Properties . . . . . . . . . . . . . 42
114 7.1.1. CALDAV:supported-vpoll-component-sets . . . . . . . . 42
115 7.1.2. CALDAV:vpoll-max-items . . . . . . . . . . . . . . . 43
116 7.1.3. CALDAV:vpoll-max-active . . . . . . . . . . . . . . . 44
117 7.1.4. CALDAV:vpoll-max-voters . . . . . . . . . . . . . . . 45
118 7.1.5. CalDAV:even-more-properties . . . . . . . . . . . . . 46
119 7.1.6. Extensions to CalDAV scheduling . . . . . . . . . . . 46
120 7.2. Additional Preconditions for PUT, COPY, and MOVE . . . . 46
121 7.3. CalDAV:calendar-query Report . . . . . . . . . . . . . . 47
122 7.3.1. Example: Partial Retrieval of VPOLL . . . . . . . . . 47
123 7.4. CalDAV time ranges . . . . . . . . . . . . . . . . . . . 49
124 8. Security Considerations . . . . . . . . . . . . . . . . . . . 50
125 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 50
126 9.1. Parameter Registrations . . . . . . . . . . . . . . . . . 51
127 9.2. Property Registrations . . . . . . . . . . . . . . . . . 51
128 9.3. POLL-MODE Registration Template . . . . . . . . . . . . . 51
129 9.4. POLL-MODE Registrations . . . . . . . . . . . . . . . . . 51
130 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 52
131 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 52
132 11.1. Normative References . . . . . . . . . . . . . . . . . . 52
133 11.2. Informative References . . . . . . . . . . . . . . . . . 53
134 Appendix A. Open issues . . . . . . . . . . . . . . . . . . . . 53
135 Appendix B. Change log . . . . . . . . . . . . . . . . . . . . . 55
136 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 56
138 1. Introduction
140 The currently existing approach to agreeing on meeting times using
141 iTip [RFC5546] and/or iMip [RFC6047] has some significant failings.
142 There is no useful bargaining or suggestion mechanism in iTip, only
143 the ability for a potential attendee to accept or refuse or to
144 counter with a time of their own choosing.
146 Part of the problem is that for many potential attendees, their
147 freebusy is not an accurate representation of their availability. In
148 fact, when trying to schedule conference calls across different
149 organizations, attendees may not be allowed to provide freebusy
150 information or availability as this may reveal something of the
151 organizations internal activities.
153 A number of studies have shown that large amounts of time are spent
154 trying to come to an agreement - up to and beyond 20 working hours
155 per meeting. Many organizers fall back on other approaches such as
156 phone calls and email to determine a suitable time.
158 Online services have appeared as a result and these allow
159 participants to vote on a number of alternatives without revealing or
160 using freebusy or availability. When agreement is reached a
161 conventional scheduling message may be sent to the attendees. This
162 approach appears to reach consensus fairly rapidly. Peer pressure
163 may have some bearing on this as all voters are usually able to see
164 the current state of the voting and may adjust their own meeting
165 schedules to make themselves available for a popular choice.
167 The component and properties defined in this specification provide a
168 standardized structure for this process and allow calendar clients
169 and servers and web based services to interact.
171 These structures also have uses beyond the relatively simple needs of
172 most meeting organizers. The process of coming to consensus can also
173 be viewed as a bidding process.
175 2. Terms and definitions
177 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
178 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
179 "OPTIONAL" in this document are to be interpreted as described in
180 [RFC2119].
182 Additionally the following terms are used:
184 2.1. consensus scheduling
186 The process whereby users come to some agreement on meeting or task
187 alternatives and then book that meeting or task.
189 2.2. active Vpoll
191 A VPoll may have a DTSTART, DTEND and DURATION which may define the
192 start and end of the active voting period
194 2.3. voter
196 A participant who votes on the alternatives. A voter need not be an
197 attendee of any of the alternatives presented.
199 3. Simple Consensus Scheduling
201 This specification defines components and properties which can be
202 used for simple consensus scheduling but also have the generality to
203 handle more complex cases. To provide an easy (and for many -
204 sufficient) introduction to consensus scheduling and VPOLL we will
205 outline the flow of information for the simple case of voting on a
206 number of meeting alternatives which differ only in time. In
207 addition the voters will all be potential attendees.
209 This specification not only defines data structures but adds a new
210 iTip method used when consensus has been reached. This document will
211 show how a VPOLL object is used to inform voters of the state of a
212 simple vote on some alternatives.
214 3.1. The VPOLL Component: An Overview
216 The VPOLL component acts as a wrapper for a number of alternatives to
217 be voted on, together with some properties and a new component used
218 to maintain the state of the voting. For our simple example the
219 following VPOLL properties and sub-components are either required or
220 appropriate:
222 DTSTAMP
223 The usual [RFC5545] property.
225 SEQUENCE
226 The usual [RFC5545] property. See below for SEQUENCE behavior.
228 UID
229 The usual [RFC5545] property.
231 ORGANIZER
232 The usual [RFC5545] property. In general this need not be an
233 organizer of any of the alternatives. In this simple outline we
234 assume it is the same.
236 SUMMARY
237 The usual [RFC5545] property. This optional but recommended
238 property provides the a short title to the poll.
240 DESCRIPTION
241 The usual [RFC5545] property. This optional property provides
242 more details.
244 DTEND
245 The usual [RFC5545] property. This optional property provides a
246 poll closing time and date after which the VPOLL is no longer
247 active.
249 POLL-MODE
250 A new property which defines how the votes are used to obtain a
251 result. For our use case it will take the value "BASIC" meaning
252 one event will be chosen from the alternatives.
254 POLL-COMPLETION
255 A new property which defines who (server or client) chooses and/or
256 submits the winning choice. In our example the value is "SERVER-
257 SUBMIT" which means the client chooses the winner but the server
258 will submit the winning choice.
260 POLL-PROPERTIES
261 A new property which defines which icalendar properties are being
262 voted on. For our use case it will take the value "DTSTART,
263 LOCATION" meaning only those properties are significant for
264 voting. Other properties in the events may differ but are not
265 considered significant for the voting process.
267 PARTICIPANT
268 There is one of these components for each voter with the
269 PARTICIPANT-TYPE set to "VOTER". The CALENDAR-ADDRESS property
270 identifies the voter and this component will contain one VOTE
271 component for each item being voted on.
273 VOTE
274 A new component. There is one of these for each voter and choice.
275 It usually contains at least a POLL-ITEM-ID property to identify
276 the choice and a RESPONSE property to provide a vote. For more
277 complex poll modes it may contain other information such as cost
278 or estimated duration.
280 VEVENT
281 In our simple use case there will be multiple VEVENT sub-
282 components defining the alternatives. Each will have a different
283 date and or time for the meeting.
285 VPOLL with 3 voters and 3 alternative meetings:
287 BEGIN:VCALENDAR
288 VERSION:2.0
289 PRODID:-//Example//Example
290 METHOD:REQUEST
291 BEGIN:VPOLL
292 POLL-MODE:BASIC
293 POLL-COMPLETION:SERVER-SUBMIT
294 POLL-PROPERTIES:DTSTART,LOCATION
295 ORGANIZER:mailto:mike@example.com
296 UID:sched01-1234567890
297 DTSTAMP:20120101T000000Z
298 SUMMARY:What to do this week
299 DTEND:20120101T000000Z
300 BEGIN: PARTICIPANT
301 PARTICIPANT-TYPE: VOTER
302 CALENDAR-ADDRESS:mailto:cyrus@example.com
303 END PARTICIPANT
304 BEGIN: PARTICIPANT
305 PARTICIPANT-TYPE: VOTER
306 CALENDAR-ADDRESS:mailto:eric@example.com
307 END PARTICIPANT
308 BEGIN: PARTICIPANT
309 PARTICIPANT-TYPE: VOTER
310 CALENDAR-ADDRESS:mailto:mike@example.com
311 END PARTICIPANT
312 BEGIN:VEVENT.......(with a poll-item-id=1)
313 END:VEVENT
314 BEGIN:VEVENT.......(with a poll-item-id=2)
315 END:VEVENT
316 BEGIN:VEVENT.......(with a poll-item-id=3)
317 END:VEVENT
318 END:VPOLL
319 END:VCALENDAR
321 As can be seen in the example above, there is an iTip METHOD property
322 with the value REQUEST. The VPOLL object will be distributed to all
323 the voters, either through iMip or through some VPOLL enabled
324 service.
326 3.2. The VPOLL Alternative Choices: An Overview
328 Within the VPOLL component we have the alternatives to vote on. In
329 many respects these are standard [RFC5545] components. For our
330 simple use case they are all VEVENT components. In addition to the
331 usual [RFC5545] properties some extra properties are used for a
332 VPOLL.
334 POLL-ITEM-ID
335 This provides a unique reference to the sub-component within the
336 VPOLL. It's value SHOULD be a small integer.
338 3.3. VPOLL responses
340 Upon receipt of a VPOLL REQUEST the voter will reply with a VPOLL
341 component containing their vote. In our simple case it will have the
342 following properties and components:
344 DTSTAMP
345 The usual [RFC5545] property.
347 SEQUENCE
348 The usual [RFC5545] property. See below for SEQUENCE behavior.
350 UID
351 Same as the request.
353 ORGANIZER
354 Same as the request.
356 SUMMARY
357 Same as the request.
359 PARTICIPANT
360 One only with a CALENDAR-ADDRESS identifying the voter replying.
362 VOTE
363 One per item being voted on.
365 POLL-ITEM-ID
366 One inside each VOTE component to identify the choice.
368 RESPONSE
369 One inside each VOTE component to specify the vote.
371 Note that a voter can send a number of REPLYs for each REQUEST sent
372 by the organizer. Each REPLY completely replaces the voting record
373 for that voter for all components being voted on. In our example, if
374 Eric responds and votes for items 1 and 2 and then responds again
375 with a vote for only item 3, the final outcome is one vote on item 3.
377 NOTE
378 This is poll-mode specific behavior?
380 REPLY VPOLL from Cyrus:
382 BEGIN:VCALENDAR
383 VERSION:2.0
384 PRODID:-//Example//Example
385 METHOD: REPLY
386 BEGIN:VPOLL
387 ORGANIZER:mailto:mike@example.com
388 UID:sched01-1234567890
389 DTSTAMP:20120101T010000Z
390 SUMMARY:What to do this week
391 BEGIN:PARTICIPANT
392 PARTICIPANT-TYPE: VOTER
393 CALENDAR-ADDRESS:mailto:cyrus@example.com
394 BEGIN:VOTE
395 POLL-ITEM-ID:1
396 RESPONSE:50
397 COMMENT:Work on iTIP
398 END:VOTE
399 BEGIN:VOTE
400 POLL-ITEM-ID:2
401 RESPONSE:100
402 COMMENT:Work on WebDAV
403 END:VOTE
404 BEGIN:VOTE
405 POLL-ITEM-ID:3
406 RESPONSE:0
407 END:VOTE
408 END:PARTICIPANT
409 END:VPOLL
410 END:VCALENDAR
412 3.4. VPOLL updates
414 When the organizer receives a response from one or more voters the
415 current state of the poll is sent to all voters. The new iTip method
416 POLLSTATUS is used. The VPOLL can contain a reduced set of
417 properties but MUST contain DTSTAMP, SEQUENCE (if not 0), UID,
418 ORGANIZER and one or more PARTICIPANT components each populated with
419 zero or more VOTE components.
421 BEGIN:VCALENDAR
422 VERSION:2.0
423 PRODID:-//Example//Example
424 METHOD: POLLSTATUS
425 BEGIN:VPOLL
426 ORGANIZER:mailto:mike@example.com
427 UID:sched01-1234567890
428 DTSTAMP:20120101T020000Z
429 SEQUENCE:0
430 SUMMARY:What to do this week
431 BEGIN:PARTICIPANT
432 PARTICIPANT-TYPE: VOTER
433 CALENDAR-ADDRESS:mailto:cyrus@example.com
434 BEGIN: VOTE
435 POLL-ITEM-ID:1
436 RESPONSE:50
437 COMMENT:Work on iTIP
438 END:VOTE
439 BEGIN:VOTE
440 POLL-ITEM-ID:2
441 RESPONSE:100
442 COMMENT:Work on WebDAV
443 END:VOTE
444 BEGIN:VOTE
445 POLL-ITEM-ID:3
446 RESPONSE:0
447 END:VOTE
448 END:PARTICIPANT
449 BEGIN:PARTICIPANT
450 PARTICIPANT-TYPE: VOTER
451 CALENDAR-ADDRESS:mailto:eric@example.com
452 BEGIN:VOTE
453 POLL-ITEM-ID:1
454 RESPONSE:100
455 END:VOTE
456 BEGIN:VOTE
457 POLL-ITEM-ID:2
458 RESPONSE:100
459 END:VOTE
460 BEGIN:VOTE
461 POLL-ITEM-ID:3
462 RESPONSE:0
463 END:VOTE
464 END:PARTICIPANT
465 END:VPOLL
466 END:VCALENDAR
468 3.5. VPOLL Completion
470 After a number of REPLY messages have been received the poll will be
471 considered complete. If there is a DTEND on the poll the system may
472 automatically close the poll, or the organizer may, at any time,
473 consider the poll complete. A VPOLL can be completed (and
474 effectively closed for voting) by sending an iTip REQUEST message
475 with the VPOLL STATUS property set to COMPLETED.
477 The poll winner is confirmed by sending a final iTip REQUEST message
478 with the VPOLL STATUS property set to CONFIRMED. In this case the
479 VPOLL component contains all the events being voted on along with a
480 POLL-WINNER property to identify the winning event. As the POLL-
481 COMPLETION property is set to SERVER-SUBMIT the server will submit
482 the winning choice and when it has done so set the STATUS to
483 "SUBMITTED".
485 VPOLL confirmation:
487 BEGIN:VCALENDAR
488 VERSION:2.0
489 PRODID:-//Example//Example
490 METHOD: REQUEST
491 BEGIN:VPOLL
492 ORGANIZER:mailto:douglm@example.com
493 UID:sched01-1234567890
494 DTSTAMP:20120101T030000Z
495 COMPLETED:20120101T030000Z
496 POLL-COMPLETION:SERVER-SUBMIT
497 SEQUENCE:0
498 SUMMARY:What to do this week
499 STATUS:CONFIRMED
500 POLL-WINNER:3
501 BEGIN:VEVENT.......(with a poll-item-id=1)
502 END:VEVENT
503 BEGIN:VEVENT.......(with a poll-item-id=2)
504 END:VEVENT
505 BEGIN:VEVENT.......(with a poll-item-id=3)
506 END:VEVENT
507 END:VPOLL
508 END:VCALENDAR
510 3.6. Other Responses
512 A voter being asked to choose between a number of ORGANIZER supplied
513 alternatives may find none of them acceptable or may simply not care.
515 An alternative response, which may be disallowed by the ORGANIZER, is
516 to send back the respondees availability or freebusy or even one or
517 more new, alternative choices.
519 This is accomplished by responding with a VOTE component which has no
520 POLL-ITEM-ID property. In this case it MUST contain some alternative
521 information. What form this takes depends on the poll mode in
522 effect.
524 4. iCalendar Extensions
526 4.1. Updated Participant Type Value
528 Participant type property values are defined in section 11.2.1. of
529 [I-D.draft-ietf-calext-eventpub-extensions]. This specification
530 updates that type to include the new participant type VOTER to
531 provide information about the voter and to contain their votes.
533 Format Definition
534 This property parameter is redefined by the following notation:
536 partvalue /= "VOTER"
538 Description
539 The new property value indicates that the associated PARTICIPANT
540 component identifies a voter in a VPOLL.
542 4.2. Updated Relation Type Value
544 Relationship parameter type values are defined in section 3.2.15. of
545 [RFC5545]. This specification updates that type to include the new
546 relationship value POLL to provide a link to the VPOLL component in
547 which the current component appears.
549 Format Definition
550 This property parameter is redefined by the following notation:
552 reltypeparam /= "RELTYPE" "=" "POLL"
553 ; Property value is a VPOLL uid
555 Description
556 This parameter can be specified on a property that references
557 another related calendar component. The new parameter value
558 indicates that the associated property references a VPOLL
559 component which contains the current component.
561 4.3. Updated Status Value
563 Status property values are defined in section 3.8.1.11. of [RFC5545].
564 This specification updates that type to define valid VPOLL status
565 values.
567 Format Definition
568 This property parameter is redefined by the following notation:
570 statvalue /= statvalue-poll
571 ; Status values for "VPOLL".
572 statvalue-poll = "IN-PROCESS"
573 / "COMPLETED" ; Poll has closed,
574 ; nothing has been chosen yet
575 / "CONFIRMED" ; Poll has closed and
576 ; winning items confirmed
577 / "SUBMITTED" ; The winning item has been
578 ; submitted
579 / "CANCELLED"
581 Description
582 These values allow clients and servers to handle the choosing and
583 submission of winning choices.
585 If the client is choosing and the server submitting then the
586 client should set the POLL-WINNER property, set the status to
587 CONFIRMED and save the poll. When the server submits the winning
588 choice it will set the status to SUBMITTED.
590 4.4. New Property Parameters
592 4.4.1. Required
594 Parameter name
595 REQUIRED
597 Purpose
598 To specify whether the associated property is required in the
599 current context.
601 Format Definition
602 This parameter is defined by the following notation:
604 requirededparam = "REQUIRED" "=" ("TRUE" / "FALSE")
605 ; Default is FALSE
607 Description
608 This parameter MAY be specified on REPLY-URL and, if the value is
609 TRUE, indicates the organizer requires all replies to be made via
610 the specified service rather than iTip replies.
612 4.4.2. Stay-Informed
614 Parameter name
615 STAY-INFORMED
617 Purpose
618 To specify the voter also wants to be added as an ATTENDEE when
619 the poll is confirmed.
621 Format Definition
622 This parameter is defined by the following notation:
624 stayinformedparam = "STAY-INFORMED" "=" ("TRUE" / "FALSE")
625 ; Default is FALSE
627 Description
628 This parameter MAY be specified on the CALENDAR-ADDRESS property
629 in the PARTICIPANT component and, if the value is TRUE, indicates
630 the voter wishes to be added to the final choice as a non
631 participant.
633 4.5. New Properties
635 4.5.1. Accept-Response
637 Property name
638 ACCEPT-RESPONSE
640 Purpose
641 This property is used in VPOLL to indicate the types of component
642 that may be supplied in a response.
644 Property Parameters
645 Non-standard or iana parameters can be specified on this property.
647 Conformance
648 This property MAY be specified in a VPOLL component.
650 Description
651 When used in a VPOLL this property indicates what allowable
652 component types may be returned in a reply. Typically this would
653 allow a voter to respond with their freebusy or availability
654 rather than choosing one of the presented alternatives.
656 If this property is not present voters are only allowed to respond
657 to the choices in the request.
659 Format Definition
660 This property is defined by the following notation:
662 acceptresponse = "ACCEPT-RESPONSE" acceptresponseparams ":"
663 iana-token ("," iana-token) CRLF
665 acceptresponseparams = *(";" other-param)
667 4.5.2. Poll-Completion
669 Property name
670 POLL-COMPLETION
672 Purpose
673 This property is used in VPOLL to indicate whether the client or
674 server is responsible for choosing and/or submitting the
675 winner(s).
677 Description
678 When a VPOLL is stored on a server which is capable of handling
679 choosing and submission of winning choices a value of SERVER
680 indicates that the server should close the poll, choose the winner
681 and submit whenever it is appropriate to do so.
683 For example, in BASIC poll-mode, reaching the DTEND of the poll
684 could trigger this server side action.
685 Server initiated submission requires that the submitted choice
686 MUST be a valid calendaring component.
687 POLL-COMPLETION=SERVER-SUBMIT allows the client to set the poll-
688 winner, set the status to CONFIRMED and then store the poll on the
689 server. The server will then submit the winning choice and set
690 the status to SUBMITTED.
692 Format Definition
693 This property is defined by the following notation:
695 poll-completion = "POLL-COMPLETION" pcparam ":" pcvalue CRLF
697 pcparam = *(";" other-param)
699 pcvalue = "SERVER" ; The server is responsible for both choosing and
700 ; submitting the winner(s)
701 / "SERVER-SUBMIT" ; The server is responsible for
702 ; submitting the winner(s). The client chooses.
703 / "SERVER-CHOICE" ; The server is responsible for
704 ; choosing the winner(s). The client will submit.
705 / "CLIENT" ; The client is responsible for both choosing and
706 ; submitting the winner(s)
707 / iana-token
708 / x-name
709 ;Default is CLIENT
711 Example
712 The following is an example of this property:
714 POLL-COMPLETION: SERVER-SUBMIT
716 4.5.3. Poll-Item-Id
718 Property name
719 POLL-ITEM-ID
721 Purpose
722 This property is used in VPOLL child components as an identifier.
724 Value type
725 INTEGER
727 Property Parameters
728 Non-standard parameters can be specified on this property.
730 Conformance
731 This property MUST be specified in a VOTE component and in VPOLL
732 choice items.
734 Description
735 In a METHOD:REQUEST each choice component MUST have a POLL-ITEM-ID
736 property. Each set of components with the same POLL- ITEM-ID
737 value represents one overall set of items to be voted on.
739 POLL-ITEM-ID SHOULD be a unique small integer for each component
740 or set of components. If it remains the same between REQUESTs
741 then the previous response for that component MAY be re-used. To
742 force a re-vote on a component due to a significant change, the
743 POLL-ITEM-ID MUST change.
745 Format Definition
746 This property is defined by the following notation:
748 pollitemid = "POLL-ITEM-ID" pollitemdparams ":"
749 integer CRLF
751 pollitemidparams = *(
752 (";" other-param)
753 )
755 4.5.4. Poll-Mode
757 Property name
758 POLL-MODE
760 Purpose
761 This property is used in VPOLL to indicate what voting mode is to
762 be applied.
764 Property Parameters
765 Non-standard or iana parameters can be specified on this property.
767 Conformance
768 This property MAY be specified in a VPOLL component or its sub-
769 components.
771 Description
772 The poll mode defines how the votes are applied to obtain a
773 result. BASIC mode, the default, means that the voters are
774 selecting one component (or group of components) with a given
775 POLL=ITEM-ID.
777 Other polling modes may be defined in updates to this
778 specification. These may allow for such modes as ranking or task
779 assignment.
781 Format Definition
782 This property is defined by the following notation:
784 pollmode = "POLL-MODE" pollmodeparams ":"
785 ("BASIC" / iana-token / other-token) CRLF
787 pollmodeparams = *(";" other-param)
789 4.5.5. Poll-properties
791 Property name
792 POLL-PROPERTIES
794 Purpose
795 This property is used in VPOLL to define which icalendar
796 properties are being voted on.
798 Property Parameters
799 Non-standard or iana parameters can be specified on this property.
801 Conformance
802 This property MAY be specified in a VPOLL component.
804 Description
805 This property defines which icalendar properties are significant
806 in the voting process. It may not be clear to voters which
807 properties are varying in a significant manner. Clients may use
808 this property to highlight those listed properties.
810 Format Definition
811 This property is defined by the following notation:
813 pollproperties = "POLL-PROPERTIES" pollpropparams ":"
814 text *("," text) CRLF
816 pollpropparams = *(";" other-param)
818 4.5.6. Poll-Winner
820 Property name
821 POLL-WINNER
823 Purpose
824 This property is used in a basic mode VPOLL to indicate which of
825 the VPOLL sub-components won.
827 Value type
828 INTEGER
830 Property Parameters
831 Non-standard parameters can be specified on this property.
833 Conformance
834 This property MAY be specified in a VPOLL component.
836 Description
837 For poll confirmation each child component MUST have a POLL-ITEM-
838 ID property. For basic mode the VPOLL component SHOULD have a
839 POLL-WINNER property which MUST correspond to one of the POLL-
840 ITEM-ID properties and indicates which sub-component was the
841 winner.
843 Format Definition
844 This property is defined by the following notation:
846 pollwinner = "POLL-WINNER" pollwinnerparams ":"
847 integer CRLF
849 pollwinnerparams = *(";" other-param)
851 ; Used with a STATUS:CONFIRMED VPOLL to indicate which
852 ; components have been confirmed
854 4.5.7. Reply-URL
856 Property name
857 REPLY-URL
859 Purpose
860 This property may be used in scheduling messages to indicate
861 additional reply methods, for example a web-service.
863 Property Parameters
864 Non-standard, required or iana parameters can be specified on this
865 property.
867 Conformance
868 This property MAY be specified in a VPOLL component.
870 Description
871 When used in a scheduling message this property indicates
872 additional or required services that can be used to reply.
873 Typically this would be a web service of some form.
875 Format Definition
876 This property is defined by the following notation:
878 reply-url = "REPLY-URL" reply-urlparams ":" uri CRLF
880 reply-urlparams = *(
881 (";" requiredparam) /
882 (";" other-param)
883 )
885 4.5.8. Response
887 Property name
888 RESPONSE
890 Purpose
891 To specify a response vote.
893 Value type
894 INTEGER
896 Format Definition
897 This property is defined by the following notation:
899 response = "RESPONSE" response-params ":" integer CRLF
900 ; integer value 0..100
902 responseparams = *(";" other-param)
904 Description
905 This parameter can be specified on the POLL-ITEM-ID property to
906 provide the value of the voters response. This parameter allows
907 for fine grained responses which are appropriate to some
908 applications. For the case of individuals voting for a choice of
909 events, client applications SHOULD conform to the following
910 convention:
912 * 0 - 39 A "NO vote"
914 * 40 - 79 A "MAYBE" vote
916 * 80 - 89 A "YES - but not preferred vote"
918 * 90-100 A "YES" vote.
919 Clients MUST preserve the response value when there is no
920 change from the user even if they have a UI with fixed states
921 (e.g. yes/no/maybe).
923 4.6. New Components
925 4.6.1. VPOLL Component
927 Component name
928 VPOLL
930 Purpose
931 This component provides a mechanism by which voters can vote on
932 provided choices.
934 Format Definition
935 This property is defined by the following notation:
937 pollc = "BEGIN" ":" "VPOLL" CRLF
938 pollprop
939 *participantc *eventc *todoc *journalc *freebusyc
940 *availabilityc *alarmc *iana-comp *x-comp
941 "END" ":" "VPOLL" CRLF
943 pollprop = *(
944 ;
945 ; The following are REQUIRED,
946 ; but MUST NOT occur more than once.
947 ;
948 dtstamp / uid / organizer /
949 ;
950 ; The following are OPTIONAL,
951 ; but MUST NOT occur more than once.
952 ;
953 acceptresponse / class / created / completed /
954 description / dtstart / last-mod / pollmode /
955 pollproperties / priority / seq / status /
956 summary / url /
957 ;
958 ; Either 'dtend' or 'duration' MAY appear in
959 ; a 'pollprop', but 'dtend' and 'duration'
960 ; MUST NOT occur in the same 'pollprop'.
961 ; 'duration' MUST only occur when 'dtstart'
962 ; is present
963 ;
964 dtend / duration /
965 ;
966 ; The following are OPTIONAL,
967 ; and MAY occur more than once.
968 ;
969 attach / categories / comment /
970 contact / rstatus / related /
971 resources / x-prop / iana-prop
972 ;
973 ; The following is OPTIONAL, it SHOULD appear
974 ; once for the confirmation of a BASIC mode
975 ; VPOLL. Other modes may define differing
976 ; requirements.
977 ;
978 pollwinner /
979 ;
980 )
982 Description
983 This component provides a mechanism by which voters can vote on
984 provided choices. The outcome depends upon the POLL-MODE in
985 effect.
987 The PARTICIPANT components in VPOLL requests provide information
988 on each recipient who will be voting - both their identity through
989 the CALENDAR-ADDRESS property and their votes through the VOTE
990 components.
992 If specified, the "DTSTART" property defines the start or opening
993 of the poll active period. If absent the poll is presumed to have
994 started when created.
996 If "DTSTART" is present "DURATION" MAY be specified and indicates
997 the duration, and hence the ending, of the poll. The value of the
998 property MUST be a positive duration.
1000 "DTEND" MAY be specified with or without "DTSTART" and indicates
1001 the ending of the poll. If DTEND is specified it MUST be later
1002 than the DTSTART or CREATED property.
1004 If one or more VALARM components are included in the VPOLL they
1005 are not components to be voted on and MUST NOT contain a POLL-
1006 ITEM-ID property. VALARM sub-components may be used to provide
1007 warnings to the user when polls are due to start or end.
1009 TODO: Need some text to describe what relative alarms are relative
1010 to.
1012 4.6.2. VOTE Component
1014 Component name
1015 VOTE
1017 Purpose
1018 This component provides a mechanism by which voters can vote on
1019 provided choices.
1021 Conformance
1022 This component may be specified zero or more times in a
1023 PARTICIPANT component which identifies the voter.
1025 Format Definition
1026 This property is defined by the following notation:
1028 votec = "BEGIN" ":" "VOTE" CRLF
1029 voteprop
1030 *eventc *todoc *journalc *freebusyc
1031 *availabilityc *alarmc *iana-comp *x-comp
1032 "END" ":" "VOTE" CRLF
1034 voteprop = *(
1035 ;
1036 ; The following are REQUIRED,
1037 ; but MUST NOT occur more than once.
1038 ;
1039 pollitemid / response /
1040 ;
1041 ; The following are OPTIONAL,
1042 ; and MAY occur more than once.
1043 ;
1044 comment / x-prop / iana-prop
1045 ;
1046 )
1048 Description
1049 This component appears inside the PARTICIPANT component with a
1050 PARTICIPANT-TYPE of VOTER to identify the voter. This component
1051 contains that participants responses.
1053 The required and optional properties and their meanings will
1054 depend upon the POLL-MODE in effect.
1056 For any POLL-MODE, POLL-ITEM-ID is used to associate the
1057 information to a choice supplied by the organizer. This means
1058 that each VOTE component only provides information about that
1059 choice.
1061 If allowed by the POLL-MODE a VOTE component without a POLL-ITEM-
1062 ID may be provided in a REPLY to indicate a possible new choice or
1063 to provide information to the ORGANIZER - such as the respondees
1064 availability.
1066 5. Poll Modes
1068 The VPOLL component is intended to allow for various forms of
1069 polling. The particular form in efffect is indicated by the POLL-
1070 MODE property.
1072 New poll modes can be registered by including a completed POLL-MODE
1073 Registration Template (see Section 9.3) in a published RFC.
1075 5.1. POLL-MODE:BASIC
1077 BASIC poll mode is the form of voting in which one possible outcome
1078 is chosen from a set of possibilities. Usually this will be
1079 represented as a number of possible event objects one of which will
1080 be selected.
1082 5.1.1. Property restrictions
1084 This poll mode has the following property requirements:
1086 POLL-ITEM-ID
1087 Each contained sub-component that is being voted upon MUST contain
1088 a POLL-ITEM_ID property which is unique within the context of the
1089 POLL. The value MUST NOT be reused when events are removed and/or
1090 added to the poll.
1092 POLL-WINNER
1093 On confirmation of the poll this property MUST be present and
1094 identifies the winning component.
1096 5.1.2. Outcome reporting
1098 To confirm the winner the POLL-WINNER property MUST be present and
1099 the STATUS MUST be set to CONFIRMED.
1101 When the winning VEVENT or VTODO is not a scheduled entity, that is,
1102 it has no ORGANIZER or ATTENDEES it MUST be assigned an ORGANIZER
1103 property and a list of non-participating ATTENDEEs. This allows the
1104 winning entity to be distributed to the participants through iTip or
1105 some other protocol.
1107 6. iTIP Extensions
1109 This specification introduces a number of extensions to [RFC5546].
1110 In group scheduling the parties involved are organizer and attendees.
1111 In VPOLL the parties are organizer and voters.
1113 For many of the iTip processing rules the voters take the place of
1114 attendees.
1116 6.1. Methods
1118 There are some extensions to the behavior of iTip methods for a VPOLL
1119 object and two new methods are defined.
1121 +----------------+--------------------------------------------------+
1122 | Method | Description |
1123 +----------------+--------------------------------------------------+
1124 | PUBLISH | No changes (yet) |
1125 | REQUEST | Each child component MUST have a POLL-ITEM-ID |
1126 | | property. Each set of components with the same |
1127 | | POLL-ITEM-ID value represents one overall set of |
1128 | | items to be voted on. |
1129 | REPLY | There MUST be a single VPOLL component which |
1130 | | MUST have: either one or more POLL-ITEM-ID |
1131 | | properties with a RESPONSE param matching that |
1132 | | from a REQUEST or a VFREEBUSY or VAVAILABILITY |
1133 | | child component showing overall busy/available |
1134 | | time. The VPOLL MUST have one voter only. |
1135 | ADD | Not supported for VPOLL. |
1136 | CANCEL | There MUST be a single VPOLL component with UID |
1137 | | matching that of the poll being cancelled. |
1138 | REFRESH | The organizer returns a METHOD:REQUEST with the |
1139 | | current full state, or a METHOD:CANCEL or an |
1140 | | error if no matching poll is found. |
1141 | COUNTER | Not supported for VPOLL. |
1142 | DECLINECOUNTER | Not supported for VPOLL. |
1143 | POLLSTATUS | Used to send the current state of the poll to |
1144 | | all voters. The VPOLL can contain a reduced set |
1145 | | of properties but MUST contain DTSTAMP, SEQUENCE |
1146 | | (if not 0), UID, ORGANIZER and PARTICIPANTS. |
1147 +----------------+--------------------------------------------------+
1149 The following table shows the above methods broken down by who can
1150 send them with VPOLL components.
1152 +------------+------------------------------------------------+
1153 | Originator | Methods |
1154 +------------+------------------------------------------------+
1155 | Organizer | CANCEL, PUBLISH, REQUEST, POLLSTATUS |
1156 | Voter | REPLY, REFRESH, REQUEST (only when delegating) |
1157 +------------+------------------------------------------------+
1159 6.2. Interoperability Models
1161 Most of the standard iTip specification applies with respect to
1162 organizer and voters.
1164 6.2.1. Delegation
1166 TBD
1168 6.2.2. Acting on Behalf of Other Calendar Users
1170 TBD
1172 6.2.3. Component Revisions
1174 o Need to talk about what a change in SEQUENCE means
1176 o Sequence change forces a revote.
1178 o New voter - no sequence change
1180 o Add another poll set or change poll item ids or any change to a
1181 child
1183 o component - bump sequence
1185 6.2.4. Message Sequencing
1187 TBD
1189 6.3. Application Protocol Elements
1191 6.3.1. Methods for VPOLL Calendar Components
1193 This section defines the property set restrictions for the method
1194 types that are applicable to the "VPOLL" calendar component. Each
1195 method is defined using a table that clarifies the property
1196 constraints that define the particular method.
1198 The presence column uses the following values to assert whether a
1199 property is required or optional, and the number of times it may
1200 appear in the iCalendar object.
1202 +----------------+--------------------------------------------------+
1203 | Presence Value | Description |
1204 +----------------+--------------------------------------------------+
1205 | 1 | One instance MUST be present. |
1206 | 1+ | At least one instance MUST be present. |
1207 | 0 | Instances of this property MUST NOT be present. |
1208 | 0+ | Multiple instances MAY be present. |
1209 | 0 or 1 | Up to 1 instance of this property MAY be |
1210 | | present. |
1211 +----------------+--------------------------------------------------+
1213 The following summarizes the methods that are defined for the "VPOLL"
1214 calendar component.
1216 +------------+------------------------------------------------------+
1217 | Method | Description |
1218 +------------+------------------------------------------------------+
1219 | PUBLISH | Post notification of an poll. Used primarily as a |
1220 | | method of advertising the existence of a poll. |
1221 | REQUEST | To make a request for a poll. This is an explicit |
1222 | | invitation to one or more voters. Poll requests are |
1223 | | also used to update, change or confirm an existing |
1224 | | poll. Clients that cannot handle REQUEST MAY degrade |
1225 | | the poll to view it as a PUBLISH. REQUEST SHOULD NOT |
1226 | | be used just to set the status of the poll - |
1227 | | POLLSTATUS provides a more compact approach. |
1228 | REPLY | Reply to a poll request. Voters may set their |
1229 | | RESPONSE parameter to supply the current vote in the |
1230 | | range 0 to 100. |
1231 | CANCEL | Cancel a poll. |
1232 | REFRESH | A request is sent to an Organizer by a Voter asking |
1233 | | for the latest version of a poll to be resent to the |
1234 | | requester. |
1235 | POLLSTATUS | Used to send the current state of the poll to all |
1236 | | voters. The VPOLL can contain a reduced set of |
1237 | | properties but MUST contain DTSTAMP, SEQUENCE (if |
1238 | | not 0), UID, ORGANIZER and PARTICIPANT. |
1239 +------------+------------------------------------------------------+
1241 6.3.2. Method: PUBLISH
1243 The "PUBLISH" method in a "VPOLL" calendar component is an
1244 unsolicited posting of an iCalendar object. Any CU may add published
1245 components to their calendar. The "Organizer" MUST be present in a
1246 published iCalendar component. "Voters" MUST NOT be present. Its
1247 expected usage is for encapsulating an arbitrary poll as an iCalendar
1248 object. The "Organizer" may subsequently update (with another
1249 "PUBLISH" method) or cancel (with a "CANCEL" method) a previously
1250 published "VPOLL" calendar component.
1252 Note
1253 Not clear how useful this is but needs some work on transmitting
1254 the current vote without any voter identification.
1256 This method type is an iCalendar object that conforms to the
1257 following property constraints:
1259 +--------------------+----------+-----------------------------------+
1260 | Component/Property | Presence | Comment |
1261 +--------------------+----------+-----------------------------------+
1262 | METHOD | 1 | MUST equal PUBLISH. |
1263 | VPOLL | 1+ | |
1264 | DTSTAMP | 1 | |
1265 | DTSTART | 0 or 1 | If present defines the start of |
1266 | | | the poll. Otherwise the poll |
1267 | | | starts when it is created and |
1268 | | | distributed. |
1269 | ORGANIZER | 1 | |
1270 | SUMMARY | 1 | Can be null. |
1271 | UID | 1 | |
1272 | SEQUENCE | 0 or 1 | MUST be present if value is |
1273 | | | greater than 0; MAY be present if |
1274 | | | 0. |
1275 | ACCEPT-RESPONSE | 0 or 1 | |
1276 | ATTACH | 0+ | |
1277 | CATEGORIES | 0+ | |
1278 | CLASS | 0 or 1 | |
1279 | COMMENT | 0+ | |
1280 | COMPLETED | 0 or 1 | |
1281 | CONTACT | 0 or 1 | |
1282 | CREATED | 0 or 1 | |
1283 | DESCRIPTION | 0 or 1 | Can be null. |
1284 | DTEND | 0 or 1 | If present, DURATION MUST NOT be |
1285 | | | present. |
1286 | DURATION | 0 or 1 | If present, DTEND MUST NOT be |
1287 | | | present. |
1288 | LAST-MODIFIED | 0 or 1 | |
1289 | POLL-ITEM-ID | 0 | |
1290 | POLL-MODE | 0 or 1 | |
1291 | POLL-PROPERTIES | 0 or 1 | |
1292 | PRIORITY | 0 or 1 | |
1293 | RELATED-TO | 0+ | |
1294 | RESOURCES | 0+ | |
1295 | STATUS | 0 or 1 | MAY be one of |
1296 | | | COMPLETED/CONFIRMED/CANCELLED. |
1297 | URL | 0 or 1 | |
1298 | IANA-PROPERTY | 0+ | |
1299 | X-PROPERTY | 0+ | |
1300 | PARTICIPANT | 0+ | Only PARTICIPANT components with |
1301 | | | PARTICIPANT-TYPE not equal to |
1302 | | | "VOTER" - that is, no voters |
1303 | REQUEST-STATUS | 0 | |
1304 | VALARM | 0+ | |
1305 | VEVENT | 0+ | Depending upon the poll mode in |
1306 | | | effect there MAY be candidate |
1307 | | | components included in the poll |
1308 | | | component. |
1309 | VFREEBUSY | 0 | |
1310 | VJOURNAL | 0+ | Depending upon the poll mode in |
1311 | | | effect there MAY be candidate |
1312 | | | components included in the poll |
1313 | | | component. |
1314 | VTODO | 0+ | Depending upon the poll mode in |
1315 | | | effect there MAY be candidate |
1316 | | | components included in the poll |
1317 | | | component. |
1318 | VTIMEZONE | 0+ | MUST be present if any date/time |
1319 | | | refers to a timezone. |
1320 | IANA-COMPONENT | 0+ | |
1321 | X-COMPONENT | 0+ | |
1322 +--------------------+----------+-----------------------------------+
1324 Constraints for a METHOD:PUBLISH of a VPOLL
1326 6.3.3. Method: REQUEST
1328 The "REQUEST" method in a "VPOLL" component provides the following
1329 scheduling functions:
1331 o Invite "Voters" to respond to the poll.
1333 o Change the items being voted upon.
1335 o Complete or confirm the poll.
1337 o Response to a "REFRESH" request.
1339 o Update the details of an existing vpoll.
1341 o Update the status of "Voters".
1343 o Forward a "VPOLL" to another uninvited CU.
1345 o For an existing "VPOLL" calendar component, delegate the role of
1346 "Voter" to another CU.
1348 o For an existing "VPOLL" calendar component, change the role of
1349 "Organizer" to another CU.
1351 The "Organizer" originates the "REQUEST". The recipients of the
1352 "REQUEST" method are the CUs voting in the poll, the "Voters".
1353 "Voters" use the "REPLY" method to convey votes to the "Organizer".
1355 The "UID" and "SEQUENCE" properties are used to distinguish the
1356 various uses of the "REQUEST" method. If the "UID" property value in
1357 the "REQUEST" is not found on the recipient's calendar, then the
1358 "REQUEST" is for a new "VPOLL" calendar component. If the "UID"
1359 property value is found on the recipient's calendar, then the
1360 "REQUEST" is for an update, or a reconfirmation of the "VPOLL"
1361 calendar component.
1363 For the "REQUEST" method only a single iCalendar object is permitted.
1365 This method type is an iCalendar object that conforms to the
1366 following property constraints:
1368 +--------------------+----------+-----------------------------------+
1369 | Component/Property | Presence | Comment |
1370 +--------------------+----------+-----------------------------------+
1371 | METHOD | 1 | MUST be REQUEST. |
1372 | VPOLL | 1 | |
1373 | PARTICIPANT | 1+ | Identified as voters with the |
1374 | | | PARTICIPANT-TYPE=VOTER |
1375 | DTSTAMP | 1 | |
1376 | DTSTART | 0 or 1 | If present defines the start of |
1377 | | | the poll. Otherwise the poll |
1378 | | | starts when it is created and |
1379 | | | distributed. |
1380 | ORGANIZER | 1 | |
1381 | SEQUENCE | 0 or 1 | MUST be present if value is |
1382 | | | greater than 0; MAY be present if |
1383 | | | 0. |
1384 | SUMMARY | 1 | Can be null. |
1385 | UID | 1 | |
1386 | ACCEPT-RESPONSE | 0 or 1 | |
1387 | ATTACH | 0+ | |
1388 | CATEGORIES | 0+ | |
1389 | CLASS | 0 or 1 | |
1390 | COMMENT | 0+ | |
1391 | COMPLETED | 0 or 1 | |
1392 | CONTACT | 0+ | |
1393 | CREATED | 0 or 1 | |
1394 | DESCRIPTION | 0 or 1 | Can be null. |
1395 | DTEND | 0 or 1 | If present, DURATION MUST NOT be |
1396 | | | present. |
1397 | DURATION | 0 or 1 | If present, DTEND MUST NOT be |
1398 | | | present. |
1399 | GEO | 0 or 1 | |
1400 | LAST-MODIFIED | 0 or 1 | |
1401 | LOCATION | 0 or 1 | |
1402 | POLL-ITEM-ID | 0 | |
1403 | POLL-MODE | 0 or 1 | |
1404 | POLL-PROPERTIES | 0 or 1 | |
1405 | PRIORITY | 0 or 1 | |
1406 | RELATED-TO | 0+ | |
1407 | REQUEST-STATUS | 0 | |
1408 | RESOURCES | 0+ | |
1409 | STATUS | 0 or 1 | MAY be one of |
1410 | | | COMPLETED/CONFIRMED/CANCELLED. |
1411 | TRANSP | 0 or 1 | |
1412 | URL | 0 or 1 | |
1413 | IANA-PROPERTY | 0+ | |
1414 | X-PROPERTY | 0+ | |
1415 | VALARM | 0+ | |
1416 | VTIMEZONE | 0+ | MUST be present if any date/time |
1417 | | | refers to a timezone. |
1418 | IANA-COMPONENT | 0+ | |
1419 | X-COMPONENT | 0+ | |
1420 | VEVENT | 0+ | Depending upon the poll mode in |
1421 | | | effect there MAY be candidate |
1422 | | | components included in the poll |
1423 | | | component. |
1424 | VFREEBUSY | 0 | |
1425 | VJOURNAL | 0+ | Depending upon the poll mode in |
1426 | | | effect there MAY be candidate |
1427 | | | components included in the poll |
1428 | | | component. |
1429 | VTODO | 0+ | Depending upon the poll mode in |
1430 | | | effect there MAY be candidate |
1431 | | | components included in the poll |
1432 | | | component. |
1433 +--------------------+----------+-----------------------------------+
1435 Constraints for a METHOD:REQUEST of a VPOLL
1437 6.3.3.1. Rescheduling a poll
1439 The "REQUEST" method may be used to reschedule a poll, that is force
1440 a revote. A rescheduled poll involves a change to the existing poll
1441 in terms of its time the components being voted on may have changed.
1442 If the recipient CUA of a "REQUEST" method finds that the "UID"
1443 property value already exists on the calendar but that the "SEQUENCE"
1444 (or "DTSTAMP") property value in the "REQUEST" method is greater than
1445 the value for the existing poll, then the "REQUEST" method describes
1446 a rescheduling of the poll.
1448 6.3.3.2. Updating or Reconfirmation of a Poll
1450 The "REQUEST" method may be used to update or reconfirm a poll. An
1451 update to an existing poll does not involve changes to the time or
1452 candidates, and might not involve a change to the location or
1453 description for the poll. If the recipient CUA of a "REQUEST" method
1454 finds that the "UID" property value already exists on the calendar
1455 and that the "SEQUENCE" property value in the "REQUEST" is the same
1456 as the value for the existing poll, then the "REQUEST" method
1458 describes an update of the poll details, but not a rescheduling of
1459 the POLL.
1461 The update "REQUEST" method is the appropriate response to a
1462 "REFRESH" method sent from a "Voter" to the "Organizer" of a poll.
1464 The "Organizer" of a poll may also send unsolicited "REQUEST"
1465 methods. The unsolicited "REQUEST" methods may be used to update the
1466 details of the poll without rescheduling it, to update the "RESPONSE"
1467 parameter of "Voters", or to reconfirm the poll.
1469 6.3.3.3. Confirmation of a Poll
1471 The "REQUEST" method may be used to confirm a poll, that is announce
1472 the winner in BASIC mode. The STATUS MUST be set to CONFIRMED and
1473 for BASIC mode a VPOLL POLL-WINNER property must be provided with the
1474 poll-id of the winning component.
1476 6.3.3.4. Closing a Poll
1478 The "REQUEST" method may be used to close a poll, that is indicate
1479 voting is completed. The STATUS MUST be set to COMPLETED.
1481 6.3.3.5. Delegating a Poll to Another CU
1483 Some calendar and scheduling systems allow "Voters" to delegate the
1484 vote to another "Calendar User". iTIP supports this concept using the
1485 following workflow. Any "Voter" may delegate their right to vote in
1486 a poll to another CU. The implication is that the delegate
1487 participates in lieu of the original "Voter", NOT in addition to the
1488 "Voter". The delegator MUST notify the "Organizer" of this action
1489 using the steps outlined below. Implementations may support or
1490 restrict delegation as they see fit. For instance, some
1491 implementations may restrict a delegate from delegating a "REQUEST"
1492 to another CU.
1494 The "Delegator" of a poll forwards the existing "REQUEST" to the
1495 "Delegate". The "REQUEST" method MUST include a "Voter" property
1496 with the calendar address of the "Delegate". The "Delegator" MUST
1497 also send a "REPLY" method to the "Organizer" with the "Delegator's"
1498 "Voter" property "DELEGATED-TO" parameter set to the calendar address
1499 of the "Delegate". Also, a new "Voter" property for the "Delegate"
1500 MUST be included and must specify the calendar user address set in
1501 the "DELEGATED-TO" parameter, as above.
1503 In response to the request, the "Delegate" MUST send a "REPLY" method
1504 to the "Organizer", and optionally to the "Delegator". The "REPLY"
1506 method SHOULD include the "Voter" property with the "DELEGATED-FROM"
1507 parameter value of the "Delegator's" calendar address.
1509 The "Delegator" may continue to receive updates to the poll even
1510 though they will not be attending. This is accomplished by the
1511 "Delegator" setting their "role" attribute to "NON-PARTICIPANT" in
1512 the "REPLY" to the "Organizer".
1514 6.3.3.6. Changing the Organizer
1516 The situation may arise where the "Organizer" of a "VPOLL" is no
1517 longer able to perform the "Organizer" role and abdicates without
1518 passing on the "Organizer" role to someone else. When this occurs,
1519 the "Voters" of the "VPOLL" may use out-of-band mechanisms to
1520 communicate the situation and agree upon a new "Organizer". The new
1521 "Organizer" should then send out a new "REQUEST" with a modified
1522 version of the "VPOLL" in which the "SEQUENCE" number has been
1523 incremented and the "ORGANIZER" property has been changed to the new
1524 "Organizer".
1526 6.3.3.7. Sending on Behalf of the Organizer
1528 There are a number of scenarios that support the need for a "Calendar
1529 User" to act on behalf of the "Organizer" without explicit role
1530 changing. This might be the case if the CU designated as "Organizer"
1531 is sick or unable to perform duties associated with that function.
1532 In these cases, iTIP supports the notion of one CU acting on behalf
1533 of another. Using the "SENT-BY" parameter, a "Calendar User" could
1534 send an updated "VPOLL" "REQUEST". In the case where one CU sends on
1535 behalf of another CU, the "Voter" responses are still directed back
1536 towards the CU designated as "Organizer".
1538 6.3.3.8. Forwarding to an Uninvited CU
1540 A "Voter" invited to a "VPOLL" calendar component may send the
1541 "VPOLL" calendar component to another new CU not previously
1542 associated with the "VPOLL" calendar component. The current "Voter"
1543 participating in the "VPOLL" calendar component does this by
1544 forwarding the original "REQUEST" method to the new CU. The new CU
1545 can send a "REPLY" to the "Organizer" of the "VPOLL" calendar
1546 component. The reply contains a "Voter" property for the new CU.
1548 The "Organizer" ultimately decides whether or not the new CU becomes
1549 part of the poll and is not obligated to do anything with a "REPLY"
1550 from a new (uninvited) CU. If the "Organizer" does not want the new
1551 CU to be part of the poll, the new "Voter" property is not added to
1552 the "VPOLL" calendar component. The "Organizer" MAY send the CU a
1553 "CANCEL" message to indicate that they will not be added to the poll.
1555 If the "Organizer" decides to add the new CU, the new "Voter"
1556 property is added to the "VPOLL" calendar component. Furthermore,
1557 the "Organizer" is free to change any "Voter" property parameter from
1558 the values supplied by the new CU to something the "Organizer"
1559 considers appropriate. The "Organizer" SHOULD send the new CU a
1560 "REQUEST" message to inform them that they have been added.
1562 When forwarding a "REQUEST" to another CU, the forwarding "Voter"
1563 MUST NOT make changes to the original message.
1565 6.3.3.9. Updating Voter Status
1567 The "Organizer" of an poll may also request updated status from one
1568 or more "Voters". The "Organizer" sends a "REQUEST" method to the
1569 "Voter" and sets the "RSVP=TRUE" property parameter on the
1570 PARTICIPANT CALENDAR-ADDRESS. The "SEQUENCE" property for the poll
1571 is not changed from its previous value. A recipient will determine
1572 that the only change in the "REQUEST" is that their "RSVP" property
1573 parameter indicates a request for updated status. The recipient
1574 SHOULD respond with a "REPLY" method indicating their current vote
1575 with respect to the "REQUEST".
1577 6.3.4. Method: REPLY
1579 The "REPLY" method in a "VPOLL" calendar component is used to respond
1580 (e.g., accept or decline) to a "REQUEST" or to reply to a delegation
1581 "REQUEST". When used to provide a delegation response, the
1582 "Delegator" SHOULD include the calendar address of the "Delegate" on
1583 the "DELEGATED-TO" property parameter of the "Delegator's" "CALENDAR-
1584 ADDRESS" property. The "Delegate" SHOULD include the calendar
1585 address of the "Delegator" on the "DELEGATED-FROM" property parameter
1586 of the "Delegate's" "CALENDAR-ADDRESS" property.
1588 The "REPLY" method is also used when processing of a "REQUEST" fails.
1589 Depending on the value of the "REQUEST-STATUS" property, no action
1590 may have been performed.
1592 The "Organizer" of a poll may receive the "REPLY" method from a CU
1593 not in the original "REQUEST". For example, a "REPLY" may be
1594 received from a "Delegate" to a poll. In addition, the "REPLY"
1595 method may be received from an unknown CU (a "Party Crasher"). This
1596 uninvited "Voter" may be accepted, or the "Organizer" may cancel the
1597 poll for the uninvited "Voter" by sending a "CANCEL" method to the
1598 uninvited "Voter".
1600 A "Voter" MAY include a message to the "Organizer" using the
1601 "COMMENT" property. For example, if the user indicates a low
1602 interest and wants to let the "Organizer" know why, the reason can be
1603 expressed in the "COMMENT" property value.
1605 The "Organizer" may also receive a "REPLY" from one CU on behalf of
1606 another. Like the scenario enumerated above for the "Organizer",
1607 "Voters" may have another CU respond on their behalf. This is done
1608 using the "SENT-BY" parameter.
1610 The optional properties listed in the table below (those listed as
1611 "0+" or "0 or 1") MUST NOT be changed from those of the original
1612 request. (But see comments on VFREEBUSY and VAVAILABILITY)
1614 This method type is an iCalendar object that conforms to the
1615 following property constraints:
1617 +--------------------+----------+-----------------------------------+
1618 | Component/Property | Presence | Comment |
1619 +--------------------+----------+-----------------------------------+
1620 | METHOD | 1 | MUST be REPLY. |
1621 | VPOLL | 1+ | All components MUST have the same |
1622 | | | UID. |
1623 | PARTICIPANT | 1 | Identifies the Voter replying. |
1624 | DTSTAMP | 1 | |
1625 | ORGANIZER | 1 | |
1626 | UID | 1 | MUST be the UID of the original |
1627 | | | REQUEST. |
1628 | SEQUENCE | 0 or 1 | If non-zero, MUST be the sequence |
1629 | | | number of the original REQUEST. |
1630 | | | MAY be present if 0. |
1631 | ACCEPT-RESPONSE | 0 or 1 | |
1632 | ATTACH | 0+ | |
1633 | CATEGORIES | 0+ | |
1634 | CLASS | 0 or 1 | |
1635 | COMMENT | 0+ | |
1636 | COMPLETED | 0 or 1 | |
1637 | CONTACT | 0+ | |
1638 | CREATED | 0 or 1 | |
1639 | DESCRIPTION | 0 or 1 | |
1640 | DTEND | 0 or 1 | If present, DURATION MUST NOT be |
1641 | | | present. |
1642 | DTSTART | 0 or 1 | |
1643 | DURATION | 0 or 1 | If present, DTEND MUST NOT be |
1644 | | | present. |
1645 | GEO | 0 or 1 | |
1646 | LAST-MODIFIED | 0 or 1 | |
1647 | LOCATION | 0 or 1 | |
1648 | POLL-ITEM-ID | 1+ | One per item being voted on. |
1649 | POLL-MODE | 0 | |
1650 | POLL-PROPERTIES | 0 | |
1651 | PRIORITY | 0 or 1 | |
1652 | RELATED-TO | 0+ | |
1653 | RESOURCES | 0+ | |
1654 | REQUEST-STATUS | 0+ | |
1655 | STATUS | 0 or 1 | |
1656 | SUMMARY | 0 or 1 | |
1657 | TRANSP | 0 or 1 | |
1658 | URL | 0 or 1 | |
1659 | IANA-PROPERTY | 0+ | |
1660 | X-PROPERTY | 0+ | |
1661 | VALARM | 0 | |
1662 | VTIMEZONE | 0 or 1 | MUST be present if any date/time |
1663 | | | refers to a timezone. |
1664 | IANA-COMPONENT | 0+ | |
1665 | X-COMPONENT | 0+ | |
1666 | VEVENT | 0 | |
1667 | VFREEBUSY | 0 or 1 | A voter may respond with a |
1668 | | | VFREEBUSY component indicating |
1669 | | | that the ORGANIZER may select |
1670 | | | some other time which is not |
1671 | | | marked as busy. |
1672 | VAVAILABILITY | 0 | A voter may respond with a |
1673 | | | VAVAILABILITY component |
1674 | | | indicating that the ORGANIZER may |
1675 | | | select some other time which is |
1676 | | | shown as available. |
1677 | VJOURNAL | 0 | |
1678 | VTODO | 0 | |
1679 +--------------------+----------+-----------------------------------+
1681 Constraints for a METHOD:REPLY of a VPOLL
1683 6.3.5. Method: CANCEL
1685 The "CANCEL" method in a "VPOLL" calendar component is used to send a
1686 cancellation notice of an existing poll request to the affected
1687 "Voters". The message is sent by the "Organizer" of the poll.
1689 The "Organizer" MUST send a "CANCEL" message to each "Voter" affected
1690 by the cancellation. This can be done using a single "CANCEL"
1691 message for all "Voters" or by using multiple messages with different
1692 subsets of the affected "Voters" in each.
1694 When a "VPOLL" is cancelled, the "SEQUENCE" property value MUST be
1695 incremented as described in Section 6.2.3.
1697 Once a CANCEL message has been sent to all voters no further voting
1698 may take place. The poll is considered closed.
1700 This method type is an iCalendar object that conforms to the
1701 following property constraints:
1703 +--------------------+----------+-----------------------------------+
1704 | Component/Property | Presence | Comment |
1705 +--------------------+----------+-----------------------------------+
1706 | METHOD | 1 | MUST be CANCEL. |
1707 | VPOLL | 1+ | All must have the same UID. |
1708 | PARTICIPANT | 0+ | MUST include some or all Voters |
1709 | | | being removed from the poll. MUST |
1710 | | | include some or all Voters if the |
1711 | | | entire poll is cancelled. |
1712 | UID | 1 | MUST be the UID of the original |
1713 | | | REQUEST. |
1714 | DTSTAMP | 1 | |
1715 | ORGANIZER | 1 | |
1716 | SEQUENCE | 1 | |
1717 | ATTACH | 0+ | |
1718 | ACCEPT-RESPONSE | 0 | |
1719 | COMMENT | 0+ | |
1720 | COMPLETED | 0 or 1 | |
1721 | CATEGORIES | 0+ | |
1722 | CLASS | 0 or 1 | |
1723 | CONTACT | 0+ | |
1724 | CREATED | 0 or 1 | |
1725 | DESCRIPTION | 0 or 1 | |
1726 | DTEND | 0 or 1 | If present, DURATION MUST NOT be |
1727 | | | present. |
1728 | DTSTART | 0 or 1 | |
1729 | DURATION | 0 or 1 | If present, DTEND MUST NOT be |
1730 | | | present. |
1731 | GEO | 0 or 1 | |
1732 | LAST-MODIFIED | 0 or 1 | |
1733 | LOCATION | 0 or 1 | |
1734 | POLL-ITEM-ID | 0 | |
1735 | POLL-MODE | 0 | |
1736 | POLL-PROPERTIES | 0 | |
1737 | PRIORITY | 0 or 1 | |
1738 | RELATED-TO | 0+ | |
1739 | RESOURCES | 0+ | |
1740 | STATUS | 0 or 1 | MUST be set to CANCELLED to |
1741 | | | cancel the entire event. If |
1742 | | | uninviting specific Attendees, |
1743 | | | then MUST NOT be included. |
1744 | SUMMARY | 0 or 1 | |
1745 | TRANSP | 0 or 1 | |
1746 | URL | 0 or 1 | |
1747 | IANA-PROPERTY | 0+ | |
1748 | X-PROPERTY | 0+ | |
1749 | REQUEST-STATUS | 0 | |
1750 | VALARM | 0 | |
1751 | VTIMEZONE | 0+ | MUST be present if any date/time |
1752 | | | refers to a timezone. |
1753 | IANA-COMPONENT | 0+ | |
1754 | X-COMPONENT | 0+ | |
1755 | VTODO | 0 | |
1756 | VJOURNAL | 0 | |
1757 | VEVENT | 0 | |
1758 | VFREEBUSY | 0 | |
1759 +--------------------+----------+-----------------------------------+
1761 Constraints for a METHOD:CANCEL of a VPOLL
1763 6.3.6. Method: REFRESH
1765 The "REFRESH" method in a "VPOLL" calendar component is used by
1766 "Voters" of an existing event to request an updated description from
1767 the poll "Organizer". The "REFRESH" method must specify the "UID"
1768 property of the poll to update. The "Organizer" responds with the
1769 latest description and version of the poll.
1771 This method type is an iCalendar object that conforms to the
1772 following property constraints:
1774 +--------------------+----------+-----------------------------------+
1775 | Component/Property | Presence | Comment |
1776 +--------------------+----------+-----------------------------------+
1777 | METHOD | 1 | MUST be REFRESH. |
1778 | VPOLL | 1 | |
1779 | PARTICIPANT | 1 | MUST identify the requester as a |
1780 | | | voter. |
1781 | DTSTAMP | 1 | |
1782 | ORGANIZER | 1 | |
1783 | UID | 1 | MUST be the UID associated with |
1784 | | | original REQUEST. |
1785 | COMMENT | 0+ | |
1786 | COMPLETED | 0 | |
1787 | IANA-PROPERTY | 0+ | |
1788 | X-PROPERTY | 0+ | |
1789 | ACCEPT-RESPONSE | 0 | |
1790 | ATTACH | 0 | |
1791 | CATEGORIES | 0 | |
1792 | CLASS | 0 | |
1793 | CONTACT | 0 | |
1794 | CREATED | 0 | |
1795 | DESCRIPTION | 0 | |
1796 | DTEND | 0 | |
1797 | DTSTART | 0 | |
1798 | DURATION | 0 | |
1799 | GEO | 0 | |
1800 | LAST-MODIFIED | 0 | |
1801 | LOCATION | 0 | |
1802 | POLL-ITEM-ID | 0 | |
1803 | POLL-MODE | 0 | |
1804 | POLL-PROPERTIES | 0 | |
1805 | PRIORITY | 0 | |
1806 | RELATED-TO | 0 | |
1807 | REQUEST-STATUS | 0 | |
1808 | RESOURCES | 0 | |
1809 | SEQUENCE | 0 | |
1810 | STATUS | 0 | |
1811 | SUMMARY | 0 | |
1812 | URL | 0 | |
1813 | VALARM | 0 | |
1814 | VTIMEZONE | 0+ | |
1815 | IANA-COMPONENT | 0+ | |
1816 | X-COMPONENT | 0+ | |
1817 | VTODO | 0 | |
1818 | VJOURNAL | 0 | |
1819 | VEVENT | 0 | |
1820 | VFREEBUSY | 0 | |
1821 +--------------------+----------+-----------------------------------+
1823 Constraints for a METHOD:REFRESH of a VPOLL
1825 6.3.7. Method: POLLSTATUS
1827 The "POLLSTATUS" method in a "VPOLL" calendar component is used to
1828 inform recipients of the current status of the poll in a compact
1829 manner. The "Organizer" MUST be present in the confirmed poll
1830 component. All "Voters" MUST be present. The selected component(s)
1831 according to the poll mode SHOULD NOT be present in the poll
1832 component. Clients receiving this message may store the confirmed
1833 items in their calendars.
1835 This method type is an iCalendar object that conforms to the
1836 following property constraints:
1838 +--------------------+----------+-----------------------------------+
1839 | Component/Property | Presence | Comment |
1840 +--------------------+----------+-----------------------------------+
1841 | METHOD | 1 | MUST equal POLLSTATUS. |
1842 | VPOLL | 1+ | |
1843 | PARTICIPANT | 1+ | The voters containing their |
1844 | | | current vote |
1845 | COMPLETED | 0 or 1 | Only present for a completed poll |
1846 | DTSTAMP | 1 | |
1847 | DTSTART | 0 or 1 | |
1848 | ORGANIZER | 1 | |
1849 | SUMMARY | 1 | Can be null. |
1850 | UID | 1 | |
1851 | SEQUENCE | 0 or 1 | MUST be present if value is |
1852 | | | greater than 0; MAY be present if |
1853 | | | 0. |
1854 | ACCEPT-RESPONSE | 0 | |
1855 | ATTACH | 0 | |
1856 | CATEGORIES | 0 | |
1857 | CLASS | 0 | |
1858 | COMMENT | 0+ | |
1859 | CONTACT | 0 | |
1860 | CREATED | 0 or 1 | |
1861 | DESCRIPTION | 0 or 1 | Can be null. |
1862 | DTEND | 0 or 1 | If present, DURATION MUST NOT be |
1863 | | | present. |
1864 | DURATION | 0 or 1 | If present, DTEND MUST NOT be |
1865 | | | present. |
1866 | LAST-MODIFIED | 0 or 1 | |
1867 | POLL-ITEM-ID | 0 | |
1868 | POLL-MODE | 0 or 1 | |
1869 | POLL-PROPERTIES | 0 | |
1870 | PRIORITY | 0 or 1 | |
1871 | RELATED-TO | 0+ | |
1872 | RESOURCES | 0+ | |
1873 | STATUS | 0 or 1 | MAY be one of |
1874 | | | TENTATIVE/CONFIRMED/CANCELLED. |
1875 | URL | 0 or 1 | |
1876 | IANA-PROPERTY | 0+ | |
1877 | X-PROPERTY | 0+ | |
1878 | REQUEST-STATUS | 0 | |
1879 | VALARM | 0+ | |
1880 | VEVENT | 0 | All candidate components SHOULD |
1881 | | | NOT be present. |
1882 | VFREEBUSY | 0 | |
1883 | VJOURNAL | 0 | All candidate components SHOULD |
1884 | | | NOT be present. |
1885 | VTODO | 0 | All candidate components SHOULD |
1886 | | | NOT be present. |
1887 | VTIMEZONE | 0+ | MUST be present if any date/time |
1888 | | | refers to a timezone. |
1889 | IANA-COMPONENT | 0+ | |
1890 | X-COMPONENT | 0+ | |
1891 +--------------------+----------+-----------------------------------+
1893 Constraints for a METHOD:POLLSTATUS of a VPOLL
1895 7. CalDAV Extensions
1897 This specification extends [RFC4791] in that it defines a new
1898 component and new iCalendar properties to be supported and requires
1899 extra definitions related to time-ranges and reports.
1901 Additionally, it extends [RFC6638] as it a VPOLL component is a
1902 schedulable entity.
1904 7.1. Calendar Collection Properties
1906 This section defines new CalDAV properties for calendar collections.
1908 7.1.1. CALDAV:supported-vpoll-component-sets
1910 Name
1911 supported-vpoll-component-sets
1913 Namespace
1914 urn:ietf:params:xml:ns:caldav
1916 Purpose
1917 Specifies the calendar component types (e.g., VEVENT, VTODO, etc.)
1918 and combination of types that may be included in a VPOLL
1919 component.
1921 Conformance
1922 This property MAY be defined on any calendar collection. If
1923 defined, it MUST be protected and SHOULD NOT be returned by a
1924 PROPFIND DAV:allprop request (as defined in section=12.14.1
1925 [RFC2518]).
1927 Description
1928 The CALDAV:supported-vpoll-component-sets property is used to
1929 specify restrictions on the calendar component types that VPOLL
1930 components may contain in a calendar collection.
1932 It also specifies the combination of allowed component types.
1934 Any attempt by the client to store VPOLL components with component
1935 types or combinations of types not listed in this property, if it
1936 exists, MUST result in an error, with the "CALDAV:supported-vpoll-
1937 component-sets" precondition Section 7.2 being violated. Since
1938 this property is protected, it cannot be changed by clients using
1939 a PROPPATCH request. However, clients can initialize the value of
1940 this property when creating a new calendar collection with
1941 MKCALENDAR. In the absence of this property, the server MUST
1942 accept all component types, and the client can assume that all
1943 component types are accepted.
1945 Definition
1947
1950
1952
1955
1956
1957
1958
1959
1960
1962
1963
1964
1965
1966
1968
1969
1970
1971
1973
1974
1975
1976
1977
1979 7.1.2. CALDAV:vpoll-max-items
1981 Name
1982 vpoll-max-items
1984 Namespace
1985 urn:ietf:params:xml:ns:caldav
1987 Purpose
1988 Provides a numeric value indicating the maximum number of items
1989 that may be contained in any instance of a VPOLL calendar object
1990 resource stored in the calendar collection.
1992 Conformance
1993 This property MAY be defined on any calendar collection. If
1994 defined, it MUST be protected and SHOULD NOT be returned by a
1995 PROPFIND DAV:allprop request (as defined in section=12.14.1
1996 [RFC2518]).
1998 Description
1999 The CALDAV:vpoll-max-items is used to specify a numeric value that
2000 indicates the maximum number of iCalendar components in any one
2001 instance of a VPOLL calendar object resource stored in a calendar
2002 collection. Any attempt to store a calendar object resource with
2003 more components per instance than this value MUST result in an
2004 error, with the CALDAV: vpoll-max-items precondition Section 7.2
2005 being violated. In the absence of this property, the client can
2006 assume that the server can handle any number of items in a VPOLL
2007 calendar component.
2009 Definition
2011
2012 PCDATA value: a numeric value (integer greater than zero)
2014 25
2017 7.1.3. CALDAV:vpoll-max-active
2019 Name
2020 vpoll-max-active
2022 Namespace
2023 urn:ietf:params:xml:ns:caldav
2025 Purpose
2026 Provides a numeric value indicating the maximum number of active
2027 vpolls at any one time.
2029 Conformance
2030 This property MAY be defined on any calendar collection. If
2031 defined, it MUST be protected and SHOULD NOT be returned by a
2032 PROPFIND DAV:allprop request (as defined in section=12.14.1
2033 [RFC2518]).
2035 Description
2036 The CALDAV:vpoll-max-active is used to specify a numeric value
2037 that indicates the maximum number of active VPOLLs at any one
2038 time. Any attempt to store a new active VPOLL calendar object
2039 resource which results in exceeding this limit MUST result in an
2040 error, with the "CALDAV:vpoll-max-active" precondition Section 7.2
2041 being violated. In the absence of this property, the client can
2042 assume that the server can handle any number of active VPOLLs.
2044 Definition
2046
2047 PCDATA value: a numeric value (integer greater than zero)
2049 25
2052 7.1.4. CALDAV:vpoll-max-voters
2054 Name
2055 "vpoll-max-voters"
2057 Namespace
2058 "urn:ietf:params:xml:ns:caldav"
2060 Purpose
2061 Provides a numeric value indicating the maximum number of voters
2062 for any instance of a VPOLL calendar object resource stored in the
2063 calendar collection.
2065 Conformance
2066 This property MAY be defined on any calendar collection. If
2067 defined, it MUST be protected and SHOULD NOT be returned by a
2068 PROPFIND "DAV:allprop" request (as defined in section=12.14.1
2069 [RFC2518]).
2071 Description
2072 The "CALDAV:vpoll-max-voters" is used to specify a numeric value
2073 that indicates the maximum number of voters for any one instance
2074 of a VPOLL calendar object resource stored in a calendar
2075 collection. Any attempt to store a calendar object resource with
2076 more voters per instance than this value MUST result in an error,
2077 with the CALDAV: "vpoll-max-voters" precondition Section 7.2 being
2078 violated. In the absence of this property, the client can assume
2079 that the server can handle any number of voters in a VPOLL
2080 calendar component.
2082 Definition
2084
2085 PCDATA value: a numeric value (integer greater than zero)
2087 25
2090 7.1.5. CalDAV:even-more-properties
2092 TODO: vpoll-supported-mode poll options - e.g "vpoll-basic"
2094 7.1.6. Extensions to CalDAV scheduling
2096 This specification extends [RFC6638].
2098 Each section of Appendix A "Scheduling Privileges Summary" is
2099 extended to include VPOLL.
2101 Any reference to the ATTENDEE property should be read to include the
2102 CALENDAR-ADDRESS property contained in the PARTICIPANT compoents.
2103 That is, for scheduling purposes the CALENDAR-ADDRESS property is
2104 handled in exactly the same manner as the ATTENDEE property.
2106 7.2. Additional Preconditions for PUT, COPY, and MOVE
2108 This specification creates additional Preconditions for PUT, COPY,
2109 and MOVE methods. These preconditions apply when a PUT operation of
2110 a VPOLL calendar object resource into a calendar collection occurs,
2111 or when a COPY or MOVE operation of a calendar object resource into a
2112 calendar collection occurs, or when a COPY or MOVE operation occurs
2113 on a calendar collection.
2115 The new preconditions are:
2117 (CALDAV:supported-vpoll-component-sets)
2118 The VPOLL resource submitted in the PUT request, or targeted by a
2119 COPY or MOVE request, MUST contain a type or combination of
2120 calendar component that is supported in the targeted calendar
2121 collection;
2123 (CALDAV:vpoll-max-items)
2124 The VPOLL resource submitted in the PUT request, or targeted by a
2125 COPY or MOVE request, MUST have a number of sub-components
2126 (excluding VTIMEZONE) less than or equal to the value of the
2127 "CALDAV:vpoll-max-items" property value Section 7.1.2 on the
2128 calendar collection where the resource will be stored;
2130 (CALDAV:vpoll-max-active)
2131 The PUT request, or COPY or MOVE request, MUST not result in the
2132 number of active VPOLLs being greater than the value of the
2133 "CALDAV:vpoll-max-active" property value Section 7.1.3 on the
2134 calendar collection where the resource will be stored;
2136 (CALDAV:vpoll-max-voters)
2137 The VPOLL resource submitted in the PUT request, or targeted by a
2138 COPY or MOVE request, MUST have a number of voters represented by
2139 PARTICIPANT components less than or equal to the value of the
2140 "CALDAV:vpoll-max-voters" property value Section 7.1.4 on the
2141 calendar collection where the resource will be stored;
2143 7.3. CalDAV:calendar-query Report
2145 This allows the retrieval of VPOLLs and their included components.
2146 The query specification allows queries to be directed at the
2147 contained sub-components. For VPOLL queries this feature is
2148 disallowed. Time-range queries can only target the vpoll component
2149 itself.
2151 7.3.1. Example: Partial Retrieval of VPOLL
2153 In this example, the client requests the server to return specific
2154 components and properties of the VPOLL components that overlap the
2155 time range from December 4, 2012, at 00:00:00 A.M. UTC to December
2156 5, 2012, at 00:00:00 A.M. UTC. In addition, the "DAV:getetag"
2157 property is also requested and returned as part of the response.
2158 Note that due to the CALDAV: calendar-data element restrictions, the
2159 DTSTAMP property in VPOLL components has not been returned, and the
2160 only property returned in the VCALENDAR object is VERSION.
2162 >> Request <<
2164 REPORT /cyrus/work/ HTTP/1.1
2165 Host: cal.example.com
2166 Depth: 1
2167 Content-Type: application/xml; charset="utf-8"
2168 Content-Length: xxxx
2170
2171
2173
2174
2175
2176
2177
2178
2179
2180
2181
2182
2183
2184
2186
2187
2188
2189
2190
2191
2192
2194
2195
2196
2197
2199 >> Response <<
2201 HTTP/1.1 207 Multi-Status
2202 Date: Sat, 11 Nov 2012 09:32:12 GMT
2203 Content-Type: application/xml; charset="utf-8"
2204 Content-Length: xxxx
2206
2207
2209
2210 http://cal.example.com/cyrus/work/poll2.ics
2211
2212
2213 "fffff-abcd2"
2214 BEGIN:VCALENDAR
2215 VERSION:2.0
2216 BEGIN:VPOLL
2217 DTSTART;TZID=US/Eastern:20121202T120000
2218 DURATION:PT4D
2219 SUMMARY:Poll #2
2220 UID:00959BC664CA650E933C892C@example.com
2221 END:VPOLL
2222 END:VCALENDAR
2223
2224
2225 HTTP/1.1 200 OK
2226
2227
2228
2229 http://cal.example.com/cyrus/work/poll3.ics
2230
2231
2232 "fffff-abcd3"
2233 BEGIN:VCALENDAR
2235 VERSION:2.0
2236 PRODID:-//Example Corp.//CalDAV Client//EN
2237 BEGIN:VPOLL
2238 DTSTART;TZID=US/Eastern:20121204T100000
2239 DURATION:PT4D
2240 SUMMARY:Poll #3
2241 UID:DC6C50A017428C5216A2F1CD@example.com
2242 END:VPOLL
2243 END:VCALENDAR
2244
2245
2246 HTTP/1.1 200 OK
2247
2248
2249
2251 7.4. CalDAV time ranges
2253 "CALDAV:time-range XML Element" in section=9.9 [RFC4791] describes
2254 how to specify time ranges to limit the set of calendar components
2255 returned by the server. This specification extends [RFC4791] to
2256 describe the meaning of time ranges for VPOLL
2258 A VPOLL component is said to overlap a given time range if the
2259 condition for the corresponding component state specified in the
2260 table below is satisfied. The conditions depend on the presence of
2261 the DTSTART, DURATION, DTEND, COMPLETED and CREATED properties in the
2262 VPOLL component. Note that, as specified above, the DTEND value MUST
2263 be a DATE-TIME value equal to or after the DTSTART value if
2264 specified.
2266 +-------------------------------------------------------------------+
2267 | VPOLL has the DTSTART property? |
2268 | +---------------------------------------------------------------+
2269 | | VPOLL has the DURATION property? |
2270 | | +-----------------------------------------------------------+
2271 | | | VPOLL has the DTEND property? |
2272 | | | +-------------------------------------------------------+
2273 | | | | VPOLL has the COMPLETED property? |
2274 | | | | +---------------------------------------------------+
2275 | | | | | VPOLL has the CREATED property? |
2276 | | | | | +-----------------------------------------------+
2277 | | | | | | Condition to evaluate |
2278 +---+---+---+---+---+-----------------------------------------------+
2279 | Y | Y | N | * | * | (start <= DTSTART+DURATION) AND |
2280 | | | | | | ((end > DTSTART) OR |
2281 | | | | | | (end >= DTSTART+DURATION)) |
2282 +---+---+---+---+---+-----------------------------------------------+
2283 | Y | N | Y | * | * | ((start < DTEND) OR (start <= DTSTART)) |
2284 | | | | | | AND |
2285 | | | | | | ((end > DTSTART) OR (end >= DTEND)) |
2286 +---+---+---+---+---+-----------------------------------------------+
2287 | Y | N | N | * | * | (start <= DTSTART) AND (end > DTSTART) |
2288 +---+---+---+---+---+-----------------------------------------------+
2289 | N | N | Y | * | * | (start < DTEND) AND (end >= DTEND) |
2290 +---+---+---+---+---+-----------------------------------------------+
2291 | N | N | N | Y | Y | ((start <= CREATED) OR (start <= COMPLETED))|
2292 | | | | | | AND |
2293 | | | | | | ((end >= CREATED) OR (end >= COMPLETED))|
2294 +---+---+---+---+---+-----------------------------------------------+
2295 | N | N | N | Y | N | (start <= COMPLETED) AND (end >= COMPLETED) |
2296 +---+---+---+---+---+-----------------------------------------------+
2297 | N | N | N | N | Y | (end > CREATED) |
2298 +---+---+---+---+---+-----------------------------------------------+
2299 | N | N | N | N | N | TRUE |
2300 +---+---+---+---+---+-----------------------------------------------+
2302 8. Security Considerations
2304 Applications using these property need to be aware of the risks
2305 entailed in using the URIs provided as values. See [RFC3986] for a
2306 discussion of the security considerations relating to URIs.
2308 9. IANA Considerations
2309 9.1. Parameter Registrations
2311 This document defines the following new iCalendar property parameters
2312 to be added to the registry defined in section=8.2.4 [RFC5545]:
2314 +--------------------+---------+---------------+
2315 | Property Parameter | Status | Reference |
2316 +--------------------+---------+---------------+
2317 | REQUIRED | Current | Section 4.4.1 |
2318 | STAY-INFORMED | Current | Section 4.4.2 |
2319 +--------------------+---------+---------------+
2321 9.2. Property Registrations
2323 This document defines the following new iCalendar properties to be
2324 added to the registry defined in section=8.2.3 [RFC5545]:
2326 +-----------------+---------+---------------+
2327 | Property | Status | Reference |
2328 +-----------------+---------+---------------+
2329 | ACCEPT-RESPONSE | Current | Section 4.5.7 |
2330 | POLL-ITEM-ID | Current | Section 4.5.3 |
2331 | POLL-MODE | Current | Section 4.5.4 |
2332 | POLL-PROPERTIES | Current | Section 4.5.5 |
2333 | POLL-WINNER | Current | Section 4.5.6 |
2334 | RESPONSE | Current | Section 4.5.8 |
2335 +-----------------+---------+---------------+
2337 9.3. POLL-MODE Registration Template
2339 A poll mode is defined by completing the following template.
2341 Poll mode name
2342 The name of the poll mode.
2344 Purpose
2345 The purpose of the poll mode. Give a short but clear description.
2347 Reference
2348 A reference to the RFC in which the poll mode is defined
2350 9.4. POLL-MODE Registrations
2352 This document defines the following registered poll modes.
2354 +----------+--------------------------------------------+-----------+
2355 | Poll | Purpose | Reference |
2356 | mode | | |
2357 | name | | |
2358 +----------+--------------------------------------------+-----------+
2359 | BASIC | To provide simple voting for a single | Current |
2360 | | outcome from a number of candidates. | |
2361 +----------+--------------------------------------------+-----------+
2363 10. Acknowledgements
2365 The authors would like to thank the members of the Calendaring and
2366 Scheduling Consortium (CalConnect) for contributing their ideas and
2367 support.
2369 11. References
2371 11.1. Normative References
2373 [I-D.draft-ietf-calext-eventpub-extensions]
2374 Douglass, M., "Event Publishing Extensions to iCalendar",
2375 draft-ietf-calext-eventpub-extensions-15 (work in
2376 progress), October 2019.
2378 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
2379 Requirement Levels", BCP 14, RFC 2119,
2380 DOI 10.17487/RFC2119, March 1997,
2381 .
2383 [RFC2518] Goland, Y., Whitehead, E., Faizi, A., Carter, S., and D.
2384 Jensen, "HTTP Extensions for Distributed Authoring --
2385 WEBDAV", RFC 2518, DOI 10.17487/RFC2518, February 1999,
2386 .
2388 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
2389 Resource Identifier (URI): Generic Syntax", STD 66,
2390 RFC 3986, DOI 10.17487/RFC3986, January 2005,
2391 .
2393 [RFC4791] Daboo, C., Desruisseaux, B., and L. Dusseault,
2394 "Calendaring Extensions to WebDAV (CalDAV)", RFC 4791,
2395 DOI 10.17487/RFC4791, March 2007,
2396 .
2398 [RFC5545] Desruisseaux, B., Ed., "Internet Calendaring and
2399 Scheduling Core Object Specification (iCalendar)",
2400 RFC 5545, DOI 10.17487/RFC5545, September 2009,
2401 .
2403 [RFC5546] Daboo, C., Ed., "iCalendar Transport-Independent
2404 Interoperability Protocol (iTIP)", RFC 5546,
2405 DOI 10.17487/RFC5546, December 2009,
2406 .
2408 [RFC6047] Melnikov, A., Ed., "iCalendar Message-Based
2409 Interoperability Protocol (iMIP)", RFC 6047,
2410 DOI 10.17487/RFC6047, December 2010,
2411 .
2413 [RFC6638] Daboo, C. and B. Desruisseaux, "Scheduling Extensions to
2414 CalDAV", RFC 6638, DOI 10.17487/RFC6638, June 2012,
2415 .
2417 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2418 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
2419 May 2017, .
2421 11.2. Informative References
2423 [IETF.TLP]
2424 IETF, "IETF Trust Legal Provisions (TLP)", April 2018,
2425 .
2427 [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC
2428 Text on Security Considerations", BCP 72, RFC 3552,
2429 DOI 10.17487/RFC3552, July 2003,
2430 .
2432 [RFC4918] Dusseault, L., Ed., "HTTP Extensions for Web Distributed
2433 Authoring and Versioning (WebDAV)", RFC 4918,
2434 DOI 10.17487/RFC4918, June 2007,
2435 .
2437 [RFC5378] Bradner, S., Ed. and J. Contreras, Ed., "Rights
2438 Contributors Provide to the IETF Trust", BCP 78, RFC 5378,
2439 DOI 10.17487/RFC5378, November 2008,
2440 .
2442 Appendix A. Open issues
2444 public-comment: Not documented and was a parameter on something.
2445 Really sounds like a PARTICIPANT or VOTE property
2447 Notifications: Need to do a section on what Notifications to support.
2448 A. VPOLL is about to end and you haven't voted on it yet. Instead
2449 reuse VALARMS to notify the user?
2450 Future: Restarting a confirmed/completed VPOLL What to do with
2451 changes to STATUS:CONFIRMED? Allow them or not? What do to that
2452 poll had a winning event or todo. Stress VPOLL UID MUST be unique
2453 Changing status back from CONFIRMED MUST adjust status of any events
2454 booked as a result of confirmation. MUST winning event be cancelled
2455 for POLL-MODE basic? No - voter has indicated now unable to attend -
2456 want to revote
2458 Future: Voting on a confirmed/completed VPOLL Can a voter vote after
2459 completion? May be unable to attend and wants to indicate. Requires
2460 retention of VPOLL retention period Removed status
2462 ORGANIZER/ATTENDEE validity Can a user create a poll with scheduled
2463 events where that user's isn't the organizer of the poll? So is
2464 there a requirement that the account that poll is on is able to
2465 create each one of the resources in the poll? i.e. I can't create a
2466 poll with a set of events where I am just the attendee of the events.
2467 Are there any other restrictions for components in a VPOLL? Add to
2468 security consideration
2470 Update to existing event after poll confirm When voting on existing
2471 event - winning properties ONLY are merged in to the real event.
2473 Need to write down what isn't valid in a VPOLL
2474 a. Can't change POLL-MODE
2476 Guide for ATTENDEE roles chair, NON-PARTICIPANT etc
2478 ? - some iTip notes On confirm - send itip if appropriate (PUBLISH) -
2479 all non-participating - shared - feeds Organizer can specify where
2480 result is? Confirm can specify that itip is sent - ITIP / NONE -
2481 parameter ? on POLL-WINNER
2483 Need to add example of freebusy in response
2484 BEGIN:VCALENDAR
2485 VERSION:2.0
2486 PRODID:-//BedeworkCaldavTest//BedeworkCaldavTest
2487 METHOD: REPLY
2488 BEGIN:VPOLL
2489 ORGANIZER:mailto:douglm@mysite.edu
2490 BEGIN:PARTICIPANT
2491 PARTICIPANT-TYPE: VOTER
2492 CALENDAR-ADDRESS:mailto:eric@example.com
2493 UID:sched01-1234567890
2494 DTSTAMP:20120101T010000Z
2495 SEQUENCE:0
2496 SUMMARY:What to do this week
2497 BEGIN:VFREEBUSY
2498 .......
2499 END:VFREEBUSY
2500 END:PARTICIPANT
2501 END:VPOLL
2502 END:VCALENDAR
2504 Appendix B. Change log
2506 Calext V01: 2019-10-17 MD
2507 Replace VVOTER and VOTER with PARTICIPANT.
2509 Calext V00: 2019-05-17 MD
2510 First calext version. Moved source to metanorma. No changes to
2511 specification.
2513 V03: 2014-10-28 MD
2515 * Add VVOTER and VOTE components.
2517 * Add RESPONSE property.
2519 * Remove RESPONSE parameter from VOTER.
2521 V03: 2014-05-12 MD
2523 * Add reply-url property and required parameter.
2525 * Fix ACCEPT-RESPONSE definition.
2527 V02: 2014-05-12 MD
2529 * Typos fixed, clarifications made.
2531 * Removed spurious COMMENT param. Switched some to PUBLIC-
2532 COMMENT
2534 * Changed STAY-INFORMED to remove boolean value type and state
2535 explicit TRUE/FALSE values.
2537 * iTip: Allow VPOLL DTSTART to be optional and allow
2538 VAVAILABILITY as subcomponent
2540 * iTip: fix broken table cells
2542 * Add POLL-PROPERTIES, POLL-WINNER to 5545 extensions table
2544 * Added Caldav scheduling section
2546 V01: 2013-08-07 MD
2548 * Removed method CONFIRM
2550 * Removed pollitemid from VPOLL abnf. Added text for pollwinner
2552 * Added POLL-WINNER and verbiage
2554 * Added STATUS values
2556 * Added RELTYPE=POLL
2558 * Added supported-vpoll-component-sets
2560 * Added CalDAV related parameters to VOTER
2562 * Removed bad CalDAV query example. State that queries cannot
2563 target the sub-components.
2565 Initial version: 2012-11-02 MD
2567 Authors' Addresses
2569 Eric York
2570 California Things, Inc
2571 650 Main Street
2572 Redwood City 94063
2573 United States of America
2575 Email: eric.york@gmail.com
2576 URI: www.linkedin.com/in/eryork
2577 Cyrus Daboo
2578 Apple Inc.
2579 1 Infinite Loop
2580 Cupertino 95014
2581 United States of America
2583 Email: cyrus@daboo.name
2584 URI: https://www.apple.com
2586 Michael Douglass
2587 Spherical Cow Group
2588 226 3rd Street
2589 Troy 12180
2590 United States of America
2592 Email: mikeadouglass@gmail.com
2593 URI: https://sphericalcowgroup.com/