[Ietf-calsify] Issue 13, 24, 25: Generation of the recurrence set

[Bernard Desruisseaux]

Here's an omnibus proposal that addresses the following issues:

Issue 13: Is the first instance defined by DTSTART always
           considered as part of the COUNT of a recurrence
           rule?

Issue 24: Need to clarify number of recurrence instances
           generated when multiple recurrence rules are
           specified.

Issue 25: Is the first instance defined by DTSTART always
           excluded by EXRULE?

Based on the information I currently have, we only have
good interoperability when:

   - The value of the DTSTART property matches the pattern of
     the recurrence rule;

   - Only a single RRULE property is specified;

   - No EXRULE property is specified.

Given that most calendar client applications currently don't provide
a way to create a recurring component:

   - with a DTSTART property value that doesn't match the
     pattern of the recurrence rule;

   - with multiple recurrence rules;

   - with an exclusion recurrence rule.

I propose to modify the iCalendar specification to state the
following:

   - In a recurring component, the value of the DTSTART property
     SHOULD match the pattern of the recurrence rule. The recurrence
     set generated with a DTSTART property value that doesn't match
     the pattern of the rule is undefined.

   - The RRULE property SHOULD NOT occur more than once in a
     recurring component. The recurrence set generated with
     multiple RRULE properties is undefined.

   - The use of the EXRULE property is deprecated.

     Every reference to EXRULE would be removed from the draft.
     The EXRULE property would be documented as "Deprecated" in
     an Appendix of the draft and would refer readers to RFC 2445
     for more information on this property.

Cheers,
Bernard