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

From: Doug Royer <[email-masked]>
Date: Wed, 27 Aug 2003 13:03:20 -0600

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: [email-masked]
Date: Wed, 27 Aug 2003 15:28:41 -0400

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

I think that proof is:

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

                 Then you get:

                    UID:100
                    SEQUENCE:1

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

--

---

From: [email-masked]
Date: Wed, 27 Aug 2003 16:11:37 -0400

You are sending invalid instance invitations to start with.
If you send an Instance invitation you MUST include the RECURRENCE-ID

When you send a REQUEST with a new RULE.  You are telling the receiving 
Calendar Store ...NUKE ALL ENTRIES   in your calendar store.   Nothing in 
your store is valid, I AM RESETTING THE RULE AND RECURRENCE-IDs and 
sending all new information.
_____________________
Note: new email address

To

Subject

I think that proof is:

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

                 Then you get:

                    UID:100
                    SEQUENCE:1

--

---

From: "Shannon J. Clark" <[email-masked]>
Date: Wed, 27 Aug 2003 15:28:40 -0500

It occurs to me to wonder, mostly as a user, what a change in RULE does to
events IN THE PAST?

In at least some calendars, I have seen "past" events deleted or otherwise
modified when rules have been modified.

Perhaps this is not specifically a question for the standards, but it
appears to me to be something fairly important in general.

1. Is there a built in assumption to the calendaring standards that there is
a "past" "present" and "future", perhaps with the possibility that no
changes should modify the past?

2. If not, should the standards at least make a clear suggestion of a
standardized way to handle reoccurring events which change how they reoccur,
where the "past" events MUST remain on the times on which they occurred?

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

  When you send a REQUEST with a new RULE.  You are telling the receiving
Calendar Store ...NUKE ALL ENTRIES   in your calendar store.   Nothing in
your store is valid, I AM RESETTING THE RULE AND RECURRENCE-IDs and sending
all new information.
  _____________________
  Note: new email address

        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 think that proof is:

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

                  Then you get:

                       UID:100
                       SEQUENCE:1

  --

---

From: Doug Royer <[email-masked]>
Date: Wed, 27 Aug 2003 15:01:08 -0600

> Only when you send a new RULE

I assume you also mean change any of:

	DTSTART
	RDATE
	RRULE
	EXDATE
	EXRULE

--

---

From: Doug Royer <[email-masked]>
Date: Wed, 27 Aug 2003 15:18:18 -0600

Shannon J. Clark wrote:
> It occurs to me to wonder, mostly as a user, what a change in RULE does 
> to events IN THE PAST?
>  
> In at least some calendars, I have seen "past" events deleted or 
> otherwise modified when rules have been modified.
>  
> 1. Is there a built in assumption to the calendaring standards that 
> there is a "past" "present" and "future", perhaps with the possibility 
> that no changes should modify the past?

No. iCAL and iTIP specify how to transfer information. It is up
to the CUA to care about the CU's view of the history of a UID.

> standardized way to handle reoccurring events which change how they 
> reoccur, where the "past" events MUST remain on the times on which they 
> occurred?

There is a 'RANGE' parameter that is used with the RECURRENCE-ID
property to specify changes relative to a time, but NOT the same purpose.

So when the ORGANIZER changes a VEVENT for example, they can
change the instances 'this' (by RANGE's omission), THISANDPRIOR,
and THISANDFUTURE.

However as the usage of calendaring information may vary, it is
a CUA implementation detail as to the memory of any obsolete objects
or instances. I do not think that it could be standardized without
very specific and constrained usage definitions. What would work
for 'a history of events' might not apply to 'motel reservations'.

If a CUA needs to remember history it could save the objects in
its CS with a modified UID that it could use to tell were related
to the originals, or kept for history, or ....

--

---

From: Doug Royer <[email-masked]>
Date: Wed, 27 Aug 2003 15:26:05 -0600

[email-masked] wrote:
> Calendar Store ...NUKE ALL ENTRIES   in your calendar store.   Nothing 
> in your store is valid, I AM RESETTING THE RULE AND RECURRENCE-IDs and 

It goes further than that as iTIP says that when the SEQUENCE changes
then all older objects are obsolete. And SEQUENCE can be incremented
for more than instance changes.

And as all changes to any instance (single or all) require that the
SEQUENCE must be incremented, then yes the old instances are obsolete
and must be nuked. So according to iTIP it is the fact that the SEQUENCE
number got bumped that causes the old obsolete objects (instances
and all) to get nuked. However if no instance is changed and for other
reasons the SEQUENCE is incremented, then it is just a coincidence
that the RECURRENCE-IDs in the old nuked objects just happen to be
the same as the ones in the new object.

--

---

From: [email-masked]
Date: Wed, 27 Aug 2003 17:58:32 -0400

No I do not.

I do mean 
                 RDATE
                 RRULE
                 EXDATE
                 EXRULE

DTSTART is not part of RULE
_____________________
Note: new email address

08/27/2003 05:01 PM

To

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

                 DTSTART
                 RDATE
                 RRULE
                 EXDATE
                 EXRULE

--

---

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

The reschedule  to an instance only changes the SEQUENCE on that 
instance... NOT ON THE ENTIRE SET.
_____________________
Note: new email address

08/27/2003 05:26 PM

To

Subject

--

---

From: Doug Royer <[email-masked]>
Date: Wed, 27 Aug 2003 16:58:01 -0600

If you change the DTSTART - *only*, as in:

	SEQUENCE:X
	DTSTART:...monday..
	RRULE:FREQ=WEEKLY

To:

	SEQUENCE:X+Y
	DTSTART:...tuesday...
	RRULE:FREQ=WEEKLY.

The instances and RECURRECE-ID's change.
So DTSTART *is* included even when; RRULE,
RDATE, EXDATE, and EXRULE do not change.

--

---

From: Doug Royer <[email-masked]>
Date: Wed, 27 Aug 2003 17:05:34 -0600

> instance... NOT ON THE ENTIRE SET.

Whether this is done with RRULEs, ADD's or what ever, if the result
is equivalent to:

	SEQUENCE:0
	RDATE:...monday...
	RDATE:...tuesday..

And then the Monday meeting is chagned to Friday with
a single instance modificaiton:

	SEQUENCE:1
	RECURRENCE-ID:...monday
	RDATE:...friday...

The RECURRENCE-ID for Monday is void because I could have
choosen to send the following and not the previous example:

	SEQUENCE:1
	RDATE:...friday...
	RDATE:...tuesday..

And the results must be equivelent to the ATTENDEE.

So in all cases the 'set' of RECURRECNE-ID's is not the same
and SEQUENCE:0

--

---

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

If I change "DTSTART" on the base object, it says that
I am redefining all instances to start at that new time.

Since RECURRENCE-IDs are both date and time based, and
they are calculated off of the RULEs plus the DTSTART,
this would be a redefinition of the set and would redefine
the RECURRENCE-IDs since every single instance now starts
at that new time.

Since we are forced to bump the SEQUENCE number when changing
DTSTART there is no violation of iCal nor iTIP here.  It
just means something other than an instance reschedule. It
means a reschedule of the entire set and as is appropriate
to such an act it redefines the set of RECURRENCE-IDs.

Again, it does not mean an instance reschedule.  It has nothing
to do with an instance reschedule.  It is not true that changing
the DTSTART of any particular instance redefines the entire
set and therefore no RECURRENCE-IDs change in the event of an
instance reschedule.

-- Michael --

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

---

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

Updates to DTSTART, EX/RRULE, EX/RDATE or submitting
an ADD all update the SEQUENCE of the base event.
They all redefine the set of RECURRENCE-IDs.

None of these however are instance reschedules.
Instance reschedules only bump the SEQUENCE of that
individual instance not the base object and therefore
do not redefine any RECURRENCE-IDs.

We have presented on several occasions the problems
that ensue if one did try and do this and he has not
addressed them.  Further, even for arguments sake,
he has not even accurately represented the SEQUENCE
per instance behavior when he talks about the
fixed-id model.

Doug has not addressed what he thinks that each instance
"may be both referenced and versioned" means, but his
other supporter Chris Olds acknowledged that it *could*
mean that each instance had its own SEQUENCE value.

Meaning that even a proponent of Doug's model says
that per instance SEQUENCE values can not be disputed
as invalid.  Though, because of the "may", he does not
go so far as to say that iTIP says that each instance
definitely has its own SEQUENCE value and contends that
their one-SEQUENCE-for-all model is still valid within
that wording.

While I don't disagree with him on that point, other
wording from both iCal and iTIP becomes more meaningful
when each instance MUST track a SEQUENCE independently.

-- Michael --

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

---

From: [email-masked]
Date: Wed, 27 Aug 2003 19:55:28 -0400

We are not doing your CRAZY model.
You do not send an RDATE in and instance REQUEST

_____________________
Note: new email address

08/27/2003 07:05 PM

To

Subject

                 SEQUENCE:0
                 RDATE:...monday...
                 RDATE:...tuesday..

                 SEQUENCE:1
                 RECURRENCE-ID:...monday
                 RDATE:...friday...

                 SEQUENCE:1
                 RDATE:...friday...
                 RDATE:...tuesday..

--

---

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

[email-masked] wrote:

(your childish rude comment removed)

 > instance... NOT ON THE ENTIRE SET.

I should have sent:

                 SEQUENCE:0
		DTSTART:...monday...
                 RDATE:...tuesday..

And then the Monday meeting is changed to Friday with
a single instance modification:

                 SEQUENCE:1
                 RECURRENCE-ID:...monday
                 DTSTART:...friday...

The RECURRENCE-ID for Monday is void because I could have
chosen to send the following and not the previous example:

                 SEQUENCE:1
                 DTSTART:...friday...
                 RDATE:...tuesday..

as SEQUENCE:0

--

---

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

"Doug Royer" <[email-masked]> wrote in message
news:[email-masked]...
> Whether this is done with RRULEs, ADD's or what ever, if the result

Rescheduling an instance is never equivalent to an RRULE or ADD update.
Rescheduling an instance changes solely the DTSTART of that instance
and the SEQUENCE.  The RECURRENCE-ID remains as it is defined by
the latest recurrence set description set forth in the base object.

Rescheduling an instance has influence only over that instance.
Changing an RRULE or doing an ADD has influence over the base
object, thereby having influence over the entire set.

> chosen to send the following and not the previous example:

Your examples are hard to follow because you don't tell us
what's going on.  In the first case you talk about Mondays,
and you move one of them to Friday, and in the second case
(supposedly the base event for the first case) you are now
seemingly talking about Fridays and adding a Tuesday.
What was the base case?
What change are you trying to make?

There are two ways to get the same result as a rescheduling of
an instance.  In one, you simply reschedule the instance, in
the other you redefine the whole set to exclude the original
date and add the new date.

In the first case, the RECURRENCE-ID for Monday is not void
because you have not changed the SEQUENCE for the base event.
The SEQUENCE for only that Monday instance has increased.
When the recurrence rule for the base event is expanded it
still contains a Monday RECURRENCE-ID.  The "reschedule" is
treated as an update to that Monday instance.  When a REFRESH
happens the bsae event is still SEQUENCE 0 and that Monday
instance is now SEQUENCE 1.  If you rescheduled that instance
50 more times, the SEQUENCE for the base event would still be
0, and the SEQUENCE for that Monday would be 51.

In the second instance you have rescheduled the entire series
and redefined the entire set of instances, coincidently the
Monday instance is no longer there and there also happens to
be a new Friday instance.  The two are not related as far as
the CUA's are concerned.  So in the second case, you have not
"rescheduled an instance" you have "redefined the set to
exclude one instance and add a different instance".

While an ORGANIZER's CUA can make this look like a reschedule,
it's not, it's a set redefinition.

-- Michael --

---

From: [email-masked]
Date: Thu, 28 Aug 2003 15:33:02 -0400

> go away. But it really needs to be settled.

We went thru this before we RFCd.  We went over this a lot recently.  We 
even got the original authors to clarify it.  Yet it seems that its a hard 
concept for some to accept for some reason... 

> agrees that the RECURRECE-ID's do change and must change.

Not quite.  Ive not kept up with the last spurt of messages but when I 
last checked I sensed no such feeling by the WG.

Unless you ignore how poorly the workflow process performs when a delta 
model is used with missequenced or lost messages then I dont see how that 
anyone can think the RECURRENCE-IDs "must" change. 

Ive repeatdly shown how poorly a changing ID model is, especially with 
missequenced or lost messages.  To date, no one has been able to dispute 
it; at least not technically. 

So Im a bit weary with this topic and the repeated attempts to change 
whats WRITTEN in the RFCs and whats been technically analyzed and even 
commented on by the original authors.  How many times do we need to rehash 
this??

>         RRULE;FREQ=DAILY;COUNT=10

<FRUSTRATION /SHOW=ON>
Ugh!  THIS IS A TOTALLY DIFFERENT FISH THAN THE NORMAL INSTANACE 
RESCHEDULE EXAMPLE!  The former snippet is a singleton instance reference 
(NO RECURRENCE-ID).  The latter snipper is a (re)creating of a repeating 
set of instnaces.  They are 2 totally different fish!  You cannot use them 
both to justify the delta model; the 1st one isnt repeating!
</FRUSTRATION>

The first example is NOT a legit message when referencing an instance of a 
repeating set; it has no RECURRENCE-ID.  The only thing I can infer from 
these 2 snippets is that you took a non-repeating entry and made it 
repeat. 

This is totally unrelevant to WHY a RECURRENCE-ID "must change" when an 
instance is rescheduled!

>      ...sep-1...10am... Correct?

If by "the 1st object" you are referring to the 1st fragment then it has 
NONE!  Its NOT repeating.

If by "the 1st object" you are referring to the 1st instance generated by 
the 2nd fragment then its Sep02@3PM; the DTSTART value defines the first 
instance of the repeat set, as defined in iCalendar by:

                                              The recurrence set is
   generated by considering the initial "DTSTART" property along with
   the "RRULE", "RDATE", "EXDATE" and "EXRULE" properties contained
   within the iCalendar object.

Do not try to confuse the issue by mixing non-repeating and repeating 
defintions; a non-repeating entry is not the same as an entry that repeats 
only once (unless you have a different defintion of the word repeating or 
repeat than the rest of us). 

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

You are using an invalid example to justify why RECURRENCE-ID must change 
for all cases. 

You have pointedly ignored the objective analysis of where the changing 
model fails without changing the instance set; where we just reschedule a 
single instance and have missequenced or lost messages.  The delta model 
can become unrecoverable for this common case as the analysis has shown. 

We even got a posting from the original authors on this issue but that 
didnt seem to help some.  Perhaps you didnt actually see all of the text 
in Deriks/Franks posting.  Let me cut out the relevant bits that you 
seemed to have missed:

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.  [Emphasis added -BK]

b) An addition of a new recurrence instance to the set would be an example 
of an action that would create a new recurrence set ? e.g. changing a 
Monday weekly meeting to a Monday and Tuesday weekly meeting. This latter 
action is an example of an action that *might* also cause the values of 
the RECURRENCE-ID properties for each member of the recurrence set to get 
redefined

I have said all along that adding new instances could be cause for 
RECURRENCE-ID to change (part 'b') but since the example in question was 
rescheduling a single instance I maintain (in agreement with the RFCs 
[except for the _1_ erroneous line in iTIP] and the authors) that 
RECURRENCE-ID stays fixed (part 'a').  Doing so makes dealing with 
missequenced or lost messages much simpler and easier.  If the model were 
a delta model then workflow recovery would require LOTS more work and 
would still not be guaranteed.

In talking w/some folks I think I see why there is such tenacity regarding 
"How do I send the same rule" to a new invitee after the fact or after 
something changed.  I suspect that some folks are relying too heavily 
repeating rules and do not quite understand their role/use.   Perhaps a 
few cycles should be spent on this now to clear up some possibly 
misunderstood or overlooked ideas.

We added a repeating grammar for repeating (and exception) rules for 2 
reasons: it provided a shorthand way to send large sets of repeat instance 
dates and it was the only way to represent "the infinitely repeating 
entry" (that only Outlook had at the time).  In order for repeating rules 
to be applicable for use, all instances generated must by defintion have 
the exact same set of properties (except their effective DTSTART/DTEND). 

The _only_ place where a repeating rule is really necessary is for the 
infinite case.  For a non-infinite set, the RRULE only saves some octets 
in the iTIP message compared to sending RDATEs.  So, for large repeating 
sets using a recurrence rule is an easy way to save space in the iCalendar 
stream sent.   So the fragment:

     DTSTART:20030902T140000Z
     RRULE:FREQ=DAILY;COUNT=10

is an alternative to this fragment:

     DTSTART:20030902T140000Z
     RDATE:20030903T140000Z
     RDATE:20030904T140000Z
     RDATE:20030905T140000Z
     RDATE:20030906T140000Z
     RDATE:20030907T140000Z
     RDATE:20030908T140000Z
     RDATE:20030909T140000Z
     RDATE:20030910T140000Z
     RDATE:20030911T140000Z

It should be clear that once you reschedule a single instance then the use 
of a recurrence rule becomes MUCH harder if not impossible (at least 
solely).  For example, if I reschedule the 6th instance to a different 
time then you cannot expect the RRULE:FREQ=DAILY;COUNT=10 to still be 
usable when adding any new invitees!  You have a few possible ways of 
sending this new set to a new invitee but using just a single RRULE is NOT 
possible any more.

If I opt'd to send the REQUEST with RDATEs instead of an RRULE and then I 
want to reschedule an instance, I would send nearly the same iCalendar 
stream but the 6th instance would be different (reflecting the new time). 
If I didnt use an RRULE then there is no "pattern" to change.  I'm 
guessing that some folks are focusing on that particular word (to the 
exclusion of all the other author reponse) since only the recurrence 
grammar is designed to express patterns in a compact way. 

People should not get hung up on the use of a pattern in the iTIP 
messages; the pattern is simply what the recurrence grammar is designed to 
encode.  As such, it cannot be used for entries that do not repeat on some 
form of regular pattern. To do that you have to use RDATEs (or ugly 
combinations of RRULEs/EXRULEs/EXDATEs).  Once you reschedule any single 
instance, you no longer have a pattern to follow.

Another thing that I think some folks do not grok fully is that in order 
for an RRULE to be used to generate a set of entry instances, there can be 
NO differences between each instance apart from its start/end date/times. 
Every single property is _exactly_ the same: the same ATTENDEE list, the 
same DESCRIPTION, the same ATTACHments, etc.  This most commonly occurs 
only when the instances are first created.  After that things typically 
change: ATTENDEE PARTSTATs vary, ATTACHments change, DESCRIPTIONs 
(typically the Agendas) change, COMMENTS about the instances vary, etc. As 
such, its not possible to rely on a RRULE (or group of RRULEs) in a single 
message to be usable when adding a new invitee; the individual instances 
have different data.  They no longer are near exact clones of each other. 

If you do not focus just on the idea of a particular pattern and treat the 
instances as a set that can move around then it should be clear why the 
RECURRENCE-IDs do not change on a reschedule.  By keeping them fixed 
missed changes (ie: lower SEQUENCE valued messages) are NOT a concern 
since they are obsolete anyway.  ONLY with fixed RECURRENCE-IDs is it 
possible to detect a missequenced iTIP message and deal with it properly. 

Some folks seem to think that there is some mystical need to distinguish 
an invitation from a reschedule from an update and are seemingly deriving 
this from the presence of repeating information (or lack of 
RECURRNECE-IDs).  This is an unnecessary distinction AND its NOT described 
at all in the iTIP RFC.  The distinction is clearly described in reference 
to the recipients calendar and NOT to the senders or the iTIP message 
itself.   There is NO need to draw any distinctions; if the entry is new 
to the recipient then its an Invitation, otherwise its a reschedule or an 
update. 

So you may ask why does Doug try to draw a distiction?  The answer is 
simple: The need for a distinction derives from the delta models inability 
to deal with lost or missequenced messages.  The recipient has no way to 
differentiate a missed reschedule from a new instance invitation.  Thus 
the only solution for the delta model is to stop all workflow on ALL 
instances and ask the Organizer for a REFRESH of all instances in 
question.  There are a couple notable problems w/this design: 

1: Until the Organizers 'nuke' REQUEST gets there the recipient can 
perform NO workflow on ANY instance.  That means NO accepting, declining, 
counter proposing or delegating; they can safely perform NO action until 
they recreate all instances w/the correct current RECURRENCE-IDs. 

2: Because iTIP cannot guarantee delivery its possible that the Organizers 
REQUEST never arrives thus the invitee can be indefinitely stuck 
w/calendar entries that they cannot be sure are still real or not.  Or its 
possible that the "full REFRESH" never gets to the Organzier so they never 
have a clue that some invitee needs help...

3: Its possible that the recipient was only invited to a particular 
instance.  As such the Organizer would only send a REQUEST with that 
RECURRENCE-ID in it; not one with an RRULE or other repeating info in it. 
Sending a REQUEST without a RECURRENCE-ID is not semantically the same as 
a REQUEST for a single instance;  the recipient will treat it as a 
non-repeating entry when in fact its an instnace of a repeat set.  As such 
adding the invitee to other instances means destroying what they think the 
UID is and having them recreate a new set of now repeating instances. This 
means that even though nothing may have changed about the initial instnace 
they were invited to, the Organizer MUST resend all the data for the 
unchanged instance just so the recipient can destroy and recreate it in 
their calendar as a repeating instance now.  What a waste of bandwidth and 
cycles!  Plus, iTIP clearly says that RECURRENCE-ID MUST be on the REQUEST 
when it refers to an instance of a repeat set (check the restriction table 
if in doubt).

If you consider the correct usages for recurrence rules, the analysis of 
the delta models shortcomings and the response from Derik/Frank I would 
hope that it should be clear now exactly why the model is fixed and not 
changing.  But Im not holding my breath just yet...

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:13:22 -0400

> RDATE, EXDATE, and EXRULE do not change.

This is NOT rescheduling an instance; its recreating the set!  iCalendar 
says that RECURRENCE-IDs "might also change" in this case and so far we 
all seem to agree on this case (and this is backed up by the 3.b text from 
the original authors).

If you want to discuss when RECURRENCE-IDs do change thats one thing but 
your example above is NOT a instance reschedule example.

Bruce

---

From: [email-masked]
Date: Thu, 28 Aug 2003 16:26:21 -0400

Doug claimed on 08/27/2003 07:05:34 PM:
> The RECURRENCE-ID for Monday is void 

Not, its not void.  What you describe exactly matches the iCalendar text 
and what we've said been saying all along. 

>                                      because I could have

The above is not equivalent to the attempted reschedule.  This fragment is 
one that causes the recipient to recreate the UID with the given 
RECURRENCE-IDs; it in effect is a recreating of all the instances for that 
UID on the recipients calendar. The first fragment was a single instance 
reschedule.  They are totally different.

PLUS its incorrect in that the Tuesday instance did NOT change so its 
SEQUENCE should still be 0.

> So in all cases the 'set' of RECURRECNE-ID's is not the same

Huh??  You must not have understood the text Derik/Frank put in their #3 
item.  It clearly says that RECURRENCE-IDs are fixed and do not change 
unless you recreate the set; a reschedule does NOT recreate the set, it 
merely moves an instance around.

Believe what you like but iCalendar was pretty clear on RECURRENCE-ID 
staying fixed when an instance is rescheduled.  Derik/Frank reiterated 
that with their recent reponse that expressly said this.

If you look at the analysis of how iTIP performs or fails when messages 
are lost or missequenced, how can you still think that a delta model 
works?  A delta model is error prone and hard to recover from.  The fixed 
model recovers quite easily and there is no need for extra back and forth 
iTIP messaging (which still does not guarantee workflow recovery and 
resyncing like a fixed model)

Bruce

---

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

[email-masked] wrote:
> even got the original authors to clarify it.  Yet it seems that its a 
> hard concept for some to accept for some reason...  

Yes. They said it changed. Yet some still insist that it does not.

Derik and Frank do think it changes, as they said when the pattern
changes - it changes.

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

   ...

  "This semantic and behavior was settled on because it is imperative in order
  for an implementation to maintain order and sensibility between the original
  definition for the recurrence set and exceptions created by subsequent
  rescheduling actions on the recurrence set. "

  ...

  "In summary, the original intention of the iCalendar specification was that
  the value of the RECURRENCE-ID for a specific recurrence instance would
  remain unchanged for the duration of the existence of the recurrence set.
  Rescheduling individual recurrence instances did not cause recreation of the
  recurrence set or change the value of the RECURRENCE-ID property for the
  associated recurrence instance, but only involved changes to the start/end
  of the recurrence instance."

So if an ATTENDEE has SEQUENCE:X and you update SEQUENCE:X to SEQUENCE:Y
then it does not change the RECURRENCE-ID of SEQUENCE:X, it updates
the object from X to Y in the ATTENDEE's store. And the RECURRECE-ID in
Y (the one the ATTENDEE is now at) has a different pattern in Y than in X.
So the next update will be to the Y pattern and not the X pattern. This
allows invitation without the need for history.

If you disagree please explain what Frank and Derik mean when they
said '...This value remains unchanged for as long as  the base recurrence
set (or pattern) exists. ...' If you change the base (reschedule it)
it changes the pattern. When would a reschedule NOT change the pattern?

So when you change the pattern - it changes. If you only change
the LOCATION (for example)- it does not change the RECURRENCE-ID's.

They did not say it is fixed forever.

(your related other subject deleted from this email.)

--

---

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

[email-masked] wrote:

> RESCHEDULE EXAMPLE!

I assume you have not read my corrected e-mail. So I'll reply
to any post you have to that correction - if any.

--

---

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

> it; at least not technically.  

So far your assertion that it does not change has been disputed
by Frank and Derik, so what is the point of debating a conclusion
based on your disputed assumption?

> commented on by the original authors.  How many times do we need to 
> rehash this??

Explain how you change the pattern and still keep the RECURRECE-ID's
fixed. Or explain how your model is consistent with Frank and Deriks
assertion that it changes?

--

---

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

[email-masked] wrote:
> This is NOT rescheduling an instance; its recreating the set! 

Which was my point as Robert said that 'DTSTART' was not
in the set that effected the RECURRENCE-ID changing when he
replied to my example and he said:

     "No I do not.

      I do mean
                 RDATE
                 RRULE
                 EXDATE
                 EXRULE

     DTSTART is not part of RULE"

In responce to my email that said that moving the DTSTART effects
the pattern. And it does change the RECURRENCE-IDs. I said
noting about single instance update. And the example he responded
to was a full replacement showing that the RECURRECE-IDs change
when the pattern changes on a full replacement.

_____________________

--

---

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

> and what we've said been saying all along.  

Well itip says it is 'obsolete'. That means void to me.

> The above is not equivalent to the attempted reschedule.  This fragment 
> is one that causes the recipient to recreate the UID with the given 
> RECURRENCE-IDs; it in effect is a recreating of all the instances for 
> that UID on the recipients calendar. The first fragment was a single 
> instance reschedule.  They are totally different.

Yes that is my point. They are different and BOTH valid.
They both produce the exact same dates/times on the ATTENDEE's CUA.
So why does it matter which of the two methods were used?
They both changed the instance patterns. And the instance
patterns changed are exactly the same. So what?

> merely moves an instance around.

Yes. They clearly say that if the pattern changes, the RECURRECE-IDs
change. The recurrece-id in SEQUENCE:1 does NOT have the same
RECURRECE-ID patterns that are in SEQUENEC:0, they changed. You also
noticed that above when you noted by exclusion that one of the two
did not change - (implying that the patterns are not the same - correct?)

--

---

From: [email-masked]
Date: Thu, 28 Aug 2003 17:14:20 -0400

That's is BOGUS Doug.

Derik Stenerson said
> 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. 

_____________________
Note: new email address

08/28/2003 04:35 PM

To

Subject

--

---

From: [email-masked]
Date: Thu, 28 Aug 2003 17:27:20 -0400

I will admit I was wrong in that case.  Sorry
If you send a REQUEST with no RECURRENCE-ID than it applies to the entire 
set.
Thus changing the DTSTART does reset the pattern.
_____________________
Note: new email address

08/28/2003 05:05 PM

To

Subject

     "No I do not.

      I do mean
                 RDATE
                 RRULE
                 EXDATE
                 EXRULE

_____________________

--

---

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

> That's is BOGUS Doug.

I'll place that on the list of points that one day will help
resolve the issue. But first could you explain your point
as it relates to CALSCH or resolving this debate?

--

---

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

I'll place that on the list of points that one day will help
resolve the issue. But first could you explain your point
as it relates to CALSCH or resolvint this debate?

--

---

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

[email-masked] wrote:
> If you send a REQUEST with no RECURRENCE-ID than it applies to the 
> entire set.

Okay - my quesitons now are:

  When does the pattern NOT change on a reschedule as seen
  by the ATTENDEE?

  When does the pattern NOT change on a reschedule as seen
  by the ORGANIZER?

And I do not care  if it is a single or full update example(s).

--

---

From: [email-masked]
Date: Thu, 28 Aug 2003 18:19:40 -0400

I sent the supporting  text.. You ignored it.
_____________________
Note: new email address

08/28/2003 05:58 PM

To

Subject

--

---

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

> I sent the supporting  text.. You ignored it.

Please explain how posting the word BOGUS helps anything.

And I am still waiting to see examples of how to
reschedule one or more instances and not change
the recurrence pattern (set).

---

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

[email-masked] wrote:

> sets using a recurrence rule is an easy way to save space in the 
> iCalendar stream sent.   So the fragment:
> 
>      DTSTART:20030902T140000Z
> It should be clear that once you reschedule a single instance then the 
> use of a recurrence rule becomes MUCH harder if not impossible (at least 
> sending this new set to a new invitee but using just a single RRULE is 
> NOT possible any more.

If the RRUE is easy or hard does not seem to be a qualification for
the definition of RECURRENCE-ID. Your point above is not relevant
to the point of whether the effective DTSTARTs you have above are
the same in the SEQUENCE:0 object as they are for the SEQUENEC:1 object.

> If I opt'd to send the REQUEST with RDATEs instead of an RRULE and then 
> I want to reschedule an instance, I would send nearly the same iCalendar 
> stream but the 6th instance would be different (reflecting the new 
> time).  If I didnt use an RRULE then there is no "pattern" to change. 
>  I'm guessing that some folks are focusing on that particular word (to 
> the exclusion of all the other author reponse) since only the recurrence 

Bruce - I find it hard to believe that you really believe that you
can exclude 'pattern' and 'change' in Derik's and Frank's email and
keep a straight face.

> messages; the pattern is simply what the recurrence grammar is designed 
> to encode.  As such, it cannot be used for entries that do not repeat on 
> some form of regular pattern. To do that you have to use RDATEs (or ugly 

Pattern is the pattern of instances. No where in Frank's or Derik's email
do they define pattern to be the RRULE grammar. It is however used
in the paragraph that describes the 'instances'. And for that I read
that the RECURRENE-ID's are the effective start dates of the object.

> for an RRULE to be used to generate a set of entry instances, there can 
> be NO differences between each instance apart from its start/end 
> date/times.  Every single property is _exactly_ the same: the same 
> ATTENDEE list, the same DESCRIPTION, the same ATTACHments, etc.  This 
> most commonly occurs only when the instances are first created.  After 
> that things typically change: ATTENDEE PARTSTATs vary, ATTACHments 
> change, DESCRIPTIONs (typically the Agendas) change, COMMENTS about the 
> instances vary, etc.  As such, its not possible to rely on a RRULE (or 
> group of RRULEs) in a single message to be usable when adding a new 
> invitee; the individual instances have different data.  They no longer 
> are near exact clones of each other.  

When you use the word 'instances' above in the last sentence you do not
mean the effective start date instance - Correct? You mean the copy
that one ATTENDEE sees with respect to another ATTENDEE may differ-
Correct? If so, I think we agree.

You are also not saying that all ATTENDEES need see the exact (byte
for byte) same object correct?

> If you do not focus just on the idea of a particular pattern and treat 
> the instances as a set that can move around then it should be clear why 
> the RECURRENCE-IDs do not change on a reschedule.  By keeping them fixed 

> an invitation from a reschedule from an update and are seemingly 
> deriving this from the presence of repeating information (or lack of 
> RECURRNECE-IDs). 

You do seem to get initial invitations crossed referenced with the
RECURRENCE-ID issue. I suspect it is for the same reason. Because
you have a legacy problem and not because it says so in ITIP (and
despite the 300-400 emails sent on this subject - there has not
been ONE that explains where in iTIP or iCAL or iMIP that says you
can send an instance update and call it an initial invitation.)

The myth as you call it is a section or two in iTIP. The real myth
is that you can selectively ignore parts of iTIP to satisfy your CUA
legacy requirements.

> This is an unnecessary distinction AND its NOT 
> described at all in the iTIP RFC.

What about the specific text in: "4.4.2 Modify A Recurring Instance" ?

>  The distinction is clearly described 
> in reference to the recipients calendar and NOT to the senders or the 
> iTIP message itself.   There is NO need to draw any distinctions; if the 
> entry is new to the recipient then its an Invitation, otherwise its a 
> reschedule or an update.  

Then why has EVERYONE  that thinks that you can invite someone
by sending them an instance update guessed incorrectly as to the
example I sent was an update or not? I copied the text verbatim
from iTIP itself. Its not a debate, it is not my opinion,
it was 'verbatim' from iTIP and yet you got the wrong answer.

The only response was when someone called it 'fishy' and somehow
the CUA would know that it is 'fishy' and do a REFRESH. Yet
you and they can not seem to reply or explain how the CUA would know
to do that REFRESH or how to know that it was 'fishy'.

> simple: The need for a distinction derives from the delta models 
> inability to deal with lost or missequenced messages.  The recipient has 
> no way to differentiate a missed reschedule from a new instance 
> invitation.  Thus the only solution for the delta model is to stop all 
> workflow on ALL instances and ask the Organizer for a REFRESH of all 
> instances in question.  There are a couple notable problems w/this 
> design:  

No and please stop mis-quoting me.  The real answer is I copied
the example from ITIP and you guessed the wrong answer because
you could not tell by looking at the object. And you guessed
the wrong answer because you thought it was an initial invitation
to a single instance (Now that is something NOT described in iTIP
at all - that *is* a Bruce invention).

Your CUA and all persons that called the example I sent an initial
invitation to this day would have incorrect data in their CUA because
they did a REPLY to a INSTANCE update and never knew to do the REFRESH.
The objects did not look 'fishy' as someone called it because it
was byte for byte what you called an initial invitation, yet it was
not, it was an instance update copied straight from iTIP. You have been 
misleading people about this and I suspect it is again a legacy problem
you have in your implementation.

> perform NO workflow on ANY instance.  That means NO accepting, 
> declining, counter proposing or delegating; they can safely perform NO 
> action until they recreate all instances w/the correct current 
> RECURRENCE-IDs.  

False - as you can not confuse an initial invitation from an update
in the iTIP model, no such problem exists. Simply not true and
outrageous for your to make that up on the fly.

If you get an update you know you missed something. If you
get an update and you have not got a non-update object, do a REFRESH.

If you get a full object - nothing to miss as you are up to date.

In your model if you get an update you called it an initial invitation
and would have no way to know that it is an update so your
CUA would not know to do a REFRESH - your CU going to miss
meetings. You keep making assertions that that is not true, yet
you can not explain how your CUA would know it is 'fishy'.

Your assertions about workflow have not been posted about using
the iTIP model with distinct update and invitation, it mixed the
fixed model with the non-mixed model and declared that broken.
And yes that example sent was broken.

> 2: Because iTIP cannot guarantee delivery its possible that the 
> Organizers REQUEST never arrives thus the invitee can be indefinitely 
> stuck w/calendar entries that they cannot be sure are still real or not. 
>  Or its possible that the "full REFRESH" never gets to the Organzier so 
> they never have a clue that some invitee needs help...

Simply false and for the same reasons as above. Because the objects
are distinctly updates or distinctly new invitations, then 100% of the time
you can distinctly tell the difference the first object you get.

With your model you have still failed to explain how to tell if
it is 'fishy'.

> RECURRENCE-ID in it; not one with an RRULE or other repeating info in 

Again falsely representing the email that was sent.
Simply not what was said at all.

(1) Send them the object as they need to see it. Done.
(2) There is NO requirement and it HAS been discussed and IS in ITIP
     that you can send distinct objects to unique ATTENDEEs.

>  Sending a REQUEST without a RECURRENCE-ID is not semantically the 
> same as a REQUEST for a single instance;

Yet BYTE for BYTE they are 100% identical in your proposal.
Explain by what magic they are they not semantically the same
and how you your CUA can tell them apart, but on the WG list
you can not and did not know how to tell them apart when sent
samples.

? the recipient will treat it as
> a non-repeating entry when in fact its an instnace of a repeat set.   As
> such adding the invitee to other instances means destroying what they 
> think the UID is and having them recreate a new set of now repeating 
> instances.  This means that even though nothing may have changed about 
> the initial instnace they were invited to, the Organizer MUST resend all 
> the data for the unchanged instance just so the recipient can destroy 
> and recreate it in their calendar as a repeating instance now.  What a 
> waste of bandwidth and cycles!  Plus, iTIP clearly says that 
> RECURRENCE-ID MUST be on the REQUEST when it refers to an instance of a 
> repeat set (check the restriction table if in doubt).

(please submit a real draft so it can be debated)

So in your proposal you can only invite an ATTENDEE to ONE instance
at a time to an existing series? Why not just send them ONE object with all 
the instances they are requested to attend, tailored to that ATTENDEE?

> changing.  But Im not holding my breath just yet...

Bruce - you ether did not read the email that was sent, did not understand
it, or you are intentionally misrepresenting it. No matter what iTIP-next
concludes, there is NO way that a serious evaluation of what was sent
came from you in this email.

--