Re: [caldav] [VCARDDAV] new webdav sync draft
Arnaud Quillaud <Arnaud.Quillaud@Sun.COM> Fri, 20 November 2009 16:13 UTC
Return-Path: <Arnaud.Quillaud@Sun.COM>
X-Original-To: caldav@core3.amsl.com
Delivered-To: caldav@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E7A053A67A6; Fri, 20 Nov 2009 08:13:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.698
X-Spam-Level:
X-Spam-Status: No, score=-5.698 tagged_above=-999 required=5 tests=[AWL=-0.900, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_34=0.6, J_CHICKENPOX_37=0.6, J_CHICKENPOX_38=0.6, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r+15azPsHA4K; Fri, 20 Nov 2009 08:13:53 -0800 (PST)
Received: from gmp-eb-inf-2.sun.com (gmp-eb-inf-2.sun.com [192.18.6.24]) by core3.amsl.com (Postfix) with ESMTP id 7617F3A6A1F; Fri, 20 Nov 2009 08:13:53 -0800 (PST)
Received: from fe-emea-09.sun.com (gmp-eb-lb-1-fe1.eu.sun.com [192.18.6.7] (may be forged)) by gmp-eb-inf-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id nAKGDnxB006270; Fri, 20 Nov 2009 16:13:49 GMT
MIME-version: 1.0
Content-type: multipart/alternative; boundary="Boundary_(ID_Lg8ETQRR5+Vlp/WGoeGBLQ)"
Received: from conversion-daemon.fe-emea-09.sun.com by fe-emea-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KTE00J00ZZP4V00@fe-emea-09.sun.com>; Fri, 20 Nov 2009 16:13:37 +0000 (GMT)
Received: from vpn-129-150-118-65.uk.sun.com ([unknown] [129.150.118.65]) by fe-emea-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KTF00AUB12GW580@fe-emea-09.sun.com>; Fri, 20 Nov 2009 16:13:29 +0000 (GMT)
Date: Fri, 20 Nov 2009 17:13:28 +0100
From: Arnaud Quillaud <Arnaud.Quillaud@Sun.COM>
In-reply-to: <1258668093.15545.555.camel@happy.home.mcmillan.net.nz>
Sender: Arnaud.Quillaud@Sun.COM
To: Andrew McMillan <andrew@morphoss.com>
Message-id: <4B06C028.9050200@sun.com>
References: <4B057E6B.7040808@sun.com> <1258668093.15545.555.camel@happy.home.mcmillan.net.nz>
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.4pre) Gecko/20090915 Lightning/1.0pre Thunderbird/3.0b4
Cc: caldav@ietf.org, w3c-dist-auth@w3.org, vcarddav@ietf.org
Subject: Re: [caldav] [VCARDDAV] new webdav sync draft
X-BeenThere: caldav@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <caldav.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/caldav>, <mailto:caldav-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/caldav>
List-Post: <mailto:caldav@ietf.org>
List-Help: <mailto:caldav-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/caldav>, <mailto:caldav-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 20 Nov 2009 16:13:55 -0000
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.
- [caldav] new webdav sync draft Arnaud Quillaud
- Re: [caldav] [VCARDDAV] new webdav sync draft Julian Reschke
- Re: [caldav] [VCARDDAV] new webdav sync draft Cyrus Daboo
- Re: [caldav] [VCARDDAV] new webdav sync draft Julian Reschke
- Re: [caldav] [VCARDDAV] new webdav sync draft Arnaud Quillaud
- Re: [caldav] [VCARDDAV] new webdav sync draft Julian Reschke
- Re: [caldav] new webdav sync draft Helge Hess
- Re: [caldav] new webdav sync draft Arnaud Quillaud
- Re: [caldav] new webdav sync draft Cyrus Daboo
- Re: [caldav] new webdav sync draft Helge Hess
- Re: [caldav] [VCARDDAV] new webdav sync draft Julian Reschke
- Re: [caldav] [VCARDDAV] new webdav sync draft Andrew McMillan