Re: DTSTART for recurrence instances

On 2 déc. 03, at 20:01, Doug Royer wrote:
> Because you mixed without quoting the author of the comments, I can not
> figure out which comment your are asking about or commenting on in
> your reply.
> Perhaps your GUI processes leading spaces/tabs differently than mine.

Sorry, I copied some rich text and forgot to reforce everything in 
plain text.
Here is a repost.

On 2 déc. 03, at 03:14, Doug Royer wrote:
> Craig Johnson wrote:
>
>> Unless I have misunderstood, this seems contrary to common
>> practice.  Some clarification regarding DTSTART value for
>> recurrence instances would be helpful.
>>  Suppose we have a recurring event for every Monday in January:
>>  BEGIN:VEVENT
>> SUMMARY:Every Monday in January
>> DTSTART:20040105T100000Z
>> DTEND:20040105T110000Z
>> UID:A-Unique-ID
>> RRULE:FREQ=WEEKLY;UNTIL=20040131T170000Z;
>>  INTERVAL=1;BYDAY=MO;WKST=SU
>> ...
>> END:VEVENT
>>  Now suppose we SEARCH for that event with Expand:TRUE:
>>  BEGIN:VQUERY
>> EXPAND:TRUE
>> QUERY: SELECT * from VEVENT
>>   WHERE UID = 'A-Unique-ID'
>> END:VQUERY
>>  What will be returned in the query?  Will the DTSTART
>> (and DTEND) of each recurrence instance be the same as
>> the 'master' (as in column 1 below)?
>
> Yes. And each object returned will have a RECURRENCE-ID property
> added with its value set to the effective start time of that instance 
> of the component.
> All objects returned will have the same DTSTART /  [ DTEND | DURATION ]

2445 and 2446 mention RECURRENCE-ID as a way to actually identify 
component instance more than for actual date for the event. For 
example, in RFC 2445, sect 4.2.7:
     'Component instances are identified by the combination of "UID", 
"RECURRENCE-ID", and "SEQUENCE"

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

RFC 2446, sect 2.1.5
     To reference an instance of a recurring component, the primary key 
is composed of the "UID" and
     the "RECURRENCE-ID" properties.

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.

> IN 2445 (EXDATE) (a similar section for EXRULE also exists):
>
>   The "EXDATE" property can be used to exclude the value specified in
>   "DTSTART". However, in such cases the original "DTSTART" date MUST
>   still be maintained by the calendaring and scheduling system because
>   the original "DTSTART" value has inherent usage dependencies by other
>   properties such as the "RECURRENCE-ID".

This is coherent in that case: making an exception on original DTSTART 
with an EXDATE must not change the other, unrelated component instances 
in the recurrence, as the RECURRENCE-ID is using the date where an 
occurrence should happen in the recurrence. The recurrence definition 
must not change for this to be possible, this include the RRULE of 
course, and the original DTSTART.  This has been corroborated by Frank 
Dawson and Derik Stenerson recently:

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

RFC 2445 in 4.8.5.1 also mentions:
      The "DTSTART" property defines the first instance in the 
recurrence set.
But note that this is in the context of a component definining the 
recurrence (RRULE, EXDATE, RDATE, EXDATE, ...), not in the context of a 
RECURRENCE-ID identified component instance. Actually, DTSTART 
definition (4.8.4.2) only refer to the VEVENT component:
     Description: Within the "VEVENT" calendar component, this property
    defines the start date and time for the event.

So it seems somewhat unrelated to the DTSTART issue within a 
RECURRENCE-ID identified component from Craig's example.

> The only time the DTSTART is not the same as the master is when
> specifying a change to a single instance as described in iTIP 3.7.1
> and 4.4.2 . Then the master is not altered, just the specifc object
> declaring the change details.

I think the issue comes from ambiguities like:

RFC 2445 - 4.8.2.3 Date/Time Due
    Description: The value MUST be a date/time equal to or after the 
DTSTART value, if specified.
RFC 2446 - 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.

Even if the text mention the original DTSTART as the reference point, 
it does not mention the actual value of the DTSTART/DUE values in an 
identified recurrence instance. The section is actually quite clear 
when it differentiates the 'recurring instance' and the initial VTODO 
component.

And also:

RFC 2245 - 4.6.6 Alarm Component
    In an alarm set to trigger on the "START" of an event or to-do, the
    "DTSTART" property MUST be present in the associated event or to-do.
RFC 2445 - 4.8.6.3 Trigger
     If the trigger is set relative to START, then the "DTSTART" property
    MUST be present in the associated "VEVENT" or "VTODO" calendar
    component.

In all these cases, the property is defined relative to the DTSTART (or 
DTEND) of the associated component. If we assume that the DTSTART is 
the DTSTART of the original event, how can we express an iTIP ADD 
("especially useful if there are instance-specific properties to be 
preserved in a recurring "VEVENT"" -  idem for VTODO) or COUNTER and 
referring to actual DTSTART instance in that case and to global DTSTART 
in another case ?

>> Or will DTSTART and DTEND have the 'effective' value for the 
>> recurrence instance
>> (as in column 2 below)?
> No. Why would there need to be a new property (RECURRENCE-ID)?
> It could be done with a boolean (this is a single instance) to DTSTART
> if that were true.

Why introducing a new parameter if the existing model is sufficient ?

>> The expected result, intuitively and instinctively, is Column 2.
>> The prior discussion thread implied that Column 1 is correct
>> (along with some discussion explaining that this is why DTSTART
>> is not always suitable for use in QUERYs, whereas RECURRENCE-ID
>> is more suitable).
>
> DTSTART is a fixed value for any specific revision of a UID.

I can't see anything in 2445/2446 that explicitly states that (see 
comments above about recurrence instances).

> RECURRENCE-ID is calculated only when the object is expanded.

I agree with that.
However (DUE case above), if in the query result the returned DTSTART 
is the original DTSTART, I assume that means that a DUE property will 
also be the original component DUE value ? If find that worrying for 
two reasons:
    - EXPAND=TRUE is convenient for CUA that don't want or can't handle 
the complete recurrence model (PDA or cell phones were cited in earlier 
discussions). That means that the query results will not be immediately 
usable. I'm also worried with the case of a original event having an 
alarm and a specific instance having a  different alarm (a case likely 
to be related to the ALARMID/SEQUENCE discussion).
    - Semantics of the returned VEVENT/VTODO recurrence instances seem 
to be debatable, because of the parts of RFC 2445  that mentions 
recurrence instances as 'self sufficient' components (see above, 
4.8.4.1, 4.8.4.4).

>>  This is a fundamental issue that impacts interoperability. I'd like 
>> to hear others view on this issue:
>> What is the value of DTSTART for recurrence instances?
>>   - DTSTART is the same as the 'master'.
>>   - DTSTART is the 'effective' value for the instance.

I admit I also understand it as the effective value for the instance 
component, instance which is identified through 
UID/RECURRENCE-ID/SEQUENCE properties.

Ol.