WebDAV Collection Synchronization

Collection Synchronization for WebDAV solves the problem every client of a remote folder eventually hits: the only way to find out what changed is to list everything again and compare. RFC 6578 gives the collection a sync-token, an opaque value that identifies its state, and a sync-collection REPORT that takes the old token and returns the members that changed plus a new token. The client keeps one string per folder and never walks the tree twice.

• sync-token on the collection - A DAV: property any client can read; it changes whenever the collection or a member does.
• sync-collection REPORT - Given a token, returns added and modified members with the properties the client asked for, and removed members as 404 entries. Given no token, returns everything, which is the initial sync.
• Depth and truncation - A server may limit results and tell the client to come back, so a huge change set does not become a huge response.
• The engine under CalDAV and CardDAV - Calendar and contact clients from Apple, Google and the open-source suites use it to stay in sync; it is why those clients do not re-download a calendar on every refresh.

I split this out from WebDAV because it is the part of the WebDAV family that keeps getting reinvented. Microsoft Graph’s delta query, Google Drive’s changes.list with a start page token, Dropbox’s list_folder/continue cursor and JMAP’s changes method are all this report with different spelling. When the Model Context Protocol Filesystems charter asked in 2026 how a write should interact with change notification, and contributors asked for a way to learn what else changed without calling list again, the fourteen-year-old answer was a token and a report. Specifying it inside JSON-RPC is work; deciding what it should do is not.