Re: [Gen-art] Genart last call review of draft-ietf-calext-eventpub-extensions-12

[Alissa Cooper <[e-mail]>]

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 <[e-mail]> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/gen-art