<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<p>
<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:</p>
<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>
</body>
</html>