Extended MKCOL (RFC 5689): detection, testing and 207 handling

[tobixen]

Some history ...

• Back when the very first versions of the library was implemented, MKCOL was used instead of MKCALENDAR for creating calendars.
• MKCOL didn't work at all servers. The CalDAV standard specifies that there is a method MKCALENDAR that should be used. I changed the library from using MKCOL to using MKCALENDAR when creating calendars.
• In January 2026 I asked Claude to make me a list of features that were missing from the caldav library. RFC 5689 was flagged (see the file docs/design/FEATURE_COMPLETE_ROADMAP.md).
• I forgot about this, but later I discovered that some of the servers where MKCALENDAR doesn't work supports creating calendars through MKCOL, so now there is some logic in there trying both methods.
• Now, Claude claims that most of the work here is already done.

The very least I need to do here is to read through RFC 5689 and see if I understand it.

AI-generated analysis below the line

---

⚠️ This issue is AI-generated (Claude Opus 5 via Claude Code) on behalf of tobixen, from the prompt: "3.3 Extended MKCOL (RFC 5689) also needs an issue"

Not a green field — most of it is already there

The roadmap said "support extended MKCOL as an alternative to MKCALENDAR" as if nothing existed. That is wrong, and the roadmap has been corrected: Calendar._create() in collection.py already builds an extended MKCOL request — dav.Mkcol() wrapping a DAV:set/DAV:prop with resourcetype set to collection + calendar, plus display name and supported-calendar-component-set — and uses it instead of MKCALENDAR whenever the server is configured with create-calendar: {support: quirk, behaviour: mkcol-required}. Properties are therefore already set atomically at creation, with a PROPPATCH afterwards only as a fallback.

What is missing is everything around it.

Tasks

• Nothing detects support. The MKCOL path is only taken when a server profile declares mkcol-required, and exactly one profile does (baikal_old). A server that supports both, or only extended MKCOL, is not discovered — there is no "try MKCALENDAR, fall back to MKCOL on 405/501" and no probe.
• Nothing tests it. The description of the create-calendar feature in compatibility_hints.py already admits this: "RFC5689 extended MKCOL may also be used to create calendar collections as an alternative to MKCALENDAR. We should consider testing this as well". A caldav-server-tester check would tell us how much of the matrix supports it, which is the input needed for everything else here.
• A 207 response is treated as an error. RFC 5689 section 3 says that when the collection is created but a property could not be set, the server answers 207 Multi-Status with a propstat per property. Both _create() and _async_create() pass expected_return_value=201, so such a response raises instead of being parsed — we would neither know which property failed nor that the collection exists.
• Consider a feature flag distinguishing "supports extended MKCOL" from "requires it", since mkcol-required currently conflates the two.
• Consider whether extended MKCOL for plain (non-calendar) collections belongs on the object API; today only the raw mkcol() method on the client exists.

Worth it?

The honest case against: MKCALENDAR works on nearly everything, and the one profile that needs MKCOL is an old Baikal. The 207 handling is the part with real bite — it is a latent bug rather than a missing feature, and it is cheap. Detection and a server-tester check are the natural companions to it. The rest can wait.

RFC: https://datatracker.ietf.org/doc/html/rfc5689

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