Re: DTSTART for recurrence instances

Mark wrote on 12/08/2003 02:25:39 PM:
> > 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.
> 
> 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.

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

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
===========================================================================
Bruce Kahn                                INet: 
[email protected]
Messaging & Collaboration                 Phone: 978.399.6496
IBM Software Group                         FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law...