<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=utf-8">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    <p>I'm not (yet) a developer at that level, but seems to me there
      might be an advantage to all calendar software developers if
      CalConnect published an open-source set of 'functional' examples
      of how to do things "How to retrieve the user's events", "How to
      send a meeting invitation", etc.   It might help drive adoption of
      'best practices' methods and make it easier on server vendors for
      sure.  Or is this what the API group is hoping to accomplish?  In
      an event, for client developers, it's usually the UX that
      differentiates products, the user rarely sees or thinks about the
      'back end'  (exactly as in e-mail).<br>
      <br>
      Tim Hare<br>
      Interested Bystander, Non-Inc.<br>
    </p>
    <div class="moz-cite-prefix">On 11/7/2017 12:00 PM, Ken Murchison
      wrote:<br>
    </div>
    <blockquote type="cite"
      cite="mid:31d6d504-f4fd-6a7e-f78b-2349ab34bb94@fastmailteam.com">
      <meta http-equiv="Content-Type" content="text/html; charset=utf-8">
      <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" moz-do-not-send="true">caldeveloper-l@lists.calconnect.org</a>
<a class="moz-txt-link-freetext" href="http://lists.calconnect.org/listinfo.cgi/caldeveloper-l-calconnect.org" moz-do-not-send="true">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>
      <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>
    <br>
  </body>
</html>