<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body smarttemplateinserted="true">
<div id="smartTemplate4-quoteHeader">
<div style="font-size:10.0pt;font-family:Verdana,Arial">Great! <font
style="font-size:24px">👍</font><br>
<br>
</div>
<div style="border:none;border-top:solid #B5C4DF
1.0pt;padding:3.0pt 0cm 0cm
0cm;font-size:10.0pt;font-family:"Tahoma","sans-serif""><b>From:</b>
Ken Murchison<br>
<b>Sent:</b> Wednesday, June 06, 2018 16:22<br>
<b>To:</b> Cyrus Devel<br>
<b>Subject:</b> Re: shared xDAV resources<br>
</div>
<br>
</div>
<span type="cite"
cite="mid:3a689588-0c11-af27-9fc1-08108994276b@fastmail.com"
style="display: block; word-break: break-all; margin: 7px 0 0 0;
padding: 0; line-height:0"></span>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<p>I looked into shared calendar discovery and I have 2 ideas in
mind. One is simpler than the other, and I have an email into one
of the Apple client devs to see which of the two (or both) they
may support. He's currently at CalConnect in Tokyo and I'm hoping
it prompts some discussion among the membership.<br>
</p>
<br>
<div class="moz-cite-prefix">On 05/26/2018 07:19 PM, Anatoli wrote:<br>
</div>
<blockquote type="cite"
cite="mid:7c7a2ba1-5079-1eb5-955f-d86141ba635e@anatoli.ws">
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<div id="smartTemplate4-quoteHeader">
<div style="font-size:10.0pt;font-family:Verdana,Arial">Hi Ken,<br>
<br>
Thanks for dedicating time to this issue.<br>
<br>
The <b>current problem</b>: the auto-discovery mechanism for
CalDAV/CardDAV resources in Cyrus doesn't return the <i>shared</i>
resources a user has access to. It does return all resources
in the <i>user folder</i> (<font face="Courier New">/dav/calendars/user/<user@domain>/</font>)
for all known clients (including iOS).<br>
<br>
The clients that I'm aware of that <i>only</i> support
auto-discovery mechanism (i.e. where users can't specify a
direct resource URL), is all iOS (Calendar and Contacts apps),
not sure about the same Mac apps. Then there is a lot of
clients that support both methods (e.g. Evolution, even
Thunderbird has a plug-in that enables auto-discovery) and its
much simpler to auto-discover everything just entering the
server address and user/pass than configuring the same for
each resource one by one.<br>
<br>
For me the most basic functionality would be enough at this
time: the clients that support auto-discovery mechanism should
be able to list and access the shared resources the same way
they access now the resources in the user folder. Once this
works, we could deploy shared calendars and addressbooks in
production, gather users feedback and see what could be
improved.<br>
<br>
<b>TL;DR</b>: I guess it would be enough to just include the
shared resource URLs in the list returned by Cyrus to <font
face="Courier New">PROPFIND </font><font face="Courier New">/dav/principals/user/<user@domain>/</font>
query.<br>
<br>
<br>
With respect to <b>ACLs</b>, they do work correctly on all
resources (shared and user-owned). Here probably one thing
could be improved to not confuse users. Now if a user tries to
introduce changes to a calendar/addressbook where he has a
read-only access (rl ACL), his client gets <font
face="Courier New">403 Forbidden</font> and it asks the user
to enter different credentials. The ideal would be to return
some other code that won't trigger a credentials request in
the client (maybe something like "operation not supported" or
some temporary error). The idea is to activate this behavior
only when the user is properly authenticated and has a r/o
access, but asks for a write operation, i.e. it's not for all
403 Forbidden cases:<br>
<br>
<font face="Courier New">if (user.authenticated &&
user.acl(requested_resource) == r&l &&
requested_operation == w|i|p|k|x|t|e)<br>
return "operation not supported"<br>
else<br>
return "403 Forbidden"<br>
</font><br>
<br>
With respect to the <b>scheduling</b> support, I can't talk
for the entire community, but at least in my case, we don't
use this feature at the moment not even for user calendars.
Our shared calendars use cases now are to create reminders for
public holidays, employees birthdays, etc. and for meeting
rooms reservations. Once the users become familiar with shared
calendars, new use cases would appear probably.<br>
<br>
<br>
One feature that would be nice to have (but it's
workaround-able now with custom scripts, so it's of low
priority) is to be able to create shared calendars and
addressbooks with a web GUI the same way user calendars and
addressbooks could be created now.<br>
<br>
With this functionality we would probably have to define the
concept of shared resources <i>scope</i>, i.e. global
(public) shared resources and user-owned shared resources,
with the main difference being their path (<font face="Courier
New">/dav/calendars/X</font> vs <font face="Courier New">/dav/calendars/user/<user@domain>/X</font>)
and a special permission (probably <font face="Courier New">w</font>,
<font face="Courier New">i</font> or <font face="Courier New">k</font>
on <font face="Courier New">/dav/calendars/</font> could
work) that would allow the user to create global (public)
shared resources.<br>
<br>
Also, the current web GUI for user calendars/contacts could
have an option to add permissions on available resources for
other users (e.g. a mail address field and 2 radio buttons for
access type (read|write)), so its owner could share his/her
calendars/contacts directly from the existing GUI.<br>
<br>
<br>
Please let me know if I can provide additional details.<br>
<br>
Thanks,<br>
Anatoli<br>
<br>
</div>
<div style="border:none;border-top:solid #B5C4DF
1.0pt;padding:3.0pt 0cm 0cm
0cm;font-size:10.0pt;font-family:"Tahoma","sans-serif""><b>From:</b>
Ken Murchison<br>
<b>Sent:</b> Friday, May 25, 2018 10:29<br>
<b>To:</b> Cyrus Devel<br>
<b>Subject:</b> Re: shared xDAV resources<br>
</div>
<br>
</div>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<p>Hi Anatoli,</p>
<p>I'm guessing that this will be a couple of days work. Bron has
told me to carve out some time to work on this. I have 4
flights and 2 hotel stays coming up June 4-14, which will give
me some time to look at this.</p>
<p>Can you summarize the functionality that you require and what
the current problems are? E.g., Do you need scheduling support
on the shared calendar? Do Apple clients not autodiscover the
calendars? Are ACLs working properly?</p>
<p><br>
</p>
<br>
<div class="moz-cite-prefix">On 05/25/2018 12:22 AM, Anatoli
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:2b3e11a1-217b-df5b-0c8a-a613bbfb66be@anatoli.ws">
<meta http-equiv="Content-Type" content="text/html;
charset=utf-8">
<div id="smartTemplate4-quoteHeader">
<div style="font-size:10.0pt;font-family:Verdana,Arial">Bron,
Ken,<br>
<br>
I've just created a new issue for this: <a
class="moz-txt-link-freetext"
href="https://github.com/cyrusimap/cyrus-imapd/issues/2373"
moz-do-not-send="true">https://github.com/cyrusimap/cyrus-imapd/issues/2373</a>,
so it's not lost in the mails archive.<br>
<br>
Please let us know if the community can sponsor the
development.<br>
<br>
Thanks,<br>
Anatoli<br>
<br>
</div>
<div style="border:none;border-top:solid #B5C4DF
1.0pt;padding:3.0pt 0cm 0cm
0cm;font-size:10.0pt;font-family:"Tahoma","sans-serif""><b>From:</b>
Anatoli<br>
<b>Sent:</b> Monday, April 09, 2018 00:40<br>
<b>To:</b> Cyrus Devel<br>
<b>Subject:</b> Re: shared xDAV resources<br>
</div>
<br>
</div>
<meta http-equiv="Content-Type" content="text/html;
charset=utf-8">
<div id="smartTemplate4-quoteHeader">
<div style="font-size:10.0pt;font-family:Verdana,Arial"><font
face="Verdana">Bron, Ken,<br>
<br>
Thanks for your explanations.<br>
<br>
Do you consider this is something possible to implement
for an outside developer, i.e. without Cyrus HTTP/DB
implementation internals understanding, nor solid
knowledge of xDAV RFCs? I'd like to collaborate, but I
believe it only makes sense to start this work if I could
finish it without too much effort to become fluent with
the related internals/standards.<br>
<br>
On the other hand, if I don't have a reasonable chance to
implement it myself, could I sponsor the development by
your team or help your team in other ways (e.g. extensive
testing, logs/telemetry, etc.)?<br>
<br>
I have the Cyrus xDAV functionality deployed
experimentally at one organization, everything looks good
so far, but the fact that shared resources (calendars and
addressbooks) can't be accessed from iOS devices obstructs
its definitive deployment there and at other
organizations. WebDAV resources work well on all devices
with some minor issues on macOS (I'm debugging them now,
looks like they only occur on previous versions of macOS,
i.e. El Capitan).<br>
<br>
<br>
> I originally wrote the code to handle public
calendars in the "shared" namespace, but I focused on user
calendars first, and public calendar support got tossed on
the back burner. It appears that the code for public
calendars partly works.<br>
<br>
Public calendars actually work quite well, if the device
can discover them. Currently, I've tested them with
Thunderbird and haven't found any issues.<br>
<br>
Remote addressbooks are not supported in Thunderbird, so I
use <i>CardBook</i> add-on and it works well with shared
addressbooks, no issues detected. <i>Evolution</i>
supports CardDAV natively and also works well with shared
addressbooks.<br>
<br>
Regards,<br>
Anatoli</font><br>
<br>
</div>
<div style="border:none;border-top:solid #B5C4DF
1.0pt;padding:3.0pt 0cm 0cm
0cm;font-size:10.0pt;font-family:"Tahoma","sans-serif""><b>From:</b>
Ken Murchison<br>
<b>Sent:</b> Saturday, April 07, 2018 21:53<br>
<b>To:</b> Bron Gondwana, Cyrus Devel<br>
<b>Cc:</b> Ken Murchison<br>
<b>Subject:</b> Re: shared xDAV resources<br>
</div>
<br>
</div>
<meta content="text/html; charset=utf-8"
http-equiv="Content-Type">
<div class="moz-cite-prefix">I originally wrote the code to
handle public calendars in the "shared" namespace, but I
focused on user calendars first, and public calendar support
got tossed on the back burner. It appears that the code for
public calendars partly works. <br>
<br>
My first thought to get auto-discovery of public calendars is
to add /dav/calendars as a second calendar-home-set for users
and see what the Apple clients do with that. I don't know if
they can handle multiple home-sets. If that doesn't work,
then we could map public calendars into the user's home-set
via the same subscription mechanism that we use for CalDAV
sharing.<br>
<br>
To answer the original question, calendars are enumerated by
meth_propfind() and propfind_by_collection() in http_dav.c<br>
<br>
<br>
On 4/7/18 8:25 PM, Bron Gondwana wrote:<br>
</div>
<blockquote
cite="mid:1523147109.3986766.1330184448.5F04F251@webmail.messagingengine.com"
type="cite">
<title></title>
<style type="text/css">p.MsoNormal,p.MsoNoSpacing{margin:0}</style>
<div style="font-family:Arial;">Ken knows this code best. I
bet there's something which is requiring that there's a user
on the mboxname because we implement the same behaviour at
FastMail by having a separate user on which shared resources
are kept. The DAV resources are stored per-user, and
without a place to keep them for "shared calendars" that
code might just not be accessible. I'm sure it would be
possible to create a shared DAV database as well for this
case, but it just needs some programming effort.<br>
</div>
<div style="font-family:Arial;"><br>
Bron.<br>
</div>
<div><br>
</div>
<div><br>
</div>
<div>On Sun, 8 Apr 2018, at 07:30, Anatoli wrote:<br>
</div>
<blockquote type="cite">
<div style="font-family:Arial;">Hi All,<br>
</div>
<div style="font-family:Arial;"> <br>
</div>
<div style="font-family:Arial;"> 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.<br>
</div>
<div style="font-family:Arial;"> <br>
</div>
<div style="font-family:Arial;"> Could you please point me
to the place where the enumeration occurs and briefly
mention how the general workflow looks like?<br>
</div>
<div style="font-family:Arial;"> <br>
</div>
<div style="font-family:Arial;"> The client asks for:<br>
</div>
<div style="font-family:Arial;"> <br>
</div>
<div style="font-family:Arial;"> <span class="font"
style="font-family:"Courier New"">PROPFIND
/dav/calendars/user/<user@domain>/<br>
<br>
<A:propfind xmlns:A="DAV:"><br>
...</span></div>
<div style="font-family:Arial;"> <br>
</div>
<div style="font-family:Arial;"> The server responds with:<br>
</div>
<div style="font-family:Arial;"> <br>
</div>
<div style="font-family:Arial;"> <span class="font"
style="font-family:"Courier New"">HTTP/1.1 207
Multi-Status<br>
<br>
<A:multistatus xmlns:A="DAV:" ...><br>
<A:response><br>
<A:href>/dav/calendars/user/<user@domain>/</A:href><br>
<A:propstat><br>
...<br>
</A:response><br>
<A:response><br>
<A:href>/dav/calendars/user/<user@domain>/Default/</A:href><br>
<A:propstat><br>
<A:prop><br>
...</span></div>
<div style="font-family:Arial;"> <br>
</div>
<div style="font-family:Arial;"> The idea is to include in
the returned lists the shared calendars too with the
discovery logic based on the IMAP shared folders.<br>
</div>
<div style="font-family:Arial;"> <br>
</div>
<div style="font-family:Arial;"> 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@domain.com/) as iOS is
pointed to it by Cyrus). In the attached file goes the
telemetry for the rest of the communication.<br>
</div>
<div style="font-family:Arial;"> <br>
</div>
<div style="font-family:Arial;"> Thanks,<br>
</div>
<div style="font-family:Arial;"> Anatoli<br>
</div>
<div style="font-family:Arial;"> <br>
</div>
<div style="font-family:Arial;"> <span class="font"
style="font-family:"Courier New"">---------- <a
moz-do-not-send="true" href="mailto:t3@domain.com">t3@domain.com</a>
Sun Mar 25 06:05:36 2018<br>
<br>
<1521968736<<b>PROPFIND</b> <b>/dav/calendars/shared/</b>
HTTP/1.1<br>
Accept: */*<br>
Content-type: text/xml<br>
Connection: keep-alive<br>
Content-length: 181<br>
Host: mail.domain.com<br>
User-agent: iOS/11.2.6 (15D100) accountsd/1.0<br>
Prefer: return=minimal<br>
Depth: 0<br>
Brief: t<br>
Accept-language: en-us<br>
Authorization: Basic ...<br>
Accept-encoding: br, gzip, deflate<br>
<br>
<1521968736<<?xml version="1.0"
encoding="UTF-8"?><br>
<A:propfind xmlns:A="DAV:"><br>
<A:prop><br>
<A:current-user-principal/><br>
<A:principal-URL/><br>
<A:resourcetype/><br>
</A:prop><br>
</A:propfind><br>
<br>
<br>
>1521968736>HTTP/1.1 207 Multi-Status<br>
Date: Sun, 25 Mar 2018 09:05:36 GMT<br>
Strict-Transport-Security: max-age=600<br>
Vary: Accept-Encoding, Brief, Prefer<br>
Preference-Applied: return=minimal<br>
Content-Type: application/xml; charset=utf-8<br>
Content-Length: 546<br>
<br>
<?xml version="1.0" encoding="utf-8"?><br>
<A:multistatus xmlns:A="DAV:"
xmlns:C="urn:ietf:params:xml:ns:caldav"><br>
<A:response><br>
<A:href><b>/dav/calendars/shared/</b></A:href><br>
<A:propstat><br>
<A:prop><br>
<A:current-user-principal><br>
<A:href><b>/dav/principals/user/t3@domain.com/</b></A:href><br>
</A:current-user-principal><br>
<A:resourcetype><br>
<A:collection/><br>
<C:calendar/><br>
</A:resourcetype><br>
</A:prop><br>
<A:status>HTTP/1.1 200 OK</A:status><br>
</A:propstat><br>
</A:response><br>
</A:multistatus><br>
<br>
<1521968736<OPTIONS
/dav/principals/user/t3%40domain.com/ HTTP/1.1<br>
Host: mail.domain.com<br>
Connection: keep-alive<br>
Accept: */*<br>
User-Agent: iOS/11.2.6 (15D100) accountsd/1.0<br>
Accept-Language: en-us<br>
Content-Length: 0<br>
Accept-Encoding: br, gzip, deflate<br>
<br>
>1521968736>HTTP/1.1 200 OK<br>
Date: Sun, 25 Mar 2018 09:05:36 GMT<br>
Strict-Transport-Security: max-age=600<br>
Cache-Control: no-cache<br>
Link: </dav/principals/.server-info>;
rel="server-info";
token="80769c2c66d340ecd178710db26d56b9c4699e3e"<br>
DAV: 1, 2, 3, access-control, extended-mkcol,
resource-sharing<br>
DAV: calendar-access, calendar-auto-schedule<br>
DAV: calendar-query-extended, calendar-availability,
calendar-managed-attachments<br>
DAV: calendarserver-sharing, inbox-availability<br>
DAV: addressbook<br>
Allow: OPTIONS, GET, HEAD<br>
Allow: PROPFIND, REPORT, COPY<br>
Content-Length: 0</span> </div>
<p>Email had 1 attachment:<br>
</p>
<ul>
<li>
<div style="font-family:Arial;"><code>telemetry.log</code><br>
</div>
<div style="font-family:Arial;"> 36k (text/x-log)<br>
</div>
</li>
</ul>
</blockquote>
<div style="font-family:Arial;"><br>
</div>
<div id="sig56629417">
<div class="signature">--<br>
</div>
<div class="signature"> Bron Gondwana, CEO, FastMail Pty
Ltd<br>
</div>
<div class="signature"> <a
class="moz-txt-link-abbreviated"
href="mailto:brong@fastmailteam.com"
moz-do-not-send="true">brong@fastmailteam.com</a><br>
</div>
<div class="signature"><br>
</div>
</div>
<div style="font-family:Arial;"><br>
</div>
</blockquote>
<br>
<p><br>
</p>
<pre class="moz-signature" cols="72">--
Kenneth Murchison
Cyrus Development Team
FastMail Pty Ltd</pre>
<br>
<br>
</blockquote>
<br>
<pre class="moz-signature" cols="72">--
Ken Murchison
Cyrus Development Team
FastMail US LLC</pre>
<br>
</blockquote>
<br>
<pre class="moz-signature" cols="72">--
Ken Murchison
Cyrus Development Team
FastMail US LLC</pre>
<br>
</body>
</html>