Re: Where to use EXDATE

Thanks for your answer Doug, but my question was only about the use of 
EXDATE. For simplicity lets say we are only dealing with appointments 
(no attendees). I know that I need to include the second VEVENT for the 
changed occurrence and I know how to deal with SEQUENCE and 
RECURRENCE-ID. My question was if I need to create an EXDATE property in 
the base event for the changed occurrence.

The reason I am asking is that I am doing some testing with Evolution 
and our server (which currently does not create EXDATEs for changed 
occurrences, only for deleted ones). Evolution obviously expects those 
and will display two entries because of the missing EXDATE: one for the 
original occurrence and one for the changed one. I would like to know 
who is right here.

Carsten

Doug Royer wrote:

>
> I would suggest that you increment the SEQUENCE
> and send out a new object. This is the most portable way.
> The new object should use RDATEs when ever possible and not RRULE
> or EXRULE for maximum portability.
>
> If you can not describe them in one VEVENT, use two (or more)
> VEVENTs, the 2nd and up set METHOD:ADD
>
> The real problem is that ALL are valid iCal/iTIP, and most
> vendors only did one of them. Many can display
> many of the variations, but can not edit or reply
> to ones that they can not generate.
>
>
> Carsten Guenther wrote:
>
>>
>> Good day!
>>
>> I have a question about the use of EXDATE: should this property be 
>> generated for ALL exceptions (deleted and changed) or only for 
>> deleted occurrences? So in an example with one deleted occurrence and 
>> one changed occurrence (resulting in a second VEVENT) should there be 
>> one or two EXDATEs in the base VEVENT?
>>
>> Thanks,
>> Carsten
>
>