Subject: Re: Correct handling of Recurrence-id

From: [email-masked]
Date: Wed, 2 Jul 2003 14:28:03 -0400

Chris wrote on 06/12/2003 04:28:45 PM:
>              I believe that "the most recent version" is the correct 
answer.
> My reasoning is that while RECURRENCE-ID is, if present, part of the 
primary
> key to use in finding an instance, it is only valid when used in 
relation to
> the correct version of the object in question.

I refer to the SEQUENCE:0 RECURRENCE-ID since so far no shipping C&S 
products that do C&S support ADD add or do a good job of 'changing the 
repeat set' so as such they are always '0' based.  There is no SEQUENCE:0 
for an ADDed instance and so far the discussions were foucsed around the 
most common and basic model of invitations and reschedules to the initial 
set.  This is by far the most common set of actions performed in C&S and 
thus relevant to the discussions here.  It is of no value to discuss less 
common paths if they do not work for the more common ones.  Solutions that 
work only for the 20 in the 80/20 rule are of little value to the larger 
80...

Chris seems to espouse a fixed RECURRENCE-ID as being necessary to key to 
the instance (ala UID for finding the set) but then says that a changing 
RID is the way to go.  Its simple to show that its NOT possible to resync 
a particular instance of the set if even 1 reschedule is missed. 

Doug has claimed it can be resyncd and his answer is a "full REFRESH". 
Putting asside the semantic oddities (Organiers do not issue REFRESHes, 
they respond to them), Doug has actually tacitly agreed that a specific 
instance resync is not possible; the entire set must be resync for this 
model to recover.  An expensive proposition for a single missed REQUEST 
(esp. given the "small footprint" preferances of some who like this "send 
it all again" model) by resending the current 'base' defintion plus all 
the current individual instances (esp. if only 1 instance needed to be 
resync'd!).

However, in taking a step back I think that the key to this is a phrase 
that seems to have been misinterpreted by some and misunderstood by 
others.  Doug and George have cited the following as the basis for 
claiming a changing RECURRENCE-ID model:

                                   For a given pair of "UID" and
   "SEQUENCE" property values, the "RECURRENCE-ID" value for a
   recurrence instance is fixed. When the definition of the recurrence
   set for a calendar component changes, and hence the "SEQUENCE"
   property value changes, the "RECURRENCE-ID" for a given recurrence
   instance might also change.

The operative phrase here is "definition of the recurrence set for a 
calendar component changes".  This means when the entrys repeat _set_ 
changes from "Every Monday for 5 weeks" to "Every Thursday and Friday for 
3 months", NOT "When the individual instance is rescheduled to a different 
date/time." 

When an instance itself is rescheduled, its RECURRENCE-ID _does_not_change
_.  This _is_ coherent w/the paragraph previous to the citation in 2445 
and w/the message sequencing and method interpreation sections in iTIP 
because it means the UID/RECURRENCE-ID values do not change with each 
reschedule.  As such a single (or 100) missed reschedules (or CANCELs, 
etc) can be safely ignored and no "full REFRESH" or full resyncs are 
necessary. 

> Please help me understand if this model is broken, and if so, how.

Before we go further I think that its important to realize that the cited 
text for why RECURRENCE-IDs change has been misunderstood/misread by some 
as meaning the RECURRENCE-ID changes whenever the instance is rescheduled. 
 Once we all grasp that it does NOT say that a rescheduling an instance 
means RECURRENCE-ID changes then we can revisit any other confusion folks 
have.  Sound ok??

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: Wed, 2 Jul 2003 14:40:43 -0400

Chris wrote on 06/12/2003 04:28:45 PM:
> > > If later the SEQUENCE gets updated again, the ORGANIZER would send
> > > the SEQUENCE:<next> object and the CUAs REPLY.
> > 
> > This does not address how the CUA would match the changed RECURRENCE-
> > ID to the correct instance in the set.  If the RECURRENCE-ID changed 
> > at each change of SEQUENCE as you claim then the CUA can only 
> > process the latest REQUEST if they have _all_ of the previous 
> > REQUESTs too so they can say "RECURRENCE-ID changes to Wednesday for 
> > SEQUENCE:1.  Now it changes to Thursday for SEQUENCE:2.  Finally it 
> > changes to Friday for SEQUENCE:3". If ANY of the REQUESTs between 
> > SEQUENCE:0 and SEQUENCE:3 are missing then its not possible to 
> > properly determine which Friday instance the Organizer is referring 
> > to.  Right?
> 
> Wrong.  If I got SEQUENCE:0, and then SEQUENCE:3 for UID:xyzzy, I would 
ask
> for a REFRESH of UID:xyzzy, and defer processing until I got SEQUENCE:3 
(or
> greater, but then the SEQUENCE:3 data would be discarded). 

Huh?  If you just got a UID:xyzzy, SEQUENCE:3 REQUEST you would send a 
REFRESH to the Organzier who would send you the SAME REQUEST back which 
you would then process?  If you get the same (or a higher) REQUEST in 
response to the REFRESH then what have you learned new?  Nothing?  If you 
can act on the 2nd REQUEST w/the exact same info (assuming SEQUENCE:3 
here) then why couldnt you act on the 1st REQUEST?  Sorry but I must be 
missing something here...

Since rescheduling an individual instance means changing its SEQUENCE 
value then by using UID then SEQUENCE you effectively tie all instances to 
a single SEQUENCE value.  Surely you did not mean for that to happen.  If 
so, do you realize that it means rescheduling 1 instance means that you 
invalidate all the workflow to all other instances even though they have 
not changed??

Doug is saying that RECURRNECE-ID changes with _each_ reschedule of the 
instance.  Chris seems to agree w/him but  some of the the stuff he 
describes sounds like a fixed RECURRENCE-ID that can be used as like a key 
to find the instance once you "know the SEQUENCE" (my term, not Chriss') 
so you can do workflow on the instances.  Thats not possible with SEQUENCE 
since thats not the meaning of SEQUENCE.

Bruce

---

From: Doug Royer <[email-masked]>
Date: Wed, 02 Jul 2003 16:26:54 -0600

[email-masked] wrote:

> instance. 

No but almost, it is tied to the latest SEQUENCE.

-- 

  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, 02 Jul 2003 16:24:20 -0600

[email-masked] wrote:
> repeat set' so as such they are always '0' based.

> There is no SEQUENCE:0 for an ADDed instance ...

True an no one has said there is that I can find in the archives.

 > ...and so far the discussions were foucsed
> around the most common and basic model of invitations and reschedules to 
> the initial set.

I have not seen any one claim that including you in the debate.
But assuming it is - so what?

 > This is by far the most common set of actions
> performed in C&S and thus relevant to the discussions here.  It is of no 
> value to discuss less common paths if they do not work for the more 
> common ones.  Solutions that work only for the 20 in the 80/20 rule are 
> of little value to the larger 80...

And by the word 'this' do you mean doing it your way, or rescheduling?

And when there is a way to make it work 100% of the time?

> Chris seems to espouse a fixed RECURRENCE-ID as being necessary to key 
> to the instance (ala UID for finding the set) but then says that a 
> changing RID is the way to go.  Its simple to show that its NOT possible 
> to resync a particular instance of the set if even 1 reschedule is 
> missed.  

No, there has been no such proof offered. If the ATTENDEE can't
figure it out, they do a full REFRESH and they are back in sync.

> Doug has claimed it can be resyncd and his answer is a "full REFRESH". 

Yes, per the text in iTIP.

> they respond to them),

I have made NO such claim and I have told you that I have made
no such claim.

> Doug has actually tacitly agreed that a specific 
> instance resync is not possible;

No, I said when that happens the attendee must do a full REFRESH.

> the entire set must be resync for this 
> model to recover. 

In your model if an newly invited ATTENDEE would not have
a clue what recurrence-id:x is if is all they get is a
instance change. They also must do a full REFRESH. That
is exactly the same problem as if they get out of sync.
Except in your model you said throw the UID away if the
RRULE, RDATE, EXRULE, or EXDATE change, forcing EVERYONE
to have to reply to a new REQUEST.

> An expensive proposition for a single missed REQUEST 
> (esp. given the "small footprint" preferances of some who like this 
> "send it all again" model) by resending the current 'base' defintion 
> plus all the current individual instances (esp. if only 1 instance 
> needed to be resync'd!).

So how is one attendee doing a full REFRESH more expensive than
them never having SEQUENCE:0 and asking for a full REFRESH?

If they miss one of the single instance recurrence updates, then
they will also have to do a full REFRESH as no matter how many
times they do a single instance REFRESH, if that instance did
not exist in their copy of the object, they will not get anything
useful - they MUST do a full REFRESH ether way. Its a wash.

> changes from "Every Monday for 5 weeks" to "Every Thursday and Friday 
> for 3 months", NOT "When the individual instance is rescheduled to a 
> different date/time."  
> 
> When an instance itself is rescheduled, its RECURRENCE-ID 
> _does_not_change_.  This _is_ coherent w/the paragraph previous to the 
> citation in 2445 and w/the message sequencing and method interpreation 
> sections in iTIP because it means the UID/RECURRENCE-ID values do not 
> change with each reschedule.  As such a single (or 100) missed 
> reschedules (or CANCELs, etc) can be safely ignored and no "full 
> REFRESH" or full resyncs are necessary.  

So if two or more instances need to change, you do what? (a) Issue
a bunch of single instance changes and handle multiple REPLYs
to/from EACH attendee? (b) Do you issue a FULL REQUEST which WILL
change the recurrence rules? (c) Or do you throw the UID away if you
need to change the RRULE, RDATE, EXRULE, or EXDATE as you have
stated in previous email to this list?

Given:

	I == Instances that change (instance REQUEST message).
	A == Number of attendees.
         C == A CANCEL message
         R == A full REQUEST
       SET == one data blob from the ORGANIZER plus ONE blob from ATTENDEE.
         F == Number of REFRESH requests.

(a) Will generate (I * A) objects in (A) communications SETs.
(a.1) Plus (F * A) objects *IF* any attendee is out of sync in (A)
     communication sets.

(b) Will generate (A) objects in (A) communication SETs.

(c) WIll generate (C * A) in (A) communication SETs.
     Plus (A * R) in (A) communication SETs.

Which one is more expensive? I would go with (B).

The above is more complex to calculate when you only send
objects when you know which ATTENDEE has replied to which
SEQUENCES, as you can optimize out several of the (a)
objects and eliminate (a.1). Or eliminate some of the (b)
steps if you know it does not effect some ATTENDEES.
(c) can not be optimized.

> Before we go further I think that its important to realize that the 
> cited text for why RECURRENCE-IDs change has been misunderstood/misread 
> by some as meaning the RECURRENCE-ID changes whenever the instance is 
> rescheduled.  Once we all grasp that it does NOT say that a rescheduling 
> an instance means RECURRENCE-ID changes then we can revisit any other 
> confusion folks have.  Sound ok??

So are you claiming that if I do a reschedule as described in iTIP
"4.4.7 Add A New Series of Instances To A Recurring Event" that
the 'instances' do not change in the example after the paragraph
that starts with:

    The next series of examples illustrate how an "Organizer" would
    respond to a "REFRESH" submitted by an "Attendee" after a series of
    instance-specific modifications. To convey all instance-specific
    changes, the "Organizer" must provide the latest event description
    and the relevant instances. The first three examples show the history
    including the initial "VEVENT" request and subsequent instance
    changes and finally the "REFRESH".

Note the words 'instance changes' above.

    < followed by example changing the 'instance >

Summary of steps in that example:

   (a) The first example after the above paragraph is the original SEQUENCE:0
       object.

   (b) The ORGANIZER changes ONE instance (TIME-A to TIME-B) and the
       SEQUENCE becomes '1' as shown in the iTIP text.

   (c) The ORGANIZER ADD's ONE instance (TIME-C) . The SEQUENCE is now '2'
       as shown in the iTIP text.

   (d) The ATTENDEE does a full REFRESH and gets back the SEQUENCE:2 object.

At this point a NEW attendee would only get SEQUENCE:2 objects back
from the ORGANIZER on REFRESH. And all NEW ATTENDEES would get
a SEQUENCE:2 REQUEST to join.

If the recurence-id were tied to the 'original' object as you claim,
then ALL new ATTENDEEs would be UNABLE to reschedule single instances
which have start times not in SEQUENCE:2 (TIME-A in this example) and
would be FORCED to do a full REFRESH on each and every single
instance REQUEST in that case using your model.

Now let say the the ORGANIZER needs to re-schedule the instance added
in (c) (TIME-C to TIME-E). Lets call this step (e). We are now at SEQUENCE:3.

And lets also say that that step (e) has LOCATION:Room B in it.

Now what *if* just by chance that the 'instance' added in (c) [SEQUENCE:2,
TIME-C] just happened to have a start time the same as the (a) instance
[SEQUENE:0, TIME-A] (TIME-C coincidentally was the SAME as TIME-A)
that was rescheduled in (b) [SEQUENCE:1 to TIME-B].

Which instance data has changed in step (e) and which LOCATION is
the meeting in? Simple, it is the SEQUENCE:3/TIME-E instance in
'Room B' and NOT the SEQUENCE:0/TIME-A instance that was changed to a
SEQUENCE:2/TIME-B and SEQUENCE:3/TIME-B instance in 'Conference Room A'
that just coincidentally had the same same start time. The RECURRENCE-ID
is tied to the SEQUENCE number and NOT to the original object
or over time long standing meeting that get rescheduled are going
to be a mess or impossible to reschedule.

Now what if the ATTENDEE missed (b), they would have
instead reschedule the (a) instance to (e). And would
not know about the (b) change. So the ATTENDEE MUST
track instances to SEQUENCE and if all of the SEQUENCEs
have not been received between the last full REQUEST
and a specific instance update - They MUST do a full REFRESH
else they would not have a clue.

You have NOT shown that anything is busted. And you model
breaks when as shown in this example when there have been
updates that change the instances to a previous SEQUENCE
instance (TIME-A == TIME-E in this example).

--

---

From: [email-masked]
Date: Thu, 3 Jul 2003 16:22:44 -0400

> No but almost, it is tied to the latest SEQUENCE.

Ok, help me out here then. 

Since the SEQUENCE is changed with each reschedule of the instance then 
each time a higher SEQUENCE becomes "the latest" doesn't the RECURRENCE-ID 
also change?  Back on May 20th you replied:

If SEQUENCE:1 has an instance of MONDAY      <- ORIGINAL
And you say yes (book it).

If SEQUENCE:2 changes the MONDAY instance to TUESDAY <- UPDATE '1'
And you say yes (book it)

If SEQUENCE:3 uses the RECURRANCE-ID of MONDAY  <- UPDATE '2'
  Nothing matches - the sending CUA is busted.

UPDATE '2' MUST use the RECURRANCE-ID of the UPDATE '1'
instance (currently booked entry), not the original.

So how does that different from "RECURRENCE-ID changes with each 
reschedule of the instance"?  Each update (at the next higher SEQUENCE) 
"MUST use the RECURRANCE-ID" of the previous update.  That sound like what 
I said...

Bruce

---

From: Doug Royer <[email-masked]>
Date: Thu, 03 Jul 2003 14:59:27 -0600

[email-masked] wrote:
> Ok, help me out here then.   ..
> 
> "MUST use the RECURRANCE-ID" of the previous update.  That sound like 
> what I said...

The difference is simply my assertion that RECURRENCE-ID is tied to SEQUENCE.
A reschedule is only one of the reasons that SEQUENCE changes.

---

From: [email-masked]
Date: Thu, 3 Jul 2003 17:49:39 -0400

> But assuming it is - so what?

The point is to put misinterpretations to rest and get on with other WG 
business.  I just do not want some folks misinterpreation of the RFCs to 
become contagious causing us no end of grief to those that read the RFCs 
correctly.

Lets get back to the facts of this shall we:

1: iCalendar clearly says that RECURRENCE-ID does not change on a 
reschedule.  For those that missed it the last 4 times:

   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.

2: iCalendar has been misquoted/misread by some as saying that the 
RECURRENCE-ID does change on a reschedule.  The misunderstanding stems 
from:

   The "RECURRENCE-ID" property is used in conjunction with the "UID"
   and "SEQUENCE" property to identify a particular instance of a
   recurring event, to-do or journal. For a given pair of "UID" and
   "SEQUENCE" property values, the "RECURRENCE-ID" value for a
   recurrence instance is fixed. When the definition of the recurrence
   set for a calendar component changes, and hence the "SEQUENCE"
   property value changes, the "RECURRENCE-ID" for a given recurrence
   instance might also change.

which says that RECURRENCE-ID "might also change" but ONLY for the case 
where "the definition of the recurrence set for a calendar component 
changes".  A reschedule of an entry in the recurrence (aka repeat) set is 
NOT changing the set definition!  Changing the definition is going from 
repeating "Every Monday for 3 weeks" to "Every Wednesday and Thursday for 
2 months" (or some other pattern).  Sounds like confusion on the part of 
some between the two.

3: iTIP does not describe changing the RECURRENCE-ID value on a reschedule 
depsite instances to the contrary.  Section 4.7.2 Bad RECURRENCE-ID says:

   1.  The component with the referenced "UID" and "RECURRENCE-ID" has
       been found but the "SEQUENCE" number in the calendar store does
       not match that of the ITIP message.

In order for the UID and RECURRENCE-ID  to match but the SEQUENCE to be 
"larger" or "smaller" then obviously UID and RECURRENCE-ID cannot be 
changed when SEQUENCE changes or they would never match the correct 
instance in question.

Section 2.1.5 Message Sequencing clearly states that UID and RECURRENCE-ID 
are to be used as the primary key when sequencing any iTIP message for a 
particular repeating instance.  They are to be combined into a key to find 
the particular instance and then SEQUENCE is to be looked for (as 
described in Section 4.7.2 bullet 1 even).  Missed messages at lower 
SEQUENCE values are irrelevant because they are obsoleted by the newer 
SEQUENCE versions.  As such missed messages are not a problem for workflow 
(unless you need them to change the RECURRENCE-ID values).

Section 3.2.2 REQUEST clearly describes how to differentiate between a new 
request and a reschedule of an existing one.  If RECURRENCE-ID changed on 
each reschedule then it would be impossible to match it to an existing 
entry correctly. 

Any attempts to change the model so that RECURRENCE-ID changes on each 
reschedule is either a misinterpretation of the RFCs or an attempt to 
change their behaviour that is clearly outlined otherwise. 

Bruce

---

From: [email-masked]
Date: Thu, 3 Jul 2003 17:59:47 -0400

> Yes, per the text in iTIP.

There is no phrase "full REFRESH" in iTIP that I can find.  There is an 
iTIP REFRESH message that can contain the following properties:

METHOD              1      MUST be "REFRESH"

VEVENT              1
    ATTENDEE        1      MUST be the address of requestor
    DTSTAMP         1
    ORGANIZER       1
    UID             1      MUST be the UID associated with original
                           REQUEST
    COMMENT         0 or 1
    RECURRENCE-ID   0 or 1 MUST only if referring to an instance of a
                           recurring calendar component.  Otherwise
                           it must NOT be present.
    X-PROPERTY      0+

Since Ive been referring to resycing up a particular instance Ive been 
talking about sending a REFRESH for that particular RECURRENCE-ID (as 
described in the defintion of REFRESH).

I can only find 1 instance of the phrase 'full' in iTIP and thats NOT in 
REFESH (besides "Full Copyright"). It is in ADD:

                                                   Unlike the "REQUEST"
   method, when using issuing an "ADD" method, the "Organizer" does not
   send the full "VEVENT" description; only the new instance(s).

so thats clearly not what Doug is referring to.

Arnaud asked if Doug was referring to a REFRESH message that had no 
RECURRENCE-ID and I thought he said yes.  However he later said no when I 
checked.  The definition for REFRESH says:

                                         A recurrence instance of an
   event may be requested by specifying the "RECURRENCE-ID" property
   corresponding to the associated event. The "Organizer" responds with
   the latest description and version of the event.

and the restriction table clearly says "MUST only if referring to an 
instance" (which we were or at least I was since I had an particular 
RECURRENCE-ID I need to REFRESH for). 

Since the REQUEST was for a single instance (thats all I was invited to) 
then the REQUEST the Organzier sends in response must also contain a 
RECURRENCE-ID so we can be sure all REQUEST/REPLYs are relevant to the 
same instance and not the repeat set as a whole.

In any case I view some of this as moot given the fact that nothing in 
iCalendar or iTIP supports the claim that RECURRENCE-IDs change on each 
instance reschedule...

Bruce

---

From: Doug Royer <[email-masked]>
Date: Thu, 03 Jul 2003 16:53:28 -0600

[email-masked] wrote:
> There is no phrase "full REFRESH" in iTIP that I can find.

Your correct bruce, but we have been using that term
ever since Arnaud (I think) pointed out there was
a misunderstand about what a REFRESH vs. instance
specific REFRESH.

Perhaps you mised that post?

--

---

From: Doug Royer <[email-masked]>
Date: Thu, 03 Jul 2003 17:19:00 -0600

> iCalendar or iTIP supports the claim that RECURRENCE-IDs change on each 

I have quoted it several times from iCal where is says that the
UID and SEQUENCE property identify a particular instance (3rd
paragraph below). And one reason to increment the SEQUENCE number
is a recurrence change. If the organizer is at SEQUENCE:X for
a given UID and it gets a REPLY for less than X, it (if it has
not already done so) needs to issue a new REQUEST/SEQUNCE:X to
that attendee. If an ATTENDEE has SEQUENCE:W where W < X,
and gets an instance specific update for SEQUENCE:X,
then the attendee needs to do a REFRESH, the attendee can
toss the instance specific update and wait for the REQUEST
(REFRESH reply) from the ORGANIZER.

The text is in iCal is clear, the UID+SEQUENCE pair identify
a particular instance (RECURRENCE-ID).

  4.8.4.4 Recurrence ID

    Property Name: RECURRENCE-ID

    Purpose: This property is used in conjunction with the "UID" and
    "SEQUENCE" property to identify a specific instance of a recurring
    "VEVENT", "VTODO" or "VJOURNAL" calendar component. The property
    value is the effective value of the "DTSTART" property of the
    recurrence instance.

    ...

    Description: The full range of calendar components specified by a
    recurrence set is referenced by referring to just the "UID" property
    value corresponding to the calendar component. The "RECURRENCE-ID"
    property allows the reference to an individual instance within the
    recurrence set.

    ...The "RECURRENCE-ID" property is used in conjunction with the "UID"
    and "SEQUENCE" property to identify a particular instance of a
    recurring event, to-do or journal. For a given pair of "UID" and
    "SEQUENCE" property values, the "RECURRENCE-ID" value for a
    recurrence instance is fixed..

    ...When the definition of the recurrence
    set for a calendar component changes, and hence the "SEQUENCE"
    property value changes, the "RECURRENCE-ID" for a given recurrence
    instance might also change. ...

--

---

From: [email-masked]
Date: Mon, 7 Jul 2003 17:49:19 -0400

> paragraph below). 

Doug may have quoted the iCalendar text but he seems to be overlooking 
some inconvenient prose and misinterpreting other bits.

Lets get this straight once and for all shall we.  iCalendar Section 
4.8.4.4 Recurrence ID describes the property with:

   If the value of the "DTSTART" property is a DATE type value, then the
   value MUST be the calendar date for the recurrence instance.

   The "RECURRENCE-ID" property is used in conjunction with the "UID"
   and "SEQUENCE" property to identify a particular instance of a
   recurring event, to-do or journal. For a given pair of "UID" and
   "SEQUENCE" property values, the "RECURRENCE-ID" value for a
   recurrence instance is fixed. When the definition of the recurrence
   set for a calendar component changes, and hence the "SEQUENCE"
   property value changes, the "RECURRENCE-ID" for a given recurrence
   instance might also change.The "RANGE" parameter is used to specify
   the effective range of recurrence instances from the instance
   specified by the "RECURRENCE-ID" property value. The default value
   for the range parameter is the single recurrence instance only. The
   value can also be "THISANDPRIOR" to indicate a range defined by the
   given recurrence instance and all prior instances or the value can be
   "THISANDFUTURE" to indicate a range defined by the given recurrence
   instance and all subsequent instances.

Now, lets reread the 3rd paragraph again:

This paragraph expressly says that the RECURRENCE-ID value "is still set 
to the original" value AFTER the reschedule occurs.  "The date/time value 
is set to the time when the original recurrence instance would occur" 
clearly says "original recurrence instance" and not "latest recurrence 
instance" or "most recent" value.  No amout of misreading or 
misinterpretation can overcome this.

Now the next paragraph clearly defines the case where RECURRENCE-ID "might 
also change" with the prose:

                               When the definition of the recurrence
   set for a calendar component changes, and hence the "SEQUENCE"
   property value changes, the "RECURRENCE-ID" for a given recurrence
   instance might also change.

Rescheduling an instance to a different date/time is just that, a 
reschedule.  It is not recreating the instances in the set which is what "
When the definition of the recurrence set for a calendar component changes
" means.

>                    And one reason to increment the SEQUENCE number
> is a recurrence change. 

Corect but incrementing the SEQUENCE property does NOT mean that the 
recurrence definition has changed.

>                If an ATTENDEE has SEQUENCE:W where W < X,

This does not follow from reading the RFCs.  You are not applying the iTIP 
Section 2.1.5 rules for message sequencing to the REQUEST and you are 
misapplying the example from iTIP Section 4.7.2. 

The invite uses the UID/RECURRENCE-ID as the primary key to indentify the 
instance to see if they have it already or not. 

A: If they find the UID/RECURRENCE-ID pair THEN they use SEQUENCE to tell 
if W<X or not.  There are 3 possible cases at this point:
        1: W<X therefore the new REQUEST "obsoletes" the existing one and 
the invitee can take some action on it.
        2: W=X therefore the next rule regarding using DTSTAMP needs to be 
applyed to the REQUEST to determine if something should take place.
        3: W>X therefore the new REQUEST is obsolete since the one the 
invitee already has is higher.  This jives with Dougs cited Section 4.7.2 
bullet 1.
B: If they do not find the UID/RECURRENCE-ID pair then its a new instance 
(per iTIP Section 3.2.2 REQUEST) and there is no need to check SEQUENCE 
(or DTSTAMP).

The invitee simply treats it as a new invitation to a new instance.  No 
need to ask for a REFRESH.  The REQUEST is new and the invitee can take 
immediate action on it.

If you read the description for bullet 1 in iTIP Section 4.7.2 it clearly 
talks about using UID/RECURRENCE-ID and SEQUENCE:

   In case (1), two things can happen. If the "SEQUENCE" number of the
   "Attendee's" instance is larger than that in the "Organizer's"
   message then the "Attendee" is receiving an out-of-sequence message
   and MUST ignore it.  If the "SEQUENCE" number of the "Attendee's"
   instance is smaller, then the "Organizer" is sending out a newer
   version of the component and the "Attendee's" version needs to be
   updated

In order for the invitee to be able to find the UID/RECURRENCE-ID pair at 
a level other than "1 off" from the current SEQUENCE the values MUST stay 
fixed.  Otherwise its not possible to match them and then compare SEQUENCE 
values of X and W if W != X - 1.  Clearly the values of UID/RECURRENCE-ID 
MUST stay "fixed" so that SEQUENCE checks can properly detect "larger" or 
"smaller" otherwise this "larger" or "smaller" check is just not possible.

>     instance might also change. ...

I noticed that the cited description did NOT contain the paragraph that 
clearly described that RECURRENCE-ID did not change on a reschedule. 

Also, as I noted before a reschedule is not a change to the "definition of 
the recurrence _set_".  Its a change to an instance _in_ the set!

Bruce

---

From: Doug Royer <[email-masked]>
Date: Mon, 07 Jul 2003 17:03:44 -0600

[email-masked] wrote:

> to the original" value AFTER the reschedule occurs.  ...

Orignal means the value of the object you are changing FROM.
It does not mean the value of SEQUENCE:0

You set the RECURRENCE-ID to the effective DTSTART time
of the instance you are change from which is NOT always SEQUENCE:0.

The "the date/time is still set to the original Friday meeting." is
refering to the value of the RECURRENCE-ID in the object that causes
the RECURRENCE-ID  to change in the next SEQUENCE.

  To change an instance, set the RECURRENE-ID to the 'was' value.
                         set the DTSTART to the 'is now' value.
                         And you supply the NEW  SEQUENCE number

After that object is processed the effective dtstart value
is now the value supplied in the DTSTART of the update object,
not the pre-updated (orignal) object. And the effective dtstart
time is the 'RECURRENCE-ID'.

 > to the original" value AFTER the reschedule occurs. ...

If you want update DTSTART:FRIDAY / SEQUENCE:3
                 to DTSTART:FRIDAY / SEQUENCE:4

Then provide the SEQUENCE:3 / DTSTART:FRIDAY recurrance-id
and the new DTSTART:value of THURSDAY and SEQUENCE:4.
And the examples in iTIP:

    An instance of a recurring event is assigned a unique identification,
    "RECURRENCE-ID" property, when that instance is renegotiated.
    Negotiation may be necessary when a substantive change to the event
    or to-do has be made (such as changing the start time, end time, due
    date or location). The "Organizer" can identify a specific recurrence
    instance using the "RECURRENCE-ID" property. The property value is
    equal to the date/time of the instance. If the "Organizer" wishes to
    change the "DTSTART", the original "DTSTART" value is used for
    "RECURRENCE-ID" property and the new "DTSTART" and "DTEND" values
    reflect the change.  Note that after the change has occurred, the
    "RECURRENCE-ID" has changed to the new "DTSTART" value.

Note that RECURRENEC-ID 'has changed to the new "DTSTART" value.'
And the word 'original' does NOT mean SEQUENCE:0, it means the
original value prior to the change.

--

---

From: Doug Royer <[email-masked]>
Date: Mon, 07 Jul 2003 17:11:55 -0600

[email-masked] wrote:

> In order for the invitee to be able to find the UID/RECURRENCE-ID pair 
> at a level other than "1 off" from the current SEQUENCE the values MUST 
> stay fixed.  Otherwise its not possible to match them and then compare 
> SEQUENCE values of X and W if W != X - 1.  Clearly the values of 
> UID/RECURRENCE-ID MUST stay "fixed" so that SEQUENCE checks can properly 
> detect "larger" or "smaller" otherwise this "larger" or "smaller" check 
> is just not possible.

If they do not equal and you are the ORGANIZER - then throw
away their REPLY and generate them a new REQUEST as they do
not have a clue what they are replying to. If they send you
are REPLY that is less than the current object SEQUENCE, they
are replying to old news anyway - no matter which model you use.

If you get an instance specific update for SEQUENCE:x and you are an
ATTENDEE and you have SEQUENCE:z (where z <= (x-2)), then DO a REFRESH
as you do not have a clue what SEQUENCE (x-1) is at all and no matter
what model you use for RECURRENCE-ID, they will need to do a REFRESH.

If you get an instance specific update for SEQUENCE:x and you are an
ATTENDEE and you have SEQUENCE:z (where z = (x-1), Then you DO
have the latest object and can apply the instance change.

--

---

From: Doug Royer <[email-masked]>
Date: Mon, 07 Jul 2003 17:17:48 -0600

> clearly described that RECURRENCE-ID did not change on a reschedule.

I noticed that no such text exists in "4.8.4.4 Recurrence ID" which
is why I did not quote it :-)

--

---

From: [email-masked]
Date: Tue, 8 Jul 2003 10:43:17 -0400

Doug wrote on 07/07/2003 07:11:55 PM:
> not have a clue what they are replying to. 

You absolutely DO if the RECURRENCE-ID is fixed.  You absolutely DO NOT if 
the RECURRENCE-ID changed on each reschedule.  However the latter case is 
contrary to the RFC where a fixed RECURRENCE-ID is clearly described:

If RECURRENCE-ID were NOT fixed then the only solution would be to rescyc 
ALL instances the invitee was invited too, not just the one in question.

With a fixed RECURRENCE-ID identifying the exact instance in question is 
trival (its part of the primary key used to find the instance) and thus 
the Organizer can quickly and easily just send a newer REQUEST for that 
particular instance.  No need to rewrite all instances the invitee has 
been invited to.  No need to resend all that extra data.

>                                            If they send you

We have been talking about instance specific workflow but your phrase 
"current object SEQUENCE" has lots of loaded and undefined meaning. 

Each instance in the set has its own SEQUENCE value (thats how workflow 
for each instance can proceeded independent of all the other instances!). 
SEQUENCE is NOT shared among all the instances because if you did that 
then ANY reschedule of ANY single instance would raise the shared SEQUENCE 
value and invalidate ALL workflow for ALL other instances in the set. 

That generates TONS of extra wasted workflow messaging and renegotation. 
It also does NOT jive with the way message sequencing works in 2446.  If 
the UID/RECURRENCE-ID are the primary keys to find the instance (per rule 
1 in Section 2.1.5 in iTIP) and SEQUENCE is the secondary key (per rule 2) 
then clearly each instance MUST have its own SEQUENCE value.

So can you please clearly describe what you mean be "the current object 
SEQUENCE" because it sounds like it means each instance in the recurrence 
set shares the same SEQUENCE value...

> what model you use for RECURRENCE-ID, they will need to do a REFRESH.

Sorry but thats patently NOT true; its ONLY true for the case of a 
RECURRENCE-ID that changs on each reschedule (which is clearly contrary to 
the text from 2445 at top!)

If the RECURRENCE-ID is fixed then you have no doubt that it refers to the 
same RECURRENCE-ID you have but at a lower or higher SEQUENCE value.  You 
use the UID/RECURRENCE-ID to find the instance and then you check the 
SEQUENCE value. 

As iTIP clearly describes in 2 places its NOT an issue if you missed any 
intermediate REQUESTs since:

                                                              the
       component with the highest numeric value for the "SEQUENCE"
       property obsoletes all other revisions of the component with
       lower values.

That means if find the correct instance and detect that your SEQUENCE is 1 
or 2 or 100 below the one in the REQUEST then your copy is clearly 
obsolete.  NO need for a REFRESH as the REQUEST is a complete snapshot of 
that instance at that SEQUENCE value.  You simply accept, decline, etc and 
save away the new information.  Now if you are still thinking that Section 
4.7.2 of iTIP justifys the need to do a REFRESH because it says:

                      If the "SEQUENCE" number of the "Attendee's"
   instance is smaller, then the "Organizer" is sending out a newer
   version of the component and the "Attendee's" version needs to be
   updated. Since one or more updates have been missed, the "Attendee"
   SHOULD send a "REFRESH" message to the "Organizer" to get an updated
   version of the event.

then you need to consider some facts:

1:  In order for the UID/RECURRENCE-ID to match so you can do the SEQUENCE 
check of "larger" or "smaller" then clearly UID & RECURRENCE-ID  have to 
remain fixed!  Otherwise you cannot match the UID and RECURRENCE-ID values 
to the correct instance in question to do the SEQUENCE check.

2: As noted by Section 2.1.5 a higher SEQUENCE "obsoletes" all lower 
SEQUENCE values and this agrees when it says that the invitees "version 
needs to be updated.".  However since each REFRESH is a complete snapshot 
we no longer have to worry about missed "updates" because we no longer 
need them.  This was another benefit of going to full snapshots on 
REQUESTs from the early model of rolling changes forward (akin to changing 
the RECURRENCE-ID on each reschedule).  The new REQUEST obsoletes any 
lower SEQUENCE valued info, plain and simple.  No need to worry about 
missed updates, unless of course you try to ignore 2445 and change 
RECURRENCE-ID each time you reschedule.

3: The only way to recover a missed reschedule REQUEST is to resync ALL 
instances; you cannot just resync a single instance if RECURRENCE-ID 
changes.  Lots of wasted bandwidth and workflow thrashing.  However the 
text clearly says "SHOULD send a "REFRESH"" and NOT "MUST send a "REFRESH" 
to the Organzier.  In the delta model of RECURRENCE-IDs it would have to 
be a MUST in order to restore order.  SHOULD would not cut it.

> have the latest object and can apply the instance change.

The new REQUEST does NOT mean that you change the RECURRENCE-ID.  Thats 
contrary to 2445 no matter how you try to read bits of 2446. 

Bruce

---

From: Doug Royer <[email-masked]>
Date: Tue, 08 Jul 2003 20:21:50 -0600

[email-masked] wrote:
> You absolutely DO if the RECURRENCE-ID is fixed.  You absolutely DO NOT 
> if the RECURRENCE-ID changed on each reschedule.

My reply was to your single instance REQUEST, NOT a full REQUEST.
Your points (deleted) because we agree that if you get a FULL
REQUEST you do not need to do an REFRESH.

And I think we agree, if you get a single instance change,
and you are (>=2) lower than that SEQUENCE value in the object,
the ATTENDEE must do a REFRESH no matter what the model.

--

---

From: [email-masked]
Date: Wed, 9 Jul 2003 10:58:29 -0400

> REQUEST you do not need to do an REFRESH.

We also agree that the stale REPLY needs to be ignored and a new REQUEST 
needs to be sent.  However I was taking about a REPLY to a particular 
instance and we were only talking about an instance REQUEST.

If the RECURRENCE-ID changed on each reschedule then the Organizer has NO 
consistant and reliable way to match stale REPLYs ( UID / RECURRENCE-ID / 
(older) SEQUENCE ) to the proper current instance unless they track all 
UID / RECURRENCE-ID / SEQUENCE combos and can properly indentify the 
instance in question.  However as I showed using just 5 steps, at some 
point in time 2 instances can share the same UID / RECURRENCE-ID / 
SEQUENCE values thus this possible mechansim is not consistantly reliable. 
 As such a REPLY that the Organizer gets is not uniquely matachable to the 
instance the invitee was REPLYing to and the Orgaizer has no accurate way 
to decide which instance to send the new REQUEST for.

With a fixed RECURRENCE-ID, the Organizer can unambiguously tell exactly 
which instance the stale REPLY was for and send out the proper new 
REQUEST.  They simply match the UID & RECURRENCE-ID to find the instance 
and then check the SEQUENCE value.  If its different then the Organizer 
must not process the REPLY and sends the instances current defintion in a 
new REQUEST.  No fumbling.  No guessing.  No mis-matching.

> the ATTENDEE must do a REFRESH no matter what the model.

Sorry but I never said that nor do I agree with that.  In fact Ive said 
that its not necessary when you use fixed RECURRENCE-IDs.

Accepting your suggestion supposes that I accept that RECURRENCE-ID 
changes on each reschedule which I do not.  Thats because 2445 clearly 
says otherwise in no uncertain terms.  Thats also because it makes 
applying the iTIP rules on Message Sequencing, etc impossible!  If the 
primary key used to find the instance changes on each action then the key 
is no good for finding the instance and ordering the changes! 

In addition, the iTIP section you referred to only say "SHOULD" (not 
"must") because "one or more updates have been missed".  However since 
each REQUEST is a full snapshot missed updates are irrelevant since the 
would be obsoleted anyway at the higher SEQUENCE.  In addition if you read 
the description for the cases it should be clear that the only way for the 
UID/RECURRENCE-ID to match so that you can do a "higher" or "lower" 
SEQUENCE check is if UID and RECURRENCE-ID do not change.

Finally, since higher SEQUENCE versions obsolete lower SEQUENCE versions 
and each REQUEST is a fully defintion of that instance then _WHY_ would I 
need to do a REFRESH (full or otherwise) for the >=2 case?  The  REQUEST I 
just got simply "obsoletes" what I have currently and therefore I can 
safely take some action on it such as REPLYing.  I can safely and simply 
ignore the missed (or delayed) SEQUENCE+1 case since the REQUEST Im 
currently parsing is newer and has obsoleted the missed or delayed 
REQUEST.

Bruce

---

From: Doug Royer <[email-masked]>
Date: Wed, 09 Jul 2003 11:03:41 -0600

[email-masked] wrote:
> If the RECURRENCE-ID changed on each reschedule then the Organizer has 
> NO consistant and reliable way to match stale REPLYs ( UID / 
> RECURRENCE-ID / (older) SEQUENCE ) to the proper current instance unless 
> they track all UID / RECURRENCE-ID / SEQUENCE combos and can properly 
> indentify the instance in question.  However as I showed using just 5 
> steps, at some point in time 2 instances can share the same UID / 
> RECURRENCE-ID / SEQUENCE values thus this possible mechansim is not 
> consistantly reliable.  As such a REPLY that the Organizer gets is not 
> uniquely matachable to the instance the invitee was REPLYing to and the 
> Orgaizer has no accurate way to decide which instance to send the new 
> REQUEST for.

As ALL REPLYs contain the SEQUENCE number they are replying to.
And ALL REQUESTS that change any recurrence date MUST bump the SEQUENCE
number. Then why can't you match them up as no matter what, they
must equal.
If the SEQUENCE number is OLD in a REPLY to a single instance change.
Send them the new REQUEST. Also note that in iTIP - ALL such text and
examples show that a single instance updates - bumps the SEQUENCE number.
So in ALL cases the SEQUENCE in the REPLY MUST match the SEQUENCE in
the REQUEST (single or full update).

If the ORGANIZER changes an instance twice, then the SEQUENCE number
gets bumped twice and the REPLY to each of those single instance updates
MUST have matching SEQUENCE numbers. It is ALWAYS reliable as they MUST
match ALL of the time.

There is NO difference between single and full updates with respect
to the SEQUENCE number, they both update the sequence number.

> must not process the REPLY and sends the instances current defintion in 
> a new REQUEST.  No fumbling.  No guessing.  No mis-matching.
> 
> Sorry but I never said that nor do I agree with that.  

> says otherwise in no uncertain terms. 

Only when you ignore all of the other text in iCAL and iTIP that
clearly and specifically disagrees with you.

Sequence of events. Assume your conflicting dates issue:
Assume ALL of the instance changes are for conflicting
dates/times.

	ORGANIZER sends a SINGLE instance update, SEQUENCE:3
	to ATTENDEE:a

	ORGANIZER sends a second SINGLE instance update, SEQUENEC:4
	to ATTENDEE:a

	ORGANIZER sends a third SINGLE instance update, SEQUENEC:5
	to ATTENDEE:a

	ORGANIZER gets a REPLY to SEQUENCE:5 from ATTENDEE:a
	ORGANIZER gets a REPLY to SEQUENCE:3 from ATTENDEE:a
	ORGANIZER gets a REPLY to SEQUENCE:4 from ATTENDEE:a

No matter which order you get them in, they are ALL resolvable.
There is NO breakage.

> and each REQUEST is a fully defintion of that instance then _WHY_ would 
> I need to do a REFRESH (full or otherwise) for the >=2 case? 

Sequence of events. Assume that ATTENDEE has SEQUENCE:2 of
the object and that is the SEQUENCE number of their FIRST invitation
(they were not originally on the guest list).

	ORGANIZER sends a SINGLE instance update, SEQUENCE:3
	to ATTENDEE:a

	ORGANIZER sends a second SINGLE instance update, SEQUENCE:4
	to ATTENDEE:a

	ORGANIZER sends a third SINGLE instance update, SEQUENEC:5
	to ATTENDEE:a

	ATTENDEE gets the single instance update, SEQUENCE:4 and
         the CUA has determined that too much time has gone by and
         for some reason (vendor lost your inbox an you did iMIP) the
	single instance SEQUENCE:3 change is lost. The ATTENDEE MUST
	do a REFRESH as they would have no idea what was in the
	SEQUENCE:3 object. Now as the ORGANIZER is NOT required
	to remember the state of past object/sequence sets, the
	ATTENDEE MUST do a full REFRESH.

> The 
>  REQUEST I just got simply "obsoletes" what I have currently and 
> therefore I can safely take some action on it such as REPLYing.  I can 
> safely and simply ignore the missed (or delayed) SEQUENCE+1 case since 
> the REQUEST Im currently parsing is newer and has obsoleted the missed 
> or delayed REQUEST.

Full REQUEST - yes. The SEQUENCE:3 single instance change (in the
example above) may have changed the DTSTART of a MONDAY meeting to
another time on MONDAY and the SEQUENCE:4 change may have only changed
the DTSTART of the TUESDAY meeting to another time on TUESDAY. Without
doing a REFRESH, the ATTENDEE would not have a clue.

--