Subject: Re: DTSTART for recurrence instances

From: "Craig Johnson" <[email-masked]>
Date: Wed, 03 Dec 2003 17:10:02 -0700

Olivier presented an excellent case showing that a RECCURRENCE-ID's
primary role is that of an 'identifier'; and not a 'date/time' value
that can
be relied on as the 'effective start' for a recurrence instance.  This
is made
even more clear in the following from 2445:
 
Section 4.8.4.4 Recurrence ID
. . .
   The date/time value (RECURRENCE-ID) 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 (RECURRENCE-ID) is still
set to the
   original Friday meeting.
 
With RECURRENCE-ID consigned to the role of an identifier
it clearly falls to DTSTART to represent a recurrence instance's
effective start time.
 
Doug wrote:
> For a recurring instance the effective start of an instance
> is defined in 2445 to be the RECURRENCE-ID.
 
That is not quite correct.  The effective start of an instance
is its DTSTART.  RECURRENCE-ID gets DTSTART as its 
initial value:
 
4.8.4.4 Recurrence ID
. . .                                               The property
   value is the effective value of the "DTSTART" property of the
   recurrence instance.
 
This statement makes it clear that a recurrence instance has a 
DTSTART property containing the "effective" value  ... and this is
where RECURRENCE-ID gets its initial value.  Initially, DTSTART
and RECURRENCE-ID have the same value.  If the instance is 
changed to a different time, DTSTART changes and 
RECURRENCE-ID does not.
 
Craig J

---

From: Doug Royer <[email-masked]>
Date: Thu, 04 Dec 2003 14:10:11 -0700

>    Friday meeting to Thursday, the date/time (RECURRENCE-ID) is still 

Meaning in the object being sent in the reschedule. In order to say X 
moves to Y,
you need to properties to hold X and Y. So the above paragraph means send a
new object with the new Y in RECURRENCE-ID and the old X in DTSTART.

> it clearly falls to DTSTART to represent a recurrence instance's

2445 is talking about a reschedule object not what 2446 calls the master 
object.

> changed to a different time, DTSTART changes and

Yet the topic of the section is RECURRENCE-ID and not DTSTART, so the
subject usage 'THE" in that sentence is RECURENCE-ID and not DTSTART.

Yes RECURRENCE-ID is the effective DTSTART of the 'instance'. If you have 3
daily instances the effective DTSTART of the 1st is 4-DEC, 2nd 5-DEC, and
the 3rd 6-DEC.

So the value of recurrence ids are:

1st
   
    RECURRENCE-ID: 4-DEC

2nd

    RECURRENCE-ID:5-DEC

3rd

    RECURRENCE-ID:6-DEC

Is does not say the "the value of DTSTART is", it says the value [of 
recurrence-id]
is the effective value of DTSTART. Not the same meaning.

It also does not say the value of DTSTART and RECURRENCE-ID are both
set to the same value (as I understoon one person to have said).

-- 

Doug Royer                     |   http://INET-Consulting.com
-------------------------------|-----------------------------
[email-masked]                 | Office: (208)520-4044
http://Royer.com/People/Doug   |    Fax: (866)594-8574
                               |   Cell: (208)520-4044

               We Do Standards - You Need Standards

---

From: [email-masked]
Date: Fri, 5 Dec 2003 12:08:06 -0500

> new object with the new Y in RECURRENCE-ID and the old X in DTSTART.

Lets not start this again shall we?  The original authors have even 
responded to this and they have clearly said that RECURRENCE-ID does not 
change on an instance reschedule.  The DTSTART for the instance can change 
on each instance reschedule but the the RECURRENCE-ID does not. 

I dont know what you mean by "hold X and Y".  What you need is an 
identifier to correctly identify the instance in question as its 
properties change.  Thats why was specified RECURRENCE-ID not to change on 
reschedules but DTSTART can.  The others have got it right from the bits 
Ive read. 

If the identifier changed each time, you'll have one heck of a time trying 
to deal with missequenced or lost messages.  Thats why RECURRENCE-ID does 
not change on each instance reschedule; so you can safely detect missed 
messages or missequenced ones and properly deal with them.  Doug and 
Franks response to this seemed to be pretty clear on this point.

And you seem to have it backwards in your last line there.  The reschedule 
would send the unchanged RECURRENCE-ID (the old X?) and the new DTSTART 
(the new Y?) in a reschedule REQUEST (with 'newer' or 'higher' SEQUENCE, 
DTSTAMP etc values).  Thus a second reschedule would use the same 
unchanged RECURRENCE-ID (the old X?) and another newer DTSTART (a new Z) 
value with a still higher SEQUENCE and newer DTSTAMP. 

If RECURRENCE-ID was supposed to be the previous incarnations DTSTART then 
you have 3 problems to contend with: Cases where reschedules do NOT entail 
changes to DTSTART (ie: a duration change only), how to deal with 
resequencing of messages that can arrive in any order and how to deal with 
missed messages.  If you tried to build a 'chain' of RECURRENCE-ID(0) -> 
DTSTART(1) / RECURRENCE-ID(1) -> DTSTART(2)... then you cannot recover 
easily if a message is lost.  It has been shown that in 5 simple steps you 
can easily mangle the workflow process when missequencing occurs too. 
Derik & Frank noted as much in their recent posting on this.

> object.

2445 deals with the C&S properties and their meanings / behavoiur.  2446 
deals with putting those properties into a coherent message for doing C&S 
workflow.

The term "master" as first used in iTIP Section 2.1 Application Protocol 
refers to the Organizers copy of the entry since that is the "definitive" 
copy.  All other copies are just that, copies that may or may not be in 
sync w/the Organizers version.  Much like there is only 1 'master' copy of 
the U.S. Constitution or the Deed for your property.  There can be copies 
made all you like but there is only 'master' copy or version of it.

The line:

                                    "Attendees" do not make
   direct changes to the master calendar entry.

could be slightly wrong in the CAP context since it is possible that an 
Invitee may have sufficient access rights to go and modify the Organizers 
copy directly.  However this was not how we originally modeled the 
workflow process since that was not something anyone actually did in the 
C&S systems.  Invitees always sent some kind of response back and the 
Organziers CUA (or perhaps server) would apply that change (or keep the 
information separate from the actual entry itself).  Whether or not its 
good CAP design/practice to allow invitees to do this is something else 
though...

> daily instances the effective DTSTART of the 1st is 4-DEC, 2nd 5-DEC, 
and
[Snip]
> is the effective value of DTSTART. Not the same meaning.

You are correct in that the text under 4.8.4.4 does NOT discuss the 
DTSTART value for the instance.  It is talking about how RECURRENCE-ID is 
defined and dealt with.  The text actually says:

   The date/time value is set to the time when the original recurrence
   instance would occur...

meaning that when the instance is created the DTSTART and RECURRENCE-ID 
values are the same.  As the instance gets rescheduled, the DTSTART 
may/may not change but the RECURRENCE-ID defintely does not.  It is kept 
at the "original" value for the instance (which matched the original 
DTSTART value the instance had). 

The only reason the term "effective" is used is because not all recurrence 
is sent using RDATEs where the values are just given.  With RRULEs the 
recipent must roll the rule out and calculate when the date/time of each 
repeat instance is (factoring in TZ shifts, etc). 

> set to the same value (as I understoon one person to have said).

I guess its all in how you read the cited line above then.

BTW: more than 1 person has said this.  I said it when we had the entire 
RECURRENCE-ID discussion during the summer and Frank and Derik (the 
original authors of 2445) said this in their posting on 18-Aug-03 
(http://www.imc.org/ietf-calendar/mail-archive/msg08662.html ):

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. 

and they even tried to explain why we did this:

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. To illustrate, 
consider the consequences if RECURRENCE-ID changed on each reschedule of 
an instance. Specifically, if the RECURRENCE-ID is changed on each 
reschedule of an instance, the sender and the recipient have no way to 
accurately know which instance is being referred to if just a single iTIP 
message was lost or mis-sequenced, or if the message is an invitation to a 
new instance entirely.  This inability to distinguish invitation, from 
reschedule, from update is not problematic with the fixed RECURRENCE-ID 
because it is unambiguous which instance is being referred to. 

Ok, I guess it depends on your understanding of the word "original" but 
thats not something we need to codify in RFCs I hope.  After all, you 
should be assigning RECURRENCE-ID properties to each instance when you 
first create them so you should see that the DTSTART and RECURRENCE-ID 
values you start with are the same. 

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: Olivier Gutknecht <[email-masked]>
Date: Fri, 5 Dec 2003 18:50:38 +0100

On 3 déc. 03, at 21:55, Doug Royer wrote:
>>
>> There is also a note in 2445 4.8.4.4 about DATE value type that 
>> actually tells something about DTSTART semantics in a RECURRENCE-ID 
>> based component:
>>
>>  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 definition here is for the -recurrence instance- and is a MUST.
>
> Yes and as the section and subject of that text is  'Recurrence ID', 
> as in :
>    If the value of the "DTSTART" property is a DATE type value, then 
> the
>     value [of RECURRENCE-ID] MUST be the calendar date for the 
> recurrence instance

Right, so we agree this is only about the 'value type' coherence 
problem between (original) DTSTART & RECURRENCE-ID.

On 4 déc. 03, at 22:10, Doug Royer wrote:
>> be relied on as the 'effective start' for a recurrence instance.  
>> This is made
[..]
> 2445 is talking about a reschedule object not what 2446 calls the 
> master object.

I don't think so as the text only refer to recurrence instance 
identification, and disagree with the above interpretation of having 
the object sent to reschedule. RFC 2445 is not talking about a 
reschedule object. The only concept in the RECURRENCE-ID definition in 
2445 is the 'specific instance of a recurring event'.
Which is coherent with the aim of 2445 to be a core, standalone, data 
model in my opinion (and close to Craig's views if I understand him 
correctly), leaving the (re)scheduling aspects to additional 
specifications (2446 being one specific possible model)

Having the RECURRENCE-ID value reflecting the effective value of the 
start date for the given instance is not coherent with the aim of using 
recurrence-id along with UID and sequence to properly identify the 
recurrence instance, as clarified by Frank and Derik:
	"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." [...] "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."

If the RECURRENCE-ID value is not changed, "changes to the start/end of 
the recurrence instance" are done, how can it be expressed if not in 
DTSTART / DTEND values ? How can a rescheduled specific instance could 
be expressed in a complete snapshot of the event state  if not by 
having the recurrence-ID identifying the initial value for the instance 
and dtstart giving the actual, rescheduled value ?

> subject usage 'THE" in that sentence is RECURENCE-ID and not DTSTART.

Immediatly below, this is precised to be "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."

Why insisting on "the time when the *original* recurrence instance 
would occur" if not to have a possible -distinct- dtstart ? the 'The' 
in that case is the RECURRENCE-ID (topic of the section).

> So the value of recurrence ids are:

Agreed.

> is the effective value of DTSTART. Not the same meaning.

... as the initial recurrence instance value, and I think we all agree 
about that. This does not imply that the DTSTART for the specified 
recurrence instance must never change or be the start date of the 
original event instance.
It is more than likely that we're actually discussing the very same 
problem of recurrence-ID 'stability' again.

Ol.

---

From: Doug Royer <[email-masked]>
Date: Fri, 05 Dec 2003 12:08:28 -0700

[email-masked] wrote:

> responded to this and they have clearly said that RECURRENCE-ID does 
> not change on an instance reschedule.  The DTSTART for the instance 
> can change on each instance reschedule but the the RECURRENCE-ID does 
> not.   

NO ONE SAID THAT IS THE TOPIC.

--

---

From: Doug Royer <[email-masked]>
Date: Fri, 05 Dec 2003 12:15:56 -0700

> problem between (original) DTSTART & RECURRENCE-ID. 

Yes.

>>>    Friday meeting to Thursday, the date/time (RECURRENCE-ID) is 
>>> still set to the
>>>    original Friday meeting.
>>
>>
> the object sent to reschedule.

> If the RECURRENCE-ID value is not changed, "changes to the start/end 
> of the recurrence instance" are done, how can it be expressed if not 
> in DTSTART / DTEND values ? How can a rescheduled specific instance 
> could be expressed in a complete snapshot of the event state  if not 
> by having the recurrence-ID identifying the initial value for the 
> instance and dtstart giving the actual, rescheduled value ? 

As I posted the date math in a previous email (yesterday?)

> Immediatly below, this is precised to be "The date/time value is set 
> to the time when the original recurrence

Again it is talking about a change object, not the original.

--

---

From: Mark Smith <[email-masked]>
Date: Fri, 05 Dec 2003 12:20:42 -0700

[email-masked] wrote:
> still
> Lets not start this again shall we? 

Is your worst fear in life (1) that you do not have a clue what
others are talking about, (2) that when you speak no one takes
your word as the authoritative answer, or (3) when you can not be
the one to start a controversy you will just keep trying.

---

From: [email-masked]
Date: Fri, 5 Dec 2003 14:52:27 -0500

still
> > > you need to properties to hold X and Y. So the above paragraph means 

> > send a

You appeared to be reintroducing that idea in this discussion.   At least 
thats how I take your comments given the citation you were responding to. 
Please do not use concepts that were already covered and the original 
authors have noted as being incorrect.   On instance reschedules 
RECURRENCE-ID is unchanging so using it as part of some X - Y or Y - X or 
other calculation is not viable.

As I noted in another reply, there is no iTIP text regaring the use of 
RECURRENCE-ID to calculate DUE values and thats likely due to the edits we 
made when we changed the design for RECURRENCE-ID. 

Thinking logically, if you tried to do some calculation based on a 
changing DTSTART and a fixed RECURRENCE-ID value then you can get a wildly 
changing and inaccurate DUE value.  For example, if you move the VTODO out 
a day the DUE date would move out 1 day.  If you then moved it out 3 more 
days your DUE date would be calculated as 4 days after the DTSTART rather 
than 1 day after it.  If you moved the instance backwards a few days in 
time, the DUE value would be miscalcuated as being before the DTSTART 
value.  Clearly this is not desirable.

Since the iTIP messages are full snapshots of the Organizers copy it would 
provide a DUE (or DURATION) value for the recipient to use if the 
Organizer had one.  If they did not, none will be present.  No need for 
mess or fuss and certainly no problem with not being in sync w/the 
Organzier.

Bruce

---

From: Mark Smith <[email-masked]>
Date: Fri, 05 Dec 2003 13:13:00 -0700

[email-masked] wrote:

> 
> You appeared to be reintroducing that idea in this discussion.

Are you completely incapable of haveing a technical discussion
without controversy?
 Why do you always insist on makeing a pointt
of a on a non technecal point?

---

From: Doug Royer <[email-masked]>
Date: Fri, 05 Dec 2003 13:27:56 -0700

Olivier,

I want to take a recurrence change step by step until we disagree and 
see if I can
understand what exactly is the issue.  (Sorry Bruce - I am going to 
ignore ALL of your email
on this subject as you seem to be focused on differences and your 
version of history
rather than solutions and understanding).

So, if the ORGANIZER sends the following iTIP object to ATTENDEE:

    BEGIN:VEVENT
    UID:XXX
    SEQUENCE:0
    ...
    METHOD:REQUEST
    ATTENDEE:attendee
    ...
    DTSTART: 1-dec-2003 at noon
    DTEND: 1-dec-2003 at 1pm
    ...
    RRULE:FREQ=DAILY;COUNT=3
    ...
    END:VEVENT

(And 'attendee' sends a  reply saying yes).

Now later ORGANIZER sends an iTIP update to move the 2nd instance from  
noon->1pm
 and have it at 2pm->3:30pm:

    BEGIN:VEVENT
    UID:XXX
    SEQUENCE:1
    ...
    METHOD:REQUEST
    DTSTART:2-dec-2003 at 2pm
    DTEND:2-dec-2003 at 3:30pm
    RECURRENCE-ID:2-dec-2003 at noon
    ..
    END:VEVENT

Do you agree that is a valid object to tell the ATTENDEE of the single 
instance change?

--

---

From: Doug Royer <[email-masked]>
Date: Fri, 05 Dec 2003 13:24:30 -0700

Oliver,

I want to take a recurrence change step by step until we disagree and 
see if I can
understand where the issues is (Sorry Bruce - I am going to ignore ALL 
of your email
on this subject as you seem to be focused on differences rather than 
solutions
and understanding).

If the ORGANIZER sends the following iTIP object to ATTENDEE:

    BEGIN:VEVENT
    UID:XXX
    SEQUENCE:0
    ...
    METHOD:REQUEST
    ATTENDEE:attendee
    ...

    BEGIN:VEVENT
    UID:XXX
    SEQUENCE:1
    ...
    METHOD:REQUEST

Do you agree that is how to move a single instance?

--

---

From: Mark Smith <[email-masked]>
Date: Mon, 08 Dec 2003 12:21:49 -0700

> You appeared to be reintroducing that idea in this discussion. 

In your previous email you just declared you had not followed the
topic. Please explain how you get to argue both sides of 'yes I do'
and 'no I do not' follow the same topic.

---

From: Mark Smith <[email-masked]>
Date: Mon, 08 Dec 2003 12:25:39 -0700

[email-masked] wrote:
> You appeared to be reintroducing that idea in this discussion.   At
> least thats how I take your comments given the citation you were
> responding to.  Please do not use concepts that were already covered
> and the original authors have noted as being incorrect.   On instance
> reschedules RECURRENCE-ID is unchanging so using it as part of some X
> - Y or Y - X or other calculation is not viable.
> 
> RECURRENCE-ID to calculate DUE values and thats likely due to the
> edits we made when we changed the design for RECURRENCE-ID.

Yes 2446 does, look for 'Calculating due dates in recurring VTODOs'.

> changing DTSTART and a fixed RECURRENCE-ID value then you can get a
> wildly changing and inaccurate DUE value. 

> For example, if you move
> the VTODO out a day the DUE date would move out 1 day.  If you then
> moved it out 3 more days your DUE date would be calculated as 4 days
> after the DTSTART rather than 1 day after it.  If you moved the
> instance backwards a few days in time, the DUE value would be
> miscalcuated as being before the DTSTART value.  Clearly this is not
> desirable.

instance due date as described in 4.5.7.2 is:

  instance-due-date = RECURRENCE-ID + (DUE - DTSTART).

It is always correct.

Clearly you are using incorrect procedures as outlined in 2446.

---

From: [email-masked]
Date: Mon, 8 Dec 2003 17:16:43 -0500

> Yes 2446 does, look for 'Calculating due dates in recurring VTODOs'.

Dont bother trying to bait me into non-technical discussions or exchanging 
personal barbs.  I wont waste my time or the WG bandwidth on it.

If you actually read iTIP, it only says:

4.5.7.2 Calculating due dates in recurring VTODOs

   The due date in a recurring "VTODO" calendar component is either a
   fixed interval specified in the "REQUEST" method or specified using
   the "RECURRENCE-ID" property. The former is calculated by applying
   the difference between "DTSTART" and "DUE" properties and applying it
   to each of the start of each recurring instance. Hence, if the
   initial "VTODO" calendar component specifies a "DTSTART" property
   value of "19970701T190000Z" and a "DUE" property value of
   "19970801T190000Z" the interval of one day which is applied to each
   recurring instance of the "VTODO" calendar component to determine the
   "DUE" date of the instance.

There is no actual text for the "latter case" describing _how_ 
RECURRENCE-ID would be used on a VTODO; just that "or specified..." bit 
that has nothing supporting it elsewhere in the text.  It was likely in a 
second paragraph that got removed before we went to Last Call.  One could 
take it to be "Well, I can just use the RECURRENCE-ID as the DUE value" 
however thats not valid because A) it could be BEFORE the instances 
DTSTART and B) the reschedule is a full snapshot so if it had no DUE or 
DURATION value then you should not be calculating one now.

If we had kept the delta RECURRENCE-ID model then a CUA could have done 
something like "diff between RECURRENCE-ID and new DTSTART" is how much 
the VTODO shifted and so the new DUE date can be calculated based on the 
old DUE date.

However this logic is useless now if you properly consider:

1: Any initial VTODO wont have be able to calculate a difference between 2 
versions of the VTODO since both RECURRENCE-ID and DTSTART at identical. 
As such each VTODO instance will have the same length interval between its 
DTSTART and its DUE.

2: On any reschedule of the VTODO instance, the Organzier would be sending 
a full snapshot of the VTODO and as such the recipient would be using that 
so they are in sync w/the Organzier.  If the Organzier did not include a 
DUE then who is the invitee to add one for them?  (They can if they want 
but its not a valid DUE value.)

3: When dealing with multiple instances at a time, the DUE for each 
subsequent instance should be calculated based on the difference between 
the DTSTART and DUE (or DURATION) of the 1st instance of the affected 
subset, if provided (see #2). 

4: We did not opt for a delta RECURRENCE-ID model so its not useful in 
trying to do any shift calculations.  This coupled the above means you are 
inventing mechanisms or behaivour that is just not there or that is 
incorrect.

> Clearly you are using incorrect procedures as outlined in 2446.

Actually I think you are still under the mistaken impression that 
RECURRENCE-ID changes when the a component is rescheduled.  As the authors 
have already confirmed, this is not the case.  ( 
http://www.imc.org/ietf-calendar/mail-archive/msg08662.html )  Plus you 
may be misreading the iTIP text that says "either a fixed interval 
specified in the "REQUEST" method or specified using the "RECURRENCE-ID" 
property""  Essentially its "either A or B" and you are reading it more 
like "A + B".

With a fixed RECURRENCE-ID you cannot use that algorithm as then you can 
get wildly incorrect instance due dates/times. 

An algorithm that will work is:

        instance-DUE = instance-DTSTART + ( ( DURATION ) ? DURATION : ( 
DUE - DTSTART )

where you calculate the DUE value based on either the given DURATION or 
the difference of DUE and DTSTART.  However you apply it to the instances 
current DTSTART and not to its RECURRENCE-ID.

This algorithm though does NOT show that you do NOT calculate a DUE value 
if there was no DUE / DURATION value in the reschedule.  After all, if the 
sender did NOT set a DUE / DURATION then the recipient should not when 
they get it.

Bruce

---

From: Mark Smith <[email-masked]>
Date: Mon, 08 Dec 2003 16:04:55 -0700

[email-masked] wrote:
> Dont bother trying to bait me into non-technical discussions or
> exchanging personal barbs.  I wont waste my time or the WG bandwidth
> on it.
> 
> RECURRENCE-ID would be used on a VTODO; just that "or specified..."
> bit that has nothing supporting it elsewhere in the text.  It was
> likely in a second paragraph that got removed before we went to Last
> Call.  One could take it to be "Well, I can just use the RECURRENCE-ID
> as the DUE value" however thats not valid because A) it could be
> BEFORE the instances DTSTART and B) the reschedule is a full snapshot
> so if it had no DUE or DURATION value then you should not be
> calculating one now.
> 
> If we had kept the delta RECURRENCE-ID model then a CUA could have
> done something like "diff between RECURRENCE-ID and new DTSTART" is
> how much the VTODO shifted and so the new DUE date can be calculated
> based on the old DUE date.
> 
> 1: Any initial VTODO wont have be able to calculate a difference
> between 2 versions of the VTODO since both RECURRENCE-ID and DTSTART
> at identical.  As such each VTODO instance will have the same length
> interval between its DTSTART and its DUE.
> 
> 2: On any reschedule of the VTODO instance, the Organzier would be
> sending a full snapshot of the VTODO and as such the recipient would
> be using that so they are in sync w/the Organzier.  If the Organzier
> did not include a DUE then who is the invitee to add one for them?
>  (They can if they want but its not a valid DUE value.)
> 
> subsequent instance should be calculated based on the difference
> between the DTSTART and DUE (or DURATION) of the 1st instance of the
> affected subset, if provided (see #2).
> 
> trying to do any shift calculations.  This coupled the above means you
> are inventing mechanisms or behaivour that is just not there or that
> is incorrect.
> 
> RECURRENCE-ID changes when the a component is rescheduled.

FYI - EVERY discussion about RECURRENCE-ID is not that topic.

---

From: Mark Smith <[email-masked]>
Date: Mon, 08 Dec 2003 16:12:54 -0700

> exchanging personal barbs.  I wont waste my time or the WG bandwidth

You said there was NO SUCH text, and there IS text that describes
that in iTIP. You expect people to believe your point of view when
you make such inaccurate statements about text in the RFCs?

No, you accuracy rating is in the low 10% when you make statements.

---

From: Doug Royer <[email-masked]>
Date: Mon, 08 Dec 2003 17:06:54 -0700

[email-masked] wrote:

> are inventing mechanisms or behavior that is just not there or that is 
> incorrect.

The discussion was how to expand RECURRENCE-ID's in the result set.
So, what you are talking about has (again) nothing to do with the
topic of if (or not) the RECURRENCE-ID changes on old 'set's.

As has been pointed out by several on this mailing list, including
Robert-(what-ever-his-name-is) from Lotus AND YOU that the RECRRENCE-ID
is not fixed to the value it was in SEQUENCE:0. Everyone seems to agree
to that including your peers and Frank and Derik. If it was you can never
invite a new attendee or delegate to someone that never got the sequence:0
object. -You- also seem to have declared that it is per 'set' 
(uid/sequence/...).

So, given an object you were first invited to is (or your 'booked' 
object is):

    SEQUENCE:100
    UID: uid-1
    DTSTART: monday 10am
    DTEND: monday 11am
    RRULE ... daily for 5 days...

Are you trying to tell me that only a CS that have the sequence:0
object can ever return an expanded object? No. there has never been any 
one that
proposed that RECURRENCE-IDs only relate to only old objects. If your
BOOKED object is SEQUENCE:X, then the -ONLY-  RECURRENCE-ID's
that you  will ever be able to calculate is the set that contains 
SEQUENCE:X .

No amount of claming 'this' means 'that' or quoting for the nTh time 
that someone
said whatever, will ever make such objets be able to create the SEQUENCE: <X
RECURRENCE-ID values when the booked object is > X.

If you expand an object, that is exactly what it means, the named object is
expanded. It can not mean that some previous incarnation of the object is
to be expanded. It means the object you have is expanded.

So, no, the RECURRENCE-ID's are NOT the same as in the previous
topic, they must be from the BOOKED (or unscheduled) objects you have.

Think of it this way, you have X new unscheduled objects in your CS.
The CU wishes to determine IF they will respond YES I  WILL ATTEND.
The CU will need to know the dates IN THAT OBJECT in order to decide
if THOSE dates are acceptable.

The CS MUST expand those object "as is", else no matter how many times
the CUA asks, it will only get the dates for the OLDER object? No, that
would be busted.

--

---

From: [email-masked]
Date: Tue, 9 Dec 2003 10:18:30 -0500

> FYI - EVERY discussion about RECURRENCE-ID is not that topic.

I suggest you learn to distingush the role of instance _identifier_ 
(RECURRENCE-ID) from instance _start_date/time_ (DTSTART) when you propose 
algorithms then.  You (and others) continue to misuse RECURRENCE-ID and I 
will continue to try and disavow you of that mistaken idea.

RECURRENCE-ID is strictly used to find and identify the correct repeat 
instance of a repeat set.  Its intended to help both sides of the workflow 
process correctly identify the instance in question.  It is NOT designed 
to be anything like "the instances last DTSTART time" as this makes 
dealing with missequenced or lost workflow messages impossible (or at 
least waaay to cumbersome). 

DTSTART is used to specify when the instance starts.  When an instance 
first gets created this value is assigned to the instances RECURRENCE-ID. 
As the instance gets rescheduled though, only DTSTART changes.

As such, your proposed algorithm would generate wildly varying and 
inaccurate DUE values depending on how far the instance gets rescheduled 
from its original DTSTART value.   As noted before, you could even get DUE 
values before the DSTART value of an instance and thats hardly acceptable.

Bruce

---

From: Mark Smith <[email-masked]>
Date: Tue, 09 Dec 2003 11:37:14 -0700

[email-masked] wrote:
> (RECURRENCE-ID) from instance _start_date/time_ (DTSTART) when you
> propose algorithms then.  You (and others) continue to misuse
> RECURRENCE-ID and I will continue to try and disavow you of that
> mistaken idea.

And it STILL is not that topic.

---

From: "Michael Fair" <[email-masked]>
Date: Tue, 9 Dec 2003 16:09:43 -0800

I think someone should pick up this thread with Doug.
This is the most productive line of conversation yet to
create clarity around this.  Some time ago Doug Royer
started ignoring me.  Will someone please reply to my post
or Doug's directly to persue this?

> Do you agree that is how to move a single instance?

Yes I agree that would be the iTIP to send to move the
2nd instance from noon to 2pm.

Now I believe the next step is to move it from 2pm to 4pm.
(I moved the RECURRENCE-ID property to place it with the identifiers.)

     BEGIN:VEVENT
     METHOD:REQUEST
     UID:XXX
     RECURRENCE-ID:2-dec-2003 at noon
     SEQUENCE:2
     ...
     DTSTART:2-dec-2003 at 4pm
     DTEND:2-dec-2003 at 5:30pm
     ..
     END:VEVENT

The key being that Recurrence-id is "at noon" and not "at 2pm".
Do you agree that is how to move a single instance a second time?

-- Michael --

---

From: Doug Royer <[email-masked]>
Date: Tue, 09 Dec 2003 18:33:39 -0700

(Again the topic is DTSTART for recurrence instances, not any thing else)

Is there any disagreement that these are -also- a valid ways to change 
the 2nd instance:

Again starting from the same original object.

   BEGIN:VEVENT
   UID:XXX
   SEQUENCE:0
   ...
   METHOD:REQUEST
   ATTENDEE:attendee
   ...

Method A:  Now later ORGANIZER sends iTIP updates to move the second 
instance
 from  noon->1pm  and have it at 2pm->3:30pm:

   BEGIN:VCALENDAR
   ...
   METHOD:REQUEST
   BEGIN:VEVENT
   UID:XXX
   SEQUENCE:1
   ...
   RDATE:3-dec-2003 at noon
   ...
   END:VEVENT
   END:VCALENDAR

   BEGIN:VCALENDAR
   METHOD:ADD
   BEGIN:VEVENT
   UID:XXX
   SEQUENCE:2
   ...
   END:VCALENDAR
  
Method B:  Now later ORGANIZER sends iTIP updates to move the second 
instance
 from  noon->1pm  and have it at 2pm->3:30pm:

   BEGIN:VEVENT
   UID:XXX
   SEQUENCE:1
   ...
   METHOD:REQUEST
   ATTENDEE:attendee
   ...
   DTSTART: 1-dec-2003 at noon
   DTEND: 1-dec-2003 at 1pm
   ...
   RRULE:FREQ=DAILY;COUNT=3
   EXDATE:2-dec-2003 at noon
   ...
   END:VEVENT

   BEGIN:VCALENDAR
   METHOD:ADD
   BEGIN:VEVENT
   UID:XXX
   SEQUENCE:2
   ...
   END:VCALENDAR
  
Method C:  -OR- this:

   BEGIN:VCALENDAR
   ...
   METHOD:CANCEL
   BEGIN:VEVENT
   UID:XXX
   SEQUENCE:1
   ...
   END:VCALENDAR

   BEGIN:VCALENDAR
   METHOD:ADD
   BEGIN:VEVENT
   UID:XXX
   SEQUENCE:2
   ...
   END:VCALENDAR

Do you agree that these are also valid objects to tell the ATTENDEE of 
the single instance change?

--

---

From: "Michael Fair" <[email-masked]>
Date: Tue, 9 Dec 2003 18:51:33 -0800

"Doug Royer" <[email-masked]> wrote in message
news:[email-masked]...
> (And 'attendee' sends a  reply saying yes).

Just to ensure that I am following I am going to describe
the state of the CU's store at the end of each message.

>    DTEND:2-dec-2003 at 3:30pm

I agree.

This first message would redefine the event XXX to have exactly two
instances (Dec 1, Dec 3), and drop the orginal Dec 2 instance.

The second message then adds to the series of UID XXX one singleton
on Dec 2 and updates the SEQUENCE of all instances to 2.

>    DTEND:2-dec-2003 at 3:30pm

I agree.

The first message redefines the series to contain two instances
on Dec 1 and Dec 3.
The second message redefines the entire series to add a singleton
event happening on Dec 2.

It then updates the SEQUENCE for all instances of XXX to 2.

> the single instance change?

I agree.

I'm not entirely certain of all the gritty details of how the first message
gets handled because of other questions I raised back in August.
Don't bother looking for them though, they aren't relevant at this point.
For now I'm fine to just accept that this has the effect of cancelling the
second instance in the series leaving just Dec 1 and Dec 3.

The second message then adds a new instance to the series XXX on Dec-2 and
updates the SEQUENCE of all instances of XXX to 2.

Having said that there is one thing I do have a problem with and that is
calling any of the above methods an instance reschedule.  They result in
the intended calendar and that's about all I can say about them.

Everyone of the aboves methods uses extremely invasive reschedules of
the entire series and I cannot consider them as proper methods for
instance updates or reschedules.

Where do we go from here?

-- Michael --

---

From: [email-masked]
Date: Wed, 10 Dec 2003 09:12:11 -0500

> 2nd instance from noon to 2pm.

I agree too.  (I dont know if Oliver didnt see Dougs posting was directed 
at him or not so maybe thats why he didnt respond yet.)

Yes.

Bruce

---

From: Olivier Gutknecht <[email-masked]>
Date: Wed, 10 Dec 2003 17:18:45 +0100

On 10 déc. 03, at 15:12, [email-masked] wrote:
> I agree too.  (I dont know if Oliver didnt see Dougs posting was 
> directed at him or not so maybe thats why he didnt respond yet.)

I agree too. I was just somewhat offline in the last two days, sorry 
for the delay.

> > Do you agree that is how to move a single instance a second time?

If the instance was previously identified as above with the first 
REQUEST, yes I agree.

Ol.

---

From: Olivier Gutknecht <[email-masked]>
Date: Wed, 10 Dec 2003 17:19:08 +0100

> Do you agree that is a valid object to tell the ATTENDEE of the single 

I agree. iTIP to request that the instance identified by UID xxx and 
RECURRENCE-ID 2-dec-2003 noon (occurrence time) has now a DTSTART of 
2-dec-2003 2pm (and DTEND of 3:30pm). Although this was the first 
solution, let's call that 'method D' to differentiate it from the A, B, 
C proposals of your next mail.

Ol.

---

From: Olivier Gutknecht <[email-masked]>
Date: Wed, 10 Dec 2003 17:18:33 +0100

On 10 déc. 03, at 02:33, Doug Royer wrote:
> [...]

Method A: I agree. I rephrase to be sure we all understand it the same 
way:
	- a REQUEST to  modify the event by having an instance on at 3-dec 
noon, the other one being the DTSTART at 1-dec-2003 noon
	- an ADD to then add another instance at 2-dec-2003 2pm

>   DTEND:2-dec-2003 at 3:30pm

Method B: I agree
	- a REQUEST to modify the event. We keep the RRULE and remove the 
2-dec noon instance
	- a subsequent ADD to add the 2-dec-2003 2pm instance

> the single instance change?

Method C: ok too
	- CANCEL to remove the instance identified by UID  + recurrence-ID 
2-dec-noon
	- then a ADD to put another instance at 2-dec-2003 2pm
And in all cases (A,B,C,D), SEQUENCE for all instances is 2.
I also agree with Michael's comments that we end with a calendar where 
we have 1-dec noon->1pm, 2-dec 2pm->3:30pm, 3-dec noon->1pm and I'm not 
sure I can consider every method as a 'reschedule'.

Ol.

---

From: [email-masked]
Date: Wed, 10 Dec 2003 13:24:46 -0500

If we have a good line of conversation going, I agree, let's keep it 
rolling.  Anyone else want to reply?  If we keep the number of notes to a 
minimum it may give people bandwidth to be able to reply.  Also, try to 
change the subject line if you are stating something different.  In trying 
to go back and build and issues list, i am missing things because they are 
in notes that have different subject lines.  Thanks for helping on that.
___________________
Patricia Egen Consulting
www.egenconsulting.com
423-875-2652

"Michael Fair" <[email-masked]> 
Sent by: [email-masked]
12/09/2003 19:09

To
[email-masked]
cc

Subject
Re: DTSTART for recurrence instances

     BEGIN:VEVENT
     METHOD:REQUEST
     UID:XXX

-- Michael --

---

From: [email-masked]
Date: Wed, 10 Dec 2003 13:39:02 -0500

> Is there any disagreement that these are -also- a valid ways to change 

I disagree that the semantics of the examples included are NOT instance 
reschedules.  Rather they all are a recreation of the set of instances in 
a recipients calendar.

There is a semantic difference between a reschedule of a particluar 
instance and recreating the entire set of instances. 

The end result of your examples MAY result in the same but it may not be 
for various reasons including:

1: The state of the 1st and 3rd instances are negotiatble separately.  So 
if there was ANYTHING done to them such as changing PARTSTAT (ie: the CU 
DECLINED it) then that information will be lost when the CU recreates the 
instance set using any of the included methods.

2: Given that workflow for instances can occur independently, using any of 
the alternate methods will result in all participation info being reset on 
ALL OTHER instances.  For example, if instance 1 was uncontested by 
everyone and they all ACCEPTed before the Organzier sent any of the 
alternatives reschedules then the iTIP message would result in a higher 
SEQUENCE value for ALL instances, NOT just the second instance.  This has 
2 big drawbacks:

        A) Workflow already done for that instance MUST be redone all over 
again.  That is, although instance 1 was not being rescheduled the invitee 
MUST reACCEPT the new version at a higher SEQUENCE value.
        B) This need to renegotiate applys to ALL other instances in the 
set potentially!  Imagine trying to deal with this resetting of PARSTAT 
while rescheduling 2 separate instances, not just 1.  Users would wind up 
reACCEPTing or reDECLINEing the same instance multiple times for apparent 
reason as _other_ instances are rescheduled instead of the one you 
ACCEPTed or DECLINEd.

3: The RECURRENCE-ID value for the new second instance is NOT the same as 
its original incarination.  It is a new instance as seen by its different 
value.  For example, Method A would create a second instance whose 
RECURRENCE-ID is 2-dec-2003 at 2pm (for those implementations that support 
ADD) and would destroy the original second instance whose RECURRENCE-ID 
was 2-dec-2003 at noon.  This means that there is an effective disjoin 
because:

        A) For those implementations that do not support ADD, there is no 
longer a RECURRENCE-ID:2-dec-2003 at noon; only a 2 instance set for 
UID:XXX.  This means their picture of the repeating set is different from 
the Organziers.  This disjoin may not be readily visible in workflow 
messages so recovery is non-trivial at best.

        B) If one compares the per instance info the RECURRENCE-ID 
property for the second instance of the set will be different (assuming 
ADD was supported).  In the original case, the RECURRENCE-ID stayed at 
2-dec-2003 at noon but in the alternative cases all the RECURRENCE-IDs 
were changed to 2-dec-2003 at 2pm.  Clearly this means the end results are 
NOT equivalent.

>  from  noon->1pm  and have it at 2pm->3:30pm:

Again, technically speaking this example and the others that follow are 
NOT moving the second instance.  It was recreating the set as 2 instances 
and then adding an instance in between to get back to 3 instances.  That 
is not the same as moving an existing entry.

> the single instance change?

Again, they do not change the second instance but rather they remove it 
and create a new one.  As show above, this does not always result in the 
equivalent data or view of the set by all parties.  The end result may be 
a 3 instance repeat set on both sides but its not equivalent in that other 
instances are also impacted needlessly.

Bruce

---

From: Doug Royer <[email-masked]>
Date: Wed, 10 Dec 2003 13:15:17 -0700

PLEASE - if you want to talk about the other RECURRENCE-ID issue - change
the subject line. How you derive RECURRENCE-ID from a given object with
EXPAND:TRUE and how it effects DTSTART is NOT the same as
if (or not) RECURRENCE-ID changes after a reschedule.

Please read all of this as there are some interdependencies with
text after statements.

Olivier Gutknecht wrote:

> we have 1-dec noon->1pm, 2-dec 2pm->3:30pm, 3-dec noon->1pm and I'm 
> not sure I can consider every method as a 'reschedule'. 

In the first email the sequence is '1', and in (A, B, C) the sequence is 
'2'. (D?).

And although they are -all-  -not- really a 'reschedule' they all four
represent ways the CU could change the 2nd instance.

Now assume that 'A' or 'B' as sent previously to this list was
sent to ATTENDEE:attendee-2 as attendee-2's initial REQUEST
to attendee this meeting. Except 'ATTENDEE:attendee-2'
in place of (or in addition to) ATTENDEE:attendee. And
attendee-2 said yes.

The CS of the  attendee-2 (I am NOT talking about the organizer
or attendee-1) has in the attendee-2's CS (I am NOT talking about
the CUAs)

  BEGIN:VEVENT
  ...
  (no METHOD as it is booked)
  ...
  UID:XXX
  ...
  SEQUENCE:2
  ...
  ATTENDEE:attendee-2
  ...
  DTSTART: 1-dec-2003 at noon
  DTEND: 1-dec-2003 at 1pm
  ...
  RRULE:FREQ=DAILY;COUNT=3
  EXDATE:2-dec-2003 at noon
  ...
  (plus the following start/stop time however it may be
    represented in the 'attendee-2' CS)
  ...
  DTSTART:2-dec-2003 at 2pm
  DTEND:2-dec-2003 at 3:30pm
  ...
  END:VEVENT
  END:VCALENDAR
 
Assume this is the ONLY UID for all of  the organizer, original 
attendee, and
attendee-2 in their  CS's (not CUAs).

On -4-dec-2003, I said, and you replied on 5-dec for to the ORIGINAL 
object (Not
A, B, or C as they has not been sent yet) to attendee (not attendee-2)' 
and you agreed.

 >> the 3rd 6-DEC. So the value of recurrence ids are:
 >>
 >> 1st
 >>  RECURRENCE-ID: 4-DEC
 >>
 >> 2nd
 >> RECURRENCE-ID:5-DEC
 >>
 >>3rd
 >> RECURRENCE-ID:6-DEC
 >
 > Agreed.

At this point both 'attendee' and 'attendee-2' have the same pattern of
instances. The ORGANIZER (master copy) of UID:XXX is at SEQUENCE:2.

So my questions to any and all  using your understanding of how they
are generated.

 What are the RECURRENCE-ID's and DTSTARTs for 'attendee-2'? That is
  attendee-2 does an EXPAND:TRUE fetch. (Got one object == SEQUENCE:2)

 What are the RECURRENCE-ID's and DTSTARTs for 'attendee' (not-2) after
 getting the 1st (not A, B, or C) objects?  (Got original[SEQUENCE:0]
 + instance update[SEQUENCE:1], 'attendee' at SEQUENCE:1)

 What are the RECURRENCE-ID's and DTSTARTs for 'attendee' after
  getting A, B, or C (not the first reschedule)?   (Got original 
[SEQUENCE:0],
  + 2 sequence updates,  'attendee' now at SEQUENCE:2).

 What are the RECURRENCE-ID's and DTSTARTs for the
 ORGANIZER? (master copy now at SEQUENCE:2).

As I understand the process  that some on this list believe to be true, the
answers will not be the same for some of; ORGANIZER, both ATTENDEE's,
or for all 4 update methods.

And that is busted as no ORGANIZER CUA could figure them out if they -later-
send  single instance reschedule (As sent in the 1st email) to the same UID.
As the ORGANZER's CUA would have to contact each ATTENDEEs CS to
figure out what that ATTENDEE's CS thought the RECURRECE-ID's were
or do some vendor specific CAP I/O to look at a log of what was sent
to each attendee which may not work with the next CUA looking at the
same UID.

Attendee-2 will not have any history of the object at this point only
has SEQUENCE:2 invite.

Which is why I say for any UID/SEQUENCE the RECURRENCE-ID's must be
derived from the object it self without any knowledge of history - or of 
the previous
methods. And as the ORGANIZER is the owner of a UID, then the owners
object is the 'master' copy.

The answers have to be all 2-dec-2003 at noon, 3-dec-2003-at 2pm, and 
4-dec-2003 at noon
for RECURENCE-ID's and the DTSTARTs are the one in the master object.

If you disagree:

 - And if all of your answers to the above questions are the same:
     Say so and start a NEW thread (new subject line)  on how
     and why.

 - And if all of your answers to the above questions are not the same:
     Start a new thread (new subject line) and please step this WG through
     the process you use to later send a single instance update to all 
attendees.
 
    And we can start a thread (new subject line) on how  you got your 
answers.

Only when everything is documented step by stem in writing can we solve 
this.

--

---

From: [email-masked]
Date: Thu, 11 Dec 2003 13:05:24 -0500

> if (or not) RECURRENCE-ID changes after a reschedule.

It was already hammered at ad naseum and confirmed by the RFC authors that 
RECURRENCE-ID does not change on an instance reschedule.  Please see 
http://www.imc.org/ietf-calendar/mail-archive/msg08662.html for 
confirmation of this. 

As such, can we please NOT even go down any discussion path that tries to 
reintroduce the concept of RECURRENCE-ID changing on a reschedule?!?

The RECURRENCE-ID value should be the the DTSTART that the instance was 
originally created at as described in iCalendar Section 4.8.4.4:

The use of EXPAND should be orthogonal to the discussion of calculating 
any instances RECURRENCE-ID.  EXPAND is currently defined in CAP-12-e as:

   Purpose: This property is to notify the CS if it should or should not
   expand any component with recurrence rules into multiple instances in
   a query reply.

so it is defined as a way for the CUA to tell the CS how to handle 
bundling results to return.  It should have no bearing on the actual 
instance properties themselves.  The EXPAND property  does not impact how 
the CS calculates the RECURRENCE-ID of any particular instance; that is 
already defined by iCalendar.

Bruce

---

From: [email-masked]
Date: Thu, 11 Dec 2003 13:33:27 -0500

> Please read all of this as there are some interdependencies with

I will soon be out of touch for a few weeks on vacation so I may not be 
able to continue this discussion until I get back.  Fore warning in case 
it appears as if I just disappeared (my silence is not acceptance, merely 
my inability to participate while traveling)

> represent ways the CU could change the 2nd instance.

Actually they all represent ways for an Organizer to recreate a 3 instance 
repeat set.  Since there is a fundamental difference between a simple 
instance reschedule (iTIP Section 3.2.2.1 Rescheduling an Event) and 
recreating all instances in the repeat set (see the analysis from 
yesterday), why are we even considering these "alternatives"? 

If the intent of this discussion is how to determine how RECURRENCE-IDs 
are assigned in the CS then thats simple to answer (see iCalendar). 

If the intent of this discussion is to understand how 
invitation/rescheduling of a repeating instance happens then thats also 
simple to answer (see iTIP). 

However it seems that the intent is to discuss alternative means of trying 
to represent an instance reschedule (which are not truely equivalent) for 
reasons that I just dont grok.

Why do we spend cycles discussing different means of recreating the entire 
repeating set (as opposed to actually rescheduling the just that instance) 
which have no direct bearing on how the EXPAND property is handled on a 
query?

> Only when everything is documented step by stem in writing can we solve 

What steps of the C&S workflow process are not already documented in iTIP? 

Also, I am having a hard time understanding how any of this digression 
relates to handling EXPAND on a query.  Am I the only one?

Bruce

---

From: "Michael Fair" <[email-masked]>
Date: Thu, 11 Dec 2003 16:02:59 -0800

> or for all 4 update methods.

Ok I think the easiest way to answer the first half of this message is
merely to iterate the calendar stores for UID:XXX resulting from each
method.  At the bottom I address how the assertment that there is a
problem with things being out of sync is not a problem and why the
assertment that RECURRENCE-IDs should be derived from the present state
of an instance must not be followed and to do so would be a violation
of the RFCs.

First the CS gets the original 3 instance recurring event resulting
in the following four calendar store components:

UID:XXX / SEQUENCE:0
   RRULE:FREQ=DAILY;COUNT=3

UID:XXX / RECURRENCE-ID: 1-dec-2003 at noon / SEQUENCE:0
   DTSTART: 1-dec-2003 at noon

UID:XXX / RECURRENCE-ID: 2-dec-2003 at noon / SEQUENCE:0
   DTSTART: 2-dec-2003 at noon

UID:XXX / RECURRENCE-ID: 3-dec-2003 at noon / SEQUENCE:0
   DTSTART: 3-dec-2003 at noon

Then we start manipulating the store:

Method A:
1) Recreate UID:XXX to have 2 instances on 1-Dec and 3-Dec
2) Add the 2-Dec instance back in

After step 1:
- The store has deleted all instances and created a new set
- 1-Dec and 3-Dec instances are reinitialized
- All SEQUENCEs are at 1.
- There is no 2-Dec instance

After step 2:
- The store retains 1-Dec and 3-Dec instances
- The store now also has a 2-Dec instance
    the newly created instance has RECURRENCE-ID: 2-dec-2003 at 2pm
- All SEQUENCEs are at 2.

Method B:
1) Recreate UID:XXX to have 2 instances on 1-Dec and 3-Dec
2) Add the 2-Dec instance back in

The results are exactly the same as Method A.
(The only difference between A and B was the method used
 to describe the set in step 1).

Method C:
1) Cancel the 2-dec-2003 instance
2) Add the 2-dec instance back in

After step 1:
- The store retains all information about 1-Dec and 3-Dec instances
- The store no longer has a 2-dec-2003 instance
- All SEQUENCEs are at 1

After step 2:
- The store retains the 1-dec-2003 and 3-dec-2003 instances
- The store now has a 2-dec-2003 instance
    the instance has RECURRENCE-ID: 2-dec-2003 at 2pm
- All SEQUENCEs are at 2.

Method D:
1) Properly reschedule the 2-dec-2003 instance

After step 1:
- The store retains all instances with their original RECURRENCE-ID
- The 2-dec-2003 instance begins at 3:30 and has kept the
    RECURRENCE-ID: 2-dec-2003 at noon (the original)
- All SEQUENCEs are 0 except the 2-dec instance which is 1.

> to each attendee which may not work with the next CUA looking at the

This is not a real problem as this can never legally happen.

It is a violation of the protocol to send Attendee-1 one set description for
UID:XXX and Attendee-2 a differing description for UID:XXX.

There is no allowance in iTIP or iCal for differing RECURRENCE-IDs to be in
the set of instances for the same UID between different CS' (assuming the
updates aren't still in transit or lost or something abnormal).  To do so
violates the global uniqueness rule of UIDs.

All attendees MUST be sent the same set description information for
the same UID under all circumstances.

> derived from the object it self without any knowledge of history

The RECURRENCE-IDs are derived from the set described by the object
with the UID in question but no RECURRENCE-ID property. period.
The RECURRENCE-ID MUST NEVER be derived from the instance itself.
If the instance is being stored as a separate object in the CS it
must also track the RECURRENCE-ID value originally assigned to it.

The REQUEST message that has the proper UID with the highest SEQUENCE and
no RECURRENCE-ID defines the set of legal RECURRENCE-IDs for that UID.

If you ever receive a message for a RECURRENCE-ID that is not in the
set described the most recent UID only object there is something wrong.

If there ever exists more than one set of RECURRENCE-IDs described by
the same UID/SEQUENCE pair there has been a violation of the protocol.
A UID/RECURRENCE-ID/SEQUENCE triplet does not count as a UID/SEQUENCE pair.

There will never be a REQUEST object that redefines the set of
instances and has a RECURRENCE-ID property.  To invoke the clause regarding
a UID/SEQUENCE pair the RECURRENCE-ID property can not be present.

-- Michael --

---

From: Mark Smith <[email-masked]>
Date: Thu, 11 Dec 2003 18:02:07 -0700

> must also track the RECURRENCE-ID value originally assigned to it.

How would the CS used by attendee-2 ever have that history in
order to find or track the originall and RECURRENCE-ID?

> a UID/SEQUENCE pair the RECURRENCE-ID property can not be present.

When you send and instance update you must bump the sequence, so the
set changes? correct?

---

From: "Michael Fair" <[email-masked]>
Date: Fri, 12 Dec 2003 10:17:17 -0800

"Mark Smith" <[email-masked]> wrote in message
news:[email-masked]...
> order to find or track the originall and RECURRENCE-ID?

Attendee-2 received a sequence of messages that:

   a) defined a 3peat event  (UID:XXX/SEQ:0)
   b) redefined that event to be a 2peat event  (UID:XXX/SEQ:1)
   c) added a 3rd instance (using ADD)   (UID:XXX/SEQ:2)

   None of these actions are an instance reschedule.
   All three messages are set redefining messages.

   Therefore, the "history" is a combination of messages b and c.
   If c were a REQUEST and not an ADD, then you would only need message c.

   When message b arrives, as a "REQUEST", it replaces all prior data
   associated with UID:XXX.

   When message c arrives, as an "ADD", it merges with all existing data
   associated with UID:XXX.

   By creating the "UNION" of the set described by messages b and c
   you get the set described by the object UID:XXX/SEQ:2.  The valid
   RECURRENCE-IDs would be the set of start times generated by
   enumerating that set.

   For any given event that repeats N times, there are N+1 objects in
   the CS.  N instance objects identified by UID/RECURRENCE-ID and 1
   set description object identified by the UID alone.  It is the 1
   set description object that defines the set or RECURRENCE-IDs that
   the N instance objects will use.

> When you send and instance update you must bump the sequence, so the

Yes the SEQUENCE for that instance gets bumped, but no the set doesn't
change.
You are bumping the SEQUENCE for the instance object (UID/RID) not the set
description object (UID only).

In the "proper rescheduling" (aka method D) from the prior examples
the 2-dec-2003 at noon instance still exists, it just doesn't start
on 2-dec-2203 at noon anymore.

UID:XXX/SEQ:0 defined 3 instances 1-dec, 2-dec, 3-dec.
UID:XXX/RID:2-dec/SEQ:1 updated the DTSTART of the 2-dec instance.

The 2-dec instance is still the 2-dec instance identified by the
enumeration of the set description from UID:XXX/SEQ:0.  It just
starts at a different time.

Another way to understand it is that all events are identified by
two components, the UID and RECURRENCE-ID.  For singleton events
the value of the RECURRENCE-ID is NULL and there are no RDATE/RRULE
or EXDATE/EXRULE properties.  For recurring events, the UID object
without a RECURRENCE-ID attatched is the "set definition" object
and the instances are identified with a RECURRENCE-ID that is a
member of the set described therein.  When you reschedule an instance
you don't redefine the set, you update the times of the instance
identified by the RECURRENCE-ID.

The RECURRENCE-ID is just a name assigned to the instance.  But it's
an algorithmically assigned name so that it can be automaticly chosen
and so that physical storage for the instance can be delayed until
there is a real need to actually track differences related to that
particular instance.  The RECURRENCE-ID is not a reflection of reality,
it's an identifier.  Only DTSTART can tell you when an instance
actually starts.  DTSTART is not an identifier, only UID/RECURRENCE-ID
can identify a particular instance for you.  They, by design, do
oftentimes coincide, but that's an artifact not a mandate or rule.

-- Michael --

---

From: Mark Smith <[email-masked]>
Date: Fri, 12 Dec 2003 13:32:19 -0700

>    c) added a 3rd instance (using ADD)   (UID:XXX/SEQ:2)

You did not follow the example that was sent and that was not the
question.

---

From: "Michael Fair" <[email-masked]>
Date: Fri, 12 Dec 2003 13:47:55 -0800

"Mark Smith" <[email-masked]> wrote in message
news:[email-masked]...
> You did not follow the example that was sent and that was not the

Could you please expand on this response?  Would you please clarify
for me the example you think was sent that I am not following?

Here is what I followed:

There were four total examples sent, named methods A, B, C, and D.
Attendee-2 used method A or B.  The example Doug displayed of the
Calendar store was clearly from Method B but I understood why it
could have been A or B because both methods A and B were fundamentally
the same.  The only difference was the method used to construct the
set in step b above (A used RDATE, B used RRULE).

Method A:
a) send original 3peat event
b) send redefinition to make it a 2peat event using DTSTART/RDATE
c) send an add to create the 3rd instance

Method B:
a) send original 3peat event
b) send redefinition to make it a 2peat event using DTSTART/RRULE/EXDATE
c) send an add to create the 3rd instance

What am I not following?
If you still think that I have not addressed the question can you
please rephrase it and/or expand a little more on the question so
that I might understand it and respond to it?

-- Michael --

---

From: Mark Smith <[email-masked]>
Date: Fri, 12 Dec 2003 15:30:59 -0700

> set in step b above (A used RDATE, B used RRULE).

Method B did NOT send a sequence starting at ZERO to attendee-2.
Attendee-2 was not invited until sequence:2. So no such history exists
in attende-2's CS. The ONLY way that attendee-2 can expand
the instances for the object it was invited to is from the object
it self.

I can ftp or webdav fetch a sequence:2 .ics file, or get an imip
sequence:2 method:request object all by itself. So, it can not be
true that the expansion of the sequence:2 object depends on
recurrence-id's that pre date the sequence:2 object because
attendee-2 will not have that history. Nor will any other attendee
that does not get invited in the initial request.

---

From: "Michael Fair" <[email-masked]>
Date: Fri, 12 Dec 2003 16:22:09 -0800

I've retitled the thread since we are no clearly on a different topic.

> the instances for the object it was invited to is from the object

My apologies.  The example was hard for me to follow.  I obviously did
not understand that Attendee-2 did not receive all the messages.  In the
future, if you could clear up such misunderstandings in your first reponse
it would be appreciated and cut down on the bandwidth.  Thank you.

In terms of constructing the set of RECURRENCE-IDs, enumerating the set
described by an ADD or REQUEST with a UID only message is absolute in
terms of defining the valid RECURRENCE-IDs.

So reconstructing Attendee-2's CS if it did not receive messages a or b
(SEQ:0 and 1 respectively) the CUA will look in its store for UID:XXX and
not find it.

The results are undefined.

However, consistent with iTIP's mandate to handle lost and missequenced
messages it should treat the ADD like a REQUEST and then since it obviously
is missing data (as evidneced by both a SEQ:2 and that it has just received
an ADD for a non-existant event (i.e. way out of context for the UID)) it
sends a REFRESH request to the ORGANIZER.

This results in the "2-dec-2003 at 3:30" instance being put on the calendar
immediately and requesting the missing info.  THe CS ends up with exactly
2 objects:
1) UID:XXX/SEQ:2 - a set describing an event 2-dec-2003 at 3:30
2) UID:XXX/RECURRENCE-ID:2-dec-2003 at 3:30/SEQ:2 - the instance in
question.

The RECURRENCE-ID is "at 3:30", not because it doesn't have prior info and
had to take it from the instance object, but because taking it from the
DTSTART
is the right thing to do.  An ADD is a set defining moment.  Even if it had
the prior info it would still do exactly the same thing.  It's not forced to
use DTSTART because of lack of info.  It does so because that's what the
standard says to do.

An ADD will increase the number of instances present in a recurring
event.  It figures out the _newly created_ RIDs by expanding the set
described by the ADD message and merging that set with the prior
definition.

The RID calculation is no different than using the DTSTART value to figure
out what the RECURRENCE-IDs are for a new REQUEST.  These messages
are the first time these instance have ever come into existence and
therefore use the initial DTSTART as the RECURRENCE-ID.  However, once
defined, they persist from that point forward until the RID is no longer
part of the set described by the rules of UID only object.

> sequence:2 method:request object all by itself.

But the example didn't use a method:request object, it used a method:add.
If it had used sequence:2 method:request object then it would have
redefined the whole series to be a singleton.  1-dec-2003 and 3-dec-2003
would have been erased.  There would have been no need to send a REFRESH
because it clearly has the most recent information.

> So, it can not be
> attendee-2 will not have that history.

The expansion of the sequence 2 object itself doesn't depend on prior
data, but the very nature of the "add" message certainly does.  An
ADD unlike a REQUEST is not an authoritative description of the entire
event.  It is an addendum to the existing data.  Therefore, by definition
an ADD depends on prior data.  If that data is absent the CUA should send
for a REFRESH.

So what's the question?

-- Michael --

---

From: Mark Smith <[email-masked]>
Date: Fri, 12 Dec 2003 18:00:29 -0700

> sends a REFRESH request to the ORGANIZER.

Okay, now what if it gets the sequence:1 request and the sequence:2
'add'
as shown in 'B'. As all three instances can not be represented in
one 'method request' object because the duration of all three instances
are not the same. Now the master object is at sequence:2, as is
attendee-2.

The recurrence-id's can be calculated from what attendee-2 has. Correct?
And it will be the same recurrence-id's as organizer. Correct?

---

From: "Michael Fair" <[email-masked]>
Date: Fri, 12 Dec 2003 18:41:58 -0800

I need to apologize for getting the original examples wrong again.

All of Doug's examples moved the 2nd instance from noon to 2pm
not noon to 3:30.  To remain consistent with the previous posts
I made I am going to continue using 3:30 as the start time for the
added instance.  It will still be 1.5 hours long, making the new
time be from 3:30pm-5pm (instead of being from 2pm-3:30pm).  I'm
sorry for not reading it right to begin with.

"Mark Smith" <[email-masked]> wrote in message
news:[email-masked]...
> Okay, now what if it gets the sequence:1 request and the sequence:2 'add'

This can actually be described in one method:request object as I'll
demonstrate below in response to a REFRESH request.  You are right
if what you meant was that it can't be described in 1 VEVENT component.

> And it will be the same recurrence-id's as organizer. Correct?

This sounds correct, but since we haven't rescheduled any of the instances
yet it's not all that meaningful...  I'm also not sure if you're playing
with the ordering of the messages so I'll address both orderings.  I
apologize if I'm overcomplicating your assertions, but the terse style
and my past mistakes at misunderstanding your questions makes me doubt
that I understand everything you're asking.

Both scenarios will end up with matching RIDs (matching between ORG and A2).
I just want to be sure we're clear about how/why.

I also think a more meaningful example would be to use something that
actually uses an instance reschedule in the mix since that's when DTSTART
and RECURRENCE-ID are no longer in sync, but I'm following your lead at
the moment (for instance, request - instance reschedule - add).

Scenario 1:
If A2 receives S1(request) then S2(add) then the CUA will not send a
REFRESH.

Upon receipt of S1 the CUA will store 1-Dec and 3-Dec instances along with
the
UID:XXX object in the CS all at SEQ:1.

At this point the RIDs for UID:XXX on both ends will be:
1-Dec-2003 at noon
3-Dec-2003 at noon

Then upon receipt of S2 it will store the data for instace 2-Dec, merge the
DTSTART,
RRULE/RDATE and EXRULE/EXDATE values from S2 (if there are any) with the
ones
from S1 and update the UID:XXX object with the new info.  It also update the
UID:XXX
object and the instances 1-Dec and 3-Dec to be at SEQ:2.

The RIDs for UID:XXX on both ends are now:
1-Dec-2003 at noon
3-Dec-2003 at noon
2-Dec-2003 at 3:30

If A2 receives S2 (add) then S1 (request) then the CUA will send a REFRESH.

After the receipt of S2 the RIDS in the CS for UID:XXX are:
2-Dec-2003 at 3:30

It will ignore S1 and not be synchronized until the REFRESH response
arrives.

The ORGANIZER will send the following message in response to the REFRESH:
BEGIN:VCALENDAR
  METHOD:REQUEST

  BEGIN:VEVENT
   UID:XXX
   SEQUENCE:2
   ...
   RDATE:2-dec-2003 at 3:30
  END:VEVENT

  BEGIN:VEVENT
   UID:XXX
   RECURRENCE-ID:2-dec-2003 at 3:30
   SEQUENCE:2
   ...
   DTSTART: 2-dec-2003 at 3:30
   DTEND: 2-dec-2003 at 5pm
   ...
  END:VEVENT

END:VCALENDAR

(As an aside, had the ORGANIZER done a normal reschedule, then the RDATE
 and RECURRENCE-ID values would be "at noon" and the SEQUENCE would most
 likely be 1.  Other then that, the response would be the same.)

After receipt of the REFRESH response the two CS' would be in sync.

-- Michael --

PS I am concerned that at some point in this thread you might try and bring
A1 who received the proper instance reschedule message back into this and
say
the RIDs don't match.  However, that can't legally happen because it would
violate the uniqueness of UID:XXX and is an entirely different conversation.

---

From: Mark Smith <[email-masked]>
Date: Sat, 13 Dec 2003 11:14:48 -0700

> if what you meant was that it can't be described in 1 VEVENT component.

However you did not do a request+add below which was the question.
You did a request + single instance reschedule.

> yet it's not all that meaningful... 

As this topic is part of EXPAND:TRUE debate - yes it is valid.

Your example below is not the one asked.

---

From: "Michael Fair" <[email-masked]>
Date: Sun, 14 Dec 2003 11:52:40 -0800

"Mark Smith" <[email-masked]> wrote in message
news:[email-masked]...
'add'
> You did a request + single instance reschedule.

I'm not quite sure how to respond to this.
I assure you that I responded accurately and completely to a request+add.

You have neither corrected me by putting forth your expectation nor have
you done anything other than just assert the belief that I didn't respond
to the example when I have.

If you have a different answer I ask that you present it and refrain from
just stating that you believe someone's answer isn't correct.

If you do not know what the correct answer should be then you should state
that in your email.  I believe what I believe and I can back up what I've
presented (it's a very long email which I'm really inclined to create unless
it really needs to be done).  You saying that I didn't answer the question
is not going to help me understand the question you think is being asked or
how my answer is somehow invalid.

> Your example below is not the one asked.

The question asked was a REQUEST followed by an ADD.
The first response in my email covered that.

Because of my uncertainty about what you were asking I decided to
cover my bases and also show what would happen if A2 received an
ADD as the first message in the sequence.

You said that A2 didn't see the event until SEQ:2.
SEQ:2 was an ADD message.  Therefore it would generate REFRESH request
when the CUA received it.

The ORGRANIZER would then respond with a single REQUEST message that
encapsulated the entire current state of UID:XXX.

This "current state" would include the merged sets of events from the
SEQ:1 state and the "ADD message" resulting in the RDATEs described.
As you pointed out, the second instance is 1.5 hours long and not 1 hour
long.
This cannot be represented in a single VEVENT component.
The method outlined in the standard for relaying per instance specific data
is to use multiple VEVENT components.  You may use multiple VEVENT
components
in the same message if and only if all VEVENT components reference the same
UID.

What was sent below is not a REQUEST followed by a RESCHEDULE.  That would
be
two separate and distinct messages.  What was sent is a single REQUEST
message.
Describing the SEQ:2 state of UID:XXX.  Generated in response to a REFRESH
request from the CUA when it received the "ADD" message.

> >    DTSTART: 2-dec-2003 at 3:30

How is this not the example given?
How is this not the question asked?

-- Michael --

---

From: Mark Smith <[email-masked]>
Date: Sun, 14 Dec 2003 13:58:03 -0700

> I assure you that I responded accurately and completely to a request+add.

Re check what you send, there is NOT a ADD.

> How is this not the example given?

The example given was ADD which is NOT the object above.
See the original post and section "3.2.4 ADD" in iTIP.

---

From: "Michael Fair" <[email-masked]>
Date: Sun, 14 Dec 2003 14:29:19 -0800

"Mark Smith" <[email-masked]> wrote in message
news:[email-masked]...
> See the original post and section "3.2.4 ADD" in iTIP.

I think you are misunderstanding what object it is that's being
described here.

Here's what happened:
Organizer sends an ADD
A2 having determined that it missed something requests a REFRESH
Organizer sends a REQUEST in response to the REFRESH

The object above that you keep saying is not an ADD, but imply
should be an ADD, is the response object from the ORGANIZER to
A2's REFRESH request.

It is not an ADD (just as you said) and should not be an ADD
(as you are implying).

The above object is a recurring event that has per instance data
which needs to be communicated.  The above object is the proper
object with which describe the complete state of UID:XXX at SEQ:2.

What else could it be?

-- Michael --

---

From: Mark Smith <[email-masked]>
Date: Sun, 14 Dec 2003 16:20:26 -0700

> I think you are misunderstanding what object it is that's being

So the question (restated) is:

  Once attendee-2 gets 'B' which is an 'add' (not some other things).
  As that is a valid way to invite an attendee.

  Do you agree that once 'B' is complete then attendee-2 can
  only get the recurrence-id's from what it has those objects
  described in 'B'. As attendee-2 attendee-2 will never have
  the sequence:0 object.

A 'refresh' would only return 'A', 'B' or 'C' and not 
the sequence:0 iTIP message.

So it can not be true that you have to have the history
of an object to get the recurrence-id's. It also can 
not be true that the recurrence-id's are tied to the
original (0) object. As it would be impossible to 
change an object that was later added with the
add method. The attendee must be able to expand
the 'A', 'B', or 'C' objects from themselves.

---

From: "Michael Fair" <[email-masked]>
Date: Mon, 15 Dec 2003 02:20:10 -0800

"Mark Smith" <[email-masked]> wrote in message
news:[email-masked]...
>   As that is a valid way to invite an attendee.

Where in rfc2446 did you get that?

As far as valid invites go, I only see one "valid" way to do an invite:

3.2.2 REQUEST

   The "REQUEST" method in a "VEVENT" component provides the following
   scheduling functions:

     -  Invite "Attendees" to an event;

Further, section 3.2.4 ADD does not specify what a CUA _must_ do if
it receives an ADD for a UID that isn't in the store.

3.2.4 ADD:
   ...

   The "UID" must be that of the existing event. If the "UID" property
   value in the "ADD" is not found on the recipient's calendar, then the
   recipient SHOULD send a "REFRESH" to the "Organizer" in order to be
   updated with the latest version of the "VEVENT".  If an "Attendee"
   implementation does not support the "ADD" method it should respond
   with a "REQUEST-STATUS" value of 3.14 and ask for a "REFRESH".

That very clearly states that ADD is not a valid method of inviting a
user to a set of recurring events.  Just because a CUA could safely get
by utilizing the information that is in the message (which the RFC
encourages) does make it a valid method.

Further, let me stress _could_.
Another legal thing for the CUA to do is to throw the message out and
just send a REFRESH request only.

The only section that is explcitly blessed as a valid invite is REQUEST.

>   described in 'B'. As attendee-2 attendee-2 will never have

Yes and then no.
Once B is complete a generous CUA will only be able to put onto the
calendar that which the ADD message describes.
However, it sent the REFRESH request and therefore has a REQUEST message
coming its way.  This REQUEST message has all the data for every currently
valid instance in it.  So I disagree that A2 will never see the prior info.

I want to stress that A2 will never see and has no need to see the SEQ:0
object to construct the most recent version of UID:XXX.  So the sentence
that A2 will never see the SEQ:0 info is true, but the statement that it
will never see earlier information is false.  A2 will see the SEQ:1 info.

A2 needs only to receive information from SEQ:1 forward because SEQ:1 is
the most recent redefinition of the entire set.

In our example, once SEQ:1 has been created by the ORGANIZER, the SEQ:0
object
becomes completely obsolete and totally useless and irrevocably consigned to
be forgotten by all parties interested in UID:XXX.  At that moment, the only
necessary information comes from the SEQ:1 version of UID:XXX.  The same is
not true of the SEQ:2 ADD though.

It is the combination of the SEQ:1 REQUEST and the SEQ:2 ADD that make
up the current state of UID:XXX.

That combined state can be encapsulated in a single REQUEST message, and
that SEQ:2 ADD message will never be sent to any interested party ever
again.  It will be sent once and only once to the ATTENDEES and if they
have a problem with it that's tough.  The ORGANIZER will never generate
it for them again as they have no way to ask for that.

> the sequence:0 iTIP message.

I'm not sure I'm following you...
Above I thought you were referring to message B, here I'm not sure
what A,B, and C are...
Here's what I can say though.

A REFRESH, once methods A,B or C have completed, will send the exact same
response.  The single REQUEST message from my prior email.  Method D
(the proper method) however would give the 2nd instance a different
RECURRENCE-ID but otherwise would be the same.

In methods A, B and C, the SEQ:0 version of the object is utterly and
completely useless.  There is no need to see it... ever... by anyone...
The SEQ:1 version is the version that has all the valid data to be
combined with SEQ:2.

A REFRESH would send the combined status of SEQ:1 and SEQ:2 as its response.

> the 'A', 'B', or 'C' objects from themselves.

The "original" is not the same as SEQ:0.
The "original" is the most recent REQUEST that does not contain
a RECURRENCE-ID for UID:XXX.

SEQ:0 is a REQUEST that does not contain a RECURRENCE-ID property.
Therefore, it is the "original" at that time.

SEQ:1 is also a REQUEST that does not contain a RECURRENCE-ID
property.  Further, it is more recent than SEQ:0, and therefore
it is the new "original" definition of the RECURRENCE-IDs for
UID:XXX.

SEQ:2 is then an ADD, therefore it gets combined with the most
recent version of the original UID:XXX, which in this case is
the SEQ:1 version.

As a thought experiment, if SEQ:1 had been an instance reschedule
instead of a REQUEST without a RECURRENCE-ID, then the most recent
"original" definition would have been SEQ:0 and then the information
contained in SEQ:0 would be retained.  As the example was written
however, at the moment of SEQ:1's incarnation, SEQ:0 become completely
obsolete and complete unnecessary.  The pivotal piece of prior info
for the definition of RECURENCE-IDs was no contained in SEQ:1.

How we doing?  Making progress?

-- Michael --

---

From: Mark Smith <[email-masked]>
Date: Mon, 15 Dec 2003 10:53:23 -0700

> As far as valid invites go, I only see one "valid" way to do an invite:

That was the question that was asked repeatedly (B)
which was a request + add, which is also the subject
line you keep replying to. I am now convinced you have no
intention of participating in a technical debate about
this issue.

If there is anyone that thinks that you can get 'B'
and still thinks that you have to have prior history
of an object in order to extract the recurrece-id
on expand?

If there are 20 changes to a uid, it is insane to expect
that the next person added will have to say yes/no to
19 old dates, reply to them, only to finaly get vevent
request 20 and then possibly counter. How would they
know that they can not counter the first 19 until they
get a no, accept and then get another sequence. I do not
read that into any rfc or draft.  I have over the last
two months read the entire list archive and see discussions
about using 'add' to describe a single instance that is part
of a set that has a different location. That seems to have
been one purpose to 'add'.

---

From: "Michael Fair" <[email-masked]>
Date: Tue, 16 Dec 2003 20:55:20 -0800

I vote we continue this offline.

It's obvious to me that we aren't understanding each other.
I'm certainly not proposing the solution you've implied results
from what I presented and there's no need, in my opinion, to
have the WG watch us talk past each other.

Let's get on the same page, and if there is a clarification
or resolution we can come back to this thread then.

-- Michael --

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

---

From: Doug Royer <[email-masked]>
Date: Wed, 17 Dec 2003 11:33:19 -0700

Let try this another way - BOOKED:

Your CUA connects to a public CS that serves up your favorite Symphony
to see their schedule. These are BOOKED entries in that CS.
There is no-METHOD, No-REQUEST, No-REPLY.

BEGIN:VCALENDAR:
...
...
BEGIN:VEVENT
UID:byBSO.org
SEQUENCE:25
...
DTSTART:December 19, 2003 7:30 PM
DTEND: December 19, 2003 9:30 PM
...
RDATE:December 20, 2003 3:00 PM
RDATE:December 20, 2003 7:30 PM
RDATE:...
...
END:VEVENT

Your CUA will NEVER be able to get the history of that calendar.
So, if those that think that RECURRENCE-ID depends on the
history of the UID pre SEQUENCE:25.  How could you
ever calculate the RECURRENCE-ID's? You could not.

The expansion of RECURRENCE-ID's can not depend
on anything except the object the CS has - and only
that object.

--

---

From: "Michael Fair" <[email-masked]>
Date: Wed, 17 Dec 2003 22:36:57 -0800

"Doug Royer" <[email-masked]> wrote in message
news:[email-masked]...
> on anything except the object the CS has - and only

Certainly, but how does this relate in the context of an ADD
as Mark was suggesting?

If I had subscribed to receive iMIP updates from said symphony
group, and the first message I ever saw was an ADD at SEQ:26,
then it will not contain the above information from SEQ:25.  Right?

Further, in keeping with just "the most recent information is all
I need", I have absolutely no use for objects with SEQ:0-24 as Mark
again seemed to imply.

-- Michael --

---

From: Mark Smith <[email-masked]>
Date: Thu, 18 Dec 2003 09:41:33 -0700

> I need", I have absolutely no use for objects with SEQ:0-24 as Mark

No you have that backwards. I have always said that the recurrence-id
has nothing to do with old information about a uid.

---

From: "Michael Fair" <[email-masked]>
Date: Thu, 18 Dec 2003 10:37:04 -0800

"Mark Smith" <[email-masked]> wrote in message
news:[email-masked]...
> has nothing to do with old information about a uid.

Oh great!  I knew we just weren't understanding each other.
Glad we agree. :)

So I guess the only question marks left on behavior that I'm not certain
we agree on have to do with what is considered a "set-redefining" moment
for recurring events, each recurring instance in addition to the UID only
object tracking their own SEQUENCE values, and as a fallout of those two
what the resulting RIDs are for a given SEQUENCE of messages and what the
the authoritative SEQUENCE for a particular UID is.

However that should probably be discussed in a separate thread as we
would be moving way off the topic.

-- Michael --