This set of commits, along with the recent changes to the to/from 
iCalendar code in Kronolith should close this issue.

Changes have been made in Git for this ticket:

Handle iTip CANCEL request of a recurring event instance correctly.
According to RFC 2446, when cancelling an instance of a recurring
event, the RECURRENCE-ID value MUST be specified along with the UID.
If cancelling the entire event series, the RECURRENCE-ID value
MUST NOT be included.

Bug: 8956

http://git.horde.org/diff.php/imp/lib/Mime/Viewer/Itip.php?rt=horde-git&r1=1a61808f3fb6881144106806a21e9532c25775ae&r2=90a9aa6cd06eeb00f09baf369f2c087210dc68f8
http://git.horde.org/diff.php/kronolith/lib/Api.php?rt=horde-git&r1=3bd6cf612aa29fde902bb6a88b18b548b3aaa14b&r2=90a9aa6cd06eeb00f09baf369f2c087210dc68f8
http://git.horde.org/diff.php/kronolith/lib/Kronolith.php?rt=horde-git&r1=3bd6cf612aa29fde902bb6a88b18b548b3aaa14b&r2=90a9aa6cd06eeb00f09baf369f2c087210dc68f8

Yes, that sounds better. :)

Sorry, actually we can just send an appropriately built CANCEL message 
with the UID and RECURRENCE-ID.

Since we now store relationships between exceptions and their related 
recurring event, it seems to me we can do the following:

If it's being rescheduled to a different date/time, we can send an 
iTip with just this modification, with the UID and RECURRENCE-ID 
fields filled in appropriately.

If the event instance is outright canceled, send an iTip representing 
the entire event series, with appropriate values for EXDATE. Yes, this 
would also have to include the vEvent components for any already 
existing rescheduled exceptions, but that seems to me to be ok since 
all the vEvent components would be for the same UID. (As I understand 
RFC 2446, you can have multiple vEvent entries in the single iCalendar 
REQUEST if they all reference the same UID).

Sound right, or am I missing something?

Yes, I think that could be the best approach.
  - If the event is rescheduled (so is not going to happen on the 
original date time ) the attendee should update the event with the 
exception.
  - In addition, attendee may or may not accept the new event

Thanks for response, regards,

I don't think it's possible to add an exception through a single 
iCalendar message. So in this case we probably have to send two 
updates to the attendees, one which updates the original event, with 
the new exception, and one with the replacement event.

When I reschedule one entry of a recurrent event, the behaviour seems to be:
- Create exception on recurrent event on Meeting creator/modifier calendar
- Create new event with modified details of the event
- Notify attendees about the "new event"

When attendees "accept and add to calendar" the notified event, it 
creates a new one on calendar, but the exception is not added to the 
recurrent event, which it seems to be duplicated on the attendee 
calendar.

I hope the issue is more or less clear. Do not doubt to contact me if 
more info is needed.

Regards,