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.

* 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?

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

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

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

* 12.4: Normative language varies between automatic modes ("that it can change"
  vs. "that it SHOULD change"). Why?

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

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

Editorial:

* 1.1: The quoted all-caps strings for "REQUEST" and "REPLY" are not used that
  way throughout the document.

* 1.1: '"A"ttendee"'?

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

* 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?

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

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.

* 1.1: Bold of you to assume that a projector won't control its own attendance.
  The world is getting smarter every day…