RFC 10051
Task Extensions to iCalendar
RFC 10051 is a Proposed Standard published in October 2026 in the IETF stream by the calext working group.
Proposed Standard IETF stream calext WG Applications and Real-Time
- Updates
- RFC 5545
- Citations
- Cites 11 RFCs
Abstract
The "VTODO" calendar component in the Internet Calendaring and Scheduling Core Object Specification (iCalendar; RFC 5545) has seen limited adoption and use, mainly for personal reminders and to-do lists.
This document updates RFC 5545 and defines extensions to "VTODO" to provide improved status tracking, scheduling, and specification of tasks to allow its use in other contexts, such as process control and project management.
It also defines how Calendaring Extensions to WebDAV (CalDAV) (RFC 4791) servers can be extended to support certain automated task management behaviors.
Plain text 66 KB · rfc-editor.org · Datatracker · doi:10.17487/RFC10051 · draft-ietf-calext-ical-tasks-17
Internet Engineering Task Force (IETF) A. Apthorp
Request for Comments: 10051 DHL Express
Updates: 5545 M. Douglass
Category: Standards Track Bedework Commercial Services
ISSN: 2070-1721 October 2026
Task Extensions to iCalendar
Abstract
The "VTODO" calendar component in the Internet Calendaring and
Scheduling Core Object Specification (iCalendar; RFC 5545) has seen
limited adoption and use, mainly for personal reminders and to-do
lists.
This document updates RFC 5545 and defines extensions to "VTODO" to
provide improved status tracking, scheduling, and specification of
tasks to allow its use in other contexts, such as process control and
project management.
It also defines how Calendaring Extensions to WebDAV (CalDAV) (RFC
4791) servers can be extended to support certain automated task
management behaviors.
Status of This Memo
This is an Internet Standards Track document.
This document is a product of the Internet Engineering Task Force
(IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by the
Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 7841.
Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
https://www.rfc-editor.org/info/rfc10051.
Copyright Notice
Copyright (c) 2026 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
Provisions Relating to IETF Documents
(https://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. Code Components extracted from this document must
include Revised BSD License text as described in Section 4.e of the
Trust Legal Provisions and are provided without warranty as described
in the Revised BSD License.
Table of Contents
1. Introduction
1.1. Terms and Definitions
2. Task Architecture
2.1. Task Architecture Elements
2.2. Architecture Foundations
3. Task Extensions
4. Task Specification
4.1. Task Type
4.2. Task Context and Relationships
5. Task Deadlines, Milestones, and Time Planning
5.1. Deadlines
5.2. Milestones
6. Task Scheduling and Assignment
7. Status Reporting
7.1. Improved Granularity in Status Reporting Information
7.2. Comments Associated to Reasons and Status Changes
7.3. Updating the Overall Status
7.4. Relating Reason and Comments to "ATTENDEE" Property Status
Changes
7.5. Task Alerts and Notifications
7.6. Automated Status Changes
8. Modifications to Calendar Components
9. New Parameter Values
9.1. Redefined VTODO Participant Status
10. New Properties
10.1. Estimated Duration
10.2. Reason
10.3. Substate
10.4. Task Mode
11. Property Extensions and Clarifications
11.1. Updated DURATION Property Definition for VTODO
11.2. Redefined STATUS Property
12. New Components
12.1. Status Component
13. CalDAV Support for Task Mode
13.1. CALDAV:supported-task-mode-set Property
14. Security Considerations
15. IANA Considerations
15.1. Component Registration
15.2. Property Registrations
15.3. STATUS Values Registry
15.4. SUBSTATE Values Registry
15.5. TASK-MODE Values Registry
15.6. Participation Statuses Registry
16. References
16.1. Normative References
16.2. Informative References
Appendix A. Examples of Task State Lifecycle
A.1. Simple Case Status Change
A.2. Example for Multiple "Attendees"
A.3. Example of Failure
Acknowledgements
Authors' Addresses
1. Introduction
This document specifies extensions to the 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, time planning, and scheduling of tasks by and between
automated systems (e.g., taxi dispatch systems, smart power grids
[WsCalendar], and 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 business
processes (ranging from repetitive workflows to adaptive cases and
trouble ticketing) and project management (whether for large-scale
construction projects or collaborative software development).
The extensions specified in this document enhance and standardize the
following:
* The specification of tasks: How a task type is defined and the
relationships between tasks; see Section 4.
* Task planning and scheduling: Improved specification of deadlines
and estimated time for completion; see Section 5.
* Task assignment and status reporting: The addition of "VSTATUS"
(Section 8) allows for more detailed reports; see Section 7.
These extensions are defined within the context of an overall
architecture for task calendaring and scheduling, which elaborates
that supported by [RFC5545] and related standards.
1.1. Terms and Definitions
The 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 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
The notation used in this memo to (re-)define iCalendar elements is
ABNF [RFC5234], as used by [RFC5545]. Any syntax elements shown
below that are not explicitly defined in this specification come from
iCalendar [RFC5545].
Calendaring and scheduling roles are referred to in quoted-strings of
text with the first character of each word in uppercase. For
example, "Organizer" refers to the role of a "Calendar User" (CU)
within the scheduling protocol.
Calendar components defined by [RFC5545] and updating specifications
are referred to with capitalized quoted-strings of text, followed by
the words "calendar component". For example, "VEVENT" calendar
component refers to the event calendar component, "VTODO" calendar
component refers to the to-do calendar component, and "VJOURNAL"
calendar component 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, and "REPLY"
refers to the method the recipient of a request uses to update their
status with the "Organizer" of the calendar component.
Properties defined by [RFC5545] and updating specifications are
referred to with capitalized quoted-strings of text, followed by the
word "property". For example, the "ATTENDEE" property refers to the
iCalendar property used to convey the calendar address of a "Calendar
User".
Property parameters defined by [RFC5545] and updating specifications
are referred to with lowercase quoted-strings of text, followed by
the word "parameter". For example, the "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 and used in this specification include:
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" [RFC5545].
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 [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
interoperability. Central to this architecture is the Calendar and
Scheduling System. The logical elements identified here establish an
appropriate separation of concerns and clarify the responsibilities
of different elements. However, the architecture does not prescribe
the 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].
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 | | | |
| | User Agent +----> Specific | <----> |
| | | |Application| | | |
| +----------------------+ +-----------+ | | |
| | | |
+-----^---------^--------+---------+--------+ | |
| | | | | |
+-----V---------V--------V---------V--------+ | |
| Task Actors | | |
| O O O O | | |
| /|\ /|\ /|\ /|\ +----> |
| / \ / \ / \ / \ | | |
| Candidate(s) Observer(s) | | |
| Assignee(s) Resource(s) | | |
+-------------------------------------------+ +-----------+
Figure 1: Task Architecture Diagram
2.1. Task Architecture Elements
The 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 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 [WfRP] may be considered, including the two
general cases:
a. Delegation to a named actor or group of actors
b. 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.
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 conventional
programming languages (e.g., C++ and Java) or process modeling
languages (e.g., Business Process Model and Notation (BPMN) [BPMN]).
2.2. Architecture Foundations
The key standards that enable interoperability between the logical
elements of the architecture are iCalendar [RFC5545] and the
associated protocols. Task and task status are represented by the
"VTODO" calendar component. Protocols include, in particular, the
iCalendar Transport-Independent Interoperability Protocol (iTIP)
[RFC5546] for task assignment and scheduling and the Calendaring
Extensions to WebDAV (CalDAV) [RFC4791] for client server
communication.
Additionally, this specification uses definitions from "Support for
iCalendar Relationships" [RFC9253]. The "LINK", "REFID", "RELATED-
TO", and "CONCEPT" properties enable context and a rich set of
relationships between tasks and other calendar components to be
specified.
3. Task Extensions
In order to support the task architecture described in Section 2,
this document defines a number of extensions to iCalendar [RFC5545]
in the following areas:
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 patterns of scheduling and assigning
tasks.
Task Status Tracking:
Improved granularity in status tracking information and alerting
task actors of pending or actual task status changes.
These extensions are supported mainly by additions to the properties
and parameters used within the "VTODO" calendar component.
4. 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 understood by both humans and IT systems. The "VTODO"
calendar component [RFC5545] 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.
4.1. Task Type
The "CONCEPT" property [RFC9253] is used to identify the type of
task, for example:
CONCEPT:http://example.com/task/delivery
4.2. Task Context and Relationships
The "LINK" property [RFC9253] specifies a link to external
information, which may provide context for the task. For example:
LINK;LINKREL=describedby;VALUE=URI:
mid:752142.141482.307E5@mx123.example.com
The external information may consist of data to be manipulated in
performing the task.
The "LINK" property can be used to relate a domain-specific service
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.
Note: The link relations below are for illustration only.
LINK;LINKREL="vacation-system";VALUE=URI:
http://example.com/vacation-approval?id=1234
Additionally, it might be used to link data specific to the task, for
example, an electronic copy of a signature taken to confirm delivery
of a package.
LINK;LINKREL="electronic-signature";VALUE=URI:
http://example.com/delivery/sig1234.jpg
The "REFID" property [RFC9253] is used to identify a key used to
group tasks by that key.
REFID:Manhattan
REFID:1234567890
Extensions to the "RELATED-TO" property defined in [RFC9253] allow
temporal relationships between tasks as found in project management
to be specified as well as parent/child relationships and
dependencies (DEPENDS-ON). Tasks ("VTODO" calendar components) may
also be related to other calendar components, for example, a "VEVENT"
calendar component used to block time to perform a task.
5. Task Deadlines, Milestones, and Time Planning
5.1. Deadlines
Deadlines for starting and finishing a task are defined by the
"DTSTART", "DUE", and "DURATION" properties. The "DTSTART" property
represents the earliest start time for beginning work on a task. The
"DUE" or "DTSTART" + "DURATION" properties represent the latest
finish time for a task. Thus, these properties define a "window"
within which a task has to be performed. However, [RFC5545] provides
no way to indicate how long the task is expected to take. This
document defines a new "ESTIMATED-DURATION" property, in
Section 10.1, 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, which allows calendar users to
visualize when tasks should be performed and to allocate time to them
accordingly.
5.2. Milestones
A task that has intermediary deadlines (i.e., milestones) MUST be
expressed by child "VTODO" calendar components (i.e., subtasks
associated with each of the milestones) in conjunction with the
"RELATED-TO" property to relate the parent and child tasks.
6. Task Scheduling and Assignment
Tasks are assigned to actors using one or more "ATTENDEE" properties
[RFC5545] and/or one or more "PARTICIPANT" calendar components
[RFC9073], as described in Section 7.4.
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 "ATTENDEE" properties 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 later specification.
7. Status Reporting
7.1. Improved Granularity in Status Reporting Information
This document defines a new "VSTATUS" calendar component (see
Section 12.1) that can be used to group related information about the
status of the task. This might include information on why (the
"REASON" property) and when (the "DTSTAMP" property) a status has
changed. In addition, new status values are specified to provide for
task suspension, failure, and preparation.
BEGIN:VSTATUS
STATUS:FAILED
REASON:https://example.com/reason/delivery-failed
SUBSTATE:ERROR
DTSTAMP:20130212T120000Z
COMMENT:Breakdown
END:VSTATUS
7.2. Comments Associated to Reasons and Status Changes
Multiple comments and reasons may have the same status. As
situations change, further "VSTATUS" calendar components can be added
to provide additional information.
CONCEPT:https://example.com/task/delivery
BEGIN:VSTATUS
STATUS:FAILED
SUBSTATE:ERROR
DTSTAMP:20220212T104900Z
COMMENT:Out of time
END:VSTATUS
BEGIN:VSTATUS
STATUS:FAILED
COMMENT:Traffic Accident on E44
REASON:https://example.com/reason/traffic
DTSTAMP:20220212T110451Z
END:VSTATUS
BEGIN:VSTATUS
STATUS:FAILED
COMMENT:Arrived after office hours
REASON:https://example.com/reason/closed
DTSTAMP:20220212T180451Z
END:VSTATUS
Note that the "VSTATUS" calendar component is not intended to be used
as a history of changes to a task's properties. The purpose of the
"VSTATUS" calendar component is only to document changes related to
fulfilling the tasks.
7.3. Updating the Overall Status
Only the Task Organizer, or the server acting as the Organizer's
proxy, may change or add "VSTATUS" calendar components and the
"STATUS" property.
The overall "VSTATUS" will be changed in response to incoming
"Attendee" replies. Each change of the overall "VSTATUS" MUST be
accompanied by a change to the STATUS.
Note there is no defined ordering of properties and components so the
DTSTAMP property SHOULD be set for each "VSTATUS" component to
preserve ordering.
7.4. Relating Reason and Comments to "ATTENDEE" Property Status Changes
The "PARTICIPANT" calendar component [RFC9073] can be used to provide
additional information about why an "ATTENDEE" property's
participation status has changed, by following the guidelines set out
in Section 7.1 of [RFC9073]. The "COMMENT" property can also be used
to include additional human-readable information about why the
associated "STATUS" or "ATTENDEE" property changed. For example, if
a driver failed to deliver a package because of a puncture, it might
be expressed as
ATTENDEE;PARTSTAT=FAILED:mailto:xxx@example.com
...
BEGIN:PARTICIPANT
CALENDAR-ADDRESS:mailto:xxx@example.com
DTSTAMP:20130226T1104510Z
REASON:https://example.com/reason/van-break-down
COMMENT:Puncture
END:PARTICIPANT
7.5. Task Alerts and Notifications
Different requirements to alert or notify task actors of pending or
actual task status changes are recognized:
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 [RFC9074]) 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 [RFC9073]
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
Appendix A).
7.6. Automated Status Changes
A new "TASK-MODE" property is introduced to instruct servers to apply
automated operations for changing the status of a task.
8. Modifications to Calendar Components
The following changes to the syntax defined in iCalendar [RFC5545]
and Event Publishing Extensions to iCalendar [RFC9073] are made here.
New elements are defined in subsequent sections.
; Addition of VSTATUS as a valid component for VEVENT
eventc = "BEGIN" ":" "VEVENT" CRLF
eventprop *alarmc *participantc *locationc
*resourcec *statusc
"END" ":" "VEVENT" CRLF
; Addition of VSTATUS as a valid component for VTODO
todoc = "BEGIN" ":" "VTODO" CRLF
todoprop *alarmc *participantc *locationc
*resourcec *statusc
"END" ":" "VTODO" CRLF
; Addition of properties ESTIMATED-DURATION and TASK-MODE to VTODO
todoprop =/ est-duration /
task-mode
; Addition of VSTATUS as a valid component for VJOURNAL
journalc = "BEGIN" ":" "VJOURNAL" CRLF
jourprop *statusc
"END" ":" "VJOURNAL" CRLF
; Addition of VSTATUS as a valid component for VFREEBUSY
freebusyc = "BEGIN" ":" "VFREEBUSY" CRLF
fbprop *participantc *locationc *resourcec *statusc
"END" ":" "VFREEBUSY" CRLF
; Addition of VSTATUS as a valid component for PARTICIPANT
participantc = "BEGIN" ":" "PARTICIPANT" CRLF
partprop *locationc *resourcec
*statusc
"END" ":" "PARTICIPANT" CRLF
; Addition of properties PERCENT-COMPLETE and REASON to PARTICIPANT
partprop =/ percent / ; OPTIONAL but MUST NOT occur more than once.
reason ; OPTIONAL but MUST NOT occur more than once.
9. New Parameter Values
9.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" calendar components.
Format Definition:
This property parameter is redefined by the following notation,
which adds the value "FAILED":
partstat-todo = ("NEEDS-ACTION" ; To-do needs action
/ "ACCEPTED" ; To-do accepted
/ "DECLINED" ; To-do declined
/ "TENTATIVE" ; To-do tentatively
; accepted
/ "DELEGATED" ; To-do delegated
/ "COMPLETED" ; To-do completed
; COMPLETED property has
; DATE-TIME completed
/ "IN-PROCESS" ; To-do in process of
; being completed
/ "FAILED" ; To-do cannot be
; completed
/ x-name ; Experimental status
/ iana-token) ; Other IANA-registered
; status
; These are the participation statuses for a "VTODO".
; Default is NEEDS-ACTION.
Example:
ATTENDEE;REASON="https://example.com/reason/not-enough-time";
PARTSTAT=FAILED:mailto:jsmith@example.com
10. New Properties
10.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 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 [RFC5546] messages.
Example:
The following example illustrates how this property is used to
estimate a task duration of one hour:
ESTIMATED-DURATION:PT1H
10.2. Reason
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:
reason = "REASON" reasonparam ":" uri CRLF
reasonparam = *(";" other-param)
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:
REASON:https://example.com/reason/delivered-on-time
10.3. Substate
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:
substate = "SUBSTATE" substateparam ":" substatevalue CRLF
substateparam = *(";" other-param)
substatevalue = ("OK" ; everything is fine (the default)
/ "ERROR" ; something is wrong (REASON
; explains why)
/ "SUSPENDED" ; waiting on some other task to
; complete or availability of a
; resource (REASON explains why)
/ iana-token) ; other IANA-registered type
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:
BEGIN:VSTATUS
STATUS:FAILED
REASON:https://example.com/reason/no-one-home
SUBSTATE:ERROR
END:VSTATUS
BEGIN:VSTATUS
STATUS:IN-PROCESS
REASON:https://example.com/reason/paint-drying
SUBSTATE:SUSPENDED
END:VSTATUS
10.4. Task Mode
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:
task-mode = "TASK-MODE" taskmodeparam ":"
("AUTOMATIC-COMPLETION"
/ "AUTOMATIC-FAILURE"
/ "AUTOMATIC"
/ "SERVER"
/ "CLIENT"
/ iana-token) CRLF
taskmodeparam = *(";" other-param)
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
Section 12.1.
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:
TASK-MODE:AUTOMATIC-COMPLETION
TASK-MODE:AUTOMATIC-FAILURE
TASK-MODE:SERVER
11. Property Extensions and Clarifications
11.1. Updated DURATION Property Definition for VTODO
Section 3.6.2 of [RFC5545] introduces a constraint on the use of the
"DURATION" property in the "VTODO" calendar component, requiring that
a "DURATION" property MUST be accompanied by a "DTSTART" property.
This constraint is now dropped, reverting to the situation as
specified previously. Thus, Section 3.6.2 of [RFC5545] is updated as
follows:
OLD TEXT:
; Either 'due' or 'duration' MAY appear in
; a 'todoprop', but 'due' and 'duration'
; MUST NOT occur in the same 'todoprop'.
; If 'duration' appear in a 'todoprop',
; then 'dtstart' MUST also appear in
; the same 'todoprop'.
NEW TEXT:
; Either 'due' or 'duration' MAY appear in
; a 'todoprop', but 'due' and 'duration'
; MUST NOT occur in the same 'todoprop'.
Note: This allows a "VTODO" calendar component to only have a
"DURATION" property.
OLD TEXT:
| 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.
NEW TEXT:
| 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.
11.2. Redefined STATUS Property
The "STATUS" property is defined in Section 3.8.1.11 of [RFC5545].
This specification extends that property to include new values
associated with "VTODO" calendar components (see Appendix A for
examples of the task state lifecycle).
Format Definition:
The "STATUS" property parameter list for tasks is redefined by the
addition of the values "PENDING" and "FAILED":
statvalue-todo = "NEEDS-ACTION" ; To-do needs action.
/ "COMPLETED" ; To-do completed.
/ "IN-PROCESS" ; To-do in process of.
/ "CANCELLED" ; To-do was cancelled.
/ "PENDING" ; A to-do has been
; created and accepted, but
; has not yet started.
/ "FAILED" ; To-do has failed.
; Extended status values for "VTODO" calendar component.
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:
STATUS:FAILED
12. New Components
12.1. 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 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.
This component may be added to the "PARTICIPANT" component [RFC9073]
to allow participants in a task to specify their own status.
For backwards compatibility, when a "VSTATUS" component is added, the
"STATUS" property [RFC5545] MUST be set on the parent component.
Format Definition:
This component is defined by the following notation:
statusc = "BEGIN" ":" "VSTATUS" CRLF
statusprop
"END" ":" "VSTATUS" CRLF
statusprop = *(
;
; The following is REQUIRED,
; but MUST NOT occur more than once.
;
status /
;
; The following are OPTIONAL,
; but MUST NOT occur more than once.
;
description / dtstamp / reason / substate / summary /
;
; The following are OPTIONAL,
; and MAY occur more than once.
;
comment / styleddescription / iana-prop
;
)
Examples:
BEGIN:VSTATUS
STATUS:COMPLETED
REASON: https://example.com/reason/delivered-on-time
DTSTAMP:20220212T120000Z
END:VSTATUS
13. CalDAV Support for Task Mode
The CalDAV [RFC4791] 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 behaviors 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 MUST assume the server does not support
this specification. The client MAY attempt to store iCalendar data
containing "TASK-MODE" elements but needs to be prepared for a
failure response from the server.
A server supporting this specification MUST 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 a
"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.
13.1. 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
[RFC4918]).
Description:
See above.
Definition:
<!ELEMENT supported-task-mode-set(supported-task-mode*)>
<!ELEMENT supported-task-mode (#PCDATA)>
<!-- PCDATA value: string - case insensitive but
uppercase preferred -->
Example:
<C:supported-task-mode-set
xmlns:C="urn:ietf:params:xml:ns:caldav">
<C:supported-task-mode>AUTOMATIC</C:supported-task-mode>
<C:supported-task-mode>SERVER</C:supported-task-mode>
<C:supported-task-mode>CLIENT</C:supported-task-mode>
</C:supported-task-mode-set>
14. Security Considerations
This specification introduces no new security considerations beyond
those identified in [RFC5545], [RFC5546], [RFC4791], and [RFC9253].
15. IANA Considerations
15.1. Component Registration
IANA has added the following new iCalendar component to the
"Components" registry defined in Section 8.3.1 of [RFC5545] and
located on <https://www.iana.org/assignments/icalendar>.
+===========+=========+===========================+
| Component | Status | Reference |
+===========+=========+===========================+
| VSTATUS | Current | Section 12.1 of RFC 10051 |
+-----------+---------+---------------------------+
Table 1: Addition to the Components Registry
15.2. Property Registrations
IANA has added the following new iCalendar properties to the
"Properties" registry defined in Section 8.3.2 of [RFC5545] and
located on <https://www.iana.org/assignments/icalendar>.
+====================+=========+===========================+
| Property | Status | Reference |
+====================+=========+===========================+
| ESTIMATED-DURATION | Current | Section 10.1 of RFC 10051 |
+--------------------+---------+---------------------------+
| REASON | Current | Section 10.2 of RFC 10051 |
+--------------------+---------+---------------------------+
| SUBSTATE | Current | Section 10.3 of RFC 10051 |
+--------------------+---------+---------------------------+
| STATUS | Current | Section 11.2 of RFC 10051 |
+--------------------+---------+---------------------------+
| TASK-MODE | Current | Section 10.4 of RFC 10051 |
+--------------------+---------+---------------------------+
Table 2: Additions to the Properties Registry
15.3. STATUS Values Registry
IANA has created a new iCalendar registry called "STATUS Values" for
values of the "STATUS" property defined in Section 3.8.1.11 of
[RFC5545].
Additional values MAY be used, provided the process of Standards
Action with Expert Review as described in Section 8.2.1 of [RFC5545]
is used to register them, using the template in Section 8.2.6 of
[RFC5545].
The initial contents of the "STATUS Values" registry are as follows:
+==============+=========+===============================+
| Name | Status | Reference |
+==============+=========+===============================+
| CANCELLED | Current | Section 3.8.1.11 of [RFC5545] |
+--------------+---------+-------------------------------+
| COMPLETED | Current | Section 3.8.1.11 of [RFC5545] |
+--------------+---------+-------------------------------+
| CONFIRMED | Current | Section 3.8.1.11 of [RFC5545] |
+--------------+---------+-------------------------------+
| DRAFT | Current | Section 3.8.1.11 of [RFC5545] |
+--------------+---------+-------------------------------+
| FAILED | Current | Section 11.2 of RFC 10051 |
+--------------+---------+-------------------------------+
| FINAL | Current | Section 3.8.1.11 of [RFC5545] |
+--------------+---------+-------------------------------+
| IN-PROCESS | Current | Section 3.8.1.11 of [RFC5545] |
+--------------+---------+-------------------------------+
| NEEDS-ACTION | Current | Section 3.8.1.11 of [RFC5545] |
+--------------+---------+-------------------------------+
| PENDING | Current | Section 11.2 of RFC 10051 |
+--------------+---------+-------------------------------+
| TENTATIVE | Current | Section 3.8.1.11 of [RFC5545] |
+--------------+---------+-------------------------------+
Table 3: Initial Contents of the STATUS Values Registry
15.4. SUBSTATE Values Registry
IANA has created a new iCalendar registry called "SUBSTATE Values"
for values of the "SUBSTATE" property defined in Section 10.3.
Additional values MAY be used, provided the process of Standards
Action with Expert Review described in Section 8.2.1 of [RFC5545] is
used to register them, using the template in Section 8.2.6 of
[RFC5545].
The initial contents of the "SUBSTATE Values" registry are as
follows:
+===========+=========+===========================+
| Substate | Status | Reference |
+===========+=========+===========================+
| OK | Current | Section 10.3 of RFC 10051 |
+-----------+---------+---------------------------+
| ERROR | Current | Section 10.3 of RFC 10051 |
+-----------+---------+---------------------------+
| SUSPENDED | Current | Section 10.3 of RFC 10051 |
+-----------+---------+---------------------------+
Table 4: Initial Contents of the SUBSTATE
Values Registry
15.5. TASK-MODE Values Registry
IANA has created a new iCalendar registry called "TASK-MODE Values"
for values of the "TASK-MODE" property defined in Section 10.4.
Additional values MAY be used, provided the process of Standards
Action with Expert Review described in Section 8.2.1 of [RFC5545] is
used to register them, using the template in Section 8.2.6 of
[RFC5545].
The initial contents of the "TASK-MODE Values" registry are as
follows:
+======================+=========+===========================+
| Task Mode | Status | Reference |
+======================+=========+===========================+
| AUTOMATIC-COMPLETION | Current | Section 10.4 of RFC 10051 |
+----------------------+---------+---------------------------+
| AUTOMATIC-FAILURE | Current | Section 10.4 of RFC 10051 |
+----------------------+---------+---------------------------+
| AUTOMATIC | Current | Section 10.4 of RFC 10051 |
+----------------------+---------+---------------------------+
| CLIENT | Current | Section 10.4 of RFC 10051 |
+----------------------+---------+---------------------------+
| SERVER | Current | Section 10.4 of RFC 10051 |
+----------------------+---------+---------------------------+
Table 5: Initial Contents of the TASK-MODE Values Registry
15.6. Participation Statuses Registry
IANA has added the following new iCalendar participation status to
the "Participation Statuses" registry defined in Section 8.3.7 of
[RFC5545] and located here: <https://www.iana.org/assignments/
icalendar>.
+======================+=========+==========================+
| Participation Status | Status | Reference |
+======================+=========+==========================+
| FAILED | Current | Section 9.1 of RFC 10051 |
+----------------------+---------+--------------------------+
Table 6: Participation Statuses Registry
16. References
16.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC4791] Daboo, C., Desruisseaux, B., and L. Dusseault,
"Calendaring Extensions to WebDAV (CalDAV)", RFC 4791,
DOI 10.17487/RFC4791, March 2007,
<https://www.rfc-editor.org/info/rfc4791>.
[RFC4918] Dusseault, L., Ed., "HTTP Extensions for Web Distributed
Authoring and Versioning (WebDAV)", RFC 4918,
DOI 10.17487/RFC4918, June 2007,
<https://www.rfc-editor.org/info/rfc4918>.
[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234,
DOI 10.17487/RFC5234, January 2008,
<https://www.rfc-editor.org/info/rfc5234>.
[RFC5545] Desruisseaux, B., Ed., "Internet Calendaring and
Scheduling Core Object Specification (iCalendar)",
RFC 5545, DOI 10.17487/RFC5545, September 2009,
<https://www.rfc-editor.org/info/rfc5545>.
[RFC5546] Daboo, C., Ed., "iCalendar Transport-Independent
Interoperability Protocol (iTIP)", RFC 5546,
DOI 10.17487/RFC5546, December 2009,
<https://www.rfc-editor.org/info/rfc5546>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC9073] Douglass, M., "Event Publishing Extensions to iCalendar",
RFC 9073, DOI 10.17487/RFC9073, August 2021,
<https://www.rfc-editor.org/info/rfc9073>.
[RFC9074] Daboo, C. and K. Murchison, Ed., ""VALARM" Extensions for
iCalendar", RFC 9074, DOI 10.17487/RFC9074, August 2021,
<https://www.rfc-editor.org/info/rfc9074>.
[RFC9253] Douglass, M., "Support for iCalendar Relationships",
RFC 9253, DOI 10.17487/RFC9253, August 2022,
<https://www.rfc-editor.org/info/rfc9253>.
16.2. Informative References
[BPMN] Object Management Group, "Business Process Model and
Notation", Version 2.0.2, January 2014,
<https://www.omg.org/spec/BPMN/2.0.2/About-BPMN>.
[TARCH] CalConnect, "Task Architecture V 1.0",
<https://www.calconnect.org/docs/architectures/
Task%20Architecture%201.0.pdf>.
[WfRP] Russell, N., ter Hofstede, A.H.M., Edmond, T., and W.M.P.
van der Aalst, "Workflow Resource Patterns", BETA Working
Paper Series, WP 127, 2004,
<http://www.workflowpatterns.com/patterns/resource/>.
[WsCalendar]
"WS-Calendar Version 1.0", OASIS Committee Specification
01, 30 July 2011, <https://docs.oasis-open.org/ws-
calendar/ws-calendar-spec/v1.0/cs01/ws-calendar-spec-
v1.0-cs01.pdf>.
Appendix A. Examples of Task State Lifecycle
A.1. Simple Case Status Change
The following is an example of status changes when 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 | Overall state set by either |
| | | | the Organizer for TASK- |
| | | | MODE=CLIENT or the server |
| | | | for AUTOMATIC-COMPLETION |
+---+--------------+--------------+-----------------------------+
Table 7: Example of Status Changes in Assigning and
Performing a Task with One "Attendee"
A.2. Example for Multiple "Attendees"
The following is an example of status changes when assigning and
performing a task with two "Attendees" (A1 and A2).
+==+============+============+==============+=======================+
| |STATUS |PARTSTAT | PARTSTAT | Action |
| | |(A1) | (A2) | |
+==+============+============+==============+=======================+
|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 | Overall state set |
| | | | | once both |
| | | | | "Attendees" are |
| | | | | finished. May be |
| | | | | set by either the |
| | | | | Organizer for TASK- |
| | | | | MODE=CLIENT or the |
| | | | | server for |
| | | | | AUTOMATIC-COMPLETION |
+--+------------+------------+--------------+-----------------------+
Table 8: Example for Multiple "Attendees"
| NOTE: The logic for determining the status change to the
| "VTODO" calendar component is determined by the Task Organizer
| based on the "ATTENDEE" property status and other business
| logic.
A.3. Example of Failure
The following is an 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 | Overall state set by Organizer |
| | | | for TASK-MODE=CLIENT or by |
| | | | server for AUTOMATIC-FAILURE |
+---+--------------+--------------+--------------------------------+
Table 9: Example of Failure
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, and Ken Murchison.
The authors would also like to thank CalConnect, the Calendaring and
Scheduling Consortium, for advice with this specification.
Authors' Addresses
Adrian Apthorp
DHL Express
Fritz-Erler-Str. 5
Bonn
Germany
Email: adrian.apthorp@dhl.com
Michael Douglass
Bedework Commercial Services
226 3rd Street
Troy, NY
United States of America
Email: mdouglass@bedework.com
Contents 56
- Abstract
- Status of This Memo
- Copyright Notice
- Table of Contents
- 1 Introduction
- 1.1 Terms and Definitions
- 2 Task Architecture
- 2.1 Task Architecture Elements
- 2.2 Architecture Foundations
- 3 Task Extensions
- 4 Task Specification
- 4.1 Task Type
- 4.2 Task Context and Relationships
- 5 Task Deadlines, Milestones, and Time Planning
- 5.1 Deadlines
- 5.2 Milestones
- 6 Task Scheduling and Assignment
- 7 Status Reporting
- 7.1 Improved Granularity in Status Reporting Information
- 7.2 Comments Associated to Reasons and Status Changes
- 7.3 Updating the Overall Status
- 7.4 Relating Reason and Comments to "ATTENDEE" Property Status Changes
- 7.5 Task Alerts and Notifications
- 7.6 Automated Status Changes
- 8 Modifications to Calendar Components
- 9 New Parameter Values
- 9.1 Redefined VTODO Participant Status
- 10 New Properties
- 10.1 Estimated Duration
- 10.2 Reason
- 10.3 Substate
- 10.4 Task Mode
- 11 Property Extensions and Clarifications
- 11.1 Updated DURATION Property Definition for VTODO
- 11.2 Redefined STATUS Property
- 12 New Components
- 12.1 Status Component
- 13 CalDAV Support for Task Mode
- 13.1 CALDAV:supported-task-mode-set Property
- 14 Security Considerations
- 15 IANA Considerations
- 15.1 Component Registration
- 15.2 Property Registrations
- 15.3 STATUS Values Registry
- 15.4 SUBSTATE Values Registry
- 15.5 TASK-MODE Values Registry
- 15.6 Participation Statuses Registry
- 16 References
- 16.1 Normative References
- 16.2 Informative References
- A Examples of Task State Lifecycle
- A.1 Simple Case Status Change
- A.2 Example for Multiple "Attendees"
- A.3 Example of Failure
- Acknowledgements
- Authors' Addresses