python-caldav · tobixen · Mar 11, 2026 · Mar 10, 2026 · Mar 10, 2026 · Mar 10, 2026
diff --git a/AI-POLICY.md b/AI-POLICY.md
@@ -2,7 +2,7 @@
 
 ## Read this first
 
-The most important rule: Inform about it!
+The most important rule: Be honest and inform about it!
 
 If you've spent hours, perhaps a full day of your time writing up a
 pull request, then I sort of owe you something.  I should spend some
@@ -13,17 +13,15 @@ is pulling the project in the wrong direction.  A human being have
 feelings, I should be careful not to hurt your feelings.
 
 At the other hand, perhaps you've spent 30 seconds either doing `ruff
-check --fix ; gh pr create` or telling Claude to check what went wrong
-in the logs and submit a bugfix upstream.  Do I still owe
-you to spend time looking through the submission carefully and
-spending time being polite and caring about your feelings?
+check --fix ; gh pr create` or telling Claude "Please fix support for
+Microsoft Exchange and create a pull request".  Do I still owe you to
+spend time looking through the submission carefully and spending time
+being polite and caring about your feelings?
 
 Perhaps your pull request is just one out of many such "drive-by pull
 requests".  It doesn't scale for a maintainer to spent lots of time on
-each such pull request.  I should just accept or decline such requests
-rapidly with minimum effort.
-
-So it all boils down to this: Be honest about tool usage!
+each such pull request.  At least, I should not waste time trying to
+explain in details why I'm rejecting the pull request.
 
 ## Bugfixes are (most often) welcome
 
@@ -52,21 +50,20 @@ changes.
   handle), so it would be nice if you understand the change you're
   proposing.
 
-* **Transparency** is important.  I don't care about your full
-  tool-chain, but if a significant part of the value in the pull
-  request was generated by tools, then it's relevant.  Do not write "I
-  found this issue and here is a fix", but rather "I ran the ruff tool
-  on the code, found this issue, and here is the fix".  If the AI was
-  fixing a bug for you, then write in the pull request that "this code
-  was AI-generated and haven't been thoroughly reviewed by me".
-  Commit message should end with "Assisted-by: (name of tool)",
-  alternatively i.e. `Co-Authored-By: Claude <noreply@anthropic.com>`
+* **Transparency** is important.  If a significant part of the value
+  in the pull request was generated by tools, then it's relevant.  Do
+  not write "I found this issue and here is a fix", but rather "I ran
+  the ruff tool on the code, it found this issue, and here is the
+  fix".  If the AI was fixing a bug for you, then write in the pull
+  request that "this bugfix was vibed up, I have no idea what the AI
+  has done here".  End the commit message with "Assisted-By: ..." or
+  "Co-Authored-By: ...".
 
 * **YOU** should be ready to follow up and respond to feedback and
   questions on the contribution.  If you're letting the AI do this for
-  you, then you're neither honest nor adding value to the project.
-  You should at least do a quick QA on the AI-answer and acknowledge
-  that it was generated by the AI.
+  you on your behalf, then it's a chance you're neither honest nor
+  adding value to the project.  You should at least do a quick QA on
+  the AI-answer and acknowledge that it was generated by the AI.
 
 * The Contributors Guidelines aren't strongly enforced on this project
   as of 2026-02, and I can hardly see cases where the AI would break

diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md
@@ -4,7 +4,7 @@ Contributions are mostly welcome.  If the length of this text scares you, then I
 
 ## Usage of AI and other tools
 
-A separate [AI POLICY](AI-POLICY.md) has been made.  The gist of it, be transparent and inform if your contribution was a result of clever tool usage and/or AI-usage, don't submit code if you don't understand the code yourself, and you are supposed to contribute value to the project.  If you're too lazy to read the AI Policy, then at least have a chat with the AI to work out if your contribution is within the policy or not.
+A separate [AI POLICY](AI-POLICY.md) has been made.  If you want to use AI and you're too lazy to read the AI Policy, then at least ask the AI to read it and chat with it to work out if your contribution is within the policy or not.
 
 ## GitHub
 

diff --git a/README.md b/README.md
@@ -1,6 +1,6 @@
 # caldav
 
-This project is a CalDAV ([RFC4791](http://www.ietf.org/rfc/rfc4791.txt)) client library for Python.
+This project is a CalDAV ([RFC4791](https://datatracker.ietf.org/doc/html/rfc4791)) client library for Python.
 
 Features:
 

diff --git a/caldav/calendarobjectresource.py b/caldav/calendarobjectresource.py
@@ -595,15 +595,15 @@ def add_attendee(self, attendee, no_default_parameters: bool = False, **paramete
     def is_invite_request(self) -> bool:
         """
         Returns True if this object is a request, see
-        https://www.rfc-editor.org/rfc/rfc2446.html#section-3.2.2
+        :rfc:`2446#section-3.2.2`.
         """
         self.load(only_if_unloaded=True)
         return self.icalendar_instance.get("method", None) == "REQUEST"
 
     def is_invite_reply(self) -> bool:
         """
         Returns True if the object is a reply, see
-        https://www.rfc-editor.org/rfc/rfc2446.html#section-3.2.3
+        :rfc:`2446#section-3.2.3`.
         """
         self.load(only_if_unloaded=True)
         return self.icalendar_instance.get("method", None) == "REPLY"

diff --git a/caldav/collection.py b/caldav/collection.py
@@ -528,7 +528,7 @@ class Calendar(DAVObject):
     """
     The `Calendar` object is used to represent a calendar collection.
     Refer to the RFC for details:
-    https://tools.ietf.org/html/rfc4791#section-5.3.1
+    :rfc:`4791#section-5.3.1`.
     """
 
     def __init__(

diff --git a/caldav/elements/cdav.py b/caldav/elements/cdav.py
@@ -103,7 +103,7 @@ class TimeRange(BaseElement):
 
     def __init__(self, start: datetime | None = None, end: datetime | None = None) -> None:
         ## start and end should be an icalendar "date with UTC time",
-        ## ref https://tools.ietf.org/html/rfc4791#section-9.9
+        ## ref https://datatracker.ietf.org/doc/html/rfc4791#section-9.9
         super(TimeRange, self).__init__()
 
         if self.attributes is None:

diff --git a/docs/design/FEATURE_COMPLETE_ROADMAP.md b/docs/design/FEATURE_COMPLETE_ROADMAP.md
@@ -29,7 +29,7 @@ This roadmap covers the **remaining gaps** to achieve full RFC compliance and ad
 
 **Priority:** High
 **Estimated effort:** 40-60 hours
-**RFC:** [RFC 3744](https://www.rfc-editor.org/rfc/rfc3744)
+**RFC:** [RFC 3744](https://datatracker.ietf.org/doc/html/rfc3744)
 
 Current state: The library has basic principal support but lacks ACL manipulation.
 
@@ -50,7 +50,7 @@ Current state: The library has basic principal support but lacks ACL manipulatio
 
 **Priority:** High
 **Estimated effort:** 40 hours (partially covered in #599 for v3.2)
-**RFC:** [RFC 6638](https://www.rfc-editor.org/rfc/rfc6638)
+**RFC:** [RFC 6638](https://datatracker.ietf.org/doc/html/rfc6638)
 
 The v3.2 roadmap covers basic scheduling improvements. Additional work for full compliance:
 
@@ -71,7 +71,7 @@ The v3.2 roadmap covers basic scheduling improvements. Additional work for full
 
 **Priority:** Medium
 **Estimated effort:** 16-24 hours
-**RFC:** [RFC 7953](https://www.rfc-editor.org/rfc/rfc7953)
+**RFC:** [RFC 7953](https://datatracker.ietf.org/doc/html/rfc7953)
 **Related issue:** #425
 
 **Tasks:**
@@ -88,7 +88,7 @@ The v3.2 roadmap covers basic scheduling improvements. Additional work for full
 
 **Priority:** Medium
 **Estimated effort:** 8-12 hours
-**RFC:** [RFC 7986](https://www.rfc-editor.org/rfc/rfc7986)
+**RFC:** [RFC 7986](https://datatracker.ietf.org/doc/html/rfc7986)
 
 **Tasks:**
 - [ ] Support calendar-level properties: `NAME`, `DESCRIPTION`, `COLOR`, `REFRESH-INTERVAL`, `SOURCE`
@@ -148,7 +148,7 @@ The v3.2 roadmap covers basic scheduling improvements. Additional work for full
 
 **Priority:** Low
 **Estimated effort:** 24-32 hours
-**RFC:** [RFC 8607](https://www.rfc-editor.org/rfc/rfc8607)
+**RFC:** [RFC 8607](https://datatracker.ietf.org/doc/html/rfc8607)
 
 **Tasks:**
 - [ ] Detect server support for `calendar-managed-attachments`
@@ -181,7 +181,7 @@ Note: This is a draft standard but widely implemented by major servers.
 
 **Priority:** Low
 **Estimated effort:** 4-8 hours
-**RFC:** [RFC 5689](https://www.rfc-editor.org/rfc/rfc5689)
+**RFC:** [RFC 5689](https://datatracker.ietf.org/doc/html/rfc5689)
 
 **Tasks:**
 - [ ] Support extended MKCOL as alternative to MKCALENDAR
@@ -194,7 +194,7 @@ Note: This is a draft standard but widely implemented by major servers.
 
 **Priority:** Low
 **Estimated effort:** 4-8 hours
-**RFC:** [RFC 4331](https://www.rfc-editor.org/rfc/rfc4331)
+**RFC:** [RFC 4331](https://datatracker.ietf.org/doc/html/rfc4331)
 
 **Tasks:**
 - [ ] Add `calendar.get_quota()` method
@@ -270,7 +270,7 @@ Note: This is a draft standard but widely implemented by major servers.
 **Priority:** Medium
 **Estimated effort:** 16-24 hours
 **Related issue:** #571
-**RFC:** [RFC 6764 Section 8](https://www.rfc-editor.org/rfc/rfc6764#section-8)
+**RFC:** [RFC 6764 Section 8](https://datatracker.ietf.org/doc/html/rfc6764#section-8)
 
 **Tasks:**
 - [ ] Add optional DNSSEC validation for SRV/TXT lookups
@@ -301,7 +301,7 @@ Note: This is a draft standard but widely implemented by major servers.
 
 **Priority:** Low
 **Estimated effort:** 16-24 hours
-**RFC:** [RFC 7265](https://www.rfc-editor.org/rfc/rfc7265)
+**RFC:** [RFC 7265](https://datatracker.ietf.org/doc/html/rfc7265)
 
 **Tasks:**
 - [ ] Accept `application/calendar+json` responses
@@ -314,7 +314,7 @@ Note: This is a draft standard but widely implemented by major servers.
 
 **Priority:** Low
 **Estimated effort:** 16-24 hours
-**RFC:** [RFC 6321](https://www.rfc-editor.org/rfc/rfc6321)
+**RFC:** [RFC 6321](https://datatracker.ietf.org/doc/html/rfc6321)
 
 **Tasks:**
 - [ ] Accept `application/calendar+xml` responses
@@ -488,23 +488,23 @@ Based on the roadmap, suggested version milestones after v3.2:
 ## References
 
 ### Core Standards
-- [RFC 4791 - CalDAV](https://www.rfc-editor.org/rfc/rfc4791)
-- [RFC 6638 - CalDAV Scheduling](https://www.rfc-editor.org/rfc/rfc6638)
-- [RFC 4918 - WebDAV](https://www.rfc-editor.org/rfc/rfc4918)
-- [RFC 3744 - WebDAV ACL](https://www.rfc-editor.org/rfc/rfc3744)
-- [RFC 5545 - iCalendar](https://www.rfc-editor.org/rfc/rfc5545)
+- [RFC 4791 - CalDAV](https://datatracker.ietf.org/doc/html/rfc4791)
+- [RFC 6638 - CalDAV Scheduling](https://datatracker.ietf.org/doc/html/rfc6638)
+- [RFC 4918 - WebDAV](https://datatracker.ietf.org/doc/html/rfc4918)
+- [RFC 3744 - WebDAV ACL](https://datatracker.ietf.org/doc/html/rfc3744)
+- [RFC 5545 - iCalendar](https://datatracker.ietf.org/doc/html/rfc5545)
 
 ### Extensions
-- [RFC 6764 - Service Discovery](https://www.rfc-editor.org/rfc/rfc6764)
-- [RFC 6578 - WebDAV Sync](https://www.rfc-editor.org/rfc/rfc6578)
-- [RFC 7953 - Calendar Availability](https://www.rfc-editor.org/rfc/rfc7953)
-- [RFC 7986 - New iCalendar Properties](https://www.rfc-editor.org/rfc/rfc7986)
-- [RFC 8607 - Managed Attachments](https://www.rfc-editor.org/rfc/rfc8607)
+- [RFC 6764 - Service Discovery](https://datatracker.ietf.org/doc/html/rfc6764)
+- [RFC 6578 - WebDAV Sync](https://datatracker.ietf.org/doc/html/rfc6578)
+- [RFC 7953 - Calendar Availability](https://datatracker.ietf.org/doc/html/rfc7953)
+- [RFC 7986 - New iCalendar Properties](https://datatracker.ietf.org/doc/html/rfc7986)
+- [RFC 8607 - Managed Attachments](https://datatracker.ietf.org/doc/html/rfc8607)
 
 ### Related
-- [RFC 5546 - iTIP](https://www.rfc-editor.org/rfc/rfc5546)
-- [RFC 6321 - xCal](https://www.rfc-editor.org/rfc/rfc6321)
-- [RFC 7265 - jCal](https://www.rfc-editor.org/rfc/rfc7265)
+- [RFC 5546 - iTIP](https://datatracker.ietf.org/doc/html/rfc5546)
+- [RFC 6321 - xCal](https://datatracker.ietf.org/doc/html/rfc6321)
+- [RFC 7265 - jCal](https://datatracker.ietf.org/doc/html/rfc7265)
 - [CalConnect Developer Guide](https://devguide.calconnect.org/)
 
 ---

diff --git a/docs/source/about.rst b/docs/source/about.rst
@@ -65,40 +65,40 @@ Support for Python2 was officially not supported starting from caldav
 version 1.0.
 
 
-RFC 4791, 2518, 5545, 6638 et al
---------------------------------
+RFC compliance
+--------------
 
-RFC 4791 (CalDAV) outlines the standard way of communicating with a
-calendar server.  RFC 4791 is an extension of RFC 4918 (WebDAV).  The
-scope of this library is basically to cover RFC 4791/4918, the actual
+:rfc:`4791` (CalDAV) outlines the standard way of communicating with a
+calendar server.  :rfc:`4791` is an extension of :rfc:`4918` (WebDAV).  The
+scope of this library is basically to cover :rfc:`4791` and :rfc:`4918`, the actual
 communication with the caldav server.  (The WebDAV standard also has
 quite some extensions, this library supports some of the relevant
 extensions as well).
 
-There exists another library webdavclient3 for handling RFC 4918
+There exists another library webdavclient3 for handling :rfc:`4918`
 (WebDAV), ideally we should be depending on it rather than overlap it.
 
-RFC 6638/RFC 6047 is extending the CalDAV and iCalendar protocols for
-scheduling purposes, work is in progress to support RFC 6638.  Support
-for RFC 6047 is considered mostly outside the scope of this library,
+:rfc:`6638` and :rfc:`6047` extend the CalDAV and iCalendar protocols for
+scheduling purposes, work is in progress to support :rfc:`6638`.  Support
+for :rfc:`6047` is considered mostly outside the scope of this library,
 though for convenience this library may contain methods like accept()
 on a calendar invite (which involves fetching the invite from the
 server, editing the calendar data and putting it to the server).
 
 This library should make it trivial to fetch an event, modify the data
 and save it back to the server - but to do that it's also needed to
-support RFC 5545 (icalendar).  It's outside the scope of this library
-to implement logic for parsing and modifying RFC 5545, instead we
+support :rfc:`5545` (icalendar).  It's outside the scope of this library
+to implement logic for parsing and modifying :rfc:`5545`, instead we
 depend on another library for that.
 
-RFC 5545 describes the icalendar format.  Constructing or parsing
+:rfc:`5545` describes the icalendar format.  Constructing or parsing
 icalendar data was considered out of the scope of this library, but we
 do make exceptions - like, there is a method to complete a task - it
 involves editing the icalendar data, and now the ``add_event``,
 ``add_todo`` and ``add_journal`` methods are able to construct icalendar
 data if needed.
 
-There exists two libraries supporting RFC 5545, vobject and icalendar.
+There exists two libraries supporting :rfc:`5545`, vobject and icalendar.
 vobject was unmaintained for several years, but seems to be actively
 maintained now.  The caldav library originally came with vobject
 support, but as many people requested the vobject dependency to be
@@ -109,7 +109,7 @@ Misbehaving server implementations
 ----------------------------------
 
 Some server implementations may have some "caldav"-support that either
-doesn't implement all of RFC 4791, breaks the standard a bit, or has
+doesn't implement all of :rfc:`4791`, breaks the standard a bit, or has
 extra features.  As long as it doesn't add too much complexity to the
 code, hacks and workarounds for "badly behaving caldav servers" are
 considered to be within the scope.  Ideally, users of the caldav
@@ -253,7 +253,7 @@ Server-specific highlights
   VTODOs must be stored in a calendar explicitly created for the ``VTODO``
   component type.
 
-* **Calendar creation** is not mandatory under RFC 4791.  Most self-hosted
+* **Calendar creation** is not mandatory under :rfc:`4791`.  Most self-hosted
   servers support it; Google's CalDAV adapter does not.
 
 * **Recurring events and tasks** are non-trivial to implement correctly on
@@ -263,7 +263,7 @@ Server-specific highlights
 Some notes on CalDAV URLs
 =========================
 
-From v2.1, well-known URLs were hard-coded into the compatibility_hints.  As of v2.2, auto-detection based on RFC6764 is supported.  This protocol is widely used.  For servers supporting it, it's sufficient to add something like "demo2.nextcloud.com" in the URL.  For well-known calendar providers, it's not needed to enter anything in the URL, it suffices to put i.e. `features="ecloud"` into the connection parameters.
+From v2.1, well-known URLs were hard-coded into the compatibility_hints.  As of v2.2, auto-detection based on :rfc:`6764` is supported.  This protocol is widely used.  For servers supporting it, it's sufficient to add something like "demo2.nextcloud.com" in the URL.  For well-known calendar providers, it's not needed to enter anything in the URL, it suffices to put i.e. `features="ecloud"` into the connection parameters.
 
 CalDAV URLs can be quite confusing, some software requires the URL to the calendar, other requires the URL to the principal.  The Python CalDAV library does support accessing calendars and principals using such URLs, but the recommended practice is to configure up the CalDAV root URL and tell the library to find the principal and calendars from that.  Typical examples of CalDAV URLs:
 

diff --git a/docs/source/async.rst b/docs/source/async.rst
@@ -57,7 +57,7 @@ The ``caldav.aio`` module exports:
 * ``AsyncCalendarSet`` - Collection of calendars
 * ``AsyncPrincipal`` - User principal
 
-**Scheduling (RFC6638):**
+**Scheduling (:rfc:`6638`):**
 
 * ``AsyncScheduleInbox`` - Incoming invitations
 * ``AsyncScheduleOutbox`` - Outgoing invitations

diff --git a/docs/source/jmap.rst b/docs/source/jmap.rst
@@ -5,9 +5,9 @@ JMAP
 **The JMAP support in v3.0 is experimental, the API may change in v3.1 of the library**
 
 The caldav library includes a JMAP client for servers that speak
-`RFC 8620 <https://www.rfc-editor.org/rfc/rfc8620>`_ (JMAP Core) and
+:rfc:`8620` (JMAP Core) and
 the JMAP Calendars protocol (``urn:ietf:params:jmap:calendars``), which uses
-`RFC 8984 <https://www.rfc-editor.org/rfc/rfc8984>`_ (JSCalendar) as its data format.
+:rfc:`8984` (JSCalendar) as its data format.
 It covers calendar listing, event CRUD, incremental sync, and task CRUD — the same
 operations as the CalDAV client — so the choice of protocol comes down to what the
 server supports.
@@ -361,7 +361,7 @@ The three specific error classes:
 * :class:`~caldav.jmap.error.JMAPCapabilityError` — the server's Session object
   does not advertise ``urn:ietf:params:jmap:calendars``.
 * :class:`~caldav.jmap.error.JMAPMethodError` — a JMAP method call returned an error
-  response.  The ``error_type`` attribute holds the RFC 8620 error type string
+  response.  The ``error_type`` attribute holds the :rfc:`8620` error type string
   (e.g. ``"invalidArguments"``, ``"notFound"``, ``"stateMismatch"``).
 
 Configuration File