[calsify] AD Evaluation: draft-ietf-calext-ical-tasks-11

Orie <orie@or13.io> Wed, 12 February 2025 16:28 UTC

Return-Path: <orie@or13.io>
X-Original-To: calsify@ietfa.amsl.com
Delivered-To: calsify@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC571C180B56 for <calsify@ietfa.amsl.com>; Wed, 12 Feb 2025 08:28:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.106
X-Spam-Level:
X-Spam-Status: No, score=-2.106 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=or13.io
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d1UuG3h2uI-4 for <calsify@ietfa.amsl.com>; Wed, 12 Feb 2025 08:28:07 -0800 (PST)
Received: from mail-vk1-xa2d.google.com (mail-vk1-xa2d.google.com [IPv6:2607:f8b0:4864:20::a2d]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9FC60C14F726 for <calsify@ietf.org>; Wed, 12 Feb 2025 08:28:07 -0800 (PST)
Received: by mail-vk1-xa2d.google.com with SMTP id 71dfb90a1353d-5203d50ade0so732912e0c.0 for <calsify@ietf.org>; Wed, 12 Feb 2025 08:28:07 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=or13.io; s=google; t=1739377686; x=1739982486; darn=ietf.org; h=to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=cXMpcCOv18himTnsCuGFQApBVW42yO/RptXmk/71AsU=; b=XCEudmWTxMiL7FyRrZEcRnGaSml9+hh+14YcbosYm7xN6YzhaVY1OQqDBbLlWJ+Don P8tz1gbd3MEZVqfvz9+8V7tlL8EzKHpDKJrjaaiJN5TpIHDqdIR11q1Gx6LokjLCbjo6 H6CjA+C1gNaJw1/2qJ/kZc0IafGGuAF+SlA60N52Z8jvCfL48poemIoMFK1/Sx1faz+E fKlQFT+LK/EO0rJxvGjRXdlNyQeskngMbwubKfY1mZjYvgN6wgHyxi3lxXDieKJi9jNd 7dukOi+a0dr82IRsbQKkFO3h2wTsk24fi6cF61xbq3IqN4kWNwxQllDC9yzX66wAGgyG zPpA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1739377686; x=1739982486; h=to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=cXMpcCOv18himTnsCuGFQApBVW42yO/RptXmk/71AsU=; b=IaglvSr6FYvwqek7AVdGa2LwVV1uhag0GSJtP4ZTW1xs/yIXkWi7c6vHAl9mWFb9MX fD8lSvv7Qmaj+ou5+FBpYx0rzCmLBcOEs4EWp40CyX5zKIH7uP78alyJUEXix9PLRHAm 2Zg86MUvXLohs/0upc/N3iZulwh0LuOYf5TKmbZusjlX4hK6GshATeDgoqLKWsw66DjL 0E20roX6IXJPfhxOxLqpuO/TcwtcdgQ6kpIGdVcjFZWL/K/tRowppNgsV5BUHOVpfw3R elXYC6x9LV0uCRm1wGC5mf08UOeDcXhhbiqkwn3jBCaPn9kzt/49jwjJpbn8MhPekLvg O0Tg==
X-Gm-Message-State: AOJu0Yx4RMW+vMCgaC3wPadGrAqHTg4tcWF8hwIVDIp2c9kWbAH5JuQg 6fWOGpEDwihJrAjPPusl/cdXhkyyx+hPHVghupjoXG7KFaQSNJ44wGXEraW5OZXg3s+YgBjIpZS JCwE0HdhhLeFo2KDhRWIb8HyTP+76QITN+x3ULDgstUo+XlBqUk0=
X-Gm-Gg: ASbGncunepWOQkWMWnCTccxVyOGexzcSxGyhtnBpPEomv/11jS2BzIZ6jNb16JaQG5J t3STXGNY79xl1Wpz4vI3ZfFHL0DFy9E8SxSsY7V+hj6qBi3MEtPis89IoJwpjWeCGPJ+sNQ0mYg ==
X-Google-Smtp-Source: AGHT+IHzV6jTeIyr0dwOeyxqjtdvilUmmI5lMhGTHox73yUWHlcuTkPqFwMmC+J1J2XmyOaM91RUa35QJdPap2ACvQ0=
X-Received: by 2002:a05:6122:2187:b0:520:652b:cdf9 with SMTP id 71dfb90a1353d-52067ba9daemr3695685e0c.5.1739377685903; Wed, 12 Feb 2025 08:28:05 -0800 (PST)
MIME-Version: 1.0
From: Orie <orie@or13.io>
Date: Wed, 12 Feb 2025 10:27:55 -0600
X-Gm-Features: AWEUYZl_7umHZRihzrzWWf6UIlS7VZOnIGoodVytp-OFuHfZtDmGCw5LUMt_VIQ
Message-ID: <CAMzqgozNHZqGrb3JuX=qM2dnWrVGr1AW-Qw8AUhtHXxC24fiXA@mail.gmail.com>
To: calsify@ietf.org
Content-Type: multipart/alternative; boundary="000000000000195bf7062df46d35"
Message-ID-Hash: K3OCC7PW72U42FUSG54LTL6RIEQZZW3L
X-Message-ID-Hash: K3OCC7PW72U42FUSG54LTL6RIEQZZW3L
X-MailFrom: orie@or13.io
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-calsify.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
X-Mailman-Version: 3.3.9rc6
Precedence: list
Subject: [calsify] AD Evaluation: draft-ietf-calext-ical-tasks-11
List-Id: Calendaring and Scheduling Standards Simplification <calsify.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/calsify/NR6B0BkA56rbz11BQdN4v4cmz-0>
List-Archive: <https://mailarchive.ietf.org/arch/browse/calsify>
List-Help: <mailto:calsify-request@ietf.org?subject=help>
List-Owner: <mailto:calsify-owner@ietf.org>
List-Post: <mailto:calsify@ietf.org>
List-Subscribe: <mailto:calsify-join@ietf.org>
List-Unsubscribe: <mailto:calsify-leave@ietf.org>

# Orie Steele, ART AD, comments for draft-ietf-calext-ical-tasks-11
CC @OR13

* line numbers:
  -
https://author-tools.ietf.org/api/idnits?url=https://www.ietf.org/archive/id/draft-ietf-calext-ical-tasks-11.txt&submitcheck=True

* comment syntax:
  - https://github.com/mnot/ietf-comments/blob/main/format.md

## Comments

Love the diagram in Figure 1.

### Augmented Status definition

```
938   Format Definition  The "STATUS" property parameter list is augmented
939      as follows:

941   statvalue-todo = / "PENDING"    ;Indicates a to-do has been
942                                   ;created and accepted, but has
943                                   ; not yet started.
944                   / "FAILED"      ;Indicates to-do has failed.
```

Title of the section says redefined, but the body of the section only has
the additions.
I would prefer to see a completely updated ABNF here, or at least the
existing definitions, since they are not being destroyed by this update.

I didn't check all the ABNF, but if you feel that this applies to other
sections, I would consider making it clear where you are "overwriting" and
where you are  "extending".

### Why not MUST?

```
493   A task that has intermediary deadlines (i.e., milestones) SHOULD be
494   expressed by child "VTODO" calendar components (i.e., sub-tasks
495   associated with each of the milestones) in conjunction with the
496   "RELATED-TO" property to relate the parent and child tasks.
```

Are there any obvious cases where this SHOULD ought to be strengthened or
weakened?

### Why not MUST?

```
1040   The server SHOULD return an HTTP 403 response with a DAV:error
1041   element containing a CALDAV:supported-task-mode XML element, if a
1042   client attempts to store iCalendar data with an "TASK-MODE" element
1043   value not supported by the server.
```


### SHOULD fail gracefully?

```
1045   It is possible for a "TASK-MODE" value to be present in calendar data
1046   on the server being accessed by a client that does not support the
1047   "TASK-MODE" property.  It is expected that existing clients, unaware
1048   of "TASK-MODE", will fail gracefully by ignoring the calendar
1049   property.
```

## Nits

### poor relation is a bit casual

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

### "DUE"/"DURATION"

```
708      completed.  When present, "DTSTART" and "DUE"/"DURATION"
709      properties represent the window in which the task can be
710      performed.  The "ESTIMATED-DURATION" property SHOULD be passed
```

I know what you mean here, but the / is perhaps not as clear as a rewording.