On Mo, 2011-08-29 at 13:49 +0200, Patrick Ohly wrote:
Consider the following situation:
1. User A sets up a recurring meeting.
2. He invites user B for one (but not all) recurrences, which
happens to be modified (say, different summary).
3. User B receives the meeting invitation. It gets added to his
4. User A invites him for the recurring meeting.
5. User B receives that meeting invitation.
I ran the experiment, with Google Calendar for creating the invitations
and Evolution and Exchange/OWA for accepting them.
The key question is: at step 3, is the meeting stored as a detached
recurrences, or whatever the corresponding Exchange semantic is?
No. Google did send an iCalendar 2.0 VEVENT with RECURRENCE-ID (as
expected), but then Exchange stored it like any other event.
If it is not, then how do Outlook/Exchange deal with the second
They overwrite the information received earlier, which is broken. In my
test, the first invitation was for a modified recurrence (different
summary, but meeting time could also have been different). That is the
information that Google still uses after step 4, as intended. But OWA
shows the information from the recurring parent event instead.
I would love to report that Evolution did it right, but it also failed.
It imported the first invitation okay (RECURRENCE-ID stored), but then
removes the detached recurrence when importing the parent.
So what do we do? Write it off as a corner case that no-one else handles
Right now detached recurrences without parent are simply not sent at
all. It would be fairly easy to turn a single detached recurrence into a
stand-alone event (like Exchange did in step 3), but then what is to be
done with any further detached recurrence sharing the same UID? Make
them exceptions of an event that doesn't recur? Hmm...
If the existing event is not marked as a detached
recurrence, then the invitation looks like an update, which should
overwrite the old data instead of adding the parent event to it.
And indeed, this is what happens... oh how I hate it to be right.
It depends a bit on what kind of meeting invitations are sent: is it
for the parent, or one for parent and all detached recurrences?
The one in step 4 only includes the parent, which IMHO makes sense,
because it avoids triggering the meeting import/acceptance process anew
for something which was already dealt with earlier.
Best Regards, Patrick Ohly
The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.