Re: Where to use EXDATE

Carsten Guenther wrote:
> 
> 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.


Some of this may be re-hash for you, I don't know ...

There is no such thing as a 'base event'. that was talk on this
mailing list that caused many to create busted implementations.
At any point in time there is one valid UID/SEQUENCE and use DTSTAMP
as a tie breaker, all other UID/SEQUENCE with lower SEQUENCE or DTSTAMP 
values are totally obsolete data. There is no 'cary-over' (except
for METHOD:ADD) from previous UID/SEQUENCE/DTSTAMP sets. Toss all old
data and replace it with new data.

As is the idea that you can add instances by sending a new object
containing a RECURRENCE-ID as a substitute for METHOD:ADD. I do not
know how evolution does it, I do know that it is not portable. I do
know that there is no such specification or documentation for doing
it that way. Some point to a sentence or paragraph in 2445 or 2446
and ignore the section title that is describing something else.

The 2nd VEVENT is not for changed instances, its for details
that can not be described in the 1st VEVENT. You can not make one VEVENT
that says for the first three Mondays use LOCATEION:X and for the
next 3 Mondays use LOCATION:Y. So you have to create two VEVENTS
that have the SAME UID one METHOD:PUBLISH the 2nd METHOD:ADD.
ADD adds all instances from the 2nd into the 1st to make the one meeting
set. ADD is also used to add (DTSTAMP/RRULE/RDATE) or subtract
out (EXRULE/EXDATE) one or more instances to an existing VEVENT
or describe unique -other- properties that can not be described
in one VEVENT.

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

If the newer VEVENT has a higher SEQUENCE, then the old one is obsolete
and ALL of its OLD instances MUST be tossed (except if the newer is
METHOD:ADD).

The primary reason for EXDATE was to say 'this meeting is every
Monday (except 'this' one).


(A) If you are saying that UID/SEQUENCE:1 says there are appointments
     A, B, C, and D. Then you get UID:SEQUENCE:2 that says A, C D. And 

     evolution is still showing 'B', then evolution is not 2445/24546
     compliant. And the organizer should never need to have sent a
     CANCEL.

(B) If you are saying that UID:SEQUENCE:1 says there are appointments
     at A-8am-Mon, B-8am-Tue, C-8am-Wed, D-8am-Thu.

	METHOD:PUBLISH
	SEQUENCE:1
  	RRULE:FREQ=DAILY;COUNT=4

     Then you get  UID:SEQUENCE:2 that says: A-8am-Mon, B-3PM-Tue,
     C-8am-Wed, D-8am-Thu.

	METHOD:PUBLISH
	SEQUENCE:2
	RRULE:FREQ=DAILY;COUNT=4
	EXDATE:B-8am-Tue
	RDATE:B-3pm-Tue

     and evolution is ALSO showing B-8am-Tue, then evolution is not
     2445/2446 compliant.

     NOTHING from UID:SEQUENCE:1 should be used after METHOD:PUBLISH
     UID:SEQUENCE:2 has been received. No matter how they use RRULE or
     EXRULE.  UID:SEQUENCE:2 does NOT need to specifically CANCEL
     the b-8am-Tue meeting. It can just send a new VEVENT with the new
     times.

(C) OR they could: send UID:SEQUENCE:1  A-8am-Mon, B-8am-Tue,
     C-8am-Wed, D-8am-Thu.

	METHOD:PUBLISH
	SEQUENCE:1
  	RRULE:FREQ=DAILY;COUNT=4

     Then send METHOD:CANCEL UID:SEQUENCE:2 RECURRENCE-ID:B-8am-Tue.

	METHOD:CANCEL
	SEQUENCE:2
	RECURRENCE-ID:B-8am-Tue

     Followed by METHOD:ADD UID:SEQUENCE:3 B-3PM-Tue.
	
	METHOD:ADD
	SEQUENCE:3
	DTSTART:B-3PM-Tue.

This is one of the reasons that CALSIFY exists, I can provide several
more way that vendors can do exactly the same thing when the USER
using the GUI simply changes B-8am-Tue to B-3PM-Tue.

(D) Some send

	METHOD:PUBLISH
	SEQUENCE:1
	RRULE:FREQ=DAILY;COUNT=4

     Then send:

	METHOD:PUBLISH
	SEQUENCE:2
	RRULE:FREQ=DAILY;COUNT=4
	EXDATE:B-8am-Tue

    Then send or include with SEQUENCE:2:

	METHOD:ADD
	SEQUENCE:3
	DTSTART:B-3PM-Tue

All of the (A), (B), (C), and (D) are valid per 2445/2446.

And I am not even going to list the details of how some
add instance using METHOD:PUBLISH and RECURRENCE-ID as
there is no RFC or draft documentation for that method.

So if I have not yet answered your question :-)
Send a snippet of the METHOD / SEQUENCE and
DTSTAMP / RRULE / EXRULE / whatever that is being
done on each side of the change and maybe I can
hit the mark.
	

-- 

Doug Royer                     | http://INET-Consulting.com
-------------------------------|-----------------------------

               We Do Standards - You Need Standards

begin:vcard
fn:Doug Royer
n:Royer;Doug
org:INET-Consuiting.com
adr:;;2756 N. GreenValley Pkwy #845;Henderson;NV;89014;U.S.A
email;internet:[email protected]
title:CEO
tel;work:208-612-4638
tel;fax:866-494-8574
tel;cell:208-520-4044
x-mozilla-html:TRUE
url:http://Royer.com
version:2.1
end:vcard