Hello, what is the status of this? Are the theoretical concerns clarified by now?
About CALDAV:calendar-home-set: While after logging in a user is supposed to find the list of the owned calendars available with CALDAV:calendar-home-set, the specification says this is an URL and the calendars owned by the user are below that URL. Owned or not-owned does not matter here. RFC4791 says for CALDAV:calendar-home-set "Identifies the URL of any WebDAV collections that contain calendar collections owned by the associated principal resource.". As it is not mandated, that a user has to own calendars only within a single base URL, many base-URLs can be returned. Section 3.1 says: ... That might mean that calendaring data is spread throughout the repository and mixed with non-calendar data in nearby collections (e.g., calendar data may be found in /home/lisa/calendars/ as well as in /home/bernard/calendars/, and non-calendar data in /home/lisa/contacts/). Or, it might mean that calendar data can be found only in certain sections of the repository (e.g., /calendar/). Any idea what happens, when /dav/calendars is returned in calendar- home-set? As having calendar (of bernard and lisa) data under /calendar/ is no different than having calendar data under /home/bernard/calendars and /home/list/calendars, the home-set can return either only /calendar/ or both other URLs. About caldav-clients not accepting two URLs here... some CalDAV clients also don't accept the fact that CalDAV resource can be subscribed without username/password, but they accept subscribing to iCalendar files without username/password. So it is a matter of time that caldav clients adopt. What is the concept with the data per user from <userid>.dav, when the resources are in a shared namespace? Regards Дилян On Sat, 2018-04-07 at 18:30 -0300, Anatoli wrote: > Hi All, > > I'm trying to understand the code responsible for enumerating user calendars > (and xDAV resources in general) to try to make the discovery work for shared > resources too (currently there's no way to access shared resources with Apple > xDAV client implementation, yes with Thunderbird as it doesn't use the > discovery mechanism, but instead should be pointed to the exact URL for each > calendar). If I understand it correctly, the functionality is in > imap/http_caldav.c. > > Could you please point me to the place where the enumeration occurs and > briefly mention how the general workflow looks like? > > The client asks for: > > PROPFIND /dav/calendars/user/<user@domain>/ > > <A:propfind xmlns:A="DAV:"> > ... > > The server responds with: > > HTTP/1.1 207 Multi-Status > > <A:multistatus xmlns:A="DAV:" ...> > <A:response> > <A:href>/dav/calendars/user/<user@domain>/</A:href> > <A:propstat> > ... > </A:response> > <A:response> > <A:href>/dav/calendars/user/<user@domain>/Default/</A:href> > <A:propstat> > <A:prop> > ... > > The idea is to include in the returned lists the shared calendars too with > the discovery logic based on the IMAP shared folders. > > Below goes the initial exchange between the calendar app on iOS 10.2.6 and > Cyrus 3.0.5 when the exact URL (/dav/calendars/shared/) for the shared > calendar is provided in the advanced settings of the app (the URL finally > resets to the user principals folder (/dav/principals/user/t...@domain.com/) > as iOS is pointed to it by Cyrus). In the attached file goes the telemetry > for the rest of the communication. > > Thanks, > Anatoli > > ---------- t...@domain.com Sun Mar 25 06:05:36 2018 > > <1521968736<PROPFIND /dav/calendars/shared/ HTTP/1.1 > Accept: */* > Content-type: text/xml > Connection: keep-alive > Content-length: 181 > Host: mail.domain.com > User-agent: iOS/11.2.6 (15D100) accountsd/1.0 > Prefer: return=minimal > Depth: 0 > Brief: t > Accept-language: en-us > Authorization: Basic ... > Accept-encoding: br, gzip, deflate > > <1521968736<<?xml version="1.0" encoding="UTF-8"?> > <A:propfind xmlns:A="DAV:"> > <A:prop> > <A:current-user-principal/> > <A:principal-URL/> > <A:resourcetype/> > </A:prop> > </A:propfind> > > > >1521968736>HTTP/1.1 207 Multi-Status > Date: Sun, 25 Mar 2018 09:05:36 GMT > Strict-Transport-Security: max-age=600 > Vary: Accept-Encoding, Brief, Prefer > Preference-Applied: return=minimal > Content-Type: application/xml; charset=utf-8 > Content-Length: 546 > > <?xml version="1.0" encoding="utf-8"?> > <A:multistatus xmlns:A="DAV:" xmlns:C="urn:ietf:params:xml:ns:caldav"> > <A:response> > <A:href>/dav/calendars/shared/</A:href> > <A:propstat> > <A:prop> > <A:current-user-principal> > <A:href>/dav/principals/user/t...@domain.com/</A:href> > </A:current-user-principal> > <A:resourcetype> > <A:collection/> > <C:calendar/> > </A:resourcetype> > </A:prop> > <A:status>HTTP/1.1 200 OK</A:status> > </A:propstat> > </A:response> > </A:multistatus> > > <1521968736<OPTIONS /dav/principals/user/t3%40domain.com/ HTTP/1.1 > Host: mail.domain.com > Connection: keep-alive > Accept: */* > User-Agent: iOS/11.2.6 (15D100) accountsd/1.0 > Accept-Language: en-us > Content-Length: 0 > Accept-Encoding: br, gzip, deflate > > >1521968736>HTTP/1.1 200 OK > Date: Sun, 25 Mar 2018 09:05:36 GMT > Strict-Transport-Security: max-age=600 > Cache-Control: no-cache > Link: </dav/principals/.server-info>; rel="server-info"; > token="80769c2c66d340ecd178710db26d56b9c4699e3e" > DAV: 1, 2, 3, access-control, extended-mkcol, resource-sharing > DAV: calendar-access, calendar-auto-schedule > DAV: calendar-query-extended, calendar-availability, > calendar-managed-attachments > DAV: calendarserver-sharing, inbox-availability > DAV: addressbook > Allow: OPTIONS, GET, HEAD > Allow: PROPFIND, REPORT, COPY > Content-Length: 0
