Return-Path: X-Original-To: ietf-caldav@osafoundation.org Delivered-To: ietf-caldav@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 426717F81F for ; Thu, 27 Apr 2006 13:44:16 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 33708142299 for ; Thu, 27 Apr 2006 13:44:16 -0700 (PDT) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 10801-09 for ; Thu, 27 Apr 2006 13:44:12 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by laweleka.osafoundation.org (Postfix) with SMTP id C9F96142295 for ; Thu, 27 Apr 2006 13:44:11 -0700 (PDT) Received: (qmail invoked by alias); 27 Apr 2006 20:44:09 -0000 Received: from p508FBC84.dip0.t-ipconnect.de (EHLO [192.168.178.21]) [80.143.188.132] by mail.gmx.net (mp041) with SMTP; 27 Apr 2006 22:44:09 +0200 X-Authenticated: #1915285 Message-ID: <44512C9B.6090102@gmx.de> Date: Thu, 27 Apr 2006 22:42:03 +0200 From: Julian Reschke User-Agent: Thunderbird 1.5.0.2 (Windows/20060308) MIME-Version: 1.0 To: Lisa Dusseault Subject: Re: [Ietf-caldav] Last Call comment on Etag requirements in draft-dusseault-caldav-12 References: <443FAB85.8030503@gmx.de> <7246CAD3-9329-4B34-8D23-08B196E80EDE@osafoundation.org> <443FEF47.3050406@gmx.de> <5FD8AADA-F91A-4B1F-9453-01178901DB6F@osafoundation.org> <443FF7B9.3050801@gmx.de> <7D5DE367-5FD8-4398-849D-2158EF6BC256@osafoundation.org> <443FFE81.6010605@gmx.de> <4440AC2D.2050802@gmx.de> <44509D3B.4050503@gmx.de> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-1.6 tagged_above=-50.0 required=4.0 tests=AWL, BAYES_00 X-Spam-Level: Cc: ietf@ietf.org, CalDAV DevList X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions on Calendar Access protocol based on WebDAV List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Apr 2006 20:44:16 -0000 Lisa Dusseault wrote: > Thanks for the input. Speaking as a document author here, I'm confident > we've made a decent set of tradeoffs, balancing possible risks against > benefits, and attempting to minimize the risks too. > > The basic risk is that any requirements related to ETags may conflict > with future requirements. We've attempted to minimize this risk by > making only one requirement -- that servers MUST NOT return strong ETags > if they have changed the data provided to be stored. We believe that > this requirement is quite within the spirit of ETag design. We didn't > make any requirements about weak ETags, nor did we require any behavior > that future specs might make illegal. Since today with HTTP it's > perfectly acceptable not to return an ETag at all, future requirements > on ETags would at least have to work with a huge deployed base of HTTP > servers that don't return any ETag on PUT responses. > > Thus, any future ETag-related requirements that invalidated this CalDAV > requirement, would also conflict with the huge deployed base of HTTP. I How so? A potential requirement of an XyzDav spec to return ETags even though the content was rewritten wouldn't be in conflict with HTTP at all. It would just be impossible to implement a resource that's both compliant to CalDAV and XyzDav. This is why I think CalDav uses the wrong approach. There's a simple way to give CalDav clients that piece of information and which is guaranteed to be compatible with other specs, and that's what CalDav should do. Or, alternatively, it could just stay silent and let that other spec work out the solution, instead of trying to come up with a fait accompli. > ... Best regards, Julian Return-Path: X-Original-To: ietf-caldav@osafoundation.org Delivered-To: ietf-caldav@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 670917F8AB for ; Thu, 27 Apr 2006 13:26:13 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 582CF142292 for ; Thu, 27 Apr 2006 13:26:13 -0700 (PDT) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 31116-07; Thu, 27 Apr 2006 13:26:10 -0700 (PDT) Received: from [192.168.1.100] (c-67-161-46-163.hsd1.ca.comcast.net [67.161.46.163]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 8BC7214228A; Thu, 27 Apr 2006 13:26:10 -0700 (PDT) In-Reply-To: <44509D3B.4050503@gmx.de> References: <443FAB85.8030503@gmx.de> <7246CAD3-9329-4B34-8D23-08B196E80EDE@osafoundation.org> <443FEF47.3050406@gmx.de> <5FD8AADA-F91A-4B1F-9453-01178901DB6F@osafoundation.org> <443FF7B9.3050801@gmx.de> <7D5DE367-5FD8-4398-849D-2158EF6BC256@osafoundation.org> <443FFE81.6010605@gmx.de> <4440AC2D.2050802@gmx.de> <44509D3B.4050503@gmx.de> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Lisa Dusseault Subject: Re: [Ietf-caldav] Last Call comment on Etag requirements in draft-dusseault-caldav-12 Date: Thu, 27 Apr 2006 13:25:54 -0700 To: Julian Reschke X-Mailer: Apple Mail (2.746.2) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-0.7 tagged_above=-50.0 required=4.0 tests=AWL, BAYES_00, RCVD_IN_NJABL_DUL, RCVD_IN_SORBS_DUL X-Spam-Level: Cc: ietf@ietf.org, CalDAV DevList X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions on Calendar Access protocol based on WebDAV List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Apr 2006 20:26:13 -0000 Thanks for the input. Speaking as a document author here, I'm confident we've made a decent set of tradeoffs, balancing possible risks against benefits, and attempting to minimize the risks too. The basic risk is that any requirements related to ETags may conflict with future requirements. We've attempted to minimize this risk by making only one requirement -- that servers MUST NOT return strong ETags if they have changed the data provided to be stored. We believe that this requirement is quite within the spirit of ETag design. We didn't make any requirements about weak ETags, nor did we require any behavior that future specs might make illegal. Since today with HTTP it's perfectly acceptable not to return an ETag at all, future requirements on ETags would at least have to work with a huge deployed base of HTTP servers that don't return any ETag on PUT responses. Thus, any future ETag-related requirements that invalidated this CalDAV requirement, would also conflict with the huge deployed base of HTTP. I find that sufficiently unlikely as to be an acceptable risk to take. Any standard we write has some risk of making requirements that are in conflict with future spec requirements and so we always take this kind of risk. I do hope that new work on ETags and PUT will clarify this situation further for all protocols, and if it becomes desirable to re-issue CalDAV to make use of that general work, I'll be happy to re-issue it. Lisa On Apr 27, 2006, at 3:30 AM, Julian Reschke wrote: > Hi, > > I note that draft 12 of caldav still makes requirements that are > potentially incompatible with HTTP: > > Quoting caldav-12.html#rfc.section.5.3.4.p.4>: > > "In the case where the data stored by a server as a result of a PUT > request is not equivalent by octet equality to the submitted > calendar object resource, the behavior of the ETag response header > is undefined, with the exception that a strong entity tag MUST NOT > be returned in the response. As a result, clients may need to > retrieve the modified calendar object resource (and ETag) as a > basis for further changes, rather than use the calendar object > resource it had sent with the PUT request." > > This is a requirement that is not in RFC2616. Adding this to CalDav > may make it impossible to implement resources that are both > compliant to CalDav and other HTTP based specifications (which may > have a different opinion about ETags in PUT responses). > > If CalDav clients *really* require knowledge about this situation, > please define it in a way that will not potentially be in conflict > with other specifications, such as by adding a *new* response > header, indicating that content was not rewritten (as proposed in > 000787.html> two weeks ago). > > Best regards, Julian > > _______________________________________________ > Ietf-caldav mailing list -- Ietf-caldav@osafoundation.org > See http://ietf.webdav.org/caldav/ for more CalDAV resources > http://lists.osafoundation.org/mailman/listinfo/ietf-caldav Return-Path: X-Original-To: ietf-caldav@osafoundation.org Delivered-To: ietf-caldav@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 3A22F7F82F for ; Thu, 27 Apr 2006 07:22:15 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 2C75E142295 for ; Thu, 27 Apr 2006 07:22:15 -0700 (PDT) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 09541-09 for ; Thu, 27 Apr 2006 07:22:13 -0700 (PDT) Received: from agminet01.oracle.com (agminet01.oracle.com [141.146.126.228]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 9B086142281 for ; Thu, 27 Apr 2006 07:22:13 -0700 (PDT) Received: from rgmsgw301.us.oracle.com (rgmsgw301.us.oracle.com [138.1.186.50]) by agminet01.oracle.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id k3REMCR1025686 for ; Thu, 27 Apr 2006 09:22:12 -0500 Received: from [10.156.42.83] (bdesruis-ca.ca.oracle.com [10.156.42.83]) by rgmsgw301.us.oracle.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id k3REMAuM002505 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Thu, 27 Apr 2006 08:22:11 -0600 Message-ID: <4450D37E.4090207@oracle.com> Date: Thu, 27 Apr 2006 10:21:50 -0400 From: Bernard Desruisseaux User-Agent: Thunderbird 1.5.0.2 (Windows/20060308) MIME-Version: 1.0 To: CalDAV DevList Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAQAAAAI= X-Whitelist: TRUE X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-2.3 tagged_above=-50.0 required=4.0 tests=AWL, BAYES_00 X-Spam-Level: Subject: [Ietf-caldav] [Fwd: Last Call: 'Calendaring Extensions to WebDAV (CalDAV)' to Proposed Standard (draft-dusseault-caldav)] X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions on Calendar Access protocol based on WebDAV List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Apr 2006 14:22:15 -0000 -------- Original Message -------- Subject: Last Call: 'Calendaring Extensions to WebDAV (CalDAV)' to Proposed Standard (draft-dusseault-caldav) Date: Wed, 26 Apr 2006 17:01:38 -0400 From: The IESG Reply-To: iesg@ietf.org To: IETF-Announce The IESG has received a request from an individual submitter to consider the following document: - 'Calendaring Extensions to WebDAV (CalDAV) ' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by 2006-05-24. The file can be obtained via http://www.ietf.org/internet-drafts/draft-dusseault-caldav-12.txt _______________________________________________ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce Return-Path: X-Original-To: ietf-caldav@osafoundation.org Delivered-To: ietf-caldav@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id DA1E77F82F for ; Thu, 27 Apr 2006 07:21:58 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id CA8CA142295 for ; Thu, 27 Apr 2006 07:21:58 -0700 (PDT) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 09541-08 for ; Thu, 27 Apr 2006 07:21:57 -0700 (PDT) Received: from agminet01.oracle.com (agminet01.oracle.com [141.146.126.228]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 083DD142281 for ; Thu, 27 Apr 2006 07:21:56 -0700 (PDT) Received: from rgmsgw300.us.oracle.com (rgmsgw300.us.oracle.com [138.1.186.49]) by agminet01.oracle.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id k3RELtgc025262 for ; Thu, 27 Apr 2006 09:21:55 -0500 Received: from [10.156.42.83] (bdesruis-ca.ca.oracle.com [10.156.42.83]) by rgmsgw300.us.oracle.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id k3RELraA017934 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Thu, 27 Apr 2006 08:21:54 -0600 Message-ID: <4450D36C.2090809@oracle.com> Date: Thu, 27 Apr 2006 10:21:32 -0400 From: Bernard Desruisseaux User-Agent: Thunderbird 1.5.0.2 (Windows/20060308) MIME-Version: 1.0 To: CalDAV DevList Content-Type: multipart/mixed; boundary="------------020309050503000001020909" X-Brightmail-Tracker: AAAAAQAAAAI= X-Whitelist: TRUE X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-2.3 tagged_above=-50.0 required=4.0 tests=AWL, BAYES_00 X-Spam-Level: Subject: [Ietf-caldav] [Fwd: I-D ACTION:draft-dusseault-caldav-12.txt] X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions on Calendar Access protocol based on WebDAV List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Apr 2006 14:21:59 -0000 This is a multi-part message in MIME format. --------------020309050503000001020909 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit -------- Original Message -------- Subject: I-D ACTION:draft-dusseault-caldav-12.txt Date: Wed, 26 Apr 2006 15:50:01 -0400 From: Internet-Drafts@ietf.org Reply-To: internet-drafts@ietf.org To: i-d-announce@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Calendaring Extensions to WebDAV (CalDAV) Author(s) : L. Dusseault, et al. Filename : draft-dusseault-caldav-12.txt Pages : 109 Date : 2006-4-26 This document specifies a set of methods, headers, message bodies, properties, and reports that define calendar access extensions to the WebDAV protocol. The new protocol elements are intended to make WebDAV-based calendaring and scheduling an interoperable standard that supports calendar access, calendar management, calendar sharing, and calendar publishing. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-dusseault-caldav-12.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-dusseault-caldav-12.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-dusseault-caldav-12.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --------------020309050503000001020909 Content-Type: Message/External-body; name="draft-dusseault-caldav-12.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="draft-dusseault-caldav-12.txt" Content-Type: text/plain Content-ID: <2006-4-26125716.I-D@ietf.org> --------------020309050503000001020909 Content-Type: text/plain; name*0="file:///C|/DOCUME%7E1/BDESRU%7E1.ST-/LOCALS%7E1/TEMP/nsmail.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename*0="file:///C|/DOCUME%7E1/BDESRU%7E1.ST-/LOCALS%7E1/TEMP/nsmail."; filename*1="txt" _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/i-d-announce --------------020309050503000001020909-- Return-Path: X-Original-To: ietf-caldav@osafoundation.org Delivered-To: ietf-caldav@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 3A4BC7F556 for ; Thu, 27 Apr 2006 06:37:38 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 2AB8B14225E for ; Thu, 27 Apr 2006 06:37:38 -0700 (PDT) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 10112-05 for ; Thu, 27 Apr 2006 06:37:34 -0700 (PDT) Received: from rgminet01.oracle.com (rgminet01.oracle.com [148.87.113.118]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 71B6A14225C for ; Thu, 27 Apr 2006 06:37:34 -0700 (PDT) Received: from rgmsgw300.us.oracle.com (rgmsgw300.us.oracle.com [138.1.186.49]) by rgminet01.oracle.com (Switch-3.1.6/Switch-3.1.6) with ESMTP id k3RDbWQZ024272; Thu, 27 Apr 2006 07:37:32 -0600 Received: from [10.156.42.83] (bdesruis-ca.ca.oracle.com [10.156.42.83]) by rgmsgw300.us.oracle.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id k3RDbUKW003374 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Thu, 27 Apr 2006 07:37:31 -0600 Message-ID: <4450C90C.4020106@oracle.com> Date: Thu, 27 Apr 2006 09:37:16 -0400 From: Bernard Desruisseaux User-Agent: Thunderbird 1.5.0.2 (Windows/20060308) MIME-Version: 1.0 To: venkat Subject: Re: [Ietf-caldav] caldav protocol - doubt References: <20060427124027.92867.qmail@web30811.mail.mud.yahoo.com> In-Reply-To: <20060427124027.92867.qmail@web30811.mail.mud.yahoo.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAQAAAAI= X-Whitelist: TRUE X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-2.3 tagged_above=-50.0 required=4.0 tests=AWL, BAYES_00 X-Spam-Level: Cc: ietf-caldav@osafoundation.org X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions on Calendar Access protocol based on WebDAV List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Apr 2006 13:37:38 -0000 Hi Venkat, The CALDAV:time-range XML element specifies a search criteria. That is, a condition a calendar object resource must match in order to be returned in a calendaring report response. The CALDAV:limit-freebusy-set XML element specifies which FREEBUSY property values of a VFREEBUSY component should be returned in a calendaring report response. Here's 2 different use cases: If you are only interested in free busy information in a given time range, you would specify this time range in the CALDAV:time-range XML element nested in the CALDAV:filter element in order to select all the VFREEBUSY components that contain free busy information in that time range, and you would also specify the same time range in the CALDAV:limit-freebusy-set XML element to filter out the FREEBUSY property outside the time range that is of interest to you. If you are searching for VFREEBUSY components that defines FREEBUSY property values in a given time range and that you want you want to receive all the FREEBUSY property values of the matched VFREEBUSY components (i.e., even the FREEBUSY property values outside your specified time range), but that your CalDAV client only supports date values between 1990 and 2038, you might want to specify this time range in the CALDAV:limit-freebusy-set to avoid receiving FREEBUSY property values outside this time range. Cheers, Bernard venkat wrote: > > > Hi, > > I am trying to understand the CalDAV protocol and build a small prototype. > > In the following example, why are two time ranges(limit-freebusy-set, time-range) required? > How should it be handled if they are different? > > > xmlns:C="urn:ietf:params:xml:ns:caldav"> > > > end="20060103T000000Z"/> > > > > > > end="20060103T000000Z"/> > > > > > > Thanks > Venkat > > > > > > > > > > > > > > > > > > > > > > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Ietf-caldav mailing list -- Ietf-caldav@osafoundation.org > See http://ietf.webdav.org/caldav/ for more CalDAV resources > http://lists.osafoundation.org/mailman/listinfo/ietf-caldav Return-Path: X-Original-To: ietf-caldav@osafoundation.org Delivered-To: ietf-caldav@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 6DF897F87D for ; Thu, 27 Apr 2006 05:40:29 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 52451142299 for ; Thu, 27 Apr 2006 05:40:29 -0700 (PDT) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 29282-03 for ; Thu, 27 Apr 2006 05:40:28 -0700 (PDT) Received: from web30811.mail.mud.yahoo.com (web30811.mail.mud.yahoo.com [68.142.201.254]) by laweleka.osafoundation.org (Postfix) with SMTP id CFCAB142298 for ; Thu, 27 Apr 2006 05:40:27 -0700 (PDT) Received: (qmail 92869 invoked by uid 60001); 27 Apr 2006 12:40:27 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Date:From:Subject:To:MIME-Version:Content-Type; b=0r7Tr9lX/WsaC2q98bqLFZ+al/9xIRlEJPrvdqWXo3gqRShMGqaoa3eQZBOe8bVhPTBt3iQ/NTTaGEXPHDrER0wURlGxl/03S4+dlPsMEwZk633eIg5fucD/ddF/p87Olkh+bEBtaaGvf6pgeuOePY/pkvxcuqXjyLvuuPZ4wNQ= ; Message-ID: <20060427124027.92867.qmail@web30811.mail.mud.yahoo.com> Date: Thu, 27 Apr 2006 05:40:27 -0700 (PDT) From: venkat To: ietf-caldav@osafoundation.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-806199334-1146141627=:92162" X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=0.4 tagged_above=-50.0 required=4.0 tests=BAYES_00, DNS_FROM_RFC_WHOIS, FORGED_YAHOO_RCVD, HTML_MESSAGE X-Spam-Level: Subject: [Ietf-caldav] caldav protocol - doubt X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions on Calendar Access protocol based on WebDAV List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Apr 2006 12:40:29 -0000 --0-806199334-1146141627=:92162 Content-Type: text/plain; charset=us-ascii -- DIV {margin:0px} --> Hi, I am trying to understand the CalDAV protocol and build a small prototype. In the following example, why are two time ranges(limit-freebusy-set, time-range) required? How should it be handled if they are different? Thanks Venkat --0-806199334-1146141627=:92162 Content-Type: text/html; charset=us-ascii 
Hi,

I am trying to understand the CalDAV protocol and build a small prototype.

In the following example, why are two time ranges(limit-freebusy-set, time-range) required? 
How should it be handled if they are different?

<?xml version="1.0" encoding="utf-8" ?>
   <C:calendar-query xmlns:D="DAV:"
                 xmlns:C="urn:ietf:params:xml:ns:caldav">
     <D:prop>
       <C:calendar-data>
         <C:limit-freebusy-set start="20060102T000000Z"
                                 end="20060103T000000Z"/>
       </C:calendar-data>
     </D:prop>
     <C:filter>
       <C:comp-filter name="VCALENDAR">
         <C:comp-filter name="VFREEBUSY">
           <C:time-range start="20060102T000000Z"
                           end="20060103T000000Z"/>
         </C:comp-filter>
       </C:comp-filter>
     </C:filter>
   </C:calendar-query>

Thanks
Venkat























--0-806199334-1146141627=:92162-- Return-Path: X-Original-To: ietf-caldav@osafoundation.org Delivered-To: ietf-caldav@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 1A2CE7F864 for ; Thu, 27 Apr 2006 03:32:28 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 0A474142293 for ; Thu, 27 Apr 2006 03:32:28 -0700 (PDT) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 15600-08 for ; Thu, 27 Apr 2006 03:32:25 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.de [213.165.64.20]) by laweleka.osafoundation.org (Postfix) with SMTP id 088F5142288 for ; Thu, 27 Apr 2006 03:32:24 -0700 (PDT) Received: (qmail invoked by alias); 27 Apr 2006 10:32:22 -0000 Received: from mail.greenbytes.de (EHLO [192.168.1.40]) [217.91.35.233] by mail.gmx.net (mp040) with SMTP; 27 Apr 2006 12:32:22 +0200 X-Authenticated: #1915285 Message-ID: <44509D3B.4050503@gmx.de> Date: Thu, 27 Apr 2006 12:30:19 +0200 From: Julian Reschke User-Agent: Thunderbird 1.5.0.2 (Windows/20060308) MIME-Version: 1.0 To: ietf@ietf.org, CalDAV DevList References: <443FAB85.8030503@gmx.de> <7246CAD3-9329-4B34-8D23-08B196E80EDE@osafoundation.org> <443FEF47.3050406@gmx.de> <5FD8AADA-F91A-4B1F-9453-01178901DB6F@osafoundation.org> <443FF7B9.3050801@gmx.de> <7D5DE367-5FD8-4398-849D-2158EF6BC256@osafoundation.org> <443FFE81.6010605@gmx.de> <4440AC2D.2050802@gmx.de> In-Reply-To: <4440AC2D.2050802@gmx.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-1.6 tagged_above=-50.0 required=4.0 tests=AWL, BAYES_00 X-Spam-Level: Subject: [Ietf-caldav] Last Call comment on Etag requirements in draft-dusseault-caldav-12 X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions on Calendar Access protocol based on WebDAV List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Apr 2006 10:32:28 -0000 Hi, I note that draft 12 of caldav still makes requirements that are potentially incompatible with HTTP: Quoting : "In the case where the data stored by a server as a result of a PUT request is not equivalent by octet equality to the submitted calendar object resource, the behavior of the ETag response header is undefined, with the exception that a strong entity tag MUST NOT be returned in the response. As a result, clients may need to retrieve the modified calendar object resource (and ETag) as a basis for further changes, rather than use the calendar object resource it had sent with the PUT request." This is a requirement that is not in RFC2616. Adding this to CalDav may make it impossible to implement resources that are both compliant to CalDav and other HTTP based specifications (which may have a different opinion about ETags in PUT responses). If CalDav clients *really* require knowledge about this situation, please define it in a way that will not potentially be in conflict with other specifications, such as by adding a *new* response header, indicating that content was not rewritten (as proposed in two weeks ago). Best regards, Julian Return-Path: X-Original-To: ietf-caldav@osafoundation.org Delivered-To: ietf-caldav@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 0336B7F70E for ; Tue, 18 Apr 2006 06:38:03 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id E6D5A14226F for ; Tue, 18 Apr 2006 06:38:02 -0700 (PDT) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 17157-07 for ; Tue, 18 Apr 2006 06:38:02 -0700 (PDT) Received: from out1.smtp.messagingengine.com (out1.smtp.messagingengine.com [66.111.4.25]) by laweleka.osafoundation.org (Postfix) with ESMTP id 2ED1C14226C for ; Tue, 18 Apr 2006 06:38:02 -0700 (PDT) Received: from frontend2.internal (frontend2.internal [10.202.2.151]) by frontend1.messagingengine.com (Postfix) with ESMTP id 0F558D4C209; Tue, 18 Apr 2006 09:38:01 -0400 (EDT) Received: from frontend3.messagingengine.com ([10.202.2.152]) by frontend2.internal (MEProxy); Tue, 18 Apr 2006 09:37:28 -0400 X-Sasl-enc: dSk+9fSqWu5905hvgvmdJ8oJJz5uqdEQWntU6cDEN9ZI 1145367448 Received: from [17.101.35.110] (unknown [17.101.35.110]) by www.fastmail.fm (Postfix) with ESMTP id 73D8F8A3B; Tue, 18 Apr 2006 09:37:26 -0400 (EDT) Date: Tue, 18 Apr 2006 09:38:02 -0400 From: Cyrus Daboo To: Jay Batson Subject: Re: [Ietf-caldav] I-D ACTION:draft-dusseault-caldav-11.txt (fwd) Message-ID: In-Reply-To: <553FF59D-A154-4AA9-956C-D76C242D43A4@plumcanary.com> References: <443FAB85.8030503@gmx.de> <7246CAD3-9329-4B34-8D23-08B196E80EDE@osafoundation.org> <443FEF47.3050406@gmx.de> <5FD8AADA-F91A-4B1F-9453-01178901DB6F@osafoundation.org> <443FF7B9.3050801@gmx.de> <7D5DE367-5FD8-4398-849D-2158EF6BC256@osafoundation.org> <443FFE81.6010605@gmx.de> <4440AC2D.2050802@gmx.de> <1145343520.26786.36.camel@hed034-145.research.nokia.com> <553FF59D-A154-4AA9-956C-D76C242D43A4@plumcanary.com> X-Mailer: Mulberry/4.0.4 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-2.0 tagged_above=-50.0 required=4.0 tests=AWL, BAYES_00 X-Spam-Level: Cc: CalDAV DevList X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions on Calendar Access protocol based on WebDAV List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Apr 2006 13:38:03 -0000 Hi Jay, --On April 18, 2006 8:35:54 AM -0400 Jay Batson wrote: > In summary, my thoughts on the requirements: > - Permit changes to DB on either side (client/server) while clients/ > servers are not connected; This is certainly allowed with CalDAV as it stands today. > - Ability for one side (client or server; probably client in the context > of CalDAV) to detect which objects (events, todos, ...) to detect > modifications made at the other end while disconnected; Again possible right now. The crude approach would be to do a PROPFIND Depth:1 on a calendar collection requesting the DAV:getetag property and then use the results to compare with the items cached locally. The client can then use the multiget report to fetch those items that have changed or are new, and can upload its changed or new items. This is not ideal from a network bandwidth standpoint when calendars get large (as they undoubtedly will do). In that case clients can be smarter about using the calendar-query report with time-range option to refresh portions of their cache in a 'paged' manner (e.g. on initial connect refresh one month either side of the current 'view' the user has set, then refresh other time ranges either on demand or in the background). > - Ability for one side (ditto) to inform the other of changes made while > disconnected; Notifications of changes (even whilst the client thinks it is connected) are not supported right now. We do plan on addressing that at some point. > - Ability for the side doing the detection/informing to perform user- > directed conflict resolution, and set the DB on both ends to contained > the result. Right now the client is responsible for conflict resolution - that I think is the right solution as in many cases the user will need to be consulted about how to resolve a conflict. > - Do the detection/informing/updating in a bandwidth-efficient manner; We need not include a more efficient synchronization facility in CalDAV for various reasons. However, as I've mentioned previously, I did put together a 'prototype' solution in CardDAV with the hopes that that would be critiqued and ultimately lead to a solution in CalDAV (which would have to be done as an extension). So I would certainly welcome feedback on that feature in CardDAV with a view to having something similar for CalDAV. -- Cyrus Daboo Return-Path: X-Original-To: ietf-caldav@osafoundation.org Delivered-To: ietf-caldav@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 3C9ED7F6DC for ; Tue, 18 Apr 2006 05:36:05 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 2EB6A14226F for ; Tue, 18 Apr 2006 05:36:05 -0700 (PDT) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 24933-05 for ; Tue, 18 Apr 2006 05:36:02 -0700 (PDT) Received: from plumcanary.com (sync.plumcanary.com [216.154.222.73]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 00D78142269 for ; Tue, 18 Apr 2006 05:36:01 -0700 (PDT) Received: from [10.0.0.8] (AMarigot-102-1-2-109.w81-248.abo.wanadoo.fr [81.248.11.109]) by plumcanary.com (8.12.11.20060308/8.12.10) with ESMTP id k3ICZqoh014866; Tue, 18 Apr 2006 08:35:52 -0400 In-Reply-To: <1145343520.26786.36.camel@hed034-145.research.nokia.com> References: <443FAB85.8030503@gmx.de> <7246CAD3-9329-4B34-8D23-08B196E80EDE@osafoundation.org> <443FEF47.3050406@gmx.de> <5FD8AADA-F91A-4B1F-9453-01178901DB6F@osafoundation.org> <443FF7B9.3050801@gmx.de> <7D5DE367-5FD8-4398-849D-2158EF6BC256@osafoundation.org> <443FFE81.6010605@gmx.de> <4440AC2D.2050802@gmx.de> <1145343520.26786.36.camel@hed034-145.research.nokia.com> Mime-Version: 1.0 (Apple Message framework v749.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <553FF59D-A154-4AA9-956C-D76C242D43A4@plumcanary.com> Content-Transfer-Encoding: 7bit From: Jay Batson Subject: Re: [Ietf-caldav] I-D ACTION:draft-dusseault-caldav-11.txt (fwd) Date: Tue, 18 Apr 2006 08:35:54 -0400 To: Jari Urpalainen X-Mailer: Apple Mail (2.749.3) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-2.6 tagged_above=-50.0 required=4.0 tests=BAYES_00 X-Spam-Level: Cc: CalDAV DevList X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions on Calendar Access protocol based on WebDAV List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Apr 2006 12:36:05 -0000 Without (being capable of) expressing a solution preference, I want to make sure the authors have sufficient "evidence on the list" that -- as part of the basic requirements -- CalDAV must provide an acceptable, efficient way for calendaring clients to be capable of "offline use using cached calendars & change detection-resolution (on reconnect)" mentioned by Julian. This is, as you're all painfully aware, a difficult thing to do efficiently. There are obvious tradeoffs: - Good: Client-side detection of changes, & conflict resolution, scales well (by moving the processing to the client); - Bad: If designed badly, client-side detection of changes can lead to a significant amount of network traffic to obtain necessary information from the server to perform the sync / resolution. There are still a significant number of places where CalDAV (and HTTP) are going to be used over dial-up where you can't simply assume "free, high-speed bandwidth" for all the client/server interactions. - (Of course, server-side resolution has the opposite problems). - Version tags are good, and historically many products have been built using this method. The devil-in-the-details question is always "How granular should the version tags be? Per-field, per-object (e.g. VEVENT), or per-Calendar?" Again, with processing / bandwidth tradeoffs being the obstacles. I'm technical enough to know the problem, and need, exists, and have been involved at an engineering-management level with two commercial products that have solved the problem (MeetingMaker, and Chirp). So I know it can be done; but you're better off not asking me to design the solution. I'm not *that* technical. :-) In summary, my thoughts on the requirements: - Permit changes to DB on either side (client/server) while clients/ servers are not connected; - Ability for one side (client or server; probably client in the context of CalDAV) to detect which objects (events, todos, ...) to detect modifications made at the other end while disconnected; - Ability for one side (ditto) to inform the other of changes made while disconnected; - Ability for the side doing the detection/informing to perform user- directed conflict resolution, and set the DB on both ends to contained the result. - Do the detection/informing/updating in a bandwidth-efficient manner; Cheers -jb On Apr 18, 2006, at 2:58 AM, Jari Urpalainen wrote: > On Sat, 2006-04-15 at 10:17 +0200, ext Julian Reschke wrote: >> Lisa Dusseault wrote: >>> >>> On Apr 14, 2006, at 12:56 PM, Julian Reschke wrote: >>> >>>>> happen, some clients might always do a GET (poor performance) and >>>>> others might always not (poor interoperability). >>>> >>>> Just tell clients to do conditional GETs with the cache >>>> validator they >>>> got upon PUT. The client may not have the same content octet-for- >>>> octet >>>> as the server, but besides that I see no problem (yet). >>> >>> Yes, but that's exactly it, there's confusion about what the cache >>> validator they got upon PUT means, or in what cases the server is >>> allowed to return it. Many clients cache calendar items for >>> offline >>> use, and if the server has added its own custom properties or >>> modified >>> data, that may well need to be available offline as well. >> >> Currently, there's no way to find out. If this is a requirement, >> CalDAV >> will either have to rely on draft-whitehead-http-etag solving that >> problem, or come up with its own solution. >> >> I'd prefer the former approach, because solving this once and for all >> HTTP based specs certainly is better. >> >> If CalDAV wants to do its own thing, it must make sure that it >> doesn't >> contradict other specs, on which it builds or that servers may >> want to >> implement in parallel with CalDAV. A safe way to do that for now >> would >> be to add a new response header that contains just that piece of >> information, such as: >> >> X-Content-Rewritten: "T" / "F" >> >> Best regards, Julian > > We had similar ambiquities/difficulties with ETags in XCAP, where > adding > new headers were not the preferred way to solve this kind of issues. > That said, as I have also previously said that 5.3.4 section was > somewhat difficult to understand and incorrect (rfc2616 reference > and no > clear why reasoning of ETag behavior), I agree with Julian that a new > X-header or a normative reference to draft-whitehead-http-etag is a > better way to solve this issue, and certainly the latter option the > best > one. > br, > Jari > > _______________________________________________ > Ietf-caldav mailing list -- Ietf-caldav@osafoundation.org > See http://ietf.webdav.org/caldav/ for more CalDAV resources > http://lists.osafoundation.org/mailman/listinfo/ietf-caldav ------------- Jay Batson batsonjay@plumcanary.com +1-978-824-0111 (w) +1-978-758-1599 (m) Return-Path: X-Original-To: ietf-caldav@osafoundation.org Delivered-To: ietf-caldav@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id AF7117F715; Mon, 17 Apr 2006 23:59:24 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 9FBB5142272; Mon, 17 Apr 2006 23:59:24 -0700 (PDT) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 16253-05; Mon, 17 Apr 2006 23:59:22 -0700 (PDT) Received: from mgw-ext13.nokia.com (mgw-ext13.nokia.com [131.228.20.172]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 9A024142287; Mon, 17 Apr 2006 23:59:21 -0700 (PDT) Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext13.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k3I6vgTc019649; Tue, 18 Apr 2006 09:57:46 +0300 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 18 Apr 2006 09:58:41 +0300 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 18 Apr 2006 09:58:41 +0300 Received: from 172.21.34.145 ([172.21.34.145]) by esebe105.NOE.Nokia.com ([172.21.143.53]) with Microsoft Exchange Server HTTP-DAV ; Tue, 18 Apr 2006 06:58:40 +0000 Received: from hed034-145.research.nokia.com by esebe105.noe.nokia.com; 18 Apr 2006 09:58:40 +0300 Subject: Re: [Ietf-caldav] I-D ACTION:draft-dusseault-caldav-11.txt (fwd) From: Jari Urpalainen To: ext Julian Reschke In-Reply-To: <4440AC2D.2050802@gmx.de> References: <443FAB85.8030503@gmx.de> <7246CAD3-9329-4B34-8D23-08B196E80EDE@osafoundation.org> <443FEF47.3050406@gmx.de> <5FD8AADA-F91A-4B1F-9453-01178901DB6F@osafoundation.org> <443FF7B9.3050801@gmx.de> <7D5DE367-5FD8-4398-849D-2158EF6BC256@osafoundation.org> <443FFE81.6010605@gmx.de> <4440AC2D.2050802@gmx.de> Content-Type: text/plain Content-Transfer-Encoding: 7bit Date: Tue, 18 Apr 2006 09:58:40 +0300 Message-Id: <1145343520.26786.36.camel@hed034-145.research.nokia.com> Mime-Version: 1.0 X-Mailer: Evolution 2.6.0 (2.6.0-1) X-OriginalArrivalTime: 18 Apr 2006 06:58:41.0452 (UTC) FILETIME=[86A9DEC0:01C662B5] X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-1.3 tagged_above=-50.0 required=4.0 tests=AWL, BAYES_00 X-Spam-Level: Cc: CalDAV DevList X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions on Calendar Access protocol based on WebDAV List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Apr 2006 06:59:24 -0000 On Sat, 2006-04-15 at 10:17 +0200, ext Julian Reschke wrote: > Lisa Dusseault wrote: > > > > On Apr 14, 2006, at 12:56 PM, Julian Reschke wrote: > > > >>> happen, some clients might always do a GET (poor performance) and > >>> others might always not (poor interoperability). > >> > >> Just tell clients to do conditional GETs with the cache validator they > >> got upon PUT. The client may not have the same content octet-for-octet > >> as the server, but besides that I see no problem (yet). > > > > Yes, but that's exactly it, there's confusion about what the cache > > validator they got upon PUT means, or in what cases the server is > > allowed to return it. Many clients cache calendar items for offline > > use, and if the server has added its own custom properties or modified > > data, that may well need to be available offline as well. > > Currently, there's no way to find out. If this is a requirement, CalDAV > will either have to rely on draft-whitehead-http-etag solving that > problem, or come up with its own solution. > > I'd prefer the former approach, because solving this once and for all > HTTP based specs certainly is better. > > If CalDAV wants to do its own thing, it must make sure that it doesn't > contradict other specs, on which it builds or that servers may want to > implement in parallel with CalDAV. A safe way to do that for now would > be to add a new response header that contains just that piece of > information, such as: > > X-Content-Rewritten: "T" / "F" > > Best regards, Julian We had similar ambiquities/difficulties with ETags in XCAP, where adding new headers were not the preferred way to solve this kind of issues. That said, as I have also previously said that 5.3.4 section was somewhat difficult to understand and incorrect (rfc2616 reference and no clear why reasoning of ETag behavior), I agree with Julian that a new X-header or a normative reference to draft-whitehead-http-etag is a better way to solve this issue, and certainly the latter option the best one. br, Jari Return-Path: X-Original-To: ietf-caldav@osafoundation.org Delivered-To: ietf-caldav@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id CE3B17F8C8 for ; Sat, 15 Apr 2006 01:19:40 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id BF8E4142258 for ; Sat, 15 Apr 2006 01:19:40 -0700 (PDT) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 07367-03 for ; Sat, 15 Apr 2006 01:19:39 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by laweleka.osafoundation.org (Postfix) with SMTP id AB295142262 for ; Sat, 15 Apr 2006 01:19:38 -0700 (PDT) Received: (qmail invoked by alias); 15 Apr 2006 08:19:36 -0000 Received: from p508FC3DC.dip0.t-ipconnect.de (EHLO [192.168.178.21]) [80.143.195.220] by mail.gmx.net (mp032) with SMTP; 15 Apr 2006 10:19:36 +0200 X-Authenticated: #1915285 Message-ID: <4440AC2D.2050802@gmx.de> Date: Sat, 15 Apr 2006 10:17:49 +0200 From: Julian Reschke User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Lisa Dusseault Subject: Re: [Ietf-caldav] I-D ACTION:draft-dusseault-caldav-11.txt (fwd) References: <443FAB85.8030503@gmx.de> <7246CAD3-9329-4B34-8D23-08B196E80EDE@osafoundation.org> <443FEF47.3050406@gmx.de> <5FD8AADA-F91A-4B1F-9453-01178901DB6F@osafoundation.org> <443FF7B9.3050801@gmx.de> <7D5DE367-5FD8-4398-849D-2158EF6BC256@osafoundation.org> <443FFE81.6010605@gmx.de> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-1.5 tagged_above=-50.0 required=4.0 tests=AWL, BAYES_00 X-Spam-Level: Cc: CalDAV DevList X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions on Calendar Access protocol based on WebDAV List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Apr 2006 08:19:41 -0000 Lisa Dusseault wrote: > > On Apr 14, 2006, at 12:56 PM, Julian Reschke wrote: > >> Lisa Dusseault wrote: >>> On Apr 14, 2006, at 12:27 PM, Julian Reschke wrote: >>>> Lisa Dusseault wrote: >>>>> Unfortunately, that just does not solve the problem for CalDAV, >>>>> which is likely to have interoperability problems if we don't make >>>>> firm >>>> >>>> ...such as...? >>> The near certainty, from talking to implementors, that some CalDAV >>> servers will add their own iCalendar properties to the body of the >>> iCalendar resources that clients create, and the undesirability of >>> clients always having to do GET after a PUT just to see whether this >>> in fact happened. If we don't explain how to see whether this didn't >> >> Why would they need to do that? > > Usually it's a bunch of concerns for backward compatibility with > existing systems -- e.g. compatibility with a limited set of timezone > definitions. Timezones complicate this problem, as with so many other > problems. Misunderstanding. What I meant was: why would the client need to know whether the server rewrote the entry? This would only be relevant if clients use an ETag returned upon PUT for a conditional GET with byte range header afterwards. >>> happen, some clients might always do a GET (poor performance) and >>> others might always not (poor interoperability). >> >> Just tell clients to do conditional GETs with the cache validator they >> got upon PUT. The client may not have the same content octet-for-octet >> as the server, but besides that I see no problem (yet). > > Yes, but that's exactly it, there's confusion about what the cache > validator they got upon PUT means, or in what cases the server is > allowed to return it. Many clients cache calendar items for offline > use, and if the server has added its own custom properties or modified > data, that may well need to be available offline as well. Currently, there's no way to find out. If this is a requirement, CalDAV will either have to rely on draft-whitehead-http-etag solving that problem, or come up with its own solution. I'd prefer the former approach, because solving this once and for all HTTP based specs certainly is better. If CalDAV wants to do its own thing, it must make sure that it doesn't contradict other specs, on which it builds or that servers may want to implement in parallel with CalDAV. A safe way to do that for now would be to add a new response header that contains just that piece of information, such as: X-Content-Rewritten: "T" / "F" Best regards, Julian Return-Path: X-Original-To: ietf-caldav@osafoundation.org Delivered-To: ietf-caldav@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id E2FCF7F92B for ; Fri, 14 Apr 2006 16:32:27 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id D0A2114227B for ; Fri, 14 Apr 2006 16:32:27 -0700 (PDT) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 01311-03; Fri, 14 Apr 2006 16:32:27 -0700 (PDT) Received: from [192.168.1.100] (c-67-161-46-163.hsd1.ca.comcast.net [67.161.46.163]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 44423142277; Fri, 14 Apr 2006 16:32:27 -0700 (PDT) In-Reply-To: <443FFE81.6010605@gmx.de> References: <443FAB85.8030503@gmx.de> <7246CAD3-9329-4B34-8D23-08B196E80EDE@osafoundation.org> <443FEF47.3050406@gmx.de> <5FD8AADA-F91A-4B1F-9453-01178901DB6F@osafoundation.org> <443FF7B9.3050801@gmx.de> <7D5DE367-5FD8-4398-849D-2158EF6BC256@osafoundation.org> <443FFE81.6010605@gmx.de> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Lisa Dusseault Subject: Re: [Ietf-caldav] I-D ACTION:draft-dusseault-caldav-11.txt (fwd) Date: Fri, 14 Apr 2006 16:32:16 -0700 To: Julian Reschke X-Mailer: Apple Mail (2.746.2) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-0.6 tagged_above=-50.0 required=4.0 tests=AWL, BAYES_00, RCVD_IN_NJABL_DUL, RCVD_IN_SORBS_DUL X-Spam-Level: Cc: CalDAV DevList X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions on Calendar Access protocol based on WebDAV List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Apr 2006 23:32:28 -0000 On Apr 14, 2006, at 12:56 PM, Julian Reschke wrote: > Lisa Dusseault wrote: >> On Apr 14, 2006, at 12:27 PM, Julian Reschke wrote: >>> Lisa Dusseault wrote: >>>> Unfortunately, that just does not solve the problem for CalDAV, >>>> which is likely to have interoperability problems if we don't >>>> make firm >>> >>> ...such as...? >> The near certainty, from talking to implementors, that some CalDAV >> servers will add their own iCalendar properties to the body of the >> iCalendar resources that clients create, and the undesirability of >> clients always having to do GET after a PUT just to see whether >> this in fact happened. If we don't explain how to see whether >> this didn't > > Why would they need to do that? Usually it's a bunch of concerns for backward compatibility with existing systems -- e.g. compatibility with a limited set of timezone definitions. Timezones complicate this problem, as with so many other problems. > >> happen, some clients might always do a GET (poor performance) and >> others might always not (poor interoperability). > > Just tell clients to do conditional GETs with the cache validator > they got upon PUT. The client may not have the same content octet- > for-octet as the server, but besides that I see no problem (yet). Yes, but that's exactly it, there's confusion about what the cache validator they got upon PUT means, or in what cases the server is allowed to return it. Many clients cache calendar items for offline use, and if the server has added its own custom properties or modified data, that may well need to be available offline as well. lisa Return-Path: X-Original-To: ietf-caldav@osafoundation.org Delivered-To: ietf-caldav@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id B34177F8E1 for ; Fri, 14 Apr 2006 12:59:03 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id A3FA5142278 for ; Fri, 14 Apr 2006 12:59:03 -0700 (PDT) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 32301-09 for ; Fri, 14 Apr 2006 12:59:00 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by laweleka.osafoundation.org (Postfix) with SMTP id BEFAF142279 for ; Fri, 14 Apr 2006 12:58:59 -0700 (PDT) Received: (qmail invoked by alias); 14 Apr 2006 19:58:58 -0000 Received: from p508FC13F.dip0.t-ipconnect.de (EHLO [192.168.178.21]) [80.143.193.63] by mail.gmx.net (mp002) with SMTP; 14 Apr 2006 21:58:58 +0200 X-Authenticated: #1915285 Message-ID: <443FFE81.6010605@gmx.de> Date: Fri, 14 Apr 2006 21:56:49 +0200 From: Julian Reschke User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Lisa Dusseault Subject: Re: [Ietf-caldav] I-D ACTION:draft-dusseault-caldav-11.txt (fwd) References: <443FAB85.8030503@gmx.de> <7246CAD3-9329-4B34-8D23-08B196E80EDE@osafoundation.org> <443FEF47.3050406@gmx.de> <5FD8AADA-F91A-4B1F-9453-01178901DB6F@osafoundation.org> <443FF7B9.3050801@gmx.de> <7D5DE367-5FD8-4398-849D-2158EF6BC256@osafoundation.org> In-Reply-To: <7D5DE367-5FD8-4398-849D-2158EF6BC256@osafoundation.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-1.5 tagged_above=-50.0 required=4.0 tests=AWL, BAYES_00 X-Spam-Level: Cc: CalDAV DevList X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions on Calendar Access protocol based on WebDAV List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Apr 2006 19:59:03 -0000 Lisa Dusseault wrote: > > On Apr 14, 2006, at 12:27 PM, Julian Reschke wrote: > >> Lisa Dusseault wrote: >>> Unfortunately, that just does not solve the problem for CalDAV, which >>> is likely to have interoperability problems if we don't make firm >> >> ...such as...? > > The near certainty, from talking to implementors, that some CalDAV > servers will add their own iCalendar properties to the body of the > iCalendar resources that clients create, and the undesirability of > clients always having to do GET after a PUT just to see whether this in > fact happened. If we don't explain how to see whether this didn't Why would they need to do that? > happen, some clients might always do a GET (poor performance) and others > might always not (poor interoperability). Just tell clients to do conditional GETs with the cache validator they got upon PUT. The client may not have the same content octet-for-octet as the server, but besides that I see no problem (yet). > ... Best regards, Julian Return-Path: X-Original-To: ietf-caldav@osafoundation.org Delivered-To: ietf-caldav@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 3AF9A7F8DD for ; Fri, 14 Apr 2006 12:38:09 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 2C15514227F for ; Fri, 14 Apr 2006 12:38:09 -0700 (PDT) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 09342-10; Fri, 14 Apr 2006 12:38:06 -0700 (PDT) Received: from [192.168.1.100] (c-67-161-46-163.hsd1.ca.comcast.net [67.161.46.163]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id A741B142279; Fri, 14 Apr 2006 12:38:06 -0700 (PDT) In-Reply-To: <443FF7B9.3050801@gmx.de> References: <443FAB85.8030503@gmx.de> <7246CAD3-9329-4B34-8D23-08B196E80EDE@osafoundation.org> <443FEF47.3050406@gmx.de> <5FD8AADA-F91A-4B1F-9453-01178901DB6F@osafoundation.org> <443FF7B9.3050801@gmx.de> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <7D5DE367-5FD8-4398-849D-2158EF6BC256@osafoundation.org> Content-Transfer-Encoding: 7bit From: Lisa Dusseault Subject: Re: [Ietf-caldav] I-D ACTION:draft-dusseault-caldav-11.txt (fwd) Date: Fri, 14 Apr 2006 12:37:57 -0700 To: Julian Reschke X-Mailer: Apple Mail (2.746.2) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-0.6 tagged_above=-50.0 required=4.0 tests=AWL, BAYES_00, RCVD_IN_NJABL_DUL, RCVD_IN_SORBS_DUL X-Spam-Level: Cc: CalDAV DevList X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions on Calendar Access protocol based on WebDAV List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Apr 2006 19:38:09 -0000 On Apr 14, 2006, at 12:27 PM, Julian Reschke wrote: > Lisa Dusseault wrote: >> Unfortunately, that just does not solve the problem for CalDAV, >> which is likely to have interoperability problems if we don't make >> firm > > ...such as...? The near certainty, from talking to implementors, that some CalDAV servers will add their own iCalendar properties to the body of the iCalendar resources that clients create, and the undesirability of clients always having to do GET after a PUT just to see whether this in fact happened. If we don't explain how to see whether this didn't happen, some clients might always do a GET (poor performance) and others might always not (poor interoperability). > >> requirements about modifying resources on PUT. Relying on >> RFC2518bis, which has been through WG last call, is one thing; >> relying on the etag draft is another. > > OK, minimally it must not make incorrect statements about what > RFC2616 says. If CalDAV really has additional requirements > (which?), then CalDAV of course could impose them. Thx. Lisa Return-Path: X-Original-To: ietf-caldav@osafoundation.org Delivered-To: ietf-caldav@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 02E597F8BC for ; Fri, 14 Apr 2006 12:30:05 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id E7EF0142279 for ; Fri, 14 Apr 2006 12:30:04 -0700 (PDT) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 29181-02 for ; Fri, 14 Apr 2006 12:30:03 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by laweleka.osafoundation.org (Postfix) with SMTP id BFEF4142258 for ; Fri, 14 Apr 2006 12:30:02 -0700 (PDT) Received: (qmail invoked by alias); 14 Apr 2006 19:30:01 -0000 Received: from p508FC13F.dip0.t-ipconnect.de (EHLO [192.168.178.21]) [80.143.193.63] by mail.gmx.net (mp030) with SMTP; 14 Apr 2006 21:30:01 +0200 X-Authenticated: #1915285 Message-ID: <443FF7B9.3050801@gmx.de> Date: Fri, 14 Apr 2006 21:27:53 +0200 From: Julian Reschke User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Lisa Dusseault Subject: Re: [Ietf-caldav] I-D ACTION:draft-dusseault-caldav-11.txt (fwd) References: <443FAB85.8030503@gmx.de> <7246CAD3-9329-4B34-8D23-08B196E80EDE@osafoundation.org> <443FEF47.3050406@gmx.de> <5FD8AADA-F91A-4B1F-9453-01178901DB6F@osafoundation.org> In-Reply-To: <5FD8AADA-F91A-4B1F-9453-01178901DB6F@osafoundation.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-1.5 tagged_above=-50.0 required=4.0 tests=AWL, BAYES_00 X-Spam-Level: Cc: CalDAV DevList X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions on Calendar Access protocol based on WebDAV List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Apr 2006 19:30:05 -0000 Lisa Dusseault wrote: > Unfortunately, that just does not solve the problem for CalDAV, which is > likely to have interoperability problems if we don't make firm ...such as...? > requirements about modifying resources on PUT. Relying on RFC2518bis, > which has been through WG last call, is one thing; relying on the etag > draft is another. OK, minimally it must not make incorrect statements about what RFC2616 says. If CalDAV really has additional requirements (which?), then CalDAV of course could impose them. Best regards, Julian Return-Path: X-Original-To: ietf-caldav@osafoundation.org Delivered-To: ietf-caldav@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 3E07B7F8D4 for ; Fri, 14 Apr 2006 12:20:10 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 2EDEC14227B for ; Fri, 14 Apr 2006 12:20:10 -0700 (PDT) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 18117-06; Fri, 14 Apr 2006 12:20:09 -0700 (PDT) Received: from [192.168.1.100] (c-67-161-46-163.hsd1.ca.comcast.net [67.161.46.163]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 7DB2E142258; Fri, 14 Apr 2006 12:20:09 -0700 (PDT) In-Reply-To: <443FEF47.3050406@gmx.de> References: <443FAB85.8030503@gmx.de> <7246CAD3-9329-4B34-8D23-08B196E80EDE@osafoundation.org> <443FEF47.3050406@gmx.de> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <5FD8AADA-F91A-4B1F-9453-01178901DB6F@osafoundation.org> Content-Transfer-Encoding: 7bit From: Lisa Dusseault Subject: Re: [Ietf-caldav] I-D ACTION:draft-dusseault-caldav-11.txt (fwd) Date: Fri, 14 Apr 2006 12:20:05 -0700 To: Julian Reschke X-Mailer: Apple Mail (2.746.2) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-0.6 tagged_above=-50.0 required=4.0 tests=AWL, BAYES_00, RCVD_IN_NJABL_DUL, RCVD_IN_SORBS_DUL X-Spam-Level: Cc: CalDAV DevList X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions on Calendar Access protocol based on WebDAV List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Apr 2006 19:20:10 -0000 On Apr 14, 2006, at 11:51 AM, Julian Reschke wrote: > Lisa Dusseault wrote: >> Should we simply remove the claim about what RFC2616 says and >> continue to make these requirements? (If not, do you have a >> proposal for solving the problem?) > > I think neither CalDAV nor RFC2518bis should make any statements > about this issue, but draft-whitehead-http-etag. This who care > about this issue should join the discussion on the HTTP mailing list. > Unfortunately, that just does not solve the problem for CalDAV, which is likely to have interoperability problems if we don't make firm requirements about modifying resources on PUT. Relying on RFC2518bis, which has been through WG last call, is one thing; relying on the etag draft is another. Lisa Return-Path: X-Original-To: ietf-caldav@osafoundation.org Delivered-To: ietf-caldav@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 916C87F8BC for ; Fri, 14 Apr 2006 11:54:02 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 8291B142279 for ; Fri, 14 Apr 2006 11:54:02 -0700 (PDT) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 25256-09 for ; Fri, 14 Apr 2006 11:54:02 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by laweleka.osafoundation.org (Postfix) with SMTP id D68F1142258 for ; Fri, 14 Apr 2006 11:54:01 -0700 (PDT) Received: (qmail invoked by alias); 14 Apr 2006 18:53:58 -0000 Received: from p508FC13F.dip0.t-ipconnect.de (EHLO [192.168.178.21]) [80.143.193.63] by mail.gmx.net (mp005) with SMTP; 14 Apr 2006 20:53:58 +0200 X-Authenticated: #1915285 Message-ID: <443FEF47.3050406@gmx.de> Date: Fri, 14 Apr 2006 20:51:51 +0200 From: Julian Reschke User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Lisa Dusseault Subject: Re: [Ietf-caldav] I-D ACTION:draft-dusseault-caldav-11.txt (fwd) References: <443FAB85.8030503@gmx.de> <7246CAD3-9329-4B34-8D23-08B196E80EDE@osafoundation.org> In-Reply-To: <7246CAD3-9329-4B34-8D23-08B196E80EDE@osafoundation.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-1.5 tagged_above=-50.0 required=4.0 tests=AWL, BAYES_00 X-Spam-Level: Cc: CalDAV DevList X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions on Calendar Access protocol based on WebDAV List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Apr 2006 18:54:02 -0000 Lisa Dusseault wrote: > Should we simply remove the claim about what RFC2616 says and continue > to make these requirements? (If not, do you have a proposal for solving > the problem?) I think neither CalDAV nor RFC2518bis should make any statements about this issue, but draft-whitehead-http-etag. This who care about this issue should join the discussion on the HTTP mailing list. Best regards, Julian Return-Path: X-Original-To: ietf-caldav@osafoundation.org Delivered-To: ietf-caldav@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 06FA67F8C7 for ; Fri, 14 Apr 2006 11:34:39 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id EA373142279 for ; Fri, 14 Apr 2006 11:34:38 -0700 (PDT) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 08961-08; Fri, 14 Apr 2006 11:34:36 -0700 (PDT) Received: from [192.168.1.100] (c-67-161-46-163.hsd1.ca.comcast.net [67.161.46.163]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 5CC55142260; Fri, 14 Apr 2006 11:34:36 -0700 (PDT) In-Reply-To: <443FAB85.8030503@gmx.de> References: <443FAB85.8030503@gmx.de> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <7246CAD3-9329-4B34-8D23-08B196E80EDE@osafoundation.org> Content-Transfer-Encoding: 7bit From: Lisa Dusseault Subject: Re: [Ietf-caldav] I-D ACTION:draft-dusseault-caldav-11.txt (fwd) Date: Fri, 14 Apr 2006 11:34:28 -0700 To: Julian Reschke X-Mailer: Apple Mail (2.746.2) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-0.6 tagged_above=-50.0 required=4.0 tests=AWL, BAYES_00, RCVD_IN_NJABL_DUL, RCVD_IN_SORBS_DUL X-Spam-Level: Cc: CalDAV DevList X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions on Calendar Access protocol based on WebDAV List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Apr 2006 18:34:39 -0000 On Apr 14, 2006, at 7:02 AM, Julian Reschke wrote: > >> As required by [RFC2616], a response to a PUT request with a >> strong entity tag MUST mean that the server will return on a >> subsequent GET request a calendar object resource that is >> equivalent by octet equality. > > No, that's not in RFC2616. > >> A response to a PUT request MUST NOT contain an ETag response >> header field if the server will return on a subsequent GET request >> a calendar object resource that is not equivalent by octet >> equality to the submitted calendar object resource. In this case, >> the client SHOULD retrieve the new entity (and ETag) as a basis >> for further changes, rather than use the entity it had sent with >> the PUT request. > > Again, not in RFC2616. Should we simply remove the claim about what RFC2616 says and continue to make these requirements? (If not, do you have a proposal for solving the problem?) Lisa Return-Path: X-Original-To: ietf-caldav@osafoundation.org Delivered-To: ietf-caldav@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 1DCA77F887 for ; Fri, 14 Apr 2006 07:04:49 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 0FCDF142276 for ; Fri, 14 Apr 2006 07:04:49 -0700 (PDT) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 20425-05 for ; Fri, 14 Apr 2006 07:04:45 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by laweleka.osafoundation.org (Postfix) with SMTP id 44B1D142253 for ; Fri, 14 Apr 2006 07:04:45 -0700 (PDT) Received: (qmail invoked by alias); 14 Apr 2006 14:04:43 -0000 Received: from p508FC13F.dip0.t-ipconnect.de (EHLO [192.168.178.21]) [80.143.193.63] by mail.gmx.net (mp017) with SMTP; 14 Apr 2006 16:04:43 +0200 X-Authenticated: #1915285 Message-ID: <443FAB85.8030503@gmx.de> Date: Fri, 14 Apr 2006 16:02:45 +0200 From: Julian Reschke User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Cyrus Daboo Subject: Re: [Ietf-caldav] I-D ACTION:draft-dusseault-caldav-11.txt (fwd) References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-1.5 tagged_above=-50.0 required=4.0 tests=AWL, BAYES_00 X-Spam-Level: Cc: CalDAV DevList X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions on Calendar Access protocol based on WebDAV List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Apr 2006 14:04:49 -0000 Cyrus Daboo wrote: > Hi folks, > A new version of the draft is now available. This addresses almost all > of the comments we've received to date (just some from Jeff's last > message still to address). At this point it is our intention to submit > this to the IESG as soon as possible. > > Note that there have been some important changes since -10 - please > check the Changes section for full details. > ... I appreciate the change moving to RFC2518bis, and requiring level 3 compliance. Hopefully now all CalDAV implementors are busy looking at the Changes section for RFC2518bis as well :-) (see ). One thing I still think is broken in CalDAV are the ETag requirements in Section 5.3.4 (). In particular: > As required by [RFC2616], a response to a PUT request with a strong entity tag MUST mean that the server will return on a subsequent GET request a calendar object resource that is equivalent by octet equality. No, that's not in RFC2616. > A response to a PUT request MUST NOT contain an ETag response header field if the server will return on a subsequent GET request a calendar object resource that is not equivalent by octet equality to the submitted calendar object resource. In this case, the client SHOULD retrieve the new entity (and ETag) as a basis for further changes, rather than use the entity it had sent with the PUT request. Again, not in RFC2616. Best regards, Julian Return-Path: X-Original-To: ietf-caldav@osafoundation.org Delivered-To: ietf-caldav@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 30AE17F78A for ; Wed, 12 Apr 2006 13:42:38 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 2070E142276 for ; Wed, 12 Apr 2006 13:42:38 -0700 (PDT) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 04514-09 for ; Wed, 12 Apr 2006 13:42:36 -0700 (PDT) Received: from fed1rmmtao04.cox.net (fed1rmmtao04.cox.net [68.230.241.35]) by laweleka.osafoundation.org (Postfix) with ESMTP id 64E61142274 for ; Wed, 12 Apr 2006 13:42:36 -0700 (PDT) Received: from [192.168.0.102] (really [70.191.49.25]) by fed1rmmtao04.cox.net (InterMail vM.6.01.06.01 201-2131-130-101-20060113) with ESMTP id <20060412204235.NWTH16517.fed1rmmtao04.cox.net@[192.168.0.102]>; Wed, 12 Apr 2006 16:42:35 -0400 Message-ID: <443D663A.2050505@calconnect.org> Date: Wed, 12 Apr 2006 13:42:34 -0700 From: Dave Thewlis Organization: The Calendaring and Scheduling Consortium User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: ietf-caldav list Content-Type: multipart/alternative; boundary="------------060307020200050108060703" X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-1.3 tagged_above=-50.0 required=4.0 tests=AWL, BAYES_00, HTML_20_30, HTML_MESSAGE X-Spam-Level: Subject: [Ietf-caldav] CalConnect Roundtable VI -- May 22-25, Cambridge, Massachusetts - The Calendaring and Scheduling Consortium X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Dave.Thewlis@calconnect.org List-Id: Discussions on Calendar Access protocol based on WebDAV List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Apr 2006 20:42:38 -0000 This is a multi-part message in MIME format. --------------060307020200050108060703 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit *Come to Cambridge for CalConnect's Sixth Roundtable!* This is a reminder that The Calendaring and Scheduling Consortium's Roundtable VI and associated interoperability testing event will be hosted by IBM/Lotus in Cambridge, Massachusetts, on May 22-25. Registration is now open for both the Roundtable and the IOP testing event (see below). The *interoperability testing event* will be all day Monday, May 22, and Tuesday morning the 23rd. This event will offer IOP testing against the RFCs and extensive CalDAV testing, and will also focus on testing Free/Busy support. The Consortium will offer a *Practicum on Tuesday morning* from 9:30-12:00 to all Roundtable registrants (member representatives and observers), comprising two one-hour overview/levelset sessions on iCalendar Specifications and on CalDAV (the new calendaring access protocol). The goal of these sessions is to provide a basic level of familiarity and understanding of iCalendar and CalDAV to any attendees who are not involved with the specifications and may wish to know more. Tuesday afternoon is planned to be an in-depth *workshop on Mobile Calendaring*, with the goal of better identifying actual vendor and customer requirements for mobile interoperable calendaring and scheduling and helping to identify use cases, requirements, and a consensus vision statement for mobile calendaring in the future. The workshop will be open to all attendees. Wednesday, and Thursday morning, will be dedicated to *Technical Committee sessions* in areas such as CalDAV, Realtime (calendaring server-to-server protocols and requirements), Event Publication, Use Case development, and Authentication, plus a Plenary meeting of the Consortium. All attendees are welcome to participate in any TC sessions which interest them. Registration is now open for the IOP testing event and for the Roundtable (separate registration required). For more information and logistics see http://www.calconnect.org/roundtable6.html and http://www.calconnect.org/iopmay2006.html. To register for the Roundtable or IOP testing, see http://www.calconnect.org/roundtablereg.html (1) and http://www.calconnect.org/iopreg.html (2). (1) Please note that if you register by _May 5_ you will get a discount on your registration fee for the Roundtable. (2) If you are a Consortium Member doing interoperability testing, you are also eligible for a 10% discount by agreeing to attend three consecutive IOP testing events (the discount applies for all three events). Please contact me if you have any questions. See you in May! Dave Thewlis -- *Dave Thewlis, Executive Director Calconnect - The Calendaring and Scheduling Consortium* +1 707 840 9391 (voice) · +1 707 498 2238 (mobile) http://www.calconnect.org · Dave.Thewlis@calconnect.org --------------060307020200050108060703 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Come to Cambridge for CalConnect's Sixth Roundtable!

This is a reminder that The Calendaring and Scheduling Consortium's Roundtable VI and associated interoperability testing event will be hosted by IBM/Lotus in Cambridge, Massachusetts, on May 22-25.  Registration is now open for both the Roundtable and the IOP testing event (see below). 

The interoperability testing event will be all day Monday, May 22, and Tuesday morning the 23rd.  This event will offer IOP testing against the RFCs and extensive CalDAV testing, and will also focus on testing Free/Busy support.

The Consortium will offer a Practicum on Tuesday morning from 9:30-12:00 to all Roundtable registrants (member representatives and observers), comprising two one-hour overview/levelset sessions on iCalendar Specifications and on CalDAV (the new calendaring access protocol).  The goal of these sessions is to provide a basic level of familiarity and understanding of iCalendar and CalDAV to any attendees who are not involved with the specifications and may wish to know more.

Tuesday afternoon is planned to be an in-depth workshop on Mobile Calendaring, with the goal of better identifying actual vendor and customer requirements for mobile interoperable calendaring and scheduling and helping to identify use cases, requirements, and a consensus vision statement for mobile calendaring in the future.  The workshop will be open to all attendees.

Wednesday, and Thursday morning, will be dedicated to Technical Committee sessions in areas such as CalDAV, Realtime (calendaring server-to-server protocols and requirements), Event Publication,  Use Case development, and  Authentication, plus a Plenary meeting of the Consortium.  All attendees are welcome to participate in any TC sessions which interest them. 

Registration is now open for the IOP testing event and for the Roundtable (separate registration required).  For more information and logistics see http://www.calconnect.org/roundtable6.html and http://www.calconnect.org/iopmay2006.html. 

To register for the Roundtable or IOP testing, see http://www.calconnect.org/roundtablereg.html (1) and
http://www.calconnect.org/iopreg.html (2).


(1) Please note that if you register by May 5 you will get a discount on your registration fee for the Roundtable.

(2) If you are a Consortium Member doing interoperability testing, you are also eligible for a 10% discount by agreeing to attend three consecutive IOP testing events (the discount applies for all three events).

Please contact me if you have any questions. 

See you in May!

Dave Thewlis
--
Dave Thewlis, Executive Director
Calconnect - The Calendaring and Scheduling Consortium
+1 707 840 9391 (voice) · +1 707 498 2238 (mobile)
http://www.calconnect.org · Dave.Thewlis@calconnect.org
--------------060307020200050108060703-- Return-Path: X-Original-To: ietf-caldav@osafoundation.org Delivered-To: ietf-caldav@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id E099F7F73D; Tue, 11 Apr 2006 17:40:42 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id D1C30142269; Tue, 11 Apr 2006 17:40:42 -0700 (PDT) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 04819-01; Tue, 11 Apr 2006 17:40:42 -0700 (PDT) Received: from outbound0.sv.meer.net (outbound0.sv.meer.net [205.217.152.13]) by laweleka.osafoundation.org (Postfix) with ESMTP id 027F5142256; Tue, 11 Apr 2006 17:40:42 -0700 (PDT) Received: from mail.meer.net (mail.meer.net [209.157.152.14]) by outbound0.sv.meer.net (8.12.10/8.12.6) with ESMTP id k3C0eYpn085651; Tue, 11 Apr 2006 17:40:40 -0700 (PDT) (envelope-from dmose@mozilla.org) Received: from [192.168.1.105] (dsl081-050-187.sfo1.dsl.speakeasy.net [64.81.50.187]) by mail.meer.net (8.13.3/8.13.3/meer) with ESMTP id k3C0e55I032583; Tue, 11 Apr 2006 17:40:06 -0700 (PDT) (envelope-from dmose@mozilla.org) Message-ID: <443C4C2B.9080509@mozilla.org> Date: Tue, 11 Apr 2006 17:39:07 -0700 From: Dan Mosedale User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Cyrus Daboo Subject: Re: [Ietf-caldav] non-calendar resources in calendar collections References: <29a761a00603152047w36c19342kab76282d26f8a3b8@mail.gmail.com> <787A077135802436A7265C5A@ninevah.local> <5091BE1225EFCA23C188876A@Cyrus-Daboo.local> In-Reply-To: <5091BE1225EFCA23C188876A@Cyrus-Daboo.local> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-1.9 tagged_above=-50.0 required=4.0 tests=AWL, BAYES_00 X-Spam-Level: Cc: CalDAV DevList X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions on Calendar Access protocol based on WebDAV List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Apr 2006 00:40:43 -0000 Chiming in a bit late here, but I would tend to lean slightly in favor of the existing, slightly more restrictive semantics. My thinking is merely that simplicity really does help real-world adoption/implementation, and various folks have pointed out ways that loosening this restriction is likely at add complexity which would then require additional specification to ensure that all implementors do the sam thing, which adds even more complexity. Dan Return-Path: X-Original-To: ietf-caldav@osafoundation.org Delivered-To: ietf-caldav@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 9238C7F64A for ; Mon, 10 Apr 2006 12:59:24 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 8414414225E for ; Mon, 10 Apr 2006 12:59:24 -0700 (PDT) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 22580-10 for ; Mon, 10 Apr 2006 12:59:23 -0700 (PDT) Received: from out3.smtp.messagingengine.com (out3.smtp.messagingengine.com [66.111.4.27]) by laweleka.osafoundation.org (Postfix) with ESMTP id 85A6D14225B for ; Mon, 10 Apr 2006 12:59:23 -0700 (PDT) Received: from frontend2.internal (frontend2.internal [10.202.2.151]) by frontend1.messagingengine.com (Postfix) with ESMTP id 16F65D47599 for ; Mon, 10 Apr 2006 15:59:22 -0400 (EDT) Received: from frontend3.messagingengine.com ([10.202.2.152]) by frontend2.internal (MEProxy); Mon, 10 Apr 2006 15:59:04 -0400 X-Sasl-enc: UOIXOQ5h35dJbt4yfryb4gZutizYt9ao/P3gmpOLwqlV 1144699143 Received: from [17.101.35.110] (unknown [17.101.35.110]) by www.fastmail.fm (Postfix) with ESMTP id 95E583C43 for ; Mon, 10 Apr 2006 15:59:03 -0400 (EDT) Date: Mon, 10 Apr 2006 16:00:04 -0400 From: Cyrus Daboo To: CalDAV DevList Message-ID: X-Mailer: Mulberry/4.0.4 (Mac OS X) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="==========6D310EE7F3F4E1E807AC==========" X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-1.9 tagged_above=-50.0 required=4.0 tests=AWL, BAYES_00 X-Spam-Level: Subject: [Ietf-caldav] I-D ACTION:draft-dusseault-caldav-11.txt (fwd) X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions on Calendar Access protocol based on WebDAV List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Apr 2006 19:59:24 -0000 --==========6D310EE7F3F4E1E807AC========== Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi folks, A new version of the draft is now available. This addresses almost all of the comments we've received to date (just some from Jeff's last message still to address). At this point it is our intention to submit this to the IESG as soon as possible. Note that there have been some important changes since -10 - please check the Changes section for full details. ------------ Forwarded Message ----------- Date: April 10, 2006 3:50:01 PM -0400 From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Subject: I-D ACTION:draft-dusseault-caldav-11.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Calendaring Extensions to WebDAV (CalDAV) Author(s) : L. Dusseault, et al. Filename : draft-dusseault-caldav-11.txt Pages : 109 Date : 2006-4-10 ---------- End Forwarded Message ---------- -- Cyrus Daboo --==========6D310EE7F3F4E1E807AC========== Content-Type: message/rfc822; name="I-D ACTION:draft-dusseault-caldav-11.txt " Received: from murder (MX3.andrew.cmu.edu [128.2.10.113]) by mail1.andrew.cmu.edu (Cyrus v2.2.12-110) with LMTPA; Mon, 10 Apr 2006 15:53:24 -0400 X-Sieve: CMU Sieve 2.2 Received: from mx3.andrew.cmu.edu ([unix socket]) by mx3.andrew.cmu.edu (Cyrus v2.2.12-110) with LMTPA; Mon, 10 Apr 2006 15:53:25 -0400 Received: from megatron.ietf.org (odin.ietf.org [156.154.16.145]) by mx3.andrew.cmu.edu (8.13.5/8.13.6) with ESMTP id k3AJoEkj025190; Mon, 10 Apr 2006 15:53:24 -0400 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FT2Om-0006IF-L8; Mon, 10 Apr 2006 15:50:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FT2Og-0006Go-Li for i-d-announce@ietf.org; Mon, 10 Apr 2006 15:50:02 -0400 Received: from oak.neustar.com ([209.173.53.70]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FT2Og-0008RX-0y for i-d-announce@ietf.org; Mon, 10 Apr 2006 15:50:02 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by oak.neustar.com (8.12.8/8.12.8) with ESMTP id k3AJo1BX021082 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 10 Apr 2006 19:50:01 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1FT2Of-0007mD-P3 for i-d-announce@ietf.org; Mon, 10 Apr 2006 15:50:01 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org Cc: From: Internet-Drafts@ietf.org Message-Id: Date: Mon, 10 Apr 2006 15:50:01 -0400 X-Spam-Score: 0.3 (/) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Subject: I-D ACTION:draft-dusseault-caldav-11.txt X-BeenThere: i-d-announce@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: internet-drafts@ietf.org List-Id: i-d-announce.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: i-d-announce-bounces@ietf.org X-Spam-Clean: 7% (NO_REAL_NAME 0, __CP_URI_IN_BODY 0, __CT 0, __CTYPE_HAS_BOUNDARY 0, __CTYPE_MULTIPART 0, __HAS_MSGID 0, __MIME_VERSION 0, __SANE_MSGID 0, __STOCK_CRUFT 0) X-Spam-Value: 7% X-Greylist: Message is not spam, not delayed by milter-greylist-2.0.2 (mx3.andrew.cmu.edu [128.2.10.113]); Mon, 10 Apr 2006 15:53:25 -0400 (EDT) --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Calendaring Extensions to WebDAV (CalDAV) Author(s) : L. Dusseault, et al. Filename : draft-dusseault-caldav-11.txt Pages : 109 Date : 2006-4-10 This document specifies a set of methods, headers, message bodies, properties, and reports that define calendar access extensions to the WebDAV protocol. The new protocol elements are intended to make WebDAV-based calendaring and scheduling an interoperable standard that supports calendar access, calendar management, calendar sharing, and calendar publishing. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-dusseault-caldav-11.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-dusseault-caldav-11.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-dusseault-caldav-11.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-4-10143347.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-dusseault-caldav-11.txt --OtherAccess Content-Type: Message/External-body; name="draft-dusseault-caldav-11.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-4-10143347.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/i-d-announce --NextPart-- --==========6D310EE7F3F4E1E807AC==========-- Return-Path: X-Original-To: ietf-caldav@osafoundation.org Delivered-To: ietf-caldav@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id BFD817F76D for ; Fri, 7 Apr 2006 14:09:35 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id AB109142284 for ; Fri, 7 Apr 2006 14:09:35 -0700 (PDT) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 08850-06 for ; Fri, 7 Apr 2006 14:09:33 -0700 (PDT) Received: from mail.mdlink.net (medusa.mdlink.de [213.211.192.34]) by laweleka.osafoundation.org (Postfix) with ESMTP id 0424B142283 for ; Fri, 7 Apr 2006 14:09:33 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.mdlink.net (Postfix) with ESMTP id CD1293DBE1B for ; Fri, 7 Apr 2006 23:04:48 +0200 (CEST) Received: from [192.168.1.126] (port-ip-213-211-243-146.reverse.mdcc-fun.de [213.211.243.146]) by mail.mdlink.net (Postfix) with ESMTP id 747513DBE17 for ; Fri, 7 Apr 2006 23:04:48 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v623) In-Reply-To: <4436CE47.3070504@adevsoft.com> References: <44358840.6050903@adevsoft.com> <1A9659D5-139E-4FB8-8FA3-061BD3156466@osafoundation.org> <4435AEFB.1090807@adevsoft.com> <44367E24.7090703@adevsoft.com> <4436CE47.3070504@adevsoft.com> Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Helge Hess Subject: Re: [Ietf-caldav] Caldav sync approach comments Date: Fri, 7 Apr 2006 23:09:38 +0200 To: CalDAV DevList X-Mailer: Apple Mail (2.623) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-1.6 tagged_above=-50.0 required=4.0 tests=AWL, BAYES_00 X-Spam-Level: X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions on Calendar Access protocol based on WebDAV List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Apr 2006 21:09:35 -0000 On Apr 7, 2006, at 22:40, Kervin L. Pierre wrote: > The resulting calendar would 'consistant' from a > CalDAV data point-of-view, but may not be from the > user's or client's point-of-view. > > In other words there is no way to apply a set of > offline changes to the calendar atomically. I see your point. Though _IMO_ its not a real world issue. The client should just collect failed PUTs and present them to the user (and offer him to revert, add-a-copy, merge or overwrite [see iSync]). If you do so, it will be correct from the users point-of-view :-) Remember that the user needs to make such a decision anyway. Even if you place a lock, you would first need to present the user a view of conflicting items which he needs to resolve. Pessimistic vs optimistic is mostly a matter whether your show that before or after the sync :-) Summary: I don't think a pessimistic atomic lock provides a lot of real-world advantages over the optimistic locks (unless the items really have a tight coupling which is not the case for CalDAV resources). Remember that placing locks is highly inefficient, both from the (server) work required to implement them and from the reduction in scalability (think of why row-level locking was a major new feature in RDBMS ;-). I think keeping them optional is a good choice. regards, Helge -- http://docs.opengroupware.org/Members/helge/ OpenGroupware.org Return-Path: X-Original-To: ietf-caldav@osafoundation.org Delivered-To: ietf-caldav@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id A3C397F624 for ; Fri, 7 Apr 2006 13:40:40 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 95701142284 for ; Fri, 7 Apr 2006 13:40:40 -0700 (PDT) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 01209-06 for ; Fri, 7 Apr 2006 13:40:39 -0700 (PDT) Received: from smtp107.biz.mail.re2.yahoo.com (smtp107.biz.mail.re2.yahoo.com [206.190.52.176]) by laweleka.osafoundation.org (Postfix) with SMTP id BA17C14227E for ; Fri, 7 Apr 2006 13:40:38 -0700 (PDT) Received: (qmail 59981 invoked from network); 7 Apr 2006 20:40:38 -0000 Received: from unknown (HELO ?10.55.10.51?) (kervin@adevsoft.com@24.227.116.130 with plain) by smtp107.biz.mail.re2.yahoo.com with SMTP; 7 Apr 2006 20:40:38 -0000 Message-ID: <4436CE47.3070504@adevsoft.com> Date: Fri, 07 Apr 2006 16:40:39 -0400 From: "Kervin L. Pierre" User-Agent: Mozilla Thunderbird 1.0.5 (Windows/20050711) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Helge Hess , CalDAV DevList Subject: Re: [Ietf-caldav] Caldav sync approach comments References: <44358840.6050903@adevsoft.com> <1A9659D5-139E-4FB8-8FA3-061BD3156466@osafoundation.org> <4435AEFB.1090807@adevsoft.com> <44367E24.7090703@adevsoft.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-1.9 tagged_above=-50.0 required=4.0 tests=AWL, BAYES_00 X-Spam-Level: X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions on Calendar Access protocol based on WebDAV List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Apr 2006 20:40:40 -0000 Hello, I'm sure if it's a big deal to others, but the case were a offline client modifies multiple resources and tries to sync those with an online, multi-user calendar when it finally gets online. The resources themselves are uploaded alright, but the client can not garantee that the calendar is in the same state the client intended at the beginning of the sync because other clients could have modified the resources during that sync. The resulting calendar would 'consistant' from a CalDAV data point-of-view, but may not be from the user's or client's point-of-view. In other words there is no way to apply a set of offline changes to the calendar atomically. Checking the etags would confirm that there is a conflict, but it does not give a method to prevent or resolve the issue. Ie. If two changeset walk over each other, how does one back out? Best regards, Kervin Helge Hess wrote: > On Apr 7, 2006, at 16:58, Kervin L. Pierre wrote: > >> PS. A current related issue is that a client >> with an offline cache can not verify a >> complete sync with a multi-user calendar >> without WebDAV locks. But WebDAV locks >> are optional in CalDAV. > Return-Path: X-Original-To: ietf-caldav@osafoundation.org Delivered-To: ietf-caldav@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 634907F763 for ; Fri, 7 Apr 2006 12:04:22 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 54E9E142279 for ; Fri, 7 Apr 2006 12:04:22 -0700 (PDT) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 10954-10 for ; Fri, 7 Apr 2006 12:04:20 -0700 (PDT) Received: from mail.mdlink.net (medusa.mdlink.de [213.211.192.34]) by laweleka.osafoundation.org (Postfix) with ESMTP id BA791142277 for ; Fri, 7 Apr 2006 12:04:19 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.mdlink.net (Postfix) with ESMTP id 813483DB521 for ; Fri, 7 Apr 2006 20:59:34 +0200 (CEST) Received: from [192.168.1.126] (port-ip-213-211-243-146.reverse.mdcc-fun.de [213.211.243.146]) by mail.mdlink.net (Postfix) with ESMTP id 249A43DA43D for ; Fri, 7 Apr 2006 20:59:34 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v623) In-Reply-To: <44367E24.7090703@adevsoft.com> References: <44358840.6050903@adevsoft.com> <1A9659D5-139E-4FB8-8FA3-061BD3156466@osafoundation.org> <4435AEFB.1090807@adevsoft.com> <44367E24.7090703@adevsoft.com> Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Helge Hess Subject: Re: [Ietf-caldav] Caldav sync approach comments Date: Fri, 7 Apr 2006 21:04:26 +0200 To: CalDAV DevList X-Mailer: Apple Mail (2.623) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-1.5 tagged_above=-50.0 required=4.0 tests=AWL, BAYES_00 X-Spam-Level: X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions on Calendar Access protocol based on WebDAV List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Apr 2006 19:04:22 -0000 On Apr 7, 2006, at 16:58, Kervin L. Pierre wrote: > PS. A current related issue is that a client > with an offline cache can not verify a > complete sync with a multi-user calendar > without WebDAV locks. But WebDAV locks > are optional in CalDAV. Could you elaborate? Thanks, Helge -- http://docs.opengroupware.org/Members/helge/ OpenGroupware.org Return-Path: X-Original-To: ietf-caldav@osafoundation.org Delivered-To: ietf-caldav@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id ACB867F73A for ; Fri, 7 Apr 2006 07:58:45 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 9EE38142277 for ; Fri, 7 Apr 2006 07:58:45 -0700 (PDT) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 16653-06 for ; Fri, 7 Apr 2006 07:58:44 -0700 (PDT) Received: from smtp104.biz.mail.re2.yahoo.com (smtp104.biz.mail.re2.yahoo.com [206.190.52.173]) by laweleka.osafoundation.org (Postfix) with SMTP id BA5B214226F for ; Fri, 7 Apr 2006 07:58:43 -0700 (PDT) Received: (qmail 6804 invoked from network); 7 Apr 2006 14:58:43 -0000 Received: from unknown (HELO ?192.168.0.77?) (kervin@adevsoft.com@12.8.36.193 with plain) by smtp104.biz.mail.re2.yahoo.com with SMTP; 7 Apr 2006 14:58:42 -0000 Message-ID: <44367E24.7090703@adevsoft.com> Date: Fri, 07 Apr 2006 10:58:44 -0400 From: "Kervin L. Pierre" User-Agent: Mozilla Thunderbird 1.0.5 (Windows/20050711) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jay Batson Subject: Re: [Ietf-caldav] Caldav sync approach comments References: <44358840.6050903@adevsoft.com> <1A9659D5-139E-4FB8-8FA3-061BD3156466@osafoundation.org> <4435AEFB.1090807@adevsoft.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-1.9 tagged_above=-50.0 required=4.0 tests=AWL, BAYES_00, RCVD_IN_SORBS_WEB X-Spam-Level: Cc: ietf-caldav@osafoundation.org X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions on Calendar Access protocol based on WebDAV List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Apr 2006 14:58:45 -0000 Hello Jay, Jay Batson wrote: > So don't jump too far too fast by adding SyncML into the mix. I wish I > knew what to suggest we'd prefer to see. It's a tough call. I'm happy > to see this august body discuss it, though. > I do believe sync is an issue that needs to be addressed with some options being... (i) Adding a 'changset' report based on tags or timestamp, as Lisa mentioned. This would enable faster sync that does not require exchanging information about every resource in the calendar collection. Very important to resource light clients that sometimes go offline and have local r/w caches. Eg. many PDA organizers. (ii)Provide compatibility for external sync protocol such as SyncML over HTTP. Not suggesting SyncML being even _mentioned_ in the draft. But care can be taken that a CalDAV server implementor can also expose the collection via SyncML/HTTP without any protocol conflicts. Or any other coexistance issues that might come up. (iii)Leave the entire discussion for the 'caldav-schedule' document. PS. A current related issue is that a client with an offline cache can not verify a complete sync with a multi-user calendar without WebDAV locks. But WebDAV locks are optional in CalDAV. Best regards, Kervin Return-Path: X-Original-To: ietf-caldav@osafoundation.org Delivered-To: ietf-caldav@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 9FAC77F720 for ; Fri, 7 Apr 2006 06:59:39 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 921B7142267 for ; Fri, 7 Apr 2006 06:59:39 -0700 (PDT) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 19627-04 for ; Fri, 7 Apr 2006 06:59:39 -0700 (PDT) Received: from out3.smtp.messagingengine.com (out3.smtp.messagingengine.com [66.111.4.27]) by laweleka.osafoundation.org (Postfix) with ESMTP id DD51B142258 for ; Fri, 7 Apr 2006 06:59:38 -0700 (PDT) Received: from frontend2.internal (frontend2.internal [10.202.2.151]) by frontend1.messagingengine.com (Postfix) with ESMTP id 888C8D472BB; Fri, 7 Apr 2006 09:59:37 -0400 (EDT) Received: from frontend3.messagingengine.com ([10.202.2.152]) by frontend2.internal (MEProxy); Fri, 07 Apr 2006 09:59:24 -0400 X-Sasl-enc: srzD+5Pa5ijE6aZWJlIW+JwAzLxUxPRSUCgluFUOI0Af 1144418364 Received: from [17.101.35.110] (unknown [17.101.35.110]) by www.fastmail.fm (Postfix) with ESMTP id A01D23399; Fri, 7 Apr 2006 09:59:23 -0400 (EDT) Date: Fri, 07 Apr 2006 10:00:03 -0400 From: Cyrus Daboo To: IGnatius T Foobar , ietf-caldav@osafoundation.org Subject: Re: [Ietf-caldav] comments on version 10 of the CalDAV draft Message-ID: <712B94938B4AAECF9A37B1FE@Cyrus-Daboo.local> In-Reply-To: <2122183@uncensored.citadel.org> References: <2122183@uncensored.citadel.org> X-Mailer: Mulberry/4.0.4 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-1.9 tagged_above=-50.0 required=4.0 tests=AWL, BAYES_00 X-Spam-Level: X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions on Calendar Access protocol based on WebDAV List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Apr 2006 13:59:39 -0000 Hi IGnatius, --On April 7, 2006 9:18:38 AM -0400 IGnatius T Foobar wrote: > Consider the following sequence of events: > > 1. Client "A" issues a PUT with a strong ETag No - the client does not generate a strong ETag on PUT the server does. We are talking about the ETag returned by the server in response to a PUT. > 2. Client "B" reads the entity and replaces it with a new one. It will > have a different ETag, and it might even have a different URI altogether. How can the client 'replace' a resource with one URI with one of a different URI in a single PUT - or are you suggesting some other sequence of operations? In any case, an ETag is related to a resource URI, so if there is a different URI its a completely different resource anyway. > 3. Client "A" (unaware that Client "B" did anything) then issues its > "subsequent" GET and does not find its "equivalent by octet > " entity that it is expecting. A well written client in step 3 will use an If-Match header with the ETag it got back in step 1 and will know that someone else changed the resource. Just to clarify: the statement we put in CalDAV was meant to emphasize the nature of STRONG ETags (as opposed to weak) - i.e., if a server returns a strong ETag in a PUT response, then if on a subsequent GET or PROPFIND, the returned ETag or getetag property is the same as that which came back on the PUT, then the actual resource data is EXACTLY the same as that which was PUT. > This is the same problem that was created a few versions ago when the > CalDAV draft suddenly mandated that the server isn't allowed to change > the URI specified by the client after a PUT command. Neither HTTP nor WebDAV define such a behavior. Some people assume the server can return a Location: header but that is only defined for a POST. 2616 does allow for a 301 response to effectively 're-direct' the client to a more appropriate URI. As far as a I can tell the current draft does not rule out such behavior - if you think it does please let me know what portion of the draft that is and we can take another look at it. > HTTP is "heavily multiuser" and one cannot depend on race conditions. Right - and proper use of ETags, If-Match, If-None-Match etc is supposed to help deal with that, and what we were trying to do (maybe not as well as we should have) is emphasis that in CalDAV as we know users are likely to have multiple calendar clients accessing the same server/calendars/resources at the same time. -- Cyrus Daboo Return-Path: X-Original-To: ietf-caldav@osafoundation.org Delivered-To: ietf-caldav@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id DF52F7F672 for ; Fri, 7 Apr 2006 06:30:28 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id CEA6B142262 for ; Fri, 7 Apr 2006 06:30:28 -0700 (PDT) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 14310-04 for ; Fri, 7 Apr 2006 06:30:27 -0700 (PDT) Received: from uncensored.citadel.org (p78-90.acedsl.com [66.114.78.90]) by laweleka.osafoundation.org (Postfix) with SMTP id 0A61014225E for ; Fri, 7 Apr 2006 06:30:26 -0700 (PDT) To: ietf-caldav@osafoundation.org Date: Fri, 07 Apr 2006 09:18:38 -0400 Subject: Re: [Ietf-caldav] comments on version 10 of the CalDAV draft Message-ID: <2122183@uncensored.citadel.org> From: "IGnatius T Foobar" Organization: Uncensored X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-2.6 tagged_above=-50.0 required=4.0 tests=BAYES_00 X-Spam-Level: X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions on Calendar Access protocol based on WebDAV List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Apr 2006 13:30:29 -0000 >Sorry, if this has been discussed already, but I got somewhat confused >about this... > > "As required by [RFC2616], a response to a PUT request with a strong > entity tag MUST mean that the server will return on a subsequent GET > request a calendar object resource that is equivalent by octet > equality. Whether it is specified in RFC2616 or not, it implies a race condition. Consider the following sequence of events: 1. Client "A" issues a PUT with a strong ETag 2. Client "B" reads the entity and replaces it with a new one. It will have a different ETag, and it might even have a different URI altogether. 3. Client "A" (unaware that Client "B" did anything) then issues its "subsequent" GET and does not find its "equivalent by octet " entity that it is expecting. This is the same problem that was created a few versions ago when the CalDAV draft suddenly mandated that the server isn't allowed to change the URI specified by the client after a PUT command. HTTP is "heavily multiuser" and one cannot depend on race conditions. Art Cancro Return-Path: X-Original-To: ietf-caldav@osafoundation.org Delivered-To: ietf-caldav@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id B73B07F6DD for ; Fri, 7 Apr 2006 04:57:25 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id A7E2B142277 for ; Fri, 7 Apr 2006 04:57:25 -0700 (PDT) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 03800-07 for ; Fri, 7 Apr 2006 04:57:24 -0700 (PDT) Received: from plumcanary.com (sync.plumcanary.com [216.154.222.73]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 04734142270 for ; Fri, 7 Apr 2006 04:57:23 -0700 (PDT) Received: from [192.168.0.2] (c-24-128-44-227.hsd1.ma.comcast.net [24.128.44.227]) by plumcanary.com (8.12.10/8.12.10) with ESMTP id k37BvKWK010973 for ; Fri, 7 Apr 2006 07:57:20 -0400 Mime-Version: 1.0 (Apple Message framework v749.3) In-Reply-To: <4435AEFB.1090807@adevsoft.com> References: <44358840.6050903@adevsoft.com> <1A9659D5-139E-4FB8-8FA3-061BD3156466@osafoundation.org> <4435AEFB.1090807@adevsoft.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Jay Batson Subject: Re: [Ietf-caldav] Caldav sync approach comments Date: Fri, 7 Apr 2006 07:57:18 -0400 To: ietf-caldav@osafoundation.org X-Mailer: Apple Mail (2.749.3) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-2.2 tagged_above=-50.0 required=4.0 tests=AWL, BAYES_00 X-Spam-Level: X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions on Calendar Access protocol based on WebDAV List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Apr 2006 11:57:25 -0000 Nice discussion here. I'm not sure layering SyncML in is essential. Maybe worth an analysis, but I wouldn't jump too quickly. It's a complex thing in its own right, and I would move slowly towards adding something of this weight. The real issue isn't whether ETags is sufficient; it provides sufficient help for the "versioning" needed to make sync happen. My concern was that the client has to do the conflict detection and merge. While saddled with the issues I raise, the client-centric approach does have some scalability advantages. So don't jump too far too fast by adding SyncML into the mix. I wish I knew what to suggest we'd prefer to see. It's a tough call. I'm happy to see this august body discuss it, though. Thanks -jb On Apr 6, 2006, at 8:14 PM, Kervin L. Pierre wrote: > Hello, > > Lisa Dusseault wrote: >> OTOH maybe it looks completely different. Maybe there's a clever >> binding of SyncML to HTTP resource namespaces? > > SyncML HTTP binding on the calendar collection > would work well here I think. > > Maybe it can be an informal recommendation > outside CalDAV? With CalDAV only ensuring > compatibility between the two access methods. > > Best regards, > Kervin ------------- Jay Batson batsonjay@plumcanary.com +1-978-824-0111 (w) +1-978-758-1599 (m) Return-Path: X-Original-To: ietf-caldav@osafoundation.org Delivered-To: ietf-caldav@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 5DCF57F6D1 for ; Fri, 7 Apr 2006 04:40:35 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 4ED94142279 for ; Fri, 7 Apr 2006 04:40:35 -0700 (PDT) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 03800-01 for ; Fri, 7 Apr 2006 04:40:33 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.de [213.165.64.20]) by laweleka.osafoundation.org (Postfix) with SMTP id 48D1F142277 for ; Fri, 7 Apr 2006 04:40:33 -0700 (PDT) Received: (qmail invoked by alias); 07 Apr 2006 11:36:34 -0000 Received: from pd95b23e9.dip0.t-ipconnect.de (EHLO [192.168.1.40]) [217.91.35.233] by mail.gmx.net (mp037) with SMTP; 07 Apr 2006 13:36:34 +0200 X-Authenticated: #1915285 Message-ID: <44364E55.5090700@gmx.de> Date: Fri, 07 Apr 2006 13:34:45 +0200 From: Julian Reschke User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Jari Urpalainen Subject: Re: [Ietf-caldav] comments on version 10 of the CalDAV draft References: <891B80B426210ABAE1C865EB@ninevah.local> <1144406600.26916.104.camel@hed034-145.research.nokia.com> In-Reply-To: <1144406600.26916.104.camel@hed034-145.research.nokia.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-1.5 tagged_above=-50.0 required=4.0 tests=AWL, BAYES_00 X-Spam-Level: Cc: CalDAV DevList X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions on Calendar Access protocol based on WebDAV List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Apr 2006 11:40:35 -0000 Jari Urpalainen wrote: > On Wed, 2006-04-05 at 13:34 -0400, ext Cyrus Daboo wrote: >> Hi Jeff, >> Thanks for your comments: > >>> 5.3.4 (last paragraph: A response to a PUT request MUST NOT contain an >>> ETag response header ....) >>> >>> Why shouldn't the server respond with the ETag it used to store the >>> calendar object? Wouldn't that be more efficient than making the client >>> query the server to determine what it used? >> There is a lot of debate about the meaning of an ETag header on a PUT and I >> believe there will be some work to tighten this up in the future. What we >> put in CalDAV was what we felt was best under the current conditions. >> > Sorry, if this has been discussed already, but I got somewhat confused > about this... > > "As required by [RFC2616], a response to a PUT request with a strong > entity tag MUST mean that the server will return on a subsequent GET > request a calendar object resource that is equivalent by octet > equality. > > I could not find a straight reference to this from rfc2616. We had some > similar discussions with XCAP as well, where an explicit get(put(x))=x > is defined, but I think this kind interpretation of rfc2616 is rather > implicit, imo. So I'd prefer to just to remove the part "As required by > [RFC2616]," because it is ok to have this sort of CalDAV requirement. Or > alternatively "As required by this specification,". First of all, RFC2616 doesn't mandate that. So claiming it does is definitively a bad thing to do. Furthermore, I also think that CalDAV making it's own requirements is a bad idea; it should just rely on what RFC2518bis will say. > ... Best regards, Julian Return-Path: X-Original-To: ietf-caldav@osafoundation.org Delivered-To: ietf-caldav@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id A5B3A7F6E0 for ; Fri, 7 Apr 2006 03:44:02 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 9762F142277 for ; Fri, 7 Apr 2006 03:44:02 -0700 (PDT) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 24738-07 for ; Fri, 7 Apr 2006 03:44:02 -0700 (PDT) Received: from mgw-ext11.nokia.com (mgw-ext11.nokia.com [131.228.20.170]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 96C1414226F for ; Fri, 7 Apr 2006 03:44:01 -0700 (PDT) Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext11.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k37Ag1DH003839; Fri, 7 Apr 2006 13:42:04 +0300 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 7 Apr 2006 13:43:21 +0300 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 7 Apr 2006 13:43:21 +0300 Received: from 172.21.34.145 ([172.21.34.145]) by esebe105.NOE.Nokia.com ([172.21.143.53]) with Microsoft Exchange Server HTTP-DAV ; Fri, 7 Apr 2006 10:43:20 +0000 Received: from hed034-145.research.nokia.com by esebe105.noe.nokia.com; 07 Apr 2006 13:43:20 +0300 Subject: Re: [Ietf-caldav] comments on version 10 of the CalDAV draft From: Jari Urpalainen To: ext Cyrus Daboo In-Reply-To: <891B80B426210ABAE1C865EB@ninevah.local> References: <891B80B426210ABAE1C865EB@ninevah.local> Content-Type: text/plain Content-Transfer-Encoding: 7bit Date: Fri, 07 Apr 2006 13:43:20 +0300 Message-Id: <1144406600.26916.104.camel@hed034-145.research.nokia.com> Mime-Version: 1.0 X-Mailer: Evolution 2.6.0 (2.6.0-1) X-OriginalArrivalTime: 07 Apr 2006 10:43:21.0750 (UTC) FILETIME=[1700DB60:01C65A30] X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-1.3 tagged_above=-50.0 required=4.0 tests=AWL, BAYES_00 X-Spam-Level: Cc: CalDAV DevList X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions on Calendar Access protocol based on WebDAV List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Apr 2006 10:44:02 -0000 On Wed, 2006-04-05 at 13:34 -0400, ext Cyrus Daboo wrote: > Hi Jeff, > Thanks for your comments: > > 5.3.4 (last paragraph: A response to a PUT request MUST NOT contain an > > ETag response header ....) > > > > Why shouldn't the server respond with the ETag it used to store the > > calendar object? Wouldn't that be more efficient than making the client > > query the server to determine what it used? > > There is a lot of debate about the meaning of an ETag header on a PUT and I > believe there will be some work to tighten this up in the future. What we > put in CalDAV was what we felt was best under the current conditions. > Sorry, if this has been discussed already, but I got somewhat confused about this... "As required by [RFC2616], a response to a PUT request with a strong entity tag MUST mean that the server will return on a subsequent GET request a calendar object resource that is equivalent by octet equality. I could not find a straight reference to this from rfc2616. We had some similar discussions with XCAP as well, where an explicit get(put(x))=x is defined, but I think this kind interpretation of rfc2616 is rather implicit, imo. So I'd prefer to just to remove the part "As required by [RFC2616]," because it is ok to have this sort of CalDAV requirement. Or alternatively "As required by this specification,". "A response to a PUT request MUST NOT contain an ETag response header field if the server will return on a subsequent GET request a calendar object resource that is not equivalent by octet equality to the submitted calendar object resource. In this case, the client SHOULD retrieve the new entity (and ETag) as a basis for further changes, rather than use the entity it had sent with the PUT request." If I have understood it correctly, you want to signal whether the server does some mangling to the body or not, right ? Probably, I had this hard time of understanding the section, because I was thinking does this apply to If-Match and If-None-Match headers also (which it apparently doesn't). So probably you could add something like this to the end: "In other words, the missing ETag response header is just used to signal to the client when the server has done some mangling to the calendar object resource after successful PUT." br, Jari Return-Path: X-Original-To: ietf-caldav@osafoundation.org Delivered-To: ietf-caldav@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 20FF57F7AB for ; Thu, 6 Apr 2006 17:14:52 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 13029142270 for ; Thu, 6 Apr 2006 17:14:52 -0700 (PDT) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 30364-08 for ; Thu, 6 Apr 2006 17:14:51 -0700 (PDT) Received: from smtp107.biz.mail.re2.yahoo.com (smtp107.biz.mail.re2.yahoo.com [206.190.52.176]) by laweleka.osafoundation.org (Postfix) with SMTP id 7260214226C for ; Thu, 6 Apr 2006 17:14:51 -0700 (PDT) Received: (qmail 93410 invoked from network); 7 Apr 2006 00:14:50 -0000 Received: from unknown (HELO ?163.118.220.44?) (kervin@adevsoft.com@163.118.220.44 with plain) by smtp107.biz.mail.re2.yahoo.com with SMTP; 7 Apr 2006 00:14:50 -0000 Message-ID: <4435AEFB.1090807@adevsoft.com> Date: Thu, 06 Apr 2006 20:14:51 -0400 From: "Kervin L. Pierre" User-Agent: Mozilla Thunderbird 1.0.5 (Windows/20050711) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Lisa Dusseault Subject: Re: [Ietf-caldav] Caldav sync approach comments References: <44358840.6050903@adevsoft.com> <1A9659D5-139E-4FB8-8FA3-061BD3156466@osafoundation.org> In-Reply-To: <1A9659D5-139E-4FB8-8FA3-061BD3156466@osafoundation.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-2.2 tagged_above=-50.0 required=4.0 tests=AWL, BAYES_00 X-Spam-Level: Cc: ietf-caldav@osafoundation.org X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions on Calendar Access protocol based on WebDAV List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Apr 2006 00:14:52 -0000 Hello, Lisa Dusseault wrote: > OTOH maybe it looks completely different. Maybe there's a clever > binding of SyncML to HTTP resource namespaces? > SyncML HTTP binding on the calendar collection would work well here I think. Maybe it can be an informal recommendation outside CalDAV? With CalDAV only ensuring compatibility between the two access methods. Best regards, Kervin Return-Path: X-Original-To: ietf-caldav@osafoundation.org Delivered-To: ietf-caldav@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 0A49F7F77F; Thu, 6 Apr 2006 16:33:33 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id EF59E14226C; Thu, 6 Apr 2006 16:33:32 -0700 (PDT) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 30148-08; Thu, 6 Apr 2006 16:33:31 -0700 (PDT) Received: from out3.smtp.messagingengine.com (out3.smtp.messagingengine.com [66.111.4.27]) by laweleka.osafoundation.org (Postfix) with ESMTP id 7715A142267; Thu, 6 Apr 2006 16:33:31 -0700 (PDT) Received: from frontend2.internal (frontend2.internal [10.202.2.151]) by frontend1.messagingengine.com (Postfix) with ESMTP id C0E09D4635F; Thu, 6 Apr 2006 19:33:29 -0400 (EDT) Received: from frontend3.messagingengine.com ([10.202.2.152]) by frontend2.internal (MEProxy); Thu, 06 Apr 2006 19:33:18 -0400 X-Sasl-enc: veCuzetcH7yUUPhmyUhca/RvH69qCVawOEtaqDFBw97x 1144366398 Received: from [10.0.1.4] (pool-71-253-41-56.pitbpa.east.verizon.net [71.253.41.56]) by www.fastmail.fm (Postfix) with ESMTP id F15F62DDE; Thu, 6 Apr 2006 19:33:16 -0400 (EDT) Date: Thu, 06 Apr 2006 19:33:27 -0400 From: Cyrus Daboo To: Lisa Dusseault , "Kervin L. Pierre" Subject: Re: [Ietf-caldav] Caldav sync approach comments Message-ID: <4B18C8B31286E1A2BD90F2A9@ninevah.local> In-Reply-To: <1A9659D5-139E-4FB8-8FA3-061BD3156466@osafoundation.org> References: <44358840.6050903@adevsoft.com> <1A9659D5-139E-4FB8-8FA3-061BD3156466@osafoundation.org> X-Mailer: Mulberry/4.0.4 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-1.9 tagged_above=-50.0 required=4.0 tests=AWL, BAYES_00 X-Spam-Level: Cc: ietf-caldav@osafoundation.org X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions on Calendar Access protocol based on WebDAV List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Apr 2006 23:33:33 -0000 Hi Lisa, --On April 6, 2006 2:50:43 PM -0700 Lisa Dusseault wrote: > I had a bit of offline discussion with Jay -- we'd both like to see a > synch protocol that works well with HTTP resources, although I argued > that's out of scope for just doing calendaring. Maybe a synch solution > would be along the lines of defining state tags for collections or other > container resources, and/or a REPORT that says what has changed within a > namespace. FYI I did write a sync report into CardDAV as a 'proof of concept' type thing to see if we could do it there and then extend CalDAV to do the same at some later point. Whether we use that, SyncML or something else I do think we will need a better approach than using ETags... -- Cyrus Daboo Return-Path: X-Original-To: ietf-caldav@osafoundation.org Delivered-To: ietf-caldav@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id AEE147F75B for ; Thu, 6 Apr 2006 14:50:49 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id A03F8142270 for ; Thu, 6 Apr 2006 14:50:49 -0700 (PDT) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 24771-01; Thu, 6 Apr 2006 14:50:47 -0700 (PDT) Received: from [192.168.1.100] (c-67-161-46-163.hsd1.ca.comcast.net [67.161.46.163]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 1F87D14226E; Thu, 6 Apr 2006 14:50:47 -0700 (PDT) In-Reply-To: <44358840.6050903@adevsoft.com> References: <44358840.6050903@adevsoft.com> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <1A9659D5-139E-4FB8-8FA3-061BD3156466@osafoundation.org> Content-Transfer-Encoding: 7bit From: Lisa Dusseault Subject: Re: [Ietf-caldav] Caldav sync approach comments Date: Thu, 6 Apr 2006 14:50:43 -0700 To: "Kervin L. Pierre" X-Mailer: Apple Mail (2.746.2) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-0.5 tagged_above=-50.0 required=4.0 tests=AWL, BAYES_00, RCVD_IN_NJABL_DUL, RCVD_IN_SORBS_DUL X-Spam-Level: Cc: ietf-caldav@osafoundation.org X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions on Calendar Access protocol based on WebDAV List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Apr 2006 21:50:49 -0000 I had a bit of offline discussion with Jay -- we'd both like to see a synch protocol that works well with HTTP resources, although I argued that's out of scope for just doing calendaring. Maybe a synch solution would be along the lines of defining state tags for collections or other container resources, and/or a REPORT that says what has changed within a namespace. OTOH maybe it looks completely different. Maybe there's a clever binding of SyncML to HTTP resource namespaces? Lisa On Apr 6, 2006, at 2:29 PM, Kervin L. Pierre wrote: > Hello Jay, > > Jay Batson wrote: > > In CalDAV, the client performs the "sync" work by using ETags > to - the >> detect and resolve information changes. >> Compare this to SyncML, where the server does the that detection / > [...] > > I don't think CalDAV can be directly compared > to SyncML. CalDAV is only the access protocol, > it is suppose to be followed by the schedule > protocol at some point. Expired version of the > draft can be found at... > http://www.greenbytes.de/tech/webdav/draft-desruisseaux-caldav- > sched-00.html > > Best regards, > Kervin > > _______________________________________________ > Ietf-caldav mailing list -- Ietf-caldav@osafoundation.org > See http://ietf.webdav.org/caldav/ for more CalDAV resources > http://lists.osafoundation.org/mailman/listinfo/ietf-caldav Return-Path: X-Original-To: ietf-caldav@osafoundation.org Delivered-To: ietf-caldav@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id B4ED57F74B for ; Thu, 6 Apr 2006 14:29:40 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id A628014226F for ; Thu, 6 Apr 2006 14:29:40 -0700 (PDT) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 10504-03 for ; Thu, 6 Apr 2006 14:29:36 -0700 (PDT) Received: from smtp102.biz.mail.re2.yahoo.com (smtp102.biz.mail.re2.yahoo.com [68.142.229.216]) by laweleka.osafoundation.org (Postfix) with SMTP id CBFFF14226E for ; Thu, 6 Apr 2006 14:29:35 -0700 (PDT) Received: (qmail 40708 invoked from network); 6 Apr 2006 21:29:35 -0000 Received: from unknown (HELO ?10.55.10.51?) (kervin@adevsoft.com@24.227.116.130 with plain) by smtp102.biz.mail.re2.yahoo.com with SMTP; 6 Apr 2006 21:29:35 -0000 Message-ID: <44358840.6050903@adevsoft.com> Date: Thu, 06 Apr 2006 17:29:36 -0400 From: "Kervin L. Pierre" User-Agent: Mozilla Thunderbird 1.0.5 (Windows/20050711) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jay Batson Subject: Re: [Ietf-caldav] Caldav sync approach comments References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-1.8 tagged_above=-50.0 required=4.0 tests=AWL, BAYES_00 X-Spam-Level: Cc: ietf-caldav@osafoundation.org X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions on Calendar Access protocol based on WebDAV List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Apr 2006 21:29:40 -0000 Hello Jay, Jay Batson wrote: > In CalDAV, the client performs the "sync" work by using ETags to - the > detect and resolve information changes. > > Compare this to SyncML, where the server does the that detection / [...] I don't think CalDAV can be directly compared to SyncML. CalDAV is only the access protocol, it is suppose to be followed by the schedule protocol at some point. Expired version of the draft can be found at... http://www.greenbytes.de/tech/webdav/draft-desruisseaux-caldav-sched-00.html Best regards, Kervin Return-Path: X-Original-To: ietf-caldav@osafoundation.org Delivered-To: ietf-caldav@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id A82187F74B for ; Thu, 6 Apr 2006 11:03:12 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 9A5B814226C for ; Thu, 6 Apr 2006 11:03:12 -0700 (PDT) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 20264-04 for ; Thu, 6 Apr 2006 11:03:12 -0700 (PDT) Received: from plumcanary.com (sync.plumcanary.com [216.154.222.73]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id E3C96142267 for ; Thu, 6 Apr 2006 11:03:11 -0700 (PDT) Received: from [192.168.0.2] (c-24-128-44-227.hsd1.ma.comcast.net [24.128.44.227]) by plumcanary.com (8.12.10/8.12.10) with ESMTP id k36I38j9023616 for ; Thu, 6 Apr 2006 14:03:08 -0400 Mime-Version: 1.0 (Apple Message framework v746.3) Content-Transfer-Encoding: 7bit Message-Id: Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: ietf-caldav@osafoundation.org From: Jay Batson Date: Thu, 6 Apr 2006 14:03:08 -0400 X-Mailer: Apple Mail (2.746.3) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-2.0 tagged_above=-50.0 required=4.0 tests=AWL, BAYES_00 X-Spam-Level: Subject: [Ietf-caldav] Caldav sync approach comments X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions on Calendar Access protocol based on WebDAV List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Apr 2006 18:03:12 -0000 Hi - I know I'm a bit late to the game, and late for comments of the type I'm making, which poses an architectural problem that is probably too late / hard to work on. Caldav supports the notion of offline work, and synchronization of changes, in 8.2.1.3 et.seq. This is important stuff. AJAX trends notwithstanding, a pretty healthy amount of people want software they can use while offline. In CalDAV, the client performs the "sync" work by using ETags to - the detect and resolve information changes. Compare this to SyncML, where the server does the that detection / resolution (e.g. the "sync"). The client sends relevant data, the server resolves conflicts, and tells the client how to resolve the sync process, returning information as needed. The advantage of the SyncML approach is centralized control over a notoriously hard task. In our experience, we've had our share of pain fixing bugs in this area. Fortunately, our server is currently based on SyncML, and if there's a bug with the sync / merge logic, we can fix the bug and deploy a new server, and fix our entire installed base in one whack. Whereas with Caldav, we'll have to produce a new client release and trigger an (auto-)update our entire installed base of client desktops in order to solve sync logic problems. Unfortunately, anybody - vendors, open source projects, etc. - who deals with client software must manage the software release cycle, and release timing is affected by lots of factors. In contrast, server-side releases are much easier to handle, whether the server is being provided by a service, or in an enterprise (premises-resident) configuration. So the SyncML server-side sync approach does provide an advantage. Of course, I understand the benefits of client-side work - principally in scalability (by using client CPU cycles instead of servers), consistency with SMTP/IMAP, and other IETF-style approaches, etc. While these benefits are real, the client-centric approach does pose the practical difficulties I mention. As I said, this is probably not the right time to bring this kind of problem up. But there it is anyway. Anybody wish to comment on this? -jb ------------- Jay Batson batsonjay@plumcanary.com +1-978-824-0111 (w) +1-978-758-1599 (m) Return-Path: X-Original-To: ietf-caldav@osafoundation.org Delivered-To: ietf-caldav@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 3D7F97F6DA for ; Wed, 5 Apr 2006 16:42:49 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 2644B142269 for ; Wed, 5 Apr 2006 16:42:49 -0700 (PDT) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 06744-06 for ; Wed, 5 Apr 2006 16:42:46 -0700 (PDT) Received: from mail.mdlink.net (medusa.mdlink.de [213.211.192.34]) by laweleka.osafoundation.org (Postfix) with ESMTP id 902B4142267 for ; Wed, 5 Apr 2006 16:42:46 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.mdlink.net (Postfix) with ESMTP id E65B53DBA0C for ; Thu, 6 Apr 2006 01:39:08 +0200 (CEST) Received: from [192.168.1.233] (port-ip-213-211-243-146.reverse.mdcc-fun.de [213.211.243.146]) by mail.mdlink.net (Postfix) with ESMTP id 8F4553DB9D8 for ; Thu, 6 Apr 2006 01:39:08 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v749.3) In-Reply-To: References: <891B80B426210ABAE1C865EB@ninevah.local> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <736B2D05-DD85-4C60-A959-1CCCB916FC05@opengroupware.org> Content-Transfer-Encoding: 7bit From: Helge Hess Subject: Re: [Ietf-caldav] comments on version 10 of the CalDAV draft Date: Thu, 6 Apr 2006 01:41:21 +0200 To: CalDAV DevList X-Mailer: Apple Mail (2.749.3) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-1.5 tagged_above=-50.0 required=4.0 tests=AWL, BAYES_00 X-Spam-Level: X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions on Calendar Access protocol based on WebDAV List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Apr 2006 23:42:49 -0000 On 5. Apr 2006, at 21:11 Uhr, Jeff McCullough wrote: >> Depth can be 0, 1 or infinity so I'm not quite sure what you are >> getting at here. Can you explain some more? > If I query at say depth 2, do I get a response only from depth 2 or > also from depth 1? "Depth can be 0, 1 or infinity" If you query a depth 2, I suppose you will get an HTTP status 400 (Invalid Request). Greets, Helge -- http://docs.opengroupware.org/Members/helge/ OpenGroupware.org Return-Path: X-Original-To: ietf-caldav@osafoundation.org Delivered-To: ietf-caldav@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id D9A087F58C for ; Wed, 5 Apr 2006 12:11:53 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id CBB8E14225E for ; Wed, 5 Apr 2006 12:11:53 -0700 (PDT) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 03729-05 for ; Wed, 5 Apr 2006 12:11:51 -0700 (PDT) Received: from smtp-out1.berkeley.edu (smtp-out1.Berkeley.EDU [128.32.61.106]) by laweleka.osafoundation.org (Postfix) with ESMTP id 56EBC142257 for ; Wed, 5 Apr 2006 12:11:51 -0700 (PDT) Received: from c-24-5-93-169.hsd1.ca.comcast.net ([24.5.93.169] helo=[192.168.1.100]) by calmail-fe4.berkeley.edu with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.60) (auth plain:jeffreym@berkeley.edu) (envelope-from ) id 1FRDPz-00021t-D8; Wed, 05 Apr 2006 12:11:51 -0700 In-Reply-To: <891B80B426210ABAE1C865EB@ninevah.local> References: <891B80B426210ABAE1C865EB@ninevah.local> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Jeff McCullough Subject: Re: [Ietf-caldav] comments on version 10 of the CalDAV draft Date: Wed, 5 Apr 2006 12:11:43 -0700 To: Cyrus Daboo X-Mailer: Apple Mail (2.746.2) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-2.0 tagged_above=-50.0 required=4.0 tests=AWL, BAYES_00 X-Spam-Level: Cc: CalDAV DevList X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions on Calendar Access protocol based on WebDAV List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Apr 2006 19:11:54 -0000 Cyrus, On Apr 5, 2006, at 10:34 AM, Cyrus Daboo wrote: > >> 7.9 (Support for the CALDAV:free-busy-query REPORT is REQUIRED) >> >> If the Depth header is included, does the response contain all >> intermediate depths or only the specified depth? > > Depth can be 0, 1 or infinity so I'm not quite sure what you are > getting at here. Can you explain some more? If I query at say depth 2, do I get a response only from depth 2 or also from depth 1? > >> >> (Paragraph: If the current user is not granted the CALDAV:read-free- >> busy.... This restriction will prevent users from discovering URLs of >> resources for which they are only granted the CALDAV:read-free-busy >> privilege.) >> >> How does this prevent users from discovering URLS for resources for >> which they are granted privileges? Doesn't it prevent them from them >> discovering URLs for which they have no privileges? > > This simply means that if I only give you CALDAV:read-free-busy > privilege on a resource you will not be able to discover the > existence of that resource if you don't already have the uri. > I think the wording needs to be changed. Instead of >> This restriction will prevent users from discovering URLs of >> resources for which they are only granted the CALDAV:read-free-busy >> privilege. change to This restriction will prevent users from discovering URLs of resources for which they are not granted at least the CALDAV:read- free-busy privilege. Cheers, Jeff Return-Path: X-Original-To: ietf-caldav@osafoundation.org Delivered-To: ietf-caldav@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id E93F77F70E for ; Wed, 5 Apr 2006 10:34:14 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id D98D8142262 for ; Wed, 5 Apr 2006 10:34:14 -0700 (PDT) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 18731-09 for ; Wed, 5 Apr 2006 10:34:14 -0700 (PDT) Received: from out1.smtp.messagingengine.com (out1.smtp.messagingengine.com [66.111.4.25]) by laweleka.osafoundation.org (Postfix) with ESMTP id CA18914225E for ; Wed, 5 Apr 2006 10:34:13 -0700 (PDT) Received: from frontend2.internal (frontend2.internal [10.202.2.151]) by frontend1.messagingengine.com (Postfix) with ESMTP id 7E971D46FAC; Wed, 5 Apr 2006 13:34:12 -0400 (EDT) Received: from frontend3.messagingengine.com ([10.202.2.152]) by frontend2.internal (MEProxy); Wed, 05 Apr 2006 13:34:03 -0400 X-Sasl-enc: NHxYxqZIHXzm2AtXgbAL25PoqIqw9tEnJys3Bafv5mOK 1144258442 Received: from [10.0.1.4] (unknown [17.101.35.162]) by www.fastmail.fm (Postfix) with ESMTP id E9BB71FD1; Wed, 5 Apr 2006 13:34:01 -0400 (EDT) Date: Wed, 05 Apr 2006 13:34:09 -0400 From: Cyrus Daboo To: Jeff McCullough , CalDAV DevList Subject: Re: [Ietf-caldav] comments on version 10 of the CalDAV draft Message-ID: <891B80B426210ABAE1C865EB@ninevah.local> X-Mailer: Mulberry/4.0.4 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-1.8 tagged_above=-50.0 required=4.0 tests=AWL, BAYES_00 X-Spam-Level: X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions on Calendar Access protocol based on WebDAV List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Apr 2006 17:34:15 -0000 Hi Jeff, Thanks for your comments: --On April 5, 2006 1:44:06 AM -0700 Jeff McCullough wrote: > 4.2 (last paragraph starting: Calendar collections MUST only contain > calendar object resources .....) > > This section mostly discusses what should not be. Can you also include > some text about what should be true. Ok - reworded and reformatted into a list with some additional explanation of the restrictions themselves. > 5.1.1 (second example: In this example, the OPTIONS method returns the > value "calendar-access" in the DAV ....may support properties ....) > > Why is this "may" support, since the earlier text in 5.1 states a MUST? > Maybe the "may" can just be removed? Done. > 5.2.1 - 5.2.4 > > While there is a section marked conformance, there is conformance > information in the description section. Probably all conformance > information should be in the conformance section for consistency sake. Done. > 5.2.5 > > There may be value in clarifying the first sentence to say that the > CalDAV specification requires an additional precondition rather than > creates a precondition. Done. > 5.3.2 > > Probably a silly nit, but why does the example add an entry for a 2001 > Bastille Day Party in 2005? OK - we'll have the party in 2006 then! > 5.3.4 (last paragraph: A response to a PUT request MUST NOT contain an > ETag response header ....) > > Why shouldn't the server respond with the ETag it used to store the > calendar object? Wouldn't that be more efficient than making the client > query the server to determine what it used? There is a lot of debate about the meaning of an ETag header on a PUT and I believe there will be some work to tighten this up in the future. What we put in CalDAV was what we felt was best under the current conditions. > 6.2.1 (description section) > > This property specify the URL of collections that either are calendar ... > > should be: > This property specifies the URL of collections that are either calendar Done. > 7.2 > > You may want to reorder the sentences in this paragraph to have the MUST > part before the MAY part. Also the "subject also to the value of the > Depth request header" should be a separate sentence. Actually the MUST should be after the MAY. However, I have reworded this to make it a little clearer. > 7.5 > > In this section you refer to information that is listed later in the > document. It isn't clear from the text how the client specifies one of > the three options. Yes, that is covered in later sections, but it would > be worth bringing it forward here as well. This section has been completely rewritten for the next draft and no longer suffers from this problem. > 7.7 (paragraph starting: CALDAV:supported-filter....) > > The last sentence is a bit hard to understand the way it is worded. I > don't think it is completely obvious why it is worded as such. From our > conversation, I understand this format is similar to the way it is in > WebDAV. There may be some value in clarifying that. OK, I added a sentence to clarify this. > 7.7.x example reports > > The response date is Nov 2005 while some of the data elements have last > modified dates in 2006. Fixed. > 7.7.1 > > It would be helpful if you were to explain more about the dates that are > stored on the server. That way the example returns will be clearer. I > finally found your full reports at the end of the document, though it > would take much to clarify it in text here. I've added 'see Section ...' references to all of the examples in the REPORT section to point to the data being used in the examples. > In the first example, you specify the properties that you want returned. > In the response, you have DTSTAMP which is not included in the request > property list. Fixed. > > 7.9 (Support for the CALDAV:free-busy-query REPORT is REQUIRED) > > If the Depth header is included, does the response contain all > intermediate depths or only the specified depth? Depth can be 0, 1 or infinity so I'm not quite sure what you are getting at here. Can you explain some more? > > (Paragraph: If the current user is not granted the CALDAV:read-free- > busy.... This restriction will prevent users from discovering URLs of > resources for which they are only granted the CALDAV:read-free-busy > privilege.) > > How does this prevent users from discovering URLS for resources for > which they are granted privileges? Doesn't it prevent them from them > discovering URLs for which they have no privileges? This simply means that if I only give you CALDAV:read-free-busy privilege on a resource you will not be able to discover the existence of that resource if you don't already have the uri. > 9.2 (Purpose: Specifies a request that lists the ....) > Change "lists" to "includes". Done. > 9.5 (Description: 3rd paragraph: 2nd sentence: Given that XML parsers > normalizes the two-character....) > > change normalizes to normalize Done. > Appendix B. > > In the example the >> Response << label is placed in the middle of the > request. The response label should follow . > > Also the HTTP/1.1 200 OK > Date: ..... > Content-Type: text/calendar > Content-Length: xxxx > > should be included before the tag. Done - plus I also added proper HTTP headers for the response. -- Cyrus Daboo Return-Path: X-Original-To: ietf-caldav@osafoundation.org Delivered-To: ietf-caldav@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 025167F6A3 for ; Wed, 5 Apr 2006 01:44:14 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id E8748142264 for ; Wed, 5 Apr 2006 01:44:13 -0700 (PDT) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 05866-08 for ; Wed, 5 Apr 2006 01:44:11 -0700 (PDT) Received: from smtp-out1.berkeley.edu (smtp-out1.Berkeley.EDU [128.32.61.106]) by laweleka.osafoundation.org (Postfix) with ESMTP id 23AB5142262 for ; Wed, 5 Apr 2006 01:44:11 -0700 (PDT) Received: from c-24-5-93-169.hsd1.ca.comcast.net ([24.5.93.169] helo=[192.168.1.100]) by calmail-fe5.berkeley.edu with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.60) (auth plain:jeffreym@berkeley.edu) (envelope-from ) id 1FR3cY-0006Pc-Il for ietf-caldav@osafoundation.org; Wed, 05 Apr 2006 01:44:10 -0700 Mime-Version: 1.0 (Apple Message framework v746.2) Content-Transfer-Encoding: 7bit Message-Id: <3F521D37-9F1A-4495-BD33-D73ADDC701AA@berkeley.edu> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: CalDAV DevList From: Jeff McCullough Date: Wed, 5 Apr 2006 01:44:06 -0700 X-Mailer: Apple Mail (2.746.2) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-1.9 tagged_above=-50.0 required=4.0 tests=AWL, BAYES_00 X-Spam-Level: Subject: [Ietf-caldav] comments on version 10 of the CalDAV draft X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions on Calendar Access protocol based on WebDAV List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Apr 2006 08:44:14 -0000 Bernard, Here are the comments I have on the version 10 CalDAV draft. Many of these we already discussed. 4.2 (last paragraph starting: Calendar collections MUST only contain calendar object resources .....) This section mostly discusses what should not be. Can you also include some text about what should be true. 5.1.1 (second example: In this example, the OPTIONS method returns the value "calendar-access" in the DAV ....may support properties ....) Why is this "may" support, since the earlier text in 5.1 states a MUST? Maybe the "may" can just be removed? 5.2.1 - 5.2.4 While there is a section marked conformance, there is conformance information in the description section. Probably all conformance information should be in the conformance section for consistency sake. 5.2.5 There may be value in clarifying the first sentence to say that the CalDAV specification requires an additional precondition rather than creates a precondition. 5.3.2 Probably a silly nit, but why does the example add an entry for a 2001 Bastille Day Party in 2005? 5.3.4 (last paragraph: A response to a PUT request MUST NOT contain an ETag response header ....) Why shouldn't the server respond with the ETag it used to store the calendar object? Wouldn't that be more efficient than making the client query the server to determine what it used? 6.2.1 (description section) This property specify the URL of collections that either are calendar ... should be: This property specifies the URL of collections that are either calendar 7.2 You may want to reorder the sentences in this paragraph to have the MUST part before the MAY part. Also the "subject also to the value of the Depth request header" should be a separate sentence. 7.5 In this section you refer to information that is listed later in the document. It isn't clear from the text how the client specifies one of the three options. Yes, that is covered in later sections, but it would be worth bringing it forward here as well. 7.7 (paragraph starting: CALDAV:supported-filter....) The last sentence is a bit hard to understand the way it is worded. I don't think it is completely obvious why it is worded as such. From our conversation, I understand this format is similar to the way it is in WebDAV. There may be some value in clarifying that. 7.7.x example reports The response date is Nov 2005 while some of the data elements have last modified dates in 2006. 7.7.1 It would be helpful if you were to explain more about the dates that are stored on the server. That way the example returns will be clearer. I finally found your full reports at the end of the document, though it would take much to clarify it in text here. In the first example, you specify the properties that you want returned. In the response, you have DTSTAMP which is not included in the request property list. 7.9 (Support for the CALDAV:free-busy-query REPORT is REQUIRED) If the Depth header is included, does the response contain all intermediate depths or only the specified depth? (Paragraph: If the current user is not granted the CALDAV:read-free- busy.... This restriction will prevent users from discovering URLs of resources for which they are only granted the CALDAV:read-free-busy privilege.) How does this prevent users from discovering URLS for resources for which they are granted privileges? Doesn't it prevent them from them discovering URLs for which they have no privileges? 9.2 (Purpose: Specifies a request that lists the ....) Change "lists" to "includes". 9.5 (Description: 3rd paragraph: 2nd sentence: Given that XML parsers normalizes the two-character....) change normalizes to normalize Appendix B. In the example the >> Response << label is placed in the middle of the request. The response label should follow . Also the HTTP/1.1 200 OK Date: ..... Content-Type: text/calendar Content-Length: xxxx should be included before the tag. Cheers, Jeff Jeff McCullough jeffmc@berkeley.edu Return-Path: X-Original-To: ietf-caldav@osafoundation.org Delivered-To: ietf-caldav@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id F37577F691; Tue, 4 Apr 2006 07:57:23 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id E3AB9142279; Tue, 4 Apr 2006 07:57:23 -0700 (PDT) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 14319-09; Tue, 4 Apr 2006 07:57:21 -0700 (PDT) Received: from rgminet01.oracle.com (rgminet01.oracle.com [148.87.113.118]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 42515142273; Tue, 4 Apr 2006 07:57:21 -0700 (PDT) Received: from rgmsgw301.us.oracle.com (rgmsgw301.us.oracle.com [138.1.186.50]) by rgminet01.oracle.com (Switch-3.1.6/Switch-3.1.6) with ESMTP id k34EuYmF007533; Tue, 4 Apr 2006 08:56:35 -0600 Received: from localhost (localhost [127.0.0.1]) by rgmsgw301.us.oracle.com (Switch-3.1.7/Switch-3.1.7) with SMTP id k34EuYGH028017; Tue, 4 Apr 2006 08:56:34 -0600 Received: from [10.156.42.83] (bdesruis-ca.ca.oracle.com [10.156.42.83]) by rgmsgw301.us.oracle.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id k34EuWJv027999 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Tue, 4 Apr 2006 08:56:33 -0600 Message-ID: <443288B9.8010308@oracle.com> Date: Tue, 04 Apr 2006 10:54:49 -0400 From: Bernard Desruisseaux User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Kervin L. Pierre" Subject: Re: [Ietf-caldav] Fwd: Comments on CalDav-10 draft References: <4431751B.4090605@isode.com> <38D9F6CA-7A8D-4ABF-8396-960A7860F150@osafoundation.org> <443285BE.1040700@adevsoft.com> In-Reply-To: <443285BE.1040700@adevsoft.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAQAAAAI= X-Whitelist: TRUE X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-2.2 tagged_above=-50.0 required=4.0 tests=AWL, BAYES_00 X-Spam-Level: Cc: Alexey Melnikov , CalDAV DevList X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions on Calendar Access protocol based on WebDAV List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Apr 2006 14:57:24 -0000 Kervin, The following properties will be added to calendar collections in the next draft: CALDAV:max-resource-size CALDAV:min-date-time CALDAV:max-date-time CALDAV:max-instances CALDAV:max-attendees-per-instance The draft will also define preconditions with the same names. Cheers, Bernard Kervin L. Pierre wrote: > Lisa Dusseault wrote: > >>> 5). Postconditions in Section 7.7 >>> >>> Is there a way to find out what is the value of the server specific >>> limit? Also, is it possible for the client to ask "fail request if >>> you find more than N responses". >>> Similar feature is occasionally useful in LDAP searches. >> >> >> >> No, although a server could put human-readable text inside the >> postcondition. Generally WebDAV doesn't have this kind of feature and >> we'd be loathe to invent it for CalDAV. >> > > This issue came up recently in our testing. It > seems that some important limits like > minimum/maximum valid dates have to be > pre-configured in each client. How can a client > find this out programmatically? Some computational > and memory related limits caused by expansions, > etc. > > The client will have a hard time figuring out why > an option failed and thus will only be able to > inform the user. Users and admins will have to > figure out the errors and troubleshoot. If > CalDAV returned the errors in a machine parsable > form, then client developers would be able to > react to those error notices. > > I don't think not addressing is a bad thing, by > the way. Suspect that de facto limits will > probably emerge, as there aren't going to be many > server implementations anyway, and admins who > tweak the limits would have to understand that > they'll be bringing more work on themselves as > users will start bringing them error messages :) > > Best regards, > Kervin > _______________________________________________ > Ietf-caldav mailing list -- Ietf-caldav@osafoundation.org > See http://ietf.webdav.org/caldav/ for more CalDAV resources > http://lists.osafoundation.org/mailman/listinfo/ietf-caldav Return-Path: X-Original-To: ietf-caldav@osafoundation.org Delivered-To: ietf-caldav@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id A15AE7F61C; Tue, 4 Apr 2006 07:50:43 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 86F7A14227E; Tue, 4 Apr 2006 07:50:43 -0700 (PDT) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 15893-10; Tue, 4 Apr 2006 07:50:43 -0700 (PDT) Received: from out1.smtp.messagingengine.com (out1.smtp.messagingengine.com [66.111.4.25]) by laweleka.osafoundation.org (Postfix) with ESMTP id D0957142273; Tue, 4 Apr 2006 07:50:42 -0700 (PDT) Received: from frontend2.internal (frontend2.internal [10.202.2.151]) by frontend1.messagingengine.com (Postfix) with ESMTP id B4528D45A12; Tue, 4 Apr 2006 10:50:41 -0400 (EDT) Received: from frontend3.messagingengine.com ([10.202.2.152]) by frontend2.internal (MEProxy); Tue, 04 Apr 2006 10:50:34 -0400 X-Sasl-enc: EP3dwsrzsZtikhe+xk2k64qxkBPhalJ9HFSI1dswt5nW 1144162233 Received: from [17.101.35.110] (unknown [17.101.35.110]) by www.fastmail.fm (Postfix) with ESMTP id ED461215B; Tue, 4 Apr 2006 10:50:31 -0400 (EDT) Date: Tue, 04 Apr 2006 10:50:53 -0400 From: Cyrus Daboo To: "Kervin L. Pierre" , Lisa Dusseault Subject: Re: [Ietf-caldav] Fwd: Comments on CalDav-10 draft Message-ID: <6212411454C537BF9073DF88@Cyrus-Daboo.local> In-Reply-To: <443285BE.1040700@adevsoft.com> References: <4431751B.4090605@isode.com> <38D9F6CA-7A8D-4ABF-8396-960A7860F150@osafoundation.org> <443285BE.1040700@adevsoft.com> X-Mailer: Mulberry/4.0.4 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-1.8 tagged_above=-50.0 required=4.0 tests=AWL, BAYES_00 X-Spam-Level: Cc: Alexey Melnikov , CalDAV DevList X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions on Calendar Access protocol based on WebDAV List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Apr 2006 14:50:43 -0000 Hi Kervin, --On April 4, 2006 10:42:06 AM -0400 "Kervin L. Pierre" wrote: >> No, although a server could put human-readable text inside the >> postcondition. Generally WebDAV doesn't have this kind of feature and >> we'd be loathe to invent it for CalDAV. >> > > This issue came up recently in our testing. It > seems that some important limits like > minimum/maximum valid dates have to be > pre-configured in each client. How can a client > find this out programmatically? Some computational > and memory related limits caused by expansions, > etc. > > The client will have a hard time figuring out why > an option failed and thus will only be able to > inform the user. Users and admins will have to > figure out the errors and troubleshoot. If > CalDAV returned the errors in a machine parsable > form, then client developers would be able to > react to those error notices. > > I don't think not addressing is a bad thing, by > the way. Suspect that de facto limits will > probably emerge, as there aren't going to be many > server implementations anyway, and admins who > tweak the limits would have to understand that > they'll be bringing more work on themselves as > users will start bringing them error messages :) The next version of the draft now defines an additional set of properties on calendar collections that allow the server to advertise its limits. The set of properties are: 5.2.5. CALDAV:max-resource-size Property . . . . . . . . . . 15 5.2.6. CALDAV:min-date-time Property . . . . . . . . . . . . 15 5.2.7. CALDAV:max-date-time Property . . . . . . . . . . . . 16 5.2.8. CALDAV:max-instances Property . . . . . . . . . . . . 17 5.2.9. CALDAV:max-attendees-per-instance Property . . . . . 18 There are preconditions associated with each of these. So if a client gets one of those preconditions as an error it can check the property on the resource to see what the actual limit is. Or it can check those properties up front and prevent the user from creating events, tasks etc that exceed the limits. -- Cyrus Daboo Return-Path: X-Original-To: ietf-caldav@osafoundation.org Delivered-To: ietf-caldav@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 682E17F61C for ; Tue, 4 Apr 2006 07:42:22 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 58E62142273 for ; Tue, 4 Apr 2006 07:42:22 -0700 (PDT) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 17627-06 for ; Tue, 4 Apr 2006 07:42:20 -0700 (PDT) Received: from smtp103.biz.mail.re2.yahoo.com (smtp103.biz.mail.re2.yahoo.com [68.142.229.217]) by laweleka.osafoundation.org (Postfix) with SMTP id 10CF3142271 for ; Tue, 4 Apr 2006 07:42:19 -0700 (PDT) Received: (qmail 25277 invoked from network); 4 Apr 2006 14:42:18 -0000 Received: from unknown (HELO ?192.168.0.77?) (kervin@adevsoft.com@12.8.36.193 with plain) by smtp103.biz.mail.re2.yahoo.com with SMTP; 4 Apr 2006 14:42:18 -0000 Message-ID: <443285BE.1040700@adevsoft.com> Date: Tue, 04 Apr 2006 10:42:06 -0400 From: "Kervin L. Pierre" User-Agent: Mozilla Thunderbird 1.0.5 (Windows/20050711) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Lisa Dusseault Subject: Re: [Ietf-caldav] Fwd: Comments on CalDav-10 draft References: <4431751B.4090605@isode.com> <38D9F6CA-7A8D-4ABF-8396-960A7860F150@osafoundation.org> In-Reply-To: <38D9F6CA-7A8D-4ABF-8396-960A7860F150@osafoundation.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-1.9 tagged_above=-50.0 required=4.0 tests=AWL, BAYES_00, RCVD_IN_SORBS_WEB X-Spam-Level: Cc: Alexey Melnikov , CalDAV DevList X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions on Calendar Access protocol based on WebDAV List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Apr 2006 14:42:22 -0000 Lisa Dusseault wrote: >> 5). Postconditions in Section 7.7 >> >> Is there a way to find out what is the value of the server specific >> limit? Also, is it possible for the client to ask "fail request if you >> find more than N responses". >> Similar feature is occasionally useful in LDAP searches. > > > No, although a server could put human-readable text inside the > postcondition. Generally WebDAV doesn't have this kind of feature and > we'd be loathe to invent it for CalDAV. > This issue came up recently in our testing. It seems that some important limits like minimum/maximum valid dates have to be pre-configured in each client. How can a client find this out programmatically? Some computational and memory related limits caused by expansions, etc. The client will have a hard time figuring out why an option failed and thus will only be able to inform the user. Users and admins will have to figure out the errors and troubleshoot. If CalDAV returned the errors in a machine parsable form, then client developers would be able to react to those error notices. I don't think not addressing is a bad thing, by the way. Suspect that de facto limits will probably emerge, as there aren't going to be many server implementations anyway, and admins who tweak the limits would have to understand that they'll be bringing more work on themselves as users will start bringing them error messages :) Best regards, Kervin Return-Path: X-Original-To: ietf-caldav@osafoundation.org Delivered-To: ietf-caldav@osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id A08697F61A for ; Mon, 3 Apr 2006 13:10:37 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 91DA314227E for ; Mon, 3 Apr 2006 13:10:37 -0700 (PDT) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 21385-10; Mon, 3 Apr 2006 13:10:36 -0700 (PDT) Received: from [192.168.1.100] (c-67-161-46-163.hsd1.ca.comcast.net [67.161.46.163]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 26773142276; Mon, 3 Apr 2006 13:10:36 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v746.2) References: <4431751B.4090605@isode.com> Content-Type: multipart/alternative; boundary=Apple-Mail-23-431584174 Message-Id: <38D9F6CA-7A8D-4ABF-8396-960A7860F150@osafoundation.org> From: Lisa Dusseault Date: Mon, 3 Apr 2006 13:10:24 -0700 To: Alexey Melnikov X-Mailer: Apple Mail (2.746.2) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Status: No, hits=-0.5 tagged_above=-50.0 required=4.0 tests=AWL, BAYES_00, HTML_MESSAGE, RCVD_IN_NJABL_DUL, RCVD_IN_SORBS_DUL X-Spam-Level: Cc: CalDAV DevList Subject: [Ietf-caldav] Fwd: Comments on CalDav-10 draft X-BeenThere: ietf-caldav@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions on Calendar Access protocol based on WebDAV List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Apr 2006 20:10:37 -0000 --Apple-Mail-23-431584174 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Thanks for these comments Alexey. Some responses inline: Begin forwarded message: > From: Alexey Melnikov > Date: April 3, 2006 12:18:51 PM PDT > To: Lisa Dusseault , Cyrus Daboo > , Bernard Desruisseaux > > Subject: Comments on CalDav-10 draft > > Overall I find the document to be well written and full of > implementation details. Some comments (and question), mostly > nitpicking, below. > (Please excuse my ignorance, I didn't have time to absorb all > WebDav and Calendar related drafts/RFCs. Kindly point me to the > right documents.) > > 1). In Section 5.2.3 (CALDAV:supported-calendar-component-set) > > >Description: The CALDAV:supported-calendar-component-set property MAY > > be defined on any calendar collection to specify restrictions on > > the calendar component types that calendar object resources may > > contain in a calendar collection. > > Is this (or rather the example listing both VEVENT and VTODO) in > contradiction with the first sentence in section 4.1?: No, but we were probably a little misleading there. We will try to clarify in 4.1 that a collection can contain more than one kind of component, but only one component per resource. > > >Calendar object resources contained in calendar collections MUST NOT > >contain more than one type of calendar components (e.g., VEVENT, > >VTODO, VJOURNAL, VFREEBUSY, etc.) with the exception of VTIMEZONE > >components which MUST be specified for each unique TZID parameter > >value specified in the iCalendar object. > > 2). In Section 5.3.3 > > >Server MUST support the use of non-standard components, properties > >and parameters in calendar object resources stored via the PUT > >method. > >Servers MAY reject any non-standandard components, properties and > >parameters that have specific values in calendar object resources > >stored via the PUT method. > > It sounds like the MAY gives license to ignore the MUST, if the > server decides that any value is not allowed. You're right. we'll rework this. > > 3). In Section 7.5: > > Item # 2: > > >Return the "master component" and only the "overridden > >components" that currently or originally overlap the specified > >time range. > > Maybe it is just me, but what is "currently overlap" and > "originally overlap"? It's a particularly confusing part of iCalendar. We'll try to define those phrases in context. > > 4). Preconditions in Section 7.7 (CALDAV:calendar-query report): > > (CALDAV:valid-filter) - for ease of implementations it would be > nice to have a pointer to the section(s) describing all valid or > invalid filters. I'm sure you're right and we'll try to do a bit more of this kind of reference. > > 5). Postconditions in Section 7.7 > > Is there a way to find out what is the value of the server specific > limit? Also, is it possible for the client to ask "fail request if > you find more than N responses". > Similar feature is occasionally useful in LDAP searches. No, although a server could put human-readable text inside the postcondition. Generally WebDAV doesn't have this kind of feature and we'd be loathe to invent it for CalDAV. > > 6). In Section 7.7.1 > > In the second to the last line of the first paragraph: duplicated > word "only". > > 7). In Section 9.5.6 > > >Description: The CALDAV:limit-recurrence-set XML element specifies > >that for a give calendaring REPORT request the server MUST only > >return the "master component" as well as the "overridden > >components" that specify one of more recurrence instances whose > ... > Should the be "zero or more"? > Or does presence of the CALDAV:limit-recurrence-set in a request > means that the server is not to return the "master component" if no > "overridden component" falls between the specified dates? The limit-recurrence-set element does not affect whether or not the master component gets returned. That master component is always returned if the resource matches the filter. We'll try to spell this out in a little more detail. > > 8). In Section 9.6.1: > > I think the last word of the Description should be "match", not > "matches" (as "elements" is plural). thx > > 9). In Section 9.6.4 > > CALDAV:text-match XML element seems like a good place for using > comparators! > A boolean "caseless" parameter doesn't seem to be sufficient. > > Also, why the requirement to follow [UNICODE4] is only a SHOULD and > not a MUST? > I think MUST is needed to get consistent behavior. > (Maybe you want to say that support for ascii-only case mapping is > mandatory and for the rest of Unicode optional?) In the long run I agree with you about comparators, but they're not in common use in WebDAV yet. We do need to clarify the Unicode requirements. > > Alexey > thanks, Lisa --Apple-Mail-23-431584174 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1 Thanks for these comments = Alexey.=A0 Some responses inline:

Begin forwarded = message:

From: Alexey Melnikov <alexey.melnikov@isode.com>= ;
Date: April 3, 2006 12:18:51 PM = PDT
To: Lisa Dusseault <lisa@osafoundation.org>, = Cyrus Daboo <cyrus@daboo.name>, Bernard = Desruisseaux <bernard.desruisseaux@oracl= e.com>
Subject: Comments on CalDav-10 = draft

=
Overall I find the document to be well written and = full of implementation details. Some comments (and question), mostly = nitpicking, below.
(Please excuse my = ignorance, I didn't have time to absorb all WebDav and Calendar related = drafts/RFCs. Kindly point me to the right documents.)

1). In = Section 5.2.3 (CALDAV:supported-calendar-component-set)

> =A0 =A0 be defined on any = calendar collection to specify restrictions on
> =A0 =A0 = the calendar component types that calendar object resources = may
> =A0 =A0 contain in a calendar = collection.

Is this (or rather the example listing both VEVENT = and VTODO) in contradiction with the first sentence in section = 4.1?:

No, but we were probably a = little misleading there.=A0 We will try to clarify in 4.1 that a = collection can contain more than one kind of component, but only one = component per resource.


>contain more than one type = of calendar components (e.g., VEVENT,
>components which MUST be = specified for each unique TZID parameter

2). In = Section 5.3.3

>Server MUST support the use of non-standard = components, properties
>and parameters in = calendar object resources stored via the PUT
>method.
>Servers = MAY reject any non-standandard components, properties and
>parameters that have specific values in calendar = object resources
>stored via the PUT = method.

It sounds like the MAY gives license to ignore the = MUST, if the server decides that any value is not = allowed.

You're right. we'll rework = this.


3). In = Section 7.5:

Item # 2:

>Return the "master = component" and only the "overridden
>time range.

Maybe it = is just me, but what is "currently overlap" and "originally = overlap"?

It's a particularly = confusing part of iCalendar. We'll try to define those phrases in = context.


4). = Preconditions in Section 7.7 (CALDAV:calendar-query report):

I'm sure you're right and = we'll try to do a bit more of this kind of = reference.=A0=A0


5). = Postconditions in Section 7.7

Is there a way to find out what = is the value of the server specific limit? Also, is it possible for the = client to ask "fail request if you find more than N = responses".
Similar feature is occasionally = useful in LDAP searches.

No, although a server could = put human-readable text inside the postcondition.=A0 Generally WebDAV = doesn't have this kind of feature and we'd be loathe to invent it for = CalDAV.


6). In = Section 7.7.1

In the second to the last line of the first = paragraph: duplicated word "only".

7). In Section 9.5.6

>that for a give calendaring = REPORT request the server MUST only
>return = the "master component" as well as the "overridden
>components" that specify one of more recurrence = instances whose
...
Should = the be "zero or more"?
Or does presence of the = CALDAV:limit-recurrence-set in a request means that the server is not to = return the "master component" if no "overridden component" falls between = the specified dates?

The limit-recurrence-set = element does not affect whether or not the master component gets = returned.=A0 That master component is always returned if the resource = matches the filter.=A0 =A0We'll try to spell this out in a little more = detail.


8). In = Section 9.6.1:

I think the last word of the Description should be = "match", not "matches" (as "elements" is = plural).

thx


9). In Section 9.6.4

A boolean "caseless" parameter = doesn't seem to be sufficient.

Also, why the requirement to = follow [UNICODE4] is only a SHOULD and not a MUST?
I think MUST is needed to get consistent = behavior.
(Maybe you want to say that = support for ascii-only case mapping is mandatory and for the rest of = Unicode optional?)

In the long run I agree = with you about comparators, but they're not in common use in WebDAV = yet.=A0 We do need to clarify the Unicode = requirements.


Lisa


= --Apple-Mail-23-431584174--