Subject: RE: RECURRENCE-ID discussion

From: Satya Vempati <[email-masked]>
Date: Tue, 12 Aug 2003 17:49:34 -0700

From Merriam-Webster:
Monotonically:

2 : having the property either of never increasing or of never decreasing
as the values of the independent variable or the subscripts of the terms
increase <monotonic functions> <a monotonic sequence>

I read this to mean that the SEQUENCE number will never decrease.

But, in that case, the changing RECURRENCE-ID model will send the REFRESH
for EVERY updated component.

-----Original Message-----
From: Michael Fair [mailto:[email-masked]]
Sent: Tuesday, August 12, 2003 5:25 PM
To: [email-masked]
Subject: 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?

There is nothing iTIP that says it.
And since messages can get lost there's no gaurantee that you
will see monotonic increments anyway.  So both models need
to handle that case.

But there is this from iCal (2445):

4.8.7.4 Sequence Number

   Property Name: SEQUENCE

   ...  It is monotonically incremented
   by the "Organizer's" CUA each time the "Organizer" makes a
   significant revision to the calendar component. ...

> If sequence number increments are not always 1, will the changing
> RECURRENCE-ID model work?

Well it will be no more broken than it already is...

Not monotonically incrementing the SEQUENCE will simply
make recipient CUAs think they missed something and in
either model send a REFRESH.

Since there really wasn't any actual missed data just
a bad SEQUENCE jump the REFRESH is mostly a non-op.

-- Michael --

> -----Original Message-----
> From: Michael Fair [mailto:[email-masked]]
> Sent: Tuesday, August 12, 2003 4:02 PM
> To: [email-masked]
> 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 --
>
>
>
>
>

---

From: Doug Royer <[email-masked]>
Date: Tue, 12 Aug 2003 19:15:46 -0600

> I read this to mean that the SEQUENCE number will never decrease.

It will never decrease. Which is why the Bruce new model of inviting
a new attendee to a single instance will not work under some circumstances.
If you get an old SEQUENCE you discard it because iTIP declares it
obsolete. So an original invite of SEQUENCE:x will be discarded if
an update to that instance (SEQUENCE:x+1) is interpreted as the
original invitation. The CUA will never know it needs to REFRESH.

> for EVERY updated component.

No and that is shown in iTIP. You can send an entire new object in
which case it has the NEW sequence number that is 1 larger. Or you
can send an update with a NEW sequence number that is 1 larger. Both
will have the same sequence number which will be newer than the attendee
has.  If it is an update (For those of us that use the iTIP
and not the Bruces model to invite) and the attendee does not have
that UID, then the CUA will know to do a REFRESH as it has missed
the original (or wait for it).

-- 

  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: Tue, 12 Aug 2003 19:02:45 -0700

> original invitation. The CUA will never know it needs to REFRESH.

In the fixed-id model it doesn't need the REFRESH.
Doug's insistence that it does merely points to his misunderstanding
of the model.

-- Michael --

---

From: Doug Royer <[email-masked]>
Date: Tue, 12 Aug 2003 20:32:35 -0600

Michael Fair wrote:
>>a new attendee to a single instance will not work under some
> 
> circumstances.
> 

No. You keep ignoring the failure by declaring it will not happen.

--

---

From: "Michael Fair" <[email-masked]>
Date: Tue, 12 Aug 2003 21:33:02 -0700

"Satya Vempati" <[email-masked]> wrote in message
news:[email-masked]...
> I read this to mean that the SEQUENCE number will never decrease.

You might actually be right about this, I know that I, and
it appears that many others took this mean increases by 1.

-- Michael --