[caldeveloper-l] sync-tokens vs PROPFIND
Bron Gondwana
brong at fastmailteam.com
Mon Nov 13 04:02:51 PST 2017
Hi David,
Yes, it's not so much this particular bug (thanks for prodding the right
people for me) - I only just discovered that bug today. I have much
more experience in the IMAP world...
It's that new features are generally less stable - see the Microsoft
Exchange MOVE command issue with IMAP for a fine case of unreliable new
protocol additions:
http://mailman13.u.washington.edu/pipermail/imap-protocol/2015-November/002559.html
The easy solution is: just don't use MOVE even if the server advertises
it - especially since COPY + EXPUNGE still works fine, and also works
with older servers that don't know about MOVE.
So trying to get support for an optional extension is hard... because
the incentives for clients to support it are not there unless they get a
massive benefit.
I just rewrote the JMAP-Proxy sync code in Net::CalDAVTalk and
Net::CardDAVTalk perl modules today, which is how I discovered this bug
with Google CardDAV :) I was making our code do what you want people to
do - use sync-collection!
Anyway - hopefully I'll see you at a CalConnect some time. I haven't
been making it the last few because I'm busy with IETF and M3AAWG, but I
might make Japan next year. Robert S tells me he met you at the last
one, just finished a call with him and the rest of the Cyrus IMAPd
project team.
Cheers,
Bron.
On Mon, 13 Nov 2017, at 21:14, David Given wrote:
> I'm involved with CalDAV rather than CardDAV, which is a different
> team and a different technology stack, but I'm well aware that this is
> not really an important difference from the outside... that definitely
> looks like a bug; I will escalate it to the appropriate people.>
> (Incidentally, if anyone observes any other similar oddities, please
> get in touch.)>
>
> On Mon, 13 Nov 2017 at 09:10 Bron Gondwana
> <brong at fastmailteam.com> wrote:>> __
>> 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/defaul-
>> t/</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
>>
>>
>> _______________________________________________
>> 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/c9d7eee1/attachment.html>
More information about the caldeveloper-l
mailing list