| < 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/ | ||||