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

["Michael Fair" <michael@xxxxxxxxxxxxxxx>]

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>

> > 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.
>
> No problem at all.
>
> 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.


> > 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.
>
> 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>



> > Any thoughts?  Or is there something out there I am
> > just misinterpreting/not taking into account?
> > 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.

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 --