DHL Express

Fritz-Erler-Str. 5 Bonn Germany adrian.apthorp@dhl.com

Bedework Commercial Services

226 3rd Street Troy NY United States of America mdouglass@bedework.com

Internet This document defines extensions to the Internet Calendaring and Scheduling Core Object Specification (iCalendar) (RFC5545) to provide improved status tracking, scheduling and specification of tasks. It also defines how Calendaring Extensions to WebDAV (CalDAV) (RFC 4791) servers can be extended to support certain automated task management behaviours.

AcknowledgementsThe 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 CalConnect, the Calendaring and Scheduling Consortium, for advice with this specification.

IntroductionThis document specifies extensions to the existing Internet Calendaring and Scheduling Core Object Specification (iCalendar) , and associated protocols, in order to enhance the structured communication and execution of tasks. The enhancements allow for the communication, time planning 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 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:

• Business processes - ranging from repetitive workflows to adaptive cases and trouble ticketing
• Project Management - whether for large scale construction projects or collaborative software development

The extensions specified here are defined in the context of an overall architecture for task calendaring and scheduling.

Terms and DefinitionsThe key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here. Calendaring and scheduling roles are referred to in quoted-strings of text with the first character of each word in upper case. For example, "Organizer" refers to a role of a "Calendar User" (CU) within the scheduling protocol. Calendar components defined by are referred to with capitalized, quoted-strings of text. All calendar components start with the letter "V". For example, "VEVENT" refers to the event calendar component, "VTODO" refers to the to-do calendar component, and "VJOURNAL" refers to the daily journal calendar component. Scheduling methods are referred to with capitalized, quoted-strings of text. For example, "REQUEST" refers to the method for requesting a scheduling calendar component be created or modified; "REPLY" refers to the method a recipient of a request uses to update their status with the "Organizer" of the calendar component. Properties defined by [RFC5545] are referred to with capitalized, quoted-strings of text, followed by the word "property". For example, "ATTENDEE" property refers to the iCalendar property used to convey the calendar address of a "Calendar User". Property parameters defined by this specification are referred to with capitalized, quoted-strings of text, followed by the word "parameter". For example, "VALUE" parameter refers to the iCalendar property parameter used to override the default data type for a property value. Enumerated values defined by this specification are referred to with capitalized text, either alone or followed by the word "value". In tables, the quoted-string text is specified without quotes in order to minimize the table length. Terms defined in this specification include:

Assignee

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

Calendar User (CU)

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

Calendar User Agent (CUA)

This may be

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.

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 published 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.

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.

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 ArchitectureA 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 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 . | | +-^--------^--------------+ | | | | | | | | | | +--------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 | | | | | | User Agent +----> Specific | <----> | | | | |Application| | | | | +----------------------+ +-----------+ | | | | | | | +-----^---------^--------+---------+--------+ | | | | | | | | +-----V---------V--------V---------V--------+ | | | Task Actors | | | | O O O O | | | | /|\ /|\ /|\ /|\ +----> | | / \ / \ / \ / \ | | | | Candidate(s) Observer(s) | | | | Assignee(s) Resource(s) | | | +-------------------------------------------+ +-----------+]]>

Task Architecture ElementsThe following logical elements form the task architecture that this specification is based on:

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 Organizer of a task.

Task Domain Data

This is any domain specific data that may be acted on or provides context to it in 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 a task (or tasks) is generated and the actions to take on completion, or some other status event occurring (or not) on the task.

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.

Task Assignment Rules

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.

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 organizer.

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.

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.

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 ).

Architecture FoundationsThe key standards that enable interoperability between the logical elements of the architecture are the Internet Calendaring and Scheduling Core Object Specification (iCalendar) 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) for task assignment and scheduling, and Calendaring Extensions to WebDAV (CalDAV) for client server communication. Additionally, this specification uses definitions from Support for iCalendar Relationships . The LINK, REFID, RELATED-TO and CONCEPT properties enable context and a rich set of relationships between tasks and other iCalendar components to be specified.

Task ExtensionsIn order to support the task architecture described in , this document defines a number of extensions to the current iCalendar standards in the areas of:

Task Specification

improved ability to specify domain specific tasks

Task Deadlines, Milestones and Time Planning

clarification of deadlines and extension for task duration to support task time planning

Task Scheduling and Assignment

ensure support for common pattens of scheduling and assigning tasks

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.

Task SpecificationThe 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:

Task type

explicitly what type of task is to be performed is identified.

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.

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.

Organizer and attendee

recognizes that a task organizer or attendee can be an automated system.

CONCEPT for task type identificationThe CONCEPT property is used to identify the type of task, for example;

Task Context and RelationshipsThe LINK property specifies a link to external information, which may be context to the task. For example: 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. 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 and dependencies (DEPENDS-ON). Tasks (VTODOs) may also be related to other calendar components; for example to a VEVENT to block time to perform a task.

Task Domain Data HandlingProvide support for task specific input and output data (including updates) beyond the standard iCalendar properties. It is envisaged that standard calendar user agents will be able to launch task specific applications by passing task specific data. 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. 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.

Task Deadlines, Milestones and Time PlanningDeadlines for starting and finishing a task are defined by the 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 the estimated time that a task should take to be specified separately from the deadlines for starting and finishing a task. This supports time planning by enabling calendar user agents to display when tasks should occur and therefore allow calendar users to visualize when tasks should be performed and allocate time to them. 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.

Task Scheduling and AssignmentThis 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) [VPOLL].

Status Reporting

Improved granularity in status reporting information This document defines a new status component that can be used to group related information about the status. This might include information on why (REASON) and when (DTSTAMP) a status has changed. In addition new status values are specified to provide for task suspension, failure and preparation.

Relating reason and comments to ATTENDEE status changes.The PARTICIPANT component can be used to provide additional information about why an ATTENDEE participation status has changed. The COMMENT property can also be used to include additional human readable information about why the associated STATUS or ATTENDEE property changed.

Comments associated to reasons and status changesMultiple comments and reasons may have the same status. As situations chnage further VSTATUS components can be added to provide additional information..

Task Alerts and NotificationsDifferent needs to alert or notify task actors of pending or actual task status changes are recognized:

Alarms

Alarms (VLARM 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. Note: there is no constraint in the current standards on the propagation of alarms specified on calendar objects by organizers to individual attendees.

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.

Notifications

Task actors (observers) not directly involved in 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 ).

Automated Status Changes A new property, TASK-MODE, is introduced to instruct servers to apply automated operations for changing the status of a task.

New Parameter Values

Redefined VTODO Participant StatusParticipant status parameter type values are defined in . 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:

Example

New Properties

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:

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, 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 messages.

Example

The following is an example of this property that specifies an interval of time of exactly one hour:

Reason

Property name

REASON

Purpose

To indicate the reason for a change in status of a task or 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 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

Sub-State

Property name

SUBSTATE

Purpose

To provide additional granularity of task status for e.g. 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 sub-state property 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

Task Mode

Property Name

TASK-MODE

Purpose

This property specifies automatic operations that servers 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 or more times 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 (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 without it being completed. TASK-MODE processing is performed on the organizer's copy of the task.

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

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".

AUTOMATIC-FAILURE Task Mode

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

• the PARTSTAT of one ATTENDEE is set to FAILED; or
• the current time is past the effective due date of the component and the task has not yet been completed.

Note: The effective due date is either the "DUE" property value or the combination of the "DTSTART" and "DURATION" property values.

CLIENT Task Mode

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

SERVER Task Mode

The task mode value "SERVER" 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. The server can add this property to a "VTODO" component to indicate to the client that it will be managing the status.

Property Extensions and Clarifications

Redefined STATUS PropertyThe Status property is defined in . This specification extends that property to include 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:

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:

New Components

Status 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 appropriate calendar component.

Description

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

This compoment may also be added to the PARTICIPANT component to allow participants in a task to specify their own status.

Format Definition

This component is defined by the following notation:

Examples

CalDAV Support for Task ModeThe CalDAV calendar access protocol allows clients and servers to exchange iCalendar data. With the introduction of the "TASK-MODE" property in this specification, different automated task management behaviours may be delegated to the server by the Task Organizer depending upon the value of "TASK-MODE". In order for a CalDAV client to know what task modes are available, a CalDAV server advertises a CALDAV:supported-task-mode-set WebDAV property on calendar home or calendar collections if it supports the use of the "TASK-MODE" property as described in this specification. The server can advertise a specific set of supported task modes by including one or more CALDAV:supported-task-mode XML elements within the CALDAV:supported-task-mode-set XML element. If no CALDAV:supported-task-mode XML elements are included in the WebDAV property, then clients can try any task mode, but need to be prepared for a failure when attempting to store the calendar data. Clients MUST NOT attempt to store iCalendar data containing "TASK-MODE" elements if the CALDAV:supported-task-mode-set WebDAV property is not advertised by the server. The server SHOULD return an HTTP 403 response with a DAV:error element containing a CALDAV:supported-task-mode XML element, if a client attempts to store iCalendar data with an "TASK-MODE" element value not supported by the server. It is possible for a "TASK-MODE" value to be present in calendar data on the server being accessed by a client that does not support the "TASK-MODE" property. It is expected that existing clients, unaware of "TASK-MODE", will fail gracefully by ignoring the calendar property.

CALDAV:supported-task-mode-set Property

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 Section 14.2 of ).

Description

See above.

Definition

]]>

Example

AUTOMATIC-COMPLETION AUTOMATIC-FAILURE SERVER CLIENT ]]>

Security Considerations This specification introduces no new security considerations beyond those identified in .

IANA Considerations

Initialization of the Status registryThis specification updates by adding a Status value registry to the iCalendar Elements registry and initializing it as per . Initial Status Value Registry

Name	Status	Reference
CANCELLED	Current
COMPLETED	Current
CONFIRMED	Current
DRAFT	Current
FINAL	Current
IN-PROCESS	Current
NEEDS-ACTION	Current
TENTATIVE	Current

Update of the Status registryThis specification further updates the Status registry with additional values defined in this document. Updated Status Value Registry

Value	Status	Reference
PENDING	Current	This Spec,
FAILED	Current	This Spec,

Sub-State value registryThe following table has been used to initialize the Sub-State registry. Sub-State registry

Substate	Status	Reference
OK	Current	This Spec,
ERROR	Current	This Spec,
SUSPENDED	Current	This Spec,

Task Mode value registryThe following table has been used to initialize the Task Mode registry. Task Mode Value Registry

Task Mode	Status	Reference
AUTOMATIC-COMPLETION	Current	This Spec,
AUTOMATIC-FAILURE	Current	This Spec,
CLIENT	Current	This Spec,
SERVER	Current	This Spec,

Participation Statuses registryThe following table has been used to update the Participation Statuses registry. Participation Statuses Registry

Value	Status	Reference
FAILED	Current	This Spec,

Properties registryThe following table has been used to update the Properties registry. Updated Properties Registry

Property	Status	Reference
ESTIMATED_DURATION	Current	This Spec,
REASON	Current	This Spec,
SUBSTATE	Current	This Spec,
STATUS	Current	This Spec,
TASK-MODE	Current	This Spec,

Normative References In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 This document defines extensions to the Web Distributed Authoring and Versioning (WebDAV) protocol to specify a standard way of accessing, managing, and sharing calendaring and scheduling information based on the iCalendar format. This document defines the "calendar-access" feature of CalDAV. [STANDARDS-TRACK] RFC 4791 Web Distributed Authoring and Versioning (WebDAV) consists of a set of methods, headers, and content-types ancillary to HTTP/1.1 for the management of resource properties, creation and management of resource collections, URL namespace manipulation, and resource locking (collision avoidance).RFC 2518 was published in February 1999, and this specification obsoletes RFC 2518 with minor revisions mostly due to interoperability experience. [STANDARDS-TRACK] RFC 4918 This document defines the iCalendar data format for representing and exchanging calendaring and scheduling information such as events, to-dos, journal entries, and free/busy information, independent of any particular calendar service or protocol. [STANDARDS-TRACK] RFC 5545 This document specifies a protocol that uses the iCalendar object specification to provide scheduling interoperability between different calendaring systems. This is done without reference to a specific transport protocol so as to allow multiple methods of communication between systems. Subsequent documents will define profiles of this protocol that use specific, interoperable methods of communication between systems.The iCalendar Transport-Independent Interoperability Protocol (iTIP) complements the iCalendar object specification by adding semantics for group scheduling methods commonly available in current calendaring systems. These scheduling methods permit two or more calendaring systems to perform transactions such as publishing, scheduling, rescheduling, responding to scheduling requests, negotiating changes, or canceling. [STANDARDS-TRACK] RFC 5546 RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. RFC 8174 This specification updates RFC 5545 by introducing a number of new iCalendar properties and components that are of particular use for event publishers and in social networking. This specification also defines a new "STRUCTURED-DATA" property for iCalendar (RFC 5545) to allow for data that is directly pertinent to an event or task to be included with the calendar data. RFC 9073 This specification updates RELATED-TO defined in [RFC5545] and introduces new iCalendar properties LINK, CONCEPT and REFID to allow better linking and grouping of iCalendar components and related data. I-D.ietf-calext-ical-relations Informative References Business Modeling Domain Business Process Model and Notation has become the de-facto standard for business processes diagrams. It is intended to be used directly by the stakeholders who design, manage and realize business processes, but at the same time be precise enough to allow BPMN diagrams to be translated into software process components. BPMN has an easy-to-use flowchart-like notation that is independent of any particular implementation environment. OMG BPMN 2.0.2 CalConnect Task Architecture V1.0 UN/EDIFACT, D14.A WfRP OASIS WS-Calendar V1.0 OASIS WS-HT V1.1

Examples of Task State Lifecycle

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

Example for multiple AttendeesExample of status changes in assigning and performing a task with two attendees (A1 and A2). Example for multiple Attendees

	STATUS	PARTSTAT (A1)	PARTSTAT (A2)	Action
1	-	-	-	Organizer draft.
2	NEEDS-ACTION	NEEDS-ACTION	NEEDS-ACTION	Organizer sends iTIP request.
4	NEEDS-ACTION	ACCEPTED	NEEDS-ACTION	Attendee 1 reply.
5	NEEDS-ACTION	ACCEPTED	ACCEPTED	Attendee 2 reply.
6	PENDING	ACCEPTED	ACCEPTED	Task accepted but waiting on some"trigger" to start (e.g. another task has to finish first)
7	IN-PROCESS	ACCEPTED	IN-PROCESS	Attendee 2 reply now working on the task.
8	IN-PROCESS	IN-PROCESS	IN-PROCESS	Attendee 1 reply now working on the task.
9	IN-PROCESS	COMPLETED	IN-PROCESS	Attendee 1 reply Completed (overall status still IN-PROCESS).
10	IN-PROCESS	COMPLETED	COMPLETED	Attendee 2 reply Completed
11	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.

Example of FailureExample of status changes for a task that fails. Example of Failure

	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

Change logV02. 2021-05-05 MD

• Redo in asciidoc
• Change STRUCTURED-CATEGORY to CONCEPT
• Add GROUP parameter definition

V01. 2015-08-23 AA

• Highlighted use of ESTIMATED-DURATION for time planning.
• Corrected PARTSTAT example section 5.1. Changed DECLINED to FAILED.
• Replaced Task Mode AUTOMATIC-STATUS with CLIENT and SERVER modes. Also, clarified that task mode processing is only done on the organizer's copy.
• Clarified responsibility for setting MODIFIED.
• CalDAV support added.
• Updated normative references.

Working Notes

Advertising tasksUse 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.

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