idnits 2.17.00 (12 Aug 2021)
/tmp/idnits42070/draft-ietf-calext-ical-tasks-03.txt:
Checking boilerplate required by RFC 5378 and the IETF Trust (see
https://trustee.ietf.org/license-info):
----------------------------------------------------------------------------
No issues found here.
Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt:
----------------------------------------------------------------------------
No issues found here.
Checking nits according to https://www.ietf.org/id-info/checklist :
----------------------------------------------------------------------------
-- The draft header indicates that this document updates RFC5545, but the
abstract doesn't seem to directly say this. It does mention RFC5545
though, so this could be OK.
Miscellaneous warnings:
----------------------------------------------------------------------------
== Line 350 has weird spacing: '...ication impro...'
== Line 352 has weird spacing: '...lanning clari...'
== Line 356 has weird spacing: '...ignment ensur...'
== Line 359 has weird spacing: '...racking impro...'
== Line 375 has weird spacing: '...sk type expli...'
== (5 more instances...)
(Using the creation date from RFC5545, updated by this document, for
RFC5378 checks: 2005-10-26)
-- The document seems to lack a disclaimer for pre-RFC5378 work, but may
have content which was first submitted before 10 November 2008. If you
have contacted all the original authors and they are all willing to grant
the BCP78 rights to the IETF Trust, then this is fine, and you can ignore
this comment. If not, you may need to add the pre-RFC5378 disclaimer.
(See the Legal Provisions document at
https://trustee.ietf.org/license-info for more information.)
-- The document date (21 March 2022) is 54 days in the past. Is this
intentional?
Checking references for intended status: Proposed Standard
----------------------------------------------------------------------------
(See RFCs 3967 and 4897 for information about using normative references
to lower-maturity documents in RFCs)
== Missing Reference: 'Doug114' is mentioned on line 417, but not defined
== Missing Reference: 'VPOLL' is mentioned on line 484, but not defined
== Missing Reference: 'Doug214' is mentioned on line 567, but not defined
== Unused Reference: 'EDISTS' is defined on line 1123, but no explicit
reference was found in the text
== Unused Reference: 'WSCal' is defined on line 1132, but no explicit
reference was found in the text
== Unused Reference: 'WSHT' is defined on line 1135, but no explicit
reference was found in the text
Summary: 0 errors (**), 0 flaws (~~), 12 warnings (==), 3 comments (--).
Run idnits with the --verbose option for more detailed information about
the items above.
--------------------------------------------------------------------------------
2 Network Working Group A. Apthorp
3 Internet-Draft DHL Express
4 Updates: 5545 (if approved) M. Douglass
5 Intended status: Standards Track Bedework Commercial Services
6 Expires: 22 September 2022 21 March 2022
8 Task Extensions to iCalendar
9 draft-ietf-calext-ical-tasks-03
11 Abstract
13 This document defines extensions to the Internet Calendaring and
14 Scheduling Core Object Specification (iCalendar) (RFC5545) to provide
15 improved status tracking, scheduling and specification of tasks.
17 It also defines how Calendaring Extensions to WebDAV (CalDAV) (RFC
18 4791) servers can be extended to support certain automated task
19 management behaviours.
21 Status of This Memo
23 This Internet-Draft is submitted in full conformance with the
24 provisions of BCP 78 and BCP 79.
26 Internet-Drafts are working documents of the Internet Engineering
27 Task Force (IETF). Note that other groups may also distribute
28 working documents as Internet-Drafts. The list of current Internet-
29 Drafts is at https://datatracker.ietf.org/drafts/current/.
31 Internet-Drafts are draft documents valid for a maximum of six months
32 and may be updated, replaced, or obsoleted by other documents at any
33 time. It is inappropriate to use Internet-Drafts as reference
34 material or to cite them other than as "work in progress."
36 This Internet-Draft will expire on 22 September 2022.
38 Copyright Notice
40 Copyright (c) 2022 IETF Trust and the persons identified as the
41 document authors. All rights reserved.
43 This document is subject to BCP 78 and the IETF Trust's Legal
44 Provisions Relating to IETF Documents (https://trustee.ietf.org/
45 license-info) in effect on the date of publication of this document.
46 Please review these documents carefully, as they describe your rights
47 and restrictions with respect to this document. Code Components
48 extracted from this document must include Revised BSD License text as
49 described in Section 4.e of the Trust Legal Provisions and are
50 provided without warranty as described in the Revised BSD License.
52 Table of Contents
54 1. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 3
55 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
56 2.1. Terms and Definitions . . . . . . . . . . . . . . . . . . 4
57 3. Task Architecture . . . . . . . . . . . . . . . . . . . . . . 5
58 4. Task Architecture Elements . . . . . . . . . . . . . . . . . 7
59 5. Architecture Foundations . . . . . . . . . . . . . . . . . . 8
60 6. Task Extensions . . . . . . . . . . . . . . . . . . . . . . . 9
61 7. Task Specification . . . . . . . . . . . . . . . . . . . . . 9
62 7.1. CONCEPT for task type identification . . . . . . . . . . 10
63 7.2. Task Context and Relationships . . . . . . . . . . . . . 10
64 7.3. Task Domain Data Handling . . . . . . . . . . . . . . . . 10
65 8. Task Deadlines, Milestones and Time Planning . . . . . . . . 11
66 9. Task Scheduling and Assignment . . . . . . . . . . . . . . . 11
67 10. Status Reporting . . . . . . . . . . . . . . . . . . . . . . 12
68 10.1. Improved granularity in status reporting information . . 12
69 10.2. Relating reason and comments to ATTENDEE status
70 changes. . . . . . . . . . . . . . . . . . . . . . . . . 12
71 10.3. Comments associated to reasons and status changes . . . 12
72 10.4. Task Alerts and Notifications . . . . . . . . . . . . . 13
73 10.5. Automated Status Changes . . . . . . . . . . . . . . . . 14
74 11. New Parameter Values . . . . . . . . . . . . . . . . . . . . 14
75 11.1. Redefined VTODO Participant Status . . . . . . . . . . . 14
76 12. New Properties . . . . . . . . . . . . . . . . . . . . . . . 14
77 12.1. Estimated Duration . . . . . . . . . . . . . . . . . . . 14
78 12.2. Reason . . . . . . . . . . . . . . . . . . . . . . . . . 15
79 12.3. Sub-State . . . . . . . . . . . . . . . . . . . . . . . 16
80 12.4. Task Mode . . . . . . . . . . . . . . . . . . . . . . . 17
81 13. Property Extensions and Clarifications . . . . . . . . . . . 18
82 13.1. Redefined STATUS Property . . . . . . . . . . . . . . . 19
83 14. New Components . . . . . . . . . . . . . . . . . . . . . . . 19
84 14.1. Status Component . . . . . . . . . . . . . . . . . . . . 19
85 15. CalDAV Support for Task Mode . . . . . . . . . . . . . . . . 20
86 15.1. CALDAV:supported-task-mode-set Property . . . . . . . . 21
87 16. Security Considerations . . . . . . . . . . . . . . . . . . . 22
88 17. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22
89 17.1. Initialization of the Status registry . . . . . . . . . 22
90 17.2. Update of the Status registry . . . . . . . . . . . . . 22
91 17.3. Sub-State value registry . . . . . . . . . . . . . . . . 23
92 17.4. Task Mode value registry . . . . . . . . . . . . . . . . 23
93 17.5. Participation Statuses registry . . . . . . . . . . . . 24
94 17.6. Properties registry . . . . . . . . . . . . . . . . . . 24
95 18. Normative References . . . . . . . . . . . . . . . . . . . . 24
96 19. Informative References . . . . . . . . . . . . . . . . . . . 25
97 Appendix A. Examples of Task State Lifecycle . . . . . . . . . . 26
98 A.1. Simple Case Status Change . . . . . . . . . . . . . . . . 26
99 A.2. Example for multiple Attendees . . . . . . . . . . . . . 26
100 A.3. Example of Failure . . . . . . . . . . . . . . . . . . . 28
101 Appendix B. Change log . . . . . . . . . . . . . . . . . . . . . 28
102 Appendix C. Working Notes . . . . . . . . . . . . . . . . . . . 29
103 C.1. Advertising tasks . . . . . . . . . . . . . . . . . . . . 29
104 C.2. Subscribing to task updates . . . . . . . . . . . . . . . 29
105 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 29
107 1. Acknowledgements
109 The authors would like to thank the members of the Calendaring and
110 Scheduling Consortium technical committees and the following
111 individuals for contributing their ideas, support and comments:
113 John Chaffee, Marten Gajda, Ken Murchison
115 The authors would also like to thank CalConnect, the Calendaring and
116 Scheduling Consortium, for advice with this specification.
118 2. Introduction
120 This document specifies extensions to the existing Internet
121 Calendaring and Scheduling Core Object Specification (iCalendar)
122 [RFC5545], and associated protocols, in order to enhance the
123 structured communication and execution of tasks. The enhancements
124 allow for the communication, time planning and scheduling of tasks by
125 and between automated systems (e.g. in smart power grids, business
126 process management systems) as well as for human centered tasks.
128 A "task" is a representation of an item of work assigned to an
129 individual or organization. In the iCalendar Object Model [RFC5545]
130 the representation of tasks is by "VTODO" calendar components. Tasks
131 can be identified in a number of situations, either informally as ad-
132 hoc tasks in personal "to-do" lists or more formally in:
134 * Business processes - ranging from repetitive workflows to adaptive
135 cases and trouble ticketing
137 * Project Management - whether for large scale construction projects
138 or collaborative software development
140 The extensions specified here are defined in the context of an
141 overall architecture for task calendaring and scheduling.
143 2.1. Terms and Definitions
145 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
146 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
147 "OPTIONAL" in this document are to be interpreted as described in BCP
148 14 [RFC2119] [RFC8174] when, and only when, they appear in all
149 capitals, as shown here.
151 Terms defined in this specification include:
153 Assignee A calendar user assigned to perform a given task. An
154 assignee is equivalent to an attendee of an event.
156 Calendar User (CU) A person or software system that accesses or
157 modifies calendar information.
159 Calendar User Agent (CUA) This may be
161 1. Software with which the calendar user communicates with a
162 calendar service or local calendar store to access calendar
163 information.
165 2. Software that gathers calendar data on the Calendar User's
166 behalf.
168 Candidate A calendar user who might be able to perform a given task,
169 prior to actually being assigned the task, e.g., a dispatcher has
170 a list of taxi drivers (candidates) from which one will be
171 selected to pick-up a passenger.
173 Organizer A calendar user who creates a calendar item, requests
174 free/busy information, or published free/busy information. It is
175 an Organizer who invites Attendees [RFC5545].
177 Observer A calendar user interested in a calendar component, e.g., a
178 manager may have interest in all tasks that have not been
179 completed.
181 Resource A resource in the scheduling context is any shared entity
182 that can be scheduled by a calendar user, but does not control its
183 own attendance status. Resources can be of "Location",
184 "Equipment", or "Role" type.
186 Task A representation of an item of work that can be assigned to one
187 or more task actor assignees. In [RFC5545], these are "VTODO"
188 calendar components, which are groupings of component properties
189 and possibly "VALARM" calendar components that represent an
190 action-item or assignment.
192 3. Task Architecture
194 A reference architecture for task calendaring and scheduling is
195 defined in order to identify the key logical elements involved in
196 task management and the interfaces between them to enable
197 interoperability. The logical elements identified here establish an
198 appropriate separation of concerns and clarify the responsibilities
199 of different elements. However, the architecture does not prescribe
200 a binding or packaging of elements, i.e., software systems may be
201 developed where some elements are tightly bound and the interfaces
202 between bound elements are not exposed. The task architecture is
203 also described in [TARCH].
205 Task +-------+
206 Trigger |
207 +---------------------V---------------------+ +-----------+
208 | Task Generating System | | |
209 | +-------------------------+ | | |
210 | | O | | | |
211 | | /|\ | | | |
212 | | / \ | | | |
213 | | Task Organizer | <----> |
214 | +-^--------^--------------+ | | |
215 | | | | | |
216 | +--------V-+ +----V-----+ +----------+ | | |
217 | | Task | | Process | | Task | | | |
218 | |Assignment| | Logic <----> Domain | | | |
219 | | Rules | | | | Data | | | |
220 | +----------+ +----------+ +----------+ | | |
221 | | | |
222 +------^----------+-----^-------------------+ | |
223 | | | | |
224 Availability Task Task | |
225 | | Status | |
226 | | | | |
227 +------v----------v-----+-------------------+ | |
228 | Calendar and Scheduling System | | Directory |
229 | +---------+ +---------+ | | Service |
230 | | | | Task | <----> |
231 | |Schedule | | Lists | | | |
232 | | | | | | | |
233 | +---------+ +---------+ Server | | |
234 +-------------------------------------------+ | |
235 | Client | | |
236 | +----------------------+ +-----------+ | | |
237 | | Calendar | | Task | | | |
238 | | User Agent +----> Specific | <----> |
239 | | | |Application| | | |
240 | +----------------------+ +-----------+ | | |
241 | | | |
242 +-----^---------^--------+---------+--------+ | |
243 | | | | | |
244 +-----V---------V--------V---------V--------+ | |
245 | Task Actors | | |
246 | O O O O | | |
247 | /|\ /|\ /|\ /|\ +----> |
248 | / \ / \ / \ / \ | | |
249 | Candidate(s) Observer(s) | | |
250 | Assignee(s) Resource(s) | | |
251 +-------------------------------------------+ +-----------+
253 4. Task Architecture Elements
255 The following logical elements form the task architecture that this
256 specification is based on:
258 Task Actors Various calendar users that may be involved in the
259 monitoring or performing of a task. The set of actors includes:
260 Organizers, Observers, Resources, Assignees, and Candidates.
262 Task Organizer The Organizer of a task.
264 Task Domain Data This is any domain specific data that may be acted
265 on or provides context to it in performing a task.
267 Task Specific Application A task specific application renders the
268 data concerning the task (including task domain data) for
269 presentation and manipulation by a task actor.
271 Process Logic Determines under what conditions a task (or tasks) is
272 generated and the actions to take on completion, or some other
273 status event occurring (or not) on the task.
275 Task Trigger This is some event that gives rise to the generation of
276 a task according to Process Logic. Task triggers can come from
277 many different sources including, for example; a task being
278 requested through the calendaring system, a status change in the
279 progression of a business process being managed by a business
280 process management or ERP system.
282 Task Assignment Rules Govern how actors are assigned to a task. A
283 range of different assignment patterns [WfRP] may be considered,
284 including the two general cases:
286 1. Delegation to a named actor or group of actors
288 2. Advertising to a pool of actors for self-selection
290 In either case the assignment may be made based on a variety of
291 criteria including, name, availability, skills, capacity, etc.
293 Task Generating System A system that creates and assigns tasks in
294 response to some initiating event (task trigger). Task creation
295 is according to Process Logic with task assignment determined by
296 Task Assignment Rules. This system also tracks the status of
297 tasks and will initiate further actions based upon the status. A
298 task generating system can take many forms, for example; Business
299 Process Management System, Project Management System, Bug Tracking
300 System, Building Control System. A Task Generating System may
301 also be a human. In iCalendar terms the Task Generating System is
302 the organizer.
304 Human Task Generation Task creation, assignment and tracking
305 coordinated by a human organizer is a special case of a task
306 generating system. In this case Task Assignment Rules and Process
307 Logic may be either explicit or tacit.
309 Directory Service A software system that stores and provides access
310 to information providing details of task actors that may
311 participate or be interested in a task.
313 Calendar and Scheduling System A software system that stores,
314 publishes and synchronizes calendar data such as events, tasks and
315 journal entries for actors. In the context of tasks this includes
316 schedules (i.e. allocated time and availability to perform tasks)
317 and task lists. A calendar and scheduling system typically
318 consists of server and client software components.
320 It is not within the scope of this document to specify how Process
321 Logic or Task Assignment Rules are codified. Such logic and rules
322 may be codified in a variety of ways, including traditional
323 programming languages (e.g. C++, Java) or process modelling
324 languages (e.g. BPMN [BPMN]).
326 5. Architecture Foundations
328 The key standards that enable interoperability between the logical
329 elements of the architecture are the Internet Calendaring and
330 Scheduling Core Object Specification (iCalendar) [RFC5545] and
331 associated protocols. Task and task status are represented by the
332 iCalendar "VTODO" component. Protocols include, in particular, the
333 iCalendar Transport-Independent Interoperability Protocol (iTIP)
334 [RFC5546] for task assignment and scheduling, and Calendaring
335 Extensions to WebDAV (CalDAV) [RFC4791] for client server
336 communication.
338 Additionally, this specification uses definitions from Support for
339 iCalendar Relationships [I-D.ietf-calext-ical-relations]. The LINK,
340 REFID, RELATED-TO and CONCEPT properties enable context and a rich
341 set of relationships between tasks and other iCalendar components to
342 be specified.
344 6. Task Extensions
346 In order to support the task architecture described in Section 3,
347 this document defines a number of extensions to the current iCalendar
348 standards in the areas of:
350 Task Specification improved ability to specify domain specific tasks
352 Task Deadlines, Milestones and Time Planning clarification of
353 deadlines and extension for task duration to support task time
354 planning
356 Task Scheduling and Assignment ensure support for common pattens of
357 scheduling and assigning tasks
359 Task Status Tracking improved granularity in status tracking
360 information and alerting task actors to pending or actual task
361 status changes
363 These extensions are supported mainly by additions to the properties
364 and parameters used within the "VTODO" component.
366 7. Task Specification
368 The specification of tasks must be semantically explicit in order for
369 them to be managed within the context of a business process or
370 project, and be understood by both humans and IT systems. The
371 current VTODO component only provides for simple ad-hoc tasks or 'to
372 do' lists, and is therefore extended by this specification as
373 follows:
375 Task type explicitly what type of task is to be performed is
376 identified.
378 Task context and relationships how a specific task relates to other
379 tasks and other objects that need to be understood for the
380 effective execution of a task.
382 Task specific data the form and content of domain data provided as
383 input to a task and/or that may be output from a task.
385 Organizer and attendee recognizes that a task organizer or attendee
386 can be an automated system.
388 7.1. CONCEPT for task type identification
390 The CONCEPT property is used to identify the type of task, for
391 example;
393 CONCEPT:http://example.com/task/delivery
395 7.2. Task Context and Relationships
397 The LINK property specifies a link to external information, which may
398 be context to the task. For example:
400 LINK;REL=SOURCE:http://example.com/package/1234567890
402 LINK;REL=describedby:mid:752142.1414823874.307E5@mx123.example.com
404 The external information may be data to be manipulated in performing
405 the task. See section 3.1.3 Task Domain Data Handling.
407 REFID is used to identify a key allowing the association of tasks
408 that are related to the same object and retrieval of a task based on
409 this key. This may be, for example, to identify the tasks associated
410 with a given project without having to communicate the task structure
411 of the project, or all tasks associated to a specific package.
413 REFID:Manhattan
415 REFID:1234567890
417 Extensions [Doug114] to the RELATED-TO property allow temporal
418 relationships between tasks as found in project management to be
419 specified as well as parent/child relationships and dependencies
420 (DEPENDS-ON). Tasks (VTODOs) may also be related to other calendar
421 components; for example to a VEVENT to block time to perform a task.
423 7.3. Task Domain Data Handling
425 Provide support for task specific input and output data (including
426 updates) beyond the standard iCalendar properties. It is envisaged
427 that standard calendar user agents will be able to launch task
428 specific applications by passing task specific data.
430 The LINK property can be used to 'attach' the domain specific data to
431 the task. For example, it might be a URI pointing to a web page
432 where the status of the task can be directly manipulated.
434 LINK;REL="vacation-system";VALUE=URI:http://example.com/
435 vacation-approval?id=1234
437 Or it might be used for attachments specific to the task, for example
438 an electronic copy of a signature taken to confirm delivery of a
439 package.
441 LINK;REL="electronic-signature";VALUE=URI:http://example.com/
442 delivery/sig1234.jpg
444 8. Task Deadlines, Milestones and Time Planning
446 Deadlines for starting and finishing a task are defined by the
447 DTSTART, DUE and DURATION properties. DTSTART represents the
448 earliest start time for beginning work on a task. DUE, or DTSTART +
449 DURATION represent the latest finish time for a task. Thus these
450 properties define a "window" within which a task has to be performed.
451 However, there is currently no way to indicate how long the task is
452 expected to take. This document defines a new property, ESTIMATED-
453 DURATION, to allow the estimated time that a task should take to be
454 specified separately from the deadlines for starting and finishing a
455 task. This supports time planning by enabling calendar user agents
456 to display when tasks should occur and therefore allow calendar users
457 to visualize when tasks should be performed and allocate time to
458 them.
460 A task that has intermediary deadlines (i.e., milestones) SHOULD be
461 expressed by child VTODO components (i.e., sub-tasks associated with
462 each of the milestones) in conjunction with the RELATED-TO property
463 to relate the parent and child tasks.
465 9. Task Scheduling and Assignment
467 This specification supports the two distinct models of assigning
468 actors to tasks, i.e., 1) strictly one assignee per task or 2) task
469 assignment to multiple assignees. In this regard one or many
470 ATTENDEES may be specified against a task depending upon the model
471 applied by the task organizer.
473 In addition a number of different patterns of resource or assignee
474 identification are anticipated. The specific Task Assignment Rules
475 are the responsibility of the Task Organizer.
477 Communication of task assignment or delegation to one or more actors
478 who are allocated to a task by the organizer is directly supported by
479 iTIP, i.e., all included ATTENDEES in an iTIP REQUEST are expected to
480 perform the task.
482 The offering or advertising of a task to one or more (potential)
483 actors where only one or a subset of the candidates may accept the
484 task will be addressed by a new VPOLL mode (See Appendix B) [VPOLL].
486 10. Status Reporting
488 10.1. Improved granularity in status reporting information
490 This document defines a new status component that can be used to
491 group related information about the status. This might include
492 information on why (REASON) and when (DTSTAMP) a status has changed.
493 In addition new status values are specified to provide for task
494 suspension, failure and preparation.
496 10.2. Relating reason and comments to ATTENDEE status changes.
498 The [RFC9073] PARTICIPANT component can be used to provide additional
499 information about why an ATTENDEE participation status has changed.
500 The COMMENT property can also be used to include additional human
501 readable information about why the associated STATUS or ATTENDEE
502 property changed.
504 BEGIN:VSTATUS
505 STATUS:FAILED
506 REASON:http://example.com/reason/delivery-failed
507 SUBSTATE:ERROR
508 DTSTAMP:20130212T120000Z
509 COMMENT:Breakdown
510 END:VSTATUS
512 ATTENDEE;PARTSTAT=FAILED:mailto:xxx@example.com
513 ...
514 BEGIN:PARTICIPANT
515 CALENDAR-ADDRESS:mailto:xxx@example.com
516 DTSTAMP:20130226T1104510Z
517 REASON:http://example.com/reason/van-break-down
518 COMMENT:Puncture
519 END:PARTICIPANT
521 10.3. Comments associated to reasons and status changes
523 Multiple comments and reasons may have the same status. As
524 situations chnage further VSTATUS components can be added to provide
525 additional information..
527 CONCEPT:http://example.com/task/delivery
528 BEGIN:VSTATUS
529 STATUS:FAILED
530 SUBSTATE:ERROR
531 DTSTAMP:20220212T104900Z
532 COMMENT:Out of time
533 END:VSTATUS
534 BEGIN:VSTATUS
535 STATUS:FAILED
536 COMMENT:Traffic Accident on E44
537 REASON:http://example.com/reason/traffic
538 DTSTAMP:20220212T110451Z
539 END:VSTATUS
540 BEGIN:VSTATUS
541 STATUS:FAILED
542 COMMENT:Arrived after office hours
543 REASON:http://example.com/reason/closed
544 DTSTAMP:20220212T180451Z
545 END:VSTATUS
547 10.4. Task Alerts and Notifications
549 Different needs to alert or notify task actors of pending or actual
550 task status changes are recognized:
552 Alarms Alarms (VLARM components) operate in the calendar user agent
553 space to notify the task actor of a pending task state for a task
554 they are assigned to or are interested in. Note: there is no
555 constraint in the current standards on the propagation of alarms
556 specified on calendar objects by organizers to individual
557 attendees.
559 Escalations An escalation or notification to the ATTENDEE,
560 ORGANIZER, or other task actor may be required if a deadline
561 associated with a task is exceeded or for some other reason.
562 Process Logic identifying when and who to propagate escalations to
563 is the responsibility of the Task Generating System, e.g., a BPMS.
565 Notifications Task actors (observers) not directly involved in
566 performing a task but with a known interest in a given task's
567 status can be identified by the ASSOCIATE property [Doug214]
568 against certain components e.g. ALARM, to identify which task
569 events the stakeholder/party is interested in. Notifications on
570 shared calendars will allow task actors to register an interest in
571 changes to tasks within a calendar (see Appendix A).
573 10.5. Automated Status Changes
575 A new property, TASK-MODE, is introduced to instruct servers to apply
576 automated operations for changing the status of a task.
578 11. New Parameter Values
580 11.1. Redefined VTODO Participant Status
582 Participant status parameter type values are defined in
583 Section 3.2.12 of [RFC5545]. This specification redefines that type
584 to include the new value FAILED for VTODO iCalendar components.
586 Format Definition This property parameter is extended by the
587 following notation:
589 partstat-todo /= *("FAILED") ; To-do cannot be completed
591 Example
593 ATTENDEE;REASON="http://example.com/reason/not-enough-time";
594 PARTSTAT=FAILED:mailto:jsmith@example.com
596 12. New Properties
598 12.1. Estimated Duration
600 Property Name ESTIMATED-DURATION
602 Purpose This property specifies the estimated positive duration of
603 time the corresponding task will take to complete.
605 Value Type DURATION
607 Property Parameters IANA and non-standard property parameters can be
608 specified on this property.
610 Conformance This property can be specified in "VTODO" calendar
611 components.
613 Format Definition This property is defined by the following
614 notation:
616 est-duration = "ESTIMATED-DURATION" durparam ":" dur-value CRLF
617 ;consisting of a positive duration of time.
619 durparam = *(";" other-param)
620 Description In a "VTODO" calendar component the property MAY be used
621 to specify the estimated duration for the to-do, with or without
622 an explicit time window in which the event should be started and
623 completed. When present, DTSTART and DUE/DURATION represent the
624 window in which the task can be performed. ESTIMATED-DURATION
625 SHOULD be passed from ORGANIZER to ATTENDEE in iTIP [RFC5546]
626 messages.
628 Example The following is an example of this property that specifies
629 an interval of time of exactly one hour:
631 ESTIMATED-DURATION:PT1H
633 12.2. Reason
635 Property name REASON
637 Purpose To indicate the reason for a change in status of a task or
638 attendee participation status.
640 Value Type URI
642 Property Parameters IANA and non-standard property parameters can be
643 specified on this property.
645 Conformance This property can be specified in "VSTATUS" and
646 PARTICIPANT calendar components.
648 Format Definition This property is defined by the following
649 notation:
651 reason = "REASON" reasonparam ":" uri CRLF
653 reasonparam = *(";" other-param)
655 Description This property allows the change in status of a task or
656 participant status to be qualified by the reason for the change
657 with a codified reason. Typically reasons are defined within the
658 context of the task type and therefore SHOULD include the name-
659 space of the authority defining the task. Common reason codes are
660 IANA registered and do not have a name-space prefix.
662 Example
664 REASON:http://example.com/reason/delivered-on-time
666 REASON:out-of-office
668 12.3. Sub-State
670 Property name SUBSTATE
672 Purpose To provide additional granularity of task status for e.g.
673 IN-PROCESS.
675 Value Type TEXT
677 Property Parameters IANA and non-standard property parameters can be
678 specified on this property.
680 Conformance This property can be specified in a "VSTATUS" calendar
681 component.
683 Format Definition This property is defined by the following
684 notation:
686 substate = "SUBSTATE" substateparam ":" substatevalue CRLF
688 substateparam = *(";" other-param)
690 substatevalue = ("OK" ; everything is fine(the default)
691 / "ERROR" ; something is wrong (the REASON
692 ; code explains why)
693 / "SUSPENDED" ; waiting on some other task to
694 ; complete or availability of a
695 ; resource (REASON code explains
696 ; why)
697 / iana-token) ; Other IANA-registered type
699 Description The sub-state property allows additional qualification
700 and granularity of states to be recorded, in particular for the
701 IN-PROCESS state. It allows individual sub-states to be recorded
702 without the need to define and publish a sub-task associated with
703 a parent task purely to track that a particular state has been
704 reached. This property also allows parallel states to be
705 expressed e.g. that a task has been suspended at whatever state it
706 has reached.
708 Example
709 BEGIN:VSTATUS
710 STATUS:FAILED
711 REASON:http://example.com/reason/no-one-home
712 SUBSTATE:ERROR
713 END:VSTATUS
715 BEGIN:VSTATUS
716 STATUS:IN-PROCESS
717 REASON:http://example.com/reason/paint-drying
718 SUBSTATE:SUSPENDED
719 END:VSTATUS
721 12.4. Task Mode
723 Property Name TASK-MODE
725 Purpose This property specifies automatic operations that servers
726 apply to tasks based on changes in attendee status (PARTSTAT).
728 Value Type TEXT
730 Property Parameters IANA and non-standard property parameters can be
731 specified on this property.
733 Conformance This property can be specified zero or more times in a
734 "VTODO" calendar component.
736 Format Definition This property is defined by the following
737 notation:
739 task-mode = "TASK-MODE taskmodeparam ":" taskvalue
740 *("," taskvalue) CRLF
742 taskvalue = "AUTOMATIC-COMPLETION" ; set STATUS completed
743 ;if all attendees have completed
744 / "AUTOMATIC-FAILURE"
745 / "SERVER"
746 / "CLIENT"
747 / iana-token
748 / x-name
750 taskmodeparam = *(";" other-param)
752 Description In a "VTODO" calendar component this property MAY be
753 used to indicate to servers how they can automatically change the
754 state of the task based on iTIP replies from Attendees. For
755 example, the server can automatically set the overall task status
756 (STATUS) to COMPLETED when every attendee has marked their own
757 status (PARTSTAT) as COMPLETED, or the server could mark the task
758 as FAILED if its DUE date passes without it being completed.
759 TASK-MODE processing is performed on the organizer's copy of the
760 task.
762 The property value is a list of one or more IANA registered tokens
763 that defines modes to be used for the task. This specification
764 defines three modes which are described in the following sub-
765 sections.
767 Examples
769 TASK-MODE:AUTOMATIC-COMPLETION,AUTOMATIC-FAILURE
770 TASK-MODE:SERVER
771 TASK-MODE:AUTOMATIC-FAILURE
773 AUTOMATIC-COMPLETION Task Mode The task mode value "AUTOMATIC-
774 COMPLETION" indicates to the server that it can change the "VTODO"
775 component's STATUS property value to "COMPLETED" as soon as all
776 ATTENDEEs in the task have replied with a "PARTSTAT" parameter set
777 to "COMPLETED".
779 AUTOMATIC-FAILURE Task Mode The task mode value "AUTOMATIC-FAILURE"
780 indicates to the server that it SHOULD change the "VTODO"
781 component's STATUS property value to "FAILED" if either:
783 * the PARTSTAT of one ATTENDEE is set to FAILED; or
785 * the current time is past the effective due date of the
786 component and the task has not yet been completed.
788 Note: The effective due date is either the "DUE" property value or
789 the combination of the "DTSTART" and "DURATION" property values.
791 CLIENT Task Mode The task mode value "CLIENT" is an instruction to
792 the server to honour the status set by the client.
794 SERVER Task Mode The task mode value "SERVER" indicates to the
795 server that it can change the "VTODO" component's STATUS property
796 value to an appropriate value, based on implementation defined
797 "business rules", as ATTENDEE responses are processed or as
798 deadlines related to the task pass.
800 The server can add this property to a "VTODO" component to
801 indicate to the client that it will be managing the status.
803 13. Property Extensions and Clarifications
804 13.1. Redefined STATUS Property
806 The Status property is defined in Section 3.8.1.11 of [RFC5545].
807 This specification extends that property to include new values
808 associated with VTODO iCalendar components (See Appendix A for
809 examples of the task state lifecycle).
811 Format Definition The "STATUS" property parameter list is augmented
812 as follows:
814 statvalue-todo = / "PENDING" ;Indicates a to-do has been
815 ;created and accepted, but has not
816 ;yet started.
817 / "FAILED" ;Indicates to-do has failed.
818 ;Extended status values for
819 ;"VTODO".
821 Description:
823 PENDING - A task has been created but has not yet started and is
824 ready to start subject to other dependencies (e.g. preceding task or
825 DTSTART). This is the default state.
827 FAILED - task has failed and may need some follow-up from the
828 organizer to re-schedule or cancel
830 Example: The following is an example of this property for a "VTODO"
831 calendar component:
833 STATUS:FAILED
835 14. New Components
837 14.1. Status Component
839 Component Name VSTATUS
841 Purpose This component allows information to be associated with a
842 status, for example comments and date stamps.
844 Conformance This component can be specified multiple times in any
845 appropriate calendar component.
847 Description This component provides a way for multiple date-stamped
848 statuses to be associated with a component such as a task or an
849 event.
851 This compoment may also be added to the [RFC9073] PARTICIPANT
852 component to allow participants in a task to specify their own
853 status.
855 Format Definition This component is defined by the following
856 notation:
858 statusc = "BEGIN" ":" "VSTATUS" CRLF
859 statusprop
860 "END" ":" "VSTATUS" CRLF
862 statusprop = *(
863 ;
864 ; The following is REQUIRED,
865 ; but MUST NOT occur more than once.
866 ;
867 status /
868 ;
869 ; The following are OPTIONAL,
870 ; but MUST NOT occur more than once.
871 ;
872 description / dtstamp / reason / substate / summary
873 ;
874 ; The following are OPTIONAL,
875 ; and MAY occur more than once.
876 ;
877 comment / styleddescription / iana-prop
878 ;
879 )
881 Examples
883 BEGIN:VSTATUS
884 STATUS:COMPLETED
885 REASON: http://example.com/reason/delivered-on-time
886 DTSTAMP:20220212T120000Z
887 END:VSTATUS
889 15. CalDAV Support for Task Mode
891 The CalDAV [RFC4791] calendar access protocol allows clients and
892 servers to exchange iCalendar data. With the introduction of the
893 "TASK-MODE" property in this specification, different automated task
894 management behaviours may be delegated to the server by the Task
895 Organizer depending upon the value of "TASK-MODE".
897 In order for a CalDAV client to know what task modes are available, a
898 CalDAV server advertises a CALDAV:supported-task-mode-set WebDAV
899 property on calendar home or calendar collections if it supports the
900 use of the "TASK-MODE" property as described in this specification.
901 The server can advertise a specific set of supported task modes by
902 including one or more CALDAV:supported-task-mode XML elements within
903 the CALDAV:supported-task-mode-set XML element. If no
904 CALDAV:supported-task-mode XML elements are included in the WebDAV
905 property, then clients can try any task mode, but need to be prepared
906 for a failure when attempting to store the calendar data.
908 Clients MUST NOT attempt to store iCalendar data containing "TASK-
909 MODE" elements if the CALDAV:supported-task-mode-set WebDAV property
910 is not advertised by the server.
912 The server SHOULD return an HTTP 403 response with a DAV:error
913 element containing a CALDAV:supported-task-mode XML element, if a
914 client attempts to store iCalendar data with an "TASK-MODE" element
915 value not supported by the server.
917 It is possible for a "TASK-MODE" value to be present in calendar data
918 on the server being accessed by a client that does not support the
919 "TASK-MODE" property. It is expected that existing clients, unaware
920 of "TASK-MODE", will fail gracefully by ignoring the calendar
921 property.
923 15.1. CALDAV:supported-task-mode-set Property
925 Name supported-task-mode-set
927 Namespace urn:ietf:params:xml:ns:caldav
929 Purpose Enumerates the set of supported iCalendar "TASK-MODE"
930 element values supported by the server.
932 Protected This property MUST be protected and SHOULD NOT be returned
933 by a PROPFIND allprop request (as defined in Section 14.2 of
934 [RFC4918]).
936 Description See above.
938 Definition
940
941
942
944 Example
946
947 AUTOMATIC-COMPLETION
948 AUTOMATIC-FAILURE
949 SERVER
950 CLIENT
951
953 16. Security Considerations
955 This specification introduces no new security considerations beyond
956 those identified in [RFC5545].
958 17. IANA Considerations
960 17.1. Initialization of the Status registry
962 This specification updates [RFC5545] by adding a Status value
963 registry to the iCalendar Elements registry and initializing it as
964 per [RFC5545].
966 +==============+=========+===============================+
967 | Name | Status | Reference |
968 +==============+=========+===============================+
969 | CANCELLED | Current | Section 3.8.1.11 of [RFC5545] |
970 +--------------+---------+-------------------------------+
971 | COMPLETED | Current | Section 3.8.1.11 of [RFC5545] |
972 +--------------+---------+-------------------------------+
973 | CONFIRMED | Current | Section 3.8.1.11 of [RFC5545] |
974 +--------------+---------+-------------------------------+
975 | DRAFT | Current | Section 3.8.1.11 of [RFC5545] |
976 +--------------+---------+-------------------------------+
977 | FINAL | Current | Section 3.8.1.11 of [RFC5545] |
978 +--------------+---------+-------------------------------+
979 | IN-PROCESS | Current | Section 3.8.1.11 of [RFC5545] |
980 +--------------+---------+-------------------------------+
981 | NEEDS-ACTION | Current | Section 3.8.1.11 of [RFC5545] |
982 +--------------+---------+-------------------------------+
983 | TENTATIVE | Current | Section 3.8.1.11 of [RFC5545] |
984 +--------------+---------+-------------------------------+
986 Table 1: Initial Status Value Registry
988 17.2. Update of the Status registry
990 This specification further updates the Status registry with
991 additional values defined in this document.
993 +=========+=========+=========================+
994 | Value | Status | Reference |
995 +=========+=========+=========================+
996 | PENDING | Current | This Spec, Section 13.1 |
997 +---------+---------+-------------------------+
998 | FAILED | Current | This Spec, Section 13.1 |
999 +---------+---------+-------------------------+
1001 Table 2: Updated Status Value Registry
1003 17.3. Sub-State value registry
1005 The following table has been used to initialize the Sub-State
1006 registry.
1008 +===========+=========+=========================+
1009 | Substate | Status | Reference |
1010 +===========+=========+=========================+
1011 | OK | Current | This Spec, Section 12.3 |
1012 +-----------+---------+-------------------------+
1013 | ERROR | Current | This Spec, Section 12.3 |
1014 +-----------+---------+-------------------------+
1015 | SUSPENDED | Current | This Spec, Section 12.3 |
1016 +-----------+---------+-------------------------+
1018 Table 3: Sub-State registry
1020 17.4. Task Mode value registry
1022 The following table has been used to initialize the Task Mode
1023 registry.
1025 +======================+=========+=========================+
1026 | Task Mode | Status | Reference |
1027 +======================+=========+=========================+
1028 | AUTOMATIC-COMPLETION | Current | This Spec, Section 12.4 |
1029 +----------------------+---------+-------------------------+
1030 | AUTOMATIC-FAILURE | Current | This Spec, Section 12.4 |
1031 +----------------------+---------+-------------------------+
1032 | CLIENT | Current | This Spec, Section 12.4 |
1033 +----------------------+---------+-------------------------+
1034 | SERVER | Current | This Spec, Section 12.4 |
1035 +----------------------+---------+-------------------------+
1037 Table 4: Task Mode Value Registry
1039 17.5. Participation Statuses registry
1041 The following table has been used to update the Participation
1042 Statuses registry.
1044 +========+=========+=========================+
1045 | Value | Status | Reference |
1046 +========+=========+=========================+
1047 | FAILED | Current | This Spec, Section 11.1 |
1048 +--------+---------+-------------------------+
1050 Table 5: Participation Statuses Registry
1052 17.6. Properties registry
1054 The following table has been used to update the Properties registry.
1056 +====================+=========+=========================+
1057 | Property | Status | Reference |
1058 +====================+=========+=========================+
1059 | ESTIMATED_DURATION | Current | This Spec, Section 12.1 |
1060 +--------------------+---------+-------------------------+
1061 | REASON | Current | This Spec, Section 12.2 |
1062 +--------------------+---------+-------------------------+
1063 | SUBSTATE | Current | This Spec, Section 12.3 |
1064 +--------------------+---------+-------------------------+
1065 | STATUS | Current | This Spec, Section 13.1 |
1066 +--------------------+---------+-------------------------+
1067 | TASK-MODE | Current | This Spec, Section 12.4 |
1068 +--------------------+---------+-------------------------+
1070 Table 6: Updated Properties Registry
1072 18. Normative References
1074 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
1075 Requirement Levels", RFC 2119, RFC 2119,
1076 DOI 10.17487/RFC2119, March 1997,
1077 .
1079 [RFC4791] Daboo, C., Desruisseaux, B., and L. Dusseault,
1080 "Calendaring Extensions to WebDAV (CalDAV)", RFC 4791,
1081 RFC 4791, DOI 10.17487/RFC4791, March 2007,
1082 .
1084 [RFC4918] Dusseault, L., Ed., "HTTP Extensions for Web Distributed
1085 Authoring and Versioning (WebDAV)", RFC 4918, RFC 4918,
1086 DOI 10.17487/RFC4918, June 2007,
1087 .
1089 [RFC5545] Desruisseaux, B., Ed., "Internet Calendaring and
1090 Scheduling Core Object Specification (iCalendar)", RFC
1091 5545, RFC 5545, DOI 10.17487/RFC5545, September 2009,
1092 .
1094 [RFC5546] Daboo, C., Ed., "iCalendar Transport-Independent
1095 Interoperability Protocol (iTIP)", RFC 5546, RFC 5546,
1096 DOI 10.17487/RFC5546, December 2009,
1097 .
1099 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
1100 2119 Key Words", RFC 8174, RFC 8174, DOI 10.17487/RFC8174,
1101 May 2017, .
1103 [RFC9073] Douglass, M., "Event Publishing Extensions to iCalendar",
1104 RFC 9073, RFC 9073, DOI 10.17487/RFC9073, August 2021,
1105 .
1107 [I-D.ietf-calext-ical-relations]
1108 Douglass, M., "Support for iCalendar Relationships", I-
1109 D.ietf-calext-ical-relations, Work in Progress, Internet-
1110 Draft, ietf-calext-ical-relations, December 2020,
1111 .
1114 19. Informative References
1116 [BPMN] "Business Process Model and Notation", OMG BPMN 2.0.2,
1117 January 2014,
1118 .
1120 [TARCH] "Apthorp, A., Daboo, C., Douglass, M., CalConnect, Task
1121 Architecture V1.0,", CalConnect Task Architecture V1.0.
1123 [EDISTS] "UN Economic Commission for Europe, UN/EDIFACT, D14.A, STS
1124 STATUS, April 30,
1125 2014,http://www.unece.org/fileadmin/DAM/trade/untdid/d14a/
1126 trsd/trsdsts.htm", UN/EDIFACT, D14.A.
1128 [WfRP] "Russell, N., ter Hofstede, A.H.M., Edmond, T., van der
1129 Aalst,W.M.P., Workflow Resource Patterns, Eindhoven
1130 University of Technology, 2004,", WfRP.
1132 [WSCal] "Considine, T., Douglass, M., WS-Calendar Version 1.0,
1133 OASIS, 30 July 2011,", OASIS WS-Calendar V1.0.
1135 [WSHT] "Ings, D., Clement, L., Koenig, D., Mehta, V., Mueller,
1136 R., Rangaswamy, R., Rowley, M., Trickovic, I., Web
1137 Services - Human Task Version 1.1 (WS-HumanTask), OASIS,
1138 17 August 2010,", OASIS WS-HT V1.1.
1140 Appendix A. Examples of Task State Lifecycle
1142 A.1. Simple Case Status Change
1144 +===+==============+==============+===========================+
1145 | | STATUS | PARTSTAT | Action |
1146 +===+==============+==============+===========================+
1147 | 1 | - | - | Organizer draft |
1148 +---+--------------+--------------+---------------------------+
1149 | 2 | NEEDS-ACTION | NEEDS-ACTION | Organizer sends iTIP |
1150 | | | | request |
1151 +---+--------------+--------------+---------------------------+
1152 | 3 | NEEDS-ACTION | ACCEPTED | Attendee reply |
1153 +---+--------------+--------------+---------------------------+
1154 | 4 | PENDING | ACCEPTED | Task accepted but waiting |
1155 | | | | on some "trigger" to |
1156 | | | | start (e.g. another task |
1157 | | | | has to finish first) |
1158 +---+--------------+--------------+---------------------------+
1159 | 5 | IN-PROCESS | IN-PROCESS | Attendee reply now |
1160 | | | | working on the task |
1161 +---+--------------+--------------+---------------------------+
1162 | 6 | IN-PROCESS | COMPLETED | Attendee reply completed |
1163 +---+--------------+--------------+---------------------------+
1164 | 7 | COMPLETED | COMPLETED | Organizer changes overall |
1165 | | | | state |
1166 +---+--------------+--------------+---------------------------+
1168 Table 7: Example of status changes in assigning and
1169 performing a task with one attendee.
1171 A.2. Example for multiple Attendees
1173 Example of status changes in assigning and performing a task with two
1174 attendees (A1 and A2).
1176 +====+==============+==============+==============+================+
1177 | | STATUS | PARTSTAT | PARTSTAT | Action |
1178 | | | (A1) | (A2) | |
1179 +====+==============+==============+==============+================+
1180 | 1 | - | - | - | Organizer |
1181 | | | | | draft. |
1182 +----+--------------+--------------+--------------+----------------+
1183 | 2 | NEEDS-ACTION | NEEDS-ACTION | NEEDS-ACTION | Organizer |
1184 | | | | | sends iTIP |
1185 | | | | | request. |
1186 +----+--------------+--------------+--------------+----------------+
1187 | 4 | NEEDS-ACTION | ACCEPTED | NEEDS-ACTION | Attendee 1 |
1188 | | | | | reply. |
1189 +----+--------------+--------------+--------------+----------------+
1190 | 5 | NEEDS-ACTION | ACCEPTED | ACCEPTED | Attendee 2 |
1191 | | | | | reply. |
1192 +----+--------------+--------------+--------------+----------------+
1193 | 6 | PENDING | ACCEPTED | ACCEPTED | Task accepted |
1194 | | | | | but waiting on |
1195 | | | | | some"trigger" |
1196 | | | | | to start (e.g. |
1197 | | | | | another task |
1198 | | | | | has to finish |
1199 | | | | | first) |
1200 +----+--------------+--------------+--------------+----------------+
1201 | 7 | IN-PROCESS | ACCEPTED | IN-PROCESS | Attendee 2 |
1202 | | | | | reply now |
1203 | | | | | working on the |
1204 | | | | | task. |
1205 +----+--------------+--------------+--------------+----------------+
1206 | 8 | IN-PROCESS | IN-PROCESS | IN-PROCESS | Attendee 1 |
1207 | | | | | reply now |
1208 | | | | | working on the |
1209 | | | | | task. |
1210 +----+--------------+--------------+--------------+----------------+
1211 | 9 | IN-PROCESS | COMPLETED | IN-PROCESS | Attendee 1 |
1212 | | | | | reply |
1213 | | | | | Completed |
1214 | | | | | (overall |
1215 | | | | | status still |
1216 | | | | | IN-PROCESS). |
1217 +----+--------------+--------------+--------------+----------------+
1218 | 10 | IN-PROCESS | COMPLETED | COMPLETED | Attendee 2 |
1219 | | | | | reply |
1220 | | | | | Completed |
1221 +----+--------------+--------------+--------------+----------------+
1222 | 11 | COMPLETED | COMPLETED | COMPLETED | Organizer |
1223 | | | | | changes |
1224 | | | | | overall state |
1225 | | | | | once both |
1226 | | | | | attendees are |
1227 | | | | | finished. |
1228 +----+--------------+--------------+--------------+----------------+
1230 Table 8: Example for multiple Attendees
1232 Note: The logic for determining the status change to the VTODO is
1233 determined by the task organizer based on the ATTENDEE status and
1234 other business logic.
1236 A.3. Example of Failure
1238 Example of status changes for a task that fails.
1240 +===+==============+==============+==============================+
1241 | | STATUS | PARTSTAT | Action |
1242 +===+==============+==============+==============================+
1243 | 1 | - | - | Organizer draft |
1244 +---+--------------+--------------+------------------------------+
1245 | 2 | NEEDS-ACTION | NEEDS-ACTION | Organizer sends iTIP request |
1246 +---+--------------+--------------+------------------------------+
1247 | 3 | NEEDS-ACTION | ACCEPTED | Attendee reply |
1248 +---+--------------+--------------+------------------------------+
1249 | 4 | IN-PROCESS | IN-PROCESS | Attendee reply now working |
1250 | | | | on the task |
1251 +---+--------------+--------------+------------------------------+
1252 | 5 | IN-PROCESS | FAILED | Attendee reply task failed |
1253 +---+--------------+--------------+------------------------------+
1254 | 6 | FAILED | FAILED | Organizer changes overall |
1255 | | | | state |
1256 +---+--------------+--------------+------------------------------+
1258 Table 9: Example of Failure
1260 Appendix B. Change log
1262 V02. 2021-05-05 MD
1264 * Redo in asciidoc
1266 * Change STRUCTURED-CATEGORY to CONCEPT
1268 * Add GROUP parameter definition
1270 V01. 2015-08-23 AA
1271 * Highlighted use of ESTIMATED-DURATION for time planning.
1273 * Corrected PARTSTAT example section 5.1. Changed DECLINED to
1274 FAILED.
1276 * Replaced Task Mode AUTOMATIC-STATUS with CLIENT and SERVER modes.
1277 Also, clarified that task mode processing is only done on the
1278 organizer's copy.
1280 * Clarified responsibility for setting MODIFIED.
1282 * CalDAV support added.
1284 * Updated normative references.
1286 Appendix C. Working Notes
1288 C.1. Advertising tasks
1290 Use VPOLL for advertising a task to a pool of possible ATTENDEEs and
1291 then select the respondent to assign one or more assignees.
1293 Introduce POLL-MODE:ASSIGNMENT
1295 Need to indicate number of assignees required.
1297 Potentially different types of response e.g. ACCEPT or DECLINE, or a
1298 weighting e.g. 0 - 100
1300 Take into FREEBUSY discussion.
1302 C.2. Subscribing to task updates
1304 Stakeholders should have the ability to subscribe to categories /
1305 types of tasks on an ongoing basis. Reference calendarserver.org
1306 notifications draft
1308 Authors' Addresses
1310 Adrian Apthorp
1311 DHL Express
1312 Fritz-Erler-Str. 5
1313 Bonn
1314 Germany
1315 Email: adrian.apthorp@dhl.com
1316 Michael Douglass
1317 Bedework Commercial Services
1318 226 3rd Street
1319 Troy, NY
1320 United States of America
1321 Email: mdouglass@bedework.com