W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > October to December 2009

Re: [VCARDDAV] [caldav] new webdav sync draft

From: Arnaud Quillaud <Arnaud.Quillaud@Sun.COM>
Date: Fri, 20 Nov 2009 17:13:28 +0100
To: Andrew McMillan <andrew@morphoss.com>
Cc: caldav@ietf.org, w3c-dist-auth@w3.org, vcarddav@ietf.org
Message-id: <4B06C028.9050200@sun.com>
On 11/19/09 11:01 PM, Andrew McMillan wrote:
> On Thu, 2009-11-19 at 18:20 +0100, Arnaud Quillaud wrote:
>> 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...
> 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.
> 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.
> 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


Thanks for your feedback.


PS: I should have mentioned this upfront but we may want to move further 
discussion to the  w3c-dist-auth@w3.org mailing list only to avoid too 
much cross posting.
Received on Friday, 20 November 2009 16:14:29 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:01:38 UTC