docs: two feature descriptions follow the probes

save-load.event.floating named the time of calendaring-sync's example
event (09:00 UTC); what SOGo does is pin any wall-clock time to UTC.
delete.missing.if-match now says the conditional DELETE answers as the
plain one does, as RFC 9110 section 13.2.1 has it and as the tester now
grades it, rather than always 404.

Prompt: [fix issues found during the review process]
Prompts (comments made inline in the document while reviewing it):
> (on grading delete.missing.if-match against the plain DELETE's answer) Make sure both `delete.missing` and `delete.missing.if-match` is (sic) checked.

Assisted-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Reviewed-by: Tobias Brox <tobias@redpill-linpro.com>

Author: tobixen

caldav/compatibility_hints.py

@@ -505,7 +505,7 @@ class FeatureSet:
             "description": "The server accepts events with non-UTC timezone information. When unsupported or broken, the server may reject events with timezone data (e.g., return 403 Forbidden). Related to GitHub issue https://github.com/python-caldav/caldav/issues/372."
         },
         "save-load.event.floating": {
-            "description": "An event with a floating DTSTART and DTEND (a local time with neither TZID nor a UTC 'Z', RFC 5545 section 3.3.5) is stored floating, meaning the same wall-clock time in whatever time zone the user is in.  When 'unsupported', the server stores the time in a time zone of its own: SOGo adds a VTIMEZONE for Etc/UTC and gives DTSTART and DTEND TZID=Etc/UTC, so the event is pinned to 09:00 UTC.  SOGo keeps tasks floating.  'broken' when the stored time has both a TZID and a 'Z', which section 3.3.5 forbids.  The probe reads the server's own text: the icalendar library (7.3.0) itself writes a TZID=Etc/UTC time back with a 'Z', so a re-serialised object can look broken when the server's is not.",
+            "description": "An event with a floating DTSTART and DTEND (a local time with neither TZID nor a UTC 'Z', RFC 5545 section 3.3.5) is stored floating, meaning the same wall-clock time in whatever time zone the user is in.  When 'unsupported', the server stores the time in a time zone of its own: SOGo adds a VTIMEZONE for Etc/UTC and gives DTSTART and DTEND TZID=Etc/UTC, so the wall-clock time is pinned to UTC.  SOGo keeps tasks floating.  'broken' when the stored time has both a TZID and a 'Z', which section 3.3.5 forbids.  The probe reads the server's own text: the icalendar library (7.3.0) itself writes a TZID=Etc/UTC time back with a 'Z', so a re-serialised object can look broken when the server's is not.",
             "default": {"support": "full"},
             "links": ["https://datatracker.ietf.org/doc/html/rfc5545#section-3.3.5"],
         },
@@ -862,7 +862,7 @@ class FeatureSet:
             "default": {"support": "full"},
         },
         "delete.missing.if-match": {
-            "description": "A DELETE carrying If-Match on an object that does not exist still answers 404.  RFC 9110 section 13.2.1 has a server ignore the preconditions when the request would fail without them, so the missing object wins over the failed condition.  When 'unsupported', the server answers 412 Precondition Failed (Baikal, Davis, Nextcloud, CCS, OX, Robur, Purelymail, Infomaniak), and delete(if_match=True) on an object someone else already deleted raises an etag mismatch rather than NotFoundError.  Independent of delete.if-match: SOGo ignores a stale If-Match, yet answers a missing object with 404.",
+            "description": "A DELETE carrying If-Match on an object that does not exist answers as a failing plain DELETE of it does, normally 404; where a plain DELETE of a missing object succeeds, the condition is evaluated and 412 is right.  RFC 9110 section 13.2.1 has a server ignore the preconditions when the request would fail without them, so the missing object wins over the failed condition.  When 'unsupported', the server answers 412 Precondition Failed (Baikal, Davis, Nextcloud, CCS, OX, Robur, Purelymail, Infomaniak), and delete(if_match=True) on an object someone else already deleted raises an etag mismatch rather than NotFoundError.  Independent of delete.if-match: SOGo ignores a stale If-Match, yet answers a missing object with 404.",
             "default": {"support": "full"},
             "links": ["https://datatracker.ietf.org/doc/html/rfc9110#section-13.2.1"],
         },

changes/+sync-multiget-features.added.md

@@ -1,6 +1,6 @@
 Compatibility features for behaviours a sync client depends on, as found by calendaring-sync (https://github.com/PyCalendar/calendaring-sync/blob/c40782bc7afe7b350fe63bf27ef13374c280ea8b/docs/reference/server-compatibility.rst), each with a probe in caldav-server-tester:
 
-- `delete.missing` and `delete.missing.if-match`: a DELETE of a missing object answers 404, with If-Match too (Baikal, Davis, Nextcloud, CCS, OX, Robur, Purelymail and Infomaniak answer 412 with it).
+- `delete.missing` and `delete.missing.if-match`: a DELETE of a missing object answers 404, and one with If-Match answers as the plain one does (Baikal, Davis, Nextcloud, CCS, OX, Robur, Purelymail and Infomaniak answer 412 with it).
 - `save.etag.matches-stored`: a strong ETag in a PUT answer belongs to what was stored (Radicale, Xandikos, SOGo, CCS, Zimbra, Bedework 5 and Infomaniak rewrite the object and still answer with one).
 - `sync-token.initial-sync`, `sync-token.delete.created-and-deleted` and `sync-token.recreated`: which members a sync-collection report lists.
 - `multiget`, `multiget.missing-href` and `multiget.limit`, and `propfind.limit`: a calendar-multiget answers a missing href with a 404, and a multiget or a Depth: 1 PROPFIND answers every href (Stalwart stops at its maxResults, with a 507).