Re: Dealing with invites to individual instances

[Mark Swanson <mark@xxxxxxxxxxxxxxxxxxxxxxx>]

On August 20, 2003 8:09 pm, you wrote:
> > On August 20, 2003 6:20 pm, Michael Fair wrote:
> > >If I invite a CU using UID:1/RID:123/SEQ:0
> > >and then reschedule UID:1 such that instance 123
> > >is no longer a member of the recurrence set, how
> > >do I communicate this change to the CU?
> >
> > Care to provide some enlightenment on why it would be important to have
>
> the
>
> > CANCEL performed automatically? Am I missing something obvious about the
> > CANCEL/REQUEST (2 operations) vs performing it in one operation?
>
> Because event RID:123 was implicitly canceled when it's RECURRENCE-ID
> was removed from the set described by UID:1.  At no time was there an
> explicit

Got it.

> cancel sent to anyone, further only people who are not invited to the base
> event
> need be explicitly made aware of such changes.

Agreed. I can't find anything in iTIP that notifies attendees of disappearing 
recurring instances. It would seem like the courtious thing to do would be to 
send a cancel/request to those attendees.

<snip>
> So what is just a single reschedule to everyone else, needs to be a
> CANCEL and a REQUEST to me.  Or there needs to be some other
> mechanism by which I can detect that RID:123 is no longer a member
> of the recurrence set for UID:1.

I think you've made a good point. Doing a cancel/request means the problem is 
solved within the iTIP spec - and I've noticed that under those circumstances 
a very hot place would have to freeze over before iTIP would be modified to 
handle it differently. :-)

There's bound to be a number of little implementation details like this. It 
sure would be nice if they were captured in a common location.

</me hears nothing but the rustling of the wind in a far off Saskatchewan 
wheat field>


-- 
Schedule your world with ScheduleWorld.com
http://www.ScheduleWorld.com/
Java Web start (JNLP):
http://www.ScheduleWorld.com/sw/ScheduleWorld.jnlp