Subject: Fw: Correct handling of Recurrence-id

From: kiwong <[email-masked]>
Date: Fri, 30 May 2003 12:59:09 -0700

> > Still, that had nothing to do with the workflow recovers in the model
you
> > espouse.  Can you please show me how a REFRESH magically solves the case
> > of a missed (or purposely deleted by the CU) entry in the chain?
Perhaps
> > George can chime back in and rephrse what Doug's said so that its clear.
> > Or if someone else out there can show how everything gets resync'd
> > properly when RECURRENCE-IDs change per SEQUENCE Im all eyes!
Anyone??!!

 Thanks you Bruce! You put in a lot of examples and did a in-depth analysis
of why delta changes RECURRENCE-IDs is a bad thing and I agree with you
100%.
So far, I also don't see a convincing example for the benefit of delta
changes
RECURRENCE-IDs, nor do I see how delta changes RECURRENCE-ID will work for
Bruce's samples.

 Keeping the RECURRENCE-ID constant is straight-forward and easy to
understand. Not only it guarantees workflow will work, but work efficiently.
And it eliminates the whole mess of delta changes RECURRENCE-ID ambiguity.
So can someone
give us the reason why we shouldn't do it? Or can someone walk through a
complete RRULE
example like what Bruce has done and demonstrate how delta changes
RECURRENCE-ID can achieve the same goal??

Just to add one more perspective to this, Microsoft Exchange 2000 iTIP/iMIP
works with recurring instances with the model of RECURRENCE-IDs never
change. I believe
this is same for Notes. Bruce, can you confirm? If your product requires
interoperability with them,
delta changes RECURRENCE-ID will have nothing but headaches.

ki

---

From: [email-masked]
Date: Fri, 30 May 2003 16:22:46 -0400

The RNext notes uses iCalendar model  were RECURRENCE-ID's never change. 
This will not change unless there is a  VERY good argument to do so.

_____________________
Note: new email address

[email-masked]

kiwong <[email-masked]> 
Sent by: [email-masked]
05/30/2003 03:59 PM

To
[email-masked], [email-masked]
cc

Subject
Fw: Correct handling of Recurrence-id

you
Perhaps
Anyone??!!

 Thanks you Bruce! You put in a lot of examples and did a in-depth 
analysis
of why delta changes RECURRENCE-IDs is a bad thing and I agree with you
100%.
So far, I also don't see a convincing example for the benefit of delta
changes
RECURRENCE-IDs, nor do I see how delta changes RECURRENCE-ID will work for
Bruce's samples.

understand. Not only it guarantees workflow will work, but work 
efficiently.

Just to add one more perspective to this, Microsoft Exchange 2000 
iTIP/iMIP

ki

---

From: Doug Royer <[email-masked]>
Date: Fri, 30 May 2003 14:53:56 -0600

>  This will not change unless there is a  VERY good argument to do so.

So if SEQUENCE:1 changes 100% of all instances.
Then SEQUENCE:2 trying to cancel one of the new (SEQUENCE:1 instances.

You can't becaues you would have no idea what was being canceled
if the RECURRENCE-ID refer to the SEQUENCE:0 instances.

-- 

  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