[Ietf-caldav] Alternative to splitting out components

Cyrus Daboo daboo at isamet.com
Fri Aug 20 13:57:26 PDT 2004

Hi folks,
I would like to propose an alternative model to the one currently specified 
in Lisa's draft. Specifically I would like to not have each individual 
component in an iCalendar object split out into its own WebDAV resource on 
the server. i.e. we would only deal with entire iCalendar files as WebDAV 

There are several reasons why I would prefer this approach:

- There is a significant added complexity in having each component be a 
separate resource. Clients will have to maintain the uris, etags etc for 
each component in addition to all the usual iCalendar data. Reports (e.g. 
'time-range-events' example in the draft) from the server will have to 
include the uri for each component resource that is returned, which means 
that the response to such a report will likely have to be XML, rather than 
a simple iCalendar object with the matching components etc. Updating 
multiple components requires separate HTTP requests for each resource, so 
large changes to a calendar (e.g. disconnected sync operations) can be 

- By keeping the iCalendar data in one file, we gain the benefit that 
existing http and webdav clients can use PUT/GET etc operations to get the 
calendar in the way that a lot of clients do already - i.e. existing 
http/webdav clients would interoperate.

We would still have reports (such as those already in the draft) for 
getting component ranges for efficient (selective) component downloads. 
However we would need a way to do selective changes to to components in the 
single iCalendar resource. I would propose using Lisa's HTTP PATCH 
<http://www.ietf.org/internet-drafts/draft-dusseault-http-patch-04.txt> as 
the solution to that, with a special application/caldiff patch format that 
we define to allow addressing of individual iCal components. The patch 
format would allow multiple components to be changed in a single request.


Cyrus Daboo

More information about the Ietf-caldav mailing list