Subject: RE: RECURRENCE-ID discussion

From: Satya Vempati <[email-masked]>
Date: Tue, 12 Aug 2003 18:03:41 -0700

Why do you need to send a REFRESH in the fixed recurrence-id model? If
your last SEQUENCE was 2 and the current SEQUENCE is 4 why can't you
merely update the 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:19:57 -0600

> merely update the component?

I can't speak for Bruces model, for iTIP:

If the object is a an iTIP (4.2.3) update, then it is a replacement
for the object. No. you do not need to do a REFRESH.

If the object is a an iTIP (4.4.2) update, then yes you have to
do a REFRESH because you do not have the details to know what to
update.

-- 

  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 18:59:36 -0700

> If the object is a an iTIP (4.2.3) update
> If the object is a an iTIP (4.4.2) update

Nothing can ever be a section 4 anything.
Doug just doesn't want to admit that section 3 is way more
important and supercedes anything in 4.  In fact, we would
no that there was an error in one of the examples because
it didn't do what the above sections said.

Section 4 is just examples of how to apply the above sections.
It does not a definition of how to determine what a message is.

Doug's idea is so broken that if we listened to him all of the
following would an update as well:

     .  Invite "Attendees" to an event;
     .  Response to a REFRESH request;
     .  Reconfirm an existing event, without rescheduling it;
     .  Forward a "VEVENT" to another uninvited CU.
     .  For an existing "VEVENT" calendar component, delegate the role of
        "Attendee" to another CU;
     .  For an existing "VEVENT" calendar component, changing the role of
        "Organizer" to another CU.

They would all have be updates because they all look
like what's in Section 4.

The truth is that if it's the first time a CUA has seen
any of the above it's perfectly safe to treat them as a
request for new event.

-- Michael --

---

From: "Michael Fair" <[email-masked]>
Date: Tue, 12 Aug 2003 19:17:11 -0700

> merely update the component?

You can and you do.
The instance is totally consistent with itself and fully updated.

But you know that you missed a message which _might_ have had to
do with the parent series description.

For instance imagine the case:
UID:1
RID:1
SEQ:2

then (redefine the whole series):
UID:1
SEQ:3

then (update the instance again):
UID:1
RID:1
SEQ:4

SEQ:4 will absolutely be the most recent version of RID:1.

But the thing in the middle that you missed was a
redefinition of the entire recurring series.

It's because of this possibility that the aggressively
consistent CUA will use the >1 SEQUENCE jump to request
a REFRESH for the UID:1/RID:NULL event.

It does not request a REFRESH for the UID:1/RID:1 event
because it already knows about that.

You are however absolutely right, and if you know that
it's likely SEQ numbers will jump like that then you might
define different semantics.  I personally suggest semantics
where the CUA only sends a REFRESH if it receives information
for a new instance of an event for which it has no RID:NULL
event entry.  So if you are invited to two distinct instances,
but not the whole series, you will have sent only two REFRESH
requests regardless of how many updates occured.
One for each of the first times you saw a new RID.

You can also look at section 6.1.7 which talks about this.

-- Michael --

---

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

> Nothing can ever be a section 4 anything.

Your joking right? Your saying that all of section 4
was submitted in error and only a hand full of people
since November of 1988 have noticed that 122 pages
of 2446 are 'nothing'.

--

---

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

"Doug Royer" <[email-masked]> wrote in message
news:[email-masked]...
> since November of 1988 have noticed that 122 pages

No, I'm saying that nothing in section 4 is necessary
and it does not add any definition to the text.

Section 4 merely aids understanding of the above sections
but in as much as iTIP describes a way of doing things
it is superfluous and is there merely to aid in
comprehension of the above text as an example.

For example, if I say the color of the sky is determined
by looking up when your view of the sky is unobstructed.
And I then say "Section 4: Examples"
To updates someone's understanding of color of the sky
to be blue send:
Sky: blue

I am not saying that every message that contains the
text "Sky: blue" is telling them it is an update the
color of their Sky.  I'm simply saying that if and
when you send an update, that's what it looks like.

BTW, all text after the words "For example," in this
message are totally superfluous and are merely meant
to enhance the reader's comprehension of the above text.

-- Michael --