Thanks for this - see updates below
I've just submitted a version 09 of the draft.
On 10/31/21 08:07, Christer Holmberg
via Datatracker wrote:
DoneReviewer: Christer Holmberg Review result: Ready with Nits 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://trac.ietf.org/trac/gen/wiki/GenArtfaq>. Document: draft-ietf-calext-ical-relations-08 Reviewer: Christer Holmberg Review Date: 2021-10-31 IETF LC End Date: 2021-10-28 IESG Telechat date: Not scheduled for a telechat Summary: I have no technical issues with the draft, and the text is quite easy to understand also for someone not familiar with the topic. However, I do have some editorial comments (specific and general) that I would like the authors to address. Major issues: N/A Minor issues: N/A Nits/editorial comments: Q1: Please make sure that there are references on first occurrence. For example, the first sentence of Section 1: "iCalendar entities often..." ...should have a reference to RFC 5545. In addition, I don't think we use references in the Abstract ---
Q2: The Abstract says: "This specification updates RELATED-TO defined in..." I think it would be good to add a few words on HOW RELATED-TO is updated. Also, please say "RELATED-TO property". ---
---OLD---
This specification updates RELATED-TO defined in iCalendar (RFC5545) and introduces new iCalendar properties LINK, CONCEPT and REFID to allow better linking and grouping of iCalendar components and related data.
---OLD---
---NEW---
This specification updates the iCalendar RELATED-TO property by adding new relation types and introduces new iCalendar properties LINK, CONCEPT and REFID to allow better linking and grouping of iCalendar components and related data.
---NEW---
Changed to updateQ3: Related to Q2, in Section 9 you say that you redefining RELATED-TO. I think redefine and update are two separate things, so please clarify.
And, while Section 1.1 does explain how RELATED-TO is updated/redefined, it would probably be good to have some text in Section 9 too. For example, if I understand correctly you are updating Section 3.8.4.5. of RFC 5545. That should be mentioned. I would also consider changing the name of Section 9 to "Updates to RFC 5545", and then in the text describe what those updates are.
I've changed the name and added text
---OLD---
9. Redefined RELATED-TO Property 9.1. RELATED-TO
---OLD---
---NEW---
9. Updates to RFC 5545 This specification updates the RELATED-TO property defined in Section 3.8.4.5 of [RFC5545]. The RELTYPE parameter is extended to take new values defining temporal relationships, a GAP parameter is defined to provide lead and lag values, and RELATED-TO is extended to allow URI values. These changes allow the RELATED-TO property to define a richer set of relationships useful for project management. 9.1. RELATED-TO
---NEW---
:
--- Q4: The text in Section 1.1 says: "The currently existing iCalendar [RFC5545] RELATED-TO property has no support for..." Please avoid "currently", because it will have a different meaning depending on when someone reads the spec. Instead, I suggest to simply say: "The iCalendar [RFC5545] RELATED-TO property has no support for..."
Done
_______________________________________________ calsify mailing list calsify@xxxxxxxx https://www.ietf.org/mailman/listinfo/calsify
-- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
