Thanks for the review - responses below. Note that section numbering changed.
Adrian noticed that sections 3 and 4 were really subsections of
2.
On 3/11/25 18:56, Christian Amsüss via
Datatracker wrote:
I suspect we just followed the lead of 5545. Probably dropping the option is the best move now.Reviewer: Christian Amsüss Review result: Ready with Issues While I've kept the typical ART-ART issues in mind for this review, few things in that area came up -- the document uses iCalendar's existing extension points, and makes barely any decisions that touch those issues. I do have a few remarks, including ART-ART concerns, but all those should be straightforward to sort out. ART-ART specific notes: * 12.4 introduces a new TASK-MODE property that contains an x-name provision (unlike sub-state which does not). Such mechanisms are not best practice any more (BCP178). There might be good reasons to have x-name as an option here, but then they should be made very explicit here, and compared to other options.
* LINKREL=SOURCE is not a registred link relation. Granted, that is also the case in RFC9253 -- but either that is an example (then it should have been pointed out to be that there as well as here), or you see that as a valuable relation (it might make sense with a good definition), in which case you could register it in this document. Neither are vacation-system and electronic-signature; for those, some readers may take the clue more easily that they are examples, but either way, it's better to point squat here either.
* It is not clear to me how 6.3 is a special case of 6.2, other than using the value type explicitly (which Section 8.2 of RFC9253 describes as required). I'd assume that 6.3 is an example of 6.2, but then it'd better be grouped in there, described as such (including the relation types, see previous bullet), and the other links fixed to also use an explicit VALUE=URI.
Replaced 6.2 and 6.3 with this:
----------NEW
4.2. Task Context and Relationships
The [RFC9253] "LINK" property specifies a link to external
information, which may be context to the task. For example:
LINK;LINKREL=describedby;VALUE=URI:
mid:752142.141482.307E5@xxxxxxxxxxxxxxxxx
The external information may be data to be manipulated in performing
the task.
The "LINK" property can be used to relate a domain specific service
to the task. For example, it might be a URI pointing to a web page
where the status of the task can be directly manipulated.
(Note: link relations below are for illustration only)
LINK;LINKREL="vacation-system";VALUE=URI:
http://example.com/vacation-approval?id=1234
Additionally, it might be used to link data specific to the task, for
example an electronic copy of a signature taken to confirm delivery
of a package.
LINK;LINKREL="electronic-signature";VALUE=URI:
http://example.com/delivery/sig1234.jpg
The [RFC9253] "REFID" property is used to identify a key used to
group tasks by that key.
REFID:Manhattan
REFID:1234567890
Extensions to the "RELATED-TO" property defined in [RFC9253] allow
temporal relationships between tasks as found in project management
to be specified as well as parent/child relationships and
dependencies (DEPENDS-ON). Tasks ("VTODO" calendar components) may
also be related to other calendar components; for example to a
"VEVENT" calendar component to block time to perform a task.
* 9.2: IIUC, calendar components such as VSTATUS items are ordered, and DTSTAMP is typically (but not mandatorily) present. In parallel, there is the compatibility STATUS property. Is there a mandate I missed on who syncs them, and which of multiple VSTATUS takes precedence?
I've added a section to try to clarify that. I did wonder if DTSTAMP should be required in VSTATUS but it's probably unnecessary in the ATTENDEE replies.
----------NEW
7.3. Updating the overall status Only the Task Organizer, or the server acting as the Organizers proxy, may change or add "VSTATUS" calendar components and the "STATUS" property. The overall VSTATUS will be changed in response to incoming Attendee replies. Each change of the overall VSTATUS MUST be accompanied by a change to the STATUS. Note there is no defined ordering of properties and components so the DTSTAMP property SHOULD be set for each VSTATUS component to preserve ordering.
--------------
Other notes: * 1: The introduction mentions smart power grids as a possible application. The other example (business process management systems) is pretty self-evident to whom I expect to be most readers, but power grid event scheduling not so much. Are there concrete public use case descriptions you could reference, or do you have more easy-to-digest examples at hand? (The taxi example of section 1.1 or delivery of 6.1 and later come to mind).
WsCalendar (https://docs.oasis-open.org/ws-calendar/ws-calendar-spec/v1.0/cs01/ws-calendar-spec-v1.0-cs01.pdf) defines a SEQUENCE component which is in most respects very close to what we defined here - some of the changes there were rolled into this and relationships.
If we'd had these updates to tasks I suspect we would have used VTODO instead of SEQUENCE.
I felt it of value to point out a different use of calendar
components. I added a reference.
* Task Architecture is very broad. It'd have helped me understand the document
faster if components that are covered in this specification were somehow
distinguished from those that are not. (AIU what is covered is the center
left box).
Later reading that a task trigger can come from the calendaring system
doesn't make this easier to understand ("Task Trigger" definition).
Added a sentence to try to clarify:
-------------- New
A reference architecture for task calendaring and scheduling is defined in order to identify the key logical elements involved in task management and the interfaces between them to enable interoperability. Central to this architecture is the Calendar and Scheduling System. The logical elements identified here establish an appropriate separation of concerns and clarify the responsibilities of different elements. However, the architecture does not prescribe a binding or packaging of elements, i.e., software systems may be developed where some elements are tightly bound and the interfaces between bound elements are not exposed. The task architecture is also described in [TARCH]. --------------------------
Removed* Human Task Generation only comes up in the architecture list but nowhere else. * The Directory Service is not referenced anywhere else. What is its purpose, especially given the Calendar and Scheduling System provides URIs and lookup for all involved entities?
* 8: Is there a preference or dependency between "ATTENDEE" and "PARTICIPANT" components? (There might easily be one that I missed due to not being too familiar with the referenced documents).
Added a pointer to 7.3
Tasks are assigned to actors using one or more [RFC5545] "ATTENDEE" properties and/or one or more [RFC9073] "PARTICIPANT" calendar components as described in Section 7.3.
* 12.4: Normative language varies between automatic modes ("that it can change"
vs. "that it SHOULD change"). Why?
Just wrong - fixed* 15: I'd understand "can try any task mode" to be in conflict with "Clients MUST NOT attempt" -- which one is it? The server "MUST return an HTTP 403": Is a CalDAV server generally required to understand all extensions that are contained in submitted items? (My impression from using a few is that they tend to ignore them). If they may be ignored, this requirement would effectively only apply to CalDAV servers that support this specification; how would a client know that it does? (If the client can't know that, it can't rely on the 403, and the mandate is useless).
----------OLD
In order for a CalDAV client to know what task modes are available, a CalDAV server advertises a CALDAV:supported-task-mode-set WebDAV property on calendar home or calendar collections if it supports the use of the "TASK-MODE" property as described in this specification. The server can advertise a specific set of supported task modes by including one or more CALDAV:supported-task-mode XML elements within the CALDAV:supported-task-mode-set XML element. If no CALDAV:supported-task-mode XML elements are included in the WebDAV property, then clients can try any task mode, but need to be prepared for a failure when attempting to store the calendar data. Clients MUST NOT attempt to store iCalendar data containing "TASK- MODE" elements if the CALDAV:supported-task-mode-set WebDAV property is not advertised by the server. The server MUST return an HTTP 403 response with a DAV:error element containing a CALDAV:supported-task-mode XML element, if a client attempts to store iCalendar data with an "TASK-MODE" element value not supported by the server.
-------------
----------NEW
In order for a CalDAV client to know what task modes are available, a CalDAV server advertises a CALDAV:supported-task-mode-set WebDAV property on calendar home or calendar collections if it supports the use of the "TASK-MODE" property as described in this specification. The server can advertise a specific set of supported task modes by including one or more CALDAV:supported-task-mode XML elements within the CALDAV:supported-task-mode-set XML element. If no CALDAV:supported-task-mode XML elements are included in the WebDAV property, then clients MUST assume the server does not support this specification. The client MAY attempt to store iCalendar data containing "TASK-MODE" elements but needs to be prepared for a failure response from the server. A server supporting this specification MUST return an HTTP 403 response with a DAV:error element containing a CALDAV:supported-task- mode XML element, if a client attempts to store iCalendar data with an "TASK-MODE" element value not supported by the server.
--------------
Added AUTOMATIC* 15.1: Supporting both AUTOMATIC-COMPLETION and AUTOMATIC-FAILURE but not AUTOMATIC sounds like quite an odd example.
* A.1: The transition from 6 to 7 is something that could easily be a result from an AUTOMATIC or SERVER task mode. Might be an opportunity to point that out here, as well as any other status changes where something similar happens.
Added text
| 7 | COMPLETED | COMPLETED | Overall state set - either | | | | | by Organizer for TASK- | | | | | MODE=CLIENT or by server | | | | | for AUTOMATIC-COMPLETION |
FixedEditorial: * 1.1: The quoted all-caps strings for "REQUEST" and "REPLY" are not used that way throughout the document.
Fixed* 1.1: '"A"ttendee"'?
Fixed* 1.1: ROLE=NON-PARTICIPANT: As I understand, role is a property parameter on the property ATTENDEE, so it would be written quoted and lower-case as per the same section.
Getting it reinstated* TARCH is a dead link. Latest the wayback machine has is https://web.archive.org/web/20240424131710/https://www.calconnect.org/architectures/Task%20Architecture%201.0.pdf but maybe the authors republished it elsewhere.
* Task Organizer: The definition is somewhat tautological; what is their responsibility?
New text
Task Organizer The creator of a task, who also determines task assignment and scheduling, and monitors task progress.
* 12.4: The description of "AUTOMATIC" pulls in also the conflicting "MUST be handled by a client" statements; rephrasing would solve this, eg.: > This mode applies the automatisms of both "AUTOMATIC-COMPLETION" and > "AUTOMATIC-FAILURE".
New text:
AUTOMATIC Task Mode This mode handles the automatic behavior of both "AUTOMATIC-COMPLETION" and "AUTOMATIC-FAILURE".
This has been the topic of some discussion. I think we felt it needed an update to 5545.No action required: * 10-13: I trust that within the calext group there is the expertise to serialize (into a single sequence of RFCs) and error-check this style of changes to ABNF (especially for consistency with the IANA considerations); I would not recommend that style for new formats.
Agreed* 1.1: Bold of you to assume that a projector won't control its own attendance. The world is getting smarter every day…
_______________________________________________ calsify mailing list -- calsify@xxxxxxxx To unsubscribe send an email to calsify-leave@xxxxxxxx
-- last-call mailing list -- last-call@xxxxxxxx To unsubscribe send an email to last-call-leave@xxxxxxxx
