Event Publishing Extensions to iCalendar
Note: This ballot was opened for revision 12 and is now closed.
Barry Leiba (was No Objection, Discuss) Yes
Thanks very much for the changes in Section 9.1, and I think we're now at the best place we can reasonable be here. Well done. Thanks also for the changes to clarify the ABNF, and for handling all the other comments.
(Alexey Melnikov) Yes
(Ignas Bagdonas) No Objection
Deborah Brungard No Objection
Alissa Cooper (was Discuss) No Objection
Comment (2020-01-24 for -15)
Thanks for addressing my DISCUSS. Original comment: Please respond to the Gen-ART review. The abstract should mention the update to RFC 7986 and the introduction should explain what is updated. Section 11: "This specification does not introduce any additional privacy concerns beyond those described in [RFC5545]." This seems untrue given the sentence that follows it, so this should be deleted.
Roman Danyliw (was Discuss) No Objection
Comment (2019-10-16 for -15)
Thank you for addressing my DISCUSS items.
Benjamin Kaduk (was Discuss) No Objection
Comment (2020-12-29 for -16)
Thank you for addressing my Discuss points! The new FlightReservation in §5.4 looks much more plausible; thanks. I guess I shouldn't complain that the dates are in 2017... Section 5.1 While I can't fault the move from param-value to [list of quoted string], I don't remember what the motivation was for that change. Section 6.2 If there is a related ATTENDEE proeprty then all parameters must nit: s/proeprty/property/ Section 7.2 For backwards compatibility wuth existing clients and servers when used to schedule events and tasks the ATTENDEE property MUST be used to specify the sheduling parameters as defined for that property. nit: s/sheduling/scheduling/ For other, future uses the CALENDAR-ADDRESS property MUST be used to specify those parameters. I trust the responsible AD to ensure that this new requirement has received the appropriate level of (WG and community) review. Section 9 Thanks for the updates to the Security Considerations; they're a big help! I did make one further suggested improvement in my response to my previous ballot's email thread. Appendix B At least some of the new versions are in 2020, not 2019
(Suresh Krishnan) No Objection
Murray Kucherawy No Objection
Comment (2021-01-04 for -17)
Section 1.2 says "For example, we may want to record who is participating in a public event", but the Privacy Considerations section doesn't say anything about the fact that this could collect data about people who are interested in the event, even if they don't go (though the location issue is mentioned). Also, especially since 2020, the public event could be a purely online event, where location data isn't part of the issue. (Alternatively, if this is meant to address in-person events only, that would be useful to say up front.) Section 6.2 (and other sections, but I noticed it here): ABNF literal strings are case-insensitive. That means, for example, that the ABNF here would allow "ACTIVE" for a "partvalue", but would also allow "active", "AcTiVe", etc. Is that acceptable? (This probably applies to lots of prior CALEXT documents -- I admittedly didn't check -- so it may not be worth fixing here.) Section 6.4: Property Parameters: IANA, or non-standard property parameters can be specified on this property. I think that should be "IANA-registered"? Same issue in Sections 6.5 and 6.6. Section 7: I believe the ABNF here needs a once-over. Section 9.2: For the threat described in the first paragraph, are there any possible mitigations to suggest? Section 10.2: In "without that participants express permission", that should be "participant's". There's also a period missing at the end of the second last paragraph, though as it reads, it's possible there's even some intended text missing. Section 11.2: The rules for making registrations into both the existing registries and these new ones are striking. RFC 8126 doesn't even create a category that is a combination of Expert Review and Standards Action, but that's what this spells out. And I wonder what would happen if we were to publish a Standards Track RFC (which has IETF consensus) with which the Designated Expert disagreed. I'm not asking for anything to change here given that consistency with the existing registries is probably desirable, but it does set an unusually high bar for registrations.
Warren Kumari No Objection
Comment (2019-05-29 for -13)
I apologize - I run out of time to fully review this document, and so I'm balloting "NoObj" in the "I read the protocol action, and I trust the sponsoring AD so have no problem and / or this is outside my area of expertise or have no cycles" sense of the term.
(Mirja Kühlewind) No Objection
Comment (2019-05-24 for -12)
A couple of comments/questions: 1) “In addition the SOURCE property defined in [RFC7986] is redefined to allow VALUE=TEXT and broaden its usage.” As you redefine the SOURCE property, this document should probably update RFC7986. 2) “This section defines updates to the tables defined in [RFC5545] and new tables.” I wouldn’t think that the table in RFC5545 need to be “updated”. Isn’t the whole purpose of having a registry that you don’t need to update another document in order to extend the table elements? I would recommend to just define the new and updated elements. 3) “These tables may be updated using the same approaches laid down in Section 8.2.1 of [RFC5545]” I find the use of the word “may” here a bit blurry. I would propose simply “are updated”. 4) Why is this document Proposed Standard? The shepherd write-up sounds like the review and deployment of these extension is currently very limited and therefore experimental might be more appropriate…? It’s looks like the change of the SOURCE property needs standards track, however, maybe it would be better to split this up in a separate document then? 5) Can you maybe further elaborate what the use case for the Order Property Parameter is? 6) “When a LABEL parameter is supplied the language of the label must match that of the content and of the LANGUAGE parameter if present.” Shouldn’t this be a normative MUST? Or actually probably a SHOULD?
Alvaro Retana No Objection
Éric Vyncke No Objection
Comment (2019-05-18 for -12)
Thanks for the work everyone has put into this document. I liked the section 3.1 'use cases' providing insights on the goal, same for the section about extended examples. I only have one comment and a couple of nits. == COMMENT == -- Section 4 -- If this syntax replaces completely or partly the one of RFC 5545, then it should be clear in the text (and I have seen that other iCal RFC use the same introduction). What about the other RFC that also update RFC 5545? Is their syntax also impacted? == NITS == -- Section 1 -- Please introduce VCARD before using the word, other words in this section are obvious to the reader. -- Section 2 -- Missing a '.' at the end of first paragraph. -- Section 5.4 -- Please use https://example.org rather than https://schema.org or is it a reference, existing URI ? -- Section 13 -- Last sentence ends with a ','