Subject: 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: 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: 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: 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: 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: Andrew McMillan <[email-masked]>
Date: Sat, 21 Nov 2009 17:49:50 +1300

On Fri, 2009-11-20 at 17:13 +0100, Arnaud Quillaud wrote:
> > similar advantages in retrieving the actual changed data in other extensions.

> A client may ask for any property... as long as it is defined as
> such... calendar-data is not one of them. See

Ah, what a shame.  Can I take it from this that CardDAV will also suffer
from this limitation?

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

OK, I have done so.

Cheers,
					Andrew.

------------------------------------------------------------------------
http://andrew.mcmillan.net.nz/                     Porirua, New Zealand
Twitter: _karora                                  Phone: +64(272)DEBIAN
Facts do not cease to exist because they are ignored. -- Aldous Huxley,
                         "Proper Studies", 1927

------------------------------------------------------------------------

---

From: Julian Reschke <[email-masked]>
Date: Sat, 21 Nov 2009 07:56:35 +0100

> Ah, what a shame.  Can I take it from this that CardDAV will also suffer

Can't resist: "I told you so". Pseudo-properties are bad; they require 
more special cases, create ambiguities and confusion.

 > ..

BR, Julian

---

From: Andrew McMillan <[email-masked]>
Date: Sat, 21 Nov 2009 20:47:12 +1300

> more special cases, create ambiguities and confusion.

Conceptually, the idea of the actual data just being one element of the
meta-data doesn't seem unreasonable.

I have to confess that in my implementations to date I had just assumed
that the data is only one property within the schema, and it's certainly
much simpler for me to code it that way in my own application.

For webdav sync I would suggest that the caldav:calendar-data and
carddav:address-data (and perhaps other pseudo-properties I don't know
about) should be available to the sync report in the same way as they
are for the caldav:calendar-multiget and carddav:addressbook-multiget
reports.

It would also be nice to see a generic DAV:multiget report replacing the
*-multiget reports, since they don't seem to do anything particularly
special within their respective namespaces.

Cheers,
					Andrew McMillan.

------------------------------------------------------------------------
http://andrew.mcmillan.net.nz/                     Porirua, New Zealand
Twitter: _karora                                  Phone: +64(272)DEBIAN
       The truth is rarely pure, and never simple. -- Oscar Wilde
------------------------------------------------------------------------

---

From: Julian Reschke <[email-masked]>
Date: Sat, 21 Nov 2009 09:08:38 +0100

> meta-data doesn't seem unreasonable.

Yes, that is true. But in that case, it should behave the same 
everywhere, be it PROPFIND, PROPPATCH, REPORT or SEARCH.

> much simpler for me to code it that way in my own application.

Indeed.

BR, Julian