Re: DTSTART for recurrence instances

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:
> Craig Johnson wrote:
>> 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.
>
> 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.
[..]
>> 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.

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 ?

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

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

> 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

Agreed.

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

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