Re: DTSTART for recurrence instances

[Bruce_Kahn@xxxxxxxxxxxxxxxx]

Doug wrote on 12/04/2003 04:10:11 PM:
> > 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.
> 
> 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.

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.

> > With RECURRENCE-ID consigned to the role
of an identifier
> > it clearly falls to DTSTART to represent a recurrence instance's
> > effective start time.
> 
> 2445 is talking about a reschedule object not what 2446 calls the
master 
> 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...

> > 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.
> 
> 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.
[Snip]
> 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.

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

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

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: Bruce_Kahn@xxxxxxxxxxxxxxxx
Messaging & Collaboration            
    Phone: 978.399.6496
IBM Software Group                
        FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law...