Support calendar sharing (draft-pot-caldav-sharing)
メンテナーはふだん 1 日以内に返信
まだ誰も着手していません。
評価
- 難易度
- 5/5
- 見積もり時間
- 1週間以上
- 初心者へのやさしさ
- 25/100
- issue の種類
- 機能追加
- 明瞭さ
- おおむね明確
- 活発さ
- 静か
- 技術スタック
- python
調査の方向性
Start with the draft-pot-caldav-sharing spec and the roadmap entry in docs/design/FEATURE_COMPLETE_ROADMAP.md, then probe the Docker test servers as the issue suggests. This issue is research and scope-setting before implementation: document what the servers support and decide whether sharing, ACLs, or both should be pursued; the implementation tasks are broad and no files or tests are named.
索引モデルが issue の本文から書いたものです。
説明
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".
- #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 (#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.
- 主要言語
- Python
- スター
- 412
- フォーク
- 113
- 平均マージ
- 22時間 15分
- マージ済み PR（30日）
- 44
環境構築
- Dockerfile・Docker Compose ファイルなし
- プルリクエストのテンプレートなし
- コントリビューションガイドを読む
はじめの一歩
- issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
- 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
- リポジトリをフォークし、ブランチを切って変更します。
- issue 番号を参照したプルリクエストを送ります。
python-caldav/caldav のほかの issue
-
難易度 2/5 1〜3時間 初心者へのやさしさ 68/100
python-caldav/caldav#788 ·
メンテナーはふだん 1 日以内に返信
-
難易度 2/5 1〜3時間 初心者へのやさしさ 62/100
python-caldav/caldav#687 ·
メンテナーはふだん 1 日以内に返信
-
難易度 5/5 1週間以上 初心者へのやさしさ 35/100
python-caldav/caldav#786 ·
メンテナーはふだん 1 日以内に返信
-
難易度 4/5 3〜5日 初心者へのやさしさ 48/100
python-caldav/caldav#784 · コメント 1 件 ·
メンテナーはふだん 1 日以内に返信
-
難易度 4/5 3〜5日 初心者へのやさしさ 35/100
python-caldav/caldav#783 · コメント 1 件 ·
メンテナーはふだん 1 日以内に返信
python-caldav/caldav の issue をすべて見る
似ている issue
-
tunneld on Windows: Wi-Fi devices are not discovered because uvicorn runs on a ProactorEventLoopオープン
難易度 2/5 1〜3時間 初心者へのやさしさ 76/100
doronz88/pymobiledevice3#2051 ·
メンテナーはふだん 1 日以内に返信
-
Remove Datacircleオープン
難易度 1/5 1時間未満 初心者へのやさしさ 90/100
collabnix/awesome-mcp-lists#230 ·
メンテナーはふだん 9 日以内に返信
-
Groc schedules with out of range values pass config validation and fail later when the scheduler is built対応中かも @auraseb が今日担当しました。 オープン
難易度 2/5 1〜3時間 初心者へのやさしさ 78/100
-
enhancement
難易度 2/5 1〜3時間 初心者へのやさしさ 72/100
autowarefoundation/autoware_carla_scenario#342 ·
メンテナーはふだん 1 日以内に返信
-
documentation
難易度 2/5 1〜3時間 初心者へのやさしさ 72/100
ianktoo/project-monitor#14 ·