<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<p>
<blockquote type="cite">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.</span></blockquote>
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.<br>
</p>
<br>
<div class="moz-cite-prefix">On 06/06/2018 10:47 AM, Filip Navara
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:6fcb16f0e0dd6846b2d07d4d7e61b6f1@emclient.com">
<title></title>
<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"
moz-do-not-send="true">andri@dot.ee</a>><br>
To: "David Given" <<a href="mailto:dtrg@google.com"
moz-do-not-send="true">dtrg@google.com</a>><br>
Cc: <a href="mailto:caldeveloper-l@lists.calconnect.org"
moz-do-not-send="true">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"
moz-do-not-send="true">caldeveloper-l@lists.calconnect.org</a><br>
<a
href="http://lists.calconnect.org/listinfo.cgi/caldeveloper-l-calconnect.org"
moz-do-not-send="true">http://lists.calconnect.org/listinfo.cgi/caldeveloper-l-calconnect.org</a><br>
</blockquote>
</div>
</blockquote>
<br>
</body>
</html>