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

From: Satya Vempati <[email-masked]>
Date: Wed, 27 Aug 2003 13:34:19 -0700

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.
 
The next interesting challenge is to find a scheme for updating SEQUENCE
numbers on the master and exception events while conforming to iTIP.

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

Only when you send a new RULE 
_____________________
Note: new email address

[email-masked] 

Doug Royer <[email-masked]> 
Sent by: [email-masked] 

08/27/2003 03:03 PM 
Please respond to
"[email-masked]" <[email-masked]>

To
"[email-masked]" <[email-masked]> 
cc
Subject
Does anyone still think that RECURRENCE-ID's do NOT change?

I know that there may be more screams that this issues will not
go away. But it really needs to be settled.

Despite the claims on this list, it appears that almost everyone
agrees that the RECURRECE-ID's do change and must change.

I think that proof is:

                So your first invitation is to:

                     UID:100
                     SEQUENCE:0
                     DATE:...sep-1...10am...

                Then you get:

                     UID:100
                     SEQUENCE:1
                     RRULE;FREQ=DAILY;COUNT=10
                     DTSTART:...sep-2...3pm

                What is the RECURRENCE-ID for the 1st object?
                  ...sep-1...10am... Correct?

                So which of the 10 instances has its RECURRENCE-ID fixed
to the 1st
                object?

                What are the 10 RECURRENCE-ID's for the 2nd object?

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

-- 

 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: Wed, 27 Aug 2003 15:30:07 -0600

> 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.

> numbers on the master and exception events while conforming to iTIP.

I do not follow. Do you mean that you want to update instances and not
change the SEQUENCE? If so, why?

--

---

From: [email-masked]
Date: Wed, 27 Aug 2003 18:02:27 -0400

This is WRONG Doug.  Rescheduling an instance only changes the SEQUENCE on 
that instance.  IT DOES NOT reset the RECURRENCE-ID of that instance, and 
it DOES NOT reset the PATTERN (RULE) of the meeting.
_____________________
Note: new email address

08/27/2003 05:30 PM

To

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

--

---

From: "Michael Fair" <[email-masked]>
Date: Wed, 27 Aug 2003 16:02:50 -0700

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

> 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.

> > 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: Doug Royer <[email-masked]>
Date: Wed, 27 Aug 2003 17:07:22 -0600

[email-masked] wrote:
> 
> This is WRONG Doug.  Rescheduling an instance only changes the SEQUENCE 
> on that instance.  IT DOES NOT reset the RECURRENCE-ID of that instance, 
> and it DOES NOT reset the PATTERN (RULE) of the meeting.

WRONG - If you change a MONDAY to a FRIDAY - please explain
how the pattern has not been altered? Or please show
an example of a rescheduling of an instance that has
the same pattern before and after the reschedule.

--

---

From: [email-masked]
Date: Wed, 27 Aug 2003 19:58:20 -0400

Since you never listen to any arguments that you did not start, why should 
I bother sending you anything.
This has been explained many time in the past, including the document from 
the original author Derik Stenerson.
_____________________
Note: new email address

08/27/2003 07:07 PM

To

Subject

--

---

From: "Michael Fair" <[email-masked]>
Date: Wed, 27 Aug 2003 17:15:01 -0700

Would someone please say this to Doug on my behalf.
A simple empty reply post should be enough.

Step 1 the initial recurring event:
UID:1
SEQ:0
RRULE:All Monday's

Step 2 move the "1st Monday" instance's DTSTART time
to "That Friday":
UID:1
RID:1st Monday
SEQ:1
DTSTART:That Friday

Now let's say someone issues a REFRESH on UID:1,
here's what they would get in response (without
the separator lines of course):

BEGIN:VCALENDAR
-----------------------------------
BEGIN:VEVENT
UID:1
SEQ:0
RRULE:All Monday's
END:VEVENT
-----------------------------------
BEGIN:VEVENT
UID:1
RID:1st Monday
SEQ:1
DTSTART:That Friday
END:VEVENT
-----------------------------------
END:VCALENDAR

They would not get some concocted variation of
EXDATE and RDATE with an RRULE to try and describe
every Monday except the first Monday but include
that Friday with whole base object at SEQUENCE 1.

-- Michael --

"Doug Royer" <[email-masked]> wrote in message
news:[email-masked]...

---

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

[email-masked] wrote:
> 
> Since you never listen to any arguments that you did not start, why 
> should I bother sending you anything.

Your technical point being what?

> This has been explained many time in the past, including the document 
> from the original author Derik Stenerson.

In that email signed by Derik and Frank they said that it
moves when the pattern moves. Do you dispute that?

So rather than respond to what I see and gaping holes in your
position, you avoid the technical debate by self proclaimed
declarations of rightness and not a technical response.

--

---

From: "Michael Fair" <[email-masked]>
Date: Thu, 28 Aug 2003 11:14:30 -0700

> declarations of rightness and not a technical response.

If this ain't the pot calling the kettle black I don't
know what is.

The irony in Doug's accusation here is so bold it's painful. :)

-- Michael --

---

From: [email-masked]
Date: Thu, 28 Aug 2003 15:42:04 -0400

Doug wrote on 08/27/2003 05:30:07 PM:
>                   Thus the set changes. Thus the RECURRENCE-IDs

Sorry but thats false.  iCalendar clearly says:

   The date/time value is set to the time when the original recurrence
   instance would occur; meaning that if the intent is to change a
   Friday meeting to Thursday, the date/time is still set to the
   original Friday meeting.

and iTIP uses "original" in a few places that confirm this.  Even if you 
have a different understanding of the meaning of original, the rest of the 
text should provide some clues.  Plus Deriks/Franks recent note confirmed 
this and expressly rejected your assertion:

a) the value for RECURRENCE-ID was agreed to be the date/time value of the 
original recurrence instance. This value remains unchanged for as long as 
the base recurrence set (or pattern) exists. A rescheduling of an 
individual recurrence instance did not cause creation of new base 
recurrence set, but only moved the start/end of the specified recurrence 
instance.

They went on to describe _why_ and that also jives w/the analysis Ive done 
and the comments of several of us. 

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 16:44:21 -0400

Doug fired back on 08/27/2003 07:07:22 PM:
> how the pattern has not been altered?

You are too fixated on the word "pattern" and thus are not seeing the 
concept for the word (to paraphrase a bit).  You have totally ignored the 
entire text of the response from Derik/Frank that expressly describes the 
single instance reschedule.   Much like you had a different defintion of 
the word "original" when reading iCalendar Section 4.8.4.4 I'm guessing.

Given that I tried to explain that RECURRENCE-ID is fixed based on RFC 
citations, that I provided an object analysis of both the fixed and delta 
models and showed exactly how the delta model fails to perform in error 
sitations and that the original authors provided a response that 
reconfirms the RFCs and what Ive been saying/showing I am at somewhat of a 
loss as to understanding why Doug (and 1 or 2 others) persists in saying 
that RECURRENCE-ID MUST change on each reschedule.

The only justification I have seen so far as to why Doug (and Chris and 
George?) think RECURRENCE-ID MUST change on each instance reschedule is 1 
line in iTIP.  A single sentence that contradicts ALL the other bits of 
iCalendar and iTIP.  A single sentece that the WG already considered in 
error back at least as far as 1999.

Can someone please explain why a delta model is still considered practical 
or functional given all the information to the contrary?  Perhaps if I can 
understand this I can better help to debunk it and we can move on to more 
pressing WG business.

Bruce

---

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

>   Friday meeting to Thursday, the date/time is still set to the

Yes, to change the pattern (set), send an iTIP message that has
the RECURRECE-ID set to the one you are changing from. So what?
So you agree that you are telling the ATTENDEE to change the
set (pattern). Why do you feel that does not cause the pattern
of the set to change?

--

---

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

[email-masked] wrote:
> concept for the word (to paraphrase a bit).  You have totally ignored 
> the entire text of the response from Derik/Frank that expressly 
> describes the single instance reschedule.   Much like you had a 
> different defintion of the word "original" when reading iCalendar 
> Section 4.8.4.4 I'm guessing.

You are totally fixated on ignoring that words 'pattern' and 'changed'.
You ignore change in iTIP, iCAL, and now in Frank's and Derik's email.

Please send a sequence of iTIP updates that alter the date/time of
one or more instances that do not change the pattern (set).
The entire point of a iTIP instance reschedule is to change
the pattern. You could send an iTIP message that changes the
LOCATION and that does not change the pattern. Is that what
you mean?

--