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

[Dan Romascanu via Datatracker <[e-mail]>]

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