Subject: New question in regards to the fixed-id model

From: "Michael Fair" <[email-masked]>
Date: Wed, 13 Aug 2003 16:22:41 -0700

In spirit of coming up with what the new text should
unambiguously say and not having this answered for
myself yet, I have a question about how rescheduling
an entire series of events impacts individual instances
that may have been previously renegotiated.

The scenario goes something like this:

I send an invite to a bunch of people:
UID:1
SEQ:0
RRULE/RDATE:Every Friday this year.

I then move Friday, June 13th, to Thursday, June 12th.
UID:1
RID:June 13th
SEQ:1
DTSTART:June 12th

I then decide to move the entire series to Monday.
Since the SEQUENCE of the largest instance in the
series is now 1, the next highest value to use for
the new SEQUENCE is now 2.  This forumla was given
to me offline from the list and I can find no real
text in iTIP supporting it, but I agree it is what
is necessary for the desired outcome.

So I send:
UID:1
SEQ:2
RRULE/RDATE:Every Monday this year.

So now what to do about that Thursday meeting.
The SEQUENCE of the rescheduled parent event being
at 2 clearly indicates that it supercedes the
renegotiation of the instance at 1.

Further, the RECURRENCE-ID list described by the
set no longer includes June 13th.

iCal says that RECURRENCE-IDs are only fixed for
a given UID/SEQ pair.  Since that pair has now
changed it is valid for the RECURRENCE-ID of the
instance in question to change.  Unless I am
misapplying that text.

At this point I feel it reasonable to say that the
CUA should just cancel the offended out of date
instance and assume that the message it just received
is the complete latest description.  If the CUA
wanted to maintain the Thursday rather than Monday
occurence, then along with the reschedule to Monday
it must include a per-instance update to the now
Monday RECURRENCE-ID.

This however poses a problem in the case that an
individual CU has been invited to that one and
only instance because they would never have seen
the master recurring event nor its reschedule.

Therefore to maintain consistency it must send two
messages one with a CANCEL of the old RECURRENCE-ID
and another with the new RECURRENCE-ID of Monday.

If the recipient's CUA should miss the CANCEL message
it will end up with two instances on its calendar.
The original as yet uncancelled instance RID:Friday,
and the new RID:Monday instance.

Save for the CUA receiving the CANCEL message which
I can't see any way of resending I see no way to get
the recipient's calendar back into sync since they
aren't invited to the base recurring event and shouldn't
ever receive it.

To attempt to answer my own question, there is an
example in 4.7.2 Bad RECURRENCE-ID which might resolve
the dilemma, but it's format is only in 4.7.2 and in
no other example dealing with recurring instances.

The example shows an event that has both RECURRENCE-ID
and RRULE/RDATE properties.  This is the only time I
have ever seen that used.

If we define that when inviting an individual CU to a
particular instance, the ORGANIZER's CUA MUST include
both the RECURRENCE-ID of the instance AND the RRULE(s)
and/or RDATE(s) (with any EX counterparts) then this
whole situation can be avoided.

In this case, when the recipient's CUA receives the
new description with the now Monday RECURRENCE-ID
it can use the RRULE/RDATE/EXRULE/EXDATE information
to find out if the set still includes the other instances
that it has on its calendar.

Since the SEQUENCE of the new instance will be greater
and the set will no longer describe the original RID
then the CUA will no that the instance in question no
longer exists and can remove it.  It is the ORGANIZER
CUA's responsibility to ensure that any and all instance
information it wants copied from the old instances be
included in the new updates.

The act of updating the SEQUENCE value on the
UID/RID:NULL object, implicitly cancels any and all
instances whose RECURRENCE-ID no longer exists in
the new series.

Any thoughts?  Or is there something out there I am
just misinterpreting/not taking into account?
How do other implementations already handle this?

-- Michael --

---

From: "Chris Olds" <[email-masked]>
Date: Wed, 13 Aug 2003 17:21:15 -0700

On Wed, 13 Aug 2003 16:22:41 -0700, Michael Fair wrote
> is necessary for the desired outcome.

SEQ is for the whole set, not per-instance.  Since you changed an instance
(and changing a member of a set changes the set), 2 is the correct value.

> So now what to do about that Thursday meeting.

All you need to do is add another date, specifying Thursday.  If it replaces a
meeting from the RRULE/RDATE set, then use EXRULE/EXDATE.  If it is in
addition use RDATE

> instance in question to change.  Unless I am

Nope, that's exactly how I read it, and how I understand Doug to be reading
it.  Welcome to the 'current-value' camp!

> it must include a per-instance update to the now

Sure, although a simple EXDATE would be enough, no RECURRENCE-ID messing about
needed.

> the master recurring event nor its reschedule.

No problem at all.

Nothing says that every Attendee must (or even should) see the same event as
the Organizer.  There are many reasons that an Organizer might want to present
different versions of the event object to different users (or classes of
users), and since the Organizer is the only arbiter of what constitutes 'the
same event' (for purposes of unambiguous UID assignment), this all works out
just fine.

> and another with the new RECURRENCE-ID of Monday.

Not needed.  The old RECURRENCE-ID message was sent with SEQ:1, and the new
(complete) VEVENT was sent with SEQ:2, so any instances a CUA might find in
it's calendar that don't match any instance in the new set should be removed
anyway.  The exception can be included in the complete event definition.  If
only one attendee was rescheduled from Friday (now Monday) to Tuesday, just
send them an exception with SEQ:2, RECURRENCE-ID:Monday and that's it.
[ My reasoning for leaving the SEQ at 2 is that the change was initially made
before the reschedule of the event set, so the execption, whether general or
individual, was present before the change to the set.  If these messages
arrive out-of order, the CUA will request a REFRESH (to get the complete set),
and use either the VEVENT sent to everyone or the sepecific response
(whichever arrives first).  Since all of these have the same SEQ (and likely
the same DTSTAMP), they all have equal priority and should be considered
together, which gives the correct result. ]

> and the new RID:Monday instance.

No.  Getting the complete SEQ:2 event means you have all of the scheduled
instances for that UID, and so all the Friday instances get deleted.

> aren't invited to the base recurring event and shouldn't

Each Attendee MAY have a different view of the event.  If the Organizer knew
how to send the original version, they know how to send an update.  Again,
SEQ:2 makes _all_ SEQ:1 data out of date.

> included in the new updates.

Yes.  The examples make this clear.

> How do other implementations already handle this?

Thank you for this clear description of the 'current-value' model, and why it
is simpler and less error-prone.  I snipped some text describing problems that
occur if one uses the 'fixed' model, but that doesn't mean I think they're
unimportant, it just means that I want to point out that they don't occur in
the 'current-value' model.

    /cco

--
GPG Key Fingerprint: B375 A4E7 752B DB8C 4359  852E C3CF BF64 379A E9B2
Debian Project (http://www.debian.org)

---

From: "Michael Fair" <[email-masked]>
Date: Wed, 13 Aug 2003 19:06:02 -0700

Thanks for responding.

I should first say that I haven't switched camps. I'm just
trying to make sense of the text as it is written.  It was
this same logic that I used to figure out that sentence in
iTIP that says that RID ends up at its new value is an error.

However, it's highly unlikely, though it is not impossible,
that I would ever accept the current-value model as it
performs so horridly in the presence of missed messages and
iTIP on so many occasions and with good reason expects
that messages regularly will be received out of order.

iTIP and iCal (as evidenced by this whole discussion)
is not the clear document we'd all hope it to be.
Just to show you how confusing this all can get here's
another iTIP fragment from section 3.7.1 Working with
recurring instances:

   An instance of a recurring event is assigned a unique
   identification,"RECURRENCE-ID" property, when that
   instance is renegotiated.

No one I've seen on either thread here has ever come up a
clear interpretation of that text.  It could imply that
it didn't have a uique RID prior to being renegotiated,
or it could mean that when taken with another iTIP
possibility that RID's not even be dates at all if
DTSTART doesn't describe a calendar time that it gets
assigned at the time of renegotiation.  But it never
says to what, other than to say it is unique.  It's
just a bizarre piece of text (I was going to ask about
it later but it came up).

I mean I could actually read it to mean that iCal uses a
'current-value' model up until that instance is
renegotiated and it is then fixed from then on forever
more until it or the entire series is canceled, but that
causes it's own problems.

Or I can say that iCal's UID/SEQ pair statement is the
most meaningful and if using a 'current-value' this whole
statement is pretty much a noop as once the SEQ changes
it could possibly invalidate the RID anyway.

Or I can say that it uses a 'current-value' model until
an instance is renegotiated and then as per iCal's
UID/SEQ pair statement it is fixed until the set is
redefined and what I end up with is exactly the
'fixed-id' model we've discussing.

Anyway on to the real discussion.

<a lot of text using a 'current-value' model snipped>

> Nothing says that every Attendee must (or even should)
> see the same event as the Organizer.

Actually at least two things do.

One is the definition of UID which says that it is globally unique.
Once you do this you have just created two events with the same
UID that describe different sets and have therefore violated
global uniqueness of the UID.

Second is an implementation issue.
Since I don't know what the answer is, I'll pose the situation
and just ask you to tell me how the CUA's resolve it.

User A and User B get invited to two separate instances 1 and 2
respectively.  So now you have three versions of the UID, one
for A, one for B, and the original.
Both A and B decide the other one should have been invited to
their respective instances and forward the event to each other.

So both A and B now receive a message describing the same UID,
the same SEQ, but different DTSTART.  Assuming we did as you
suggested they would actaully have two singleton's without
so near a mention of a recurring instance, and the ORGANIZER
would assume that any replies from either of them were in
respect to the respective singleton's it sent them.

So first, what will A and B's respective CUAs do when then
receive the forwarded messages (for example purposes let's
say that A was invited before B and therefore the DTSTAMP
for B's event is greater)?

And second, assuming you somehow get the CUA's to sort out
the mess how will the ORGANIZER interpret their REPLY?

Please cite iTIP when saying how the respective CUAs make
their decisions.

> Not needed.  The old RECURRENCE-ID message was sent with SEQ:1,
> and the new (complete) VEVENT was sent with SEQ:2,

You are assuming that every object that refers to an instance
always contains a description of the entire set which is false.

In fact, only one example in all of iTIP even uses the
possibility that a VEVENT might ever do this.  I can't tell
if it's a mistake (for instance look closely at the RDATE field),
an oversight, or what.  The example is even internally not
consistent with itself as the RECURRENCE-ID used is clearly
not one of the set defined by the RRULE/RDATE shown.
(This is example is in 4.7.2 at the REQUEST from A)

In the case of the individual CU invited to one individual
instance, it's perfectly valid for them to never have seen
the entire event set (lest we use the fragmented/branching
UID method you described which I will only begin to consider
after you get get over the two reasons against it above).

In fact, my recommended solution was to exactly gaurantee
that this assumption could be true.  To define that the update
to the now Monday RID contains a description of the set.
This further implies that the previous instance also
described the recurrence set - this may or may not be a
desirable leak of extra information.

And by inclusion of the set, as you say, the CUA can
figure it out from there.

<Argument that again assumed the CU saw the entire series snipped>

<Argument to fragment/branch the UID snipped>

> Thank you for this clear description of the 'current-value'
> model, and why it is simpler and less error-prone.  I snipped
> some text describing problems that occur if one uses the 'fixed'
> model, but that doesn't mean I think they're unimportant, it
> just means that I want to point out that they don't occur in

No problem, I've tried very hard to completely understand what
the propenents of the 'current-value' model say it should do
so that I am arguing the right assumptions.  As you can see
it was also part of the inspiration for one of my proposals
for recovery.  However that proposal is still very error prone
in the presence of missed messages.  Not coincidently just
like the 'current-value' model.

That proposal also reveals information that may or may not
be desirable to reveal - what the recurrence set for the
whole series actually is...  It's still a work in progress
as far as I'm concerned and the final outcome may be
very different.

I mean one of my solutions is to introduce a new property,
the presence of which means that when the recurrence update
is finished, the recurrence-id has now changed, and if not
present means the recurrence-id remains what it was.
This is actually my favorite proposal but I hesitate to
suggest it in case I'm actually missing a solution that
is actually in the text.

-- Michael --

---

From: Doug Royer <[email-masked]>
Date: Wed, 13 Aug 2003 21:00:13 -0600

> that may have been previously renegotiated.

I am still confused as to why anyone would want to make
it that complicated as you had below. Why not just send a new entire
object to the effected attendees?

-- 

  Doug Royer                     |   http://INET-Consulting.com
  -------------------------------|-----------------------------
  [email-masked]                 | Office: (208)612-INET
  http://Royer.com/People/Doug   |    Fax: (866)594-8574
                                 |   Cell: (208)520-4044

                 We Do Standards - You Need Standards

---

From: "Michael Fair" <[email-masked]>
Date: Thu, 14 Aug 2003 16:08:33 -0700

> [[ NB: text with > > preceeding is me again, and Michael is > > >  /cco ]]
>
> On Wed, 13 Aug 2003 19:06:02 -0700, Michael Fair wrote
> >
> I don't understand this statement.  If a message w/o a RID is
> recieved out of order, the older message is discarded when it
> arrives, based on both SEQ and DTSTAMP values.

You are assuming that the older message is actually stale
information and not valid info dealing with a separate
instance or the recurring series itself.

Besides, the practice of holding REQUEST messages as you and
Doug purport is actually a violation of iTIP section 3.2.2.
But given that the 'current-value' model totally breaks down
if we do that and I'm interested in the best performing model
possible, I'm going to assume that it holds out of sequence
messages for later application (if and only if still valid).

Let's send four messages to arrive in reverse order:
1)
fixed-id and current-value:
UID:1
SEQ:0
RDATE: Jan-1
RDATE: Jan-2
RDATE: Jan-3
RDATE: Jan-4

2)
fixed-id and current-value:
UID:1
RID:Jan-1
SEQ:1
DTSTART:Jan-5

3)
UID:1
RID:Jan-2
SEQ:1 <- fixed-id
SEQ:2 <- current-value
DTSTART:Jan-6

4)
UID:1
RID:Jan-3
SEQ:1 <- fixed-id
SEQ:3 <- current-value
DTSTART:Jan-7

Receive Message 4:
fixed-id - treat it as a new invite and put it on the calendar
           send a REPLY and REFRESH - it'd be nice if the REFRESH
           and the corresponding REQUEST made it through the system.

current-value - send a REFRESH wait for a reply and rely on the
                hope that neither of the two messages get lost
                in transit

Receive Message 3:
fixed-id - treat it as a new invite and put it on the calendar
           send a REPLY and REFRESH - it'd be nice if the REFRESH
           and the corresponding REQUEST made it through the system.

current-value - send a REFRESH wait for a reply and rely on the
                hope that neither of the two messages get lost
                in transit

Receive Message 2:
fixed-id - treat it as a new invite and put it on the calendar
           send a REPLY and REFRESH - it'd be nice if the REFRESH
           and the corresponding REQUEST made it through the system.

current-value - send a REFRESH wait for a reply and rely on the
                hope that neither of the two messages get lost
                in transit

So looks at the scoreboard shall we:
Fixed-id:
Messages Received: 3
Messages Processed: 3
Accurate Events Scheduled: 3

Current-Value:
Messages Received: 3
Messages Processed: 0
Accurate Events Scheduled: 0

And finally:
Receive Message 1:
fixed-id - Treat it as a new invite and put it on the calendar.
           Add the Jan-4 instance we didn't know about.  Ignore
           the Jan-1, Jan-2, Jan-3 dates because the calednar
           already has more recent information.
           send a REPLY for the event which implicitly applies
           to the Jan-4 instance but will not override the
           answers for Jan-5,6,7.

current-value - Treat it as a new invite and put it on the
                calendar.  Add the Jan-1,2,3,4 instances.
                Reprocess our holding queue applying the
                updates we can.  Let's assume optimal
                implementation where each UID has it's own
                priority queue for holding unprocessable
                messages so it can just apply 2,3,4 in order
                and rather easily.
                Send a REPLY for the whole series and any
                additional REPLY for different status info
                per instance.

So now let's look at the scoreboard:
Fixed-id:
Messages Received: 4
Messages Processed: 4
Accurate Events Scheduled: 4

Current-Value:
Messages Received: 4
Messages Processed: 4
Accurate Events Scheduled: 4

So the good news is that after receiving all the messages they
are both completely, accurate and totally up-to-date.
The bad news is that the current-value model couldn't do a thing
until it received the description of the recurring series in
message 1.  Had message 1 been lost current-value would have been
stuck waiting for a REFRESH response to show up.  I don't like
models that can't process received messages because there is
other data that had come before it.

Let's take this example a bit further.

Three more messages again received in reverse order:
1)
fixed-id:
UID:1
RID:Jan-1
SEQ:2
DTSTART:Jan-8

current-value:
UID:1
RID:Jan-5
SEQ:4
DTSTART:Jan-8

2)
fixed-id:
UID:1
RID:Jan-1
SEQ:3
DTSTART:Jan-9

current-value:
UID:1
RID:Jan-8
SEQ:5
DTSTART:Jan-9

3)
fixed-id:
UID:1
RID:Jan-1
SEQ:4
DTSTART:Jan-10

current-value:
UID:1
RID:Jan-9
SEQ:6
DTSTART:Jan-10

Receive message 3:
fixed-id: Update The Jan-1 instance (currently at Jan-5) to Jan-10.
          Send an attendence status REPLY.  Since the sequence jumped
          more than 1 send a REFRESH - it'd be nice if the messages
          made it through the transport system.

current-value:  Stick the message on the UID priority queue, send
                a REFRESH, and wait for more info.

Receive message 2:
fixed-id: Throw it out it's old news.

current-value:  Stick the message on the UID priority queue, send
                a REFRESH, and wait for more info.

So now let's look at the scoreboard:
Fixed-id:
Messages Received: 2
Messages Processed: 2
Accurate Events Scheduled: 2 (counting the ignore as accurate)

Current-Value:
Messages Received: 2
Messages Processed: 0
Accurate Events Scheduled: 0

Receive message 1:
fixed-id: Throw it out it's old news.
current-value:  Apply SEQ:4 move Jan-1 to Jan-8
                Apply SEQ:5 move Jan-8 to Jan-9
                Apply SEQ:6 move Jan-9 to Jan-10

So now let's look at the scoreboard:
Fixed-id:
Messages Received: 3
Messages Processed: 3
Accurate Events Scheduled: 3 (counting the ignores as accurate)

Current-Value:
Messages Received: 3
Messages Processed: 3
Accurate Events Scheduled: 3

Please inform me if I have in some way misrepresented the
'current-value' model.

Given the two examples above what becomes obvious is the
current-value model's reliance on what I'm going to call
a "trigger message"  it's a particular message, be it the
original missed message or the response to a REFRESH that
allows for or obsoletes the need for processing of all
other messages.  This reliance on the trigger mssage is
why I say the current-value model is not overly fault
tolerant in the presence of missed messages.

The fixed-id model can immediately always apply to the most
up to date information for whatever data the message happens
to contain - it can then immediately throw it out and move on.

That is the real advantage to the model.

> As I see it, this is as tight as one can get an still be assured
> of having a sensible view of the event (yes, it is possible
> to still be out of synch, but that reqires missed messages,
> and I think we agree that they are unavoidable and both
> models have to live with it).

Yes, both absolutely must live with missed messages.
No, the fixed-id model is tighter - see above.

< Snip discussion regarding iTIP/iCal not being totally
  consistent in all areas with respect to a paragraph.
[
  If any things the part I snipped was really valuable
  please bring it back up - it looked like it was going
  to be an I say it's this - you say it's that - and only
  a decision on the underlying model will say which it was.
]
  However leave the following germane portion. >

> So close... fixed until the instance is rescheduled,
> either by the set being redefined or the instance being
> modifed by RID.

That's again just your interpretation based on that you
clearly believe 'current-value' is what iTIP describes.

I happen to interpret it differently and defensibly within
the context of iTIP.

> Fixed-id, as promoted by Bruce, is not what you describe
> here; it is fixed at SEQ:0 (or when the instance is first
> added to the set, but that has even more problems).

Then I should calrify to say that it's the model I've been
discussing which is slightly different from Bruce's and
someone around here is in error (and I'd be quicker to
say me over Bruce and you and Doug over me - we'll all
have our own orderings here ;) ).

I happen to disagree with Bruce on that point as I read
the text differently.  However assuming Bruce can explain
certain things to me about what happens during an entire
series reschedule and figuring out how to match up which
instances override which set members I'd probably accept
his model as it has the fewest messages and the most
accurate potential of any of the models.

> > global uniqueness of the UID.

< Snip example of a birthday party that always has the same
  UID/SEQ/DTSTAMP for all instances (exactly one since it was
  a singleton) as it is totally off topic from the description) >

> The organizer has no need to make any assumptions.  According to
> 3.2.3, the organizer is free to reject party crashers.

Please go through step by step about what A and B's CUAs will
do when they receive their respective forwarded messages.
At this point in this discussion as far as I'm concerned
the ORGANIZER  will have party crashers to reject because
A and B's CUA will be so confused as not even know how to
formulate a proper response- and if they do - the ORGANIZER
won't even process it becuase it's wires are crossed as it
won't even know how to match the REPLY to an event in
its calendar.

> Since the DTSTART/RRULE in the reply will indicate which
> instances A (or B) is responding to
Umm - no it won't because the ORGANIZER won't get that far.
Where does it ever say that a CUA should EVER look at the
DTSTART/RRULE when matching up a REPLY?

Secondly, you have still yet to address how A and B even
formulated a REPLY to begin with.  Again just step through
and describe the sequence of events to me and why iTIP says
that's how the CUA should handle it.

Call me stupid/ignorant/pigheaded or whatever you want.  Since
both you and Doug have refused to look at this issue I have
to lead you to it.  I tried to go through the steps using a
'current-value' model as you've described where you branch
a different recurring set for each ATTENDEE.  It doesn't
work in the presence of CU's passing messages around behind
the ORGANIZER's back which they can, will, and are absolutely
allowed to do.

> This is *exactly* the same process as if RIDs are used to
> find the correct instances; the organizer knows who is
> invited to what, and can check off acceptances against
> that list.

Actually it's not the same.  A and B were invited to different
instances (1 and 2 respectively) so when they invite each other
A receives an invite to 2 and B to 1 and the CUAs are happy
becuase the presence of an RID disambiguates the two events.
A and B both send an accept REPLY that includes the RID to
the ORGANIZER who then says "Oh 'A' would like to attend 2...
Hmm - ok I'll add them" and then "Oh 'B' would like to
attend 1... Hmmm - no I send them a CANCEL on RID 1".

All I'm asking for is the same scenario described using your
model.  You'll quickly find that in every single case A and B's
CUA MUST do the wrong thing if it follows section 2.1.5.

> They should be aware that the message was sent by someone other
> than the organizer, so if they respond to the organizer, they
> know they're trying to crash the party.

But what you're not thinking of is what iTIP fragments did they
receive from each other?  How did they figure out it didn't come
from the ORGANIZER from what was in the message?  What exact
iTIP message will they construct to send back to the ORGANIZER
and given the instances that the ORGANIZER thinks A and B are
associated with how will it interpret the new messages?

And most importantly, how does someone figure that out from
reading the processing rules of 2.1.5 and REPLY.

> As noted in the text, the fact that the RECURRENCE-ID is not in the
> recurrence set is an additional hint (additional to SEQ:3) that a
> REFRESH is needed.  The example is consistent, if you read the text.

Ok, so I looked at it, and looked at it, and looked at it again,
and tried to concoct some situation where that message in iTIP
would be valid.  Assuming there was just an extra 0 in the RDATE.

The text specificly states that the RID listed is not in the
set the recipient has on its calendar.  It doesn't say anything
about what the set was or is supposed to be...

So the only example I could come up with is that it is
an update to a recurring instance and a reccurence set
reschedule at the same time which actually isn't possible.

An RID must - given either model - be a member of the current
set described by an RRULE/RDATE.  I challenge you to some up
with a series of events in which the RRULE/RDATE listed does
not include the RID listed.

The example is inconsistent with itself except for in
(supposedly) Bruce's description of the fixed-id model
where the RECURRENCE-ID gets described at SEQ:0 and
regardless of set redefinition that instance ID is
fixed until either the instance, or the whole series
is cancelled.

> Have I done that?  I don't think of it as either fragmented or
> branching, but just the way things are as a result of the fact
> that it is _likely_ (IMHO) that *only* the Organizing CUA will
> EVER have the complete picture of an event.

This assumption about the CUA is patently false.  CUs will
forward stuff around behind the ORGANIZER's back and share
info with each other which must be consistent.

Again, this is EXACTLY what my forwarding around of invites
to specific instances is about.  Both you and Doug seem to
be overlooking the fact that CUs will forward things to each
other and that the messages that get forwarded in your model
MUST make the recipient of those messages do the wrong thing
because you have fragmented the UID.

A fragmentation/branching of the UID simply means that you
have more than one object with the same UID in your store.
The moment you create a singleton event with the same UID
as a recurring event to invite an individual CU to a
particular instance you now have two distinctly separate
objects identifiable by the same UID and it takes looking
at who the message came from to sort out which one the
message is referring which iTIP strictly tried to protect
against when it declared that each UID must be globally
unique (global includes even within the ORGANIZER's calendar).

< Rest of text snipped as it was either covered above,
  didn't appear to be very germane, or came from the
  singleton suprise party answer that very clearly did
  not address the issues I was proposing. >

-- Michael --