[calsify] WGLC feedback for draft-ietf-calext-ical-tasks-05

[Robert Stepanek <[e-mail]>]

First, my apologies for waiting until last call for a thorough re-read of the document.

I support the proposals in this RFC.

I have a few remarks about its definitions.I think the RFC presentation could be improved. For details, see below.

*Feedback on definitions:*
 * Section 7.2: the REL parameter in the example is not defined, it should read LINKREL as defined in RFC 9253.
 * Section 7.3: it's unclear why LINK is the better choice over ATTACH in these examples. Even the text in this section talks about "attachments".
 * Section 12.3: The examples for SUBSTATE confused me:
   * First example: What does SUBSTATE:ERROR tell more than STATUS:FAILED?
   * Second example: Wouldn't a SUSPENDED value for STATUS be more appropriate?
 * Section 12.4: The AUTOMATIC-COMPLETION and AUTOMATIC-FAILURE modes for TASK-MODE are defined for server. First, it's not clear to me which server is meant. It seems as if the server of the organizer of the task is the one that should enact these modes? If so,
   * Would it make sense to define the TASK-MODE property as follows:
     * Define a STATUS-AGENT (or TASK-AGENT) property with allowed values "SERVER" / "CLIENT". This is similar to the SCHEDULE-AGENT property that RFC 6638 defined.
     * Define a STATUS-MODE (or TASK-MODE) parameter with the AUTOMATIC-.. modes?
 * Section 17: The IANA registration for VSTATUS is missing.

*Feedback on presentation:*

The RFC introduces an architecture and terminology which I found to not contribute much to the actual iCalendar-related changes proposed in later sections. It seems most of the terminology introduced only is required to define the architecture itself. Putting my implementors hat on, and trying to understand what this RFC brings new to VTODO, I did not see what the architecture provides for me. Maybe there is an audience for this, though, it wasn't just me.

I wonder if sections 3 to 10 could be condensed to some definitions in the Introduction section and some in the sections with iCalendar definitions. This would also align the RFC document structure with the other iCalendar-related RFCs.

What follows is detailed feedback on phrasing, typos, etc:
 * Section 4: the ERP acronym is undefined
 * Section 7.1: adding a reference to RFC 9253 for the CONCEPT property would help
 * Section 7.2:
   * "REFID is used to identify a key allowing the association of tasks "... I found this hard to parse, both the "used to identify" and "allowing the association". The REFID already is defined in RFC 9253. Why not just say here that it can be used to group tasks by that reference key?
   * The "Doug114" reference is outdated and should mean RFC 9253.
 * Section 7.3:
   * "standard calendar user agents.. “ What does “standard” mean?
   * The newlines in the examples are confusing
 * Section 8:
   * A document-internal link to the ESTIMATED-DURATION definition might be good here.
   * Split the two paragraphs into two sections? It was a hard cut from estimated durations to intermediary deadlines.
 * Section 9:
   * "supports the two distinct models “. Remove "the”?
   * This whole section reads as if it could be shortened to: “Tasks are assigned to actors with the ATTENDEE property and schedulding is done with iTIP.”
 * Section 10:
   * "about the status." The status of what? Which status?
   * Add VSTATUS component name: "“...defines a new status component _VSTATUS_ that..”
 * Section 10.2: A sentences that describes the scenario in the example would help to better understand it.
 * Section 10.4:
   * "Note: there is no constraint in the current standards on the propagation of alarms specified on calendar objects by organizers to individual attendees." What does this note hint at? That alarms may be sent from the organizer to attendees? Does this specification recommend to do that? Some servers (ours) strip alarms from calendar events that come in through iTIP.
   * BPMS: unexplained acronym.
   * No such reference: Doug214
 * Section 11:
   * Replace "/=" with "=/", the latter is defined in ABNF RFC 5234
 * Section 12.1. rephrase example description from " that specifies an interval of time of exactly one hour” to “that estimates the duration of a task to be one hour”.
 * Section 12.2: Purpose/Description: rephrase "reason for a change in status of a task“ to “reason for a status change” (e.g. omit "task").
 * Section 13.1:
   * fix typo "MUSt" to "MUST"
   * "is replaced by" should not be formatted as code
 * Section 13.2:
   * replace "/ =" with "=/"
   * the inline comments here and in some other sections are off:
     * they do not vertically align the ";" characters, so comments are not formatted as a paragraph
     * The comments mostly describe the semantics. If anything, they should be used to describe value restrictions that can't be expressed with ABNF (but ABNF recommends not to use comments for this, too).
   * PENDING - "A Task. FAILED - "task". The start of these sentences should be the same
 * Section 14.1:
   * Conformance: “In any appropriate calendar component.” What does “appropriate” mean?
   * Description: just add participant here in addition to event and task types?

That's all!
Robert