[Ietf-calsify] Issue 13, 24, 25: Generation of the recurrence set
bernard.desruisseaux at oracle.com
Sun Oct 22 22:56:35 PDT 2006
I've just submitted draft -03 with the changes you've requested.
Those interested to review the draft before it is announced can
find it at the following locations:
Eliot Lear wrote:
> Thank you for this proposal. I believe it addresses the desire of
> people to simplify recurrence rules, and at the same time deals with
> much of the ambiguities in the issues that we have been discussing.
> I would ask that you please go ahead and make the changes to the draft
> accordingly in order for people to actually see what you have in mind.
> If you can have this in people's hands before the cutoff on Monday,
> that'd be utterly fantastic.
> Thanks for your initiative,
> Bernard Desruisseaux wrote:
>> 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.
>> Ietf-calsify mailing list
>> Ietf-calsify at osafoundation.org
More information about the Ietf-calsify