[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Dealing with invites to individual instances
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
> > 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
> cancel sent to anyone, further only people who are not invited to the base
> 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.
> 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
Schedule your world with ScheduleWorld.com
Java Web start (JNLP):