Ensure that Evolution can find freebusy and other data of other participants of a meeting.

[dahopem]

As a user of Evolution backed by cyrus-imapd CalDAV, I want to schedule a meeting with another user as attendee of this meeting. After having provided an email address of the other user, evolution then asks cyrus-imapd CalDAV on my behalf regarding data of the other user, in preparation of obtaining freebusy data of that other user. Cyrus-imapd CalDAV is expected to answer properly, but instead replies with an error.

How to reproduce

1. Generate a new meeting in Evolution.
2. Enable "Options/Attendees".
3. Observe that a tab "Schedule" appears.
4. Add attendee "[email protected]" in that tab.

Expected result

1. Evolution shows a row in the calendar table showing when the user "[email protected]" is free or busy.

Actual result

1. Evolution sends this request:

   REPORT /dav/calendars/user/[email protected]/Default/ HTTP/1.1
   User-Agent: Evolution/3.50.3
   Cache-Control: no-cache
   Pragma: no-cache
   Content-Type: application/xml; charset="utf-8"
   Accept-Encoding: gzip, deflate, br
   Depth: 0
   [...]
   
   <principal-property-search xmlns="DAV:" xmlns:c="urn:ietf:params:xml:ns:caldav"><apply-to-principal-collection-set/><property-search><prop><c:calendar-user-address-set/></prop><match>[email protected]</match></property-search><prop><displayname/></prop></principal-property-search>
   

2. Cyrus-imapd CalDAV replies with:

   HTTP/1.1 403 Forbidden
   Vary: Accept-Encoding
   Content-Type: application/xml; charset=utf-8
   Content-Length: 95
   [...]
   
   <?xml version="1.0" encoding="utf-8"?>
   <D:error xmlns:D="DAV:"><D:supported-report/></D:error>
   

3. Evolution does not show any freebusy data regarding "[email protected]".
4. The syslog of the Cyrus-imapd CalDAV server contains:

   cyrus/http[498]: process request
   cyrus/http[498]: http_read_req_body(flags=0x8, framing=2)
   cyrus/http[498]: http_read_body(flags=0x28, framing=2)
   cyrus/http[498]: REPORT principal-property-search
   

Analysis

Cyrus-imapd CalDAV should search and find the handler for "principal-property-search" reports in a list defined in file imap/http_dav.c:

/* Array of supported REPORTs */
static const struct report_type_t principal_reports[] = {

    /* WebDAV Versioning (RFC 3253) REPORTs */
    { "expand-property", NS_DAV, "multistatus", &report_expand_prop,
      DACL_READ, 0 },

    /* WebDAV ACL (RFC 3744) REPORTs */
    { "principal-property-search", NS_DAV, "multistatus",
      &report_prin_prop_search, 0, REPORT_ALLOW_PROPS | REPORT_DEPTH_ZERO },
    { "principal-search-property-set", NS_DAV, "principal-search-property-set",
      &report_prin_search_prop_set, 0, REPORT_DEPTH_ZERO },

    { NULL, 0, NULL, NULL, 0, 0 }
};

However, instead of that, cyrus-imapd CalDAV searches the handler for "principal-property-search" reports in a list defined in file imap/http_caldav.c:

/* Array of supported REPORTs */
static const struct report_type_t caldav_reports[] = {

    /* WebDAV Versioning (RFC 3253) REPORTs */
    { "expand-property", NS_DAV, "multistatus", &report_expand_prop,
      DACL_READ, 0 },

    /* WebDAV ACL (RFC 3744) REPORTs */
    { "acl-principal-prop-set", NS_DAV, "multistatus", &report_acl_prin_prop,
      DACL_ADMIN, REPORT_NEED_MBOX | REPORT_NEED_PROPS | REPORT_DEPTH_ZERO },

    /* WebDAV Sync (RFC 6578) REPORTs */
    { "sync-collection", NS_DAV, "multistatus", &report_sync_col,
      DACL_READ, REPORT_NEED_MBOX | REPORT_NEED_PROPS },

    /* CalDAV (RFC 4791) REPORTs */
    { "calendar-query", NS_CALDAV, "multistatus", &report_cal_query,
      DACL_READ, REPORT_NEED_MBOX | REPORT_ALLOW_PROPS },
    { "calendar-multiget", NS_CALDAV, "multistatus", &report_multiget,
      DACL_READ, REPORT_NEED_MBOX | REPORT_ALLOW_PROPS },
    { "free-busy-query", NS_CALDAV, NULL, &report_fb_query,
      DACL_READFB, REPORT_NEED_MBOX },

    { NULL, 0, NULL, NULL, 0, 0 }
};

Observe that there is an overlap of supported report types ("expand-property" is supported by both report lists), but the report type "principal-property-search" is not among them. That is why cyrus-imapd CalDAV does not process "principal-property-search" properly, while it could.

Is there a reason not to include the support for "principal-property-search" in file "imap/http_caldav.c"?

If not, then fixing this bug could allow users of Evolution (and potentially other clients) to actually see freebusy information of other invitees.

[dilyanpalauzov]

The mailing lists archives, where WebDAV was discussed, are lost.

As far as I remember it is not clear where to send this REPORT request.

This is tracked on Evolution side at https://gitlab.gnome.org/GNOME/evolution-data-server/-/issues/302 . There the REPORT is sent towards the principal-url, while in your snippet it is sent towards the calendar. This might be consequence of the fact that you have setup the calendar as „New calendar“ with CalDAV url instead of using “Collection account”.

As stated there, I have implemented apply-to-principal-collection-set in the way I understand it. However this was towards Cyrus 3.4, it was a big change, or alike and I have not forward-copied this change on my system to newer versions. I could upload here my patches, if somebody wants to work on these.

Somehow Evolution and Cyrus IMAP do not agree how to send the free-busy information from the Scheduling Outbox. I have forgotten the details.

Is there a reason not to include the support for "principal-property-search" in file "imap/http_caldav.c"?

Probably because RFC 3744 says this needs to sent to the principal home url - /dav/principals/user/abc.

[alecpl]

Same problem already reported in #2546.

[dilyanpalauzov]

In 2021 I created this related patch, containing as description:

In REPORT principal-property-search utilize apply-to-principal-collection-set

My reading of RFC 3744 is that whenever the parameter apply-to-principal-collection-set is supplied to the principal-property-search the request URL is ignored and the REPORT acts as if performed towards the URLs from DAV:principal-collection-set = /dav/principal/users for Cyrus IMAP. The errata to RFC 3744 at https://greenbytes.de/tech/webdav/draft-reschke-rfc3744bis-latest.html add <apply-to-principal-collection-set/> parameter to the DAV:principal-search-property-set REPORT, and it acts on the same way.

This changset implements the DAV:principal-collection-set and DAV:principal-search-property-set REPORTs with apply-to-principal-collection-set in the /dav/calendars and /dav/addressbooks namespaces, but not in the /tzdist and /dav/notification namespaces. The rationale is that agendav calls the

• in the requests verify the namespace of the prop/propname/allprop DAV: tags for this the namespace must be checked after init_xml_response() is called.
• and for the apply-to-principal-collection-set element.

See question at https://lists.w3.org/Archives/Public/w3c-dist-auth/ from 24 Feb 2020.

Gnome Evolution calls REPORT DAV:principal-property-search with <apply-to-principal-collection-set/> on /dav/calendars/user/zzz/Default . My reading of RFC 3744 is that with <apply-to-principal-collection-set/> the real request URL is ignored and instead the report is executed as if the request URL was applied towards the URLs from DAV:principal-collection-set. For cyrus imap DAV:principal-collection-set is “/dav/principals/user/”.

https://greenbytes.de/tech/webdav/draft-reschke-rfc3744bis-latest.html adds <apply-to-principal-collection-set/> parameter to the DAV:principal-search-property-set REPORT, which the current changeset implements.

[dilyanpalauzov]

This is tracked on Evolution side at https://gitlab.gnome.org/GNOME/evolution-data-server/-/issues/302 .

or at https://gitlab.gnome.org/GNOME/evolution-data-server/-/issues/308.