
<html>

<head><title></title></head>

<body><div class="iw_mail" dir="ltr">

<p style="margin:0;">The description below doesn't seem to be entirely accurate.</p>

<p style="margin:0;"><br></p>

<p style="margin:0;">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.</p>

<p style="margin:0;"><br></p>

<p style="margin:0;">You should NOT run PUT requests with new <span style="font-family: roboto, tahoma, helvetica, sans-serif;">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.</span></p>

<p style="margin:0;"><span style="font-family: roboto, tahoma, helvetica, sans-serif;"><br></span></p>

<p style="margin:0;"><span style="font-family: roboto, tahoma, helvetica, sans-serif;">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.</span></p>

<p style="margin:0;"><span style="font-family: roboto, tahoma, helvetica, sans-serif;"><br></span></p>

<p style="margin:0;"><span style="font-family: roboto, tahoma, helvetica, sans-serif;">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.</span></p>

<p style="margin:0;"><span style="font-family: roboto, tahoma, helvetica, sans-serif;"><br></span></p>

<p style="margin:0;"><span style="font-family: roboto, tahoma, helvetica, sans-serif;">Best regards,</span></p>

<p style="margin:0;"><span style="font-family: roboto, tahoma, helvetica, sans-serif;">Filip Navara</span></p>

<div class="signature"> </div>

<br><blockquote class="reply_block" dir="ltr" style="border-left: 2px solid #0088CC; margin: 5pt 0 5pt 10pt; padding: 0 0 0 5pt; font-size: 13px; font-family: roboto,tahoma,helvetica,sans-serif;">

<hr size="1">-----Original Message-----<br>From: "Andri Möll" <<a href="mailto:andri@dot.ee">andri@dot.ee</a>><br>To: "David Given" <<a href="mailto:dtrg@google.com">dtrg@google.com</a>><br>Cc: <a href="mailto:caldeveloper-l@lists.calconnect.org">caldeveloper-l@lists.calconnect.org</a><br>Date: 06/06/18 12:29<br>Subject: Re: [caldeveloper-l] REPORT <sync-collection> for <caldav:calendar-data> --- Google returning only updated event instances<br><br><blockquote type="cite"><div>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.</div></blockquote>I'm happy to hear. What I described initially is fully reproducible. It's pretty much as I hinted:<ol>

<li>Import recurring event without master to Google Calendar. E.g.<br><blockquote type="cite">BEGIN:VCALENDAR<br>VERSION:2.0<br>BEGIN:VEVENT<br>UID:44b06ab7-cc52-428d-a28b-438eb19cae1d<br>RECURRENCE-ID:20180618T133742Z<br>SUMMARY:RECURRENCE-ID without repeatee, part 1<br>DTSTART:20180618T133742Z<br>DURATION:PT6H<br>END:VEVENT<br>END:VCALENDAR<br>

</blockquote>

</li>

<li>Get sync-token.</li>

<li>Add another recurring event instance without master (same UID).<br><blockquote type="cite">BEGIN:VCALENDAR<br>VERSION:2.0<br>BEGIN:VEVENT<br>UID:44b06ab7-cc52-428d-a28b-438eb19cae1d<br>RECURRENCE-ID:20180625T133742Z<br>SUMMARY:RECURRENCE-ID without repeatee, part 2<br>DTSTART:20180625T133742Z<br>DURATION:PT6H<br>END:VEVENT<br>END:VCALENDAR<br>

</blockquote>

</li>

<li>Use sync-token and get back <calendar-data> containing only the last instance, not the first</li>

</ol>

<blockquote type="cite"><div>I'd intuitively expect, though ('intuitively' meaning 'I haven't actually checked in the RFC') that both sync-collection with a token <i>would</i> only report the changed event instances --- it shouldn't be repeating data the client already knows. Is this incorrect?</div></blockquote>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).<br><br><br><div class="moz-cite-prefix">On 06/06/2018 01:42 AM, David Given wrote:<br>

</div>

<blockquote type="cite" cite="mid:CAPX+joDwXCJEwYQv5Mhutugq6K=P=B1g7gmAPcrTVgMzQHO1QQ@mail.gmail.com"><div dir="ltr">

<span>I am currently in my hotel in Tokyo waiting to go off to CalConnect myself, so...</span><div><br></div>

<div>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.</div>

<div><br></div>

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

<div><br></div>

<div>(The Oauth Playground at <a href="https://developers.google.com/oauthplayground/" moz-do-not-send="true">https://developers.google.com/oauthplayground/</a> is useful for sending raw CalDAV requests to the Google servers, BTW, although it only supports GET/POST/PUT/DELETE/PATCH.)<br><br><div class="gmail_quote">

<div dir="ltr">On Sat, 2 Jun 2018, 07:08 Bron Gondwana, <<a href="mailto:brong@fastmailteam.com" target="_blank" moz-do-not-send="true">brong@fastmailteam.com</a>> wrote:<br>

</div>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div>

<div style="font-family:Arial">Maybe Robert can check with somebody from Google next week at CalConnect in Tokyo :)<br>

</div>

<div style="font-family:Arial"><br></div>

<div style="font-family:Arial">With Cyrus the delete will return whatever the standard delete is, then 404 for the get.</div>

</div>

<div>

<div style="font-family:Arial"><br></div>

<div style="font-family:Arial">Bron.</div>

</div>

<div>

<div><br></div>

<div><br></div>

<div>On Sat, Jun 2, 2018, at 07:59, Andri Möll wrote:<br>

</div>

<blockquote type="cite">

<p><span class="m_7162677763647512068m_-9159031255229584968size" style="font-size:small"><span class="m_7162677763647512068m_-9159031255229584968font" style="font-family:Helvetica," Arial"," sans-serif"">That works indeed and I'll switch over to sync-collection + multiget</span></span> 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.<br></p>

<p>I haven't checked other servers. Happen to know how Cyrus behaves?<br></p>

<p><br></p>

<p><br></p>

<blockquote type="cite">Surely <caldav:calendar-data> isn't defined differently in the REPORT context and in the PROPFIND context?<br>

</blockquote>

<p><br></p>

<p>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.<br></p>

<div style="font-family:Arial"><br></div>

<div>On 06/01/2018 09:28 PM, Bron Gondwana wrote:<br>

</div>

<blockquote type="cite">

<div style="font-family:Arial">What happens if you just fetch the href in changes and then use a get or multiget to fetch the calendar data?<br>

</div>

<div style="font-family:Arial"><br></div>

<div style="font-family:Arial">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).<br>

</div>

<div style="font-family:Arial"><br></div>

<div style="font-family:Arial">Bron.<br>

</div>

<div><br></div>

<div><br></div>

<div>On Sat, Jun 2, 2018, at 02:58, Andri Möll wrote:<br>

</div>

<blockquote type="cite">

<p><span class="m_7162677763647512068m_-9159031255229584968size" style="font-size:small"><span>Hey,</span></span><br></p>

<p><span class="m_7162677763647512068m_-9159031255229584968size" style="font-size:small"><span>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?</span></span> Surely <caldav:calendar-data> isn't defined differently in the REPORT context and in the PROPFIND context?<br></p>

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

<p><br></p>

<blockquote type="cite">

<div style="font-family:Arial"><caldav:calendar-data><br>

</div>

<div style="font-family:Arial"><caldav:comp name="VCALENDAR"><br>

</div>

<div style="font-family:Arial"><caldav:allprop/><br>

</div>

<div style="font-family:Arial"><caldav:allcomp/><br>

</div>

<div style="font-family:Arial"></caldav:comp><br>

</div>

<div style="font-family:Arial"></caldav:calendar-data><br>

</div>

</blockquote>

<div style="font-family:Arial"><br></div>

<p><br></p>

<p>Thanks!<br></p>

<p>Andri<br></p>

<div>

<u>_______________________________________________</u><br>

</div>

<div>caldeveloper-l mailing list<br>

</div>

<div>

<a href="mailto:caldeveloper-l@lists.calconnect.org" target="_blank" moz-do-not-send="true">caldeveloper-l@lists.calconnect.org</a><br>

</div>

<div>

<a href="http://lists.calconnect.org/listinfo.cgi/caldeveloper-l-calconnect.org" target="_blank" moz-do-not-send="true">http://lists.calconnect.org/listinfo.cgi/caldeveloper-l-calconnect.org</a><br>

</div>

</blockquote>

<div style="font-family:Arial"><br></div>

<div>

<div>--<br>

</div>

<div>Bron Gondwana, CEO, FastMail Pty Ltd<br>

</div>

<div>

<a href="mailto:brong@fastmailteam.com" target="_blank" moz-do-not-send="true">brong@fastmailteam.com</a><br>

</div>

<div><br></div>

</div>

</blockquote>

</blockquote>

<div style="font-family:Arial"><br></div>

<div id="m_7162677763647512068m_-9159031255229584968sig56629417">

<div class="m_7162677763647512068m_-9159031255229584968signature">--<br>

</div>

<div class="m_7162677763647512068m_-9159031255229584968signature">Bron Gondwana, CEO, FastMail Pty Ltd<br>

</div>

<div class="m_7162677763647512068m_-9159031255229584968signature">

<a href="mailto:brong@fastmailteam.com" target="_blank" moz-do-not-send="true">brong@fastmailteam.com</a><br>

</div>

<div class="m_7162677763647512068m_-9159031255229584968signature"><br></div>

</div>

</div>_______________________________________________<br>caldeveloper-l mailing list<br><a href="mailto:caldeveloper-l@lists.calconnect.org" target="_blank" moz-do-not-send="true">caldeveloper-l@lists.calconnect.org</a><br><a href="http://lists.calconnect.org/listinfo.cgi/caldeveloper-l-calconnect.org" rel="noreferrer" target="_blank" moz-do-not-send="true">http://lists.calconnect.org/listinfo.cgi/caldeveloper-l-calconnect.org</a><br>

</blockquote>

</div>

</div>

</div></blockquote>

<br><hr>_______________________________________________<br>caldeveloper-l mailing list<br><a href="mailto:caldeveloper-l@lists.calconnect.org">caldeveloper-l@lists.calconnect.org</a><br><a href="http://lists.calconnect.org/listinfo.cgi/caldeveloper-l-calconnect.org">http://lists.calconnect.org/listinfo.cgi/caldeveloper-l-calconnect.org</a><br>

</blockquote>

</div></body>

</html>