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

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
       responses

 >>

Thanks for your feedback.

Arnaud

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.