[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: RECURRENCE-ID discussion
On a related note, is there a part of the RFC that states that the
SEQUENCE number should always be incremented by 1? The RFC's talk of
incrementing, but as far as I can tell, the increments can vary.
If sequence number increments are not always 1, will the changing
RECURRENCE-ID model work?
-----Original Message-----
From: Michael Fair [mailto:michael@xxxxxxxxxxxxxxx]
Sent: Tuesday, August 12, 2003 4:02 PM
To: ietf-calendar@xxxxxxx
Subject: Re: RECURRENCE-ID discussion
> Michael Fair wrote:
> > I don't know what this hangup on modification
> > versus new object is about?
>
>
> That idea does not work for all cases.
Assuming that we are still talking about Z-1 being
a recurring event and Z is an instance modify then
it does work. It works very well.
I am so far the only one on this list who has potentially
shown a sequence of messages that _might_ cause an
inconsistency using the fixed-id model because there is
one circumstance under which the RECURRENCE-ID _might_ change.
And in fact, it happens to be the same sequence of messages
that causes the 'current-value' model to fall apart.
> Your CUA will be out of SYNC with the organizer view
> if iMIP objects that are sent as updates are interpreted
> as new objects - when received out of order via iMIP.
Why would it be out of sync?
The Z message is totally and completely a self contained
update with all information from the <Z message in regards
to that instance.
> You can pretend that out of order objects will not
> happen via iMIP all you want. It is not true.
It's good that we can agree on this. Forever more neither
one of us has to prove that messages can arrive out of order,
it can just be accepted that they might.
Further, all of us will have to defend what our respective
models do when it receives messages out of order.
> Servers queue up outgoing email all of the time
> and for reasons of system load can send them out in an
> order that is random. Your CUA will call it a new
> item then ignore the SEQUENCE:x-1 object because
> it thinks it is older.
The fixed-id model doesn't ever need to see the SEQ:x-1
object to know that it has the latest version of the instance.
I think you believe that if X was recurrence instance modify,
and X-1 was a recurring event definition, that we would ignore
X-1 and that would be bad.
And if the fixed-id model did ignore it, you would be right,
it would be bad.
But it doesn't ignore it so you just misunderstand the model.
If we receive an instance update with UID:1/RID:1/SEQ:1 we
will put it on the caledar as a recurring event instance
with the primary key UID:1/RID:1.
If afterward we recieve a full blown recurring event
UID:1/SEQ:0 we will not ignore it because we haven't
seen a message for event UID:1/RID:NULL before.
We will process this new event message and add every instance
that we have not already seen (i.e. we will skip UID:1/RID:1
because we already have that object at a SEQ > 0).
The easiest way for you to think about this is using SQL.
An event in the iTIP model has a primary key of:
UID: NOT NULL UNIQUE
RECURRENCE-ID: DEFAULT VALUE NULL
events primary key (UID, RECURRENCE-ID);
Note that in this definition RECURRENCE-ID could be NULL
and is NULL unless otherwise specified.
So in the iTIP model all events that do not have a
RECURRENCE-ID in them effectively have a RECURRENCE-ID
of NULL.
So when we recieve the first for message UID:1/RID:1 we look
in our calendar and don't find one. We process it as a
new event and put that instance on the calendar using the
primary key UID:1/RID:1.
Then when we later receive a message for UID:1/RID:NULL
we look in our table and again don't find one. We process
it as a new event and now put the entire series on our
calendar. When we process the UID:1/RID:null series,
we don't clobber the UID:1/RID:1 we have as that would
be stupid. UID:1/RID:1 is at SEQ:1 whereas UID:1/RID:NULL
is at SEQ:0. As such, our SEQ:1 version of UID:1/RID:1
trumps UID:1/RID:NULL's implied SEQ:0 version of the
same event. Same goes for DTSTAMP in case the SEQUENCE
values happen to match.
This is all very clear from reading 2.1.5.
-- Michael --