Implement WebDAV ACL operations on calendars (RFC 3744)

Start with caldav/elements/dav.py and §1.1 of docs/design/FEATURE_COMPLETE_ROADMAP.md, then inspect the existing principal_property_search implementation and compatibility hints. The issue proposes phased work: expose ACL-related properties, resolve principals, and support ACL writes with server compatibility checks. Done means the selected phases are implemented and covered by tests that account for servers without ACL support.

We should work on ways to share access to calendars for other users. The established WebDAV standard for this is RFC 3744, unfortunately it's not supported by a lot of servers. There is an expired draft-pot-caldav-sharing that may be supported by some servers - the scope of this issue is to ensure support for RFC 3744, the draft proposal has a separate issue #701.

The estimate for this issue is 40 hours.

The text below is AI-generated.

⚠️ This text is AI-generated (Claude Opus 5 via Claude Code) on behalf of tobixen, from the prompt: "Do we have any issue on RFC 3744 and ACL-operations? If not, create a feature issue for doing ACL-operations on calendars."

The library has no support for access control today: there is no acl() method, no Acl / Privilege / CurrentUserPrivilegeSet elements (caldav/elements/dav.py has only Owner and CurrentUserPrincipal), and no compatibility hints for ACL. docs/design/FEATURE_COMPLETE_ROADMAP.md §1.1 scopes this as a high-priority, 40–60h item and notes "Related issues: None currently open" — this issue is that missing tracking issue.

Closest prior art is #202 ("Is it possible to share calendars with another user using caldav?"), closed in 2022 with "there is no support for granting access rights through the CalDAV protocol". That is still true, and it is the user-facing need this would eventually serve.

Suggested scope, in order of value-per-effort

Phase 1 — read the ACL (cheap, widely supported, useful on its own)

• DAV:current-user-privilege-set via PROPFIND — "what may I do with this calendar?" This alone answers a common practical question (is this calendar read-only for me?) and needs no ACL method support on the server.
• DAV:owner is already an element but is not exposed on collections.
• Read DAV:acl and parse it into something inspectable (ACE list: principal, grant/deny, privileges, protected/inherited flags).
• DAV:supported-privilege-set so callers can discover what a server actually offers.

Phase 2 — principal resolution

• Resolve a principal from an email address / user name to a principal URL, needed before any ACE can be written. principal_property_search (RFC 3744 §9.4) already exists in the codebase for this and could be reused.
• DAV:acl-principal-prop-set REPORT to enumerate who has access.

Phase 3 — write the ACL (the risky part)

• The ACL HTTP method itself, with the standard privileges DAV:read, DAV:write, DAV:read-acl, DAV:write-acl, plus CALDAV:read-free-busy (RFC 4791 §6.1).
• Convenience helpers for the common patterns: grant read-only, grant read-write, revoke.
• Error handling for the RFC 3744 §7.1.1 precondition-failure bodies (DAV:not-supported-privilege, DAV:no-protected-ace-conflict, DAV:recognized-principal, …) — servers signal why an ACL was rejected in a machine-readable way, and that should surface as distinct exceptions rather than a generic error.

Compatibility

ACL support is very uneven, so this needs compatibility hints and server-tester checks from the start rather than bolted on afterwards:

• Something like acl.read, acl.current-user-privilege-set and acl.write, so the integration tests can skip rather than fail.
• Radicale has no ACL method; DAViCal, Cyrus and Bedework have varying degrees of support; Google and Nextcloud do sharing through their own non-standard APIs.

Why this may not be worth doing (or not doing first)

Being honest about the downside: RFC 3744 is one of the least uniformly implemented parts of the WebDAV stack. What users actually ask for is calendar sharing (#202), and on the servers most people use, sharing is not done through RFC 3744 — it is done through draft-pot-caldav-sharing (roadmap §3.2) or a server-specific API. So a fully generic ACL implementation risks being a large amount of work that raises "not supported" on the majority of real deployments.

Mitigation is the phasing above: phase 1 is small, broadly supported, and independently useful even if phases 2–3 are never finished.

RFC refs: https://datatracker.ietf.org/doc/html/rfc3744 and https://datatracker.ietf.org/doc/html/rfc4791#section-6.1

⚠️ AI-generated by Claude Opus 5 via Claude Code on behalf of tobixen.