Subject: Where to use EXDATE

From: "Carsten Guenther" <[email-masked]>
Date: Thu, 24 Mar 2005 09:47:42 -0800

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

---

From: Doug Royer <[email-masked]>
Date: Thu, 24 Mar 2005 17:52:59 -0700

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.

-- 

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

               We Do Standards - You Need Standards

---

From: "Carsten Guenther" <[email-masked]>
Date: Thu, 24 Mar 2005 17:59:50 -0800

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:

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

---

From: Doug Royer <[email-masked]>
Date: Thu, 24 Mar 2005 23:05:16 -0700

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

> original occurrence and one for the changed one. I would like to know 

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.

--

---

From: [email-masked]
Date: Mon, 28 Mar 2005 17:30:35 -0500

[email-masked] wrote on 03/24/2005 08:59:50PM:
>        My question was if I need to create anEXDATE property in

No.  Exception filters (EXRULE& EXDATE) were intended to filter out instances from being creatednot remove remove them "after the fact".  So, if you makechanges to an instance of the repeating set, you would NOT remove it fromthe 'base' defintion in the iCalendar stream.  You would leave itthere and simply 'update' it with a subsequent VEVENT in the same iCalendarstream.  The slightly mangled example of this can be found in iTIP,Section 4.4.7, pp 86 & 87 where it describes the response to Bs REFRESHrequest.

> The reason I am asking is that I am doing sometesting with Evolution
> and will display two entries because of the missing EXDATE: one forthe

Im a little confused by what you aretrying to do here.  Could you describe the scenario and possibly providesome iCalendar fragments so its easier to answer your question?

Bruce
===========================================================================
Bruce Kahn                               INet: [email-masked]
Messaging & Collaboration                Phone: 978.399.6496
IBM Software Group                        FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law...

---

From: [email-masked]
Date: Mon, 28 Mar 2005 19:29:51 -0500

Doug wrote on 03/25/2005 01:05:16 AM:
> values are totally obsolete data.

Im not going to waste time revistingthis discussion and arguing misinterpretations of the standards that havealready been clarified here by the original authors, contradicting whatsome people claim to be how thing should work.  iTIP Section 2.1.5Message Sequencing defines the sequencing process:

1.  The primary key for referencinga particular iCalendar component
is the "UID" property value. To referencean instance of a
recurring component, the primary key is composedof the "UID" and
the "RECURRENCE-ID" properties.

2.  The secondary key for referencing a component is the "SEQUENCE"
property value.  For components where the "UID"is the same, the
component with the highest numeric value for the"SEQUENCE"
property obsoletes all other revisions of the componentwith
lower values.

3.  "Attendees" send "REPLY" messagesto the "Organizer".  For
replies where the "UID" property valueis the same, the value of
the "SEQUENCE" property indicates the revisionof the component
to which the "Attendee" is replying.  Thereply with the highest
numeric value for the "SEQUENCE" propertyobsoletes all other
replies with lower values.

4.  In situations where the "UID" and "SEQUENCE"properties match,
the "DTSTAMP" property is used as the tie-breaker.The component
with the latest "DTSTAMP" overrides allothers. Similarly, for
"Attendee" responses where the "UID"property values match and
the "SEQUENCE"property values match, the response with the
latest "DTSTAMP" overrides all others.

Step 1 it clearly says for repeatingentries "the primary key is composed of the"UID" and the "RECURRENCE-ID" properties".  So for repeating entries you use UID/RECURRENCE-ID/SEQUENCE withDTSTAMP being the tie breaker.  This key composition should be appliedthroughout iTIP when reading the text, otherwise much of what you do iswasted effort or inaccurate.  This was already argued here long agoand then clarified by both original RFC authors back ~Sep 2003 along withRECURRENCE-ID does not change on the instance as it moves around.

>                                     There is no 'cary-over' (except
> for METHOD:ADD) from previous UID/SEQUENCE/DTSTAMP sets. Toss allold

Unless you are changing the size ofthe repeat set (ie: METHOD:ADD) then you can simply send the "initial"definition of the relevant repeating entries plus any per-instance changesin the same iCalendar stream. If you check iTIP p. 86 you will find:

In this case both the initial
request and an additional "VEVENT" that specifies theinstance-
specific data are included. Because these are both of the sametype
(they are both "VEVENTS"), they can be conveyed in thesame iCalendar
object.

Alternately you can also send an iCalendarstream with just the current individual instance VEVENTs in it.  Receivingeither should have the same net effect on the receiving side though (wherealready sync'd entries will be a NOOP even with the newer DTSTAMP)

From Carstens original post I got theimpression he modifying the set size though (with talk of deleted entries). RFC 2445 is quiet on how to handle the case of modifyed sets in thismanner.  We added ADD late in the process and did not fully realizehow it would impact the workflow and sequencing process until afterwards.  We never had the concept of actually removing entries from the set,you could cancel them but not really remove them unless you recreated theset.  We allowed for expanding a set with ADD but never decreasingthe set with a DELETE.  This concept was just not considered whenwe did the model.   Workflow gets waaay too ugly if you try to designthat in.

For example: How do you distinguisha REPLY to a deleted instance that you then ADDed back later on with differentinvitees, data, etc?  How does a CUA actually keep track of the factthat it used to have a UID:12345, RECURRENCE-ID:20050401T140000Z that wasremoved and then later the CU recreate a _new_ instance that occurs atthe exact same date/time but it "different"?

>                                 Soyou have to create two VEVENTS

Not necessary.  The response toa REFRESH would be the VEVENT that defined the instances with all theircommon values and then the subsequent VEVENTs would be the change to eachindividual instance, if any changes at all.

>      ADD is also used to add (DTSTAMP/RRULE/RDATE)or subtract

Who would do an ADD to define an exclusiondate or exclusion rule?  Thats more work than necessary.  Youshould just not ADD it in the first place...

> If the newer VEVENT has a higher SEQUENCE, thenthe old one is obsolete

You only 'toss' "OLD instances"if the update is for the entire set, not a particular instance.  Thisis described in iTIP Section 4.4.7 Add A New Series of Instances To A RecurringEvent, pp 84 - 85.

> (A) If you are saying that UID/SEQUENCE:1 saysthere are appointments
>      A, B, C, and D. Then you get UID:SEQUENCE:2 thatsays A, C D. And
>      evolution is still showing 'B', then evolutionis not 2445/24546
>      compliant. And the organizer should never needto have sent a
>      CANCEL.

Agree

> (B) If you are saying that UID:SEQUENCE:1 saysthere are appointments
[Snip, snip]
>      and evolution is ALSO showingB-8am-Tue, then evolution is not
>      2445/2446 compliant.

Agree

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

Or you could just send a REQUEST atSEQUENCE:2 that moved B to 3PM-Tue and be done with it.  Its the basicinstance reschedule case and has no worrys about support for ADD or not.

> (D) Some send
[Snip, snip]
> All of the (A), (B), (C), and (D) are valid per2445/2446.

You could also have put RDATE:B-3PM-Tuein SEQUENCE:2 and not had to worry about ADD support or miss sequenceddata.

Or you could go whole hog ugly and send:

METHOD:PUBLISH
SEQUENCE:2
RRULE:FREQ=DAILY;COUNT=4
EXDATE:A-8am-Mon
EXDATE:B-8am-Tue
EXDATE:C-8am-Wed
EXDATE:D-8am-Thu

and then follow it up with:

METHOD:ADD
SEQUENCE:3
DTSTART:A-8AM-Mon
METHOD:ADD
SEQUENCE:3
DTSTART:B-3PM-Tue
METHOD:ADD
SEQUENCE:3
DTSTART:C-8AM-Wed
METHOD:ADD
SEQUENCE:3
DTSTART:D-8AM-Thu

or a host of really really ugly streamsof iCalendar that are equally valid if you receive and process them all. But why do all this?

The KISS approach is usually best Ithink.  A simple reschedule REQUEST for RECURRENCE-ID:B-8am-Tue toDTSTART:B-3PM-Tue works just fine I think.  If you want to representthis in a single iCalendar object it would simply be:

METHOD:PUBLISH
DTSTART:A-8am-Mon
SEQUENCE:1
RRULE:FREQ=DAILY;COUNT=4

immediately followed by:

DTSTART:B-3PM-Tue
SEQUENCE:2
RECURRENCE-ID:B-8am-Tue

in the same stream.

> And I am not even going to list the details ofhow some

Err, if you use UID/RECURRENCE-ID asthe instance location key as described in iTIP Section 2.1.5 and then applythat to iTIP 3.2.2 properly you would treat a new UID/RECURRENCE-ID REQUESTcorrectly as a new invite.  It has all the data you need to properlyadd it to your calendar and do workflow on it.  Otherwise you wouldhave to restart workflow on ALL other instances you have on your calendaralready because you'd have to do a REFRESH and then wait for the new REQUESTfor all instances to be sent.  (There is a reason we have RECURRENCE-IDon REFRESH, so you dont have to do this...)

Bruce