[Ietf-caldav] The VALARM problem
daboo at isamet.com
Mon Aug 23 11:48:31 PDT 2004
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
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
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?
More information about the Ietf-caldav