idnits 2.17.1
draft-apthorp-ical-tasks-01.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
(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 (September 14, 2015) is 3146 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: 'RFC 4791' is mentioned on line 337, but not defined
== Unused Reference: 'RFC2234' is defined on line 1100, but no explicit
reference was found in the text
== Unused Reference: 'RFC3688' is defined on line 1104, but no explicit
reference was found in the text
== Unused Reference: 'RFC3986' is defined on line 1107, but no explicit
reference was found in the text
== Unused Reference: 'WSCal' is defined on line 1154, but no explicit
reference was found in the text
== Unused Reference: 'WSHT' is defined on line 1159, but no explicit
reference was found in the text
** Obsolete normative reference: RFC 2234 (Obsoleted by RFC 4234)
== Outdated reference: A later version (-06) exists of
draft-douglass-calendar-extension-04
-- Possible downref: Normative reference to a draft: ref. 'Doug214'
== Outdated reference: A later version (-04) exists of draft-york-vpoll-03
Summary: 1 error (**), 0 flaws (~~), 9 warnings (==), 4 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 Intended status: Standards Track C. Daboo
5 Updates: 5545 (if approved) Apple Inc.
6 Expires: March 17, 2016 M. Douglass
7 RPI
8 September 14, 2015
10 Task Extensions to iCalendar
11 draft-apthorp-ical-tasks-01.txt
13 Abstract
15 This document defines extensions to the Internet Calendaring and
16 Scheduling Core Object Specification (iCalendar) (RFC5545) to provide
17 improved status tracking, scheduling and specification of tasks. It
18 also defines how Calendaring Extensions to WebDAV (CalDAV) (RFC 4791)
19 servers can be extended to support certain automated task management
20 behaviours.
22 Status of this Memo
24 This Internet-Draft is submitted in full conformance with the
25 provisions of BCP 78 and BCP 79.
27 Internet-Drafts are working documents of the Internet Engineering
28 Task Force (IETF), its areas, and its working groups. Note that
29 other groups may also distribute working documents as Internet-
30 Drafts.
32 Internet-Drafts are draft documents valid for a maximum of six months
33 and may be updated, replaced, or obsoleted by other documents at any
34 time. It is inappropriate to use Internet-Drafts as reference
35 material or to cite them other than as "work in progress."
37 The list of current Internet-Drafts can be accessed at
38 http://www.ietf.org/ietf/1id-abstracts.txt
40 The list of Internet-Draft Shadow Directories can be accessed at
41 http://www.ietf.org/shadow.html
43 This Internet-Draft will expire on March 17, 2016.
45 Copyright Notice
47 Copyright (c) 2015 IETF Trust and the persons identified as the
48 document authors. All rights reserved.
50 This document is subject to BCP 78 and the IETF Trust's Legal
51 Provisions Relating to IETF Documents
52 (http://trustee.ietf.org/license-info) in effect on the date of
53 publication of this document. Please review these documents
54 carefully, as they describe your rights and restrictions with respect
55 to this document.
57 Table of Contents
59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
60 1.1. Conventions used in this document . . . . . . . . . . . . . 4
61 1.2. Glossary . . . . . . . . . . . . . . . . . . . . . . . . . 4
62 2. Task Architecture . . . . . . . . . . . . . . . . . . . . . . . 5
63 2.1. Task Architecture Elements . . . . . . . . . . . . . . . . 7
64 2.2. Architecture Foundations . . . . . . . . . . . . . . . . . 8
65 3. Task Extensions . . . . . . . . . . . . . . . . . . . . . . . . 9
66 3.1. Task Specification . . . . . . . . . . . . . . . . . . . . 9
67 3.1.1. STRUCTURED-CATEGORY for task type identification . . . 9
68 3.1.2. Task Context and Relationships . . . . . . . . . . . . 10
69 3.1.3. Task Domain Data Handling . . . . . . . . . . . . . . . 10
70 3.2. Task Deadlines, Milestones and Time Planning . . . . . . . 11
71 3.3. Task Scheduling and Assignment . . . . . . . . . . . . . . 11
72 3.4. Status Reporting . . . . . . . . . . . . . . . . . . . . . 12
73 3.4.1. Improved granularity in status reporting information . 12
74 3.4.2. Relating comments to status . . . . . . . . . . . . . . 12
75 3.4.3. Comments associated to reasons and status changes . . . 12
76 3.4.4. Task Alerts and Notifications . . . . . . . . . . . . . 12
77 3.4.5. Automated Status Changes . . . . . . . . . . . . . . . 13
78 4. New Property Parameters . . . . . . . . . . . . . . . . . . . . 13
79 4.1. Reason . . . . . . . . . . . . . . . . . . . . . . . . . . 13
80 4.2. Modified . . . . . . . . . . . . . . . . . . . . . . . . . 14
81 4.3. Sub-State . . . . . . . . . . . . . . . . . . . . . . . . . 14
82 5. New Parameter Values . . . . . . . . . . . . . . . . . . . . . 15
83 5.1. Redefined VTODO Participant Status . . . . . . . . . . . . 15
84 6. New Properties . . . . . . . . . . . . . . . . . . . . . . . . 15
85 6.1. Estimated Duration . . . . . . . . . . . . . . . . . . . . 15
86 6.2. Task Mode . . . . . . . . . . . . . . . . . . . . . . . . . 16
87 6.2.1 AUTOMATIC-COMPLETION Task Mode . . . . . . . . . . . . . 17
88 6.2.2 AUTOMATIC-FAILURE Task Mode . . . . . . . . . . . . . . 17
89 6.2.3 CLIENT Task Mode . . . . . . . . . . . . . . . . . . . . 18
90 6.2.4 SERVER Task Mode . . . . . . . . . . . . . . . . . . . . 18
91 7. Property Extensions and Clarifications . . . . . . . . . . . . 18
92 7.1. The ATTENDEE property . . . . . . . . . . . . . . . . . . . 18
93 7.2. Redefined COMMENT Property Parameter List . . . . . . . . . 19
94 7.3. Redefined STATUS Property . . . . . . . . . . . . . . . . . 19
95 8. CalDAV Support for Task Mode . . . . . . . . . . . . . . . . . 20
96 8.1. CALDAV:supported-task-mode-set Property . . . . . . . . . . 21
97 9. Security Considerations . . . . . . . . . . . . . . . . . . . . 21
98 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21
99 10.1. The Status registry . . . . . . . . . . . . . . . . . . . 21
100 10.1.1 Initialization of the Status registry . . . . . . . . . 21
101 10.1.2 Update of the Status registry . . . . . . . . . . . . . 22
102 10.2. Sub-State value registry . . . . . . . . . . . . . . . . . 22
103 10.3. Task Mode value registry . . . . . . . . . . . . . . . . . 23
104 10.4. Participation Statuses registry . . . . . . . . . . . . . 23
105 10.5. Properties registry . . . . . . . . . . . . . . . . . . . 23
106 10.6. Parameters registry . . . . . . . . . . . . . . . . . . . 24
107 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 24
108 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 25
109 12.1. Normative References . . . . . . . . . . . . . . . . . . . 25
110 12.2. Informative References . . . . . . . . . . . . . . . . . . 25
111 Appendix A. Examples of Task State Lifecycle . . . . . . . . . . . 27
112 A.1. Simple Case Status Change . . . . . . . . . . . . . . . . . 27
113 A.2. Example for multiple Attendees . . . . . . . . . . . . . . 27
114 A.3. Failed Example . . . . . . . . . . . . . . . . . . . . . . 28
115 Appendix B. Working Notes . . . . . . . . . . . . . . . . . . . . 29
116 B.1. Advertising tasks . . . . . . . . . . . . . . . . . . . . . 29
117 B.2. Subscribing to task updates . . . . . . . . . . . . . . . . 29
118 Appendix C. Change Log . . . . . . . . . . . . . . . . . . . . . . 30
119 V01. 2015-08-23 AA . . . . . . . . . . . . . . . . . . . . . . . . 30
120 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 31
122 1. Introduction
124 This document specifies extensions to the existing Internet
125 Calendaring and Scheduling Core Object Specification (iCalendar)
126 [RFC5545], and associated protocols, in order to enhance the
127 structured communication and execution of tasks. The enhancements
128 allow for the communication, time planning and scheduling of tasks by
129 and between automated systems (e.g. in smart power grids, business
130 process management systems) as well as for human centered tasks.
132 A "task" is a representation of an item of work assigned to an
133 individual or organization. In the iCalendar Object Model [RFC5545]
134 the representation of tasks is by "VTODO" calendar components. Tasks
135 can be identified in a number of situations, either informally as
136 ad-hoc tasks in personal "to-do" lists or more formally in:
138 o Business processes - ranging from repetitive workflows to adaptive
139 cases and trouble ticketing
141 o Project Management - whether for large scale construction projects
142 or collaborative software development
144 The extensions specified here are defined in the context of an
145 overall architecture for task calendaring and scheduling.
147 1.1. Conventions used in this document
149 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
150 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
151 document are to be interpreted as described in RFC-2119 [RFC2119].
153 1.2. Glossary
155 The following calendaring and scheduling terms are applied throughout
156 this document:
158 o Assignee - A calendar user assigned to perform a given task. An
159 assignee is equivalent to an attendee of an event.
161 o Calendar User (CU) - A person or software system that accesses or
162 modifies calendar information.
164 o Calendar User Agent (CUA) - (1) Software with which the calendar
165 user communicates with a calendar service or local calendar store
166 to access calendar information. (2) Software that gathers
167 calendar data on the Calendar User's behalf.
169 o Candidate - A calendar user who might be able to perform a given
170 task, prior to actually being assigned the task, e.g., a
171 dispatcher has a list of taxi drivers (candidates) from which one
172 will be selected to pick-up a passenger.
174 o Organizer - A calendar user who creates a calendar item, requests
175 free/busy information, or published free/busy information. It is
176 an Organizer who invites Attendees [RFC5545].
178 o Observer - A calendar user interested in a calendar component,
179 e.g., a manager may have interest in all tasks that have not been
180 completed.
182 o Resource - A resource in the scheduling context is any shared
183 entity that can be scheduled by a calendar user, but does not
184 control its own attendance status. Resources can be of "Location",
185 "Equipment", or "Role" type.
187 o Task - A representation of an item of work that can be assigned to
188 one or more task actor assignees. In [RFC5545], these are "VTODO"
189 calendar components, which are groupings of component properties
190 and possibly "VALARM" calendar components that represent an
191 action-item or assignment.
193 2. Task Architecture
195 A reference architecture for task calendaring and scheduling is
196 defined in order to identify the key logical elements involved in
197 task management and the interfaces between them to enable
198 interoperability. The logical elements identified here establish an
199 appropriate separation of concerns and clarify the responsibilities
200 of different elements. However, the architecture does not prescribe a
201 binding or packaging of elements, i.e., software systems may be
202 developed where some elements are tightly bound and the interfaces
203 between bound elements are not exposed. The task architecture is also
204 described in [TARCH].
206 Task +-------+
207 Trigger |
208 +---------------------V---------------------+ +-----------+
209 | Task Generating System | | |
210 | +-------------------------+ | | |
211 | | O | | | |
212 | | /|\ | | | |
213 | | / \ | | | |
214 | | Task Organizer | <----> |
215 | +-^--------^--------------+ | | |
216 | | | | | |
217 | +--------V-+ +----V-----+ +----------+ | | |
218 | | Task | | Process | | Task | | | |
219 | |Assignment| | Logic <----> Domain | | | |
220 | | Rules | | | | Data | | | |
221 | +----------+ +----------+ +----------+ | | |
222 | | | |
223 +------^----------+-----^-------------------+ | |
224 | | | | |
225 Availability Task Task | |
226 | | Status | |
227 | | | | |
228 +------v----------v-----+-------------------+ | |
229 | Calendar and Scheduling System | | Directory |
230 | +---------+ +---------+ | | Service |
231 | | | | Task | <----> |
232 | |Schedule | | Lists | | | |
233 | | | | | | | |
234 | +---------+ +---------+ Server | | |
235 +-------------------------------------------+ | |
236 | Client | | |
237 | +----------------------+ +-----------+ | | |
238 | | Calendar | | Task | | | |
239 | | User Agent +----> Specific | <----> |
240 | | | |Application| | | |
241 | +----------------------+ +-----------+ | | |
242 | | | |
243 +-----^---------^--------+---------+--------+ | |
244 | | | | | |
245 +-----V---------V--------V---------V--------+ | |
246 | Task Actors | | |
247 | O O O O | | |
248 | /|\ /|\ /|\ /|\ +----> |
249 | / \ / \ / \ / \ | | |
250 | Candidate(s) Observer(s) | | |
251 | Assignee(s) Resource(s) | | |
252 +-------------------------------------------+ +-----------+
254 2.1. Task Architecture Elements
256 The following logical elements form the task architecture that this
257 specification is based on:
259 o Task Actors - Various calendar users that may be involved in the
260 monitoring or performing of a task. The set of actors includes:
261 Organizers, Observers, Resources, Assignees, and Candidates.
263 o Task Organizer - The Organizer of a task.
265 o Task Domain Data - This is any domain specific data that may be
266 acted on or provides context to it in performing a task.
268 o Task Specific Application - A task specific application renders
269 the data concerning the task (including task domain data) for
270 presentation and manipulation by a task actor.
272 o Process Logic - Process logic determines under what conditions a
273 task (or tasks) is generated and the actions to take on
274 completion, or some other status event occurring (or not) on the
275 task.
277 o Task Trigger - This is some event that gives rise to the
278 generation of a task according to Process Logic. Task triggers can
279 come from many different sources including, for example; a task
280 being requested through the calendaring system, a status change in
281 the progression of a business process being managed by a business
282 process management or ERP system.
284 o Task Assignment Rules - Rules that govern how actors are assigned
285 to a task. A range of different assignment patterns [WfRP] may be
286 considered, including the two general cases:
288 1. Delegation to a named actor or group of actors
290 2. Advertising to a pool of actors for self-selection
292 In either case the assignment may be made based on a variety of
293 criteria including, name, availability, skills, capacity, etc.
295 o Task Generating System - A system that creates and assigns tasks
296 in response to some initiating event (task trigger). Task creation
297 is according to Process Logic with task assignment determined by
298 Task Assignment Rules. This system also tracks the status of tasks
299 and will initiate further actions based upon the status. A task
300 generating system can take many forms, for example; Business
301 Process Management System, Project Management System, Bug Tracking
302 System, Building Control System. A Task Generating System may also
303 be a human. In iCalendar terms the Task Generating System is the
304 organizer.
306 o Human Task Generation - Task creation, assignment and tracking
307 coordinated by a human organizer is a special case of a task
308 generating system. In this case Task Assignment Rules and Process
309 Logic may be either explicit or tacit.
311 o Directory Service - A software system that stores and provides
312 access to information providing details of task actors that may
313 participate or be interested in a task.
315 o Calendar and Scheduling System - A software system that stores,
316 publishes and synchronizes calendar data such as events, tasks and
317 journal entries for actors. In the context of tasks this includes
318 schedules (i.e. allocated time and availability to perform tasks)
319 and task lists. A calendar and scheduling system typically
320 consists of server and client software components.
322 It is not within the scope of this document to specify how Process
323 Logic or Task Assignment Rules are codified. Such logic and rules may
324 be codified in a variety of ways, including traditional programming
325 languages (e.g. C++, Java) or process modelling languages (e.g. BPMN
326 [BPMN]).
328 2.2. Architecture Foundations
330 The key standards that enable interoperability between the logical
331 elements of the architecture are the Internet Calendaring and
332 Scheduling Core Object Specification (iCalendar) [RFC5545] and
333 associated protocols. Task and task status are represented by the
334 iCalendar "VTODO" component. Protocols include, in particular, the
335 iCalendar Transport-Independent Interoperability Protocol (iTIP)
336 [RFC5546] for task assignment and scheduling, and Calendaring
337 Extensions to WebDAV (CalDAV) [RFC 4791] for client server
338 communication.
340 Additionally, other iCalendar extensions embraced by this
341 specification include:
343 o Support for iCalendar Relationships [Doug114] - The LINK, REFID,
344 RELATED-TO and STRUCTURED-CATEGORY properties enable context and a
345 rich set of relationships between tasks and other iCalendar
346 components to be specified.
348 o Event Publishing Extensions to iCalendar [Doug214] - The GROUP
349 parameter specifically enables the grouping of properties
350 associated with specific status changes of a task.
352 3. Task Extensions
354 In order to support the task architecture described in section 3,
355 this document defines a number of extensions to the current iCalendar
356 standards in the areas of:
358 o Task Specification - improved ability to specify domain specific
359 tasks
361 o Task Deadlines, Milestones and Time Planning - clarification of
362 deadlines and extension for task duration to support task time
363 planning
365 o Task Scheduling and Assignment - ensure support for common pattens
366 of scheduling and assigning tasks
368 o Task Status Tracking - improved granularity in status tracking
369 information and alerting task actors to pending or actual task
370 status changes
372 These extensions are supported mainly by additions to the properties
373 and parameters used within the "VTODO" component.
375 3.1. Task Specification
377 The specification of tasks must be semantically explicit in order for
378 them to be managed within the context of a business process or
379 project, and be understood by both humans and IT systems. The current
380 VTODO component only provides for simple ad-hoc tasks or 'to do'
381 lists, and is therefore extended by this specification as follows:
383 o Task type - explicitly what type of task is to be performed is
384 identified.
386 o Task context and relationships - how a specific task relates to
387 other tasks and other objects that need to be understood for the
388 effective execution of a task.
390 o Task specific data - the form and content of domain data provided
391 as input to a task and/or that may be output from a task.
393 o Organizer and attendee - recognizes that a task organizer or
394 attendee can be an automated system.
396 3.1.1. STRUCTURED-CATEGORY for task type identification
397 The STRUCTURED-CATEGORY property is used to identify the type of
398 task, for example;
400 STRUCTURED-CATEGORY:http://example.com/task/delivery
402 3.1.2. Task Context and Relationships
404 The LINK property specifies a link to external information, which may
405 be context to the task. For example:
407 LINK;REL=SOURCE:http://example.com/package/1234567890
409 LINK;REL=describedby:mid:752142.1414823874.307E5@mx123.example.com
411 The external information may be data to be manipulated in performing
412 the task. See section 3.1.3 Task Domain Data Handling.
414 REFID is used to identify a key allowing the association of tasks
415 that are related to the same object and retrieval of a task based on
416 this key. This may be, for example, to identify the tasks associated
417 with a given project without having to communicate the task structure
418 of the project, or all tasks associated to a specific package.
420 REFID:Manhattan
422 REFID:1234567890
424 Extensions [Doug114] to the RELATED-TO property allow temporal
425 relationships between tasks as found in project management to be
426 specified as well as parent / child relationships and dependencies
427 (DEPENDS-ON). Tasks (VTODOs) may also be related to other calendar
428 components; for example to a VEVENT to block time to perform a task.
430 3.1.3. Task Domain Data Handling
432 Provide support for task specific input and output data (including
433 updates) beyond the standard iCalendar properties. It is envisaged
434 that standard calendar user agents will be able to launch task
435 specific applications by passing task specific data.
437 The LINK property can be used to 'attach' the domain specific data to
438 the task. For example, it might be a URI pointing to a web page where
439 the status of the task can be directly manipulated.
441 LINK;REL="vacation-system";VALUE=URI:http://example.com/
442 vacation-approval?id=1234
444 Or it might be used for attachments specific to the task, for example
445 an electronic copy of a signature taken to confirm delivery of a
446 package.
448 LINK;REL="electronic-signature";VALUE=URI:http://example.com/
449 delivery/sig1234.jpg
451 3.2. Task Deadlines, Milestones and Time Planning
453 Deadlines for starting and finishing a task are defined by the
454 DTSTART, DUE and DURATION properties. DTSTART represents the earliest
455 start time for beginning work on a task. DUE, or DTSTART + DURATION
456 represent the latest finish time for a task. Thus these properties
457 define a "window" within which a task has to be performed. However,
458 there is currently no way to indicate how long the task is expected
459 to take. This document defines a new property, ESTIMATED-DURATION, to
460 allow the estimated time that a task should take to be specified
461 separately from the deadlines for starting and finishing a task. This
462 supports time planning by enabling calendar user agents to display
463 when tasks should occur and therefore allow calendar users to
464 visualize when tasks should be performed and allocate time to them.
466 A task that has intermediary deadlines (i.e., milestones) SHOULD be
467 expressed by child VTODO components (i.e., sub-tasks associated with
468 each of the milestones) in conjunction with the RELATED-TO property
469 to relate the parent and child tasks.
471 3.3. Task Scheduling and Assignment
473 This specification supports the two distinct models of assigning
474 actors to tasks, i.e., 1) strictly one assignee per task or 2) task
475 assignment to multiple assignees. In this regard one or many
476 ATTENDEES may be specified against a task depending upon the model
477 applied by the task organizer.
479 In addition a number of different patterns of resource or assignee
480 identification are anticipated. The specific Task Assignment Rules
481 are the responsibility of the Task Organizer.
483 Communication of task assignment or delegation to one or more actors
484 who are allocated to a task by the organizer is directly supported by
485 iTIP, i.e., all included ATTENDEES in an iTIP REQUEST are expected to
486 perform the task.
488 The offering or advertising of a task to one or more (potential)
489 actors where only one or a subset of the candidates may accept the
490 task will be addressed by a new VPOLL mode (See Appendix B) [VPOLL].
492 3.4. Status Reporting
494 3.4.1. Improved granularity in status reporting information
496 This document defines new status parameters that can be applied to
497 the VTODO status (STATUS) property, as well as the participant status
498 (PARTSTAT) parameter. These new parameters provide additional
499 information on why (REASON) and when (MODIFIED) a status has changed.
500 In addition to these parameters new status values are specified to
501 provide for task suspension, failure and preparation.
503 3.4.2. Relating comments to status
505 The GROUP parameter is used with the STATUS or ATTENDEE properties to
506 relate an associated COMMENT property. The COMMENT property can then
507 be used to include additional human readable information about why
508 the associated STATUS or ATTENDEE property changed.
510 STATUS;REASON="http://example.com/reason/delivery-failed";SUBSTATE
511 =ERROR;MODIFIED=20130212T120000Z;GROUP=G1:FAILED
512 COMMENT;MODIFIED=20130226T110451Z;GROUP=G1:Breakdown
514 ATTENDEE;PARTSTAT=FAILED;MODIFIED=20130226T1104510Z;GROUP=G2:
515 REASON="http://example.com/reason/van-break-down":mailto:
516 xxx@example.com
517 COMMENT;MODIFIED=20130226T110451Z;GROUP=G2:Puncture
519 3.4.3. Comments associated to reasons and status changes
521 Reasons may be associated directly with a comment, allowing for
522 multiple reasons associated with a status to each have a comment
523 associated with them [EDISTS].
525 STRUCTURED-CATEGORY:http://example.com/task/delivery
526 STATUS;SUBSTATE=ERROR;MODIFIED=20130212T120000Z;GROUP=G1:FAILED
527 COMMENT;MODIFIED=20130226T110451Z;GROUP=G1:Out of time
529 COMMENT;REASON="http://example.com/reason/traffic";MODIFIED=
530 20130226T110451Z;GROUP=G1:Traffic Accident on E44
532 COMMENT;REASON="http://example.com/reason/closed";MODIFIED=
533 20130226T110451Z;GROUP=G1:Arrived after office hours
535 3.4.4. Task Alerts and Notifications
537 Different needs to alert or notify task actors of pending or actual
538 task status changes are recognized:
540 o Alarms - Alarms (VLARM components) operate in the calendar user
541 agent space to notify the task actor of a pending task state for a
542 task they are assigned to or are interested in. Note: there is no
543 constraint in the current standards on the propagation of alarms
544 specified on calendar objects by organizers to individual
545 attendees.
547 o Escalations - An escalation or notification to the ATTENDEE,
548 ORGANIZER, or other task actor may be required if a deadline
549 associated with a task is exceeded or for some other reason.
550 Process Logic identifying when and who to propagate escalations to
551 is the responsibility of the Task Generating System, e.g., a BPMS.
553 o Notifications - Task actors (observers) not directly involved in
554 performing a task but with a known interest in a given task's
555 status can be identified by the ASSOCIATE property [Doug214]
556 against certain components e.g. ALARM, to identify which task
557 events the stakeholder / party is interested in. Notifications on
558 shared calendars will allow task actors to register an interest in
559 changes to tasks within a calendar (see Appendix B.2).
561 3.4.5. Automated Status Changes
563 A new property, TASK-MODE, is introduced to instruct servers to apply
564 automated operations for changing the status of a task.
566 4. New Property Parameters
568 4.1. Reason
570 Parameter name: REASON
572 Purpose: To indicate the reason for a change in status of a task or
573 attendee participation status.
575 Format Definition: This parameter is defined by the following
576 notation:
578 reasonparam = "REASON" "=" DQUOTE uri DQUOTE
579 *("," DQUOTE uri DQUOTE)
581 Description: This property parameter allows the change in status of
582 a task or participant status to be qualified by the reason for the
583 change with a codified reason. Typically reasons are defined within
584 the context of the task type and therefore SHOULD include the name-
585 space of the authority defining the task. Common reason codes are
586 IANA registered and do not have a name-space prefix.
588 Example:
590 STATUS;REASON="http://example.com/reason/delivered-on-time";
591 MODIFIED=20130212T120000Z;GROUP=G1:COMPLETED
593 ATTENDEE;REASON="x-example-reason:out-of-office";PARTSTAT=
594 DECLINED;MODIFIED=20130212T120000Z;GROUP=123:mailto:
595 cyrus@example.com
597 4.2. Modified
599 Parameter name: MODIFIED
601 Purpose: To specify the time and date of when the status of a task
602 or attendee participant status changed.
604 Format Definition: This parameter is defined by the following
605 notation:
607 modifiedparam = "MODIFIED" "=" date-time
609 Description: The modified parameter allows the specification of the
610 date time of when a status (STATUS) or participant status (PARTSTAT)
611 changed. It MUST be specified in the UTC time format. The value of
612 MODIFIED SHOULD be set at the time when the associated status (either
613 STATUS or PARTSTAT)is changed. Therefore either a client or server
614 may set the value of MODIFIED depending on which is updating the
615 value of STATUS or PARTSTAT. For backwards compatibility if the
616 server detects that MODIFIED should have changed but wasn't (for
617 example the client doesn't support MODIFIED) then the server MAY set
618 MODIFIED retrospectively.
620 Example:
622 STATUS;REASON=""http://example.com/reason/delivered-on-time";
623 MODIFIED=20130212T120000Z;GROUP=G1:COMPLETED
625 4.3. Sub-State
627 Parameter name: SUBSTATE
629 Purpose: To provide additional granularity of task status for e.g.
630 IN-PROCESS.
632 Format Definition: This parameter is defined by the following
633 notation:
635 substateparam = "SUBSTATE" "="
636 ( "OK" ; everything is fine(the default)
637 / "ERROR" ; something is wrong (the REASON
638 ; code explains why)
639 / "SUSPENDED" ; waiting on some other task to
640 ; complete or availability of a
641 ; resource (REASON code explains
642 ; why)
643 / x-name ; Experimental type
644 / iana-token) ; Other IANA-registered type
646 Description: The sub-state parameter allows additional qualification
647 and granularity of states to be recorded, in particular for the IN-
648 PROCESS state. It allows individual sub-states to be recorded without
649 the need to define and publish a sub-task associated with a parent
650 task purely to track that a particular state has been reached. This
651 property also allows parallel states to be expressed e.g. that a task
652 has been suspended at whatever state it has reached.
654 Example:
656 STATUS;REASON="http://example.com/reason/no-one-home";SUBSTATE=
657 ERROR:FAILED
658 STATUS;REASON="http://example.com/reason/paint-drying";SUBSTATE=
659 SUSPENDED:IN-PROCESS
661 5. New Parameter Values
663 5.1. Redefined VTODO Participant Status
665 Participant status parameter type values are defined in section
666 3.2.12. of [RFC5545]. This specification redefines that type to
667 include the new value FAILED for VTODO iCalendar components.
669 Format Definition: This property parameter is extended by the
670 following notation:
672 partstat-todo /= *("FAILED") ; To-do cannot be completed
674 Example:
676 ATTENDEE;REASON="http://example.com/reason/not-enough-time";
677 PARTSTAT=FAILED:mailto:jsmith@example.com
679 6. New Properties
681 6.1. Estimated Duration
683 Property Name: ESTIMATED-DURATION
684 Purpose: This property specifies the estimated positive duration of
685 time the corresponding task will take to complete.
687 Value Type: DURATION
689 Property Parameters: IANA and non-standard property parameters can
690 be specified on this property.
692 Conformance: This property can be specified in "VTODO" calendar
693 components.
695 Format Definition: This property is defined by the following
696 notation:
698 est-duration = "ESTIMATED-DURATION" durparam ":" dur-value CRLF
699 ;consisting of a positive duration of time.
701 durparam = *(";" other-param)
703 Description: In a "VTODO" calendar component the property MAY be
704 used to specify the estimated duration for the to-do, with or without
705 an explicit time window in which the event should be started and
706 completed. When present, DTSTART and DUE/DURATION represent the
707 window in which the task can be performed. ESTIMATED-DURATION SHOULD
708 be passed from ORGANIZER to ATTENDEE in iTIP [RFC5546] messages.
710 Example: The following is an example of this property that specifies
711 an interval of time of exactly one hour:
713 ESTIMATED-DURATION:PT1H
715 6.2. Task Mode
717 Property Name: TASK-MODE
719 Purpose: This property specifies automatic operations that servers
720 apply to tasks based on changes in attendee status (PARTSTAT).
722 Value Type: TEXT
724 Property Parameters: IANA and non-standard property parameters can
725 be specified on this property.
727 Conformance: This property can be specified zero or more times in a
728 "VTODO" calendar component.
730 Format Definition: This property is defined by the following
731 notation:
733 task-mode = "TASK-MODE taskmodeparam ":" taskvalue
734 *("," taskvalue) CRLF
736 taskvalue = "AUTOMATIC-COMPLETION" ; set STATUS completed
737 ;if all attendees have completed
738 / "AUTOMATIC-FAILURE"
739 / "SERVER"
740 / "CLIENT"
741 / iana-token
742 / x-name
744 taskmodeparam = *(";" other-param)
746 Description: In a "VTODO" calendar component this property MAY be
747 used to indicate to servers how they can automatically change the
748 state of the task based on iTIP replies from Attendees. For example,
749 the server can automatically set the overall task status (STATUS) to
750 COMPLETED when every attendee has marked their own status (PARTSTAT)
751 as COMPLETED, or the server could mark the task as FAILED if its DUE
752 date passes without it being completed. TASK-MODE processing is
753 performed on the organizer's copy of the task.
755 The property value is a list of one or more IANA registered tokens
756 that defines modes to be used for the task. This specification
757 defines three modes which are described in the following sub-
758 sections.
760 Examples:
762 TASK-MODE:AUTOMATIC-COMPLETION,AUTOMATIC-FAILURE
763 TASK-MODE:SERVER
764 TASK-MODE:AUTOMATIC-FAILURE
766 6.2.1 AUTOMATIC-COMPLETION Task Mode
768 The task mode value "AUTOMATIC-COMPLETION" indicates to the server
769 that it can change the "VTODO" component's STATUS property value to
770 "COMPLETED" as soon as all ATTENDEEs in the task have replied with a
771 "PARTSTAT" parameter set to "COMPLETED".
773 6.2.2 AUTOMATIC-FAILURE Task Mode
775 The task mode value "AUTOMATIC-FAILURE" indicates to the server that
776 it SHOULD change the "VTODO" component's STATUS property value to
777 "FAILED" if either:
779 o the PARTSTAT of one ATTENDEE is set to FAILED; or
780 o the current time is past the effective due date of the component
781 and the task has not yet been completed.
783 Note: The effective due date is either the "DUE" property value or
784 the combination of the "DTSTART" and "DURATION" property values.
786 6.2.3 CLIENT Task Mode
788 The task mode value "CLIENT" is an instruction to the server to
789 honour the status set by the client.
791 6.2.4 SERVER Task Mode
793 The task mode value "SERVER" indicates to the server that it can
794 change the "VTODO" component's STATUS property value to an
795 appropriate value, based on implementation defined "business rules",
796 as ATTENDEE responses are processed or as deadlines related to the
797 task pass.
799 The server can add this property to a "VTODO" component to indicate
800 to the client that it will be managing the status.
802 7. Property Extensions and Clarifications
804 7.1. The ATTENDEE property
806 The Attendee property is defined in section 3.8.4.1. of [RFC5545].
807 This specification extends that property to include new parameters to
808 indicate the reason for a participant status change (See Appendix A)
809 and sub-states.
811 Format Definition: This property is defined by the following
812 notation:
814 attendee = "ATTENDEE" attparam ":" cal-address CRLF
816 attparam /= *(
817 ;
818 ; The following are OPTIONAL,
819 ; but MUST NOT occur more than once.
820 ;
821 (";" reasonparam)
822 (";" modifiedparam)
823 (";" substateparam)
824 )
826 Example: The following are examples of this property's use for tasks:
828 ATTENDEE;PARTSTAT=DECLINED;MODIFIED=20130212T120000Z;GROUP=G1;
829 REASON="http://example.com/reason/too-busy":
830 mailto:xxx@example.com
832 ATTENDEE;PARTSTAT=IN-PROCESS;MODIFIED=20130212T120000Z;
833 SUBSTATE=X-EXAMPLE-STEP-1:mailto:xxx@example.com
835 7.2. Redefined COMMENT Property Parameter List
837 The Comment property is defined in section 3.8.1.4. of [RFC5545].
839 Format Definition: The "COMMENT" property parameter list is
840 augmented as follows:
842 commparam /= *(
843 ; The following are OPTIONAL,
844 ; but MUST NOT occur more than once.
845 (";" reasonparam) /
846 (";" modifiedparam)
847 )
849 7.3. Redefined STATUS Property
851 The Status property is defined in section 3.8.1.11. of [RFC5545].
852 This specification extends that property to include new parameters to
853 indicate the reason for a status change as well as new values
854 associated with VTODO iCalendar components (See Appendix A for
855 examples of the task state lifecycle).
857 Format Definition: The "STATUS" property parameter list is augmented
858 as follows:
860 statparam /= *(
861 ; The following are OPTIONAL,
862 ; but MUST NOT occur more than once.
863 ;
864 (";" reasonparam)
865 (";" modifiedparam)
866 (";" substateparam) /
867 )
869 statvalue-todo = / "PENDING" ;Indicates a to-do has been
870 ;created and accepted, but has not
871 ;yet started.
872 / "FAILED" ;Indicates to-do has failed.
873 ;Extended status values for
874 ;"VTODO".
876 Description:
878 PENDING - A task has been created but has not yet started and is
879 ready to start subject to other dependencies (e.g. preceding task or
880 DTSTART). This is the default state.
882 FAILED - task has failed and may need some follow-up from the
883 organizer to re-schedule or cancel
885 Example: The following is an example of this property for a "VTODO"
886 calendar component:
888 STATUS;REASON="http://example.com/reason/delivery-failed";SUBSTATE
889 =ERROR;MODIFIED=20130212T120000Z;GROUP=G1:FAILED
891 8. CalDAV Support for Task Mode
893 The CalDAV [RFC4791] calendar access protocol allows clients and
894 servers to exchange iCalendar data. With the introduction of the
895 "TASK-MODE" property in this specification, different automated task
896 management behaviours may be delegated to the server by the Task
897 Organizer depending upon the value of "TASK-MODE".
899 In order for a CalDAV client to know what task modes are available, a
900 CalDAV server advertises a CALDAV:supported-task-mode-set WebDAV
901 property on calendar home or calendar collections if it supports the
902 use of the "TASK-MODE" property as described in this specification.
903 The server can advertise a specific set of supported task modes by
904 including one or more CALDAV:supported-task-mode XML elements within
905 the CALDAV:supported-task-mode-set XML element. If no
906 CALDAV:supported-task-mode XML elements are included in the WebDAV
907 property, then clients can try any task mode, but need to be prepared
908 for a failure when attempting to store the calendar data.
910 Clients MUST NOT attempt to store iCalendar data containing "TASK-
911 MODE" elements if the CALDAV:supported-task-mode-set WebDAV property
912 is not advertised by the server.
914 The server SHOULD return an HTTP 403 response with a DAV:error
915 element containing a CALDAV:supported-task-mode XML element, if a
916 client attempts to store iCalendar data with an "TASK-MODE" element
917 value not supported by the server.
919 It is possible for a "TASK-MODE" value to be present in calendar data
920 on the server being accessed by a client that does not support the
921 "TASK-MODE" property. It is expected that existing clients, unaware
922 of "TASK-MODE", will fail gracefully by ignoring the calendar
923 property.
925 8.1. CALDAV:supported-task-mode-set Property
927 Name: supported-task-mode-set
929 Namespace: urn:ietf:params:xml:ns:caldav
931 Purpose: Enumerates the set of supported iCalendar "TASK-MODE"
932 element values supported by the server.
934 Protected: This property MUST be protected and SHOULD NOT be
935 returned by a PROPFIND allprop request (as defined in Section 14.2 of
936 [RFC4918]).
938 Description: See above.
940 Definition:
942
943
944
947 Example:
949
951 AUTOMATIC-COMPLETION
952 AUTOMATIC-FAILURE
953 SERVER
954 CLIENT
955
957 9. Security Considerations
959 This specification introduces no new security considerations beyond
960 those identified in RFC 5545.
962 10. IANA Considerations
964 10.1. The Status registry
966 10.1.1 Initialization of the Status registry
968 This specification updates [RFC5545] by adding a Status value
969 registry to the iCalendar Elements registry and initializing it as
970 per [RFC5545].
972 +--------------+---------+------------------------------+
973 | Status | Status | Reference |
974 +--------------+---------+------------------------------+
975 | CANCELLED | Current | [RFC5545], Section 3.8.1.11. |
976 | | | |
977 | COMPLETED | Current | [RFC5545], Section 3.8.1.11. |
978 | | | |
979 | CONFIRMED | Current | [RFC5545], Section 3.8.1.11. |
980 | | | |
981 | DRAFT | Current | [RFC5545], Section 3.8.1.11. |
982 | | | |
983 | FINAL | Current | [RFC5545], Section 3.8.1.11. |
984 | | | |
985 | IN-PROCESS | Current | [RFC5545], Section 3.8.1.11. |
986 | | | |
987 | NEEDS-ACTION | Current | [RFC5545], Section 3.8.1.11. |
988 | | | |
989 | TENTATIVE | Current | [RFC5545], Section 3.8.1.11. |
990 +--------------+---------+------------------------------+
992 10.1.2 Update of the Status registry
994 This specification further updates the Status registry with
995 additional values defined in this document.
997 +-----------+---------+-------------------------+
998 | Status | Status | Reference |
999 +-----------+---------+-------------------------+
1000 | PENDING | Current | This Spec, Section 7.3. |
1001 | | | |
1002 | FAILED | Current | This Spec, Section 7.3. |
1003 +-----------+---------+-------------------------+
1005 10.2. Sub-State value registry
1007 The following table has been used to initialize the Sub-State
1008 registry.
1010 +-----------+---------+-------------------------+
1011 | Substate | Status | Reference |
1012 +-----------+---------+-------------------------+
1013 | OK | Current | This Spec, Section 4.3. |
1014 | | | |
1015 | ERROR | Current | This Spec, Section 4.3. |
1016 | | | |
1017 | SUSPENDED | Current | This Spec, Section 4.3. |
1018 +-----------+---------+-------------------------+
1020 10.3. 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 6.2. |
1029 | | | |
1030 | AUTOMATIC-FAILURE | Current | This Spec, Section 6.2. |
1031 | | | |
1032 | CLIENT | Current | This Spec, Section 6.2. |
1033 | | | |
1034 | SERVER | Current | This Spec, Section 6.2. |
1035 +----------------------+---------+-------------------------+
1037 10.4. Participation Statuses registry
1039 The following table has been used to update the Participation
1040 Statuses registry.
1042 +-----------+---------+-------------------------+
1043 | Status | Status | Reference |
1044 +-----------+---------+-------------------------+
1045 | FAILED | Current | This Spec, Section 5.1. |
1046 +-----------+---------+-------------------------+
1048 10.5. Properties registry
1050 The following table has been used to update the Properties registry.
1052 +--------------------+---------+-------------------------+
1053 | Property | Status | Reference |
1054 +--------------------+---------+-------------------------+
1055 | ATTENDEE | Current | This Spec, Section 7.1. |
1056 | | | |
1057 | COMMENT | Current | This Spec, Section 7.2. |
1058 | | | |
1059 | ESTIMATED_DURATION | Current | This Spec, Section 6.1. |
1060 | | | |
1061 | STATUS | Current | This Spec, Section 7.3. |
1062 | | | |
1063 | TASK-MODE | Current | This Spec, Section 6.2. |
1064 +--------------------+---------+-------------------------+
1066 10.6. Parameters registry
1068 The following table has been used to update the Parameters registry.
1070 +-----------+---------+-------------------------+
1071 | Parameter | Status | Reference |
1072 +-----------+---------+-------------------------+
1073 | REASON | Current | This Spec, Section 4.1. |
1074 | | | |
1075 | MODIFIED | Current | This Spec, Section 4.2. |
1076 | | | |
1077 | SUBSTATE | Current | This Spec, Section 4.3. |
1078 +-----------+---------+-------------------------+
1080 11. Acknowledgements
1082 The authors would like to thank the members of the Calendaring and
1083 Scheduling Consortium technical committees and the following
1084 individuals for contributing their ideas, support and comments:
1086 John Chaffee, Marten Gajda, Ken Murchison
1088 The authors would also like to thank the Calendaring and Scheduling
1089 Consortium for advice with this specification.
1091 This document was prepared using Internet-Draft Nroff Editor.
1093 12. References
1095 12.1. Normative References
1097 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
1098 Requirement Levels", BCP 14, RFC 2119, March 1997.
1100 [RFC2234] Crocker, D. and Overell, P.(Editors), "Augmented BNF for
1101 Syntax Specifications: ABNF", RFC 2234, Internet Mail
1102 Consortium and Demon Internet Ltd., November 1997.
1104 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
1105 January 2004.
1107 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
1108 Resource Identifier (URI): Generic Syntax", STD 66, RFC
1109 3986, January 2005.
1111 [RFC4791] Daboo, C., Desruisseaux, B., and L. Dusseault,"Calendaring
1112 Extensions to WebDAV (CalDAV)", RFC 4791, March 2007.
1114 [RFC4918] Dusseault, L., "HTTP Extensions for Web Distributed
1115 Authoring and Versioning (WebDAV)", RFC 4918, June 2007.
1117 [RFC5545] Desruisseaux, B., "Internet Calendaring and Scheduling Core
1118 Object Specification (iCalendar)", RFC 5545, September
1119 2009.
1121 [RFC5546] Daboo, C., "iCalendar Transport-Independent
1122 Interoperability Protocol(iTIP)", RFC 5546, December 2009.
1124 [Doug114] Douglass, M., "Support for Icalendar Relationships", draft-
1125 douglass-ical-relations-04, January 14, 2015
1127 [Doug214] Douglass, M., "Event Publishing Extensions to iCalendar",
1128 draft-douglass-calendar-extension-04, February 1, 2014
1130 12.2. Informative References
1132 [BPMN] Object Management Group, Business Process Model and
1133 Notation, Version 2.0.2, December 2013,
1134 http://www.omg.org/spec/BPMN/
1136 [EDISTS] UN Economic Commission for Europe, UN/EDIFACT, D14.A, STS
1137 STATUS, April 30, 2014, http://www.unece.org/fileadmin/
1138 DAM/trade/untdid/d14a/trsd/trsdsts.htm
1140 [TARCH] Apthorp, A., Daboo, C., Douglass, M., CalConnect, Task
1141 Architecture V1.0,
1144 [VPOLL] York, E., Daboo, C., Douglass, M., "VPOLL: Consensus
1145 Scheduling Component for iCalendar", draft-york-vpoll-03,
1146 January 6, 2015, https://tools.ietf.org/html/draft-york-
1147 vpoll-03
1149 [WfRP] Russell, N., ter Hofstede, A.H.M., Edmond, T., van der
1150 Aalst,W.M.P., Workflow Resource Patterns, Eindhoven
1151 University of Technology, 2004,
1152
1154 [WSCal] Considine, T., Douglass, M., WS-Calendar Version 1.0,
1155 OASIS, 30 July 2011,
1159 [WSHT] Ings, D., Clement, L., Koenig, D., Mehta, V., Mueller, R.,
1160 Rangaswamy, R., Rowley, M., Trickovic, I., Web Services -
1161 Human Task Version 1.1 (WS-HumanTask), OASIS, 17 August
1162 2010,
1165 Appendix A. Examples of Task State Lifecycle
1167 A.1. Simple Case Status Change
1169 Example of status changes in assigning and performing a task with one
1170 attendee.
1172 STATUS PARTSTAT Action
1173 ------ -------- ------
1174 1. - - Organizer draft
1175 2. NEEDS-ACTION NEEDS-ACTION Organizer sends iTIP request
1176 3. NEEDS-ACTION ACCEPTED Attendee reply
1177 4. PENDING ACCEPTED Task accepted but waiting on some
1178 "trigger" to start (e.g. another
1179 task has to finish first)
1180 5. IN-PROCESS IN-PROCESS Attendee reply now working on the
1181 task
1182 6. IN-PROCESS COMPLETED Attendee reply completed
1183 7. COMPLETED COMPLETED Organizer changes overall state
1185 A.2. Example for multiple Attendees
1187 Example of status changes in assigning and performing a task with two
1188 attendees (A1 and A2).
1190 STATUS PARTSTAT (A1) PARTSTAT (A2) Action
1191 ------ ------------ ------------ ------
1192 1. - - - Organizer draft.
1193 2. NEEDS-ACTION NEEDS-ACTION NEEDS-ACTION Organizer sends
1194 iTIP request.
1195 3. NEEDS-ACTION ACCEPTED NEEDS-ACTION Attendee 1 reply.
1196 3. NEEDS-ACTION ACCEPTED ACCEPTED Attendee 2 reply.
1197 4. PENDING ACCEPTED ACCEPTED Task accepted but
1198 waiting on some
1199 "trigger" to start
1200 (e.g. another task
1201 has to finish
1202 first)
1203 5. IN-PROCESS ACCEPTED IN-PROCESS Attendee 2 reply
1204 now working on the
1205 task.
1206 5. IN-PROCESS IN-PROCESS IN-PROCESS Attendee 1 reply
1207 now working on the
1208 task.
1209 6. IN-PROCESS COMPLETED IN-PROCESS Attendee 1 reply
1210 Completed (overall
1211 status still
1212 IN-PROCESS).
1214 6. IN-PROCESS COMPLETED COMPLETED Attendee 2 reply
1215 Completed
1216 7. COMPLETED COMPLETED COMPLETED Organizer changes
1217 overall state once
1218 both attendees are
1219 finished.
1221 Note: The logic for determining the status change to the VTODO is
1222 determined by the task organizer based on the ATTENDEE status and
1223 other business logic.
1225 A.3. Failed Example
1227 Example of status changes for a task that fails.
1229 STATUS PARTSTAT Action
1230 ------ -------- ------
1231 1. - - Organizer draft
1232 2. NEEDS-ACTION NEEDS-ACTION Organizer sends iTIP request
1233 3. NEEDS-ACTION ACCEPTED Attendee reply
1234 4. IN-PROCESS IN-PROCESS Attendee reply now working on the
1235 task
1236 5. IN-PROCESS FAILED Attendee reply task failed
1237 6. FAILED FAILED Organizer changes overall state
1239 Appendix B. Working Notes
1241 B.1. Advertising tasks
1243 Use VPOLL for advertising a task to a pool of possible ATTENDEEs and
1244 then select the respondent to assign one or more assignees.
1246 Introduce POLL-MODE:ASSIGNMENT
1248 Need to indicate number of assignees required.
1250 Potentially different types of response e.g. ACCEPT or DECLINE, or a
1251 weighting e.g. 0 - 100
1253 Take into FREEBUSY discussion.
1255 B.2. Subscribing to task updates
1257 Stakeholders should have the ability to subscribe to categories /
1258 types of tasks on an ongoing basis. Reference calendarserver.org
1259 notifications draft
1261 Appendix C. Change Log
1263 V01. 2015-08-23 AA
1265 o Highlighted use of ESTIMATED-DURATION for time planning.
1267 o Corrected PARTSTAT example section 5.1. Changed DECLINED to
1268 FAILED.
1270 o Replaced Task Mode AUTOMATIC-STATUS with CLIENT and SERVER modes.
1271 Also, clarified that task mode processing is only done on the
1272 organizer's copy.
1274 o Clarified responsibility for setting MODIFIED.
1276 o CalDAV support added.
1278 o Updated normative references.
1280 Authors' Addresses
1282 Adrian Apthorp
1283 DHL Express
1284 Fritz-Erler-Str. 5
1285 53113 Bonn
1286 Germany
1288 EMail: aapthorp@theiet.org
1289 URI: http://www.dhl.com
1291 Cyrus Daboo
1292 Apple Inc.
1293 1 Infinite Loop
1294 Cupertino, CA 95014
1295 USA
1297 EMail: cyrus@daboo.name
1298 URI: http://www.apple.com/
1300 Mike Douglass
1301 Rensselaer Polytechnic Institute
1302 110 8th Street
1303 Troy, NY 12180
1304 USA
1306 EMail: douglm@rpi.edu
1307 URI: http://www.rpi.edu/