Subject: RE: Does anyone still think that RECURRENCE-ID's do NOT change?

From: Satya Vempati <[email-masked]>
Date: Wed, 27 Aug 2003 17:40:50 -0700

Surely, Doug & Chris also agree that the RECURRENCE-ID changes when the
base recurrence set changes. They may not agree that RECURRENCE-ID stays
put if an instance is changed. Well, after the post from the original
authors, I hoped that this issue would be laid to rest. But ...

The SEQUENCE numbering scheme I am talking about is the following issue:

Suppose the base set is UID:1, SEQ:0
We reschedule an instance: UID:1, RID:x, SEQ:1
We modify/reschedule the instance 49 times: UID:1, RID:x, SEQ:50 (attendee
A is invited to this instance alone)
Now we change the RRULE on the base set: Should it be: UID:1, SEQ:51 OR
UID:1, SEQ:1?

If the SEQ:0 changes to SEQ:51

All CUAs sees a jump from UID:1, SEQ:0 to UID:1, SEQ:51 and assume they
have missed some intermediate updates (and based on your earlier posts)
would do a REFRESH. I believe the iTIP spirit to use REFRESH only when the
CUA realizes that something has gone wrong and not as a routine part of
the workflow. I see such a frequent requirement for REFRESH as an issue.

If the SEQ:0 changes to SEQ:1, and you regenerate the instances, UID:1,
RID:x will have SEQ:0 and attendee A's CUA may discard the change.

Or it could even be UID:1, SEQ:1 and UID:1, RID:x, SEQ:51.

We need to settle on the following:
  1) what changes (RRULES/EXRULES etc.) constitute changing the base set? 
  2) what is the best way to assign sequence numbers (without creating a
REFRESH storm)?
  3) under what circumstances to discard all existing exceptions to a
recurring event (If a Monday meeting is changed to Monday, Wednesday
meeting, do we really need to lose the all the old instances and
associated exception data?)

My point is that we should focus on moving on to other issues and not flog
the dead horse ("Will recurrence-id change for an instance reschedule?")
for ever.

-----Original Message-----
From: Michael Fair [mailto:[email-masked]]
Sent: Wednesday, August 27, 2003 4:03 PM
To: [email-masked]
Subject: Re: Does anyone still think that RECURRENCE-ID's do NOT change?

I know that Doug won't see this, but for the sake of
just having another voice weigh in on the issue for
the archives here goes:

> > I think everyone agrees that the RECURRENCE-IDs change
> > when the recurrence
> > set is changed (e.g. a new RRULE/EXRULE). There should
> > be no change to the
> > RECURRENCE-ID if one instance gets rescheduled.
>
> False because there is NO way to reschedule one instance without bumping
> the SEQUENCE number. Thus the set changes. Thus the RECURRENCE-IDs
> always change on one OR all instance rescheduling changes.

False because Doug Royer and Chris Olds do not agree and they
are part of "everyone".

Otherwise, excluding those two people, this seems true.

The instances themselves have their own SEQUENCE which
is always equal or greater than that of the base recurring
event description itself.  This is what is meant when
iTIP says that each instances "may be both referenced
and versioned".

Each instance of a recurring event has a RECURRENCE-ID
that remains fixed for as long as the SEQEUNCE of the
base recurring event remains the same.  This is what
iCal means when it says "for each UID/SEQUENCE pair
the RECURRENCE-ID remains fixed".

As a consequence, the only time you impact the RECURRENCE-ID
set is when you change the recurrence rules.  This always
causes a SEQUENCE bump on the base recurring event.

Doug is a 2-bit fool who can't stand 1-bit of being wrong.
His model is flawed.  His model is not iCal nor iTIP.
His model cannot be implemented sanely given iTIP's goals.
He puts you on his ignore list when you press him to prove
anything to the contrary - especially on the implementation side.

The SEQUENCE for the entire set does not bump whenever you
reschedule an instance and only two people I know of try to
do it this way, one is Doug Royer and the other is Chris Olds.

> > The next interesting challenge is to find a scheme for updating
SEQUENCE
> > numbers on the master and exception events while conforming to iTIP.

This doesn't make any sense to me.  The only time you want to bump
the SEQUENCE value is when you've changed something that invalidates
the ATTENDENCE status of an ATTENDEE.  iTIP defines how to do this
for an entire recurring series, or for instances quite plainly.

When you bump the SEQUENCE on the base event it's as if you are telling
the recipient CUAs to completely throw out any of the existing data
they have for that event and you are providing all new data.  Both
the base event and all isntances are updated to the new SEQUENCE.

If you wanted to also keep any instance reschedules in tact, you
would simply send objects with a SEQUENCE larger than that of the
base object and include that in the update as well.

If the base was SEQ:1 and if the largest instance was at SEQ:5
then the reschedule of the base event would be SEQ:6.  This
would gaurantee that it will override any other prior instance
modifications.

If you simply wanted to attach more - non SEQUENCE affecting data -
to the base event or instances, no SEQUENCE bump is required and
iTIP clearly spells out how to do this too.

This is all totally valid within iTIP already.
I don't see the interesting challenge.

-- Michael --

---

From: "Michael Fair" <[email-masked]>
Date: Wed, 27 Aug 2003 19:44:29 -0700

> authors, I hoped that this issue would be laid to rest. But ...

So did I, and as you say, but ...
 
...
> If the SEQ:0 changes to SEQ:51
...

If a CUA has any local instance that has SEQ:50, and the base 
increases to 51, then it can assume that it has seen everything.

If however, the base nor any instance is at 50, and it receives a
base at 51, then it actually has missed something (assuming the 
value has always increased by 1).

As for the "massive REFRESH requirement" you spoke of, the difference
between this model and the 'current-value' model is that for this case
and in this model it doesn't matter if the REFRESH actually makes it 
to the ORGANIZER and back.  The CUA already has the latest info and
adds it to the calendar without waiting for the REFRESH response.

Also, anyone who did not have an instance at 50, and was not invited 
to the base event will receive instance updates with SEQUENCE jump >1.
This may or may not cause a REFRESH depending on how paranoid the
programmer was.  The CUA would have already sent one REFRESH at the
time it received the first instance REQUEST.  It may consider that
request sufficient and not send another one.  In that case, it would
not send another REFRESH as it would just apply the latest copy of
the instance it knows about to the calendar.

However, it might also take the opportunity to send a REFRESH in case
it missed an update to the base object (which it actually didn't).
When dealing with recurring events and missed messages REFRESHes are
unavoidable, however as you saw above, if a CUA has indeed seen every
message, then it can detect that and not request the REFRESH.
The only exception to this is when a CU is only being invited to
individual instances.  But that's being addressed in other threads.

-- Michael --
 
-- Michael --

---

From: Doug Royer <[email-masked]>
Date: Thu, 28 Aug 2003 10:21:56 -0600

> authors, I hoped that this issue would be laid to rest. But ...

They clearly said it changes when the pattern changes.
Do you disagree that it changes when the pattern changes?

-- 

  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: Doug Royer <[email-masked]>
Date: Thu, 28 Aug 2003 10:56:06 -0600

> Now we change the RRULE on the base set: Should it be: UID:1, SEQ:51 OR

iTIP says that when you send an instance update you increment
the SEQUENCE number each time. Do you disagree?

--

---

From: "Michael Fair" <[email-masked]>
Date: Thu, 28 Aug 2003 10:02:18 -0700

Doh!

I'm totally wrong about the CUAs needing to know if they missed
something.  I got distracted by all the talk prior about instances
and realized that this is actually in reference to the base event.

Since this is about the base event and not an instance, SEQUENCE
jumps don't matter as the most recent information is always the
most up to date.  It's only when the CUA receives information
about an instance which indicates that it might have missed
something about the base event that it sends a REFRESH..

...
> If the SEQ:0 changes to SEQ:51

Then the CUA updates to 51, uses the info contained
within and goes on its merry way regardless of what other
prior SEQUENCE numbers it may or may not have seen.
No REFRESH is needed at all because it has seen the latest
and greatest info.

-- Michael --

---

From: [email-masked]
Date: Thu, 28 Aug 2003 13:32:31 -0400

There is nothing saying that invitee can not get SEQUENCE 20 and than 
SEQUENCE 30.
If chair reschedules several instances their individual SEQUENCE number 
will bump (NOT THE WHOLE SET).
If chair than reschedules over a range, the new sequence number for 
reschedule will be one greater than the highest sequence number on 
instances within range before reschedule.
_____________________
Note: new email address

[email-masked]

Doug Royer <[email-masked]> 
Sent by: [email-masked]
08/28/2003 12:56 PM
Please respond to
"[email-masked]" <[email-masked]>

To
"[email-masked]" <[email-masked]>
cc

Subject
Re: Does anyone still think that RECURRENCE-ID's do NOT change?

--

---

From: Doug Royer <[email-masked]>
Date: Thu, 28 Aug 2003 12:42:56 -0600

> There is nothing saying that invitee can not get SEQUENCE 20 and than 

I agree.

> will bump (NOT THE WHOLE SET).

What do you mean by 'THE WHOLE SET' ? What will the ORGANIZERs
SEQUENCE number be? If you are saying that not all ATTENDEEs
need see all updates - we agree. If not, I did not understand
your point.

> instances within range before reschedule.

In the iTIP packet sent to the effected ATTENDEEs, assuming they
were at newest-sequence-1, else as you point out above if
they were last at '20' and you send '30' then it will not be
'1' off, it will be '10' off. So then there set changes to
the set they were sent in sequence '30'. Correct? So in all
cases the RECURRECE-ID set changes for the effected ATTENDEES.
And as the ORGANIZER had to bump the sequence number because
they made one or more instance updates, the ORGANIZER set changes. Thus
the pattern changes, thus the RECURRECE-IDs change in all cases for
the ORGANIZER and all effected ATTENDEEs.

--

---

From: [email-masked]
Date: Thu, 28 Aug 2003 15:41:54 -0400

THIS IS BOGUS AND YOU KNOW IT.
As per Derik Stenerson reponse changes to instances do not change pattern.
_____________________
Note: new email address

08/28/2003 02:42 PM

To

Subject

I agree.

--

---

From: Doug Royer <[email-masked]>
Date: Thu, 28 Aug 2003 14:58:25 -0600

[email-masked] wrote:
(your rude and childish comment removed)

> As per Derik Stenerson reponse changes to instances do not change pattern.

They did however say that it remains fixed as long as the pattern does
not change. Please explain how to move a Monday meeting to Tuesday
without changing the pattern.

---

From: [email-masked]
Date: Thu, 28 Aug 2003 17:06:42 -0400

> Now we change the RRULE on the base set: Should it be: UID:1, SEQ:51 OR

This is an example of misundertanding the role of a RRULE that I was 
talking about elsewhere.  If you are using an RRULE to invite someone then 
you are saying that all the instances created using the RRULE shorthand 
have _exactly_the_same_data_ with the only exception being the 
DTSTART/DTEND of each instance.  Other than than, ALL instances that are 
generated have the same data.

So if you move instances around or make any changes to them, you cannot 
expect an iTIP message with just the RRULE in it to accurately represent 
the instances anymore; you will have to rely on RDATEs or you will have to 
send the RRULE used and follow it with the individual different instances.

As such, for your example you have a couple choices on how to craft an 
invitation to someone new.  However Im not sure thats what you were 
intending.  What are you trying to do w/the set now?  Add a new invitee? 
Just recreate an iCalendar stream to represent it?  Something else?

In any case, the intent is not germane to Dougs contention that 
RECURRENCE-IDs change on an instance reschedule.

> the dead horse ("Will recurrence-id change for an instance reschedule?")

I agree.  By now it should be clear(er) that the iCalendar model is a 
fixed RECURRENCE-ID model.  Lets get on to other more pressing tasks 
before the ADs pull the plug on the WG.

Bruce
===========================================================================
Bruce Kahn                                INet: 
[email-masked]
Messaging & Collaboration                 Phone: 978.399.6496
IBM Software Group                         FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law...

---

From: [email-masked]
Date: Thu, 28 Aug 2003 17:19:13 -0400

08/28/2003 04:58 PM

To

Subject

[email-masked] wrote:

---

From: Doug Royer <[email-masked]>
Date: Thu, 28 Aug 2003 16:04:20 -0600

[email-masked] wrote:
> 
> In any case, the intent is not germane to Dougs contention that RECURRENCE-IDs
 > change on an instance reschedule.
> 

I have noted that in your recent responses you fail to explain
how to change an instance without changing the pattern. Perhaps
that will clear it up. If sequence:0 has dates/times

	A
	B
	C

and SEQUENCE:1 has

	A
	B
	D

How is not not a change to the pattern?

And by the way, my email was not about 'single instance' updates.
It was about the fact that RECURENCE-IDs are not fixed forever.

--

---

From: "Michael Fair" <[email-masked]>
Date: Thu, 28 Aug 2003 15:23:07 -0700

Would someone please reply to this post so that Doug will
actually see it.  I think we've explained it enough that
he's finally ready to listen to what we've been saying all along.

> without changing the pattern.

Here goes:
I define the set of recurring Mondays at SEQ:0
I move one of those Mondays to start on Tuesday at SEQ:1.
That instance, and only that instance are at SEQUENCE 1.

If I was to do a "REFRESH" on the UID I would get back
to VEVENT objects in the same REQUEST.

The first event component says:

SEQ:0
RRULE: Every Monday

The second says:

SEQ:1
RID: Some Monday
DTSTART Some Tuesday

The "set" of every Monday is still intact and has not been changed.
It just so happens that the instance created by "Some Monday" now
starts at "Some Tuesday".

I'll repeat:
The recurrence set still describes every Monday.
The recurrence set is still defined by SEQUENCE:0
The instance of "Some Monday" starts "Some Tuesday" and is
defined by SEQUENCE:1 of RID:"Some Monday".

Again, the repeat set defined by SEQUENCE:0 has not changed.
The only thing that has changed is that one of the instances
calculated by the repeat set actually starts on on a Tuesday.
It is important to note that the RECURRENCE-ID and DTSTART
for that instance DO NOT MATCH.

-- Michael --