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.
* 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…
--
last-call mailing list -- last-call@xxxxxxxx
To unsubscribe send an email to last-call-leave@xxxxxxxx
