[Ietf-calsify] Issue 13, 24, 25: Generation of the recurrence set
bernard.desruisseaux at oracle.com
Thu Oct 19 13:00:45 PDT 2006
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
Issue 24: Need to clarify number of recurrence instances
generated when multiple recurrence rules are
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
- 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.
More information about the Ietf-calsify