Dan, thanks for your review. I entered a DISCUSS ballot on a couple of unrelated points and asked the authors to respond to you. Alissa > On Apr 28, 2019, at 5:58 AM, Dan Romascanu via Datatracker <noreply@xxxxxxxx> wrote: > > Reviewer: Dan Romascanu > Review result: Ready with Issues > > 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-eventpub-extensions-12 > Reviewer: Dan Romascanu > Review Date: 2019-04-28 > IETF LC End Date: 2019-04-29 > IESG Telechat date: Not scheduled for a telechat > > Summary: > > This is a clear and detailed document updating RFC 5545 to include new > properties and components to iCalendar. The document is READY for publication. > I found a number of minor issues as well as a few nits which should be > clarified and fixed in the further editing process. > > Major issues: > > Minor issues: > > 1. The document uses the term 'event' which has many meanings in many contexts. > It would be useful to include or reference a definition of what is meant by > 'event' in the context of iCalendar > > 2. The Abstract mentions that some of the updates are useful for social > networking. I could not find any support for this claim in the text, with the > exception mybe of mentioning 'social calendaring' in Section 3, which is also a > vague term (or at least I do not know where it is defined or referred in the > IETF). I suggest to either clarify, or drop these mentions. > > 3. In Section 3: > >> Using STRUCTURED-LOCATION, information about a number of interesting > locations can be communicated, for example, address, region, country, > > Isn't it rather 'supplementary information about the location' than > 'information about a number of interesting locations'? > > 4. Inconsistent use/non-use of keywords. > > In 5.2: > > 'This parameter MAY be specified on STRUCTURED-RESOURCE > and provides a way to differentiate multiple properties.' > > while in 5.5: > > 'This property parameter can be specified on any > property when the value is derived from some other property or > properties.' > > I suggest to decide on a consistent use of either MAY or 'can'. > > Nits/editorial comments: > > 1. In Section 2: > >> This is a > better match for the way [W3C.REC-xml-20081126] and JSON, [RFC8259] > handles such structures and allows richer definitions. > > Fix grammar (plural) > > 2. In the use cases in Section 3, there are many optional parameters, and the > use of conditional in the text may be more appropriate. > > For example in 3.1.1: > > 'In addition, there will be sponsorship information for > sponsors of the event' > > better > > 'In addition, there may be sponsorship information for > sponsors of the event' > > 3. In Section 3.1.2.1 > > s/A meeting may have 10 attendees non of which are co-located/A meeting may > have 10 attendees, none of which are co-located/ > > 4. I do not know if Appendix B will be kept, but in case it will be, there is a > typo in: > >> Fix PARTTYPE/PARTICPANT-TYPE inconsistency > > > _______________________________________________ > Gen-art mailing list > Gen-art@xxxxxxxx > https://www.ietf.org/mailman/listinfo/gen-art
