< draft-ietf-calext-ical-tasks-02.txt   draft-ietf-calext-ical-tasks-03.txt >
Network Working Group A. Apthorp Network Working Group A. Apthorp
Internet-Draft DHL Express Internet-Draft DHL Express
Updates: 5545 (if approved) M. Douglass Updates: 5545 (if approved) M. Douglass
Intended status: Standards Track Bedework Commercial Services Intended status: Standards Track Bedework Commercial Services
Expires: 8 September 2022 7 March 2022 Expires: 22 September 2022 21 March 2022
Task Extensions to iCalendar Task Extensions to iCalendar
draft-ietf-calext-ical-tasks-02 draft-ietf-calext-ical-tasks-03
Abstract Abstract
This document defines extensions to the Internet Calendaring and This document defines extensions to the Internet Calendaring and
Scheduling Core Object Specification (iCalendar) (RFC5545) to provide Scheduling Core Object Specification (iCalendar) (RFC5545) to provide
improved status tracking, scheduling and specification of tasks. improved status tracking, scheduling and specification of tasks.
It also defines how Calendaring Extensions to WebDAV (CalDAV) (RFC It also defines how Calendaring Extensions to WebDAV (CalDAV) (RFC
4791) servers can be extended to support certain automated task 4791) servers can be extended to support certain automated task
management behaviours. management behaviours.
skipping to change at page 1, line 37 skipping to change at page 1, line 37
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on 8 September 2022. This Internet-Draft will expire on 22 September 2022.
Copyright Notice Copyright Notice
Copyright (c) 2022 IETF Trust and the persons identified as the Copyright (c) 2022 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/ Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document. license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
skipping to change at page 2, line 31 skipping to change at page 2, line 31
5. Architecture Foundations . . . . . . . . . . . . . . . . . . 8 5. Architecture Foundations . . . . . . . . . . . . . . . . . . 8
6. Task Extensions . . . . . . . . . . . . . . . . . . . . . . . 9 6. Task Extensions . . . . . . . . . . . . . . . . . . . . . . . 9
7. Task Specification . . . . . . . . . . . . . . . . . . . . . 9 7. Task Specification . . . . . . . . . . . . . . . . . . . . . 9
7.1. CONCEPT for task type identification . . . . . . . . . . 10 7.1. CONCEPT for task type identification . . . . . . . . . . 10
7.2. Task Context and Relationships . . . . . . . . . . . . . 10 7.2. Task Context and Relationships . . . . . . . . . . . . . 10
7.3. Task Domain Data Handling . . . . . . . . . . . . . . . . 10 7.3. Task Domain Data Handling . . . . . . . . . . . . . . . . 10
8. Task Deadlines, Milestones and Time Planning . . . . . . . . 11 8. Task Deadlines, Milestones and Time Planning . . . . . . . . 11
9. Task Scheduling and Assignment . . . . . . . . . . . . . . . 11 9. Task Scheduling and Assignment . . . . . . . . . . . . . . . 11
10. Status Reporting . . . . . . . . . . . . . . . . . . . . . . 12 10. Status Reporting . . . . . . . . . . . . . . . . . . . . . . 12
10.1. Improved granularity in status reporting information . . 12 10.1. Improved granularity in status reporting information . . 12
10.2. Relating comments to status . . . . . . . . . . . . . . 12 10.2. Relating reason and comments to ATTENDEE status
changes. . . . . . . . . . . . . . . . . . . . . . . . . 12
10.3. Comments associated to reasons and status changes . . . 12 10.3. Comments associated to reasons and status changes . . . 12
10.4. Task Alerts and Notifications . . . . . . . . . . . . . 12 10.4. Task Alerts and Notifications . . . . . . . . . . . . . 13
10.5. Automated Status Changes . . . . . . . . . . . . . . . . 13 10.5. Automated Status Changes . . . . . . . . . . . . . . . . 14
11. New Property Parameters . . . . . . . . . . . . . . . . . . . 13 11. New Parameter Values . . . . . . . . . . . . . . . . . . . . 14
11.1. Group . . . . . . . . . . . . . . . . . . . . . . . . . 13 11.1. Redefined VTODO Participant Status . . . . . . . . . . . 14
11.2. Reason . . . . . . . . . . . . . . . . . . . . . . . . . 14 12. New Properties . . . . . . . . . . . . . . . . . . . . . . . 14
11.3. Modified . . . . . . . . . . . . . . . . . . . . . . . . 14 12.1. Estimated Duration . . . . . . . . . . . . . . . . . . . 14
11.4. Sub-State . . . . . . . . . . . . . . . . . . . . . . . 15 12.2. Reason . . . . . . . . . . . . . . . . . . . . . . . . . 15
12. New Parameter Values . . . . . . . . . . . . . . . . . . . . 16 12.3. Sub-State . . . . . . . . . . . . . . . . . . . . . . . 16
12.1. Redefined VTODO Participant Status . . . . . . . . . . . 16 12.4. Task Mode . . . . . . . . . . . . . . . . . . . . . . . 17
13. New Properties . . . . . . . . . . . . . . . . . . . . . . . 16 13. Property Extensions and Clarifications . . . . . . . . . . . 18
13.1. Estimated Duration . . . . . . . . . . . . . . . . . . . 16 13.1. Redefined STATUS Property . . . . . . . . . . . . . . . 19
13.2. Task Mode . . . . . . . . . . . . . . . . . . . . . . . 17 14. New Components . . . . . . . . . . . . . . . . . . . . . . . 19
14. Property Extensions and Clarifications . . . . . . . . . . . 18 14.1. Status Component . . . . . . . . . . . . . . . . . . . . 19
14.1. The ATTENDEE property . . . . . . . . . . . . . . . . . 19 15. CalDAV Support for Task Mode . . . . . . . . . . . . . . . . 20
14.2. Redefined COMMENT Property Parameter List . . . . . . . 19 15.1. CALDAV:supported-task-mode-set Property . . . . . . . . 21
14.3. Redefined STATUS Property . . . . . . . . . . . . . . . 20 16. Security Considerations . . . . . . . . . . . . . . . . . . . 22
15. New Components . . . . . . . . . . . . . . . . . . . . . . . 20 17. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22
15.1. Status Component . . . . . . . . . . . . . . . . . . . . 20 17.1. Initialization of the Status registry . . . . . . . . . 22
16. CalDAV Support for Task Mode . . . . . . . . . . . . . . . . 22 17.2. Update of the Status registry . . . . . . . . . . . . . 22
16.1. CALDAV:supported-task-mode-set Property . . . . . . . . 22 17.3. Sub-State value registry . . . . . . . . . . . . . . . . 23
17.4. Task Mode value registry . . . . . . . . . . . . . . . . 23
17. Security Considerations . . . . . . . . . . . . . . . . . . . 23 17.5. Participation Statuses registry . . . . . . . . . . . . 24
18. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 17.6. Properties registry . . . . . . . . . . . . . . . . . . 24
18.1. Initialization of the Status registry . . . . . . . . . 23 18. Normative References . . . . . . . . . . . . . . . . . . . . 24
18.2. Update of the Status registry . . . . . . . . . . . . . 24 19. Informative References . . . . . . . . . . . . . . . . . . . 25
18.3. Sub-State value registry . . . . . . . . . . . . . . . . 24 Appendix A. Examples of Task State Lifecycle . . . . . . . . . . 26
18.4. Task Mode value registry . . . . . . . . . . . . . . . . 25 A.1. Simple Case Status Change . . . . . . . . . . . . . . . . 26
18.5. Participation Statuses registry . . . . . . . . . . . . 25 A.2. Example for multiple Attendees . . . . . . . . . . . . . 26
18.6. Properties registry . . . . . . . . . . . . . . . . . . 25 A.3. Example of Failure . . . . . . . . . . . . . . . . . . . 28
18.7. Parameters registry . . . . . . . . . . . . . . . . . . 26 Appendix B. Change log . . . . . . . . . . . . . . . . . . . . . 28
19. Normative References . . . . . . . . . . . . . . . . . . . . 26 Appendix C. Working Notes . . . . . . . . . . . . . . . . . . . 29
20. Informative References . . . . . . . . . . . . . . . . . . . 27 C.1. Advertising tasks . . . . . . . . . . . . . . . . . . . . 29
Appendix A. Examples of Task State Lifecycle . . . . . . . . . . 28 C.2. Subscribing to task updates . . . . . . . . . . . . . . . 29
A.1. Simple Case Status Change . . . . . . . . . . . . . . . . 28 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 29
A.2. Example for multiple Attendees . . . . . . . . . . . . . 28
A.3. Example of Failure . . . . . . . . . . . . . . . . . . . 30
Appendix B. Change log . . . . . . . . . . . . . . . . . . . . . 30
Appendix C. Working Notes . . . . . . . . . . . . . . . . . . . 31
C.1. Advertising tasks . . . . . . . . . . . . . . . . . . . . 31
C.2. Subscribing to task updates . . . . . . . . . . . . . . . 31
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 31
1. Acknowledgements 1. Acknowledgements
The authors would like to thank the members of the Calendaring and The authors would like to thank the members of the Calendaring and
Scheduling Consortium technical committees and the following Scheduling Consortium technical committees and the following
individuals for contributing their ideas, support and comments: individuals for contributing their ideas, support and comments:
John Chaffee, Marten Gajda, Ken Murchison John Chaffee, Marten Gajda, Ken Murchison
The authors would also like to thank CalConnect, the Calendaring and The authors would also like to thank CalConnect, the Calendaring and
skipping to change at page 12, line 13 skipping to change at page 12, line 13
perform the task. perform the task.
The offering or advertising of a task to one or more (potential) 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 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]. task will be addressed by a new VPOLL mode (See Appendix B) [VPOLL].
10. Status Reporting 10. Status Reporting
10.1. Improved granularity in status reporting information 10.1. Improved granularity in status reporting information
This document defines new status parameters that can be applied to This document defines a new status component that can be used to
the VTODO status (STATUS) property, as well as the participant status group related information about the status. This might include
(PARTSTAT) parameter. These new parameters provide additional information on why (REASON) and when (DTSTAMP) a status has changed.
information on why (REASON) and when (MODIFIED) a status has changed. In addition new status values are specified to provide for task
In addition to these parameters new status values are specified to suspension, failure and preparation.
provide for task suspension, failure and preparation.
10.2. Relating comments to status 10.2. Relating reason and comments to ATTENDEE status changes.
The GROUP parameter is used with the STATUS or ATTENDEE properties to The [RFC9073] PARTICIPANT component can be used to provide additional
relate an associated COMMENT property. The COMMENT property can then information about why an ATTENDEE participation status has changed.
be used to include additional human readable information about why The COMMENT property can also be used to include additional human
the associated STATUS or ATTENDEE property changed. readable information about why the associated STATUS or ATTENDEE
property changed.
STATUS;REASON="http://example.com/reason/delivery-failed"; BEGIN:VSTATUS
SUBSTATE=ERROR;MODIFIED=20130212T120000Z;GROUP=G1:FAILED STATUS:FAILED
COMMENT;MODIFIED=20130226T110451Z;GROUP=G1:Breakdown REASON:http://example.com/reason/delivery-failed
ATTENDEE;PARTSTAT=FAILED;MODIFIED=20130226T1104510Z;GROUP=G2: SUBSTATE:ERROR
REASON="http://example.com/reason/van-break-down": DTSTAMP:20130212T120000Z
mailto:xxx@example.com COMMENT:Breakdown
COMMENT;MODIFIED=20130226T110451Z;GROUP=G2:Puncture END:VSTATUS
ATTENDEE;PARTSTAT=FAILED:mailto:xxx@example.com
...
BEGIN:PARTICIPANT
CALENDAR-ADDRESS:mailto:xxx@example.com
DTSTAMP:20130226T1104510Z
REASON:http://example.com/reason/van-break-down
COMMENT:Puncture
END:PARTICIPANT
10.3. Comments associated to reasons and status changes 10.3. Comments associated to reasons and status changes
Reasons may be associated directly with a comment, allowing for Multiple comments and reasons may have the same status. As
multiple reasons associated with a status to each have a comment situations chnage further VSTATUS components can be added to provide
associated with them [EDISTS]. additional information..
CONCEPT:http://example.com/task/delivery CONCEPT:http://example.com/task/delivery
STATUS;SUBSTATE=ERROR;MODIFIED=20130212T120000Z;GROUP=G1:FAILED BEGIN:VSTATUS
COMMENT;MODIFIED=20130226T110451Z;GROUP=G1:Out of time STATUS:FAILED
COMMENT;REASON="http://example.com/reason/traffic"; SUBSTATE:ERROR
MODIFIED=20130226T110451Z;GROUP=G1:Traffic Accident on E44 DTSTAMP:20220212T104900Z
COMMENT;REASON="http://example.com/reason/closed"; COMMENT:Out of time
MODIFIED=20130226T110451Z;GROUP=G1:Arrived after office hours END:VSTATUS
BEGIN:VSTATUS
STATUS:FAILED
COMMENT:Traffic Accident on E44
REASON:http://example.com/reason/traffic
DTSTAMP:20220212T110451Z
END:VSTATUS
BEGIN:VSTATUS
STATUS:FAILED
COMMENT:Arrived after office hours
REASON:http://example.com/reason/closed
DTSTAMP:20220212T180451Z
END:VSTATUS
10.4. Task Alerts and Notifications 10.4. Task Alerts and Notifications
Different needs to alert or notify task actors of pending or actual Different needs to alert or notify task actors of pending or actual
task status changes are recognized: task status changes are recognized:
Alarms Alarms (VLARM components) operate in the calendar user agent Alarms Alarms (VLARM components) operate in the calendar user agent
space to notify the task actor of a pending task state for a task 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 they are assigned to or are interested in. Note: there is no
constraint in the current standards on the propagation of alarms constraint in the current standards on the propagation of alarms
skipping to change at page 13, line 31 skipping to change at page 14, line 10
against certain components e.g. ALARM, to identify which task against certain components e.g. ALARM, to identify which task
events the stakeholder/party is interested in. Notifications on events the stakeholder/party is interested in. Notifications on
shared calendars will allow task actors to register an interest in shared calendars will allow task actors to register an interest in
changes to tasks within a calendar (see Appendix A). changes to tasks within a calendar (see Appendix A).
10.5. Automated Status Changes 10.5. Automated Status Changes
A new property, TASK-MODE, is introduced to instruct servers to apply A new property, TASK-MODE, is introduced to instruct servers to apply
automated operations for changing the status of a task. automated operations for changing the status of a task.
11. New Property Parameters 11. New Parameter Values
11.1. Group
Parameter name GROUP
Purpose This parameter allows the association of different (usually)
multiply occurring properties.
Format Definition This parameter is defined by the following
notation:
groupparam = "GROUP" "=" text
*("," text)
Description The value of this parameter is free-form text that
creates an identifier for associated properties. All properties
that use the same GROUP value are associated through that value.
For example, multiple comments and an attendee may be associated
with a status value.
Example The following is an example of this property.
GROUP=G1
11.2. Reason
Parameter name REASON
Purpose To indicate the reason for a change in status of a task or
attendee participation status.
Format Definition This parameter is defined by the following
notation:
reasonparam = "REASON" "=" DQUOTE uri DQUOTE
*("," DQUOTE uri DQUOTE)
Description This property parameter allows the change in status of a
task or participant status to be qualified by the reason for the
change with a codified reason. Typically reasons are defined
within the context of the task type and therefore SHOULD include
the name-space of the authority defining the task. Common reason
codes are IANA registered and do not have a name-space prefix.
Example
STATUS;REASON="http://example.com/reason/delivered-on-time";
MODIFIED=20130212T120000Z;GROUP=G1:COMPLETED
ATTENDEE;REASON="x-example-reason:out-of-office";
PARTSTAT=DECLINED;MODIFIED=20130212T120000Z;
GROUP=123:mailto:cyrus@example.com
11.3. Modified
Parameter name MODIFIED
Purpose To specify the time and date of when the status of a task or
attendee participant status changed.
Format Definition This parameter is defined by the following
notation:
modifiedparam = "MODIFIED" "=" date-time
Description The modified parameter allows the specification of the
date time of when a status (STATUS) or participant status
(PARTSTAT) changed. It MUST be specified in the UTC time format.
The value of MODIFIED SHOULD be set at the time when the
associated status (either STATUS or PARTSTAT)is changed.
Therefore either a client or server may set the value of MODIFIED
depending on which is updating the value of STATUS or PARTSTAT.
For backwards compatibility if the server detects that MODIFIED
should have changed but wasn't (for example the client doesn't
support MODIFIED) then the server MAY set MODIFIED
retrospectively.
Example
STATUS;REASON=""http://example.com/reason/delivered-on-time";
MODIFIED=20130212T120000Z;GROUP=G1:COMPLETED
11.4. Sub-State
Parameter name SUBSTATE
Purpose To provide additional granularity of task status for e.g.
IN-PROCESS.
Format Definition This parameter is defined by the following
notation:
substateparam = "SUBSTATE" "="
( "OK" ; everything is fine(the default)
/ "ERROR" ; something is wrong (the REASON
; code explains why)
/ "SUSPENDED" ; waiting on some other task to
; complete or availability of a
; resource (REASON code explains
; why)
/ x-name ; Experimental type
/ iana-token) ; Other IANA-registered type
Description The sub-state parameter allows additional qualification
and granularity of states to be recorded, in particular for the
IN-PROCESS state. It allows individual sub-states to be recorded
without the need to define and publish a sub-task associated with
a parent task purely to track that a particular state has been
reached. This property also allows parallel states to be
expressed e.g. that a task has been suspended at whatever state it
has reached.
Example
STATUS;REASON="http://example.com/reason/no-one-home";
SUBSTATE=ERROR:FAILED
STATUS;REASON="http://example.com/reason/paint-drying";
SUBSTATE=SUSPENDED:IN-PROCESS
12. New Parameter Values
12.1. Redefined VTODO Participant Status 11.1. Redefined VTODO Participant Status
Participant status parameter type values are defined in Participant status parameter type values are defined in
Section 3.2.12 of [RFC5545]. This specification redefines that type Section 3.2.12 of [RFC5545]. This specification redefines that type
to include the new value FAILED for VTODO iCalendar components. to include the new value FAILED for VTODO iCalendar components.
Format Definition This property parameter is extended by the Format Definition This property parameter is extended by the
following notation: following notation:
partstat-todo /= *("FAILED") ; To-do cannot be completed partstat-todo /= *("FAILED") ; To-do cannot be completed
Example Example
ATTENDEE;REASON="http://example.com/reason/not-enough-time"; ATTENDEE;REASON="http://example.com/reason/not-enough-time";
PARTSTAT=FAILED:mailto:jsmith@example.com PARTSTAT=FAILED:mailto:jsmith@example.com
13. New Properties 12. New Properties
13.1. Estimated Duration 12.1. Estimated Duration
Property Name ESTIMATED-DURATION Property Name ESTIMATED-DURATION
Purpose This property specifies the estimated positive duration of Purpose This property specifies the estimated positive duration of
time the corresponding task will take to complete. time the corresponding task will take to complete.
Value Type DURATION Value Type DURATION
Property Parameters IANA and non-standard property parameters can be Property Parameters IANA and non-standard property parameters can be
specified on this property. specified on this property.
skipping to change at page 16, line 47 skipping to change at page 15, line 4
Conformance This property can be specified in "VTODO" calendar Conformance This property can be specified in "VTODO" calendar
components. components.
Format Definition This property is defined by the following Format Definition This property is defined by the following
notation: notation:
est-duration = "ESTIMATED-DURATION" durparam ":" dur-value CRLF est-duration = "ESTIMATED-DURATION" durparam ":" dur-value CRLF
;consisting of a positive duration of time. ;consisting of a positive duration of time.
durparam = *(";" other-param) durparam = *(";" other-param)
Description In a "VTODO" calendar component the property MAY be used Description In a "VTODO" calendar component the property MAY be used
to specify the estimated duration for the to-do, with or without to specify the estimated duration for the to-do, with or without
an explicit time window in which the event should be started and an explicit time window in which the event should be started and
completed. When present, DTSTART and DUE/DURATION represent the completed. When present, DTSTART and DUE/DURATION represent the
window in which the task can be performed. ESTIMATED-DURATION window in which the task can be performed. ESTIMATED-DURATION
SHOULD be passed from ORGANIZER to ATTENDEE in iTIP [RFC5546] SHOULD be passed from ORGANIZER to ATTENDEE in iTIP [RFC5546]
messages. messages.
Example The following is an example of this property that specifies Example The following is an example of this property that specifies
an interval of time of exactly one hour: an interval of time of exactly one hour:
ESTIMATED-DURATION:PT1H ESTIMATED-DURATION:PT1H
13.2. Task Mode 12.2. 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:
reason = "REASON" reasonparam ":" uri CRLF
reasonparam = *(";" other-param)
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
REASON:http://example.com/reason/delivered-on-time
REASON:out-of-office
12.3. 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:
substate = "SUBSTATE" substateparam ":" substatevalue CRLF
substateparam = *(";" other-param)
substatevalue = ("OK" ; everything is fine(the default)
/ "ERROR" ; something is wrong (the REASON
; code explains why)
/ "SUSPENDED" ; waiting on some other task to
; complete or availability of a
; resource (REASON code explains
; why)
/ iana-token) ; Other IANA-registered type
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
BEGIN:VSTATUS
STATUS:FAILED
REASON:http://example.com/reason/no-one-home
SUBSTATE:ERROR
END:VSTATUS
BEGIN:VSTATUS
STATUS:IN-PROCESS
REASON:http://example.com/reason/paint-drying
SUBSTATE:SUSPENDED
END:VSTATUS
12.4. Task Mode
Property Name TASK-MODE Property Name TASK-MODE
Purpose This property specifies automatic operations that servers Purpose This property specifies automatic operations that servers
apply to tasks based on changes in attendee status (PARTSTAT). apply to tasks based on changes in attendee status (PARTSTAT).
Value Type TEXT Value Type TEXT
Property Parameters IANA and non-standard property parameters can be Property Parameters IANA and non-standard property parameters can be
specified on this property. specified on this property.
skipping to change at page 18, line 50 skipping to change at page 18, line 50
SERVER Task Mode The task mode value "SERVER" indicates to the SERVER Task Mode The task mode value "SERVER" indicates to the
server that it can change the "VTODO" component's STATUS property server that it can change the "VTODO" component's STATUS property
value to an appropriate value, based on implementation defined value to an appropriate value, based on implementation defined
"business rules", as ATTENDEE responses are processed or as "business rules", as ATTENDEE responses are processed or as
deadlines related to the task pass. deadlines related to the task pass.
The server can add this property to a "VTODO" component to The server can add this property to a "VTODO" component to
indicate to the client that it will be managing the status. indicate to the client that it will be managing the status.
14. Property Extensions and Clarifications 13. Property Extensions and Clarifications
14.1. The ATTENDEE property 13.1. Redefined STATUS Property
The Attendee property is defined in Section 3.8.4.1 of [RFC5545].
This specification extends that property to include new parameters to
indicate the reason for a participant status change (See Appendix A)
and sub-states.
Format Definition This property is defined by the following
notation:
attendee = "ATTENDEE" attparam ":" cal-address CRLF
attparam /= *(
;
; The following are OPTIONAL,
; but MUST NOT occur more than once.
;
(";" reasonparam)
(";" modifiedparam)
(";" substateparam)
)
Example: The following are examples of this property's use for tasks:
ATTENDEE;PARTSTAT=DECLINED;MODIFIED=20130212T120000Z;GROUP=G1;
REASON="http://example.com/reason/too-busy":mailto:xxx@example.com
ATTENDEE;PARTSTAT=IN-PROCESS;MODIFIED=20130212T120000Z;
SUBSTATE=X-EXAMPLE-STEP-1:mailto:xxx@example.com
14.2. Redefined COMMENT Property Parameter List
The Comment property is defined in Section 3.8.1.4 of [RFC5545].
Format Definition The "COMMENT" property parameter list is augmented
as follows:
commparam /= *(
; The following are OPTIONAL,
; but MUST NOT occur more than once.
(";" reasonparam) /
(";" modifiedparam)
)
14.3. Redefined STATUS Property
The Status property is defined in Section 3.8.1.11 of [RFC5545]. The Status property is defined in Section 3.8.1.11 of [RFC5545].
This specification extends that property to include new parameters to This specification extends that property to include new values
indicate the reason for a status change as well as new values
associated with VTODO iCalendar components (See Appendix A for associated with VTODO iCalendar components (See Appendix A for
examples of the task state lifecycle). examples of the task state lifecycle).
Format Definition The "STATUS" property parameter list is augmented Format Definition The "STATUS" property parameter list is augmented
as follows: as follows:
statparam /= *(
; The following are OPTIONAL,
; but MUST NOT occur more than once.
;
(";" reasonparam)
(";" modifiedparam)
(";" substateparam) /
)
statvalue-todo = / "PENDING" ;Indicates a to-do has been statvalue-todo = / "PENDING" ;Indicates a to-do has been
;created and accepted, but has not ;created and accepted, but has not
;yet started. ;yet started.
/ "FAILED" ;Indicates to-do has failed. / "FAILED" ;Indicates to-do has failed.
;Extended status values for ;Extended status values for
;"VTODO". ;"VTODO".
Description: Description:
PENDING - A task has been created but has not yet started and is 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 ready to start subject to other dependencies (e.g. preceding task or
DTSTART). This is the default state. DTSTART). This is the default state.
FAILED - task has failed and may need some follow-up from the FAILED - task has failed and may need some follow-up from the
organizer to re-schedule or cancel organizer to re-schedule or cancel
Example: The following is an example of this property for a "VTODO" Example: The following is an example of this property for a "VTODO"
calendar component: calendar component:
STATUS;REASON="http://example.com/reason/delivery-failed"; STATUS:FAILED
SUBSTATE=ERROR;MODIFIED=20130212T120000Z;GROUP=G1:FAILED
15. New Components 14. New Components
15.1. Status Component 14.1. Status Component
Component Name VSTATUS 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 Purpose This component allows information to be associated with a
appropriate calendar component. status, for example comments and date stamps.
Description This component provides a way for multiple date-stamped Conformance This component can be specified multiple times in any
statuses to be associated with a component such as a task or an appropriate calendar component.
event.
This compoment may also be added to the <<RFC9073>> PARTICIPANT component Description This component provides a way for multiple date-stamped
to allow participants in a task to specify their own status. statuses to be associated with a component such as a task or an
event.
Figure 1 This compoment may also be added to the [RFC9073] PARTICIPANT
component to allow participants in a task to specify their own
status.
Format Definition This component is defined by the following Format Definition This component is defined by the following
notation: notation:
statusc = "BEGIN" ":" "VSTATUS" CRLF statusc = "BEGIN" ":" "VSTATUS" CRLF
statusprop statusprop
"END" ":" "VSTATUS" CRLF "END" ":" "VSTATUS" CRLF
statusprop = *( statusprop = *(
; ;
; The following is REQUIRED, ; The following is REQUIRED,
; but MUST NOT occur more than once. ; but MUST NOT occur more than once.
; ;
status / status /
; ;
; The following are OPTIONAL, ; The following are OPTIONAL,
; but MUST NOT occur more than once. ; but MUST NOT occur more than once.
; ;
description / dtstamp / description / dtstamp / reason / substate / summary
summary
; ;
; The following are OPTIONAL, ; The following are OPTIONAL,
; and MAY occur more than once. ; and MAY occur more than once.
; ;
comment / styleddescription / iana-prop comment / styleddescription / iana-prop
; ;
) )
Examples Examples
BEGIN:VSTATUS BEGIN:VSTATUS
STATUS;REASON="http://example.com/reason/delivered-on-time":COMPLETED STATUS:COMPLETED
DTSTAMP:20130212T120000Z REASON: http://example.com/reason/delivered-on-time
DTSTAMP:20220212T120000Z
END:VSTATUS END:VSTATUS
16. CalDAV Support for Task Mode 15. CalDAV Support for Task Mode
The CalDAV [RFC4791] calendar access protocol allows clients and The CalDAV [RFC4791] calendar access protocol allows clients and
servers to exchange iCalendar data. With the introduction of the servers to exchange iCalendar data. With the introduction of the
"TASK-MODE" property in this specification, different automated task "TASK-MODE" property in this specification, different automated task
management behaviours may be delegated to the server by the Task management behaviours may be delegated to the server by the Task
Organizer depending upon the value of "TASK-MODE". Organizer depending upon the value of "TASK-MODE".
In order for a CalDAV client to know what task modes are available, a In order for a CalDAV client to know what task modes are available, a
CalDAV server advertises a CALDAV:supported-task-mode-set WebDAV CalDAV server advertises a CALDAV:supported-task-mode-set WebDAV
property on calendar home or calendar collections if it supports the property on calendar home or calendar collections if it supports the
skipping to change at page 22, line 39 skipping to change at page 21, line 31
element containing a CALDAV:supported-task-mode XML element, if a element containing a CALDAV:supported-task-mode XML element, if a
client attempts to store iCalendar data with an "TASK-MODE" element client attempts to store iCalendar data with an "TASK-MODE" element
value not supported by the server. value not supported by the server.
It is possible for a "TASK-MODE" value to be present in calendar data 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 on the server being accessed by a client that does not support the
"TASK-MODE" property. It is expected that existing clients, unaware "TASK-MODE" property. It is expected that existing clients, unaware
of "TASK-MODE", will fail gracefully by ignoring the calendar of "TASK-MODE", will fail gracefully by ignoring the calendar
property. property.
16.1. CALDAV:supported-task-mode-set Property 15.1. CALDAV:supported-task-mode-set Property
Name supported-task-mode-set Name supported-task-mode-set
Namespace urn:ietf:params:xml:ns:caldav Namespace urn:ietf:params:xml:ns:caldav
Purpose Enumerates the set of supported iCalendar "TASK-MODE" Purpose Enumerates the set of supported iCalendar "TASK-MODE"
element values supported by the server. element values supported by the server.
Protected This property MUST be protected and SHOULD NOT be returned Protected This property MUST be protected and SHOULD NOT be returned
by a PROPFIND allprop request (as defined in Section 14.2 of by a PROPFIND allprop request (as defined in Section 14.2 of
skipping to change at page 23, line 11 skipping to change at page 22, line 4
[RFC4918]). [RFC4918]).
Description See above. Description See above.
Definition Definition
<!ELEMENT supported-task-mode-set(supported-task-mode*)> <!ELEMENT supported-task-mode-set(supported-task-mode*)>
<!ELEMENT supported-task-mode (#PCDATA)> <!ELEMENT supported-task-mode (#PCDATA)>
<!-- PCDATA value: string - case insensitive but <!-- PCDATA value: string - case insensitive but
uppercase preferred --> uppercase preferred -->
Example Example
<C:supported-task-mode-set xmlns:C="urn:ietf:params:xml:ns:caldav"> <C:supported-task-mode-set xmlns:C="urn:ietf:params:xml:ns:caldav">
<C:supported-task-mode>AUTOMATIC-COMPLETION</C:supported-task-mode> <C:supported-task-mode>AUTOMATIC-COMPLETION</C:supported-task-mode>
<C:supported-task-mode>AUTOMATIC-FAILURE</C:supported-task-mode> <C:supported-task-mode>AUTOMATIC-FAILURE</C:supported-task-mode>
<C:supported-task-mode>SERVER</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>CLIENT</C:supported-task-mode>
</C:supported-task-mode-set> </C:supported-task-mode-set>
17. Security Considerations 16. Security Considerations
This specification introduces no new security considerations beyond This specification introduces no new security considerations beyond
those identified in [RFC5545]. those identified in [RFC5545].
18. IANA Considerations 17. IANA Considerations
18.1. Initialization of the Status registry 17.1. Initialization of the Status registry
This specification updates [RFC5545] by adding a Status value This specification updates [RFC5545] by adding a Status value
registry to the iCalendar Elements registry and initializing it as registry to the iCalendar Elements registry and initializing it as
per [RFC5545]. per [RFC5545].
+==============+=========+===============================+ +==============+=========+===============================+
| Name | Status | Reference | | Name | Status | Reference |
+==============+=========+===============================+ +==============+=========+===============================+
| CANCELLED | Current | Section 3.8.1.11 of [RFC5545] | | CANCELLED | Current | Section 3.8.1.11 of [RFC5545] |
+--------------+---------+-------------------------------+ +--------------+---------+-------------------------------+
skipping to change at page 24, line 27 skipping to change at page 22, line 48
+--------------+---------+-------------------------------+ +--------------+---------+-------------------------------+
| IN-PROCESS | 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] | | NEEDS-ACTION | Current | Section 3.8.1.11 of [RFC5545] |
+--------------+---------+-------------------------------+ +--------------+---------+-------------------------------+
| TENTATIVE | Current | Section 3.8.1.11 of [RFC5545] | | TENTATIVE | Current | Section 3.8.1.11 of [RFC5545] |
+--------------+---------+-------------------------------+ +--------------+---------+-------------------------------+
Table 1: Initial Status Value Registry Table 1: Initial Status Value Registry
18.2. Update of the Status registry 17.2. Update of the Status registry
This specification further updates the Status registry with This specification further updates the Status registry with
additional values defined in this document. additional values defined in this document.
+=========+=========+=========================+ +=========+=========+=========================+
| Value | Status | Reference | | Value | Status | Reference |
+=========+=========+=========================+ +=========+=========+=========================+
| PENDING | Current | This Spec, Section 14.3 | | PENDING | Current | This Spec, Section 13.1 |
+---------+---------+-------------------------+ +---------+---------+-------------------------+
| FAILED | Current | This Spec, Section 14.3 | | FAILED | Current | This Spec, Section 13.1 |
+---------+---------+-------------------------+ +---------+---------+-------------------------+
Table 2: Updated Status Value Registry Table 2: Updated Status Value Registry
18.3. Sub-State value registry 17.3. Sub-State value registry
The following table has been used to initialize the Sub-State The following table has been used to initialize the Sub-State
registry. registry.
+===========+=========+=========================+ +===========+=========+=========================+
| Substate | Status | Reference | | Substate | Status | Reference |
+===========+=========+=========================+ +===========+=========+=========================+
| OK | Current | This Spec, Section 11.4 | | OK | Current | This Spec, Section 12.3 |
+-----------+---------+-------------------------+ +-----------+---------+-------------------------+
| ERROR | Current | This Spec, Section 11.4 | | ERROR | Current | This Spec, Section 12.3 |
+-----------+---------+-------------------------+ +-----------+---------+-------------------------+
| SUSPENDED | Current | This Spec, Section 11.4 | | SUSPENDED | Current | This Spec, Section 12.3 |
+-----------+---------+-------------------------+ +-----------+---------+-------------------------+
Table 3: Sub-State registry Table 3: Sub-State registry
18.4. Task Mode value registry 17.4. Task Mode value registry
The following table has been used to initialize the Task Mode The following table has been used to initialize the Task Mode
registry. registry.
+======================+=========+=========================+ +======================+=========+=========================+
| Task Mode | Status | Reference | | Task Mode | Status | Reference |
+======================+=========+=========================+ +======================+=========+=========================+
| AUTOMATIC-COMPLETION | Current | This Spec, Section 13.2 | | AUTOMATIC-COMPLETION | Current | This Spec, Section 12.4 |
+----------------------+---------+-------------------------+ +----------------------+---------+-------------------------+
| AUTOMATIC-FAILURE | Current | This Spec, Section 13.2 | | AUTOMATIC-FAILURE | Current | This Spec, Section 12.4 |
+----------------------+---------+-------------------------+ +----------------------+---------+-------------------------+
| CLIENT | Current | This Spec, Section 13.2 | | CLIENT | Current | This Spec, Section 12.4 |
+----------------------+---------+-------------------------+ +----------------------+---------+-------------------------+
| SERVER | Current | This Spec, Section 13.2 | | SERVER | Current | This Spec, Section 12.4 |
+----------------------+---------+-------------------------+ +----------------------+---------+-------------------------+
Table 4: Task Mode Value Registry Table 4: Task Mode Value Registry
18.5. Participation Statuses registry 17.5. Participation Statuses registry
The following table has been used to update the Participation The following table has been used to update the Participation
Statuses registry. Statuses registry.
+========+=========+=========================+ +========+=========+=========================+
| Value | Status | Reference | | Value | Status | Reference |
+========+=========+=========================+ +========+=========+=========================+
| FAILED | Current | This Spec, Section 12.1 | | FAILED | Current | This Spec, Section 11.1 |
+--------+---------+-------------------------+ +--------+---------+-------------------------+
Table 5: Participation Statuses Registry Table 5: Participation Statuses Registry
18.6. Properties registry 17.6. Properties registry
The following table has been used to update the Properties registry. The following table has been used to update the Properties registry.
+====================+=========+=========================+ +====================+=========+=========================+
| Property | Status | Reference | | Property | Status | Reference |
+====================+=========+=========================+ +====================+=========+=========================+
| ATTENDEE | Current | This Spec, Section 14.1 | | ESTIMATED_DURATION | Current | This Spec, Section 12.1 |
+--------------------+---------+-------------------------+ +--------------------+---------+-------------------------+
| COMMENT | Current | This Spec, Section 14.2 | | REASON | Current | This Spec, Section 12.2 |
+--------------------+---------+-------------------------+ +--------------------+---------+-------------------------+
| ESTIMATED_DURATION | Current | This Spec, Section 13.1 | | SUBSTATE | Current | This Spec, Section 12.3 |
+--------------------+---------+-------------------------+ +--------------------+---------+-------------------------+
| STATUS | Current | This Spec, Section 14.3 | | STATUS | Current | This Spec, Section 13.1 |
+--------------------+---------+-------------------------+ +--------------------+---------+-------------------------+
| TASK-MODE | Current | This Spec, Section 13.2 | | TASK-MODE | Current | This Spec, Section 12.4 |
+--------------------+---------+-------------------------+ +--------------------+---------+-------------------------+
Table 6: Updated Properties Registry Table 6: Updated Properties Registry
18.7. Parameters registry 18. Normative References
The following table has been used to update the Parameters registry.
+===========+=========+=========================+
| Parameter | Status | Reference |
+===========+=========+=========================+
| REASON | Current | This Spec, Section 11.2 |
+-----------+---------+-------------------------+
| MODIFIED | Current | This Spec, Section 11.3 |
+-----------+---------+-------------------------+
| SUBSTATE | Current | This Spec, Section 11.4 |
+-----------+---------+-------------------------+
Table 7: Ipdated Parameters Registry
19. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", RFC 2119, RFC 2119, Requirement Levels", RFC 2119, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC4791] Daboo, C., Desruisseaux, B., and L. Dusseault, [RFC4791] Daboo, C., Desruisseaux, B., and L. Dusseault,
"Calendaring Extensions to WebDAV (CalDAV)", RFC 4791, "Calendaring Extensions to WebDAV (CalDAV)", RFC 4791,
RFC 4791, DOI 10.17487/RFC4791, March 2007, RFC 4791, DOI 10.17487/RFC4791, March 2007,
<https://www.rfc-editor.org/info/rfc4791>. <https://www.rfc-editor.org/info/rfc4791>.
skipping to change at page 27, line 19 skipping to change at page 25, line 24
[RFC5546] Daboo, C., Ed., "iCalendar Transport-Independent [RFC5546] Daboo, C., Ed., "iCalendar Transport-Independent
Interoperability Protocol (iTIP)", RFC 5546, RFC 5546, Interoperability Protocol (iTIP)", RFC 5546, RFC 5546,
DOI 10.17487/RFC5546, December 2009, DOI 10.17487/RFC5546, December 2009,
<https://www.rfc-editor.org/info/rfc5546>. <https://www.rfc-editor.org/info/rfc5546>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", RFC 8174, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", RFC 8174, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC9073] Douglass, M., "Event Publishing Extensions to iCalendar",
RFC 9073, RFC 9073, DOI 10.17487/RFC9073, August 2021,
<https://www.rfc-editor.org/info/rfc9073>.
[I-D.ietf-calext-ical-relations] [I-D.ietf-calext-ical-relations]
Douglass, M., "Support for iCalendar Relationships", I- Douglass, M., "Support for iCalendar Relationships", I-
D.ietf-calext-ical-relations, Work in Progress, Internet- D.ietf-calext-ical-relations, Work in Progress, Internet-
Draft, ietf-calext-ical-relations, December 2020, Draft, ietf-calext-ical-relations, December 2020,
<https://datatracker.ietf.org/doc/html/ietf-calext-ical- <https://datatracker.ietf.org/doc/html/ietf-calext-ical-
relations>. relations>.
20. Informative References 19. Informative References
[BPMN] "Business Process Model and Notation", OMG BPMN 2.0.2, [BPMN] "Business Process Model and Notation", OMG BPMN 2.0.2,
January 2014, January 2014,
<https://www.omg.org/spec/BPMN/2.0.2/About-BPMN/>. <https://www.omg.org/spec/BPMN/2.0.2/About-BPMN/>.
[I-D.york-vpoll]
York, E., Daboo, C., and M. Douglass, "VPOLL: Consensus
Scheduling Component for iCalendar", I-D.york-vpoll, Work
in Progress, Internet-Draft, york-vpoll, February 2017,
<https://datatracker.ietf.org/doc/html/york-vpoll>.
[TARCH] "Apthorp, A., Daboo, C., Douglass, M., CalConnect, Task [TARCH] "Apthorp, A., Daboo, C., Douglass, M., CalConnect, Task
Architecture V1.0,", CalConnect Task Architecture V1.0. Architecture V1.0,", CalConnect Task Architecture V1.0.
[EDISTS] "UN Economic Commission for Europe, UN/EDIFACT, D14.A, STS [EDISTS] "UN Economic Commission for Europe, UN/EDIFACT, D14.A, STS
STATUS, April 30, STATUS, April 30,
2014,http://www.unece.org/fileadmin/DAM/trade/untdid/d14a/ 2014,http://www.unece.org/fileadmin/DAM/trade/untdid/d14a/
trsd/trsdsts.htm", UN/EDIFACT, D14.A. trsd/trsdsts.htm", UN/EDIFACT, D14.A.
[WfRP] "Russell, N., ter Hofstede, A.H.M., Edmond, T., van der [WfRP] "Russell, N., ter Hofstede, A.H.M., Edmond, T., van der
Aalst,W.M.P., Workflow Resource Patterns, Eindhoven Aalst,W.M.P., Workflow Resource Patterns, Eindhoven
skipping to change at page 28, line 38 skipping to change at page 26, line 41
+---+--------------+--------------+---------------------------+ +---+--------------+--------------+---------------------------+
| 5 | IN-PROCESS | IN-PROCESS | Attendee reply now | | 5 | IN-PROCESS | IN-PROCESS | Attendee reply now |
| | | | working on the task | | | | | working on the task |
+---+--------------+--------------+---------------------------+ +---+--------------+--------------+---------------------------+
| 6 | IN-PROCESS | COMPLETED | Attendee reply completed | | 6 | IN-PROCESS | COMPLETED | Attendee reply completed |
+---+--------------+--------------+---------------------------+ +---+--------------+--------------+---------------------------+
| 7 | COMPLETED | COMPLETED | Organizer changes overall | | 7 | COMPLETED | COMPLETED | Organizer changes overall |
| | | | state | | | | | state |
+---+--------------+--------------+---------------------------+ +---+--------------+--------------+---------------------------+
Table 8: Example of status changes in assigning and Table 7: Example of status changes in assigning and
performing a task with one attendee. performing a task with one attendee.
A.2. Example for multiple Attendees A.2. Example for multiple Attendees
Example of status changes in assigning and performing a task with two Example of status changes in assigning and performing a task with two
attendees (A1 and A2). attendees (A1 and A2).
+====+==============+==============+==============+================+ +====+==============+==============+==============+================+
| | STATUS | PARTSTAT | PARTSTAT | Action | | | STATUS | PARTSTAT | PARTSTAT | Action |
| | | (A1) | (A2) | | | | | (A1) | (A2) | |
skipping to change at page 29, line 51 skipping to change at page 28, line 10
| | | | | Completed | | | | | | Completed |
+----+--------------+--------------+--------------+----------------+ +----+--------------+--------------+--------------+----------------+
| 11 | COMPLETED | COMPLETED | COMPLETED | Organizer | | 11 | COMPLETED | COMPLETED | COMPLETED | Organizer |
| | | | | changes | | | | | | changes |
| | | | | overall state | | | | | | overall state |
| | | | | once both | | | | | | once both |
| | | | | attendees are | | | | | | attendees are |
| | | | | finished. | | | | | | finished. |
+----+--------------+--------------+--------------+----------------+ +----+--------------+--------------+--------------+----------------+
Table 9: Example for multiple Attendees Table 8: Example for multiple Attendees
Note: The logic for determining the status change to the VTODO is Note: The logic for determining the status change to the VTODO is
determined by the task organizer based on the ATTENDEE status and determined by the task organizer based on the ATTENDEE status and
other business logic. other business logic.
A.3. Example of Failure A.3. Example of Failure
Example of status changes for a task that fails. Example of status changes for a task that fails.
+===+==============+==============+==============================+ +===+==============+==============+==============================+
skipping to change at page 30, line 31 skipping to change at page 28, line 38
+---+--------------+--------------+------------------------------+ +---+--------------+--------------+------------------------------+
| 4 | IN-PROCESS | IN-PROCESS | Attendee reply now working | | 4 | IN-PROCESS | IN-PROCESS | Attendee reply now working |
| | | | on the task | | | | | on the task |
+---+--------------+--------------+------------------------------+ +---+--------------+--------------+------------------------------+
| 5 | IN-PROCESS | FAILED | Attendee reply task failed | | 5 | IN-PROCESS | FAILED | Attendee reply task failed |
+---+--------------+--------------+------------------------------+ +---+--------------+--------------+------------------------------+
| 6 | FAILED | FAILED | Organizer changes overall | | 6 | FAILED | FAILED | Organizer changes overall |
| | | | state | | | | | state |
+---+--------------+--------------+------------------------------+ +---+--------------+--------------+------------------------------+
Table 10: Example of Failure Table 9: Example of Failure
Appendix B. Change log Appendix B. Change log
V02. 2021-05-05 MD V02. 2021-05-05 MD
* Redo in asciidoc * Redo in asciidoc
* Change STRUCTURED-CATEGORY to CONCEPT * Change STRUCTURED-CATEGORY to CONCEPT
* Add GROUP parameter definition * Add GROUP parameter definition
 End of changes. 64 change blocks. 
328 lines changed or deleted 237 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/