[caldeveloper-l] REPORT <sync-collection> for <caldav: calendar-data> --- Google returning only updated event instances
Andri Möll
andri at dot.ee
Wed Jun 6 04:02:24 PDT 2018
> 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.
My example below actually referred to the "Import .ics" feature in the
Google Calendar web UI. Were that second instance to be added through
CalDAV, it would of course have to be PUT along with the first instance.
I haven't explicitly checked, but I suspect their REPORT <calendar-data>
behavior is independent of how the new instance got in their system.
On 06/06/2018 10:47 AM, Filip Navara wrote:
>
> 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 <mailto:andri at dot.ee>>
> To: "David Given" <dtrg at google.com <mailto:dtrg at google.com>>
> Cc: caldeveloper-l at lists.calconnect.org
> <mailto: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:
>
> 1. 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
> 2. Get sync-token.
> 3. 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
> 4. 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
>> <mailto: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
>>>>> <mailto: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 <mailto:brong at fastmailteam.com>
>>>>
>>
>> --
>> Bron Gondwana, CEO, FastMail Pty Ltd
>> brong at fastmailteam.com <mailto:brong at fastmailteam.com>
>>
>> _______________________________________________
>> caldeveloper-l mailing list
>> caldeveloper-l at lists.calconnect.org
>> <mailto: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
> <mailto: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/3e8e4f47/attachment-0001.html>
More information about the caldeveloper-l
mailing list