Subject: RE: Fw: Correct handling of Recurrence-id

From: Arnaud Quillaud <[email-masked]>
Date: Thu, 12 Jun 2003 14:19:52 -0700

> 
> > Unless Doug or George can demonstate how to resync, etc 
> using a delta 
> > model I suggest we make a strong WG note to remove the 
> misleading text 
> > from the next revision of 2445 and move on.
> 
> You do not have to SYNC - simply do a REFRESH and get the 
> latest object
> version.
> 

But in Bruce model, you do *not* have to do a REFRESH. That sounds like a
much simpler mechanism.

So, what is the advantage of the changing recurrence-id model ?

Arnaud

---

From: Doug Royer <[email-masked]>
Date: Thu, 12 Jun 2003 15:46:46 -0600

Arnaud Quillaud wrote:
> But in Bruce model, you do *not* have to do a REFRESH. That sounds like 
> a much simpler mechanism.

You are totally hosed if you were not part of SEQUENCE:0
or somehow loose your data.

And when 100% of the original instances change and you
somehow missed an important change. The new instances
will not map to the SEQUENCE:0 instances and you
might apply them incorrectly.

-- 

  Doug Royer                     |   http://INET-Consulting.com
  -------------------------------|-----------------------------
  [email-masked]                 | Office: (208)612-INET
  http://Royer.com/People/Doug   |    Fax: (866)594-8574
                                 |   Cell: (208)520-4044

                 We Do Standards - You Need Standards

---

From: "Chris Olds" <[email-masked]>
Date: Thu, 12 Jun 2003 14:49:02 -0700

On Thu, 12 Jun 2003 14:19:52 -0700, Arnaud Quillaud wrote
> But in Bruce model, you do *not* have to do a REFRESH. That sounds 
> like a much simpler mechanism.
> 

In Bruce's model, I need to keep track of the original recurrence-id of each
instance of an event as they evolve.  In the REFRESH model, all I need to do
is get the current version of the object and I'm done.  If I have the current
version, I can use a message with a RECURRENCE-ID to update my view of the
object; if I don't have the current version, I just found that out and I can
ask for a REFRESH and I'm done.

    /cco

--
GPG Key Fingerprint: B375 A4E7 752B DB8C 4359  852E C3CF BF64 379A E9B2
Debian Project (http://www.debian.org)

---

From: Arnaud Quillaud <[email-masked]>
Date: Fri, 13 Jun 2003 10:47:36 -0700

> You are totally hosed if you were not part of SEQUENCE:0

I've asked Bruce about a new attendee being added to the VEVENT (I've 
included both my question and his response). In his view, the recurrence 
set (RRULE+RDATE+EXDATE+RDATE) that would be sent to this new attendee 
would be the original one so there wouldn't be any ambiguity.

> or somehow loose your data.

If you loose your data, you're hosed, whatever the model. All you can do 
is to do a REFRESH, that is, if you still have the ORGANIZER and UID.
The REFRESH would work (see above).

> might apply them incorrectly.

You mean, if the organizer change the recurrence set (e.g. change the 
event from weekly to bi-weekly) ?
I guess, Bruce rules needs to be refined to say that the list of 
recurrence-id  refers to the latest recurrence set 
(RRULE+RDATE-EXRULE-EXDATE) sent by the organizer.
Bruce ?

BTW, is there a section in iTIP that talks about handling of exceptions 
on the attendee side, when receiving a REQUEST with a new recurrence set ?
For example:
1st REQUEST
RRULE: weekly on mondays for ever

2nd REQUEST
RECURRENCE-ID=second monday
DTSTART=second tuesday

3rd REQUEST
RRULE: weekly on wednesday

Does the 3rd REQUEST implicitly means cancel of the second tuesday's 
instance ? Or should the attendee consider it still valid unless it 
receives a CANCEL ?

Thanks,

Arnaud

Subject: Re: Correct handling of Recurrence-id
From: Arnaud Quillaud <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Date: Fri, 23 May 2003 17:15:12 -0700

[email-masked] wrote:

>
> > The only disadvantage of version 1 that I can think of is about
> > someone joining the party while some rescheduling has already
> > occured. Since the newcommer won't have the SEQUENCE: 0 of the
> > recurrence set, he might interpret the set of RECURRENCE-ID
> > differently. But maybe this is just because I don't understand what
> > the right iTIP workflow is.
>
> Its not a problem for the non-delta model.  The Organizer simply sends 
> a new invitee a REQUEST that contains the information they will need 
> to correctly identify the instance and put it on the right date/time. 
>  So, continuing the example I used earlier to add Arnaud to Friday 
> 13-Jun-03 I would simply send the following REQUEST:
>
>    BEGIN:VCALENDAR
>   PRODID:-//ACME/DesktopCalendar//EN
>   METHOD:REQUEST
>   VERSION:2.0
>   BEGIN:VEVENT
>   ORGANIZER:Mailto:[email-masked]
>   ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:Mailto:[email-masked]
>   
> ATTENDEE;RSVP=TRUE;PARTSTAT=NEEDS-ACTION;TYPE=INDIVIDUAL;CN=Doug:Mailto:[email-masked]
>   
> ATTENDEE;RSVP=TRUE;PARTSTAT=NEEDS-ACTION;TYPE=INDIVIDUAL;CN=George:Mailto:[email-masked]
>   
> ATTENDEE;RSVP=TRUE;PARTSTAT=NEEDS-ACTION;TYPE=INDIVIDUAL;CN=Tom:Mailto:[email-masked]
>   
> ATTENDEE;RSVP=TRUE;PARTSTAT=NEEDS-ACTION;TYPE=INDIVIDUAL;CN=Ki:Mailto:[email-masked]
>   
> ATTENDEE;RSVP=TRUE;PARTSTAT=NEEDS-ACTION;TYPE=INDIVIDUAL;CN=Arnaud:Mailto:[email-masked]
>   DTSTART:20030613T140000Z
>   DTEND:20030613T150000Z
>   SUMMARY:Head bashing
>   UID:[email-masked]
>   SEQUENCE:3
>    RECURRENCE-ID:20030609T140000Z
>   DTSTAMP:20030523T225900Z
>   END:VEVENT
>   END:VCALENDAR
>
In my example, I was talking about the case where the Organizer wants to 
invite a totally new attendee to the whole serie, not just a particular 
instance.

initial REQUEST. Bruce invites bob and only bob:

BEGIN:VEVENT
UID:that
SEQUENCE:0
DTSTART: monday the 1st at 10am
RRULE: every monday forever
ATTENDEE: bob
END:VEVENT

Bruce changes the second instance to tuesday, so he sends a new iTIP 
REQUEST to bob:

BEGIN:VEVENT
UID:that
SEQUENCE:1
RECURRENCE-ID: monday the 8th at 10am
DTSTART: tuesday the 9th at 10am
ATTENDEE:bob
END:VEVENT

Now, Bruce wants to invite arnaud to _all _instances of the recurring 
event. Arnaud has no information about this event in his CUA. So I'm 
assuming Bruce will send him one iTIP request containing the "master" 
event + the exception, right ?

What will this request look like in your model ?

Will it be:

BEGIN:VCALENDAR
METHOD:REQUEST
...
BEGIN:VEVENT
UID:that
SEQUENCE:1
DTSTART: monday the 1st at 10am
*RRULE: every monday forever*
ATTENDEE: bob
ATTENDEE:arnaud
END:VEVENT
BEGIN:VEVENT
UID:that
SEQUENCE:1
RECURRENCE-ID: monday the 8th at 10am
DTSTART: tuesday the 9th at 10am
ATTENDEE:bob
ATTENDEE:arnaud
END:VEVENT
END:VCALENDAR

or will it be:

BEGIN:VCALENDAR
BEGIN:VEVENT
UID:that
SEQUENCE:1
DTSTART: monday the 1st at 10am
*RRULE: every monday forever
RDATE: tuesday the 9th at 10am
EXDATE: monday the 8th at 10am*
ATTENDEE: bob
ATTENDEE:arnaud
END:VEVENT
BEGIN:VEVENT
UID:that
SEQUENCE:1
RECURRENCE-ID: monday the 8th at 10am
DTSTART: tuesday the 9th at 10am
ATTENDEE:bob
ATTENDEE:arnaud
END:VEVENT
END:VCALENDAR

Or did I totally missed the logic of iTIP and does he send something else ?

Thanks,

Arnaud

Subject: Re: Correct handling of Recurrence-id
From: [email-masked]
To: [email-masked]
Date: Tue, 27 May 2003 16:22:30 -0400
List-Id: <ietf-calendar.imc.org>

Arnaud Quillaud wrote on 05/23/2003 08:15:12 PM:
> Now, Bruce wants to invite arnaud to all instances of the recurring 
> event. Arnaud has no information about this event in his CUA. So I'm
> assuming Bruce will send him one iTIP request containing the 
> "master" event + the exception, right ?

Yes.  From iTIP, Section 3.2.2 REQUEST:

   For the "REQUEST" method, multiple "VEVENT" components in a single
   iCalendar object are only permitted when for components with the same
   "UID" property.  That is, a series of recurring events may have
   instance-specific information.  In this case, multiple "VEVENT"
   components are needed to express the entire series.

So the iCalendar stream would contain the "base" definition followed by 
any instance specific data that "override the base" definition.

> What will this request look like in your model ?
> 
> Will it be:
> 
> BEGIN:VCALENDAR
> METHOD:REQUEST
> ...
> BEGIN:VEVENT
> UID:that
> SEQUENCE:1
> DTSTART: monday the 1st at 10am
> RRULE: every monday forever
> ATTENDEE: bob
> ATTENDEE:arnaud
> END:VEVENT
> BEGIN:VEVENT
> UID:that
> SEQUENCE:1
> RECURRENCE-ID: monday the 8th at 10am
> DTSTART: tuesday the 9th at 10am
> ATTENDEE:bob
> ATTENDEE:arnaud
> END:VEVENT
> END:VCALENDAR

For the most part yes.  The SEQUENCE property in the base would be 0, not 
1 but close enough... (Since only the 2nd instance got rescheduled only 
its SEQUENCE value has changed.)

> or will it be:
> 
> BEGIN:VCALENDAR
> BEGIN:VEVENT
> UID:that
> SEQUENCE:1
> DTSTART: monday the 1st at 10am
> RRULE: every monday forever
> RDATE: tuesday the 9th at 10am
> EXDATE: monday the 8th at 10am
> ATTENDEE: bob
> ATTENDEE:arnaud
> END:VEVENT
> BEGIN:VEVENT
> UID:that
> SEQUENCE:1
> RECURRENCE-ID: monday the 8th at 10am
> DTSTART: tuesday the 9th at 10am
> ATTENDEE:bob
> ATTENDEE:arnaud
> END:VEVENT
> END:VCALENDAR

Not this because the "base" definition does NOT define the entire repeat 
set that was originally defined.  It defines a set of [ "Every Monday 
Forever" + "Tuesday the 9th" - "Monday the 8th" ].  The "update" that 
follows now specifies an instance that was not part of the "base" (the 
RECURRENCE-ID is not reachable from the "base" because it was EXDATEed 
out).

The other problem I see is that the 1st object defines a Tuesday the 9th 
instance initially thus making the RECURRENCE-ID for that instance of 
"Tuesday the 9th" and not "Monday the 8th" which later got rescheduled to 
the 9th (in the second object).  This could mean that when a CUA rolls out 
both of these VEVENTs they 'dedup' the 2 "Tuesday the 9th" entries (per 
iCalendar) and may not be able to properly reschedule the Tuesday entry to 
a new date/time.

> Or did I totally missed the logic of iTIP and does he send something 
else ?

No, I think that was pretty much on track.  The RFCs could use some prose 
in some areas and no doubt if you spend some cycles on repeating entries 
more gaps/mistakes will appear.

Does this jive with your expectations?

Bruce
===========================================================================
Bruce Kahn                                INet: 
[email-masked]
Messaging & Collaboration                 Phone: 978.399.6496
IBM Software Group                         FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law...

---

From: Doug Royer <[email-masked]>
Date: Fri, 13 Jun 2003 12:59:23 -0600

> would be the original one so there wouldn't be any ambiguity.

Perhaps his implementations keeps old SEQUENCE / object sets around.
I would not bet my CUA on it. And how do you ask for the original
object so you can then know those now old RDATEs in the original
object?

> The REFRESH would work (see above).

Yes you can do a REFRESH, however you will get the latest object
with the latest SEQUENCE value, not the original. So you will
not get the original recurrence set and in that model you will
not be able to re-create the original recurence-id set.

> (RRULE+RDATE-EXRULE-EXDATE) sent by the organizer.

If it refers to he 'latest recurrence set' - we agree.
It can not then ever refer to the 'original' recurrence set
unless the 'latest' just happens to be 'SEQUENCE:0'.

--