Subject: Re: Dealing with invites to individual instances

From: [email-masked]
Date: Fri, 22 Aug 2003 12:12:59 -0400

The ONLY TIME  a recurrence-id changes as when you can not map the 
existing set to the new set.
i.e repeats every Monday  becomes repeats every Monday and Thursday.

A reschedule of all the instances in a set is semantically equivalent to 
rescheduling each individual instance, thus the recurrence-id's remain 
fixed.

---

From: Doug Royer <[email-masked]>
Date: Fri, 22 Aug 2003 11:00:05 -0600

> i.e repeats every Monday  becomes repeats every Monday and Thursday.

Are you sure it does not change at random?

> rescheduling each individual instance, thus the recurrence-id's remain 

Can you back that up from any text in any RFC?

-- 

  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: Fri, 22 Aug 2003 11:09:53 -0600

> rescheduling each individual instance, thus the recurrence-id's remain 

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?

--

---

From: [email-masked]
Date: Fri, 22 Aug 2003 13:47:50 -0400

Doug you are insane and should be treated as a spamer.  Don't start this 
again.
See long previous discussion and posting by this group.

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

As long as the reschedule can be treated as semantically equivalent to 
changing instance dates, the original pattern has not changed and thus the 
recurrence-ids do not change.

_____________________
Note: new email address

[email-masked]

Doug Royer <[email-masked]> 
Sent by: [email-masked]
08/22/2003 01:00 PM
Please respond to
"[email-masked]" <[email-masked]>

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

Subject
Re: Dealing with invites to individual instances

--

---

From: Doug Royer <[email-masked]>
Date: Fri, 22 Aug 2003 12:24:59 -0600

[email-masked] wrote:
> 
> *Doug you are insane and should be treated as a spamer.  Don't start 
> this again.*
> *See long previous discussion and posting by this group.*
> 
> *Derik Stenerson *wrote
>  >>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.
> 
> changing instance dates, the original pattern has not changed and thus 
> the recurrence-ids do not change.

Your misreading Franks and Deriks email. They change when the
set changes. And the reason they change is because there is
not a 1:1 mapping all of the time.

When does the SEQUENCE number get bumped? It includes the folowing:

      .  "DTSTART"
      .  "DTEND"
      .  "RDATE"
      .  "RRULE"
      .  "EXDATE"
      .  "EXRULE"

 From the email you cite above it says: "...remains unchanged for
  as long as the base recurrence set (or pattern) exists. ..."

When you change the pattern - IT CHANGES. It has to because
there would be NO way to match them up.

--

---

From: [email-masked]
Date: Fri, 22 Aug 2003 15:36:47 -0400

I Disagree.  The only time you change the recurrence id is when there is 
no 1:1 mapping.  As long as I just reschedule the existing set and do not 
change the RULE,  the 1:1 mapping is preserved.  Thus changing every 
meeting from Monday to Thursday is just a reschedule of the existing 
pattern.  If I have a repeat set on  Mondays and I change this to  Mondays 
and Thursdays, than I have changed the RULE/pattern so that there is no 
1:1 mapping.  In that case, it is equivalent to canceling the original set 
and creating a new set, THUS the recurrence-id's must be reset.  The 
polite iCal would send a Cancel of the original set and a new invitation.
_____________________
Note: new email address

08/22/2003 02:24 PM

To

Subject

      .  "DTSTART"
      .  "DTEND"
      .  "RDATE"
      .  "RRULE"
      .  "EXDATE"
      .  "EXRULE"

--

---

From: Doug Royer <[email-masked]>
Date: Fri, 22 Aug 2003 15:13:16 -0600

[email-masked] wrote:
> no 1:1 mapping.  As long as I just reschedule the existing set and do 
> not change the RULE,  the 1:1 mapping is preserved.  Thus changing every 
> pattern.  If I have a repeat set on  Mondays and I change this to 
>  Mondays and Thursdays, than I have changed the RULE/pattern so that 
> there is no 1:1 mapping.  In that case, it is equivalent to canceling 
> the original set and creating a new set, THUS the recurrence-id's must 
> be reset. 

Thank you for finally agreeing that the RECURRECE-ID does in fact change
and must change in ITIP. And I agree if the only thing that changes
is something that does not change one or more instances, then the
RECURRENCE-IDs do not change. For those the SEQUENCE number might
not be bumped and the only thing the CUA can do then is compare
DTSTAMPs and obsolete the old data.

And it does not matter if you invite one or more ATTENDEEs to one
or more instances. They are exactly the same thing and have exactly
the same problem.

If an instance modificaton is sent to an ATTENDEE then the
RECURRENCE-ID that was modified is changed because it has
to look *exactly* the same as if they have received a full
replacement object which is another valid way to update the
ATTENDEE.

> The polite iCal would send a Cancel of the original set and a 
> new invitation.

I disagree for two reasons:

  (1) The iTIP examples show updates without CANCELs, so that should
      be  sufficient for CUA's to expect them to be updated.

  (2) For ATTENDEEs that are resources, a CANCEL may be catastrophic.
      If for example I book an airline reservation and hotel room
      it could be disastrous to have CANCELed the last room in
      for the conference just because you want to add one day to
      your arrival time.

--

---

From: "Michael Fair" <[email-masked]>
Date: Fri, 22 Aug 2003 15:44:13 -0700

>       for the conference just because you want to add one day to

I also disagree that the polite iCal would necessarily send a cancel
of the original set.

While I don't understand what Doug is referring to in (2), I agree
with Doug about (1).

Simply by providing a description of the updated recurrence set
a CUA can figure out which instances still belong in the set and
which instances don't and cancel/remove the now invalid instances.

The only question that I am dealing with is given that a CANCEL
isn't "usual" for a reschedule REQUEST and is not in iTIP, does
something need to be added to iTIP which says that if a user has
not been invited to the base recurring series and thereby does not
receive a description of the recurrence set (old or new) then
a CANCEL of the old RID MUST be issued along with a REQUEST for
the new RID.

Otherwise, the recipient CUA would have no other way to find out
that the old RECURRENCE-ID is no longer valid.

-- Michael --