Assignee:

A calendar user assigned to perform a given task. An assignee is equivalent to an "Attendee" of a task.

BPMS:

Business Process Management Software

CU:

Calendar User. A person or software system that accesses or modifies calendar information.

CUA:

Calendar User Agent. This may be one of the following:

1. Software with which the CU communicates with a calendar service or local calendar store to access calendar information.
2. Software that gathers calendar data on the CU's behalf.

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.

Organizer:

A calendar user who creates a calendar item, requests free/busy information, or publishes free/busy information. It is an "Organizer" who invites "Attendees" .

Observer:

A calendar user interested in a calendar component, e.g., a manager may have interest in all tasks that have not been completed. Often represented as an "Attendee" with the "role" parameter set to NON-PARTICIPANT.

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. Examples of such resources are locations such as a bookable conference room or equipment such as projectors.

Task:

A representation of an item of work that can be assigned to one or more task actor assignees. In , these are "VTODO" calendar components, which are groupings of component properties and possibly "VALARM" calendar components that represent an action item or assignment.

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.

Task Organizer:

The creator of a task who also determines task assignment and scheduling and monitors task progress.

Task Domain Data:

This is any domain-specific data that may be acted on or that provides context for performing a task.

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.

Process Logic:

Determines under what conditions one or more tasks are generated and the actions to take upon task completion or upon the occurrence (or non-occurrence) of some other status event.

Task Trigger:

An event that gives rise to the generation of a task according to Process Logic. Task triggers can come from many sources including, for example, a task being requested through the calendaring system or a status change in the progression of a business process being managed by a business process management or enterprise resource planning (ERP) system.

Task Assignment Rules:

Govern how actors are assigned to a task. A range of different assignment patterns 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.

Task Generating System:

A system that creates and assigns tasks in response to some initiating event (task trigger). Process Logic defines task creation, while Task Assignment Rules determine task assignment. 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, such as a Business Process Management System, Project Management System, Bug Tracking System, and Building Control System. A Task Generating System may also be a human. In iCalendar terms the Task Generating System is the "Organizer". 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.

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.

Alarms:

"VALARM" calendar components operate in the calendar user agent space to notify the task actor of a pending task state for a task they are assigned to or are interested in. Current standards (such as ) indicate that "VALARM" calendar components SHOULD be removed from incoming data, and many systems in fact do so. In a task assignment scenario, it may be appropriate for the "Organizer" to be able to set alarms for the participants. A system implementing these standards may choose to preserve "VALARM" calendar components, but sending a task via some external service may result in their removal. This issue is not addressed by this specification.

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 is the responsibility of the Task Generating System, e.g., a BPMS.

Notifications:

Task actors (Observers) not directly involved in performing a task but that have a known interest in a given task's status can be identified by the "PARTICIPANT" calendar component against certain components, e.g., the "VALARM" calendar component, 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 ).

Format Definition:

This property parameter is redefined by the following notation, which adds the value "FAILED":

Example:

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:

Description:

In a "VTODO" calendar component the property MAY be 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, the "DTSTART" and "DUE" or "DTSTART" and "DURATION" properties represent the window in which the task can be performed. The "ESTIMATED-DURATION" property SHOULD be passed from the "Organizer" to the "Attendee" in iTIP messages.

Example:

The following example illustrates how this property is used to estimate a task duration of one hour:

Property Name:

REASON

Purpose:

To indicate the reason for a status change or change of "Attendee" participation status.

Value Type:

URI

Property Parameters:

IANA and non-standard property parameters can be specified on this property.

Conformance:

This property can be specified in "VSTATUS" and "PARTICIPANT" calendar components.

Format Definition:

This property is defined by the following notation:

Description:

This property allows a change in task or participant status to be qualified 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.

Example:

Property Name:

SUBSTATE

Purpose:

To provide additional granularity of a task status, such as IN-PROCESS.

Value Type:

TEXT

Property Parameters:

IANA and non-standard property parameters can be specified on this property.

Conformance:

This property can be specified in a "VSTATUS" calendar component.

Format Definition:

This property is defined by the following notation:

Description:

The "SUBSTATE" property allows additional qualification and granularity of states to be recorded, in particular for the IN-PROCESS state. It allows individual substates to be recorded without the need to define and publish a subtask associated with a parent task purely to track that a particular state has been reached. This property also allows parallel states to be expressed, such as indicating that a task has been suspended at whatever state it has reached.

Example:

Property Name:

TASK-MODE

Purpose:

This property specifies automatic operations that servers acting on behalf of the "Organizer" apply to tasks based on changes in "Attendee" status (PARTSTAT).

Value Type:

TEXT

Property Parameters:

IANA and non-standard property parameters can be specified on this property.

Conformance:

This property can be specified zero times or once in a "VTODO" calendar component.

Format Definition:

This property is defined by the following notation:

Description:

In a "VTODO" calendar component, this 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 status to "COMPLETED" when every "Attendee" has marked their own status (PARTSTAT) as "COMPLETED", or the server could mark the task as "FAILED" if its DUE date passes before completion. "TASK-MODE" processing is performed on the "Organizer's" copy of the task. To set the status, add a "VSTATUS" component as specified in . The property value is an IANA-registered token that defines the mode to be used for the task. The modes are described in the following subsections. If the "TASK-MODE" property is absent, then the "CLIENT" value is assumed.

AUTOMATIC-COMPLETION Task Mode:

The task mode value "AUTOMATIC-COMPLETION" indicates to the server that it SHOULD change the "VTODO" calendar component's status to "COMPLETED" as soon as all "Attendees" in the task have replied with a "partstat" parameter set to "COMPLETED". Failing the task MUST be handled by a client.

AUTOMATIC-FAILURE Task Mode:

The task mode value "AUTOMATIC-FAILURE" indicates to the server that it SHOULD change the "VTODO" calendar component's status to "FAILED" if either:

1. the PARTSTAT of one "ATTENDEE" property is set to "FAILED"; or
2. the current time is past the effective due date of the component and the task has not yet been completed. The effective due date is either the "DUE" property value or the combination of the "DTSTART" and "DURATION" property values. Completing the task MUST be handled by a client.

AUTOMATIC Task Mode:

This mode handles the automatic behavior of both "AUTOMATIC-COMPLETION" and "AUTOMATIC-FAILURE".

CLIENT Task Mode:

The task mode value "CLIENT" is an instruction to the server to honor the status set by the client.

SERVER Task Mode:

The task mode value "SERVER" indicates to the server that it SHOULD change the "VTODO" calendar component's status to an appropriate value, based on implementation-defined "business rules", as "Attendee" responses are processed or as deadlines related to the task pass.

Examples:

A "VTODO" calendar component without the "DTSTART" and "DUE" (or "DURATION") properties specifies a to-do that will be associated with each successive calendar date, until it is completed.

A "VTODO" calendar component without the "DTSTART" and "DUE" properties specifies a to-do that will be associated with each successive calendar date, until it is completed.

Format Definition:

The "STATUS" property parameter list for tasks is redefined by the addition of the values "PENDING" and "FAILED":

Description:

PENDING:

A to-do has been created and accepted but has not yet started and is ready to start subject to other dependencies (e.g., a preceding task or DTSTART). This is the default state.

FAILED:

A to-do has failed and may need some follow-up from the "Organizer" to reschedule or cancel.

Example:

The following is an example of this property for a "VTODO" calendar component:

Component Name:

VSTATUS

Purpose:

This component allows information to be associated with a status, for example, comments and date stamps.

Conformance:

This component can be specified multiple times in any calendar component.

Description:

This component provides a way for multiple date-stamped statuses to be associated with a component such as a participant, task, or event.

Format Definition:

This component is defined by the following notation:

Examples:

Name:

supported-task-mode-set

Namespace:

urn:ietf:params:xml:ns:caldav

Purpose:

Enumerates the set of supported iCalendar "TASK-MODE" element values supported by the server.

Protected:

This property MUST be protected and SHOULD NOT be returned by a PROPFIND allprop request (as defined in ).

Description:

See above.

Definition:

]]>

Example:

AUTOMATIC SERVER CLIENT ]]>