Skip to main content

Last Call Review of draft-ietf-calext-ical-tasks-12
review-ietf-calext-ical-tasks-12-genart-lc-enghardt-2025-03-10-00

Request Review of draft-ietf-calext-ical-tasks
Requested revision No specific revision (document currently at 17)
Type IETF Last Call Review
Team General Area Review Team (Gen-ART) (genart)
Deadline 2025-03-11
Requested 2025-02-25
Authors Adrian Apthorp , Michael Douglass
I-D last updated 2026-01-06 (Latest revision 2025-12-09)
Completed reviews Genart IETF Last Call review of -12 by Reese Enghardt (diff)
Artart IETF Last Call review of -12 by Christian Amsüss (diff)
Secdir IETF Last Call review of -13 by Joseph A. Salowey (diff)
Artart Telechat review of -13 by Christian Amsüss (diff)
Assignment Reviewer Reese Enghardt
State Completed
Request IETF Last Call review on draft-ietf-calext-ical-tasks by General Area Review Team (Gen-ART) Assigned
Posted at https://mailarchive.ietf.org/arch/msg/gen-art/nQWDZRaHo073UOjvx5M8nFSlH-c
Reviewed revision 12 (document currently at 17)
Result Ready w/nits
Completed 2025-03-10
review-ietf-calext-ical-tasks-12-genart-lc-enghardt-2025-03-10-00
I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair.  Please treat these comments just
like any other last call comments.

For more information, please see the FAQ at

<https://wiki.ietf.org/en/group/gen/GenArtFAQ>.

Document: draft-ietf-calext-ical-tasks-12
Reviewer: Reese Enghardt
Review Date: 2025-03-10
IETF LC End Date: 2025-03-11
IESG Telechat date: Not scheduled for a telechat

Summary: The document is ready for publication, and I have a few minor
suggestions to improve clarity on the motivation and diff to the previous spec.

Major issues: None.

Minor issues:

Abstract:

"The Internet Calendaring and Scheduling Core Object Specification (iCalendar)
(RFC5545) VTODO calendar component has been seen as the poor relation of VEVENT
- useful only for personal reminders and to-do lists."

While I agree that it's helpful to lay out the motivation for this work, please
consider rephrasing this part to be more neutral in tone and/or a bit more
specific. Maybe something like "has seen limited adoption and use"? I am not
sure what "a poor relation" means in a technical context.

Section 1, Introduction:

I am curious about the specific extensions and improvements to VTODO that this
specification adds. For example, was VTODO already capable to be used in an
automated way? Is the task architecture new or was it already used in RFC 5545?
Please consider laying out the improvements that this specification adds
explicitly.

Considering the motivation of this work, are there any specific improvements
that are believed to make VTODO "more useful", and why?

I can see that sections 6 and 7 lay out some of these changes, but I think
it'll be helpful to already mention the potential improvements in the
Introduction.

Section 5, Task Extensions:

"In order to support the task architecture described in Section 2, this
document defines a number of extensions to the current iCalendar standards in
the areas of:

Task Specification  improved ability to specify domain specific tasks
Task Deadlines, Milestones and Time Planning   clarification of deadlines and
extension for task duration to support task time planning

Task Scheduling and Assignment   ensure support for common patterns of
scheduling and assigning tasks

Task Status Tracking   improved granularity in status tracking information and
alerting task actors of pending or actual task status changes"

I suggest being more specific here, for example, saying that the document
extends a specific specification with an RFC number by adding fields to
specific components. I think highlighting that these added fields are expected
to make VTODO more useful will be good content for the Introduction section.

Section 16, "Security Considerations":

If this specification is expected to improve the ways in which VTODO can be
automated, rather than being mostly used manually by individual users, are
there potential new risks?

Nits/editorial comments: None.