Re: Where to use EXDATE

Doug wrote on 03/25/2005 01:05:16 AM:
> There =
is no such thing as a 'base event'. that was talk on this
> mailing l=
ist that caused many to create busted implementations.
> At any point=
in time there is one valid UID/SEQUENCE and use DTSTAMP
> as a tie b=
reaker, all other UID/SEQUENCE with lower SEQUENCE or DTSTAMP
> value=
s are totally obsolete data.

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

1. The primar=
y key for referencinga particular iCalendar component
&nb=
sp; is the "UID" property value. To referencean instance of a
=
recurring component, the primary key is composedof th=
e "UID" and
the "RECURRENCE-ID&quot=
; properties.

2. The secondary key for referencing a c=
omponent is the "SEQUENCE"
property valu=
e. For components where the "UID"is the same, the
&nbsp=
; component with the highest numeric value for the"SEQUE=
NCE"
property obsoletes all other revisions o=
f the componentwith
lower values.

3=
. "Attendees" send "REPLY" messagesto the "O=
rganizer". 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. &nbsp=
;Thereply with the highest
numeric value for the &=
quot;SEQUENCE" propertyobsoletes all other
re=
plies with lower values.

4. In situations where the &q=
uot;UID" and "SEQUENCE"properties match,
&=
nbsp; the "DTSTAMP" property is used as the tie-breaker.The compo=
nent
with the latest "DTSTAMP" overrides=
allothers. Similarly, for
"Attendee" re=
sponses where the "UID"property values match and
the "SEQUENCE"proper=
ty values match, the response with the
latest &quo=
t;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 shou=
ld be appliedthroughout iTIP when reading the text, otherwise much of what =
you do iswasted effort or inaccurate. This was already argued here lo=
ng 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
> data and replace it=
with new data.

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

=
=
In this case both the initial
=
request and an additional "VEVENT" that specifies theinst=
ance-
specific data are included. Because these are both of the =
sametype
(they are both "VEVENTS"), they can be convey=
ed 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 theimpre=
ssion he modifying the set size though (with talk of deleted entries).&nbsp=
;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 wo=
uld impact the workflow and sequencing process until afterwards. We n=
ever had the concept of actually removing entries from the set,you could ca=
ncel them but not really remove them unless you recreated theset. We =
allowed for expanding a set with ADD but never decreasingthe set with a DEL=
ETE. This concept was just not considered whenwe did the model. &nbsp=
; Workflow gets waaay too ugly if you try to designthat in.
For example: How do you distinguis=
ha REPLY to a deleted instance that you then ADDed back later on with diffe=
rentinvitees, data, etc? How does a CUA actually keep track of the fa=
ctthat it used to have a UID:12345, RECURRENCE-ID:20050401T140000Z that was=
removed and then later the CU recreate a =5Fnew=5F instance that occurs att=
he exact same date/time but it "different"?

> &n=
bsp; Soyou have to c=
reate two VEVENTS
> that have the SAME UID one METHOD:PUBLISH the 2nd=
METHOD:ADD.

Not nece=
ssary. 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 (D=
TSTAMP/RRULE/RDATE)or subtract
> out (EXRULE/EXDATE) one or more inst=
ances to an existing VEVENT
> or describe unique -other- properties t=
hat can not be described
> in one VEVENT.

Who would do an ADD to define an exclusiondate o=
r exclusion rule? Thats more work than necessary. Youshould jus=
t not ADD it in the first place...

> If=
the newer VEVENT has a higher SEQUENCE, thenthe old one is obsolete
&gt=
; and ALL of its OLD instances MUST be tossed (except if the newer is
&g=
t; METHOD:ADD).

You o=
nly 'toss' "OLD instances"if the update is for the entire set, no=
t 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 ar=
e 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
> &n=
bsp;compliant. And the organizer should never needto have sent a
> &n=
bsp; CANCEL.

Agree

> (B) If you are saying that=
UID:SEQUENCE:1 saysthere are appointments
> at A=
-8am-Mon, B-8am-Tue, C-8am-Wed, D-8am-Thu.
[Snip, snip]
> and evolution is ALSO showingB-8=
am-Tue, then evolution is not
> 2445/2446 complia=
nt.

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

Or you could just send a REQ=
UEST atSEQUENCE:2 that moved B to 3PM-Tue and be done with it. Its th=
e 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=3DDAILY;COUNT=3D4
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
DTS=
TART:A-8AM-Mon
METHOD:ADD
SEQUENCE:3
=
DTSTART:B-3PM-Tue
METHOD:ADD
&nbsp=
;SEQUENCE:3
DTSTART:C-8AM-Wed
METHOD:ADD SEQUENCE:3
DTSTART:D-8AM-Thu

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

The KISS approach is usually best Ithink. A simple resched=
ule 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 i=
t would simply be:

METHOD:PU=
BLISH
DTSTART:A-8am-Mon
SEQUENCE:1
RRULE:FREQ=
=3DDAILY;COUNT=3D4

im=
mediately followed by:

&nbsp=
; 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=

> add instance using METHOD:PUBLISH and RECURRENCE-ID as
> the=
re is no RFC or draft documentation for that method.

Err, if you use UID/RECURRENCE-ID asthe ins=
tance 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 REQUESTcorrect=
ly 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 rest=
art workflow on ALL other instances you have on your calendaralready becaus=
e you'd have to do a REFRESH and then wait for the new REQUESTfor all insta=
nces to be sent. (There is a reason we have RECURRENCE-IDon REFRESH, =
so you dont have to do this...)

Bruce
=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Bruce Kahn &nb=
sp; &n=
bsp; INet: [email protected]
Mess=
aging & Collaboration &=
nbsp; Phone: 978.399.6496
IBM Software Group =
FAX: and nothing bu=
t the FAX...
Standard disclaimers apply, even where prohibited by law...=