[Ietf-caldav] The VALARM problem
lisa at osafoundation.org
Mon Aug 23 13:45:03 PDT 2004
This is indeed a problem and I'm not sure how to deal with it. I'd
prefer if VEVENTs are non-collection resources, because if they are
collections it's more work to define what happens if you GET a VEVENT.
Does the server have to take the VALARMS and package them up as part of
the GET response?
My current approach, which hasn't been fully fleshed out in writing
yet, was to make every calendar component be a single HTTP resource for
consistency. Then each VEVENT that had one or more VALARMs associated
with it, would have a property pointing to the VALARMs. It might be a
multi-valued property like this:
This would allow multiple VEVENTs to reference the same alarm. For
example, a calendar application might suggest "standard sound alarm
fifteen minutes before event" and every time the user simply accepts
this default alarm, then the new VEVENT references the same old VALARM
containing a relative time offset. I think this is what TRIGGER
Now that this has been fleshed out a little more, does it still seem
like a bad approach? Can it be fixed up to make it a good approach? --
e.g. the proposed property could have each alarm's UID as well as the
As for the benefit of separate collections, the reasons I went with
separate collections were:
- to make PROPFIND work well. PROPFIND works best when querying a set
of items with the same properties. And PROPFIND should work well so
that clients can synchronize calendar data for offline use.
- to make access control easier -- my VJOURNALs are likely to be
private and my VEVENTS more publicly readable, so with separate
collections we can use WebDAV access control to accomplish that without
any more special thought.
- to simplify life for clients that only want to support VEVENTS even
when viewing the calendar of some other user that has more complex data
What are the disadvantages of having separate collections, or is it
just the complexity that bothers? It was my hunch that the separate
collections added complexity would be "paid for" by the advantages I
cited, but of course that depends on many factors that vary by
On Aug 23, 2004, at 11:48 AM, Cyrus Daboo wrote:
> Currently caldav has VALARMs split out into their own collection, but
> iCal has VALARMs as sub-components of VEVENTs etc. This causes a
> number of problems:
> 1) If the user fetches the VEVENT resource does that include the
> VALARM data as well?
> 2) What happens if the VEVENT resource is MOVE'd or COPY'd between
> calendar collections? Who gets to move/copy the VALARMS - the server
> or client?
> 3) What happens if the user sets an ACL on the VEVENT resource? Should
> the ACL also be set on the VALARM resource? Who does that - the server
> or client?
> 4) What happens when a VEVENT resource is deleted? Who deletes the
> corresponding VALARM resource - the server or client?
> An alternative to the current design that would better model the iCal
> data format would be to make iCal components (VEVENTs etc) collections
> rather than resources. Inside the collection would be a resource that
> represents the actual iCal data (e.g.
> /mycalendar/vevent/1234/index.ics). This would allow the concept of
> embedded components that iCal has. i.e. a VALARM component collection
> could be included inside the VEVENT component collection that 'owns'
> it (e.g. /mycalendar/vevent/1234/alarm1/index.ics would be the
> resource for the iCal data of an alarm). This model pretty much solves
> all the issues above, except perhaps for (1). It still keeps alarms as
> separate resources which can have their own set of ACLs etc.
> At the same time I would also like to question the benefit of having
> separate collections for VEVENT, VTODO, VJOURNAL. Why not have all of
> those types of component stored at the same hierarchy level and simply
> have a component-type property that describes what they are?
> Cyrus Daboo
> Ietf-caldav mailing list
> Ietf-caldav at osafoundation.org
More information about the Ietf-caldav