Subject: [Ietf-calsify] Overlapping reschedule

From: cyrus at daboo.name (Cyrus Daboo)
Date: Thu Sep 14 11:08:44 2006

Hi folks,
Lets assume an organizer has booked an event with one or more attendees for 
12:00 pm to 1:00 pm. The organizer then wants to reschedule that to 12:30 
pm to 1:30 pm. If the organizer does an iTIP VFREEBUSY REQUEST for the new 
time range the attendees will show up as busy for the first half hour 
because of the existing booked event. There are several solutions to this:

1) The organizer needs to 'subtract' the original event's time from any 
busy time it gets back from the iTIP request (i.e. effectively overriding 
when the attendees report as being busy). This seems reasonable if the 
attendee had previous accepted the meeting (and had not deliberately 
double-booked), but if they had not accepted it may be wrong to do. This 
method would work for recurring events.

2) The organizer only issues the free-busy request for the second half hour 
period of the new meeting. Well that would work in this case, but if the 
new meeting had been 11 am - 2 pm (i.e. new time required both before and 
after the original) then two requests would have to be done. Plus it gets 
worse for recurring events. The same issue with accepted attendees would 
apply.

3) Extend iTIP to allow the organizer to specify a list of UIDs of events 
that should be excluded from any busy time results returned in the reply. 
The organizer could then supply the original event UID and the attendees' 
clients would exclude that from busy. This would work for any attendee 
state and recurring meetings (though we would probably have to send UID + 
list of Recurrence-IDs to handle reschedule of exceptions). However it is 
an extension to iTIP.

4) Organizer first cancels the original meeting and then does free busy 
lookup. This is not good as the cancel operation may require the attendees' 
manual intervention to accept, whereas the free-busy lookup may complete 
faster (c.f. CalDAV where free busy iTIP operations execute immediately, 
whereas others require explicit acceptance from the attendee).

Any thoughts on this?

-- 
Cyrus Daboo

---

From: mark.paterson at oracle.com (Mark Paterson)
Date: Fri Sep 15 06:27:59 2006

3) certainly seems like an interesting possibility.

Cyrus Daboo wrote:
> Hi folks,
> Lets assume an organizer has booked an event with one or more 
> attendees for 12:00 pm to 1:00 pm. The organizer then wants to 
> reschedule that to 12:30 pm to 1:30 pm. If the organizer does an iTIP 
> VFREEBUSY REQUEST for the new time range the attendees will show up as 
> busy for the first half hour because of the existing booked event. 
> There are several solutions to this:
>
> 1) The organizer needs to 'subtract' the original event's time from 
> any busy time it gets back from the iTIP request (i.e. effectively 
> overriding when the attendees report as being busy). This seems 
> reasonable if the attendee had previous accepted the meeting (and had 
> not deliberately double-booked), but if they had not accepted it may 
> be wrong to do. This method would work for recurring events.
>
> 2) The organizer only issues the free-busy request for the second half 
> hour period of the new meeting. Well that would work in this case, but 
> if the new meeting had been 11 am - 2 pm (i.e. new time required both 
> before and after the original) then two requests would have to be 
> done. Plus it gets worse for recurring events. The same issue with 
> accepted attendees would apply.
>
> 3) Extend iTIP to allow the organizer to specify a list of UIDs of 
> events that should be excluded from any busy time results returned in 
> the reply. The organizer could then supply the original event UID and 
> the attendees' clients would exclude that from busy. This would work 
> for any attendee state and recurring meetings (though we would 
> probably have to send UID + list of Recurrence-IDs to handle 
> reschedule of exceptions). However it is an extension to iTIP.
>
> 4) Organizer first cancels the original meeting and then does free 
> busy lookup. This is not good as the cancel operation may require the 
> attendees' manual intervention to accept, whereas the free-busy lookup 
> may complete faster (c.f. CalDAV where free busy iTIP operations 
> execute immediately, whereas others require explicit acceptance from 
> the attendee).
>
> Any thoughts on this?
>

-- 
MARK PATERSON
Product Manager, OCS Mobility
Oracle Corporation - Server Technologies

Phone:  514.905.8649
Mobile: 514.862.8505
mailto: [email-masked]
http:   www.oracle.com

---

From: cyrus at daboo.name (Cyrus Daboo)
Date: Fri Sep 15 06:36:46 2006

Hi Mark,

>> reschedule of exceptions). However it is an extension to iTIP.

Having thought about this some more I realize that there is a security 
concern with this. At the very least the 'ignored UIDs' list must refer to 
components whose ORGANIZER property is the same as the ORGANIZER in the 
free-busy request. So the entity doing the free-busy lookup MUST check the 
ORGANIZER properties before ignoring an event.

-- 
Cyrus Daboo