[caldeveloper-l] sync-tokens vs PROPFIND

[Bron Gondwana]

Hi David,

I know this is contacts rather than calendars, but here's a perspective
from the other side about why people don't support optional/extended
standards in their clients:
<<<<<<<< REPORT
https://www.googleapis.com:443/carddav/v1/principals/brongondwana%40gmail.com/lists/default/
HTTP/1.1<D:sync-collection xmlns:C='urn:ietf:params:xml:ns:carddav' xmlns:CY='
http://cyrusimap.org/ns/' xmlns:D='DAV:'><D:sync-token/><D:sync-level>1</D:sync-
level><D:prop><D:getetag/></D:prop></D:sync-collection>>>>>>>>> HTTP/1.1 400 Bad Request
<?xml version="1.0" encoding="UTF-8"?>
<d:error xmlns:d="DAV:"/>

Of course this is carddav rather than caldav, but if you're building a
general client library, you quickly wind up chasing the lowest common
denominator rather than writing two different codepaths, one for
modern/correct servers and one for old servers that only support the
base standard or have buggy newer behaviour.
Particularly when docs lie:

https://developers.google.com/google-apps/carddav/

Here's what I got back from a PROPFIND:

<d:response>
  <d:href>/carddav/v1/principals/brongondwana at gmail.com/lists/default-
     /</d:href>  <d:propstat>
   <d:status>HTTP/1.1 200 OK</d:status>
   <d:prop>
    <d:displayname>Address Book</d:displayname>
    <d:current-user-privilege-set>
     <d:privilege>
      <d:read/>
     </d:privilege>
     <d:privilege>
      <d:read-acl/>
     </d:privilege>
     <d:privilege>
      <d:read-current-user-privilege-set/>
     </d:privilege>
     <d:privilege>
      <d:unlock/>
     </d:privilege>
     <d:privilege>
      <d:write/>
     </d:privilege>
     <d:privilege>
      <d:write-acl/>
     </d:privilege>
    </d:current-user-privilege-set>
    <d:supported-report-set>
     <d:supported-report>
      <d:report>
       <d:principal-search-property-set/>
      </d:report>
     </d:supported-report>
     <d:supported-report>
      <d:report>
       <card:addressbook-query/>
      </d:report>
     </d:supported-report>
     <d:supported-report>
      <d:report>
       <d:expand-property/>
      </d:report>
     </d:supported-report>
     <d:supported-report>
      <d:report>
       <d:principal-property-search/>
      </d:report>
     </d:supported-report>
     <d:supported-report>
      <d:report>
       <d:acl-principal-prop-set/>
      </d:report>
     </d:supported-report>
     <d:supported-report>
      <d:report>
       <card:addressbook-multiget/>
      </d:report>
     </d:supported-report>
     <d:supported-report>
      <d:report>
       <d:principal-match/>
      </d:report>
     </d:supported-report>
     <d:supported-report>
      <d:report>
       <d:sync-collection/>
      </d:report>
     </d:supported-report>
    </d:supported-report-set>
    <d:resourcetype>
     <d:collection/>
     <card:addressbook/>
    </d:resourcetype>
   </d:prop>
  </d:propstat>
  <d:propstat>
   <d:status>HTTP/1.1 404 Not Found</d:status>
   <d:prop>
    <d:acl/>
    <d:sync-token/>
   </d:prop>
  </d:propstat>
</d:response>
</d:multistatus>

RFC6578 is pretty clear:

3.2.  DAV:sync-collection Report

   If the DAV:sync-collection report is implemented by a WebDAV server,
   then the server MUST list the report in the "DAV:supported-report-
   set" property on any collection that supports synchronization.

The server claims to support sync-collection, but it actually doesn't.

It doesn't take dealing with many bogus servers like this and you just
give up on the more efficient method.

Do you have any contacts in the contacts team you could pass this on to?
I guess I'll make my code check for sync-token existing as well as for
the standard supported-report-set.

Cheers,Bron.

On Wed, 8 Nov 2017, at 03:38, David Given wrote:
> Hello everybody,
> 
> I have an RFC question I'd appreciate some feedback on...
> 
> 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.> 
> They're doing this:
> 
> PROPFIND /caldav/v2/$USERNAME/events
> <?xml version="1.0" encoding="UTF-8"?>
> <A:propfind xmlns:A="DAV:">
>   <A:prop>
>     <A:getcontenttype/>
>     <A:getetag/>
>   </A:prop>
> </A:propfind>
> 
> As you can see, they're not asking for a sync token.
> 
> 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).> 
> My question is. however:
> 
> Is it permissable to return a sync-token (and expect the client to
> honour it) *even if the client's original query didn't ask for it*?> 
> I'm hoping the answer is going to be yes, but if it's no --- any
> suggestions?> 
> Thanks!
> 
> David Given
> dtrg at google.com
> 
> _________________________________________________
> caldeveloper-l mailing list
> caldeveloper-l at lists.calconnect.org
> http://lists.calconnect.org/listinfo.cgi/caldeveloper-l-calconnect.org
--
  Bron Gondwana, CEO, FastMail Pty Ltd
  brong at fastmailteam.com


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.calconnect.org/pipermail/caldeveloper-l-calconnect.org/attachments/20171113/401ae23a/attachment.html>