Subject: Re: [ietf-caldav] draft-daboo-webdav-sync-01
From: Julian Reschke <[email-masked]>
To: Cyrus Daboo <[email-masked]>
Cc: WebDAV <[email-masked]>, CardDAV <[email-masked]>, CalDAV <[email-masked]>
Date: Mon, 23 Mar 2009 15:13:48 +0100
List-Id: Discussions on Calendar Access protocol based on WebDAV <ietf-caldav.osafoundation.org>

Hi,

below are some comments on draft-daboo-webdav-sync-01.

High Level:

First of all, the complexity of this mainly depends on the type of 
server. For instance, for a Subversion-style store (with a global change 
counter) this could be almost trivial, while it may be very hard to 
implement for many others.

Also, there's some related work in this area, such as:

- using a feed format (Atom?)

- sending notifications over XMPP 
(<http://greenbytes.de/tech/webdav/draft-hildebrand-webdav-notify-00.html>)

- Microsoft's take on it: SUBSCRIBE/UNSUBSCRIBE/NOTIFY/POLL 
(<http://msdn.microsoft.com/en-us/library/aa143117(EXCHG.65).aspx>)

- Notifications, as defined in JCR (Java Content Repository), which at 
some point we'll want to transport over HTTP....

- RFC 3253 (DeltaV) and WebDAV BIND which clarify what the state of a 
collection is, and define a property (DAV:resource-id) which could be 
used to define "sameness" of a WebDAV resource under name changes.

Regarding Section 3, "Open Issues":

"1. Should we try and discriminate between changes to the body of a 
resource and changes to the properties?"

I think we need to.

"2. If we indicate a property change, should we return the list of 
properties that changed on each resource (propnames NOT values)?"

Why only the names?

"3. Should we provide a way to indicate that a 'new' resource is new in 
the collection as a result of a COPY or MOVE from another location, as 
opposed to being created?"

At least MOVE and COPY should be handled separately; DAV:resource-id 
(<http://greenbytes.de/tech/webdav/draft-ietf-webdav-bind-23.html#rfc.section.3.1>) 
could be used for that.

"4. Should we provide a way to indicate that a 'deleted' resource was 
removed from the collection as a result of a MOVE to another location, 
as opposed to being actually deleted?"

Not sure it makes a difference.

"5. How should ACLs be handled? e.g. a resource is visible to a user at 
one point in time, then its <read> privilege is removed. Should the 
resource be marked as having been deleted when next synchronized?"

Why deleted? I realize that some servers return 404 for resources the 
user doesn't have read access to, but that's not the general case.

"6. Do we want a special indicator for a resource that was deleted and 
then re-created, as opposed to just indicating that the resource was 
'changed'?"

I think the information is needed. It could be provided using 
DAV:resource-id.

Other substantial comments:

1. Introduction

"This can currently be done using a WebDAV PROPFIND request on a 
collection to list all members of a collection along with their HTTP 
ETag values, which allows the client to determine which resources were 
changed, added or deleted."

s/HTTP ETag values/DAV:getetag property values/

Also note this wouldn't necessarily detect property changes.

"Additionally, a new property is added to collection resources that is 
used to convey a "synchronization token" that is guaranteed to change 
when the contents of the collection have changed."

You need to define the term "contents" here. Obviously, it includes data 
that is not included in the collection's state, as defined in RFC 3253, 
for example.

4.1

"HTTP already defines a synchronization token in the form of an entity 
tag which is attached to a resource. However, the entity tag is not 
always required to be 'strong' and thus cannot be relied on absolutely 
as a valid synchronization indicator. In addition, there is no concept 
of an entity tag for a collection's contents."

Sic -- it's because that term is not defined (at least not in the way 
this spec wants to use it :-)

4.2

"To implement the behavior for this REPORT a server needs to keep track 
of changes to any resources in a collection."

Need to clarify what "in a collection" means; I guess "Internal Member", 
as defined by RFC 4918, Section 3?

"The request URI MUST be a collection."

Why?

"The "Depth" header MUST be ignored by the server and SHOULD NOT be sent 
by the client."

Nope, see earlier discussion.

"The response body for a successful request MUST be a DAV:multistatus 
XML element, which MUST contain one DAV:sync-token element in addition 
to any DAV:sync-response elements."

Not sure why this re-uses DAV:multistatus, and then puts something 
completely else as child elements.

Editorial Comments:

- state venue for discussion

- expand abbreviations on first use

- 4.1

"The is specification defines a new WebDAV REPORT that is used to enable 
client-server collection synchronization."

"The is"?

"That is done by the client sending an empty token value to the server."

I think "no token" would be better.

- "4.2 REPORT defined"

Title.

"If the report is not available, clients MUST NOT attempt to execute one."

Requirement unnecessary.

Best regards, Julian

Date: Mon, 23 Mar 2009 15:13:48 +0100
From: Julian Reschke <[email-masked]>
To: Cyrus Daboo <[email-masked]>
Cc: WebDAV <[email-masked]>, CardDAV <[email-masked]>, CalDAV <[email-masked]>
Subject: Re: [ietf-caldav] draft-daboo-webdav-sync-01

Hi,

below are some comments on draft-daboo-webdav-sync-01.

High Level:

First of all, the complexity of this mainly depends on the type of 
server. For instance, for a Subversion-style store (with a global change 
counter) this could be almost trivial, while it may be very hard to 
implement for many others.

Also, there's some related work in this area, such as:

- using a feed format (Atom?)

- sending notifications over XMPP 
(<http://greenbytes.de/tech/webdav/draft-hildebrand-webdav-notify-00.html>)

- Microsoft's take on it: SUBSCRIBE/UNSUBSCRIBE/NOTIFY/POLL 
(<http://msdn.microsoft.com/en-us/library/aa143117(EXCHG.65).aspx>)

- Notifications, as defined in JCR (Java Content Repository), which at 
some point we'll want to transport over HTTP....

- RFC 3253 (DeltaV) and WebDAV BIND which clarify what the state of a 
collection is, and define a property (DAV:resource-id) which could be 
used to define "sameness" of a WebDAV resource under name changes.

Regarding Section 3, "Open Issues":

"1. Should we try and discriminate between changes to the body of a 
resource and changes to the properties?"

I think we need to.

"2. If we indicate a property change, should we return the list of 
properties that changed on each resource (propnames NOT values)?"

Why only the names?

"3. Should we provide a way to indicate that a 'new' resource is new in 
the collection as a result of a COPY or MOVE from another location, as 
opposed to being created?"

At least MOVE and COPY should be handled separately; DAV:resource-id 
(<http://greenbytes.de/tech/webdav/draft-ietf-webdav-bind-23.html#rfc.section.3.1>) 
could be used for that.

"4. Should we provide a way to indicate that a 'deleted' resource was 
removed from the collection as a result of a MOVE to another location, 
as opposed to being actually deleted?"

Not sure it makes a difference.

"5. How should ACLs be handled? e.g. a resource is visible to a user at 
one point in time, then its <read> privilege is removed. Should the 
resource be marked as having been deleted when next synchronized?"

Why deleted? I realize that some servers return 404 for resources the 
user doesn't have read access to, but that's not the general case.

"6. Do we want a special indicator for a resource that was deleted and 
then re-created, as opposed to just indicating that the resource was 
'changed'?"

I think the information is needed. It could be provided using 
DAV:resource-id.

Other substantial comments:

1. Introduction

"This can currently be done using a WebDAV PROPFIND request on a 
collection to list all members of a collection along with their HTTP 
ETag values, which allows the client to determine which resources were 
changed, added or deleted."

s/HTTP ETag values/DAV:getetag property values/

Also note this wouldn't necessarily detect property changes.

"Additionally, a new property is added to collection resources that is 
used to convey a "synchronization token" that is guaranteed to change 
when the contents of the collection have changed."

You need to define the term "contents" here. Obviously, it includes data 
that is not included in the collection's state, as defined in RFC 3253, 
for example.

4.1

"HTTP already defines a synchronization token in the form of an entity 
tag which is attached to a resource. However, the entity tag is not 
always required to be 'strong' and thus cannot be relied on absolutely 
as a valid synchronization indicator. In addition, there is no concept 
of an entity tag for a collection's contents."

Sic -- it's because that term is not defined (at least not in the way 
this spec wants to use it :-)

4.2

"To implement the behavior for this REPORT a server needs to keep track 
of changes to any resources in a collection."

Need to clarify what "in a collection" means; I guess "Internal Member", 
as defined by RFC 4918, Section 3?

"The request URI MUST be a collection."

Why?

"The "Depth" header MUST be ignored by the server and SHOULD NOT be sent 
by the client."

Nope, see earlier discussion.

"The response body for a successful request MUST be a DAV:multistatus 
XML element, which MUST contain one DAV:sync-token element in addition 
to any DAV:sync-response elements."

Not sure why this re-uses DAV:multistatus, and then puts something 
completely else as child elements.

Editorial Comments:

- state venue for discussion

- expand abbreviations on first use

- 4.1

"The is specification defines a new WebDAV REPORT that is used to enable 
client-server collection synchronization."

"The is"?

"That is done by the client sending an empty token value to the server."

I think "no token" would be better.

- "4.2 REPORT defined"

Title.

"If the report is not available, clients MUST NOT attempt to execute one."

Requirement unnecessary.

Best regards, Julian

Date: Fri, 20 Mar 2009 14:04:40 -0700
From: Dave Thewlis <[email-masked]>
Organization: The Calendaring and Scheduling Consortium
To: ietf-caldav list <[email-masked]>
Subject: [ietf-caldav] Registration is Now Open for CalConnect XV: Roundtable XV and CalConnect Interoperability Test Event, June 1-5, 2009, Redwood Shores, California
Reply-To: [email-masked]

This is a multi-part message in MIME format.
--------------080309020406000509000303
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit

*Registration is now open* for CalConnect XV comprised of Roundtable XV 
and a CalConnect Interoperability Test Event, hosted by *Oracle in 
Redwood Shores, California*, on June 1-5, 2009.

Please see  http://www.calconnect.org/calconnect15.shtml for logistics 
information and links to registration for the Roundtable and for the 
CalConnect Interoperability Test Event.  We will meet in the Oracle 
Conference Center at 350 Oracle Parkway, Redwood Shores. 

If you are planning on participating in the CalConnect Interoperability 
Test Event, it begins with breakfast on Monday morning the 1st at 08:00 
and runs to noon on Wednesday the 3rd.  As usual the Roundtable will 
begin with lunch at 12:30 on Wednesday the 3rd  and run until early 
Friday afternoon the 5th. 

A general schedule of events is provided on the logistics page; the 
final schedule of TC sessions, together with topical agendas, will be 
available by mid-May. 

See you at Oracle in June!

*Also* as an aid to CalConnect announcements (i.e. an RSS feed) we now 
have a CalConnect blog at http://calconnect.wordpress.com.  The primary 
purpose is to announce events, publications, and other CalConnect and 
Calendaring occurrences, but there will be occasional other posts.  If 
you want to get them hot off the (Word)press, be sure and link to the 
RSS feed.

Cheers,

Dave Thewlis

-- 
*Dave Thewlis, Executive Director
Calconnect - The Calendaring and Scheduling Consortium*
+1 707 840 9391 (voice) · +1 707 498 2238 (mobile)
http://www.calconnect.org · [email-masked] 
<mailto:[email-masked]>

--------------080309020406000509000303
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
</head>
<body bgcolor="#ffffff" text="#000000">
<b>Registration is now open</b> for CalConnect XV comprised of
Roundtable
XV and
a CalConnect
Interoperability Test Event, hosted by <b>Oracle in Redwood Shores,
California</b>, on June 1-5, 2009.<br>
<br>
Please see&nbsp; <a href="http://www.calconnect.org/calconnect15.shtml">http://www.calconnect.org/calconnect15.shtml</a>
for logistics information and links to registration for the Roundtable
and for the CalConnect Interoperability Test Event.&nbsp; We will meet in
the Oracle Conference Center at 350 Oracle Parkway, Redwood Shores.&nbsp; <br>
<br>
If you are planning on participating in the CalConnect Interoperability
Test Event, it begins with breakfast on Monday morning the
1st at 08:00 and
runs to noon on Wednesday the 3rd.&nbsp; As usual the Roundtable will begin
with lunch at 12:30 on Wednesday the 3rd&nbsp; and run until early Friday
afternoon the 5th.&nbsp; <br>
<br>
A general schedule of events is provided on the logistics page; the
final schedule of TC sessions, together with topical agendas, will be
available by mid-May.&nbsp; <br>
<br>
See you at Oracle in June!<br>
<br>
<b>Also</b> as an aid to CalConnect announcements (i.e. an RSS feed)
we now have a CalConnect blog at <a
 href="http://calconnect.wordpress.com">http://calconnect.wordpress.com</a>.&nbsp;
The primary purpose is to announce events, publications, and other
CalConnect and Calendaring occurrences, but there will be occasional
other posts.&nbsp; If you want to get them hot off the (Word)press, be sure
and link to the RSS feed.<br>
<br>
Cheers,<br>
<br>
Dave Thewlis<br>
<br>
<br>
<br>
<div class="moz-signature">-- <br>
<font size="-1"><b>Dave Thewlis, Executive Director<br>
Calconnect - The Calendaring and Scheduling Consortium</b><br>
+1 707 840 9391 (voice) &middot; +1 707 498 2238 (mobile)<br>
<a href="http://www.calconnect.org">http://www.calconnect.org</a> &middot; <a
 href="mailto:[email-masked]">[email-masked]</a>
</font></div>
</body>
</html>

--------------080309020406000509000303--

From: Roberto Polli <[email-masked]>
Organization: Babel s.r.l
To: [email-masked]
Date: Mon, 16 Mar 2009 17:17:26 +0100
Subject: Re: [ietf-caldav] draft-daboo-webdav-sync-01

On mercoled=EC 11 marzo 2009 14:32:24 you wrote:
> > I miss the point:
> > * as of now we can find events by time-range with caldav for queries 1)
> > and 2) using CREATED|LAST-MOD
>
> Hmm, this is rather dangerous since those iCalendar properties are
> controlled by the client, not by the server.
I checked and you're right, but that's not evil.
example:

1) let's assume I got one client and one server in sync at T0
2) let's create 100 items (E1..E100) on client, and trigger a new sync at T1
3) imagine that sync lasts 2 minutes and ends at T3 =3D T1+120secs
4) there're now events E1..E100 on server that have been created since the=
=20
beginning of the last sync at T2  :  T1< T2 <T3

At next sync I got 2 hypothesis:
=2D  ask for events created after T0, thus retrieving as new events the one=
s I=20
put there
=2D ask for events created after T3, thus missing events created on caldav =
while=20
syncing (eg. imagine sync is scheduled each 5minutes)

using a sync engine, I could avoid storing etags data setting CREATED and=20
LAST-MODIFIED as T0 while syncing events between server and client.=20

In that way all modifications made during sync (should) remain external to =
the=20
changes made by users.

That said, it seems that playing with etags is nicely faster (but needs a s=
ync=20
engine) and the only issue remains about time-range filter.

Hope it helps+Peace,
R.

=2D-=20

Roberto Polli
Babel S.r.l. - http://www.babel.it
Tel. +39.06.91801075 - fax +39.06.91612446
P.zza S.Benedetto da Norcia, 33 - 00040 Pomezia (Roma)

"Il seguente messaggio contiene informazioni riservate. Qualora questo=20
messaggio fosse da Voi ricevuto per errore, Vogliate cortesemente darcene=20
notizia a mezzo e-mail. Vi sollecitiamo altres=EC a distruggere il messaggi=
o=20
erroneamente ricevuto. Quanto precede Vi viene chiesto ai fini del rispetto=
=20
della legge in materia di protezione dei dati personali."

Date: Thu, 12 Mar 2009 16:22:16 +0000
From: Gren Elliot <[email-masked]>
To: Julian Reschke <[email-masked]>, CalDAV DevList <[email-masked]>, Arnaud Quillaud <[email-masked]>
Subject: [ietf-caldav] Thanks Re:  <DAV:href> and invalid URL characters

Hi Julian and Arnaud,

Thank you for your quick and valuable feedback.

I agree with your thoughts that invalid characters should NOT be 
included in <href> and therefore do not plan to try and workaround 
this.  As you say, doing so may prove dangerous!

Regards,
Gren.

Date: Thu, 12 Mar 2009 16:57:14 +0100
From: Julian Reschke <[email-masked]>
To: Gren Elliot <[email-masked]>
Cc: CalDAV DevList <[email-masked]>
Subject: Re: [ietf-caldav] <DAV:href> and invalid URL characters

Gren Elliot wrote:
> Hi,
> 
> Seeking some thoughts or a pointer to a definitive answer, as I can't 
> see an immediate, definitive answer in the WebDAV spec.
> 
> We sometimes find that a CalDAV client ends up choosing the final 
> element of the path name for a new calendar entry using a PUT similar to :
> 
> PUT 
> /api/dav/Calendars/Users/[email-masked]/Calendar/%7BCA-GREN-49B1-233%7D.ics 
> HTTP/1.1
> 
> %7B happens to be the way you would encode "{" in a URL and %7D for "}", 
> these characters not being valid in a well formed URL.

Looks good so far.

> The same client then later asks for the same entry using :
> REPORT /api/dav/Calendars/Users/[email-masked]/Calendar/ HTTP/1.1
> ...
> 
> <?xml version="1.0" encoding="UTF-8" ?>
> <x0:calendar-multiget xmlns:x0="urn:ietf:params:xml:ns:caldav" 
> xmlns:x1="DAV:">
> <x1:prop>
> <x1:getetag/>
> <x0:calendar-data/>
> </x1:prop>
> <x1:href>/api/dav/Calendars/Users/[email-masked]/Calendar/{CA-GREN-49B1-233}.ics</x1:href>
> </x0:calendar-multiget>

That's, stricly speaking, a malformed request, as the contents of 
DAV:href is syntactically invalid.

> and is not happy when it gets the response :
> 
> <D:multistatus xmlns:C="urn:ietf:params:xml:ns:caldav" xmlns:D="DAV:">
> <D:response>
> <D:href>/api/dav/Calendars/Users/[email-masked]/Calendar/%7BCA-GREN-49B1-233%7D.ics</D:href>
> <D:propstat>
> <D:prop>
> <D:getetag>8</D:getetag>
> <C:calendar-data>BEGIN:VCALENDAR&#13;
> CALSCALE:GREGORIAN&#13;
> ...

It should be more than happy with it :-)

> So, my question is, what should go in <DAV:href>?  A well formed URL 
> with correct encoding or is it OK (or even more correct?) to translate 
> to the more visually friendly form?  Theoretically, in this particular 
> case, the response could follow whatever was used in the request but...

Nope.

RFC 4918 (WebDAV) requires the content to be a URI or a relative 
reference. You're not doing anybody a favor by working around client 
bugs; instead I'd recommend to contact the authors of the client and get 
it fixed.

BR, Julian

Date: Thu, 12 Mar 2009 16:56:48 +0100
From: Arnaud Quillaud <[email-masked]>
Sender: [email-masked]
To: Gren Elliot <[email-masked]>
Cc: CalDAV DevList <[email-masked]>
Subject: Re: [ietf-caldav] <DAV:href> and invalid URL characters

Gren Elliot wrote:
> Hi,
>
> Seeking some thoughts or a pointer to a definitive answer, as I can't 
> see an immediate, definitive answer in the WebDAV spec.
>
> We sometimes find that a CalDAV client ends up choosing the final 
> element of the path name for a new calendar entry using a PUT similar to :
>
> PUT 
> /api/dav/Calendars/Users/[email-masked]/Calendar/%7BCA-GREN-49B1-233%7D.ics 
> HTTP/1.1
>
> %7B happens to be the way you would encode "{" in a URL and %7D for "}", 
> these characters not being valid in a well formed URL.
>
> The same client then later asks for the same entry using :
> REPORT /api/dav/Calendars/Users/[email-masked]/Calendar/ HTTP/1.1
> ...
>
> <?xml version="1.0" encoding="UTF-8" ?>
> <x0:calendar-multiget xmlns:x0="urn:ietf:params:xml:ns:caldav" 
> xmlns:x1="DAV:">
> <x1:prop>
> <x1:getetag/>
> <x0:calendar-data/>
> </x1:prop>
> <x1:href>/api/dav/Calendars/Users/[email-masked]/Calendar/{CA-GREN-49B1-233}.ics</x1:href>
> </x0:calendar-multiget>
>
> and is not happy when it gets the response :
>
> <D:multistatus xmlns:C="urn:ietf:params:xml:ns:caldav" xmlns:D="DAV:">
> <D:response>
> <D:href>/api/dav/Calendars/Users/[email-masked]/Calendar/%7BCA-GREN-49B1-233%7D.ics</D:href>
> <D:propstat>
> <D:prop>
> <D:getetag>8</D:getetag>
> <C:calendar-data>BEGIN:VCALENDAR&#13;
> CALSCALE:GREGORIAN&#13;
> ...
>
> So, my question is, what should go in <DAV:href>?  A well formed URL 
>   
Yes, it should be encoded. See 
http://tools.ietf.org/html/rfc4918#section-8.3.1 (or read the full 
rfc3986 but that is probably more painful).

> with correct encoding or is it OK (or even more correct?) to translate 
> to the more visually friendly form?  Theoretically, in this particular 
>   
It is not OK, especially if both sides start to reencode/decode stuff, 
assuming that the other side was using/not using encoding (e.g. your %7B 
might become %407B after a first round trip, then %40407B,...).
> case, the response could follow whatever was used in the request but...
>
> Regards,
> Gren.
>
>   

Date: Thu, 12 Mar 2009 15:44:57 +0000
From: Gren Elliot <[email-masked]>
To: CalDAV DevList <[email-masked]>
Subject: [ietf-caldav] <DAV:href> and invalid URL characters

Hi,

Seeking some thoughts or a pointer to a definitive answer, as I can't 
see an immediate, definitive answer in the WebDAV spec.

We sometimes find that a CalDAV client ends up choosing the final 
element of the path name for a new calendar entry using a PUT similar to :

PUT 
/api/dav/Calendars/Users/[email-masked]/Calendar/%7BCA-GREN-49B1-233%7D.ics 
HTTP/1.1

%7B happens to be the way you would encode "{" in a URL and %7D for "}", 
these characters not being valid in a well formed URL.

The same client then later asks for the same entry using :
REPORT /api/dav/Calendars/Users/[email-masked]/Calendar/ HTTP/1.1
...

<?xml version="1.0" encoding="UTF-8" ?>
<x0:calendar-multiget xmlns:x0="urn:ietf:params:xml:ns:caldav" 
xmlns:x1="DAV:">
<x1:prop>
<x1:getetag/>
<x0:calendar-data/>
</x1:prop>
<x1:href>/api/dav/Calendars/Users/[email-masked]/Calendar/{CA-GREN-49B1-233}.ics</x1:href>
</x0:calendar-multiget>

and is not happy when it gets the response :

<D:multistatus xmlns:C="urn:ietf:params:xml:ns:caldav" xmlns:D="DAV:">
<D:response>
<D:href>/api/dav/Calendars/Users/[email-masked]/Calendar/%7BCA-GREN-49B1-233%7D.ics</D:href>
<D:propstat>
<D:prop>
<D:getetag>8</D:getetag>
<C:calendar-data>BEGIN:VCALENDAR&#13;
CALSCALE:GREGORIAN&#13;
...

So, my question is, what should go in <DAV:href>?  A well formed URL 
with correct encoding or is it OK (or even more correct?) to translate 
to the more visually friendly form?  Theoretically, in this particular 
case, the response could follow whatever was used in the request but...

Regards,
Gren.

-- 
Gren Elliot
Senior Software Engineer
*Scalix*
[email-masked]
Tel: +44 1344 381812
www.scalix.com

From: Roberto Polli <[email-masked]>
Organization: Babel s.r.l
To: Arnaud Quillaud <[email-masked]>
Date: Wed, 11 Mar 2009 15:38:15 +0100
Cc: [email-masked]
Subject: Re: [ietf-caldav] draft-daboo-webdav-sync-01

On mercoled=EC 11 marzo 2009 14:32:24 you wrote:
> this spec applies to both (and to
> any other webdav based protocol e.g. CardDAV).
ok, now all is clear ;)=20

> >> For CalDAV we would
> >> need to write an extension that would allow a time-range to be included
> >> in the report
ok. Another way could be returning the sync info in the report query, like=
=20
what we do for the etags - but maybe this is not ok for other DAV protocols=
 (I=20
know caldav only)

eg for calendar-query: REPORT /my/dav/path
<D:calendar-query>
<D:prop>
       <D:getetag/>
       <D:sync-token>1234</D:sync-token>
</D:prop>
<D:filter>
=2E...
</D:filter>
</D:calendar-query>

I should add the <D:sync-token>5678</D:sync-token> in the response.
A drawback is that we should return the same sync token in each multi-statu=
s=20
stanza.

> > ... using CREATED|LAST-MOD
> Hmm, this is rather dangerous since those iCalendar properties are
> controlled by the client, not by the server.
I'm not sure caldav servers take dumbly these props from client. I hope to=
=20
find some time to go in depth about it.

> I think the current spec returns exactly what you want.
except for the time-range issue, they seems ok.

Thank you very much for your response!

Peace, R.

=2D-=20

Roberto Polli
Babel S.r.l. - http://www.babel.it
Tel. +39.06.91801075 - fax +39.06.91612446
P.zza S.Benedetto da Norcia, 33 - 00040 Pomezia (Roma)

"Il seguente messaggio contiene informazioni riservate. Qualora questo=20
messaggio fosse da Voi ricevuto per errore, Vogliate cortesemente darcene=20
notizia a mezzo e-mail. Vi sollecitiamo altres=EC a distruggere il messaggi=
o=20
erroneamente ricevuto. Quanto precede Vi viene chiesto ai fini del rispetto=
=20
della legge in materia di protezione dei dati personali."

Date: Wed, 11 Mar 2009 14:32:24 +0100
From: Arnaud Quillaud <[email-masked]>
Sender: [email-masked]
To: Roberto Polli <[email-masked]>
Cc: [email-masked]
Subject: Re: [ietf-caldav] draft-daboo-webdav-sync-01

Roberto Polli wrote:
> On martedì 10 marzo 2009 15:50:29 you wrote:
>   
>> Note that the current spec is a generic webdav spec.
>>     
> you mean the target is about fasten webdav sync and not caldav one?
>
>   
Given that caldav is based on webdav, this spec applies to both (and to 
any other webdav based protocol e.g. CardDAV).
>> You want to get deleted items separately from other changes?
>>     
> yes. I know the issue is quite complex. Afaik sync process needs at least 3 
> methods:
> 1- get new items since last sync
> 2- get updated items since last sync
> 3- get deleted items since last sync
>
>   
The current spec gives you all 3, except that there is only one method 
(see http://tools.ietf.org/html/draft-daboo-webdav-sync-01#section-4.2):

<<

      The DAV:status element in each DAV:sync-response element is used
      to indicate how the resource may have changed:

         A status code of '201 Created' is used to indicate resources
         that are new.

         A status code of '200 OK' is used to indicate resources that
         have changed.

         A status code of '404 Not Found' is used to indicate resources
         that have been removed.

 >>

>> For CalDAV we would
>> need to write an extension that would allow a time-range to be included in
>> the report
>>     
> I miss the point:
> * as of now we can find events by time-range with caldav for queries 1) and 2) 
> using CREATED|LAST-MOD
>   
Hmm, this is rather dangerous since those iCalendar properties are 
controlled by the client, not by the server.
> * as we lack a method for 3) we're forced to use etags mapping (and storing a 
> table on database with a history between syncs), thus retrieving all events 
> and retrieve deleted items by difference of sets (stored - retrieved).
> * retrieving deleted items directly from server will (partially) solve that 
> issue.. 
>   
I think the current spec returns exactly what you want.
> I wish this mail is not too confuse.
>
> Hope it helps+Peace,
> R.
>
>   

From: Roberto Polli <[email-masked]>
Organization: Babel s.r.l
To: [email-masked]
Date: Wed, 11 Mar 2009 13:14:38 +0100
Subject: Re: [ietf-caldav] draft-daboo-webdav-sync-01

On marted=EC 10 marzo 2009 15:50:29 you wrote:
> Note that the current spec is a generic webdav spec.
you mean the target is about fasten webdav sync and not caldav one?

> You want to get deleted items separately from other changes?
yes. I know the issue is quite complex. Afaik sync process needs at least 3=
=20
methods:
1- get new items since last sync
2- get updated items since last sync
3- get deleted items since last sync

> For CalDAV we would
> need to write an extension that would allow a time-range to be included in
> the report
I miss the point:
* as of now we can find events by time-range with caldav for queries 1) and=
 2)=20
using CREATED|LAST-MOD
* as we lack a method for 3) we're forced to use etags mapping (and storing=
 a=20
table on database with a history between syncs), thus retrieving all events=
=20
and retrieve deleted items by difference of sets (stored - retrieved).
* retrieving deleted items directly from server will (partially) solve that=
=20
issue..=20

I wish this mail is not too confuse.

Hope it helps+Peace,
R.

=2D-=20

Roberto Polli
Babel S.r.l. - http://www.babel.it
Tel. +39.06.91801075 - fax +39.06.91612446
P.zza S.Benedetto da Norcia, 33 - 00040 Pomezia (Roma)

"Il seguente messaggio contiene informazioni riservate. Qualora questo=20
messaggio fosse da Voi ricevuto per errore, Vogliate cortesemente darcene=20
notizia a mezzo e-mail. Vi sollecitiamo altres=EC a distruggere il messaggi=
o=20
erroneamente ricevuto. Quanto precede Vi viene chiesto ai fini del rispetto=
=20
della legge in materia di protezione dei dati personali."

Date: Tue, 10 Mar 2009 10:50:29 -0400
From: Cyrus Daboo <[email-masked]>
To: Roberto Polli <[email-masked]>, [email-masked]
Subject: Re: [ietf-caldav] draft-daboo-webdav-sync-01

Hi Roberto,

--On March 10, 2009 3:39:33 PM +0100 Roberto Polli <[email-masked]> wrote:

>> enquiries from folks interested in implementing something like this now.
> afaik, the main issue I got with caldav is about the lack of tombstones.
>
> during sync process in the funambol-caldav connector I save a map of
> (href,etag) to be re-used each time.
>
> a nice feature would be a getDeletedEvents from server: this would enable
> the  possibilty to easily synchronize by time-range.

You want to get deleted items separately from other changes?

Note that the current spec is a generic webdav spec. For CalDAV we would 
need to write an extension that would allow a time-range to be included in 
the report so that you can do time-range syncs. That would have to be a 
CalDAV specific specification though.

-- 
Cyrus Daboo

From: Roberto Polli <[email-masked]>
Organization: Babel s.r.l
To: [email-masked]
Date: Tue, 10 Mar 2009 15:39:33 +0100
Subject: Re: [ietf-caldav] draft-daboo-webdav-sync-01

hi all,

On marted=EC 10 marzo 2009 15:09:56 Cyrus Daboo wrote:
> enquiries from folks interested in implementing something like this now.
afaik, the main issue I got with caldav is about the lack of tombstones.

during sync process in the funambol-caldav connector I save a map of=20
(href,etag) to be re-used each time.

a nice feature would be a getDeletedEvents from server: this would enable t=
he=20
possibilty to easily synchronize by time-range.

Peace, R.
=2D-=20

Roberto Polli
Babel S.r.l. - http://www.babel.it
Tel. +39.06.91801075 - fax +39.06.91612446
P.zza S.Benedetto da Norcia, 33 - 00040 Pomezia (Roma)

"Il seguente messaggio contiene informazioni riservate. Qualora questo=20
messaggio fosse da Voi ricevuto per errore, Vogliate cortesemente darcene=20
notizia a mezzo e-mail. Vi sollecitiamo altres=EC a distruggere il messaggi=
o=20
erroneamente ricevuto. Quanto precede Vi viene chiesto ai fini del rispetto=
=20
della legge in materia di protezione dei dati personali."

Date: Tue, 10 Mar 2009 10:09:56 -0400
From: Cyrus Daboo <[email-masked]>
To: WebDAV <[email-masked]>
Archived-At: <http://www.w3.org/mid/[email-masked]>
Resent-From: [email-masked]
Sender: [email-masked]
Resent-Sender: [email-masked]
Resent-Message-Id: <[email-masked]>
Resent-Date: Tue, 10 Mar 2009 14:10:39 +0000
Cc: CalDAV <[email-masked]>, CardDAV <[email-masked]>
Subject: [ietf-caldav] draft-daboo-webdav-sync-01

Hi folks,
I have posted an update for the webdav-sync extension: 
<http://tools.ietf.org/html/draft-daboo-webdav-sync-01>. This is mostly as 
refresh of the original -00 with a few references updated. The goal is to 
restart discussion of this specification as I have been getting quite a few 
enquiries from folks interested in implementing something like this now.

For now let is keep primary discussion of this document on 
[email-masked]. CalDAV and CardDAV have been cc'd as this is of 
interest in those areas too.

-- 
Cyrus Daboo

Date: Tue, 10 Mar 2009 10:09:56 -0400
From: Cyrus Daboo <[email-masked]>
To: WebDAV <[email-masked]>
Cc: CalDAV <[email-masked]>, CardDAV <[email-masked]>
Subject: [ietf-caldav] draft-daboo-webdav-sync-01

Hi folks,
I have posted an update for the webdav-sync extension: 
<http://tools.ietf.org/html/draft-daboo-webdav-sync-01>. This is mostly as 
refresh of the original -00 with a few references updated. The goal is to 
restart discussion of this specification as I have been getting quite a few 
enquiries from folks interested in implementing something like this now.

For now let is keep primary discussion of this document on 
[email-masked]. CalDAV and CardDAV have been cc'd as this is of 
interest in those areas too.

-- 
Cyrus Daboo