idnits 2.17.1
draft-ietf-calext-ical-tasks-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 :
----------------------------------------------------------------------------
-- 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:
----------------------------------------------------------------------------
== The copyright year in the IETF Trust and authors Copyright Line does not
match the current year
== Line 353 has weird spacing: '...ication impro...'
== Line 355 has weird spacing: '...lanning clari...'
== Line 359 has weird spacing: '...ignment ensur...'
== Line 362 has weird spacing: '...racking impro...'
== Line 378 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 (22 August 2021) is 971 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 420, but not defined
== Missing Reference: 'VPOLL' is mentioned on line 487, but not defined
== Missing Reference: 'Doug214' is mentioned on line 549, but not defined
== Unused Reference: 'I-D.ietf-calext-eventpub-extensions' is defined on
line 1136, but no explicit reference was found in the text
== Unused Reference: 'I-D.york-vpoll' is defined on line 1152, but no
explicit reference was found in the text
== Unused Reference: 'WSCal' is defined on line 1169, but no explicit
reference was found in the text
== Unused Reference: 'WSHT' is defined on line 1172, but no explicit
reference was found in the text
Summary: 0 errors (**), 0 flaws (~~), 14 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: 23 February 2022 22 August 2021
8 Task Extensions to iCalendar
9 draft-ietf-calext-ical-tasks-00
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 23 February 2022.
38 Copyright Notice
40 Copyright (c) 2021 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 Simplified BSD License text
49 as described in Section 4.e of the Trust Legal Provisions and are
50 provided without warranty as described in the Simplified 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 comments to status . . . . . . . . . . . . . . 12
70 10.3. Comments associated to reasons and status changes . . . 12
71 10.4. Task Alerts and Notifications . . . . . . . . . . . . . 12
72 10.5. Automated Status Changes . . . . . . . . . . . . . . . . 13
73 11. New Property Parameters . . . . . . . . . . . . . . . . . . . 13
74 11.1. Group . . . . . . . . . . . . . . . . . . . . . . . . . 13
75 11.2. Reason . . . . . . . . . . . . . . . . . . . . . . . . . 14
76 11.3. Modified . . . . . . . . . . . . . . . . . . . . . . . . 14
77 11.4. Sub-State . . . . . . . . . . . . . . . . . . . . . . . 15
78 12. New Parameter Values . . . . . . . . . . . . . . . . . . . . 16
79 12.1. Redefined VTODO Participant Status . . . . . . . . . . . 16
80 13. New Properties . . . . . . . . . . . . . . . . . . . . . . . 16
81 13.1. Estimated Duration . . . . . . . . . . . . . . . . . . . 16
82 13.2. Task Mode . . . . . . . . . . . . . . . . . . . . . . . 17
83 14. Property Extensions and Clarifications . . . . . . . . . . . 18
84 14.1. The ATTENDEE property . . . . . . . . . . . . . . . . . 19
85 14.2. Redefined COMMENT Property Parameter List . . . . . . . 19
86 14.3. Redefined STATUS Property . . . . . . . . . . . . . . . 20
87 15. CalDAV Support for Task Mode . . . . . . . . . . . . . . . . 21
88 15.1. CALDAV:supported-task-mode-set Property . . . . . . . . 21
89 16. Security Considerations . . . . . . . . . . . . . . . . . . . 22
90 17. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22
91 17.1. Initialization of the Status registry . . . . . . . . . 22
92 17.2. Update of the Status registry . . . . . . . . . . . . . 23
93 17.3. Sub-State value registry . . . . . . . . . . . . . . . . 23
94 17.4. Task Mode value registry . . . . . . . . . . . . . . . . 24
95 17.5. Participation Statuses registry . . . . . . . . . . . . 24
96 17.6. Properties registry . . . . . . . . . . . . . . . . . . 24
97 17.7. Parameters registry . . . . . . . . . . . . . . . . . . 25
98 18. Normative References . . . . . . . . . . . . . . . . . . . . 25
99 19. Informative References . . . . . . . . . . . . . . . . . . . 26
100 Appendix A. Examples of Task State Lifecycle . . . . . . . . . . 27
101 A.1. Simple Case Status Change . . . . . . . . . . . . . . . . 27
102 A.2. Example for multiple Attendees . . . . . . . . . . . . . 27
103 A.3. Example of Failure . . . . . . . . . . . . . . . . . . . 29
104 Appendix B. Change log . . . . . . . . . . . . . . . . . . . . . 29
105 Appendix C. Working Notes . . . . . . . . . . . . . . . . . . . 30
106 C.1. Advertising tasks . . . . . . . . . . . . . . . . . . . . 30
107 C.2. Subscribing to task updates . . . . . . . . . . . . . . . 30
108 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 30
110 1. Acknowledgements
112 The authors would like to thank the members of the Calendaring and
113 Scheduling Consortium technical committees and the following
114 individuals for contributing their ideas, support and comments:
116 John Chaffee, Marten Gajda, Ken Murchison
118 The authors would also like to thank CalConnect, the Calendaring and
119 Scheduling Consortium, for advice with this specification.
121 2. Introduction
123 This document specifies extensions to the existing Internet
124 Calendaring and Scheduling Core Object Specification (iCalendar)
125 [RFC5545], and associated protocols, in order to enhance the
126 structured communication and execution of tasks. The enhancements
127 allow for the communication, time planning and scheduling of tasks by
128 and between automated systems (e.g. in smart power grids, business
129 process management systems) as well as for human centered tasks.
131 A "task" is a representation of an item of work assigned to an
132 individual or organization. In the iCalendar Object Model [RFC5545]
133 the representation of tasks is by "VTODO" calendar components. Tasks
134 can be identified in a number of situations, either informally as ad-
135 hoc tasks in personal "to-do" lists or more formally in:
137 * Business processes - ranging from repetitive workflows to adaptive
138 cases and trouble ticketing
140 * Project Management - whether for large scale construction projects
141 or collaborative software development
143 The extensions specified here are defined in the context of an
144 overall architecture for task calendaring and scheduling.
146 2.1. Terms and Definitions
148 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
149 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
150 "OPTIONAL" in this document are to be interpreted as described in BCP
151 14 [RFC2119] [RFC8174] when, and only when, they appear in all
152 capitals, as shown here.
154 Terms defined in this specification include:
156 Assignee A calendar user assigned to perform a given task. An
157 assignee is equivalent to an attendee of an event.
159 Calendar User (CU) A person or software system that accesses or
160 modifies calendar information.
162 Calendar User Agent (CUA) This may be
164 1. Software with which the calendar user communicates with a
165 calendar service or local calendar store to access calendar
166 information.
168 2. Software that gathers calendar data on the Calendar User's
169 behalf.
171 Candidate A calendar user who might be able to perform a given task,
172 prior to actually being assigned the task, e.g., a dispatcher has
173 a list of taxi drivers (candidates) from which one will be
174 selected to pick-up a passenger.
176 Organizer A calendar user who creates a calendar item, requests
177 free/busy information, or published free/busy information. It is
178 an Organizer who invites Attendees [RFC5545].
180 Observer A calendar user interested in a calendar component, e.g., a
181 manager may have interest in all tasks that have not been
182 completed.
184 Resource A resource in the scheduling context is any shared entity
185 that can be scheduled by a calendar user, but does not control its
186 own attendance status. Resources can be of "Location",
187 "Equipment", or "Role" type.
189 Task A representation of an item of work that can be assigned to one
190 or more task actor assignees. In [RFC5545], these are "VTODO"
191 calendar components, which are groupings of component properties
192 and possibly "VALARM" calendar components that represent an
193 action-item or assignment.
195 3. Task Architecture
197 A reference architecture for task calendaring and scheduling is
198 defined in order to identify the key logical elements involved in
199 task management and the interfaces between them to enable
200 interoperability. The logical elements identified here establish an
201 appropriate separation of concerns and clarify the responsibilities
202 of different elements. However, the architecture does not prescribe
203 a binding or packaging of elements, i.e., software systems may be
204 developed where some elements are tightly bound and the interfaces
205 between bound elements are not exposed. The task architecture is
206 also described in [TARCH].
208 Task +-------+
209 Trigger |
210 +---------------------V---------------------+ +-----------+
211 | Task Generating System | | |
212 | +-------------------------+ | | |
213 | | O | | | |
214 | | /|\ | | | |
215 | | / \ | | | |
216 | | Task Organizer | <----> |
217 | +-^--------^--------------+ | | |
218 | | | | | |
219 | +--------V-+ +----V-----+ +----------+ | | |
220 | | Task | | Process | | Task | | | |
221 | |Assignment| | Logic <----> Domain | | | |
222 | | Rules | | | | Data | | | |
223 | +----------+ +----------+ +----------+ | | |
224 | | | |
225 +------^----------+-----^-------------------+ | |
226 | | | | |
227 Availability Task Task | |
228 | | Status | |
229 | | | | |
230 +------v----------v-----+-------------------+ | |
231 | Calendar and Scheduling System | | Directory |
232 | +---------+ +---------+ | | Service |
233 | | | | Task | <----> |
234 | |Schedule | | Lists | | | |
235 | | | | | | | |
236 | +---------+ +---------+ Server | | |
237 +-------------------------------------------+ | |
238 | Client | | |
239 | +----------------------+ +-----------+ | | |
240 | | Calendar | | Task | | | |
241 | | User Agent +----> Specific | <----> |
242 | | | |Application| | | |
243 | +----------------------+ +-----------+ | | |
244 | | | |
245 +-----^---------^--------+---------+--------+ | |
246 | | | | | |
247 +-----V---------V--------V---------V--------+ | |
248 | Task Actors | | |
249 | O O O O | | |
250 | /|\ /|\ /|\ /|\ +----> |
251 | / \ / \ / \ / \ | | |
252 | Candidate(s) Observer(s) | | |
253 | Assignee(s) Resource(s) | | |
254 +-------------------------------------------+ +-----------+
256 4. Task Architecture Elements
258 The following logical elements form the task architecture that this
259 specification is based on:
261 Task Actors Various calendar users that may be involved in the
262 monitoring or performing of a task. The set of actors includes:
263 Organizers, Observers, Resources, Assignees, and Candidates.
265 Task Organizer The Organizer of a task.
267 Task Domain Data This is any domain specific data that may be acted
268 on or provides context to it in performing a task.
270 Task Specific Application A task specific application renders the
271 data concerning the task (including task domain data) for
272 presentation and manipulation by a task actor.
274 Process Logic Determines under what conditions a task (or tasks) is
275 generated and the actions to take on completion, or some other
276 status event occurring (or not) on the task.
278 Task Trigger This is some event that gives rise to the generation of
279 a task according to Process Logic. Task triggers can come from
280 many different sources including, for example; a task being
281 requested through the calendaring system, a status change in the
282 progression of a business process being managed by a business
283 process management or ERP system.
285 Task Assignment Rules Govern how actors are assigned to a task. A
286 range of different assignment patterns [WfRP] may be considered,
287 including the two general cases:
289 1. Delegation to a named actor or group of actors
291 2. Advertising to a pool of actors for self-selection
293 In either case the assignment may be made based on a variety of
294 criteria including, name, availability, skills, capacity, etc.
296 Task Generating System A system that creates and assigns tasks in
297 response to some initiating event (task trigger). Task creation
298 is according to Process Logic with task assignment determined by
299 Task Assignment Rules. This system also tracks the status of
300 tasks and will initiate further actions based upon the status. A
301 task generating system can take many forms, for example; Business
302 Process Management System, Project Management System, Bug Tracking
303 System, Building Control System. A Task Generating System may
304 also be a human. In iCalendar terms the Task Generating System is
305 the organizer.
307 Human Task Generation Task creation, assignment and tracking
308 coordinated by a human organizer is a special case of a task
309 generating system. In this case Task Assignment Rules and Process
310 Logic may be either explicit or tacit.
312 Directory Service A software system that stores and provides access
313 to information providing details of task actors that may
314 participate or be interested in a task.
316 Calendar and Scheduling System A software system that stores,
317 publishes and synchronizes calendar data such as events, tasks and
318 journal entries for actors. In the context of tasks this includes
319 schedules (i.e. allocated time and availability to perform tasks)
320 and task lists. A calendar and scheduling system typically
321 consists of server and client software components.
323 It is not within the scope of this document to specify how Process
324 Logic or Task Assignment Rules are codified. Such logic and rules
325 may be codified in a variety of ways, including traditional
326 programming languages (e.g. C++, Java) or process modelling
327 languages (e.g. BPMN [BPMN]).
329 5. Architecture Foundations
331 The key standards that enable interoperability between the logical
332 elements of the architecture are the Internet Calendaring and
333 Scheduling Core Object Specification (iCalendar) [RFC5545] and
334 associated protocols. Task and task status are represented by the
335 iCalendar "VTODO" component. Protocols include, in particular, the
336 iCalendar Transport-Independent Interoperability Protocol (iTIP)
337 [RFC5546] for task assignment and scheduling, and Calendaring
338 Extensions to WebDAV (CalDAV) [RFC4791] for client server
339 communication.
341 Additionally, this specification uses definitions from Support for
342 iCalendar Relationships [I-D.ietf-calext-ical-relations]. The LINK,
343 REFID, RELATED-TO and CONCEPT properties enable context and a rich
344 set of relationships between tasks and other iCalendar components to
345 be specified.
347 6. Task Extensions
349 In order to support the task architecture described in Section 3,
350 this document defines a number of extensions to the current iCalendar
351 standards in the areas of:
353 Task Specification improved ability to specify domain specific tasks
355 Task Deadlines, Milestones and Time Planning clarification of
356 deadlines and extension for task duration to support task time
357 planning
359 Task Scheduling and Assignment ensure support for common pattens of
360 scheduling and assigning tasks
362 Task Status Tracking improved granularity in status tracking
363 information and alerting task actors to pending or actual task
364 status changes
366 These extensions are supported mainly by additions to the properties
367 and parameters used within the "VTODO" component.
369 7. Task Specification
371 The specification of tasks must be semantically explicit in order for
372 them to be managed within the context of a business process or
373 project, and be understood by both humans and IT systems. The
374 current VTODO component only provides for simple ad-hoc tasks or 'to
375 do' lists, and is therefore extended by this specification as
376 follows:
378 Task type explicitly what type of task is to be performed is
379 identified.
381 Task context and relationships how a specific task relates to other
382 tasks and other objects that need to be understood for the
383 effective execution of a task.
385 Task specific data the form and content of domain data provided as
386 input to a task and/or that may be output from a task.
388 Organizer and attendee recognizes that a task organizer or attendee
389 can be an automated system.
391 7.1. CONCEPT for task type identification
393 The CONCEPT property is used to identify the type of task, for
394 example;
396 CONCEPT:http://example.com/task/delivery
398 7.2. Task Context and Relationships
400 The LINK property specifies a link to external information, which may
401 be context to the task. For example:
403 LINK;REL=SOURCE:http://example.com/package/1234567890
405 LINK;REL=describedby:mid:752142.1414823874.307E5@mx123.example.com
407 The external information may be data to be manipulated in performing
408 the task. See section 3.1.3 Task Domain Data Handling.
410 REFID is used to identify a key allowing the association of tasks
411 that are related to the same object and retrieval of a task based on
412 this key. This may be, for example, to identify the tasks associated
413 with a given project without having to communicate the task structure
414 of the project, or all tasks associated to a specific package.
416 REFID:Manhattan
418 REFID:1234567890
420 Extensions [Doug114] to the RELATED-TO property allow temporal
421 relationships between tasks as found in project management to be
422 specified as well as parent / child relationships and dependencies
423 (DEPENDS-ON). Tasks (VTODOs) may also be related to other calendar
424 components; for example to a VEVENT to block time to perform a task.
426 7.3. Task Domain Data Handling
428 Provide support for task specific input and output data (including
429 updates) beyond the standard iCalendar properties. It is envisaged
430 that standard calendar user agents will be able to launch task
431 specific applications by passing task specific data.
433 The LINK property can be used to 'attach' the domain specific data to
434 the task. For example, it might be a URI pointing to a web page
435 where the status of the task can be directly manipulated.
437 LINK;REL="vacation-system";VALUE=URI:http://example.com/
438 vacation-approval?id=1234
440 Or it might be used for attachments specific to the task, for example
441 an electronic copy of a signature taken to confirm delivery of a
442 package.
444 LINK;REL="electronic-signature";VALUE=URI:http://example.com/
445 delivery/sig1234.jpg
447 8. Task Deadlines, Milestones and Time Planning
449 Deadlines for starting and finishing a task are defined by the
450 DTSTART, DUE and DURATION properties. DTSTART represents the
451 earliest start time for beginning work on a task. DUE, or DTSTART +
452 DURATION represent the latest finish time for a task. Thus these
453 properties define a "window" within which a task has to be performed.
454 However, there is currently no way to indicate how long the task is
455 expected to take. This document defines a new property, ESTIMATED-
456 DURATION, to allow the estimated time that a task should take to be
457 specified separately from the deadlines for starting and finishing a
458 task. This supports time planning by enabling calendar user agents
459 to display when tasks should occur and therefore allow calendar users
460 to visualize when tasks should be performed and allocate time to
461 them.
463 A task that has intermediary deadlines (i.e., milestones) SHOULD be
464 expressed by child VTODO components (i.e., sub-tasks associated with
465 each of the milestones) in conjunction with the RELATED-TO property
466 to relate the parent and child tasks.
468 9. Task Scheduling and Assignment
470 This specification supports the two distinct models of assigning
471 actors to tasks, i.e., 1) strictly one assignee per task or 2) task
472 assignment to multiple assignees. In this regard one or many
473 ATTENDEES may be specified against a task depending upon the model
474 applied by the task organizer.
476 In addition a number of different patterns of resource or assignee
477 identification are anticipated. The specific Task Assignment Rules
478 are the responsibility of the Task Organizer.
480 Communication of task assignment or delegation to one or more actors
481 who are allocated to a task by the organizer is directly supported by
482 iTIP, i.e., all included ATTENDEES in an iTIP REQUEST are expected to
483 perform the task.
485 The offering or advertising of a task to one or more (potential)
486 actors where only one or a subset of the candidates may accept the
487 task will be addressed by a new VPOLL mode (See Appendix B) [VPOLL].
489 10. Status Reporting
491 10.1. Improved granularity in status reporting information
493 This document defines new status parameters that can be applied to
494 the VTODO status (STATUS) property, as well as the participant status
495 (PARTSTAT) parameter. These new parameters provide additional
496 information on why (REASON) and when (MODIFIED) a status has changed.
497 In addition to these parameters new status values are specified to
498 provide for task suspension, failure and preparation.
500 10.2. Relating comments to status
502 The GROUP parameter is used with the STATUS or ATTENDEE properties to
503 relate an associated COMMENT property. The COMMENT property can then
504 be used to include additional human readable information about why
505 the associated STATUS or ATTENDEE property changed.
507 STATUS;REASON="http://example.com/reason/delivery-failed";
508 SUBSTATE=ERROR;MODIFIED=20130212T120000Z;GROUP=G1:FAILED
509 COMMENT;MODIFIED=20130226T110451Z;GROUP=G1:Breakdown
510 ATTENDEE;PARTSTAT=FAILED;MODIFIED=20130226T1104510Z;GROUP=G2:
511 REASON="http://example.com/reason/van-break-down":
512 mailto:xxx@example.com
513 COMMENT;MODIFIED=20130226T110451Z;GROUP=G2:Puncture
515 10.3. Comments associated to reasons and status changes
517 Reasons may be associated directly with a comment, allowing for
518 multiple reasons associated with a status to each have a comment
519 associated with them [EDISTS].
521 CONCEPT:http://example.com/task/delivery
522 STATUS;SUBSTATE=ERROR;MODIFIED=20130212T120000Z;GROUP=G1:FAILED
523 COMMENT;MODIFIED=20130226T110451Z;GROUP=G1:Out of time
524 COMMENT;REASON="http://example.com/reason/traffic";
525 MODIFIED=20130226T110451Z;GROUP=G1:Traffic Accident on E44
526 COMMENT;REASON="http://example.com/reason/closed";
527 MODIFIED=20130226T110451Z;GROUP=G1:Arrived after office hours
529 10.4. Task Alerts and Notifications
531 Different needs to alert or notify task actors of pending or actual
532 task status changes are recognized:
534 Alarms Alarms (VLARM components) operate in the calendar user agent
535 space to notify the task actor of a pending task state for a task
536 they are assigned to or are interested in. Note: there is no
537 constraint in the current standards on the propagation of alarms
538 specified on calendar objects by organizers to individual
539 attendees.
541 Escalations An escalation or notification to the ATTENDEE,
542 ORGANIZER, or other task actor may be required if a deadline
543 associated with a task is exceeded or for some other reason.
544 Process Logic identifying when and who to propagate escalations to
545 is the responsibility of the Task Generating System, e.g., a BPMS.
547 Notifications Task actors (observers) not directly involved in
548 performing a task but with a known interest in a given task's
549 status can be identified by the ASSOCIATE property [Doug214]
550 against certain components e.g. ALARM, to identify which task
551 events the stakeholder/party is interested in. Notifications on
552 shared calendars will allow task actors to register an interest in
553 changes to tasks within a calendar (see Appendix A).
555 10.5. Automated Status Changes
557 A new property, TASK-MODE, is introduced to instruct servers to apply
558 automated operations for changing the status of a task.
560 11. New Property Parameters
562 11.1. Group
564 Parameter name GROUP
566 Purpose This parameter allows the association of different (usually)
567 multiply occurring properties.
569 Format Definition This parameter is defined by the following
570 notation:
572 groupparam = "GROUP" "=" text
573 *("," text)
575 Description The value of this parameter is free-form text that
576 creates an identifier for associated properties. All properties
577 that use the same GROUP value are associated through that value.
578 For example, multiple comments and an attendee may be associated
579 with a status value.
581 Example The following is an example of this property.
583 GROUP=G1
585 11.2. Reason
587 Parameter name REASON
589 Purpose To indicate the reason for a change in status of a task or
590 attendee participation status.
592 Format Definition This parameter is defined by the following
593 notation:
595 reasonparam = "REASON" "=" DQUOTE uri DQUOTE
596 *("," DQUOTE uri DQUOTE)
598 Description This property parameter allows the change in status of a
599 task or participant status to be qualified by the reason for the
600 change with a codified reason. Typically reasons are defined
601 within the context of the task type and therefore SHOULD include
602 the name-space of the authority defining the task. Common reason
603 codes are IANA registered and do not have a name-space prefix.
605 Example
607 STATUS;REASON="http://example.com/reason/delivered-on-time";
608 MODIFIED=20130212T120000Z;GROUP=G1:COMPLETED
609 ATTENDEE;REASON="x-example-reason:out-of-office";
610 PARTSTAT=DECLINED;MODIFIED=20130212T120000Z;
611 GROUP=123:mailto:cyrus@example.com
613 11.3. Modified
615 Parameter name MODIFIED
617 Purpose To specify the time and date of when the status of a task or
618 attendee participant status changed.
620 Format Definition This parameter is defined by the following
621 notation:
623 modifiedparam = "MODIFIED" "=" date-time
625 Description The modified parameter allows the specification of the
626 date time of when a status (STATUS) or participant status
627 (PARTSTAT) changed. It MUST be specified in the UTC time format.
628 The value of MODIFIED SHOULD be set at the time when the
629 associated status (either STATUS or PARTSTAT)is changed.
630 Therefore either a client or server may set the value of MODIFIED
631 depending on which is updating the value of STATUS or PARTSTAT.
632 For backwards compatibility if the server detects that MODIFIED
633 should have changed but wasn't (for example the client doesn't
634 support MODIFIED) then the server MAY set MODIFIED
635 retrospectively.
637 Example
639 STATUS;REASON=""http://example.com/reason/delivered-on-time";
640 MODIFIED=20130212T120000Z;GROUP=G1:COMPLETED
642 11.4. Sub-State
644 Parameter name SUBSTATE
646 Purpose To provide additional granularity of task status for e.g.
647 IN-PROCESS.
649 Format Definition This parameter is defined by the following
650 notation:
652 substateparam = "SUBSTATE" "="
653 ( "OK" ; everything is fine(the default)
654 / "ERROR" ; something is wrong (the REASON
655 ; code explains why)
656 / "SUSPENDED" ; waiting on some other task to
657 ; complete or availability of a
658 ; resource (REASON code explains
659 ; why)
660 / x-name ; Experimental type
661 / iana-token) ; Other IANA-registered type
663 Description The sub-state parameter allows additional qualification
664 and granularity of states to be recorded, in particular for the
665 IN-PROCESS state. It allows individual sub-states to be recorded
666 without the need to define and publish a sub-task associated with
667 a parent task purely to track that a particular state has been
668 reached. This property also allows parallel states to be
669 expressed e.g. that a task has been suspended at whatever state it
670 has reached.
672 Example
674 STATUS;REASON="http://example.com/reason/no-one-home";
675 SUBSTATE=ERROR:FAILED
676 STATUS;REASON="http://example.com/reason/paint-drying";
677 SUBSTATE=SUSPENDED:IN-PROCESS
679 12. New Parameter Values
681 12.1. Redefined VTODO Participant Status
683 Participant status parameter type values are defined in [RFC5545].
684 This specification redefines that type to include the new value
685 FAILED for VTODO iCalendar components.
687 Format Definition This property parameter is extended by the
688 following notation:
690 partstat-todo /= *("FAILED") ; To-do cannot be completed
692 Example
694 ATTENDEE;REASON="http://example.com/reason/not-enough-time";
695 PARTSTAT=FAILED:mailto:jsmith@example.com
697 13. New Properties
699 13.1. Estimated Duration
701 Property Name ESTIMATED-DURATION
703 Purpose This property specifies the estimated positive duration of
704 time the corresponding task will take to complete.
706 Value Type DURATION
708 Property Parameters IANA and non-standard property parameters can be
709 specified on this property.
711 Conformance This property can be specified in "VTODO" calendar
712 components.
714 Format Definition This property is defined by the following
715 notation:
717 est-duration = "ESTIMATED-DURATION" durparam ":" dur-value CRLF
718 ;consisting of a positive duration of time.
720 durparam = *(";" other-param)
722 Description In a "VTODO" calendar component the property MAY be used
723 to specify the estimated duration for the to-do, with or without
724 an explicit time window in which the event should be started and
725 completed. When present, DTSTART and DUE/DURATION represent the
726 window in which the task can be performed. ESTIMATED-DURATION
727 SHOULD be passed from ORGANIZER to ATTENDEE in iTIP [RFC5546]
728 messages.
730 Example The following is an example of this property that specifies
731 an interval of time of exactly one hour:
733 ESTIMATED-DURATION:PT1H
735 13.2. Task Mode
737 Property Name TASK-MODE
739 Purpose This property specifies automatic operations that servers
740 apply to tasks based on changes in attendee status (PARTSTAT).
742 Value Type TEXT
744 Property Parameters IANA and non-standard property parameters can be
745 specified on this property.
747 Conformance This property can be specified zero or more times in a
748 "VTODO" calendar component.
750 Format Definition This property is defined by the following
751 notation:
753 task-mode = "TASK-MODE taskmodeparam ":" taskvalue
754 *("," taskvalue) CRLF
756 taskvalue = "AUTOMATIC-COMPLETION" ; set STATUS completed
757 ;if all attendees have completed
758 / "AUTOMATIC-FAILURE"
759 / "SERVER"
760 / "CLIENT"
761 / iana-token
762 / x-name
764 taskmodeparam = *(";" other-param)
766 Description In a "VTODO" calendar component this property MAY be
767 used to indicate to servers how they can automatically change the
768 state of the task based on iTIP replies from Attendees. For
769 example, the server can automatically set the overall task status
770 (STATUS) to COMPLETED when every attendee has marked their own
771 status (PARTSTAT) as COMPLETED, or the server could mark the task
772 as FAILED if its DUE date passes without it being completed.
773 TASK-MODE processing is performed on the organizer's copy of the
774 task.
776 The property value is a list of one or more IANA registered tokens
777 that defines modes to be used for the task. This specification
778 defines three modes which are described in the following sub-
779 sections.
781 Examples
783 TASK-MODE:AUTOMATIC-COMPLETION,AUTOMATIC-FAILURE
784 TASK-MODE:SERVER
785 TASK-MODE:AUTOMATIC-FAILURE
787 AUTOMATIC-COMPLETION Task Mode The task mode value "AUTOMATIC-
788 COMPLETION" indicates to the server that it can change the "VTODO"
789 component's STATUS property value to "COMPLETED" as soon as all
790 ATTENDEEs in the task have replied with a "PARTSTAT" parameter set
791 to "COMPLETED".
793 AUTOMATIC-FAILURE Task Mode The task mode value "AUTOMATIC-FAILURE"
794 indicates to the server that it SHOULD change the "VTODO"
795 component's STATUS property value to "FAILED" if either:
797 * the PARTSTAT of one ATTENDEE is set to FAILED; or
799 * the current time is past the effective due date of the
800 component and the task has not yet been completed.
802 Note: The effective due date is either the "DUE" property value or
803 the combination of the "DTSTART" and "DURATION" property values.
805 CLIENT Task Mode The task mode value "CLIENT" is an instruction to
806 the server to honour the status set by the client.
808 SERVER Task Mode The task mode value "SERVER" indicates to the
809 server that it can change the "VTODO" component's STATUS property
810 value to an appropriate value, based on implementation defined
811 "business rules", as ATTENDEE responses are processed or as
812 deadlines related to the task pass.
814 The server can add this property to a "VTODO" component to
815 indicate to the client that it will be managing the status.
817 14. Property Extensions and Clarifications
818 14.1. The ATTENDEE property
820 The Attendee property is defined in [RFC5545]. This specification
821 extends that property to include new parameters to indicate the
822 reason for a participant status change (See Appendix A) and sub-
823 states.
825 Format Definition This property is defined by the following
826 notation:
828 attendee = "ATTENDEE" attparam ":" cal-address CRLF
830 attparam /= *(
831 ;
832 ; The following are OPTIONAL,
833 ; but MUST NOT occur more than once.
834 ;
835 (";" reasonparam)
836 (";" modifiedparam)
837 (";" substateparam)
838 )
840 Example: The following are examples of this property's use for tasks:
842 ATTENDEE;PARTSTAT=DECLINED;MODIFIED=20130212T120000Z;GROUP=G1;
843 REASON="http://example.com/reason/too-busy":mailto:xxx@example.com
845 ATTENDEE;PARTSTAT=IN-PROCESS;MODIFIED=20130212T120000Z;
846 SUBSTATE=X-EXAMPLE-STEP-1:mailto:xxx@example.com
848 14.2. Redefined COMMENT Property Parameter List
850 The Comment property is defined in [RFC5545].
852 Format Definition The "COMMENT" property parameter list is augmented
853 as follows:
855 commparam /= *(
856 ; The following are OPTIONAL,
857 ; but MUST NOT occur more than once.
858 (";" reasonparam) /
859 (";" modifiedparam)
860 )
862 14.3. Redefined STATUS Property
864 The Status property is defined in [RFC5545]. This specification
865 extends that property to include new parameters to indicate the
866 reason for a status change as well as new values associated with
867 VTODO iCalendar components (See Appendix A for examples of the task
868 state lifecycle).
870 Format Definition The "STATUS" property parameter list is augmented
871 as follows:
873 statparam /= *(
874 ; The following are OPTIONAL,
875 ; but MUST NOT occur more than once.
876 ;
877 (";" reasonparam)
878 (";" modifiedparam)
879 (";" substateparam) /
880 )
882 statvalue-todo = / "PENDING" ;Indicates a to-do has been
883 ;created and accepted, but has not
884 ;yet started.
885 / "FAILED" ;Indicates to-do has failed.
886 ;Extended status values for
887 ;"VTODO".
889 Description:
891 PENDING - A task has been created but has not yet started and is
892 ready to start subject to other dependencies (e.g. preceding task or
893 DTSTART). This is the default state.
895 FAILED - task has failed and may need some follow-up from the
896 organizer to re-schedule or cancel
898 Example: The following is an example of this property for a "VTODO"
899 calendar component:
901 STATUS;REASON="http://example.com/reason/delivery-failed";
902 SUBSTATE=ERROR;MODIFIED=20130212T120000Z;GROUP=G1:FAILED
904 15. CalDAV Support for Task Mode
906 The CalDAV [RFC4791] calendar access protocol allows clients and
907 servers to exchange iCalendar data. With the introduction of the
908 "TASK-MODE" property in this specification, different automated task
909 management behaviours may be delegated to the server by the Task
910 Organizer depending upon the value of "TASK-MODE".
912 In order for a CalDAV client to know what task modes are available, a
913 CalDAV server advertises a CALDAV:supported-task-mode-set WebDAV
914 property on calendar home or calendar collections if it supports the
915 use of the "TASK-MODE" property as described in this specification.
916 The server can advertise a specific set of supported task modes by
917 including one or more CALDAV:supported-task-mode XML elements within
918 the CALDAV:supported-task-mode-set XML element. If no
919 CALDAV:supported-task-mode XML elements are included in the WebDAV
920 property, then clients can try any task mode, but need to be prepared
921 for a failure when attempting to store the calendar data.
923 Clients MUST NOT attempt to store iCalendar data containing "TASK-
924 MODE" elements if the CALDAV:supported-task-mode-set WebDAV property
925 is not advertised by the server.
927 The server SHOULD return an HTTP 403 response with a DAV:error
928 element containing a CALDAV:supported-task-mode XML element, if a
929 client attempts to store iCalendar data with an "TASK-MODE" element
930 value not supported by the server.
932 It is possible for a "TASK-MODE" value to be present in calendar data
933 on the server being accessed by a client that does not support the
934 "TASK-MODE" property. It is expected that existing clients, unaware
935 of "TASK-MODE", will fail gracefully by ignoring the calendar
936 property.
938 15.1. CALDAV:supported-task-mode-set Property
940 Name supported-task-mode-set
942 Namespace urn:ietf:params:xml:ns:caldav
944 Purpose Enumerates the set of supported iCalendar "TASK-MODE"
945 element values supported by the server.
947 Protected This property MUST be protected and SHOULD NOT be returned
948 by a PROPFIND allprop request (as defined in Section 14.2 of
949 [RFC4918]).
951 Description See above.
953 Definition
955
956
957
960 Example
962
963 AUTOMATIC-COMPLETION
964 AUTOMATIC-FAILURE
965 SERVER
966 CLIENT
967
969 16. Security Considerations
971 This specification introduces no new security considerations beyond
972 those identified in [RFC5545].
974 17. IANA Considerations
976 17.1. Initialization of the Status registry
978 This specification updates [RFC5545] by adding a Status value
979 registry to the iCalendar Elements registry and initializing it as
980 per [RFC5545].
982 +==============+=========+===========+
983 | Name | Status | Reference |
984 +==============+=========+===========+
985 | CANCELLED | Current | [RFC5545] |
986 +--------------+---------+-----------+
987 | COMPLETED | Current | [RFC5545] |
988 +--------------+---------+-----------+
989 | CONFIRMED | Current | [RFC5545] |
990 +--------------+---------+-----------+
991 | DRAFT | Current | [RFC5545] |
992 +--------------+---------+-----------+
993 | FINAL | Current | [RFC5545] |
994 +--------------+---------+-----------+
995 | IN-PROCESS | Current | [RFC5545] |
996 +--------------+---------+-----------+
997 | NEEDS-ACTION | Current | [RFC5545] |
998 +--------------+---------+-----------+
999 | TENTATIVE | Current | [RFC5545] |
1000 +--------------+---------+-----------+
1002 Table 1: Initial Status Value Registry
1004 17.2. Update of the Status registry
1006 This specification further updates the Status registry with
1007 additional values defined in this document.
1009 +=========+=========+=========================+
1010 | Value | Status | Reference |
1011 +=========+=========+=========================+
1012 | PENDING | Current | This Spec, Section 14.3 |
1013 +---------+---------+-------------------------+
1014 | FAILED | Current | This Spec, Section 14.3 |
1015 +---------+---------+-------------------------+
1017 Table 2: Updated Status Value Registry
1019 17.3. Sub-State value registry
1021 The following table has been used to initialize the Sub-State
1022 registry.
1024 +===========+=========+=========================+
1025 | Substate | Status | Reference |
1026 +===========+=========+=========================+
1027 | OK | Current | This Spec, Section 11.4 |
1028 +-----------+---------+-------------------------+
1029 | ERROR | Current | This Spec, Section 11.4 |
1030 +-----------+---------+-------------------------+
1031 | SUSPENDED | Current | This Spec, Section 11.4 |
1032 +-----------+---------+-------------------------+
1034 Table 3: Sub-State registry
1036 17.4. Task Mode value registry
1038 The following table has been used to initialize the Task Mode
1039 registry.
1041 +======================+=========+=========================+
1042 | Task Mode | Status | Reference |
1043 +======================+=========+=========================+
1044 | AUTOMATIC-COMPLETION | Current | This Spec, Section 13.2 |
1045 +----------------------+---------+-------------------------+
1046 | AUTOMATIC-FAILURE | Current | This Spec, Section 13.2 |
1047 +----------------------+---------+-------------------------+
1048 | CLIENT | Current | This Spec, Section 13.2 |
1049 +----------------------+---------+-------------------------+
1050 | SERVER | Current | This Spec, Section 13.2 |
1051 +----------------------+---------+-------------------------+
1053 Table 4: Task Mode Value Registry
1055 17.5. Participation Statuses registry
1057 The following table has been used to update the Participation
1058 Statuses registry.
1060 +========+=========+=========================+
1061 | Value | Status | Reference |
1062 +========+=========+=========================+
1063 | FAILED | Current | This Spec, Section 12.1 |
1064 +--------+---------+-------------------------+
1066 Table 5: Participation Statuses Registry
1068 17.6. Properties registry
1070 The following table has been used to update the Properties registry.
1072 +====================+=========+=========================+
1073 | Property | Status | Reference |
1074 +====================+=========+=========================+
1075 | ATTENDEE | Current | This Spec, Section 14.1 |
1076 +--------------------+---------+-------------------------+
1077 | COMMENT | Current | This Spec, Section 14.2 |
1078 +--------------------+---------+-------------------------+
1079 | ESTIMATED_DURATION | Current | This Spec, Section 13.1 |
1080 +--------------------+---------+-------------------------+
1081 | STATUS | Current | This Spec, Section 14.3 |
1082 +--------------------+---------+-------------------------+
1083 | TASK-MODE | Current | This Spec, Section 13.2 |
1084 +--------------------+---------+-------------------------+
1086 Table 6: Updated Properties Registry
1088 17.7. Parameters registry
1090 The following table has been used to update the Parameters registry.
1092 +===========+=========+=========================+
1093 | Parameter | Status | Reference |
1094 +===========+=========+=========================+
1095 | REASON | Current | This Spec, Section 11.2 |
1096 +-----------+---------+-------------------------+
1097 | MODIFIED | Current | This Spec, Section 11.3 |
1098 +-----------+---------+-------------------------+
1099 | SUBSTATE | Current | This Spec, Section 11.4 |
1100 +-----------+---------+-------------------------+
1102 Table 7: Ipdated Parameters Registry
1104 18. Normative References
1106 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
1107 Requirement Levels", RFC 2119, IETF RFC 2119,
1108 DOI 10.17487/RFC2119, March 1997,
1109 .
1111 [RFC4791] Daboo, C., Desruisseaux, B., and L. Dusseault,
1112 "Calendaring Extensions to WebDAV (CalDAV)", RFC 4791,
1113 IETF RFC 4791, DOI 10.17487/RFC4791, March 2007,
1114 .
1116 [RFC4918] Dusseault, L., Ed., "HTTP Extensions for Web Distributed
1117 Authoring and Versioning (WebDAV)", RFC 4918, IETF RFC
1118 4918, DOI 10.17487/RFC4918, June 2007,
1119 .
1121 [RFC5545] Desruisseaux, B., Ed., "Internet Calendaring and
1122 Scheduling Core Object Specification (iCalendar)", RFC
1123 5545, IETF RFC 5545, DOI 10.17487/RFC5545, September 2009,
1124 .
1126 [RFC5546] Daboo, C., Ed., "iCalendar Transport-Independent
1127 Interoperability Protocol (iTIP)", RFC 5546, IETF RFC
1128 5546, DOI 10.17487/RFC5546, December 2009,
1129 .
1131 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
1132 2119 Key Words", RFC 8174, IETF RFC 8174,
1133 DOI 10.17487/RFC8174, May 2017,
1134 .
1136 [I-D.ietf-calext-eventpub-extensions]
1137 Douglass, M., "Event Publishing Extensions to iCalendar",
1138 I-D.ietf-calext-eventpub-extensions, IETF I-D.ietf-calext-
1139 eventpub-extensions, March 2021.
1141 [I-D.ietf-calext-ical-relations]
1142 Douglass, M., "Support for iCalendar Relationships", I-
1143 D.ietf-calext-ical-relations, IETF I-D.ietf-calext-ical-
1144 relations, December 2020.
1146 19. Informative References
1148 [BPMN] "Business Process Model and Notation", OMG BPMN 2.0.2,
1149 January 2014,
1150 .
1152 [I-D.york-vpoll]
1153 York, E., Daboo, C., and M. Douglass, "VPOLL: Consensus
1154 Scheduling Component for iCalendar", I-D.york-vpoll,
1155 IETF I-D.york-vpoll, February 2017.
1157 [TARCH] "Apthorp, A., Daboo, C., Douglass, M., CalConnect, Task
1158 Architecture V1.0,", CalConnect Task Architecture V1.0.
1160 [EDISTS] "UN Economic Commission for Europe, UN/EDIFACT, D14.A, STS
1161 STATUS, April 30,
1162 2014,http://www.unece.org/fileadmin/DAM/trade/untdid/d14a/
1163 trsd/trsdsts.htm", UN/EDIFACT, D14.A.
1165 [WfRP] "Russell, N., ter Hofstede, A.H.M., Edmond, T., van der
1166 Aalst,W.M.P., Workflow Resource Patterns, Eindhoven
1167 University of Technology, 2004,", WfRP.
1169 [WSCal] "Considine, T., Douglass, M., WS-Calendar Version 1.0,
1170 OASIS, 30 July 2011,", OASIS WS-Calendar V1.0.
1172 [WSHT] "Ings, D., Clement, L., Koenig, D., Mehta, V., Mueller,
1173 R., Rangaswamy, R., Rowley, M., Trickovic, I., Web
1174 Services - Human Task Version 1.1 (WS-HumanTask), OASIS,
1175 17 August 2010,", OASIS WS-HT V1.1.
1177 Appendix A. Examples of Task State Lifecycle
1179 A.1. Simple Case Status Change
1181 +===+==============+==============+===========================+
1182 | | STATUS | PARTSTAT | Action |
1183 +===+==============+==============+===========================+
1184 | 1 | - | - | Organizer draft |
1185 +---+--------------+--------------+---------------------------+
1186 | 2 | NEEDS-ACTION | NEEDS-ACTION | Organizer sends iTIP |
1187 | | | | request |
1188 +---+--------------+--------------+---------------------------+
1189 | 3 | NEEDS-ACTION | ACCEPTED | Attendee reply |
1190 +---+--------------+--------------+---------------------------+
1191 | 4 | PENDING | ACCEPTED | Task accepted but waiting |
1192 | | | | on some "trigger" to |
1193 | | | | start (e.g. another task |
1194 | | | | has to finish first) |
1195 +---+--------------+--------------+---------------------------+
1196 | 5 | IN-PROCESS | IN-PROCESS | Attendee reply now |
1197 | | | | working on the task |
1198 +---+--------------+--------------+---------------------------+
1199 | 6 | IN-PROCESS | COMPLETED | Attendee reply completed |
1200 +---+--------------+--------------+---------------------------+
1201 | 7 | COMPLETED | COMPLETED | Organizer changes overall |
1202 | | | | state |
1203 +---+--------------+--------------+---------------------------+
1205 Table 8: Example of status changes in assigning and
1206 performing a task with one attendee.
1208 A.2. Example for multiple Attendees
1210 Example of status changes in assigning and performing a task with two
1211 attendees (A1 and A2).
1213 +====+==============+==============+==============+================+
1214 | | STATUS | PARTSTAT | PARTSTAT | Action |
1215 | | | (A1) | (A2) | |
1216 +====+==============+==============+==============+================+
1217 | 1 | - | - | - | Organizer |
1218 | | | | | draft. |
1219 +----+--------------+--------------+--------------+----------------+
1220 | 2 | NEEDS-ACTION | NEEDS-ACTION | NEEDS-ACTION | Organizer |
1221 | | | | | sends iTIP |
1222 | | | | | request. |
1223 +----+--------------+--------------+--------------+----------------+
1224 | 4 | NEEDS-ACTION | ACCEPTED | NEEDS-ACTION | Attendee 1 |
1225 | | | | | reply. |
1226 +----+--------------+--------------+--------------+----------------+
1227 | 5 | NEEDS-ACTION | ACCEPTED | ACCEPTED | Attendee 2 |
1228 | | | | | reply. |
1229 +----+--------------+--------------+--------------+----------------+
1230 | 6 | PENDING | ACCEPTED | ACCEPTED | Task accepted |
1231 | | | | | but waiting on |
1232 | | | | | some"trigger" |
1233 | | | | | to start (e.g. |
1234 | | | | | another task |
1235 | | | | | has to finish |
1236 | | | | | first) |
1237 +----+--------------+--------------+--------------+----------------+
1238 | 7 | IN-PROCESS | ACCEPTED | IN-PROCESS | Attendee 2 |
1239 | | | | | reply now |
1240 | | | | | working on the |
1241 | | | | | task. |
1242 +----+--------------+--------------+--------------+----------------+
1243 | 8 | IN-PROCESS | IN-PROCESS | IN-PROCESS | Attendee 1 |
1244 | | | | | reply now |
1245 | | | | | working on the |
1246 | | | | | task. |
1247 +----+--------------+--------------+--------------+----------------+
1248 | 9 | IN-PROCESS | COMPLETED | IN-PROCESS | Attendee 1 |
1249 | | | | | reply |
1250 | | | | | Completed |
1251 | | | | | (overall |
1252 | | | | | status still |
1253 | | | | | IN-PROCESS). |
1254 +----+--------------+--------------+--------------+----------------+
1255 | 10 | IN-PROCESS | COMPLETED | COMPLETED | Attendee 2 |
1256 | | | | | reply |
1257 | | | | | Completed |
1258 +----+--------------+--------------+--------------+----------------+
1259 | 11 | COMPLETED | COMPLETED | COMPLETED | Organizer |
1260 | | | | | changes |
1261 | | | | | overall state |
1262 | | | | | once both |
1263 | | | | | attendees are |
1264 | | | | | finished. |
1265 +----+--------------+--------------+--------------+----------------+
1267 Table 9: Example for multiple Attendees
1269 Note: The logic for determining the status change to the VTODO is
1270 determined by the task organizer based on the ATTENDEE status and
1271 other business logic.
1273 A.3. Example of Failure
1275 Example of status changes for a task that fails.
1277 +===+==============+==============+==============================+
1278 | | STATUS | PARTSTAT | Action |
1279 +===+==============+==============+==============================+
1280 | 1 | - | - | Organizer draft |
1281 +---+--------------+--------------+------------------------------+
1282 | 2 | NEEDS-ACTION | NEEDS-ACTION | Organizer sends iTIP request |
1283 +---+--------------+--------------+------------------------------+
1284 | 3 | NEEDS-ACTION | ACCEPTED | Attendee reply |
1285 +---+--------------+--------------+------------------------------+
1286 | 4 | IN-PROCESS | IN-PROCESS | Attendee reply now working |
1287 | | | | on the task |
1288 +---+--------------+--------------+------------------------------+
1289 | 5 | IN-PROCESS | FAILED | Attendee reply task failed |
1290 +---+--------------+--------------+------------------------------+
1291 | 6 | FAILED | FAILED | Organizer changes overall |
1292 | | | | state |
1293 +---+--------------+--------------+------------------------------+
1295 Table 10: Example of Failure
1297 Appendix B. Change log
1299 V02. 2021-05-05 MD
1301 * Redo in asciidoc
1303 * Change STRUCTURED-CATEGORY to CONCEPT
1305 * Add GROUP parameter definition
1307 V01. 2015-08-23 AA
1308 * Highlighted use of ESTIMATED-DURATION for time planning.
1310 * Corrected PARTSTAT example section 5.1. Changed DECLINED to
1311 FAILED.
1313 * Replaced Task Mode AUTOMATIC-STATUS with CLIENT and SERVER modes.
1314 Also, clarified that task mode processing is only done on the
1315 organizer's copy.
1317 * Clarified responsibility for setting MODIFIED.
1319 * CalDAV support added.
1321 * Updated normative references.
1323 Appendix C. Working Notes
1325 C.1. Advertising tasks
1327 Use VPOLL for advertising a task to a pool of possible ATTENDEEs and
1328 then select the respondent to assign one or more assignees.
1330 Introduce POLL-MODE:ASSIGNMENT
1332 Need to indicate number of assignees required.
1334 Potentially different types of response e.g. ACCEPT or DECLINE, or a
1335 weighting e.g. 0 - 100
1337 Take into FREEBUSY discussion.
1339 C.2. Subscribing to task updates
1341 Stakeholders should have the ability to subscribe to categories /
1342 types of tasks on an ongoing basis. Reference calendarserver.org
1343 notifications draft
1345 Authors' Addresses
1347 Adrian Apthorp
1348 DHL Express
1350 Email: aapthorp@theiet.org
1352 Michael Douglass
1353 Bedework Commercial Services
1354 Email: mdouglass@bedework.com