[Docs] [txt|pdf] [Tracker] [Email] [Nits] [IPR]

Versions: 00 01

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]


Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/