[Ietf-caldav] The VALARM problem

[Cyrus Daboo]

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