No description
- Go 99.7%
- Shell 0.3%
Relevant specs
The core spec you want is RFC 4791 (CalDAV, published 2007) — this is the foundational CalDAV standard and what everything is built on.
But realistically, for solid Apple/Google compatibility, you need to treat three RFCs as a bundle:
| RFC | What it is | Why it matters |
|---|---|---|
| RFC 4791 | CalDAV core | The base spec — calendar collections, GET/PUT/DELETE of .ics files, REPORT queries |
| RFC 5545 | iCalendar | The data format CalDAV transports — VEVENT, VTODO, VTIMEZONE etc. |
| RFC 6638 | CalDAV Scheduling | Invite/response flow (iTIP over CalDAV) — Apple and Google both use this |
RFC 4791 + RFC 5545 + RFC 6638 is your primary reading list.
A few other RFCs worth having open as reference:
- RFC 7953 — iCalendar VALARM extensions (useful for reminders, which clients care about)
- RFC 7809 — CalDAV Time Zones by Reference (replaces embedding full VTIMEZONE blobs — both Apple and Google support this)
- RFC 6352 — CardDAV (not CalDAV, but you'll almost certainly implement both together)
Practical notes:
- RFC 4791 is deliberately WebDAV-dependent — it extends RFC 4918 (WebDAV). You don't need to read all of 4918 deeply, but the PROPFIND/REPORT/MKCOL mechanics are essential.
- Discovery is defined in RFC 6764 (using SRV/well-known URIs to find the server) — both Apple and Google use
.well-known/caldavso implement this early or clients won't auto-configure. - Apple and Google both deviate from spec in minor ways (non-standard properties, quirky scheduling behaviour), but if RFC 4791 + 6638 compliance is solid, you'll handle 95% of what they throw at you.
Bottom line: pin your implementation to RFC 4791 as the authoritative spec, read RFC 5545 alongside it as the data layer, and add RFC 6638 for scheduling. Everything else is supplementary.
https://datatracker.ietf.org/doc/html/rfc4791