Network Working Group A. Apthorp Internet Draft DHL Express Intended status: Standards Track C. Daboo Updates: 5545 (if approved) Apple Inc. Expires: July 8, 2015 M. Douglass RPI January 4, 2015 Task Extensions to iCalendar draft-apthorp-ical-tasks-00.txt Abstract This document defines extensions to the Internet Calendaring and Scheduling Core Object Specification (iCalendar) to provide improved status tracking, scheduling and specification of tasks. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html This Internet-Draft will expire on July 8, 2014. Copyright Notice Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Apthorp Expires July 8, 2015 [Page 1]
Internet-Draft Task Extensions to iCalendar January 4, 2015 Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Conventions used in this document . . . . . . . . . . . . . 3 1.2. Glossary . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Task Architecture . . . . . . . . . . . . . . . . . . . . . . . 4 2.1. Task Architecture Elements . . . . . . . . . . . . . . . . 7 2.2. Architecture Foundations . . . . . . . . . . . . . . . . . 8 3. Task Extensions . . . . . . . . . . . . . . . . . . . . . . . . 8 3.1. Task Specification . . . . . . . . . . . . . . . . . . . . 9 3.1.1. STRUCTURED-CATEGORY for task type identification . . . 9 3.1.2. Task Context and Relationships . . . . . . . . . . . . 10 3.1.3. Task Domain Data Handling . . . . . . . . . . . . . . . 10 3.2. Task Deadlines and Milestones . . . . . . . . . . . . . . . 10 3.3. Task Scheduling and Assignment . . . . . . . . . . . . . . 11 3.4. Status Reporting . . . . . . . . . . . . . . . . . . . . . 11 3.4.1. Improved granularity in status reporting information . 11 3.4.2. Relating comments to status . . . . . . . . . . . . . . 11 3.4.3. Comments associated to reasons and status changes . . . 12 3.4.4. Task Alerts and Notifications . . . . . . . . . . . . . 12 3.4.5. Automated Status Changes . . . . . . . . . . . . . . . 13 4. New Property Parameters . . . . . . . . . . . . . . . . . . . . 13 4.1. Reason . . . . . . . . . . . . . . . . . . . . . . . . . . 13 4.2. Modified . . . . . . . . . . . . . . . . . . . . . . . . . 13 4.3. Sub-State . . . . . . . . . . . . . . . . . . . . . . . . . 14 5. New Parameter Values . . . . . . . . . . . . . . . . . . . . . 15 5.1. Redefined VTODO Participant Status . . . . . . . . . . . . 15 6. New Properties . . . . . . . . . . . . . . . . . . . . . . . . 15 6.1. Estimated Duration . . . . . . . . . . . . . . . . . . . . 15 6.2. Task Mode . . . . . . . . . . . . . . . . . . . . . . . . . 16 6.2.1 AUTOMATIC-COMPLETION Task Mode . . . . . . . . . . . . . 17 6.2.2 AUTOMATIC-FAILED Task Mode . . . . . . . . . . . . . . . 17 6.2.3 AUTOMATIC-STATUS Task Mode . . . . . . . . . . . . . . . 17 7. Property Extensions and Clarifications . . . . . . . . . . . . 17 7.1. The ATTENDEE property . . . . . . . . . . . . . . . . . . . 17 7.2. Redefined COMMENT Property Parameter List . . . . . . . . . 18 7.3. Redefined STATUS Property . . . . . . . . . . . . . . . . . 18 8. Security Considerations . . . . . . . . . . . . . . . . . . . . 19 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 19 9.1. The Status registry . . . . . . . . . . . . . . . . . . . . 19 9.1.1 Initialization of the Status registry . . . . . . . . . 19 9.1.2 Update of the Status registry . . . . . . . . . . . . . 20 Apthorp Expires July 8, 2015 [Page 2]
Internet-Draft Task Extensions to iCalendar January 4, 2015 9.2. Sub-State value registry . . . . . . . . . . . . . . . . . 20 9.3. Task Mode value registry . . . . . . . . . . . . . . . . . 21 9.4. Participation Statuses registry . . . . . . . . . . . . . . 21 9.5. Properties registry . . . . . . . . . . . . . . . . . . . . 21 9.6. Parameters registry . . . . . . . . . . . . . . . . . . . . 21 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 22 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22 11.1. Normative References . . . . . . . . . . . . . . . . . . . 22 11.2. Informative References . . . . . . . . . . . . . . . . . . 23 Appendix A. Examples of Task State Lifecycle . . . . . . . . . . . 24 A.1. Simple Case Status Change . . . . . . . . . . . . . . . . . 24 A.2. Example for multiple Attendees . . . . . . . . . . . . . . 24 A.3. Failed Example . . . . . . . . . . . . . . . . . . . . . . 25 Appendix B. Working Notes . . . . . . . . . . . . . . . . . . . . 26 B.1. Advertising tasks . . . . . . . . . . . . . . . . . . . . . 26 B.2. Subscribing to task updates . . . . . . . . . . . . . . . . 26 B.3. Advertising supported task modes . . . . . . . . . . . . . 26 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 26 1. Introduction This document specifies extensions to the existing Internet Calendaring and Scheduling Core Object Specification (iCalendar) [RFC5545], and associated protocols, in order to enhance the structured communication and execution of tasks. The enhancements allow for the communication and scheduling of tasks by and between automated systems (e.g. in smart power grids, business process management systems) as well as for human centered tasks. A "task" is a representation of an item of work assigned to an individual or organization. In the iCalendar Object Model [RFC5545] the representation of tasks is by "VTODO" calendar components. Tasks can be identified in a number of situations, either informally as ad-hoc tasks in personal "to-do" lists or more formally in: o Business processes - ranging from repetitive workflows to adaptive cases o Projects - ranging from large construction projects to collaborative software development The extensions specified here are defined in the context of an overall architecture for task calendaring and scheduling. 1.1. Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", Apthorp Expires July 8, 2015 [Page 3]
Internet-Draft Task Extensions to iCalendar January 4, 2015 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119 [RFC2119]. 1.2. Glossary The following calendaring and scheduling terms are applied throughout this document: o Assignee - A calendar user assigned to perform a given task. An assignee is equivalent to an attendee of an event. o Calendar User (CU) - A person or software system that accesses or modifies calendar information. o Calendar User Agent (CUA) - (1) Software with which the calendar user communicates with a calendar service or local calendar store to access calendar information. (2) Software that gathers calendar data on the Calendar User's behalf. o Candidate - A calendar user who might be able to perform a given task, prior to actually being assigned the task, e.g., a dispatcher has a list of taxi drivers (candidates) from which one will be selected to pick-up a passenger. o Organizer - A calendar user who creates a calendar item, requests free/busy information, or published free/busy information. It is an Organizer who invites Attendees [RFC5545]. o Observer - A calendar user interested in a calendar component, e.g., a manager may have interest in all tasks that have not been completed. o Resource - A resource in the scheduling context is any shared entity that can be scheduled by a calendar user, but does not control its own attendance status. Resources can be of "Location", "Equipment", or "Role" type. o Task - A representation of an item of work that can be assigned to one or more task actor assignees. In [RFC5545], these are "VTODO" calendar components, which are groupings of component properties and possibly "VALARM" calendar components that represent an action-item or assignment. 2. Task Architecture A reference architecture for task calendaring and scheduling is defined in order to identify the key logical elements involved in task management and the interfaces between them to enable Apthorp Expires July 8, 2015 [Page 4]
Internet-Draft Task Extensions to iCalendar January 4, 2015 interoperability. The logical elements identified here establish an appropriate separation of concerns and clarify the responsibilities of different elements. However, the architecture does not prescribe a binding or packaging of elements, i.e., software systems may be developed where some elements are tightly bound and the interfaces between bound elements are not exposed. The task architecture is also described in [TARCH]. Apthorp Expires July 8, 2015 [Page 5]
Internet-Draft Task Extensions to iCalendar January 4, 2015 Task +-------+ Trigger | +---------------------V---------------------+ +-----------+ | Task Generating System | | | | +-------------------------+ | | | | | O | | | | | | /|\ | | | | | | / \ | | | | | | Task Organizer | <----> | | +-^--------^--------------+ | | | | | | | | | | +--------V-+ +----V-----+ +----------+ | | | | | Task | | Process | | Task | | | | | |Assignment| | Logic <----> Domain | | | | | | Rules | | | | Data | | | | | +----------+ +----------+ +----------+ | | | | | | | +------^----------+-----^-------------------+ | | | | | | | Availability Task Task | | | | Status | | | | | | | +------v----------v-----+-------------------+ | | | Calendar and Scheduling System | | Directory | | +---------+ +---------+ | | Service | | | | | Task | <----> | | |Schedule | | Lists | | | | | | | | | | | | | +---------+ +---------+ Server | | | +-------------------------------------------+ | | | Client | | | | +----------------------+ +-----------+ | | | | | Calendar | | Task | | | | | | Application +----> Specific | <----> | | | | |Application| | | | | +----------------------+ +-----------+ | | | | | | | +-----^---------^--------+---------+--------+ | | | | | | | | +-----V---------V--------V---------V--------+ | | | Task Actors | | | | O O O O | | | | /|\ /|\ /|\ /|\ +----> | | / \ / \ / \ / \ | | | | Candidate(s) Observer(s) | | | | Assignee(s) Resource(s) | | | +-------------------------------------------+ +-----------+ Apthorp Expires July 8, 2015 [Page 6]
Internet-Draft Task Extensions to iCalendar January 4, 2015 2.1. Task Architecture Elements The following logical elements form the task architecture that this specification is based on: o Task Actors - Various calendar users that may be involved in the monitoring or performing of a task. The set of actors includes: Organizers, Observers, Resources, Assignees, and Candidates. o Task Domain Data - This is any domain specific data that may be acted on or provides context to it in performing a task. o Task Specific Application - A task specific application renders the data concerning the task (including task domain data) for presentation and manipulation by a task actor. o Process Logic - Process logic determines under what conditions a task (or tasks) is generated and the actions to take on completion, or some other status event occurring (or not) on the task. o Task Trigger - This is some event that gives rise to the generation of a task according to Process Logic. Task triggers can come from many different sources including, for example; a task being requested through the calendaring system, a status change in the progression of a business process being managed by a business process management or ERP system. o Task Assignment Rules - Rules that govern how actors are assigned to a task. A range of different assignment patterns [WfRP] may be considered, including the two general cases: 1. Delegation to a named actor or group of actors 2. Advertising to a pool of actors for self-selection In either case the assignment may be made based on a variety of criteria including, name, availability, skills, capacity, etc. o Task Generating System - A system that creates and assigns tasks in response to some initiating event (task trigger). Task creation is according to Process Logic with task assignment determined by Task Assignment Rules. This system also tracks the status of tasks and will initiate further actions based upon the status. A task generating system can take many forms, for example; Business Process Management System, Project Management System, Bug Tracking System, Building Control System. A Task Generating System may also be a human. In iCalendar terms the Task Generating System is the Apthorp Expires July 8, 2015 [Page 7]
Internet-Draft Task Extensions to iCalendar January 4, 2015 organizer. o Human Task Generation - Task creation, assignment and tracking coordinated by a human organizer is a special case of a task generating system. In this case Task Assignment Rules and Process Logic may be either explicit or tacit. o Directory Service - A software system that stores and provides access to information providing details of task actors that may participate or be interested in a task. o Calendar and Scheduling System - A software system that stores, publishes and synchronizes calendar data such as events, tasks and journal entries for actors. In the context of tasks this includes schedules (i.e. allocated time and availability to perform tasks) and task lists. A calendar and scheduling system typically consists of server and client software components. It is not within the scope of this document to specify how Process Logic or Task Assignment Rules are codified. Such logic and rules may be codified in a variety of ways, including traditional programming languages (e.g. C++, Java) or process modelling languages (e.g. BPMN). 2.2. Architecture Foundations The key standards that enable interoperability between the logical elements of the architecture are the Internet Calendaring and Scheduling Core Object Specification (iCalendar) [RFC5545] and associated protocols. Task and task status are represented by the iCalendar "VTODO" component. Protocols include, in particular, the iCalendar Transport-Independent Interoperability Protocol (iTIP) [RFC5546] for task assignment and scheduling. Additionally, iCalendar extensions embraced by this specification include: o Support for iCalendar Relationships [Doug114] - The LINK, REFID, RELATED-TO and STRUCTURED-CATEGORY properties enable context and a rich set of relationships between tasks and other iCalendar components to be specified. o Event Publishing Extensions to iCalendar [Doug214] - The GROUP parameter specifically enables the grouping of properties associated with specific status changes of a task. 3. Task Extensions Apthorp Expires July 8, 2015 [Page 8]
Internet-Draft Task Extensions to iCalendar January 4, 2015 In order to support the task architecture described in section 3, this document defines a number of extensions to the current iCalendar standards in the areas of: o Task Specification - improved ability to specify domain specific tasks o Task Deadlines and Milestones - clarification of deadlines and extension for task duration o Task Scheduling and Assignment - ensure support for common pattens of scheduling and assigning tasks o Task Status Tracking - improved granularity in status tracking information and alerting task actors to pending or actual task status changes These extensions are supported mainly by additions to the properties and parameters used within the "VTODO" component. 3.1. Task Specification The specification of tasks must be semantically explicit in order for them to be managed within the context of a business process or project, and be understood by both humans and IT systems. The current VTODO component only provides for simple ad-hoc tasks or 'to do' lists, and is therefore extended by this specification as follows: o Task type - explicitly what type of task is to be performed is identified. o Task context and relationships - how a specific task relates to other tasks and other objects that need to be understood for the effective execution of a task. o Task specific data - the form and content of domain data provided as input to a task and/or that may be output from a task. o Organizer and attendee - recognizes that a task organizer or attendee can be an automated system. 3.1.1. STRUCTURED-CATEGORY for task type identification The STRUCTURED-CATEGORY property is used to identify the type of task, for example; STRUCTURED-CATEGORY:http://example.com/task/delivery Apthorp Expires July 8, 2015 [Page 9]
Internet-Draft Task Extensions to iCalendar January 4, 2015 3.1.2. Task Context and Relationships The LINK property specifies a link to external information, which may be context to the task. For example: LINK;REL="package":http://example.com/package/1234567890 The external information may be data to be manipulated in performing the task. See section 3.1.3 Task Domain Data Handling. REFID is used to identify a key allowing the association of tasks that are related to the same object and retrieval of a task based on this key. This may be, for example, to identify the tasks associated with a given project without having to communicate the task structure of the project, or all tasks associated to a specific package. REFID:Manhattan REFID:1234567890 Extensions [Doug114] to the RELATED-TO property allow temporal relationships between tasks as found in project management to be specified as well as parent / child relationships. 3.1.3. Task Domain Data Handling Provide support for task specific input and output data (including updates) beyond the standard iCalendar properties. It is envisaged that standard calendar clients would be able to launch applications with task payload. The LINK property can be used to 'attach' the domain specific data to the task. For example, it might be a URI pointing to a web page where the status of the task can be directly manipulated. LINK;REL="vacation-system";VALUE=URI:http://example.com/ vacation-approval?id=1234 Or it might be used for attachments specific to the task, for example an electronic copy of a signature taken to confirm delivery of a package. LINK;REL="electronic-signature";VALUE=URI:http://example.com/ delivery/sig1234.jpg 3.2. Task Deadlines and Milestones Deadlines for starting and finishing a task are defined by the Apthorp Expires July 8, 2015 [Page 10]
Internet-Draft Task Extensions to iCalendar January 4, 2015 DTSTART, DUE and DURATION properties. DTSTART represents the earliest start time for beginning work on a task. DUE, or DTSTART + DURATION represent the latest finish time for a task. Thus these properties define a "window" within which a task has to be performed. However, there is currently no way to indicate how long the task is expected to take. This document defines a new property, ESTIMATED-DURATION, to allow for the estimated time that a task should take to be specified separately from the deadlines for starting and finishing a task. A task that has intermediary deadlines (i.e., milestones) SHOULD be expressed by child VTODO components (i.e., sub-tasks associated with each of the milestones) in conjunction with the RELATED-TO property to relate the parent and child tasks. 3.3. Task Scheduling and Assignment This specification supports the two distinct models of assigning actors to tasks, i.e., 1) strictly one assignee per task or 2) task assignment to multiple assignees. In this regard one or many ATTENDEES may be specified against a task depending upon the model applied by the task organizer. In addition a number of different patterns of resource or assignee identification are anticipated. The specific Task Assignment Rules are the responsibility of the Task Organizer. Communication of task assignment or delegation to one or more actors who are allocated to a task by the organizer is directly supported by iTIP, i.e., all included ATTENDEES in an iTIP REQUEST are expected to perform the task. The offering or advertising of a task to one or more (potential) actors where only one or a subset of the candidates may accept the task will be addressed by a new VPOLL mode (See Appendix B). 3.4. Status Reporting 3.4.1. Improved granularity in status reporting information This document defines new status parameters that can be applied to the VTODO status, "STATUS" property, as well as the participant status, "PARTSTAT" parameter. These new parameters provide additional information on why (REASON) and when (MODIFIED) a status has changed. In addition to these parameters new status values are specified to provide for task suspension, failure and preparation. 3.4.2. Relating comments to status Apthorp Expires July 8, 2015 [Page 11]
Internet-Draft Task Extensions to iCalendar January 4, 2015 The GROUP parameter is used with the STATUS or ATTENDEE properties to relate an associated COMMENT property. The COMMENT property can then be used to include additional human readable information about why the associated STATUS or ATTENDEE property changed. STATUS;REASON="http://example.com/reason/delivery-failed";SUBSTATE =ERROR;MODIFIED=20130212T120000Z;GROUP=G1:FAILED COMMENT;MODIFIED=20130226T110451Z;GROUP=G1:Breakdown ATTENDEE;PARTSTAT=FAILED;MODIFIED=20130226T1104510Z;GROUP=G2: REASON="http://example.com/reason/van-break-down":mailto: xxx@example.com COMMENT;MODIFIED=20130226T110451Z;GROUP=G2:Puncture 3.4.3. Comments associated to reasons and status changes Reasons may be associated directly with a comment, allowing for multiple reasons associated with a status to each have a comment associated with them [EDISTS]. STRUCTURED-CATEGORY:http://example.com/task/delivery STATUS;SUBSTATE=ERROR;MODIFIED=20130212T120000Z;GROUP=G1:FAILED COMMENT;MODIFIED=20130226T110451Z;GROUP=G1:Out of time COMMENT;REASON="http://example.com/reason/traffic";MODIFIED= 20130226T110451Z;GROUP=G1:Traffic Accident on E44 COMMENT;REASON="http://example.com/reason/closed";MODIFIED= 20130226T110451Z;GROUP=G1:Arrived after office hours 3.4.4. Task Alerts and Notifications Different needs to alert or notify task actors of pending or actual task status changes are recognized: o Alarms - Alarms, VLARM, operate in the user space to notify the task actor of a pending task state for a task they are assigned to or are interested in. There is no constraint in the current standards on the propagation of alarms specified on calendar objects by organizers to individual attendees. o Escalations - An escalation or notification to the ATTENDEE, ORGANIZER, or other task actor may be required if a deadline associated with a task is exceeded or for some other reason. Process Logic identifying when and who to propagate escalations to is the responsibility of the Task Generating System, e.g., a BPMS. o Notifications - Task actors (observers) not directly involved in Apthorp Expires July 8, 2015 [Page 12]
Internet-Draft Task Extensions to iCalendar January 4, 2015 performing a task but with a known interest in a given task's status can be identified by the ASSOCIATE property [Doug214] against certain components e.g. ALARM, to identify which task events the stakeholder / party is interested in. Notifications on shared calendars will allow task actors to register an interest in changes to tasks within a calendar (see Appendix B.2). 3.4.5. Automated Status Changes A new property, TASK-MODE, is introduced to instruct servers to apply automated operations for changing the status of a task. 4. New Property Parameters 4.1. Reason Parameter name: REASON Purpose: To indicate the reason for a change in status of a task or attendee participation status. Format Definition: This parameter is defined by the following notation: reasonparam = "REASON" "=" DQUOTE uri DQUOTE *("," DQUOTE uri DQUOTE) Description: This property parameter allows the change in status of a task or participant status to be qualified by the reason for the change with a codified reason. Typically reasons are defined within the context of the task type and therefore SHOULD include the name- space of the authority defining the task. Common reason codes are IANA registered and do not have a name-space prefix. Example: STATUS;REASON="http://example.com/reason/delivered-on-time"; MODIFIED=20130212T120000Z;GROUP=G1:COMPLETED ATTENDEE;REASON="x-example-reason:out-of-office";PARTSTAT= DECLINED;MODIFIED=20130212T120000Z;GROUP=123:mailto: cyrus@example.com 4.2. Modified Parameter name: MODIFIED Purpose: To specify the time and date of when the status of a task Apthorp Expires July 8, 2015 [Page 13]
Internet-Draft Task Extensions to iCalendar January 4, 2015 or attendee participant status changed. Format Definition: This parameter is defined by the following notation: modifiedparam = "MODIFIED" "=" date-time Description: The modified parameter allows the specification of the date time of when a status of participant status changed. It MUST be specified in the UTC time format. Example: STATUS;REASON=""http://example.com/reason/delivered-on-time"; MODIFIED=20130212T120000Z;GROUP=G1:COMPLETED 4.3. Sub-State Parameter name: SUBSTATE Purpose: To provide additional granularity of task status for e.g. IN-PROCESS. Format Definition: This parameter is defined by the following notation: substateparam = "SUBSTATE" "=" ( "OK" ; everything is fine(the default) / "ERROR" ; something is wrong (the REASON ; code explains why) / "SUSPENDED" ; waiting on some other task to ; complete or availability of a ; resource (REASON code explains ; why) / x-name ; Experimental type / iana-token) ; Other IANA-registered type Description: The sub-state parameter allows additional qualification and granularity of states to be recorded, in particular for the IN- PROCESS state. It allows individual sub-states to be recorded without the need to define and publish a sub-task associated with a parent task purely to track that a particular state has been reached. This property also allows parallel states to be expressed e.g. that a task has been suspended at whatever state it has reached. Example: STATUS;REASON="http://example.com/reason/no-one-home";SUBSTATE= Apthorp Expires July 8, 2015 [Page 14]
Internet-Draft Task Extensions to iCalendar January 4, 2015 ERROR:FAILED STATUS;REASON="http://example.com/reason/paint-drying";SUBSTATE= SUSPENDED:IN-PROCESS 5. New Parameter Values 5.1. Redefined VTODO Participant Status Participant status parameter type values are defined in section 3.2.12. of [RFC5545]. This specification redefines that type to include the new value FAILED for VTODO iCalendar components. Format Definition: This property parameter is extended by the following notation: partstat-todo /= *("FAILED") ; To-do cannot be completed Example: ATTENDEE;REASON="http://example.com/reason/not-enough-time"; PARTSTAT=DECLINED:mailto:jsmith@example.com 6. New Properties 6.1. Estimated Duration Property Name: ESTIMATED-DURATION Purpose: This property specifies the estimated positive duration of time the corresponding task will take to complete. Value Type: DURATION Property Parameters: IANA and non-standard property parameters can be specified on this property. Conformance: This property can be specified in "VTODO" calendar components. Format Definition: This property is defined by the following notation: est-duration = "ESTIMATED-DURATION" durparam ":" dur-value CRLF ;consisting of a positive duration of time. durparam = *(";" other-param) Description: In a "VTODO" calendar component the property MAY be Apthorp Expires July 8, 2015 [Page 15]
Internet-Draft Task Extensions to iCalendar January 4, 2015 used to specify the estimated duration for the to-do, with or without an explicit time window in which the event should be started and completed. When present, DTSTART and DUE/DURATION represent the window in which the task can be performed. ESTIMATED-DURATION SHOULD be passed from ORGANIZER to ATTENDEE in iTIP [RFC5546] messages. Example: The following is an example of this property that specifies an interval of time of exactly one hour: ESTIMATED-DURATION:PT1H 6.2. Task Mode Property Name: TASK-MODE Purpose: This property specifies automatic operations that servers apply to tasks based on changes in state signalled by attendees. Value Type: TEXT Property Parameters: IANA and non-standard property parameters can be specified on this property. Conformance: This property can be specified zero or more times in a "VTODO" calendar component. Format Definition: This property is defined by the following notation: task-mode = "TASK-MODE taskmodeparam ":" taskvalue *("," taskvalue) CRLF taskvalue = "AUTOMATIC-COMPLETION" ; set STATUS completed ;if all attendees have completed / "AUTOMATIC-FAILURE" / "AUTOMATIC-STATUS" / iana-token / x-name taskmodeparam = *(";" other-param) Description: In a "VTODO" calendar component the property MAY be used to indicate to servers how they can automatically change the state of the task based on iTIP replies from Attendees. For example, the server can automatically set the overall task state to COMPLETED when every attendee has marked their own state as COMPLETED, or the server could mark the task as FAILED if its DUE date passes without it being completed. Apthorp Expires July 8, 2015 [Page 16]
Internet-Draft Task Extensions to iCalendar January 4, 2015 The property value is a list of one or more IANA registered tokens that defines modes to be used for the task. This specification defines three modes which are described in the following sub- sections. Examples: TASK-MODE:AUTOMATIC-COMPLETION,AUTOMATIC-FAILURE TASK-MODE:AUTOMATIC-STATUS TASK-MODE:AUTOMATIC-FAILURE 6.2.1 AUTOMATIC-COMPLETION Task Mode The task mode value "AUTOMATIC-COMPLETION" indicates to the server that it can change the "VTODO" component's STATUS property value to "COMPLETED" as soon as all ATTENDEEs in the task have replied with a "PARTSTAT" parameter set to "COMPLETED". 6.2.2 AUTOMATIC-FAILED Task Mode The task mode value "AUTOMATIC-FAILED" indicates to the server that it can change the "VTODO" component's STATUS property value to "FAILED" if the current time is past the effective due date of the component and the task has not been completed. The effective due date is either the "DUE" property value or the combination of the "DTSTART" and "DURATION" property values. 6.2.3 AUTOMATIC-STATUS Task Mode The task mode value "AUTOMATIC-STATUS" indicates to the server that it can change the "VTODO" component's STATUS property value to an appropriate value, based on implementation defined "business rules", as ATTENDEE responses are processed or as deadlines related to the task pass. 7. Property Extensions and Clarifications 7.1. The ATTENDEE property The Attendee property is defined in section 3.8.4.1. of [RFC5545]. This specification extends that property to include new parameters to indicate the reason for a participant status change (See Appendix A) and sub-states. Format Definition: This property is defined by the following notation: Apthorp Expires July 8, 2015 [Page 17]
Internet-Draft Task Extensions to iCalendar January 4, 2015 attendee = "ATTENDEE" attparam ":" cal-address CRLF attparam /= *( ; ; The following are OPTIONAL, ; but MUST NOT occur more than once. ; (";" reasonparam) (";" modifiedparam) (";" substateparam) ) Example: The following are examples of this property's use for tasks: ATTENDEE;PARTSTAT=DECLINED;MODIFIED=20130212T120000Z;GROUP=G1; REASON="http://example.com/reason/too-busy": mailto:xxx@example.com ATTENDEE;PARTSTAT=IN-PROCESS;MODIFIED=20130212T120000Z; SUBSTATE=X-EXAMPLE-STEP-1:mailto:xxx@example.com 7.2. Redefined COMMENT Property Parameter List The Comment property is defined in section 3.8.1.4. of [RFC5545]. Format Definition: The "COMMENT" property parameter list is augmented as follows: commparam /= *( ; The following are OPTIONAL, ; but MUST NOT occur more than once. (";" reasonparam) / (";" modifiedparam) ) 7.3. Redefined STATUS Property The Status property is defined in section 3.8.1.11. of [RFC5545]. This specification extends that property to include new parameters to indicate the reason for a status change as well as new values associated with VTODO iCalendar components (See Appendix A for examples of the task state lifecycle). Format Definition: The "STATUS" property parameter list is augmented as follows: statparam /= *( ; The following are OPTIONAL, Apthorp Expires July 8, 2015 [Page 18]
Internet-Draft Task Extensions to iCalendar January 4, 2015 ; but MUST NOT occur more than once. ; (";" reasonparam) (";" modifiedparam) (";" substateparam) / ) statvalue-todo = / "PENDING" ;Indicates a to-do has been ;created and accepted, but has not ;yet started. / "FAILED" ;Indicates to-do has failed. ;Extended status values for ;"VTODO". Description: PENDING - A task has been created but has not yet started and is ready to start subject to other dependencies (e.g. preceding task or DTSTART). This is the default state. FAILED - task has failed and may need some follow-up from the organizer to re-schedule or cancel Example: The following is an example of this property for a "VTODO" calendar component: STATUS;REASON="http://example.com/reason/delivery-failed";SUBSTATE =ERROR;MODIFIED=20130212T120000Z;GROUP=G1:FAILED 8. Security Considerations This specification introduces no new security considerations beyond those identified in RFC 5545. 9. IANA Considerations 9.1. The Status registry 9.1.1 Initialization of the Status registry This specification updates [RFC5545] by adding a Status value registry to the iCalendar Elements registry and initializing it as per [RFC5545]. Apthorp Expires July 8, 2015 [Page 19]
Internet-Draft Task Extensions to iCalendar January 4, 2015 +--------------+---------+------------------------------+ | Status | Status | Reference | +--------------+---------+------------------------------+ | CANCELLED | Current | [RFC5545], Section 3.8.1.11. | | | | | | COMPLETED | Current | [RFC5545], Section 3.8.1.11. | | | | | | CONFIRMED | Current | [RFC5545], Section 3.8.1.11. | | | | | | DRAFT | Current | [RFC5545], Section 3.8.1.11. | | | | | | FINAL | Current | [RFC5545], Section 3.8.1.11. | | | | | | IN-PROCESS | Current | [RFC5545], Section 3.8.1.11. | | | | | | NEEDS-ACTION | Current | [RFC5545], Section 3.8.1.11. | | | | | | TENTATIVE | Current | [RFC5545], Section 3.8.1.11. | +--------------+---------+------------------------------+ 9.1.2 Update of the Status registry This specification further updates the Status registry with additional values defined in this document. +-----------+---------+-------------------------+ | Status | Status | Reference | +-----------+---------+-------------------------+ | PENDING | Current | This Spec, Section 7.3. | | | | | | FAILED | Current | This Spec, Section 7.3. | +-----------+---------+-------------------------+ 9.2. Sub-State value registry The following table has been used to initialize the Sub-State registry. +-----------+---------+-------------------------+ | Substate | Status | Reference | +-----------+---------+-------------------------+ | OK | Current | This Spec, Section 4.3. | | | | | | ERROR | Current | This Spec, Section 4.3. | | | | | | SUSPENDED | Current | This Spec, Section 4.3. | +-----------+---------+-------------------------+ Apthorp Expires July 8, 2015 [Page 20]
Internet-Draft Task Extensions to iCalendar January 4, 2015 9.3. Task Mode value registry The following table has been used to initialize the Task Mode registry. +----------------------+---------+-------------------------+ | Task Mode | Status | Reference | +----------------------+---------+-------------------------+ | AUTOMATIC-COMPLETION | Current | This Spec, Section 6.2. | | | | | | AUTOMATIC-FAILURE | Current | This Spec, Section 6.2. | | | | | | AUTOMATIC-STATUS | Current | This Spec, Section 6.2. | +----------------------+---------+-------------------------+ 9.4. Participation Statuses registry The following table has been used to update the Participation Statuses registry. +-----------+---------+-------------------------+ | Status | Status | Reference | +-----------+---------+-------------------------+ | FAILED | Current | This Spec, Section 5.1. | +-----------+---------+-------------------------+ 9.5. Properties registry The following table has been used to update the Properties registry. +--------------------+---------+-------------------------+ | Property | Status | Reference | +--------------------+---------+-------------------------+ | ATTENDEE | Current | This Spec, Section 7.1. | | | | | | COMMENT | Current | This Spec, Section 7.2. | | | | | | ESTIMATED_DURATION | Current | This Spec, Section 6.1. | | | | | | STATUS | Current | This Spec, Section 7.3. | | | | | | TASK-MODE | Current | This Spec, Section 6.2. | +--------------------+---------+-------------------------+ 9.6. Parameters registry Apthorp Expires July 8, 2015 [Page 21]
Internet-Draft Task Extensions to iCalendar January 4, 2015 The following table has been used to update the Parameters registry. +-----------+---------+-------------------------+ | Parameter | Status | Reference | +-----------+---------+-------------------------+ | REASON | Current | This Spec, Section 4.1. | | | | | | MODIFIED | Current | This Spec, Section 4.2. | | | | | | SUBSTATE | Current | This Spec, Section 4.3. | +-----------+---------+-------------------------+ 10. Acknowledgements The authors would like to thank the members of the Calendaring and Scheduling Consortium technical committees and the following individuals for contributing their ideas, support and comments: John Chaffee, Marten Gajda, Ken Murchison The authors would also like to thank the Calendaring and Scheduling Consortium for advice with this specification. This document was prepared using Internet-Draft Nroff Editor. 11. References 11.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2234] Crocker, D. and Overell, P.(Editors), "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, Internet Mail Consortium and Demon Internet Ltd., November 1997. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, January 2004. [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005. [RFC5545] Desruisseaux, B., "Internet Calendaring and Scheduling Core Object Specification (iCalendar)", RFC 5545, September Apthorp Expires July 8, 2015 [Page 22]
Internet-Draft Task Extensions to iCalendar January 4, 2015 2009. [RFC5546] Daboo, C., "iCalendar Transport-Independent Interoperability Protocol(iTIP)", RFC 5546, December 2009. [Doug114] Douglass, M., "Support for Icalendar Relationships", draft- douglass-ical-relations-02, January 7, 2014 [Doug214] Douglass, M., "Event Publishing Extensions to iCalendar", draft-douglass-calendar-extension-04, February 1, 2014 11.2. Informative References [EDISTS] UN Economic Commission for Europe, UN/EDIFACT, D14.A, STS STATUS, April 30, 2014, http://www.unece.org/fileadmin/ DAM/trade/untdid/d14a/trsd/trsdsts.htm [TARCH] Apthorp, A., Daboo, C., Douglass, M., CalConnect, Task Architecture V0.42014, http://www.calconnect.org/Task%20Architecture%200.4.pdf [WfRP] Russell, N., ter Hofstede, A.H.M., Edmond, T., van der Aalst,W.M.P., Workflow Resource Patterns, Eindhoven University of Technology, 2004, <http://www.workflowpatterns.com/patterns/resource/> [WSCal] Considine, T., Douglass, M., WS-Calendar Version 1.0, OASIS, 30 July 2011, <http://docs.oasis-open.org/ws- calendar/ws-calendar- spec/v1.0/cs01/ws-calendar-spec-v1.0-cs01.html> [WSHT] Ings, D., Clement, L., Koenig, D., Mehta, V., Mueller, R., Rangaswamy, R., Rowley, M., Trickovic, I., Web Services - Human Task Version 1.1 (WS-HumanTask), OASIS, 17 August 2010, <http://docs.oasis-open.org/ns/bpel4people/ws- humantask/200803> Apthorp Expires July 8, 2015 [Page 23]
Internet-Draft Task Extensions to iCalendar January 4, 2015 Appendix A. Examples of Task State Lifecycle A.1. Simple Case Status Change Example of status changes in assigning and performing a task with one attendee. STATUS PARTSTAT Action ------ -------- ------ 1. - - Organizer draft 2. NEEDS-ACTION NEEDS-ACTION Organizer sends iTIP request 3. NEEDS-ACTION ACCEPTED Attendee reply 4. PENDING ACCEPTED Task accepted but waiting on some "trigger" to start (e.g. another task has to finish first) 5. IN-PROCESS IN-PROCESS Attendee reply now working on the task 6. IN-PROCESS COMPLETED Attendee reply completed 7. COMPLETED COMPLETED Organizer changes overall state A.2. Example for multiple Attendees Example of status changes in assigning and performing a task with two attendees (A1 and A2). STATUS PARTSTAT (A1) PARTSTAT (A2) Action ------ ------------ ------------ ------ 1. - - - Organizer draft. 2. NEEDS-ACTION NEEDS-ACTION NEEDS-ACTION Organizer sends iTIP request. 3. NEEDS-ACTION ACCEPTED NEEDS-ACTION Attendee 1 reply. 3. NEEDS-ACTION ACCEPTED ACCEPTED Attendee 2 reply. 4. PENDING ACCEPTED ACCEPTED Task accepted but waiting on some "trigger" to start (e.g. another task has to finish first) 5. IN-PROCESS ACCEPTED IN-PROCESS Attendee 2 reply now working on the task. 5. IN-PROCESS IN-PROCESS IN-PROCESS Attendee 1 reply now working on the task. 6. IN-PROCESS COMPLETED IN-PROCESS Attendee 1 reply Completed (overall status still IN-PROCESS). Apthorp Expires July 8, 2015 [Page 24]
Internet-Draft Task Extensions to iCalendar January 4, 2015 6. IN-PROCESS COMPLETED COMPLETED Attendee 2 reply Completed 7. COMPLETED COMPLETED COMPLETED Organizer changes overall state once both attendees are finished. Note: The logic for determining the status change to the VTODO is determined by the task organizer based on the ATTENDEE status and other business logic. A.3. Failed Example Example of status changes for a task that fails. STATUS PARTSTAT Action ------ -------- ------ 1. - - Organizer draft 2. NEEDS-ACTION NEEDS-ACTION Organizer sends iTIP request 3. NEEDS-ACTION ACCEPTED Attendee reply 4. IN-PROCESS IN-PROCESS Attendee reply now working on the task 5. IN-PROCESS FAILED Attendee reply task failed 6. FAILED FAILED Organizer changes overall state Apthorp Expires July 8, 2015 [Page 25]
Internet-Draft Task Extensions to iCalendar January 4, 2015 Appendix B. Working Notes B.1. Advertising tasks Use VPOLL for advertising a task to a pool of possible ATTENDEEs and then select the respondent to assign one or more assignees. Introduce POLL-MODE:ASSIGNMENT Need to indicate number of assignees required. Potentially different types of response e.g. ACCEPT or DECLINE, or a weighting e.g. 0 - 100 Take into FREEBUSY discussion. B.2. Subscribing to task updates Stakeholders should have the ability to subscribe to categories / types of tasks on an ongoing basis. Reference calendarserver.org notifications draft B.3. Advertising supported task modes TBD define caldav property to advertise supported modes - use RSCALE spec as a template. Authors' Addresses Adrian Apthorp DHL Express Fritz-Erler-Str. 5 53113 Bonn Germany EMail: aapthorp@theiet.org URI: http://www.dhl.com Cyrus Daboo Apple Inc. 1 Infinite Loop Cupertino, CA 95014 USA EMail: cyrus@daboo.name URI: http://www.apple.com/ Apthorp Expires July 8, 2015 [Page 26]
Internet-Draft Task Extensions to iCalendar January 4, 2015 Mike Douglass Rensselaer Polytechnic Institute 110 8th Street Troy, NY 12180 USA EMail: douglm@rpi.edu URI: http://www.rpi.edu/ Apthorp Expires July 8, 2015 [Page 27]