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

[Bernard Desruisseaux]

Eliot,

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:

http://www.geocities.com/bdesruisseaux/calsify/draft-ietf-calsify-rfc2445bis-03.html

http://www.geocities.com/bdesruisseaux/calsify/draft-ietf-calsify-rfc2445bis-03.txt

Cheers,
Bernard

Eliot Lear wrote:
> 
> Bernard,
> 
> 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,
> 
> Eliot
> 
> 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
>>           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
>> _______________________________________________
>> Ietf-calsify mailing list
>> Ietf-calsify at osafoundation.org
>> http://lists.osafoundation.org/mailman/listinfo/ietf-calsify
>>