Support calendar sharing (draft-pot-caldav-sharing)

[tobixen]

We should consider supporting draft-pot-caldav-sharing as it's supported by some servers. Some AI-generated information below the line.

---

⚠️ This issue is AI-generated (Claude Opus 5 via Claude Code) on behalf of tobixen, from the prompt: "We need an issue for 3.2 (which is related to 1.1)"

Tracking issue for section 3.2 of docs/design/FEATURE_COMPLETE_ROADMAP.md. Sibling of #699 (RFC 3744 ACL), which says: "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, but eventually research should be done on the draft proposal as well." This is that issue.

Relationship to #699

The two are competing answers to the same user request — "let my colleague see my calendar", asked in #202 and closed in 2022 with "there is no support for granting access rights through the CalDAV protocol".

• Implement WebDAV ACL operations on calendars (RFC 3744) #699 / RFC 3744 is the real standard, and is thinly implemented.
• This / draft-pot-caldav-sharing is an expired individual draft, and is what the servers people actually use have implemented — Apple Calendar Server, and the SabreDAV family (Baikal, Nextcloud) through the http://calendarserver.org/ns/ namespace.

They are not redundant: ACL grants privileges on a collection, sharing sends an invitation that the sharee accepts or declines, and gives them their own bound copy with its own alarms. A user asking to "share a calendar" almost always wants the second one.

Suggested decision, to be made in one place rather than twice: research this draft first, since it is cheap to probe against the docker test servers and tells us what the ecosystem actually does. Then decide whether ACL, sharing, or both is worth implementing.

Current state

Nothing. No calendarserver.org namespace in caldav/elements/, no sharing properties, no notification-collection support.

One naming hazard worth flagging up front: accept_invite(), decline_invite() and tentatively_accept_invite() already exist on CalendarObjectResource and mean iTIP event invitations (RFC 6638). Sharing invitations are a different concept on a different object. Whatever API this gets must not be confusable with the existing methods — calendar.accept_share_invite() or similar, never an overload of accept_invite.

Tasks

• Research: read the draft, and probe what the docker test servers actually implement
• Elements for the http://calendarserver.org/ns/ namespace — invite, share, invite-reply, shared-owner, access levels
• Detect that a calendar is shared, and whether we are the owner or a sharee
• Enumerate calendars shared with the user
• Share a calendar with another user (read / read-write)
• Accept and decline share invitations, via the notification collection
• Remove share access
• Per-user calendar data — separate alarms per sharee
• Compatibility hints, so tests skip rather than fail
• Documentation, since this is the answer to a FAQ (Is it possible to share calendars with another user using caldav? #202)

Caveats

• It is an expired draft, never standardised. Implementing it means tracking whatever each server actually does, not a spec.
• Google and Microsoft do sharing through their own APIs and are out of reach either way.
• Whether the notification-collection dance can be made to feel reasonable in a synchronous client library is an open question.

Spec: https://datatracker.ietf.org/doc/html/draft-pot-caldav-sharing

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