Document Shepherd Write-Up for draft-ietf-calext-ical-relations
1. This document is being requested as an Proposed Standard because it
extends an existing Proposed Standard (RFC5545).
The request type is indicated in the title page header as "Standards Track".
2.
Technical Summary
This spec extends the iCalendar format (RFC5545) to add new
properties (LINK, CONCEPT and REFID) to allow better linking
and grouping of related iCalendar records.
Working Group Summary
This document has been around for a long time and been through
multiple revisions and discussions since it was first proposed
in 2013, and first accepted by this working group in 2016.
The main delay has been my (Bron, document Shepherd) fault, as
it's had multiple working group last calls, and then I've just
not gotten around to submitting it until the document expired.
Blame 2020.
Document Quality
The extensions to iCalendar are all very easy to understand and
to implement. The concepts in this document have already been
implemented in the jscalendar format (RFC8984) - though there is
not need to cross-reference them, as that will be done in a
separate mapping document between the two protocols, which is
still being finalised, and will reference both this docuement
and that one (draft-ietf-calext-jscalendar-icalendar).
Personnel
Document Shepherd - Bron Gondwana (CALEXT co-chair)
Responsible Area Director - Francesca Palombini
3. The Document Shepherd has read the document through in detail.
4. There are no concerns about reviews, this document has been well reviewed.
5. There is no review required for the document by other areas.
6. There are no concerns with this document that IESG should be aware of.
7. Yes, the author has been contacted and confirmed and confirmed that
they have no disclosures.
8. There have been no IPR disclosures filed.
9. The WG consensus is solid.
10. There has been no discontent.
11. idnits notices a missing reference to RFC3986, which appears to
be a tooling bug and easily resolved in the editing process.
12. This document doesn't define anything which needs formal review
outside the working group.
13. All references have been identified as normative.
14. All normative references are published standards at the IETF or W3C.
15. There is a downref to an informational RFC, RFC8607. Per that RFC:
Although this extension to CalDAV has wide deployment, its design does
not comply with some of the best current practices of HTTP. Rather
than creating interoperability problems with deployed code, it was
decided to simply document how existing implementations interoperate.
So this reference is required to specify how this extension will also
interact with the deployed base of managed attachments.
16. This RFC does not change the status of any other RFC.
17. The IANA considerations ask for entries to be added 5 separate
icalendar registries. The registrations are formatted as tables and
clearly specify the values for all the fields in each registry.
The author of this specification is one of the expert reviewers for
these registries.
18. There are no new registries created.
19. The ABNF section is spread through the document, and was validated with
Chris Newman's tool.