8.2.1.3. Synchronization Process

If a client wants to support calendar data synchronization, as opposed to downloading calendar data each time it is needed, the client needs to cache the calendar object resource's URI and ETag, along with the actual calendar data. While the URI remains static for the lifetime of the calendar object resource, the ETag will change with each successive change to the calendar object resource. Thus, to synchronize a local data cache with the server, the client can first fetch the URI/ETag pairs for the time interval being considered, and compare those results with the cached data. Any cached component whose ETag differs from that on the server needs to be refreshed.

In order to properly detect the changes between the server and client data, the client will need to keep a record of which calendar object resources have been created, changed, or deleted since the last synchronization operation so that it can reconcile those changes with the data on the server.

Here's an example of how to do that:

The client issues a CALDAV:calendar-query REPORT request for a specific time range and asks for only the DAV:getetag property to be returned:

REPORT /bernard/work/ HTTP/1.1 Host: cal.example.com Depth: 1 Content-Type: application/xml; charset="utf-8" Content-Length: xxxx

The client then uses the results to determine which calendar object resources have changed, been created, or deleted on the server, and how those relate to locally cached calendar object resources that may have changed, been created, or deleted. If the client determines that there are calendar object resources on the server that need to be fetched, the client issues a CALDAV:calendar-multiget REPORT request to fetch its calendar data:

REPORT /bernard/work/ HTTP/1.1 Host: cal.example.com Content-Type: application/xml; charset="utf-8" Content-Length: xxxx

/bernard/work/abcd1.ics /bernard/work/mtg1.ics