shared xDAV resources

[Дилян Палаузов]

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 at 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 at domain>/</A:href>
>     <A:propstat>
> ...
>   </A:response>
>   <A:response>
>     <A:href>/dav/calendars/user/<user at 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/t3 at 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
> 
> ---------- t3 at 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/t3 at 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