[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Fw: Correct handling of Recurrence-id

Doug Royer wrote:



Arnaud Quillaud wrote:

>
> > 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


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).



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.


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

--- Begin Message --- Bruce_Kahn@xxxxxxxxxxxxxxxx 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:Bruce@xxxxxxxxxx
  ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:Mailto:Bruce@xxxxxxxxxx
  ATTENDEE;RSVP=TRUE;PARTSTAT=NEEDS-ACTION;TYPE=INDIVIDUAL;CN=Doug:Mailto:Doug@xxxxxxxxx
  ATTENDEE;RSVP=TRUE;PARTSTAT=NEEDS-ACTION;TYPE=INDIVIDUAL;CN=George:Mailto:George@xxxxxxxxxx
  ATTENDEE;RSVP=TRUE;PARTSTAT=NEEDS-ACTION;TYPE=INDIVIDUAL;CN=Tom:Mailto:Tom@xxxxxxxxxxx
  ATTENDEE;RSVP=TRUE;PARTSTAT=NEEDS-ACTION;TYPE=INDIVIDUAL;CN=Ki:Mailto:Ki@xxxxxxx
  ATTENDEE;RSVP=TRUE;PARTSTAT=NEEDS-ACTION;TYPE=INDIVIDUAL;CN=Arnaud:Mailto:Arnaud@xxxxxxx
  DTSTART:20030613T140000Z
  DTEND:20030613T150000Z
  SUMMARY:Head bashing
  UID:calsrv.widget.com-873970198738777@xxxxxxxxxx
  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

--- End Message ---
--- Begin Message ---
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: Bruce_Kahn@xxxxxxxxxxxxxxxx
Messaging & Collaboration                 Phone: 978.399.6496
IBM Software Group                         FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law...
--- End Message ---