Support for iCalendar Relationships
draft-ietf-calext-ical-relations-11

[S2; nit]

* "it's use" -> "its use", I think

[S8.1, S8.2, S9.1; nit]

* Is "http" important to the examples, or should/could these be "https"?

Thanks to Spencer Dawkins for his ARTART review.

There's a lot of missing punctuation in here, such as the prose in Sections 11.2 through 11.5, the end of the second and final paragraphs of 1.4, first paragraph of 2, "Property Parameters" of and the latter two examples in 8.2, etc.

This document needs a normative reference to ABNF (RFC 5234), and should mention explicitly that a lot of the ABNF tokens (e.g., "dur-value") are imported from RFC 5545.

Thank you to Catherine Meadows for the SECDIR review.

** Abstract.  The abstract text needs to mention that it is updating RFC5545.

** Section 6.2.  Typo. s/temporaly/temporarily/

** Section 8.1.  Per the example, “CONCEPT:http://example.com/event-types/arts/music” should this use https?

** Section 10.  Thanks for noting the RFC3986 considerations on using URIs.  Digging a bit more into the implementation approaches of the CONCEPT parameter, would clients be expected dereference the taxonomy URI in real-time?   I’m wondering if there would be a chance for tracking mechanism akin to a “web bug” on a web page or in HTML email.  For example, an .ics file is sent via an asynchronous mechanism (email) with a CONCEPT URI to something unique/unknown to the end-client and to a destination controlled by the sender or even a third party.  Could it function as a read-receipt or to harvest an identifier for the system the client is on (IP address)?

Thanks for the efforts on this specification.

One observation, the abstract should have text to mention that this specification updated 5545.

Thank you for the work put into this document. It appears to be useful especially if calendaring applications want to morph into project management style of calendaring.

Please find below some non-blocking COMMENT points (but replies would be appreciated even if only for my own education).

Special thanks to Bron Gondwana for the shepherd's write-up including the section about the WG consensus. 

I hope that this helps to improve the document,

Regards,

-éric


https://www6.ietf.org/tools/idnits?url=https://www.ietf.org/archive/id/draft-ietf-calext-ical-relations-09.txt flags multiple errors and warnings. All of them look easy to address.

I also support Erik Kline's comment about the use of "https" everywhere.


## Section 4

It would be nice to add some explanations around the direction of the arrow.

Figure 2, I like the example, but the graphic has 2 elements while the example text has 3.

# Section 6.2

Even if obvious, "dur-value" is not described in the text of this section. 

May I also assume that CALEXT has duration types ? So, that there is no need to describe the syntex of this value ?

Thank you for the updates to resolve my earlier Discuss and Comment points!