Subject: [calsify] Expert review of draft-ietf-calext-eventpub-extensions-12

From: Cyrus Daboo <[email-masked]>
Date: Mon, 20 May 2019 16:12:15 -0400

Hi,
I am one of the expert reviewers for the IANA iCalendar registries. Below 
are my comments on draft-ietf-calext-eventpub-extensions-12. This review 
has focussed solely on the definitions of the new iCalendar elements 
expected to be published by IANA.

I have divided up this review into two sections: the first are issues that 
I think warrant further discussion; the second are issues that need simple 
corrections.

Part 1
======

1. Section 6 (SOURCE): Adding a new value type for an existing property is 
potentially not backwards compatible as existing implementations may be 
coded to validate that the SOURCE property is only VALUE=URI. Have any 
tests been done to see if this change will break any current iCalendar 
implementations making use of SOURCE?

2. Section 8.1 (PARTICIPANT): should a UID property be required for this 
component? If not required, should it be optional? Or is there some other 
"primary key" that should be used to identify the same participant across 
multiple events ("calendaraddress" is not always present)?

3. Section 8.1 (PARTICIPANT): why isn't GEO property allowed in the 
component?

4. Section 5.2 (RESTYPE): How does a "remote conference" RESTYPE for a 
structured resource related to a CONFERENCE property defined by RFC 7986? 
Shouldn't CONFERENCE be preferred for describing a conference "resource"?

5. Section 5.3 (ORDER): "This parameter MAY be applied to any property that 
allows multiple instances". Strictly speaking this should result in the 
modification of lots of existing iCalendar properties to allow inclusion of 
this parameter. I presume the WG is OK with not requiring this draft to 
include all the updated property definitions? Or should this be scoped to 
only the new properties defined in this draft? I am not sure it is 
meaningful on properties like ATTENDEE

Part 2
======

1. Section 6: States "The default value type for this property is URI.". 
However, RFC 7986, which was the original definition of the property 
states: "Value Type:  URI -- no default". i.e., the VALUE parameter MUST 
always be present - there is no default. This draft must not override that 
behavior. Please fix.

2. Section 6: I think the Purpose field should include the purpose from RFC 
7986. Perhaps this can be re-worded:

    Purpose:  This property provides a reference to information about a
          component such as a participant possibly as a vcard or optionally
          a plain text typed value. It can also be used to identify a URI
          where calendar data can be refreshed from.

3. In Section 6: conformance does not indicate the cardinality of the 
property. RFC 7986 allows it only once in a VCALENDAR component. What is 
the cardinality for this new use of it? Also, I prefer the "style" used in 
RFC 7986 rather than the one using 2119 keywords - but I will leave that up 
to you.

4. Section 6: in the Description: "In a resource or participant". I 
understand that a "participant" means the new "PARTICIPANT" component - I 
think that should be explicitly described. But what is a "resource" - does 
that mean a "PARTICIPANT" component that represents a resource? Since this 
property seems to have differenting interpretations depending on the type 
of component it is used in, I think it would be better to enumerate all the 
components and describe the behaviors for each (grouping together where 
appropriate).

5. Section 6: Format definition: the "VALUE" items in the "source = " 
definition need to be moved to "sourceparam = " to avoid hard-coding the 
order of parameters. 5545's DTSTART definition shows how that can be done

6. Section 7.1: no cardinality in Conformance.

7. Section 7.1: Format definition: s/This parameter is defined/This 
property is defined/.

8. Section 7.1: Format definition: The "=" in participanttype should be ":".

9. Section 7.1: Format definition: Please include a definition for the 
parameters, even if it is only "otherparam".

10. Section 7.2: no cardinality in Conformance.

11. Section 7.2: Format definition: s/This parameter is defined/This 
property is defined/.

12. Section 7.2: Format definition: The "=" in calendaraddress should be 
":".

13. Section 7.2: Format definition: Please include a definition for the 
parameters, even if it is only "otherparam".

14. Section 7.3: Format definition: as per #6 above, please move VALUE= 
definitions into the param.

15. Section 7.4: Conformance: "in any iCalendar component". Section 4 shows 
this component only in a sub-set of others - those should be listed here. 
Why can't this be used in VJOURNAL or VFREEBUSY?

16. Section 7.4: Format definition: as per #6 above, please move VALUE= 
definitions into the param.

17: Section 7.5: Conformance: "in any iCalendar component". Section 4 shows 
this component only in a sub-set of others - those should be listed here.

18. Section 7.5: Format definition: as per #6 above, please move VALUE= 
definitions into the param. Also, the current definition is wrong - there 
should not be a "/" after strucresparam.

19. Section 7.6: Conformance: please state explicitly that TEXT is the 
default value.

20. Section 8.1: Conformance: "in any iCalendar component". Section 4 shows 
this component only in a sub-set of others - those should be listed here.

21. Section 8.1: no cardinality in Conformance.

22. Section 8.1: Format definition: s/This property is defined/This 
component is defined/.

23. Section 8.1: rstatus should probably not be present in this component 
as it is specific to scheduling of VEVENT, VTODO, VJOURNAL, and VFREEBUSY.

-- 
Cyrus Daboo

---

From: Michael Douglass <[email-masked]>
Date: Sun, 26 May 2019 23:19:43 -0400

Thanks Cyrus.

Some follow up questions below for:

Part 1 -

     #1 still considering that one

     #4

Part 2 - #19, 23

Given the number of changes I've submitted an updated draft with these 
and the previously noted changes.

Thanks.

On 5/20/19 16:12, Cyrus Daboo wrote:
> Hi,
> I am one of the expert reviewers for the IANA iCalendar registries. 
> Below are my comments on draft-ietf-calext-eventpub-extensions-12. 
> This review has focussed solely on the definitions of the new 
> iCalendar elements expected to be published by IANA.
>
> I have divided up this review into two sections: the first are issues 
> that I think warrant further discussion; the second are issues that 
> need simple corrections.
>
> Part 1
> ======
>
> 1. Section 6 (SOURCE): Adding a new value type for an existing 
> property is potentially not backwards compatible as existing 
> implementations may be coded to validate that the SOURCE property is 
> only VALUE=URI. Have any tests been done to see if this change will 
> break any current iCalendar implementations making use of SOURCE?
I guess that was the point of not allowing a default? If they don't know 
how to handle value=<anything other than uri> then they should ignore it.
>
> 2. Section 8.1 (PARTICIPANT): should a UID property be required for 
> this component? If not required, should it be optional? Or is there 
> some other "primary key" that should be used to identify the same 
> participant across multiple events ("calendaraddress" is not always 
> present)?
I'm OK with it being required. I hadn't thought of trying to indicate 
it's the same participant across different events. I guess for example 
it allows us to know it's the same hockey team for example. Added.
> 3. Section 8.1 (PARTICIPANT): why isn't GEO property allowed in the 
Added
> structured resource related to a CONFERENCE property defined by RFC 
> 7986? Shouldn't CONFERENCE be preferred for describing a conference 
> "resource"?
The intent was not to describe the conference but the resources required 
for a conference. I guess they could be implied from the conference property
>
> 5. Section 5.3 (ORDER): "This parameter MAY be applied to any property 
> that allows multiple instances". Strictly speaking this should result 
> in the modification of lots of existing iCalendar properties to allow 
> inclusion of this parameter. I presume the WG is OK with not requiring 
> this draft to include all the updated property definitions? Or should 
> this be scoped to only the new properties defined in this draft? I am 
> not sure it is meaningful on properties like ATTENDEE
>
> Part 2
> ======
>
> 1. Section 6: States "The default value type for this property is 
> URI.". However, RFC 7986, which was the original definition of the 
> property states: "Value Type:  URI -- no default". i.e., the VALUE 
> parameter MUST always be present - there is no default. This draft 
> must not override that behavior. Please fix.
Fixed
>
> 2. Section 6: I think the Purpose field should include the purpose 
> from RFC 7986. Perhaps this can be re-worded:
>
Added text
> property. RFC 7986 allows it only once in a VCALENDAR component. What 
> is the cardinality for this new use of it? Also, I prefer the "style" 
> used in RFC 7986 rather than the one using 2119 keywords - but I will 
> leave that up to you.
Switched to 7986 wording
> understand that a "participant" means the new "PARTICIPANT" component 
> - I think that should be explicitly described. But what is a 
> "resource" - does that mean a "PARTICIPANT" component that represents 
> a resource? Since this property seems to have differenting 
> interpretations depending on the type of component it is used in, I 
> think it would be better to enumerate all the components and describe 
> the behaviors for each (grouping together where appropriate).

I've made this more restrictive.

	In a PARTICIPANT component it may provide a reference to
	a vcard giving directory information.

> definition need to be moved to "sourceparam = " to avoid hard-coding 
> the order of parameters. 5545's DTSTART definition shows how that can 
> be done

Pretty sure I copied that out of some other spec...

Changed

> 6. Section 7.1: no cardinality in Conformance.
Fixed
> 7. Section 7.1: Format definition: s/This parameter is defined/This 
Fixed
> 8. Section 7.1: Format definition: The "=" in participanttype should 
Fixed
> parameters, even if it is only "otherparam".
Done
> 10. Section 7.2: no cardinality in Conformance.
Fixed
> 11. Section 7.2: Format definition: s/This parameter is defined/This 
Done
>
> 12. Section 7.2: Format definition: The "=" in calendaraddress should 
> be ":".
Done
>
> 13. Section 7.2: Format definition: Please include a definition for 
> the parameters, even if it is only "otherparam".
Done
>
> 14. Section 7.3: Format definition: as per #6 above, please move 
> VALUE= definitions into the param.
Done
>
> 15. Section 7.4: Conformance: "in any iCalendar component". Section 4 
> shows this component only in a sub-set of others - those should be 
> listed here. Why can't this be used in VJOURNAL or VFREEBUSY?
Omission - added
>
> 16. Section 7.4: Format definition: as per #6 above, please move 
> VALUE= definitions into the param.
Done
>
> 17: Section 7.5: Conformance: "in any iCalendar component". Section 4 
> shows this component only in a sub-set of others - those should be 
> listed here.
>
Done
> 18. Section 7.5: Format definition: as per #6 above, please move 
> VALUE= definitions into the param. Also, the current definition is 
> wrong - there should not be a "/" after strucresparam.
Done
> 19. Section 7.6: Conformance: please state explicitly that TEXT is the 

Following the example of the others:

     1. Should I remove the default and require VALUE=

     2. Move VALUE= and ENCODING= into the params

>
> 20. Section 8.1: Conformance: "in any iCalendar component". Section 4 
> shows this component only in a sub-set of others - those should be 
> listed here.
Fixed
> 21. Section 8.1: no cardinality in Conformance.
Fixed
> 22. Section 8.1: Format definition: s/This property is defined/This 
Fixed
>
> 23. Section 8.1: rstatus should probably not be present in this 
> component as it is specific to scheduling of VEVENT, VTODO, VJOURNAL, 
> and VFREEBUSY.

Deferred: wouldn't it be useful to have a per-attendee rstatus?