<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<p>My guess is that if the client is blindly requesting the ETag of
every resource using a PROPFIND rather than a sync-collection
REPORT, that the client will have no clue what a sync-token is if
you return it</p>
<p>I'd push back on the client developer and educate them that
sync-collection is almost mandatory to implement for any
well-behaved CalDAV/CardDAV client.</p>
<p>Is the PROPFIND not working because Google can't handle it or the
client times out waiting for the response? If the latter, we at
Fastmail recently experienced the same thing with requests that
require a huge response to be generated. We fixed this by
updating the Cyrus IMAP server so that responses to PROPFIND and
REPORT get "streamed" to client using chunked transfer-encoding.
This keeps the client from timing out.<br>
</p>
<br>
<div class="moz-cite-prefix">On 11/07/2017 11:38 AM, David Given
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CAPX+joDt_W9Dr_-7KYdPpKEHcvEq0cRwz0RjQVeLVL5DvN2Lhg@mail.gmail.com">
<div dir="ltr">Hello everybody,<br>
<div><br>
</div>
<div>I have an RFC question I'd appreciate some feedback on...</div>
<div><br>
</div>
<div>We have a situation where a Calendar client is trying to
get the etags of every event in an enormous calendar in a
single query. Naturally, this isn't working.</div>
<div><br>
</div>
<div>They're doing this:</div>
<div><br>
</div>
<div>PROPFIND /caldav/v2/$USERNAME/events</div>
<div>
<div><?xml version="1.0" encoding="UTF-8"?></div>
<div><A:propfind xmlns:A="DAV:"></div>
<div> <A:prop></div>
<div> <A:getcontenttype/></div>
<div> <A:getetag/></div>
<div> </A:prop></div>
<div></A:propfind></div>
</div>
<div><br>
</div>
<div>As you can see, they're not asking for a sync token.</div>
<div><br>
</div>
<div>RFC6578 section 3.6 provides a mechanism where clients can
ask for paginated responses, where the server returns partial
data with a 507 status code, and a new sync token so they can
continue the query. It is a, however, a bit ambiguous as to
whether this is supported for methods other than REPORT. The
interwebs suggest it is (but I'd appreciate a clarification
here).</div>
<div><br>
</div>
<div>My question is. however:</div>
<div><br>
</div>
<div>Is it permissable to return a sync-token (and expect the
client to honour it) <i>even if the client's original query
didn't ask for it</i>?</div>
<div><br>
</div>
<div>I'm hoping the answer is going to be yes, but if it's no
--- any suggestions?</div>
<div><br>
</div>
<div>Thanks!</div>
<div><br>
</div>
<div>David Given</div>
<div><a href="mailto:dtrg@google.com" moz-do-not-send="true">dtrg@google.com</a></div>
<div><br>
</div>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
caldeveloper-l mailing list
<a class="moz-txt-link-abbreviated" href="mailto:caldeveloper-l@lists.calconnect.org">caldeveloper-l@lists.calconnect.org</a>
<a class="moz-txt-link-freetext" href="http://lists.calconnect.org/listinfo.cgi/caldeveloper-l-calconnect.org">http://lists.calconnect.org/listinfo.cgi/caldeveloper-l-calconnect.org</a>
</pre>
</blockquote>
<pre class="moz-signature" cols="72">--
Ken Murchison
Cyrus Development Team
FastMail Pty Ltd</pre>
</body>
</html>