Subject: Re: [Ietf-calsify] RFC 2445bis Issue 63: Consensus needed

From: Ciny Joy <[email-masked]>
Date: Tue, 06 Nov 2007 14:14:56 -0800

>
>>
>>This time I would like to suggest a solution for the case where
>>an organizer changes all future recurrence instances of a recurring
>>calendar component:
>>
>>1- Specify RDATE properties for all past recurrence instances
>>   and define exception components for them if needed. 
>>
How do you define "if needed"?

>>The
>>   number of past recurrence instances is always finite...
>>
>>2- Remove EXDATE properties for any past recurrence instances.
>>
>>3- Set DTSTART to the first recurrence instance to which you
>>   want the change to apply.
>>    
>>
So is original DTSTART lost completely? Doesn't this go against the 
statement, "However, in such cases the original "DTSTART" date MUST 
still be maintained by the calendaring and scheduling system because the 
original "DTSTART" value has inherent usage dependencies by other 
properties such as the "RECURRENCE-ID"."
If not, is there a standard way of maintaining it?
Also, in multiple places it is stated "The "DTSTART" property defines 
the first instance in the recurrence set". Will that be modified?

Thanks,
Ciny

>>The only issue here is that we need to clarify that RDATE can
>>specify a value less than the value specified by DTSTART.
>>
>>Cheers,
>>Bernard
>>    
>>

_______________________________________________
Ietf-calsify mailing list
[email-masked]
http://lists.osafoundation.org/mailman/listinfo/ietf-calsify

---

From: Bernard Desruisseaux <[email-masked]>
Date: Wed, 14 Nov 2007 01:20:06 -0500

Hi Ciny,

> How do you define "if needed"?

A past recurrence instance identical to the recurrence instance
defined by DTSTART, except for its scheduled time, would not need
a separate component.

> So is original DTSTART lost completely?

The recurrence instance previously defined by DTSTART would become
a simple recurrence instance defined by an RDATE property. You
wouldn't be able to figure out what was the original DTSTART.

 > Doesn't this go against the

I would think that what really matter is that the set of RECURRENCE-ID
is maintained.

> the first instance in the recurrence set". Will that be modified?

That would clearly need to be modified.

Cheers,
Bernard

---

From: Ciny Joy <[email-masked]>
Date: Wed, 14 Nov 2007 10:59:01 -0800

Thanks Bernard. Just one question below...

> defined by DTSTART, except for its scheduled time, would not need
If we are making a "This & Future" change and changing dtstart to the 
first instance of the newly created series, won't all past instances be 
different from DTSTART? Or am I understanding this wrong?

Thanks,
Ciny
>> still be maintained by the calendaring and scheduling system because 
>> the original "DTSTART" value has inherent usage dependencies by other

---

From: Bernard Desruisseaux <[email-masked]>
Date: Thu, 15 Nov 2007 15:03:59 -0500

Hi Ciny,

> different from DTSTART? Or am I understanding this wrong?

Here's a simple example where separate components would not be
needed for past recurrence instances:

A.1 Schedule a daily event at 9:00 AM forever starting on Nov. 12.

     BEGIN:VEVENT
     DTSTART;TZID=America/Montreal:20071112T090000
     DTEND;TZID=America/Montreal:20071112T100000
     RRULE:FREQ=DAILY
     ...
     END:VEVENT

A.2 Reschedule 4th recurrence instance (Nov. 15) as well as
     all future recurrence instances at 10:00 AM

     BEGIN:VEVENT
     RDATE;TZID=America/Montreal:20071112T090000/20071112T100000
     RDATE;TZID=America/Montreal:20071113T090000/20071113T100000
     RDATE;TZID=America/Montreal:20071114T090000/20071114T100000
     DTSTART;TZID=America/Montreal:20071115T100000
     DTEND;TZID=America/Montreal:20071115T110000
     RRULE:FREQ=DAILY;COUNT=5
     ...
     END:VEVENT

Now let's look at a slightly more complex example:

B.1 Schedule a daily event at 9:00 AM forever starting on Nov. 12.

     BEGIN:VEVENT
     DTSTART;TZID=America/Montreal:20071112T090000
     DTEND;TZID=America/Montreal:20071112T100000
     RRULE:FREQ=DAILY
     ...
     END:VEVENT

B.2 Reschedule 2nd recurrence instance (Nov. 13) at 10:00 AM.

     BEGIN:VEVENT
     DTSTART;TZID=America/Montreal:20071112T090000
     DTEND;TZID=America/Montreal:20071112T100000
     RRULE:FREQ=DAILY;COUNT=5
     ...
     END:VEVENT
     BEGIN:VEVENT
     RECURRENCE-ID;TZID=America/Montreal:20071113T090000
     DTSTART;TZID=America/Montreal:20071113T100000
     DTEND;TZID=America/Montreal:20071113T110000
     ...
     END:VEVENT

B.3 Reschedule 4th recurrence instance (Nov. 15) as well as
     all future recurrence instances at 10:00 AM

     BEGIN:VEVENT
     RDATE;TZID=America/Montreal:20071112T090000/20071112T100000
     RDATE;TZID=America/Montreal:20071113T090000/20071113T100000
     RDATE;TZID=America/Montreal:20071114T090000/20071114T100000
     DTSTART;TZID=America/Montreal:20071115T100000
     DTEND;TZID=America/Montreal:20071115T110000
     RRULE:FREQ=DAILY;COUNT=5
     ...
     END:VEVENT
     BEGIN:VEVENT
     RECURRENCE-ID;TZID=America/Montreal:20071113T090000
     DTSTART;TZID=America/Montreal:20071113T100000
     DTEND;TZID=America/Montreal:20071113T110000
     ...
     END:VEVENT

Here you'll notice that the RDATE for the 2nd recurrence instance
specifies the original scheduled time of this instance in order to
preserve the original RECURRENCE-ID.

The real concern here is that starting from the 4th recurrence
instance, we have lost the original RECURRENCE-IDs. We need to
think carefully about how bad that really is.  What are our
options?

1- Keep the RANGE parameter and address its issues.  Hummm...

2- Remove the RANGE parameter, and recommend to move DTSTART
    to the future instance that corresponds to the new recurrence
    pattern for all future instances (current proposal) and
    live with the fact that the RECURRENCE-ID of all those
    instances will have changed.

3- Remove the RANGE parameter, and recommend to split the
    calendar component in two. One calendar component with
    the original RRULE modified to specify a COUNT or UNTIL
    rule part, and a second calendar component that specify
    a new RRULE with no COUNT or UNTIL rule part.

4- Something we haven't thought about yet...

Not clear which is the best (or less worse) solution.
Perhaps it depends on the situation.  When an Organizer
decide to reschedule all future recurrence instances
option (3) might be the way to go.  On the other hand,
when an Attendee decide to decline all future recurrence
instances, option (2) might be the only way to go.
I'm wondering how many people bothered to read this email
that far. Send me a private email if you did. Just curious.
Sorry.

Cheers,
Bernard

---

From: Cyrus Daboo <[email-masked]>
Date: Thu, 15 Nov 2007 17:01:49 -0500

Hi Bernard,

> On the other hand, when an Attendee decide to decline all future
> recurrence instances, option (2) might be the only way to go.

Actually I disagree. In that case there is a finite set of instances that 
the attendee has accepted and an infinite set that is declined. So the 
master component is marked as declined, and then overridden components for 
the finite set added with accepted status for that attendee. None of that 
involves either (1), (2) or (3).

I'm still not sure what the best overall solution for this is though. I am 
concerned about the loss of RECURRENCE-ID sync caused by (2). I think the 
rule should be if you have to do something that causes the recurrence-ids 
to change then you have to split the events. So that would cover the case 
of changing the time of all future instances, or changing the pattern of 
the rule, but not of changing the location of all future instances. For the 
later you would change the location of the master, then override all 
components upto the actual point of change and use the old location in 
those. Same would apply to attendee state etc. However, if we take that 
approach, it actually eliminates some of the problems with RANGE= and makes 
that more viable.

-- 
Cyrus Daboo

---

From: Ciny Joy <[email-masked]>
Date: Thu, 15 Nov 2007 16:10:37 -0800

Thanks again Bernard.
Sorry about not cc'ing the list earlier. It was an accidental omission.
I usually get the digest of the mailing list emails. So haven't seen 
Cyrus's reply yet. But glad to know I wasn't completely off track.
Looking forward to more discussions that might provide a solution to the 
preserving of future exceptions on a time change issue.

Thanks,
Ciny

Bernard Desruisseaux wrote:
> Hi Ciny,
>
> I'm only replying to you since you didn't CC the list on your message.
> Not sure why though!
>
> Ciny Joy wrote:
>> Thanks a lot for the detailed explanation. But if the "This & Future" 
>> change is for any field other than dtstart/dtend like description, 
>> attendee etc, we will need to create exceptions for all past instances?
>
> Yes.
>
>>> instance, we have lost the original RECURRENCE-IDs. 
>> We also remove any existing exception components in the future?
>
> You're right!  All the recurrence instance that were cancelled
> by mean of an EXDATE would also disappear.
>
>>> We need to
>> The way I was thinking was, the difference is between a change that 
>> affects time and a change that doesn't. For the latter, wouldn't 
>> creating exceptions for the past events with the old data and 
>> updating master and existing future exceptions with the new be enough?
>
> Cyrus pointed this out on the mailing list and I agree.
>
> > For the
>> former, we were thinking of option 3 but some folks wanted to keep 
>> future exceptions. And that meant exception components with 
>> recurrence-ids that did not match the master. We got stuck there :-(
>
> I don't have much time to investigate right now, but it seems that
> Apple iCal is able to do that.  I'll get back to you when I'll have
> a chance to look at what they are actually sending to our server...
>
>>
>> Again, I might be way off track on this.
>
> No, you're not!
>
> Cheers,
> Bernard
>
>>
>> Thanks,
>> Ciny
>>>>>> statement, "However, in such cases the original "DTSTART" date 
>>>>>> MUST still be maintained by the calendaring and scheduling system 
>>>>>> because the original "DTSTART" value has inherent usage 
>>>>>> dependencies by other properties such as the "RECURRENCE-ID"."
>>>>>
>>>>>> Also, in multiple places it is stated "The "DTSTART" property 
>>>>>> defines the first instance in the recurrence set". Will that be 
>>>>>> modified?
>>>>>