dav: sync-collection change enumeration for CalDAV and CardDAV #393

New Issue

2026-08-10T19:28:31Z

KofTwentyTwo commented

2026-08-10 19:28:31 +00:00

(Migrated from github.com)

Every CalDAV sync re-queries a full time window; there is no incremental sync for DAV at all, and deletions are never observed.

Implement RFC 6578 sync-collection — identical shape for CalDAV and CardDAV — behind the same CollectionSync trait as #390.

Must handle

507 truncation (RFC 6578 §3.6): 207 + 507 for the request-URI + DAV:number-of-matches-within-limits, with a sync-token valid for the partial set. "Clients MUST handle the 507 status." Without a "more pending" signal a truncated response looks complete.
Loop to convergence (§3.1) — repeat until no changes are returned.
sync-level: infinite (§3.5.1 warns sync-level: 1 is not reliable).
Discovery via DAV:supported-report-set (§3.2) — there is no DAV compliance-class token.
calendar-multiget / addressbook-multiget (RFC 4791 §7.9, RFC 6352 §8.7) to batch-fetch bodies, since sync-collection returns hrefs and ETags, not content. One GET per changed object across ten engines recreates the load problem.
CTag is a Calendar Server vendor extension, not an RFC — fallback only, not a peer mechanism.

Depends on #257 and the href/etag identity issue above.

Design: ADR 0002 · review evidence (PR #385)

Every CalDAV sync re-queries a full time window; there is no incremental sync for DAV at all, and deletions are never observed. Implement RFC 6578 `sync-collection` — identical shape for CalDAV and CardDAV — behind the same `CollectionSync` trait as #390. ### Must handle - **507 truncation** (RFC 6578 §3.6): 207 + `507` for the request-URI + `DAV:number-of-matches-within-limits`, with a sync-token valid for the partial set. *"Clients MUST handle the 507 status."* Without a "more pending" signal a truncated response looks complete. - **Loop to convergence** (§3.1) — repeat until no changes are returned. - **`sync-level: infinite`** (§3.5.1 warns `sync-level: 1` is not reliable). - **Discovery** via `DAV:supported-report-set` (§3.2) — there is no DAV compliance-class token. - **`calendar-multiget` / `addressbook-multiget`** (RFC 4791 §7.9, RFC 6352 §8.7) to batch-fetch bodies, since `sync-collection` returns hrefs and ETags, not content. One GET per changed object across ten engines recreates the load problem. - CTag is a **Calendar Server vendor extension**, not an RFC — fallback only, not a peer mechanism. Depends on #257 and the href/etag identity issue above. Design: [ADR 0002](https://github.com/KofTwentyTwo/nuncio/blob/dev/docs/adr/0002-multi-engine-sync-model.md) · [review evidence](https://github.com/KofTwentyTwo/nuncio/blob/dev/docs/reviews/2026-08-10-multi-engine-design-review.md) (PR #385)

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: KofTwentyTwo/nuncio#393