Subject: [caldav] new webdav sync draft

From: Arnaud Quillaud <[email-masked]>
Date: Thu, 19 Nov 2009 18:20:43 +0100

Hello,

I have just submitted a new version of the webdav sync draft ( 
http://www.ietf.org/id/draft-daboo-webdav-sync-02.txt ).

This draft addresses several, if not all, of the comments from the last 
version (change history is part of the draft).

The open issues section still contains 2 significant items, to be discussed.

Comments welcome...

Arnaud Quillaud

---

From: Julian Reschke <[email-masked]>
Date: Fri, 20 Nov 2009 08:08:41 +0100

Andrew McMillan wrote:
> ...
> In 4.2, under 'Marshalling' it states:
> 
>         The request URI MUST be a collection.  The request body MUST be
>         a DAV:sync-collection XML element (see Section 6.1), which MUST
>         contain one DAV:sync-token XML element, and optionally a
>         DAV:propstat XML element.
> ...

Nit: s/be a collection/identify a collection/

I confess I haven't looked at this closely yet, but why is it defining 
elements in the DAV: namespace?

BR, Julian

---

From: Julian Reschke <[email-masked]>
Date: Fri, 20 Nov 2009 08:08:41 +0100

BR, Julian

---

From: Cyrus Daboo <[email-masked]>
Date: Fri, 20 Nov 2009 09:11:16 -0500

Hi Julian,

> elements in the DAV: namespace?

This is generic to WebDAV, not specific to CardDAV or CalDAV. So use of 
DAV: is justified.

-- 
Cyrus Daboo

---

From: Cyrus Daboo <[email-masked]>
Date: Fri, 20 Nov 2009 09:11:16 -0500

Hi Julian,

-- 
Cyrus Daboo

---

From: Julian Reschke <[email-masked]>
Date: Fri, 20 Nov 2009 15:31:18 +0100

> This is generic to WebDAV, not specific to CardDAV or CalDAV. So use of 

<http://greenbytes.de/tech/webdav/rfc4918.html#rfc.section.21.1>:

"Creation of identifiers in the "DAV:" namespace is controlled by the IETF."

So it's not relevant whether something is generic. What's important is 
that there's IETF consensus to add new names to the namespace.

I'm not saying this can't be the case here, but I think the proper way 
would be to start with a proposal in a custom namespace, and then switch 
to the DAV: namespace once it's clear that consensus has been achieved.

BR, Julian

---

From: Julian Reschke <[email-masked]>
Date: Fri, 20 Nov 2009 15:31:18 +0100

BR, Julian

---

From: Arnaud Quillaud <[email-masked]>
Date: Fri, 20 Nov 2009 17:13:28 +0100

On 11/19/09 11:01 PM, Andrew McMillan wrote:
> On Thu, 2009-11-19 at 18:20 +0100, Arnaud Quillaud wrote:
>    
>> Hello,
>>
> Hi Arnaud,
> I have added support for this as at draft 1, and I see nothing in draft
> 2 to contradict what I have done other than clarifications and further
> questions, so that's great.
>
>
> This looks like an error, and that the optional element should be a
> DAV:prop element rather than a DAV:propstat, which is the response.
>    
Fixed. Thks.
>
> Additionally, the examples shown seem to only request 'DAV:getetag' to
> be returned, but it seems to me that in synchronising a collection that
> it would be valuable for the report to return other properties.
>    
Yes. I could add a proprietary dead property in the example to make it 
more clear.
> In particular when synchronising a calendar collection it would be
> desirable for the report to be able to return 'caldav:calendar-data',
> which in many cases would then save the further round-trip of a
> calendar-multiget report following this report.  I assume there would be
> similar advantages in retrieving the actual changed data in other
>
> Is it intended that this sort of activity is OK?  In my implementation I
> have assumed that any property might be requested - not limited to
> DAV:getetag - but from reading the examples it seems to me that it could
> be misinterpreted conservatively as only allowing requests for
> DAV:getetag.
>
>    
A client may ask for any property... as long as it is defined as such... 
calendar-data is not one of them. See 
http://tools.ietf.org/html/rfc4791#section-9.6 :
<<

However, the CALDAV:calendar-data XML element is
       not a WebDAV property and, as such, is not returned in PROPFIND
       responses

Thanks for your feedback.

Arnaud

PS: I should have mentioned this upfront but we may want to move further 
discussion to the  [email-masked] mailing list only to avoid too 
much cross posting.

---

From: Arnaud Quillaud <[email-masked]>
Date: Fri, 20 Nov 2009 17:13:28 +0100

Fixed. Thks.

Arnaud

---

From: Julian Reschke <[email-masked]>
Date: Fri, 20 Nov 2009 18:38:02 +0100

Alexey Melnikov wrote:
>> would be to start with a proposal in a custom namespace, and then 
>> switch to the DAV: namespace once it's clear that consensus has been 
>> achieved.
> 
> This sounds like a question to bring during IETF LC. If the document 
> fails to reach IETF consensus, then the prefix can be changed.
> Unless you are concerned about early implementations of the draft.
> ...

Not sure.

What you say makes it sound as if any document published by the IETF can 
use the DAV: namespace; I think the intent of RFC 4918 was something 
else (but I may be misinterpreting it): the default extension point for 
WebDAV (both in RFC 4918 and 2518) is to put extensions into a 
*different* namespace.

So far we have made exceptions in cases where the specs actually started 
as WG deliverables (redirect, search, or bind), were proposed by another 
WG (MKCOL extension), or were a *really* minor extension to an existing 
WebDAV spec (WebDAV Current Principal Extension).

The concern about early implementations is there as well, of course.

Best regards, Julian

---

From: Julian Reschke <[email-masked]>
Date: Fri, 20 Nov 2009 18:38:02 +0100

Not sure.

Best regards, Julian