[caldeveloper-l] REPORT <sync-collection> for <caldav: calendar-data> --- Google returning only updated event instances

Wed Jun 6 03:47:39 PDT 2018

The description below doesn't seem to be entirely accurate.

In CalDAV the recurrence and all its exception and changed occurrences are part of one resource (eg. represented by one URL). This is a bit of impedance mismatch to how Google Calendar API works where the changed occurrences are separate resources.

You should NOT run PUT requests with new recurring event instance without master (like in step 3 below). There's an exception to this rule, but the exception is only when you don't know the master event. Imagine a scenario where you organise a meeting every Monday at 3pm to discuss your product progress. Then you decide that next Monday you should also invite an external graphics designer to get his input. The changed instance on next Monday would still be part of the same resource for the organiser. However, for the external graphics designer it would be different and he could only receive an .ics containing the changed instance in the invitation. This quite a complicated edge to handle, but it happens in practice.

Deleting all instances of recurring events in CalDAV would be accomplished by a DELETE request on the resource representing the whole event (master and all changed instances). In a subsequent sync request it should return 404. In theory one could also run a PUT with empty VCALENDAR object, but this would likely be rejected by most servers.

Fetching changes to a recurring event in a sync request w/ calendar-data should return the full resource representation including master and all changed occurrences.

Best regards,

Filip Navara

-----Original Message-----
From: "Andri Möll" <andri at dot.ee>
To: "David Given" <dtrg at google.com>
Cc: caldeveloper-l at lists.calconnect.org
Date: 06/06/18 12:29
Subject: Re: [caldeveloper-l] REPORT <sync-collection> for <caldav:calendar-data> --- Google returning only updated event instances

We've had a few reports of something not being right with CalDAV syncing, but nobody's ever come up with a reproducable test case. So if you have a concrete example of unexpected results, then yes, we're very interested.
I'm happy to hear. What I described initially is fully reproducible. It's pretty much as I hinted:
 - Import recurring event without master to Google Calendar. E.g.
BEGIN:VCALENDAR
VERSION:2.0
BEGIN:VEVENT
UID:44b06ab7-cc52-428d-a28b-438eb19cae1d
RECURRENCE-ID:20180618T133742Z
SUMMARY:RECURRENCE-ID without repeatee, part 1
DTSTART:20180618T133742Z
DURATION:PT6H
END:VEVENT
END:VCALENDAR

 - Get sync-token.
 - Add another recurring event instance without master (same UID).
BEGIN:VCALENDAR
VERSION:2.0
BEGIN:VEVENT
UID:44b06ab7-cc52-428d-a28b-438eb19cae1d
RECURRENCE-ID:20180625T133742Z
SUMMARY:RECURRENCE-ID without repeatee, part 2
DTSTART:20180625T133742Z
DURATION:PT6H
END:VEVENT
END:VCALENDAR

 - Use sync-token and get back <calendar-data> containing only the last instance, not the first
I'd intuitively expect, though ('intuitively' meaning 'I haven't actually checked in the RFC') that both sync-collection with a token would only report the changed event instances --- it shouldn't be repeating data the client already knows. Is this incorrect?
My spec reading says it's incorrect as I haven't seen any mention of how those changes should be reported. As I alluded to before, Google CalDAV's behavior when deleting _only one_ of those event instances doesn't make much sense either --- you get an empty VCALENDAR. Same when deleting both instances together (see my email below).

On 06/06/2018 01:42 AM, David Given wrote:

I am currently in my hotel in Tokyo waiting to go off to CalConnect myself, so...

We've had a few reports of something not being right with CalDAV syncing, but nobody's ever come up with a reproducable test case. So if you have a concrete example of unexpected results, then yes, we're very interested.

I'd intuitively expect, though ('intuitively' meaning 'I haven't actually checked in the RFC') that both sync-collection with a token would only report the changed event instances --- it shouldn't be repeating data the client already knows. Is this incorrect?

(The Oauth Playground at https://developers.google.com/oauthplayground/ is useful for sending raw CalDAV requests to the Google servers, BTW, although it only supports GET/POST/PUT/DELETE/PATCH.)

On Sat, 2 Jun 2018, 07:08 Bron Gondwana, <brong at fastmailteam.com> wrote:

Maybe Robert can check with somebody from Google next week at CalConnect in Tokyo :)

With Cyrus the delete will return whatever the standard delete is, then 404 for the get.

Bron.

On Sat, Jun 2, 2018, at 07:59, Andri Möll wrote:

That works indeed and I'll switch over to sync-collection + multiget as well, but [Google's] <calendar-data>'s behavior in response to <sync-collection> is quite a nut in its own right. Delete the last instance you have of a repeating event without a master and Google gets you a "200 OK" with an empty VCALENDAR. Go GET or multiget it and you get 404.

I haven't checked other servers. Happen to know how Cyrus behaves?

Surely <caldav:calendar-data> isn't defined differently in the REPORT context and in the PROPFIND context?

Correction to my own question --- "defined differently in <sync-collection> vs <calendar-multiget>". Noticed in RFC 4791 that <calendar-data> isn't supposed to be returned in PROPFIND.

On 06/01/2018 09:28 PM, Bron Gondwana wrote:

What happens if you just fetch the href in changes and then use a get or multiget to fetch the calendar data?

I'm pretty sure I changed all our perl client code to do that a while back for unrelated reasons (ok, because some servers just error out if you try to fetch too many items at once, so we batch the calendar data requests).

Bron.

On Sat, Jun 2, 2018, at 02:58, Andri Möll wrote:

Hey,

Does anyone know what's up with Google Calendar's CalDAV REPORT <sync-collection> with <sync-token> response only returning updated recurring event instances in <caldav:calendar-data> and not the entire iCalendar with its master and other [unchanged] instances? Surely <caldav:calendar-data> isn't defined differently in the REPORT context and in the PROPFIND context?

Throwing in <caldav:comp> in hopes that it'll trigger a full response doesn't seem to work either.

<caldav:calendar-data>

  <caldav:comp name="VCALENDAR">

    <caldav:allprop/>

    <caldav:allcomp/>

  </caldav:comp>

</caldav:calendar-data>

Thanks!

Andri

_______________________________________________

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

--

  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

_______________________________________________
caldeveloper-l mailing list
caldeveloper-l at lists.calconnect.org
http://lists.calconnect.org/listinfo.cgi/caldeveloper-l-calconnect.org

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.calconnect.org/pipermail/caldeveloper-l-calconnect.org/attachments/20180606/6927ad12/attachment.html>