From w3c-dist-auth-request@w3.org Sat Mar 1 09:35:42 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA05965 for ; Sat, 1 Mar 2003 09:35:41 -0500 (EST) Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id h21ES3m07258; Sat, 1 Mar 2003 09:28:03 -0500 (EST) Resent-Date: Sat, 1 Mar 2003 09:28:03 -0500 (EST) Resent-Message-Id: <200303011428.h21ES3m07258@frink.w3.org> Received: from tux.w3.org (tux [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id h21ES1I07222 for ; Sat, 1 Mar 2003 09:28:01 -0500 (EST) Received: from sus-ma1it31.rational.com (sus-ma1it31.rational.com [130.213.73.33]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id JAA05080 for ; Sat, 1 Mar 2003 09:28:01 -0500 Received: from sus-ma1it00.rational.com ([10.64.1.25]) by 10.64.1.33 with InterScan Messaging Security Suite; Sat, 01 Mar 2003 09:11:33 -0500 Received: by sus-ma1it00.rational.com with Internet Mail Service (5.5.2656.59) id ; Sat, 1 Mar 2003 09:27:30 -0500 Message-ID: From: "Clemm, Geoff" To: WebDAV Date: Sat, 1 Mar 2003 09:27:29 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain Subject: RE: bind draft issues X-Archived-At: http://www.w3.org/mid/E4F2D33B98DF7E4880884B9F0E6FDEE2021C54EB@SUS-MA1IT01 Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7292 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: From: Brian Korver [mailto:briank@xythos.com] I like to bring up a couple of issues that I've found with the bind draft. I'll post more comprehensive comments on the draft in a subsequent email. Define "Resource" The term "resource" should be defined in the draft. I imagine the definition is something along the lines of "all content and all properties associated with that content (including live and dead properties), but which does not include properties associated with URIs." As indicated in section 1.1, the bind draft inherits all terminology from RFC2518, and therefore this section only includes definitions that refine or extend those from RFC2518 (which in turn inherits definitions from RFC2616). The bind draft does not modify the definition of resource inherited from RFC2518. Bindings and Locks The relationship between bindings and locks is missing from the draft. I think the behavior of locks and the lock methods should be fully specified in this draft. RFC2518bis is in the process of finalizing the behavior of locks, and we do not want the bind draft to say anything that conflicts with this. Instead, we will make sure that the locking model in RFC2518bis clearly defines locking behavior in the presence of multiple bindings. URL Properties The behavior of other URL properties (in addition to locks) should be fully specified, for instance the display-name property. I'm not aware of the binding protocol causing any change to the behavior of the properties defined by 2518. Also note that a resource has properties, not a URL. Move and Delete The spec states that move and delete are merely operations on bindings. At the very least, this is inconsistent with 2518, How is this inconsistent with 2518 (other than the use of terminology not defined in 2518)? but I also think that the draft doesn't adequately address any of the issues that come up when the server goes to "reclaim system resources." I would expect most servers to reclaim said resources during move and delete. The protocol explicitly leaves those decisions up to the server implementation, since different servers have made (and need to make) different choices wrt how system resources are reclaimed. For example, a versioning server will probably reclaim very few resources, since most of the resources are being maintained as history. Operations not Atomic None of the operations specified should be required to be atomic. I'd prefer SHOULD NOT myself. This is especially true for any operation that involves deleting collections. Atomic operations are one of the primary purposes of the binding protocol. A server that cannot maintain atomic MOVE/DELETE/BIND operations is not capable of supporting the bind protocol. Cheers, Geoff From w3c-dist-auth-request@w3.org Sat Mar 1 17:27:12 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA18909 for ; Sat, 1 Mar 2003 17:27:12 -0500 (EST) Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id h21MKRt15468; Sat, 1 Mar 2003 17:20:27 -0500 (EST) Resent-Date: Sat, 1 Mar 2003 17:20:27 -0500 (EST) Resent-Message-Id: <200303012220.h21MKRt15468@frink.w3.org> Received: from tux.w3.org (tux [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id h21MKPI15436 for ; Sat, 1 Mar 2003 17:20:25 -0500 (EST) Received: from sunbelt.seagull.net (user34.net540.or.sprint-hsd.net [65.40.225.34]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id RAA28512 for ; Sat, 1 Mar 2003 17:20:24 -0500 Received: (mail@localhost) by sunbelt.seagull.net (8.9.3) id OAA10406 sender nn683849@smallcue.com for w3c-dist-auth@w3.org; Sat, 1 Mar 2003 14:20:18 -0800 Received: from e6.ny.us.ibm.com (e6.ny.us.ibm.com [32.97.182.106]) by sunbelt.seagull.net (8.9.3) with ESMTP id OAA10390 sender obsfucated@us.ibm.com; Sat, 1 Mar 2003 14:20:17 -0800 Received: from northrelay04.pok.ibm.com (northrelay04.pok.ibm.com [9.56.224.206]) by e6.ny.us.ibm.com (8.12.7/8.12.2) with ESMTP id h21MJjGM047710; Sat, 1 Mar 2003 17:19:45 -0500 Received: from d01ml243.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by northrelay04.pok.ibm.com (8.12.3/NCO/VER6.5) with ESMTP id h21MJh4A156838; Sat, 1 Mar 2003 17:19:43 -0500 To: "Jim Whitehead" Cc: "WebDAV" X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: Jason Crawford Date: Sat, 1 Mar 2003 17:15:00 -0500 X-MIMETrack: Serialize by Router on D01ML243/01/M/IBM(Release 6.0.1 [IBM]|February 28, 2003) at 03/01/2003 17:19:42 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Subject: Re: FW: ETags again - basic question X-Archived-At: http://www.w3.org/mid/OF63161C49.2D150D21-ON85256CDC.0077B9F3@us.ibm.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7293 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Okay, I'll take a stab at this one... > When does an (strong) etag of a resource change? > > 1) when the content of a resource has changed (e.g. after a PUT) > 2) when one of the properties has changed (e.g. after a PROPPATCH) > 3) in both cases 1) and 2) I think the answer is whenever the GET response changes. So for most resources the answer is almost always (1), not (2) or (3). If you have a live resource that is dependent on other info, the answer might vary. ------------------------------------------ Phone: 914-784-7569, ccjason@us.ibm.com I do not check nn621779@smallcue.com From w3c-dist-auth-request@w3.org Sat Mar 1 22:24:20 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA23716 for ; Sat, 1 Mar 2003 22:24:20 -0500 (EST) Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id h2236EJ22712; Sat, 1 Mar 2003 22:06:14 -0500 (EST) Resent-Date: Sat, 1 Mar 2003 22:06:14 -0500 (EST) Resent-Message-Id: <200303020306.h2236EJ22712@frink.w3.org> Received: from tux.w3.org (tux [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id h2236CI22676 for ; Sat, 1 Mar 2003 22:06:12 -0500 (EST) Received: from mail.xythos.com ([206.14.210.116]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id WAA27857 for ; Sat, 1 Mar 2003 22:06:12 -0500 Received: from ravms by mail.xythos.com with mail-ok (Exim 3.36 #3) id 18pJo0-000390-00 for w3c-dist-auth@w3c.org; Sun, 02 Mar 2003 03:06:24 +0000 Received: from [198.144.203.248] (helo=xythoslap) by mail.xythos.com with asmtp (Exim 3.36 #3) id 18pJnz-00038p-00 for w3c-dist-auth@w3c.org; Sun, 02 Mar 2003 03:06:23 +0000 From: "Lisa Dusseault" To: "Webdav WG" Date: Sat, 1 Mar 2003 19:06:10 -0800 Message-ID: <03e601c2e068$ad6eb710$f8cb90c6@xythoslap> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4024 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal Old-X-Envelope-To: w3c-dist-auth@w3c.org Subject: New draft - 2518bis 03 X-Archived-At: http://www.w3.org/mid/03e601c2e068$ad6eb710$f8cb90c6@xythoslap Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7294 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit I've made some more changes to 2518bis, reflecting recent consensus as far as I was able. http://www.sharemation.com/~milele/public/dav/draft-ietf-webdav-rfc2518b is.doc http://www.sharemation.com/~milele/public/dav/draft-ietf-webdav-rfc2518b is-03.txt http://www.sharemation.com/~milele/public/dav/RFC2518%20Changes.doc The doc version can have revision viewing turned on to see exactly what has changed since 02. The Changes document lists all changes since the beginning of working on 2518bis. Lisa From w3c-dist-auth-request@w3.org Sun Mar 2 08:54:53 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA11276 for ; Sun, 2 Mar 2003 08:54:53 -0500 (EST) Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id h22DmOd00287; Sun, 2 Mar 2003 08:48:24 -0500 (EST) Resent-Date: Sun, 2 Mar 2003 08:48:24 -0500 (EST) Resent-Message-Id: <200303021348.h22DmOd00287@frink.w3.org> Received: from tux.w3.org (tux [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id h22DmLI00254 for ; Sun, 2 Mar 2003 08:48:21 -0500 (EST) Received: from sus-ma1it31.rational.com (sus-ma1it31.rational.com [130.213.73.33]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id IAA19186 for ; Sun, 2 Mar 2003 08:48:21 -0500 Received: from sus-ma1it00.rational.com ([10.64.1.25]) by 10.64.1.33 with InterScan Messaging Security Suite; Sun, 02 Mar 2003 08:31:51 -0500 Received: by sus-ma1it00.rational.com with Internet Mail Service (5.5.2656.59) id ; Sun, 2 Mar 2003 08:47:50 -0500 Message-ID: From: "Clemm, Geoff" To: WebDAV Date: Sun, 2 Mar 2003 08:47:49 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain Subject: RE: FW: ETags again - basic question X-Archived-At: http://www.w3.org/mid/E4F2D33B98DF7E4880884B9F0E6FDEE2021C5527@SUS-MA1IT01 Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7295 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Note that some file-based implementations store the dead properties as part of the file content and use the file content information to compute the etag. So an interoperable client can only make the following assumptions: - If the resource content changes, the strong etag MUST change. - If the properties change, the strong etag MAY change. Cheers, Geoff -----Original Message----- From: Jason Crawford [mailto:nn683849@smallcue.com] Sent: Saturday, March 01, 2003 5:15 PM To: Jim Whitehead Cc: WebDAV Subject: Re: FW: ETags again - basic question Okay, I'll take a stab at this one... > When does an (strong) etag of a resource change? > > 1) when the content of a resource has changed (e.g. after a PUT) > 2) when one of the properties has changed (e.g. after a PROPPATCH) > 3) in both cases 1) and 2) I think the answer is whenever the GET response changes. So for most resources the answer is almost always (1), not (2) or (3). If you have a live resource that is dependent on other info, the answer might vary. ------------------------------------------ Phone: 914-784-7569, ccjason@us.ibm.com I do not check nn621779@smallcue.com From w3c-dist-auth-request@w3.org Mon Mar 3 13:57:17 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07620 for ; Mon, 3 Mar 2003 13:57:17 -0500 (EST) Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id h23IvIH02659; Mon, 3 Mar 2003 13:57:18 -0500 (EST) Resent-Date: Mon, 3 Mar 2003 13:57:18 -0500 (EST) Resent-Message-Id: <200303031857.h23IvIH02659@frink.w3.org> Received: from tux.w3.org (tux [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id h23IvEI02627 for ; Mon, 3 Mar 2003 13:57:14 -0500 (EST) Received: from mail.xythos.com ([206.14.210.116]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id NAA31087 for ; Mon, 3 Mar 2003 13:57:13 -0500 Received: from ravms by mail.xythos.com with mail-ok (Exim 3.36 #3) id 18pv8G-0006Wt-00 for w3c-dist-auth@w3.org; Mon, 03 Mar 2003 18:57:48 +0000 Received: from ip-216-36-77-241.dsl.sjc.megapath.net ([216.36.77.241] helo=xythos.com) by mail.xythos.com with asmtp (Exim 3.36 #3) id 18pv8G-0006Wi-00 for w3c-dist-auth@w3.org; Mon, 03 Mar 2003 18:57:48 +0000 Date: Mon, 3 Mar 2003 10:57:08 -0800 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) From: Brian Korver To: WebDAV Content-Transfer-Encoding: 7bit In-Reply-To: Message-Id: X-Mailer: Apple Mail (2.551) Old-X-Envelope-To: w3c-dist-auth@w3.org Subject: Re: Bindings and Locks (was: bind draft issues) X-Archived-At: http://www.w3.org/mid/EF3AA708-4DA9-11D7-8A8F-000393751598@xythos.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7296 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit On Saturday, March 1, 2003, at 06:27 AM, Clemm, Geoff wrote: > Bindings and Locks > > The relationship between bindings and locks is missing > from the draft. I think the behavior of locks and the > lock methods should be fully specified in this draft. > > RFC2518bis is in the process of finalizing the behavior of > locks, and we do not want the bind draft to say anything that > conflicts with this. Instead, we will make sure that the > locking model in RFC2518bis clearly defines locking behavior > in the presence of multiple bindings. It probably isn't a good idea to introduce a dependency such as this, especially since 2518bis doesn't have any notion of bindings. I don't believe that the binding document can move forward. -brian briank@xythos.com From w3c-dist-auth-request@w3.org Mon Mar 3 14:10:55 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08206 for ; Mon, 3 Mar 2003 14:10:55 -0500 (EST) Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id h23JBxo05143; Mon, 3 Mar 2003 14:11:59 -0500 (EST) Resent-Date: Mon, 3 Mar 2003 14:11:59 -0500 (EST) Resent-Message-Id: <200303031911.h23JBxo05143@frink.w3.org> Received: from tux.w3.org (tux [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id h23JBvI05111 for ; Mon, 3 Mar 2003 14:11:57 -0500 (EST) Received: from mail.xythos.com ([206.14.210.116]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id OAA04607 for ; Mon, 3 Mar 2003 14:11:56 -0500 Received: from ravms by mail.xythos.com with mail-ok (Exim 3.36 #3) id 18pvMY-0006vP-00 for w3c-dist-auth@w3.org; Mon, 03 Mar 2003 19:12:34 +0000 Received: from ip-216-36-77-241.dsl.sjc.megapath.net ([216.36.77.241] helo=xythos.com) by mail.xythos.com with asmtp (Exim 3.36 #3) id 18pvMX-0006vE-00 for w3c-dist-auth@w3.org; Mon, 03 Mar 2003 19:12:33 +0000 Date: Mon, 3 Mar 2003 11:11:54 -0800 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) From: Brian Korver To: WebDAV Content-Transfer-Encoding: 7bit In-Reply-To: Message-Id: X-Mailer: Apple Mail (2.551) Old-X-Envelope-To: w3c-dist-auth@w3.org Subject: Re: bind draft issues X-Archived-At: http://www.w3.org/mid/FF1337D1-4DAB-11D7-8A8F-000393751598@xythos.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7297 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit On Saturday, March 1, 2003, at 06:27 AM, Clemm, Geoff wrote: > > From: Brian Korver [mailto:briank@xythos.com] > > URL Properties > > The behavior of other URL properties (in addition to > locks) should be fully specified, for instance the > display-name property. > > I'm not aware of the binding protocol causing any change > to the behavior of the properties defined by 2518. Also > note that a resource has properties, not a URL. Geoff, URLs have properties to. Think about how DAV:lockdiscovery works in the face of COPY/MOVE, or DAV:displayname for that matter. Regarding this issue, I was not suggesting that the problem is that the binding protocol changed the behavior of properties, just that the behavior needs to be fully specified. Do you feel that 2518 does fully specify the behavior of URL properties? -brian briank@xythos.com From w3c-dist-auth-request@w3.org Mon Mar 3 14:27:20 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08777 for ; Mon, 3 Mar 2003 14:27:20 -0500 (EST) Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id h23JSbi07803; Mon, 3 Mar 2003 14:28:37 -0500 (EST) Resent-Date: Mon, 3 Mar 2003 14:28:37 -0500 (EST) Resent-Message-Id: <200303031928.h23JSbi07803@frink.w3.org> Received: from tux.w3.org (tux [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id h23JSZI07764 for ; Mon, 3 Mar 2003 14:28:35 -0500 (EST) Received: from mail.xythos.com ([206.14.210.116]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id OAA10393 for ; Mon, 3 Mar 2003 14:28:35 -0500 Received: from ravms by mail.xythos.com with mail-ok (Exim 3.36 #3) id 18pvcf-0007H6-00 for w3c-dist-auth@w3.org; Mon, 03 Mar 2003 19:29:13 +0000 Received: from ip-216-36-77-241.dsl.sjc.megapath.net ([216.36.77.241] helo=xythos.com) by mail.xythos.com with asmtp (Exim 3.36 #3) id 18pvce-0007Gv-00 for w3c-dist-auth@w3.org; Mon, 03 Mar 2003 19:29:12 +0000 Date: Mon, 3 Mar 2003 11:28:32 -0800 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) From: Brian Korver To: WebDAV Content-Transfer-Encoding: 7bit In-Reply-To: Message-Id: <523B96A0-4DAE-11D7-8A8F-000393751598@xythos.com> X-Mailer: Apple Mail (2.551) Old-X-Envelope-To: w3c-dist-auth@w3.org Subject: Re: Move and Delete (was: bind draft issues) X-Archived-At: http://www.w3.org/mid/523B96A0-4DAE-11D7-8A8F-000393751598@xythos.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7298 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit On Saturday, March 1, 2003, at 06:27 AM, Clemm, Geoff wrote: > > From: Brian Korver [mailto:briank@xythos.com] > > Move and Delete > > The spec states that move and delete are merely operations > on bindings. At the very least, this is inconsistent with > 2518, > > How is this inconsistent with 2518 (other than the use of > terminology not defined in 2518)? 2418 correctly states that MOVE (and COPY) also may involve a DELETE with "Depth: infinity" operation in the case of overwrite. DELETE also operates on more than bindings. Consider, for instance, what happens to locks. > > but I also think that the draft doesn't adequately > address any of the issues that come up when the server > goes to "reclaim system resources." I would expect most > servers to reclaim said resources during move and delete. > > The protocol explicitly leaves those decisions up to the > server implementation, since different servers have made > (and need to make) different choices wrt how system resources > are reclaimed. For example, a versioning server will > probably reclaim very few resources, since most of the > resources are being maintained as history. My reading of the document is different, so the language should be cleaned up so that it doesn't sound like it is prohibiting the semantics spelled out in 2518. Would it help if I provided that text? -brian briank@xythos.com From w3c-dist-auth-request@w3.org Mon Mar 3 14:34:30 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09172 for ; Mon, 3 Mar 2003 14:34:30 -0500 (EST) Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id h23JZh309704; Mon, 3 Mar 2003 14:35:43 -0500 (EST) Resent-Date: Mon, 3 Mar 2003 14:35:43 -0500 (EST) Resent-Message-Id: <200303031935.h23JZh309704@frink.w3.org> Received: from tux.w3.org (tux [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id h23JZgI09672 for ; Mon, 3 Mar 2003 14:35:42 -0500 (EST) Received: from mail.xythos.com ([206.14.210.116]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id OAA12733 for ; Mon, 3 Mar 2003 14:35:42 -0500 Received: from ravms by mail.xythos.com with mail-ok (Exim 3.36 #3) id 18pvjU-0007RK-00 for w3c-dist-auth@w3.org; Mon, 03 Mar 2003 19:36:16 +0000 Received: from ip-216-36-77-241.dsl.sjc.megapath.net ([216.36.77.241] helo=xythos.com) by mail.xythos.com with asmtp (Exim 3.36 #3) id 18pvjT-0007R9-00 for w3c-dist-auth@w3.org; Mon, 03 Mar 2003 19:36:15 +0000 Date: Mon, 3 Mar 2003 11:35:36 -0800 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) From: Brian Korver To: WebDAV Content-Transfer-Encoding: 7bit In-Reply-To: Message-Id: <4E999B08-4DAF-11D7-8A8F-000393751598@xythos.com> X-Mailer: Apple Mail (2.551) Old-X-Envelope-To: w3c-dist-auth@w3.org Subject: Re: Operations not Atomic (was: bind draft issues) X-Archived-At: http://www.w3.org/mid/4E999B08-4DAF-11D7-8A8F-000393751598@xythos.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7299 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit On Saturday, March 1, 2003, at 06:27 AM, Clemm, Geoff wrote: > > From: Brian Korver [mailto:briank@xythos.com] > > Operations not Atomic > > None of the operations specified should be required > to be atomic. I'd prefer SHOULD NOT myself. This is > especially true for any operation that involves deleting > collections. > > Atomic operations are one of the primary purposes of the > binding protocol. A server that cannot maintain atomic > MOVE/DELETE/BIND operations is not capable of supporting > the bind protocol. Geoff, I disagree strongly. Nothing should be stated to prohibit atomic operations, but the spec should leave this decision up to implementors. There can be perfectly valid reasons why a server vendor might want to provide normal filesystem semantics to users. -brian briank@xythos.com From w3c-dist-auth-request@w3.org Mon Mar 3 15:19:50 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11508 for ; Mon, 3 Mar 2003 15:19:50 -0500 (EST) Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id h23KKf015894; Mon, 3 Mar 2003 15:20:41 -0500 (EST) Resent-Date: Mon, 3 Mar 2003 15:20:41 -0500 (EST) Resent-Message-Id: <200303032020.h23KKf015894@frink.w3.org> Received: from tux.w3.org (tux [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id h23KKeI15862 for ; Mon, 3 Mar 2003 15:20:40 -0500 (EST) Received: from sunbelt.seagull.net (user34.net540.or.sprint-hsd.net [65.40.225.34]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id PAA23816 for ; Mon, 3 Mar 2003 15:20:38 -0500 Received: (mail@localhost) by sunbelt.seagull.net (8.9.3) id MAA20843 sender nn683849@smallcue.com for w3c-dist-auth@w3.org; Mon, 3 Mar 2003 12:20:37 -0800 Received: from e4.ny.us.ibm.com (e4.ny.us.ibm.com [32.97.182.104]) by sunbelt.seagull.net (8.9.3) with ESMTP id MAA20827 sender obsfucated@us.ibm.com; Mon, 3 Mar 2003 12:20:35 -0800 Received: from northrelay04.pok.ibm.com (northrelay04.pok.ibm.com [9.56.224.206]) by e4.ny.us.ibm.com (8.12.8/8.12.2) with ESMTP id h23KK34V066046; Mon, 3 Mar 2003 15:20:03 -0500 Received: from d01ml243.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by northrelay04.pok.ibm.com (8.12.3/NCO/VER6.5) with ESMTP id h23KK0lT038442; Mon, 3 Mar 2003 15:20:01 -0500 To: Brian Korver Cc: WebDAV X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: Jason Crawford Date: Mon, 3 Mar 2003 15:16:17 -0500 X-MIMETrack: Serialize by Router on D01ML243/01/M/IBM(Release 6.0.1 [IBM]|February 28, 2003) at 03/03/2003 15:20:00 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Subject: Re: bind draft issues X-Archived-At: http://www.w3.org/mid/OFE0451125.B334AA18-ON05256CDE.006E5515@us.ibm.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7300 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: > URLs have properties too. Think about how DAV:lockdiscovery > works in the face of COPY/MOVE, I'm not sure I understand what you're refering to, but it is true that we protect the URL of a lock. And it's true that the influence of a lock causes there to be a DAV:lockdiscovery property shown on the resource, but I'm not sure I'd call that property a "URL property". (It's more complex than that.) > or DAV:displayname for that matter. DAV:displayname is a property of the resource in every way that I can think of. > Regarding this issue, I was not suggesting that the problem > is that the binding protocol changed the behavior of properties, > just that the behavior needs to be fully specified. Do > you feel that 2518 does fully specify the behavior of > URL properties? Hold that thought until we resolve what it is you mean by URL properties... ------------------------------------------ Phone: 914-784-7569, ccjason@us.ibm.com I do not check nn621779@smallcue.com From w3c-dist-auth-request@w3.org Mon Mar 3 15:31:35 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11732 for ; Mon, 3 Mar 2003 15:31:35 -0500 (EST) Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id h23KWcT18007; Mon, 3 Mar 2003 15:32:38 -0500 (EST) Resent-Date: Mon, 3 Mar 2003 15:32:38 -0500 (EST) Resent-Message-Id: <200303032032.h23KWcT18007@frink.w3.org> Received: from tux.w3.org (tux [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id h23KWaI17975 for ; Mon, 3 Mar 2003 15:32:36 -0500 (EST) Received: from sus-ma1it31.rational.com (sus-ma1it31.rational.com [130.213.73.33]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id PAA28004 for ; Mon, 3 Mar 2003 15:32:35 -0500 Received: from sus-ma1it00.rational.com ([10.64.1.25]) by 10.64.1.33 with InterScan Messaging Security Suite; Mon, 03 Mar 2003 15:15:56 -0500 Received: by sus-ma1it00.rational.com with Internet Mail Service (5.5.2656.59) id ; Mon, 3 Mar 2003 15:31:58 -0500 Message-ID: From: "Clemm, Geoff" To: WebDAV Date: Mon, 3 Mar 2003 15:31:56 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain Subject: RE: Bindings and Locks (was: bind draft issues) X-Archived-At: http://www.w3.org/mid/E4F2D33B98DF7E4880884B9F0E6FDEE25ED6C8@SUS-MA1IT01 Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7301 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: OK, since the bind protocol only introduces one new method, with simple behavior in the presence of locks, I'm happy to add the appropriate precondition to the BIND definition. In particular, I propose to add the following precondition: (DAV:locked-update-allowed): if the collection identified by the Request-URL is write-locked, then the appropriate token MUST be specified in an If request header. Anyone object to this addition? Cheers, Geoff -----Original Message----- From: Brian Korver [mailto:briank@xythos.com] Sent: Monday, March 03, 2003 1:57 PM To: WebDAV Subject: Re: Bindings and Locks (was: bind draft issues) On Saturday, March 1, 2003, at 06:27 AM, Clemm, Geoff wrote: > Bindings and Locks > > The relationship between bindings and locks is missing > from the draft. I think the behavior of locks and the > lock methods should be fully specified in this draft. > > RFC2518bis is in the process of finalizing the behavior of > locks, and we do not want the bind draft to say anything that > conflicts with this. Instead, we will make sure that the > locking model in RFC2518bis clearly defines locking behavior > in the presence of multiple bindings. It probably isn't a good idea to introduce a dependency such as this, especially since 2518bis doesn't have any notion of bindings. I don't believe that the binding document can move forward. -brian briank@xythos.com From w3c-dist-auth-request@w3.org Mon Mar 3 15:39:48 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12077 for ; Mon, 3 Mar 2003 15:39:47 -0500 (EST) Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id h23Keuu19592; Mon, 3 Mar 2003 15:40:56 -0500 (EST) Resent-Date: Mon, 3 Mar 2003 15:40:56 -0500 (EST) Resent-Message-Id: <200303032040.h23Keuu19592@frink.w3.org> Received: from tux.w3.org (tux [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id h23KesI19556 for ; Mon, 3 Mar 2003 15:40:54 -0500 (EST) Received: from sunbelt.seagull.net (user34.net540.or.sprint-hsd.net [65.40.225.34]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id PAA30152 for ; Mon, 3 Mar 2003 15:40:53 -0500 Received: (mail@localhost) by sunbelt.seagull.net (8.9.3) id MAA22863 sender nn683849@smallcue.com for w3c-dist-auth@w3.org; Mon, 3 Mar 2003 12:40:51 -0800 Received: from e4.ny.us.ibm.com (e4.ny.us.ibm.com [32.97.182.104]) by sunbelt.seagull.net (8.9.3) with ESMTP id MAA22847 sender obsfucated@us.ibm.com; Mon, 3 Mar 2003 12:40:50 -0800 Received: from northrelay04.pok.ibm.com (northrelay04.pok.ibm.com [9.56.224.206]) by e4.ny.us.ibm.com (8.12.8/8.12.2) with ESMTP id h23KeJ4V059976; Mon, 3 Mar 2003 15:40:19 -0500 Received: from d01ml243.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by northrelay04.pok.ibm.com (8.12.3/NCO/VER6.5) with ESMTP id h23KeGlT075646; Mon, 3 Mar 2003 15:40:17 -0500 To: Brian Korver Cc: WebDAV X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: Jason Crawford Date: Mon, 3 Mar 2003 15:37:41 -0500 X-MIMETrack: Serialize by Router on D01ML243/01/M/IBM(Release 6.0.1 [IBM]|February 28, 2003) at 03/03/2003 15:40:17 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Subject: Re: Move and Delete (was: bind draft issues) X-Archived-At: http://www.w3.org/mid/OF6A059F5E.66C86EA5-ON05256CDE.006F8305@us.ibm.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7302 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: On Monday, 03/03/2003 at 11:28 PST, Brian Korver wrote: > On Saturday, March 1, 2003, at 06:27 AM, Clemm, Geoff wrote: > > > > From: Brian Korver [mailto:briank@xythos.com] > > > > Move and Delete > > > > The spec states that move and delete are merely operations > > on bindings. At the very least, this is inconsistent with > > 2518, > > > > How is this inconsistent with 2518 (other than the use of > > terminology not defined in 2518)? > > 2518 correctly states that MOVE (and COPY) also may involve > a DELETE with "Depth: infinity" operation in the case of > overwrite. It supports that. What you're possibly refering to is the fact that 2518 let's the DELETE on a collection to delete some of the children and abort before removing the colection itself and without backing out what it did. In the Bind Spec, there is no requirement to unbind those child resources and in many cases you definitely don't want to do that. You only have to unbind the collection. There is no partial DELETE. You just have to unmap that collection. Whether that reclaims resources is a different matter. > DELETE also operates on more than bindings. Consider, > for instance, what happens to locks. Yes, you can't break a lock without having the proper lock token submitted, but you're not allowed to break the lock, but abort the DELETE. Nor are you somehow allowed to unmap the resource but not remove the lock. (At least not yet. :-)) > My reading of the document is different, so the language > should be cleaned up so that it doesn't sound like it is > prohibiting the semantics spelled out in 2518. Would it > help if I provided that text? I actually just read it for the first time in a long time and it's very clear that it doesn't speak of freeing up resources. Except to say that you "MAY" do it. ------------------------------------------ Phone: 914-784-7569, ccjason@us.ibm.com I do not check nn621779@smallcue.com From w3c-dist-auth-request@w3.org Mon Mar 3 15:45:47 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12220 for ; Mon, 3 Mar 2003 15:45:47 -0500 (EST) Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id h23KklC21013; Mon, 3 Mar 2003 15:46:47 -0500 (EST) Resent-Date: Mon, 3 Mar 2003 15:46:47 -0500 (EST) Resent-Message-Id: <200303032046.h23KklC21013@frink.w3.org> Received: from tux.w3.org (tux [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id h23KklI20981 for ; Mon, 3 Mar 2003 15:46:47 -0500 (EST) Received: from sunbelt.seagull.net (user34.net540.or.sprint-hsd.net [65.40.225.34]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id PAA31554 for ; Mon, 3 Mar 2003 15:46:46 -0500 Received: (mail@localhost) by sunbelt.seagull.net (8.9.3) id MAA23293 sender nn683849@smallcue.com for w3c-dist-auth@w3.org; Mon, 3 Mar 2003 12:46:42 -0800 Received: from e2.ny.us.ibm.com (e2.ny.us.ibm.com [32.97.182.102]) by sunbelt.seagull.net (8.9.3) with ESMTP id MAA23268 sender obsfucated@us.ibm.com; Mon, 3 Mar 2003 12:46:40 -0800 Received: from northrelay04.pok.ibm.com (northrelay04.pok.ibm.com [9.56.224.206]) by e2.ny.us.ibm.com (8.12.8/8.12.2) with ESMTP id h23Kk9WX061480; Mon, 3 Mar 2003 15:46:09 -0500 Received: from d01ml243.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by northrelay04.pok.ibm.com (8.12.3/NCO/VER6.5) with ESMTP id h23Kk7lT038498; Mon, 3 Mar 2003 15:46:07 -0500 To: Brian Korver Cc: w3c-dist-auth-request@w3.org, WebDAV X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: Jason Crawford Date: Mon, 3 Mar 2003 15:45:50 -0500 X-MIMETrack: Serialize by Router on D01ML243/01/M/IBM(Release 6.0.1 [IBM]|February 28, 2003) at 03/03/2003 15:46:07 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Subject: Re: Operations not Atomic (was: bind draft issues) X-Archived-At: http://www.w3.org/mid/OFCACC5E3B.80E2B200-ON05256CDE.00718CBC@us.ibm.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7303 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: On Monday, 03/03/2003 at 11:35 PST, Brian Korver wrote: > I disagree strongly. Nothing should be stated to prohibit > atomic operations, but the spec should leave this decision > up to implementors. There can be perfectly valid reasons > why a server vendor might want to provide normal filesystem > semantics to users. What non-atomic file system semantics in particular are you refering to here that you feel should be acceptable but are prohibited. ------------------------------------------ Phone: 914-784-7569, ccjason@us.ibm.com I do not check nn621779@smallcue.com From w3c-dist-auth-request@w3.org Mon Mar 3 15:46:57 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12280 for ; Mon, 3 Mar 2003 15:46:56 -0500 (EST) Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id h23Km6H21193; Mon, 3 Mar 2003 15:48:06 -0500 (EST) Resent-Date: Mon, 3 Mar 2003 15:48:06 -0500 (EST) Resent-Message-Id: <200303032048.h23Km6H21193@frink.w3.org> Received: from tux.w3.org (tux [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id h23Km5I21157 for ; Mon, 3 Mar 2003 15:48:05 -0500 (EST) Received: from sus-ma1it31.rational.com (sus-ma1it31.rational.com [130.213.73.33]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id PAA31810 for ; Mon, 3 Mar 2003 15:48:05 -0500 Received: from sus-ma1it00.rational.com ([10.64.1.25]) by 10.64.1.33 with InterScan Messaging Security Suite; Mon, 03 Mar 2003 15:31:31 -0500 Received: by sus-ma1it00.rational.com with Internet Mail Service (5.5.2656.59) id ; Mon, 3 Mar 2003 15:47:34 -0500 Message-ID: From: "Clemm, Geoff" To: WebDAV Date: Mon, 3 Mar 2003 15:47:32 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain Subject: RE: bind draft issues X-Archived-At: http://www.w3.org/mid/E4F2D33B98DF7E4880884B9F0E6FDEE25ED6CA@SUS-MA1IT01 Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7304 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: I do not understand what you mean by a URL having a property. A URL is just a string. It has no properties, no state, nothing other than a sequence of characters. A URL is mapped by a server to a resource, and that resource has state. A lock can "protect" a URL mapping, but that does not give a URL a WebDAV property. So at least as far as bindings are concerned, I feel that 2518 does fully specify the behavior of the properties defined by 2518. Cheers, Geoff -----Original Message----- From: Brian Korver [mailto:briank@xythos.com] Sent: Monday, March 03, 2003 2:12 PM To: WebDAV Subject: Re: bind draft issues On Saturday, March 1, 2003, at 06:27 AM, Clemm, Geoff wrote: > > From: Brian Korver [mailto:briank@xythos.com] > > URL Properties > > The behavior of other URL properties (in addition to > locks) should be fully specified, for instance the > display-name property. > > I'm not aware of the binding protocol causing any change > to the behavior of the properties defined by 2518. Also > note that a resource has properties, not a URL. Geoff, URLs have properties to. Think about how DAV:lockdiscovery works in the face of COPY/MOVE, or DAV:displayname for that matter. Regarding this issue, I was not suggesting that the problem is that the binding protocol changed the behavior of properties, just that the behavior needs to be fully specified. Do you feel that 2518 does fully specify the behavior of URL properties? -brian briank@xythos.com From w3c-dist-auth-request@w3.org Mon Mar 3 16:05:46 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12920 for ; Mon, 3 Mar 2003 16:05:46 -0500 (EST) Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id h23L6MN23320; Mon, 3 Mar 2003 16:06:22 -0500 (EST) Resent-Date: Mon, 3 Mar 2003 16:06:22 -0500 (EST) Resent-Message-Id: <200303032106.h23L6MN23320@frink.w3.org> Received: from tux.w3.org (tux [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id h23L6LI23288 for ; Mon, 3 Mar 2003 16:06:21 -0500 (EST) Received: from sunbelt.seagull.net (user34.net540.or.sprint-hsd.net [65.40.225.34]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id QAA03132 for ; Mon, 3 Mar 2003 16:06:20 -0500 Received: (mail@localhost) by sunbelt.seagull.net (8.9.3) id NAA24365 sender nn683849@smallcue.com for w3c-dist-auth@w3.org; Mon, 3 Mar 2003 13:06:19 -0800 Received: from e4.ny.us.ibm.com (e4.ny.us.ibm.com [32.97.182.104]) by sunbelt.seagull.net (8.9.3) with ESMTP id NAA24349 sender obsfucated@us.ibm.com; Mon, 3 Mar 2003 13:06:17 -0800 Received: from northrelay04.pok.ibm.com (northrelay04.pok.ibm.com [9.56.224.206]) by e4.ny.us.ibm.com (8.12.8/8.12.2) with ESMTP id h23L5k4V036914; Mon, 3 Mar 2003 16:05:46 -0500 Received: from d01ml243.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by northrelay04.pok.ibm.com (8.12.3/NCO/VER6.5) with ESMTP id h23L5hlT059766; Mon, 3 Mar 2003 16:05:44 -0500 To: "Clemm, Geoff" Cc: WebDAV X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: Jason Crawford Date: Mon, 3 Mar 2003 16:00:42 -0500 X-MIMETrack: Serialize by Router on D01ML243/01/M/IBM(Release 6.0.1 [IBM]|February 28, 2003) at 03/03/2003 16:05:43 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Subject: RE: Bindings and Locks (was: bind draft issues) X-Archived-At: http://www.w3.org/mid/OF98E84CD9.B88E3DB1-ON05256CDE.0072F2DC@us.ibm.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7305 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: On Monday, 03/03/2003 at 03:31 EST, "Clemm, Geoff" wrote: > OK, since the bind protocol only introduces one > new method, with simple behavior in the presence of > locks, I'm happy to add the appropriate precondition > to the BIND definition. In particular, I propose to > add the following precondition: > > (DAV:locked-update-allowed): if the collection identified by the Request-URL > is write-locked, then the appropriate token MUST be specified in an If > request header. > > Anyone object to this addition? I don't object, but I feel if we do add this, we'll also have to list the possibility of the binding being protected by a lock in the subtree. I think that isn't covered by the wording above. I'm not sure if you want to reword this one or add another precondition. J. From w3c-dist-auth-request@w3.org Mon Mar 3 16:23:39 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13340 for ; Mon, 3 Mar 2003 16:23:38 -0500 (EST) Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id h23LOpa25722; Mon, 3 Mar 2003 16:24:51 -0500 (EST) Resent-Date: Mon, 3 Mar 2003 16:24:51 -0500 (EST) Resent-Message-Id: <200303032124.h23LOpa25722@frink.w3.org> Received: from tux.w3.org (tux [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id h23LOoI25690 for ; Mon, 3 Mar 2003 16:24:50 -0500 (EST) Received: from sus-ma1it31.rational.com (sus-ma1it31.rational.com [130.213.73.33]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id QAA08354 for ; Mon, 3 Mar 2003 16:24:50 -0500 Received: from sus-ma1it00.rational.com ([10.64.1.25]) by 10.64.1.33 with InterScan Messaging Security Suite; Mon, 03 Mar 2003 16:08:16 -0500 Received: by sus-ma1it00.rational.com with Internet Mail Service (5.5.2656.59) id ; Mon, 3 Mar 2003 16:24:19 -0500 Message-ID: From: "Clemm, Geoff" To: WebDAV Date: Mon, 3 Mar 2003 16:24:18 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain Subject: RE: Bindings and Locks (was: bind draft issues) X-Archived-At: http://www.w3.org/mid/E4F2D33B98DF7E4880884B9F0E6FDEE25ED6CB@SUS-MA1IT01 Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7306 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Good point! I assume by "the binding being protected", you mean in the case where the binding already exists, and the Overwrite:T header is specifed? If so, I agree that we need another precondition to handle this. How about: (DAV:locked-overwrite-allowed): If the collection already contains a binding with the specified path segment, and if that binding is protected by a write-lock, then the appropriate token MUST be specified in an If request header. Cheers, Geoff -----Original Message----- From: Jason Crawford [mailto:nn683849@smallcue.com] Sent: Monday, March 03, 2003 4:01 PM To: Clemm, Geoff Cc: WebDAV Subject: RE: Bindings and Locks (was: bind draft issues) On Monday, 03/03/2003 at 03:31 EST, "Clemm, Geoff" wrote: > OK, since the bind protocol only introduces one > new method, with simple behavior in the presence of > locks, I'm happy to add the appropriate precondition > to the BIND definition. In particular, I propose to > add the following precondition: > > (DAV:locked-update-allowed): if the collection identified by the Request-URL > is write-locked, then the appropriate token MUST be specified in an If > request header. > > Anyone object to this addition? I don't object, but I feel if we do add this, we'll also have to list the possibility of the binding being protected by a lock in the subtree. I think that isn't covered by the wording above. I'm not sure if you want to reword this one or add another precondition. J. From w3c-dist-auth-request@w3.org Mon Mar 3 16:35:52 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13733 for ; Mon, 3 Mar 2003 16:35:52 -0500 (EST) Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id h23Lb0j28555; Mon, 3 Mar 2003 16:37:00 -0500 (EST) Resent-Date: Mon, 3 Mar 2003 16:37:00 -0500 (EST) Resent-Message-Id: <200303032137.h23Lb0j28555@frink.w3.org> Received: from tux.w3.org (tux [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id h23LawI28523 for ; Mon, 3 Mar 2003 16:36:58 -0500 (EST) Received: from sunbelt.seagull.net (user34.net540.or.sprint-hsd.net [65.40.225.34]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id QAA12118 for ; Mon, 3 Mar 2003 16:36:58 -0500 Received: (mail@localhost) by sunbelt.seagull.net (8.9.3) id NAA27067 sender nn683849@smallcue.com for w3c-dist-auth@w3.org; Mon, 3 Mar 2003 13:36:57 -0800 Received: from e1.ny.us.ibm.com (e1.ny.us.ibm.com [32.97.182.101]) by sunbelt.seagull.net (8.9.3) with ESMTP id NAA27051 sender obsfucated@us.ibm.com; Mon, 3 Mar 2003 13:36:55 -0800 Received: from northrelay04.pok.ibm.com (northrelay04.pok.ibm.com [9.56.224.206]) by e1.ny.us.ibm.com (8.12.8/8.12.2) with ESMTP id h23LaOn5090630; Mon, 3 Mar 2003 16:36:24 -0500 Received: from d01ml243.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by northrelay04.pok.ibm.com (8.12.3/NCO/VER6.5) with ESMTP id h23LaMlT161598; Mon, 3 Mar 2003 16:36:22 -0500 To: "Clemm, Geoff" Cc: WebDAV X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: Jason Crawford Date: Mon, 3 Mar 2003 16:35:21 -0500 X-MIMETrack: Serialize by Router on D01ML243/01/M/IBM(Release 6.0.1 [IBM]|February 28, 2003) at 03/03/2003 16:36:22 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Subject: RE: Bindings and Locks (was: bind draft issues) X-Archived-At: http://www.w3.org/mid/OF801B9C87.420ED413-ON05256CDE.0076632B@us.ibm.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7307 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: On Monday, 03/03/2003 at 04:24 EST, "Clemm, Geoff" wrote: > Good point! > > I assume by "the binding being protected", you mean in the > case where the binding already exists, and the Overwrite:T > header is specifed? If so, I agree that we need another > precondition to handle this. How about: > > (DAV:locked-overwrite-allowed): If the collection already contains a binding > with the specified path segment, and if that binding is protected by a > write-lock, then the appropriate token MUST be specified in an If request > header. I suppose that covers it. Hopefully the reader understands the situations that that covers. One question though... does it have to be a write-lock? I suspect this precondition even applies to non-write locks. From w3c-dist-auth-request@w3.org Mon Mar 3 16:44:36 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13933 for ; Mon, 3 Mar 2003 16:44:36 -0500 (EST) Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id h23LjRB29215; Mon, 3 Mar 2003 16:45:27 -0500 (EST) Resent-Date: Mon, 3 Mar 2003 16:45:27 -0500 (EST) Resent-Message-Id: <200303032145.h23LjRB29215@frink.w3.org> Received: from tux.w3.org (tux [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id h23LjQI29180 for ; Mon, 3 Mar 2003 16:45:26 -0500 (EST) Received: from sus-ma1it31.rational.com (sus-ma1it31.rational.com [130.213.73.33]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id QAA14370 for ; Mon, 3 Mar 2003 16:45:26 -0500 Received: from sus-ma1it00.rational.com ([10.64.1.25]) by 10.64.1.33 with InterScan Messaging Security Suite; Mon, 03 Mar 2003 16:28:42 -0500 Received: by sus-ma1it00.rational.com with Internet Mail Service (5.5.2656.59) id ; Mon, 3 Mar 2003 16:44:17 -0500 Message-ID: From: "Clemm, Geoff" To: WebDAV Date: Mon, 3 Mar 2003 16:44:16 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain Subject: RE: Move and Delete (was: bind draft issues) X-Archived-At: http://www.w3.org/mid/E4F2D33B98DF7E4880884B9F0E6FDEE25ED6CD@SUS-MA1IT01 Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7308 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: To emphasize an earlier comment, it is true that the bind protocol places constraints on how a server is allowed to implement the DELETE and MOVE methods. In particular, a server that supports the bind protocol is not allowed to do a partial MOVE or a partial DELETE (even though 2518 allows it). In addition, section 2.3 does identify a way in which the bind protocol differs from the semantics defined in 2518, i.e.: Section 8.6.1 of [RFC2518] states that during DELETE processing, a server "MUST remove any URI for the resource identified by the Request-URI from collections which contain it as a member." Servers that support bindings MUST NOT follow this requirement." A 2518 server that cannot (or does not want to) support the bind protocol constraints can certainly choose to not support the bind protocol. Cheers, Geoff -----Original Message----- From: Jason Crawford [mailto:nn683849@smallcue.com] On Monday, Brian Korver wrote: > On Saturday, March 1, 2003, at 06:27 AM, Clemm, Geoff wrote: > > > > From: Brian Korver [mailto:briank@xythos.com] > > > > Move and Delete > > > > The spec states that move and delete are merely operations > > on bindings. At the very least, this is inconsistent with > > 2518, > > > > How is this inconsistent with 2518 (other than the use of > > terminology not defined in 2518)? > > 2518 correctly states that MOVE (and COPY) also may involve > a DELETE with "Depth: infinity" operation in the case of > overwrite. It supports that. What you're possibly refering to is the fact that 2518 let's the DELETE on a collection to delete some of the children and abort before removing the colection itself and without backing out what it did. In the Bind Spec, there is no requirement to unbind those child resources and in many cases you definitely don't want to do that. You only have to unbind the collection. There is no partial DELETE. You just have to unmap that collection. Whether that reclaims resources is a different matter. > DELETE also operates on more than bindings. Consider, > for instance, what happens to locks. Yes, you can't break a lock without having the proper lock token submitted, but you're not allowed to break the lock, but abort the DELETE. Nor are you somehow allowed to unmap the resource but not remove the lock. (At least not yet. :-)) > My reading of the document is different, so the language should be > cleaned up so that it doesn't sound like it is prohibiting the > semantics spelled out in 2518. Would it help if I provided that > text? I actually just read it for the first time in a long time and it's very clear that it doesn't speak of freeing up resources. Except to say that you "MAY" do it. From w3c-dist-auth-request@w3.org Mon Mar 3 16:49:44 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14163 for ; Mon, 3 Mar 2003 16:49:44 -0500 (EST) Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id h23LobJ29715; Mon, 3 Mar 2003 16:50:37 -0500 (EST) Resent-Date: Mon, 3 Mar 2003 16:50:37 -0500 (EST) Resent-Message-Id: <200303032150.h23LobJ29715@frink.w3.org> Received: from tux.w3.org (tux [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id h23LoaI29683 for ; Mon, 3 Mar 2003 16:50:36 -0500 (EST) Received: from sus-ma1it31.rational.com (sus-ma1it31.rational.com [130.213.73.33]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id QAA15806 for ; Mon, 3 Mar 2003 16:50:36 -0500 Received: from sus-ma1it00.rational.com ([10.64.1.25]) by 10.64.1.33 with InterScan Messaging Security Suite; Mon, 03 Mar 2003 16:34:03 -0500 Received: by sus-ma1it00.rational.com with Internet Mail Service (5.5.2656.59) id ; Mon, 3 Mar 2003 16:50:05 -0500 Message-ID: From: "Clemm, Geoff" To: WebDAV Date: Mon, 3 Mar 2003 16:50:04 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain Subject: RE: Bindings and Locks (was: bind draft issues) X-Archived-At: http://www.w3.org/mid/E4F2D33B98DF7E4880884B9F0E6FDEE25ED6CE@SUS-MA1IT01 Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7309 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: From: Jason Crawford [mailto:nn683849@smallcue.com] On Monday, "Clemm, Geoff" wrote: > > How about: > > (DAV:locked-overwrite-allowed): If the collection already > contains a binding with the specified path segment, and if that > binding is protected by a write-lock, then the appropriate token > MUST be specified in an If request header. I suppose that covers it. Hopefully the reader understands the situations that that covers. I wouldn't want to tug any harder on that particular string (i.e. defining precisely what "protect" means), or else we'd end up needing to include most of the GULP (Grand Unified Locking Proposal) in the binding draft. One question though... does it have to be a write-lock? I suspect this precondition even applies to non-write locks. Since we currently only have definitions of the semantics of write locks, I try to avoid speculating on what semantics non-write locks may have some day. Cheers, Geoff From w3c-dist-auth-request@w3.org Mon Mar 3 17:07:16 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14671 for ; Mon, 3 Mar 2003 17:07:16 -0500 (EST) Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id h23M8JF01439; Mon, 3 Mar 2003 17:08:19 -0500 (EST) Resent-Date: Mon, 3 Mar 2003 17:08:19 -0500 (EST) Resent-Message-Id: <200303032208.h23M8JF01439@frink.w3.org> Received: from tux.w3.org (tux [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id h23M8EI01405 for ; Mon, 3 Mar 2003 17:08:14 -0500 (EST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by tux.w3.org (8.9.3/8.9.3) with SMTP id RAA21530 for ; Mon, 3 Mar 2003 17:08:13 -0500 Received: (qmail 24856 invoked by uid 0); 3 Mar 2003 22:08:09 -0000 Received: from p3EE24713.dip.t-dialin.net (HELO lisa) (62.226.71.19) by mail.gmx.net (mp019-rz3) with SMTP; 3 Mar 2003 22:08:09 -0000 From: "Julian Reschke" To: "Clemm, Geoff" , "WebDAV" Date: Mon, 3 Mar 2003 23:08:02 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Subject: RE: Move and Delete (was: bind draft issues) X-Archived-At: http://www.w3.org/mid/JIEGINCHMLABHJBIGKBCCEDJGKAA.julian.reschke@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7310 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Clemm, Geoff > Sent: Monday, March 03, 2003 10:44 PM > To: WebDAV > Subject: RE: Move and Delete (was: bind draft issues) > > > > To emphasize an earlier comment, it is true that the bind protocol > places constraints on how a server is allowed to implement the DELETE > and MOVE methods. In particular, a server that supports the bind > protocol is not allowed to do a partial MOVE or a partial DELETE (even > though 2518 allows it). > ... Good catch. I remember that we discussed that at some point of time, but it seems it was never added to the issues list. Our server indeed is able to support the BIND method and live properties with all their semantics, yet won't do an atomic DELETE on collections. I agree that *technically* a server that properly handles bindings *could* do atomic deletes, but in reality, there may be reasons why you don't *want* to. Therefore, I'd like the spec not to require a specific behaviou, or, as a minimum, change the MUST to a SHOULD. Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Mon Mar 3 17:08:55 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14732 for ; Mon, 3 Mar 2003 17:08:55 -0500 (EST) Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id h23MA1N01865; Mon, 3 Mar 2003 17:10:01 -0500 (EST) Resent-Date: Mon, 3 Mar 2003 17:10:01 -0500 (EST) Resent-Message-Id: <200303032210.h23MA1N01865@frink.w3.org> Received: from tux.w3.org (tux [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id h23M9uI01830 for ; Mon, 3 Mar 2003 17:09:56 -0500 (EST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by tux.w3.org (8.9.3/8.9.3) with SMTP id RAA22311 for ; Mon, 3 Mar 2003 17:09:56 -0500 Received: (qmail 13668 invoked by uid 0); 3 Mar 2003 22:09:19 -0000 Received: from p3EE24713.dip.t-dialin.net (HELO lisa) (62.226.71.19) by mail.gmx.net (mp012-rz3) with SMTP; 3 Mar 2003 22:09:19 -0000 From: "Julian Reschke" To: "Brian Korver" , "WebDAV" Date: Mon, 3 Mar 2003 23:09:08 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) In-Reply-To: <4E999B08-4DAF-11D7-8A8F-000393751598@xythos.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Subject: RE: Operations not Atomic (was: bind draft issues) X-Archived-At: http://www.w3.org/mid/JIEGINCHMLABHJBIGKBCGEDJGKAA.julian.reschke@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7311 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Brian Korver > Sent: Monday, March 03, 2003 8:36 PM > To: WebDAV > Subject: Re: Operations not Atomic (was: bind draft issues) > > > > On Saturday, March 1, 2003, at 06:27 AM, Clemm, Geoff wrote: > > > > From: Brian Korver [mailto:briank@xythos.com] > > > > Operations not Atomic > > > > None of the operations specified should be required > > to be atomic. I'd prefer SHOULD NOT myself. This is > > especially true for any operation that involves deleting > > collections. > > > > Atomic operations are one of the primary purposes of the > > binding protocol. A server that cannot maintain atomic > > MOVE/DELETE/BIND operations is not capable of supporting > > the bind protocol. > > Geoff, > > I disagree strongly. Nothing should be stated to prohibit > atomic operations, but the spec should leave this decision > up to implementors. There can be perfectly valid reasons > why a server vendor might want to provide normal filesystem > semantics to users. Brian, I can follow for DELETE (see separate mail), but I'm at a loss about how MOVE and BIND can be non-atomic. Could you please explain? Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Mon Mar 3 17:13:45 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14846 for ; Mon, 3 Mar 2003 17:13:45 -0500 (EST) Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id h23MEeO02633; Mon, 3 Mar 2003 17:14:40 -0500 (EST) Resent-Date: Mon, 3 Mar 2003 17:14:40 -0500 (EST) Resent-Message-Id: <200303032214.h23MEeO02633@frink.w3.org> Received: from tux.w3.org (tux [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id h23MEZI02576 for ; Mon, 3 Mar 2003 17:14:35 -0500 (EST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by tux.w3.org (8.9.3/8.9.3) with SMTP id RAA23893 for ; Mon, 3 Mar 2003 17:14:33 -0500 Received: (qmail 31236 invoked by uid 0); 3 Mar 2003 22:13:58 -0000 Received: from p3EE24713.dip.t-dialin.net (HELO lisa) (62.226.71.19) by mail.gmx.net (mp020-rz3) with SMTP; 3 Mar 2003 22:13:58 -0000 From: "Julian Reschke" To: "Brian Korver" , "WebDAV" Date: Mon, 3 Mar 2003 23:13:48 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Subject: RE: bind draft issues X-Archived-At: http://www.w3.org/mid/JIEGINCHMLABHJBIGKBCCEDKGKAA.julian.reschke@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7312 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Brian Korver > Sent: Monday, March 03, 2003 8:12 PM > To: WebDAV > Subject: Re: bind draft issues > > > > On Saturday, March 1, 2003, at 06:27 AM, Clemm, Geoff wrote: > > > > From: Brian Korver [mailto:briank@xythos.com] > > > > URL Properties > > > > The behavior of other URL properties (in addition to > > locks) should be fully specified, for instance the > > display-name property. > > > > I'm not aware of the binding protocol causing any change > > to the behavior of the properties defined by 2518. Also > > note that a resource has properties, not a URL. > > Geoff, > > URLs have properties to. Think about how DAV:lockdiscovery > works in the face of COPY/MOVE, or DAV:displayname for that > matter. Brian, properties are *never* on URLs, they are always on the resource. So if you have multiple bindings to the same resource, a PROPFIND on each of these bindings should yield the same results. So DAV:lockdiscovery and DAV:displayname indeed do *not* depend on the binding to which the PROPFIND is applied. > Regarding this issue, I was not suggesting that the problem > is that the binding protocol changed the behavior of properties, > just that the behavior needs to be fully specified. Do > you feel that 2518 does fully specify the behavior of > URL properties? :-) If we agree on that there are no "URL properties", there's nothing that needs to be defined. Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Mon Mar 3 17:14:19 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14864 for ; Mon, 3 Mar 2003 17:14:19 -0500 (EST) Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id h23MFOg02944; Mon, 3 Mar 2003 17:15:24 -0500 (EST) Resent-Date: Mon, 3 Mar 2003 17:15:24 -0500 (EST) Resent-Message-Id: <200303032215.h23MFOg02944@frink.w3.org> Received: from tux.w3.org (tux [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id h23MFKI02912 for ; Mon, 3 Mar 2003 17:15:20 -0500 (EST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by tux.w3.org (8.9.3/8.9.3) with SMTP id RAA24167 for ; Mon, 3 Mar 2003 17:15:20 -0500 Received: (qmail 14779 invoked by uid 0); 3 Mar 2003 22:14:43 -0000 Received: from p3EE24713.dip.t-dialin.net (HELO lisa) (62.226.71.19) by mail.gmx.net (mp019-rz3) with SMTP; 3 Mar 2003 22:14:43 -0000 From: "Julian Reschke" To: "Brian Korver" , "WebDAV" Date: Mon, 3 Mar 2003 23:14:35 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Subject: RE: Bindings and Locks (was: bind draft issues) X-Archived-At: http://www.w3.org/mid/JIEGINCHMLABHJBIGKBCEEDKGKAA.julian.reschke@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7313 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Brian Korver > Sent: Monday, March 03, 2003 7:57 PM > To: WebDAV > Subject: Re: Bindings and Locks (was: bind draft issues) > > > > On Saturday, March 1, 2003, at 06:27 AM, Clemm, Geoff wrote: > > Bindings and Locks > > > > The relationship between bindings and locks is missing > > from the draft. I think the behavior of locks and the > > lock methods should be fully specified in this draft. > > > > RFC2518bis is in the process of finalizing the behavior of > > locks, and we do not want the bind draft to say anything that > > conflicts with this. Instead, we will make sure that the > > locking model in RFC2518bis clearly defines locking behavior > > in the presence of multiple bindings. > > It probably isn't a good idea to introduce a dependency > such as this, especially since 2518bis doesn't have any > notion of bindings. I don't believe that the binding > document can move forward. Of course does RFC2518 have a notion of bindings. What it doesn't have is a method to *create* multiple bindings, and the live properties to inspect them. Bindings always have been there implicitly. All the BIND spec adds is the machinery to create them, and to discover some more information about them. Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Mon Mar 3 18:35:28 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA17917 for ; Mon, 3 Mar 2003 18:35:27 -0500 (EST) Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id h23NZcJ27045; Mon, 3 Mar 2003 18:35:38 -0500 (EST) Resent-Date: Mon, 3 Mar 2003 18:35:38 -0500 (EST) Resent-Message-Id: <200303032335.h23NZcJ27045@frink.w3.org> Received: from tux.w3.org (tux [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id h23NZaI27009 for ; Mon, 3 Mar 2003 18:35:36 -0500 (EST) Received: from sus-ma1it31.rational.com (sus-ma1it31.rational.com [130.213.73.33]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id SAA17398 for ; Mon, 3 Mar 2003 18:35:35 -0500 Received: from sus-ma1it00.rational.com ([10.64.1.25]) by 10.64.1.33 with InterScan Messaging Security Suite; Mon, 03 Mar 2003 18:19:00 -0500 Received: by sus-ma1it00.rational.com with Internet Mail Service (5.5.2656.59) id ; Mon, 3 Mar 2003 18:34:13 -0500 Message-ID: From: "Clemm, Geoff" To: WebDAV Date: Mon, 3 Mar 2003 18:34:11 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Move and Delete (was: bind draft issues) X-Archived-At: http://www.w3.org/mid/E4F2D33B98DF7E4880884B9F0E6FDEE25ED6D0@SUS-MA1IT01 Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7314 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: "Best effort" deletion is forbidden by the bind protocol, because it can cause a DELETE in one collection to cause a change in another collection, and this kind of "deletion side effect" was something we explicitly were trying to avoid. For example, suppose /henry/has-friend/jeff and /jim/has-friend/jeff were bindings to the same collection, JEFF, and JEFF has a binding named "wife" to a resource, MARI. Now suppose henry gets mad at jeff, and issues a "DELETE /henry/has-friend/jeff" request. But suppose at that moment someone else has a Depth:0 lock on the /henry/has-friend collection. The result of a "best effort" deletion is the removal of the "wife" binding from JEFF. That may be OK if you were just updating the information accessible from /henry (he isn't JEFF's friend anymore, and he's happy to purge as much information about JEFF as he can), but with multiple bindings, "best effort" deletion has now trashed the JEFF object in all the other contexts in which it is still visible (and the folks that still are his friends are still interested in that information). So we're not saying that "best effort deletion" is always a bad thing, but we are saying that "best effort deletion" is a bad thing when you care about multiple bindings to the same resource. Cheers, Geoff -----Original Message----- From: Julian Reschke [mailto:julian.reschke@gmx.de] Sent: Monday, March 03, 2003 5:08 PM To: Clemm, Geoff; WebDAV Subject: RE: Move and Delete (was: bind draft issues) > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Clemm, Geoff > Sent: Monday, March 03, 2003 10:44 PM > To: WebDAV > Subject: RE: Move and Delete (was: bind draft issues) > > > > To emphasize an earlier comment, it is true that the bind protocol > places constraints on how a server is allowed to implement the DELETE > and MOVE methods. In particular, a server that supports the bind > protocol is not allowed to do a partial MOVE or a partial DELETE (even > though 2518 allows it). > ... Good catch. I remember that we discussed that at some point of time, but it seems it was never added to the issues list. Our server indeed is able to support the BIND method and live properties with all their semantics, yet won't do an atomic DELETE on collections. I agree that *technically* a server that properly handles bindings *could* do atomic deletes, but in reality, there may be reasons why you don't *want* to. Therefore, I'd like the spec not to require a specific behaviou, or, as a minimum, change the MUST to a SHOULD. Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Mon Mar 3 19:22:49 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA19189 for ; Mon, 3 Mar 2003 19:22:49 -0500 (EST) Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id h240Ntu05656; Mon, 3 Mar 2003 19:23:55 -0500 (EST) Resent-Date: Mon, 3 Mar 2003 19:23:55 -0500 (EST) Resent-Message-Id: <200303040023.h240Ntu05656@frink.w3.org> Received: from tux.w3.org (tux [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id h240NsI05610 for ; Mon, 3 Mar 2003 19:23:54 -0500 (EST) Received: from mail.xythos.com ([206.14.210.116]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id TAA28183 for ; Mon, 3 Mar 2003 19:23:53 -0500 Received: from ravms by mail.xythos.com with mail-ok (Exim 3.36 #3) id 18q0EU-00041M-00; Tue, 04 Mar 2003 00:24:34 +0000 Received: from [216.36.77.241] (helo=xythoslap) by mail.xythos.com with asmtp (Exim 3.36 #3) id 18q0EU-00041B-00; Tue, 04 Mar 2003 00:24:34 +0000 From: "Lisa Dusseault" To: "'Clemm, Geoff'" , "'WebDAV'" Date: Mon, 3 Mar 2003 16:23:53 -0800 Message-ID: <051701c2e1e4$56550240$f8cb90c6@xythoslap> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4024 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal In-Reply-To: Old-X-Envelope-To: gclemm@rational.com, w3c-dist-auth@w3.org Subject: RE: FW: ETags again - basic question X-Archived-At: http://www.w3.org/mid/051701c2e1e4$56550240$f8cb90c6@xythoslap Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7315 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit I strongly recommend servers to change Etag only when the entity changes. After all, it's the "Entity" tag. Here are two to three practical reasons. If the ETag changes when the properties change, then: 1. Clients who have cached based on the ETag will download the file again unnecessarily. Perf problem only. 2. Clients who are editing without a lock (including clients who lost their lock accidentally due to network conditions) must compare Etag to see if it's safe to upload their changes. This edit will fail and confuse the user if somebody else changed the properties and makes their upload fail. 3. Clients who are editing with a lock might issue a PROPPATCH, then try to issue a PUT with an ETag validation. If the ETag has changed due to the PROPPATCH, then the client will be very confused whether or not the file can be overwritten. The lock still appears to be there, yet the ETag changed -- how did that happen? Geoff's comments are perfectly correct for client implementors -- it's hard to predict how servers actually modify ETags. There's no rule saying the content is actually different just because the ETag is different. Lisa > -----Original Message----- > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org] On Behalf Of Clemm, Geoff > Sent: Sunday, March 02, 2003 5:48 AM > To: WebDAV > Subject: RE: FW: ETags again - basic question > > > > Note that some file-based implementations store the dead > properties as part > of the file content and use the file content information to > compute the > etag. So an interoperable client can only make the following > assumptions: > > - If the resource content changes, the strong etag MUST change. > - If the properties change, the strong etag MAY change. > > Cheers, > Geoff > > -----Original Message----- > From: Jason Crawford [mailto:nn683849@smallcue.com] > Sent: Saturday, March 01, 2003 5:15 PM > To: Jim Whitehead > Cc: WebDAV > Subject: Re: FW: ETags again - basic question > > > > > > > Okay, I'll take a stab at this one... > > > When does an (strong) etag of a resource change? > > > > 1) when the content of a resource has changed (e.g. after a PUT) > > 2) when one of the properties has changed (e.g. after a PROPPATCH) > > 3) in both cases 1) and 2) > > I think the answer is whenever the GET response changes. So for most > resources the answer is almost always (1), not (2) or (3). > If you have a > live > resource that is dependent on other info, the answer might vary. > > > ------------------------------------------ > Phone: 914-784-7569, ccjason@us.ibm.com > I do not check nn621779@smallcue.com > > From w3c-dist-auth-request@w3.org Mon Mar 3 19:46:03 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA19562 for ; Mon, 3 Mar 2003 19:46:03 -0500 (EST) Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id h240koG09908; Mon, 3 Mar 2003 19:46:50 -0500 (EST) Resent-Date: Mon, 3 Mar 2003 19:46:50 -0500 (EST) Resent-Message-Id: <200303040046.h240koG09908@frink.w3.org> Received: from tux.w3.org (tux [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id h240knI09876 for ; Mon, 3 Mar 2003 19:46:49 -0500 (EST) Received: from dream.darwin.nasa.gov (betlik.darwin.nasa.gov [198.123.160.11]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id TAA03434 for ; Mon, 3 Mar 2003 19:46:48 -0500 Received: from cse.ucsc.edu (paperweight.darwin.nasa.gov [198.123.160.27]) by dream.darwin.nasa.gov ( -- Info omitted by ASANI Solutions, LLC.) with ESMTP id h240kbh16599 for ; Mon, 3 Mar 2003 16:46:37 -0800 (PST) Message-ID: <3E63F76D.6050607@cse.ucsc.edu> Date: Mon, 03 Mar 2003 16:46:37 -0800 From: Elias Sinderson Reply-To: "'WebDAV'" User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.0.1) Gecko/20020920 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "'WebDAV'" References: <051701c2e1e4$56550240$f8cb90c6@xythoslap> Content-Type: multipart/alternative; boundary="------------070900070703030704090601" Subject: Re: FW: ETags again - basic question X-Archived-At: http://www.w3.org/mid/3E63F76D.6050607@cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7316 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: --------------070900070703030704090601 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Can we include language to this effect in the specification? To do otherwise is to invite interop issues. I haven't read the latest draft closely, my apologies if you've already inserted the appropriate verbiage somewhere. I think this is an important issue that both client and server implementers need to understand fully. Cheers, Elias Lisa Dusseault wrote: >I strongly recommend servers to change Etag only when the entity >changes. After all, it's the "Entity" tag. Here are two to three >practical reasons. > >If the ETag changes when the properties change, then: >1. Clients who have cached based on the ETag will download the file >again unnecessarily. Perf problem only. >2. Clients who are editing without a lock (including clients who lost >their lock accidentally due to network conditions) must compare Etag to >see if it's safe to upload their changes. This edit will fail and >confuse the user if somebody else changed the properties and makes their >upload fail. >3. Clients who are editing with a lock might issue a PROPPATCH, then >try to issue a PUT with an ETag validation. If the ETag has changed due >to the PROPPATCH, then the client will be very confused whether or not >the file can be overwritten. The lock still appears to be there, yet the >ETag changed -- how did that happen? > >Geoff's comments are perfectly correct for client implementors -- it's >hard to predict how servers actually modify ETags. There's no rule >saying the content is actually different just because the ETag is >different. > >Lisa > > > >>-----Original Message----- >>From: w3c-dist-auth-request@w3.org >>[mailto:w3c-dist-auth-request@w3.org] On Behalf Of Clemm, Geoff >>Sent: Sunday, March 02, 2003 5:48 AM >>To: WebDAV >>Subject: RE: FW: ETags again - basic question >> >> >> >>Note that some file-based implementations store the dead >>properties as part >>of the file content and use the file content information to >>compute the >>etag. So an interoperable client can only make the following >>assumptions: >> >>- If the resource content changes, the strong etag MUST change. >>- If the properties change, the strong etag MAY change. >> >>Cheers, >>Geoff >> >>-----Original Message----- >>From: Jason Crawford [mailto:nn683849@smallcue.com] >>Sent: Saturday, March 01, 2003 5:15 PM >>To: Jim Whitehead >>Cc: WebDAV >>Subject: Re: FW: ETags again - basic question >> >> >> >> >> >> >>Okay, I'll take a stab at this one... >> >> >> >>>When does an (strong) etag of a resource change? >>> >>>1) when the content of a resource has changed (e.g. after a PUT) >>>2) when one of the properties has changed (e.g. after a PROPPATCH) >>>3) in both cases 1) and 2) >>> >>> >>I think the answer is whenever the GET response changes. So for most >>resources the answer is almost always (1), not (2) or (3). >>If you have a >>live >>resource that is dependent on other info, the answer might vary. >> >> >>------------------------------------------ >>Phone: 914-784-7569, ccjason@us.ibm.com >>I do not check nn621779@smallcue.com >> >> >> >> > > > --------------070900070703030704090601 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Can we include language to this effect in the specification? To do otherwise is to invite interop issues. I haven't read the latest draft closely, my apologies if you've already inserted the appropriate verbiage somewhere. I think this is an important issue that both client and server implementers need to understand fully.


Cheers,
Elias



Lisa Dusseault wrote:
I strongly recommend servers to change Etag only when the entity
changes. After all, it's the "Entity" tag.  Here are two to three
practical reasons.

If the ETag changes when the properties change, then:
1.  Clients who have cached based on the ETag will download the file
again unnecessarily. Perf problem only.
2.  Clients who are editing without a lock (including clients who lost
their lock accidentally due to network conditions) must compare Etag to
see if it's safe to upload their changes.  This edit will fail and
confuse the user if somebody else changed the properties and makes their
upload fail.
3.  Clients who are editing with a lock might issue a PROPPATCH, then
try to issue a PUT with an ETag validation. If the ETag has changed due
to the PROPPATCH, then the client will be very confused whether or not
the file can be overwritten. The lock still appears to be there, yet the
ETag changed -- how did that happen?

Geoff's comments are perfectly correct for client implementors -- it's
hard to predict how servers actually modify ETags. There's no rule
saying the content is actually different just because the ETag is
different.

Lisa

  
-----Original Message-----
From: w3c-dist-auth-request@w3.org 
[mailto:w3c-dist-auth-request@w3.org] On Behalf Of Clemm, Geoff
Sent: Sunday, March 02, 2003 5:48 AM
To: WebDAV
Subject: RE: FW: ETags again - basic question



Note that some file-based implementations store the dead 
properties as part
of the file content and use the file content information to 
compute the
etag.  So an interoperable client can only make the following 
assumptions:

- If the resource content changes, the strong etag MUST change.
- If the properties change, the strong etag MAY change.

Cheers,
Geoff 

-----Original Message-----
From: Jason Crawford [mailto:nn683849@smallcue.com]
Sent: Saturday, March 01, 2003 5:15 PM
To: Jim Whitehead
Cc: WebDAV
Subject: Re: FW: ETags again - basic question






Okay, I'll take a stab at this one...

    
When does an (strong) etag of a resource change?

1) when the content of a resource has changed (e.g. after a PUT)
2) when one of the properties has changed (e.g. after a PROPPATCH)
3) in both cases 1) and 2)
      
I think the answer is whenever the GET response changes.  So for most
resources the answer is almost always (1), not (2) or (3).   
If you have a
live
resource that is dependent on other info, the answer might vary.


------------------------------------------
Phone: 914-784-7569,   ccjason@us.ibm.com
I do not check nn621779@smallcue.com

--------------070900070703030704090601-- From w3c-dist-auth-request@w3.org Mon Mar 3 19:48:30 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA19602 for ; Mon, 3 Mar 2003 19:48:30 -0500 (EST) Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id h240nhk10444; Mon, 3 Mar 2003 19:49:43 -0500 (EST) Resent-Date: Mon, 3 Mar 2003 19:49:43 -0500 (EST) Resent-Message-Id: <200303040049.h240nhk10444@frink.w3.org> Received: from tux.w3.org (tux [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id h240ngI10412 for ; Mon, 3 Mar 2003 19:49:42 -0500 (EST) Received: from sunbelt.seagull.net (user34.net540.or.sprint-hsd.net [65.40.225.34]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id TAA04004 for ; Mon, 3 Mar 2003 19:49:41 -0500 Received: (mail@localhost) by sunbelt.seagull.net (8.9.3) id QAA07955 sender nn683849@smallcue.com for w3c-dist-auth@w3.org; Mon, 3 Mar 2003 16:49:40 -0800 Received: from e1.ny.us.ibm.com (e1.ny.us.ibm.com [32.97.182.101]) by sunbelt.seagull.net (8.9.3) with ESMTP id QAA07932 sender obsfucated@us.ibm.com; Mon, 3 Mar 2003 16:49:37 -0800 Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.56.224.150]) by e1.ny.us.ibm.com (8.12.8/8.12.2) with ESMTP id h240n6n5128160; Mon, 3 Mar 2003 19:49:06 -0500 Received: from d01ml243.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by northrelay02.pok.ibm.com (8.12.3/NCO/VER6.5) with ESMTP id h240n4jR053514; Mon, 3 Mar 2003 19:49:04 -0500 To: "Julian Reschke" Cc: "Clemm, Geoff" , "WebDAV" X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: Jason Crawford Date: Mon, 3 Mar 2003 19:45:28 -0500 X-MIMETrack: Serialize by Router on D01ML243/01/M/IBM(Release 6.0.1 [IBM]|February 28, 2003) at 03/03/2003 19:49:03 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Subject: RE: Move and Delete (was: bind draft issues) X-Archived-At: http://www.w3.org/mid/OF9AEFA049.C015B0CE-ON05256CDF.0000D8E8@us.ibm.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7317 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: On Monday, 03/03/2003 at 11:08 CET, "Julian Reschke" wrote: > > From: w3c-dist-auth-request@w3.org > > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Clemm, Geoff > > Sent: Monday, March 03, 2003 10:44 PM > > To: WebDAV > > Subject: RE: Move and Delete (was: bind draft issues) > > > > > > > > To emphasize an earlier comment, it is true that the bind protocol > > places constraints on how a server is allowed to implement the DELETE > > and MOVE methods. In particular, a server that supports the bind > > protocol is not allowed to do a partial MOVE or a partial DELETE (even > > though 2518 allows it). > > ... > > Good catch. I remember that we discussed that at some point of time, but it > seems it was never added to the issues list. > > Our server indeed is able to support the BIND method and live properties > with all their semantics, yet won't do an atomic DELETE on collections. I > agree that *technically* a server that properly handles bindings *could* do > atomic deletes, but in reality, there may be reasons why you don't *want* > to. Saying that it doesn't support atomic deletes doesn't make sense to me. The concept doesn't exist. The binding spec's DELETE command is asking that only one thing be done. If you can't do that one thing you need to reject the DELETE request. But leaving a partial tree there is not an option because the method didn't ask you to delete those other bindings and in fact might not want them to be deleted. I would hope it's possible though and that you wouldn't have to reject the request. Even in a file system based server, I'd hope that the server could simply unmap the collection and then in the background do the delete/move of the whole tree incrementally if that were appropriate. But if it can't, IMO it needs to reject the request. From w3c-dist-auth-request@w3.org Mon Mar 3 22:52:13 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA22707 for ; Mon, 3 Mar 2003 22:52:13 -0500 (EST) Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id h243rRb03960; Mon, 3 Mar 2003 22:53:27 -0500 (EST) Resent-Date: Mon, 3 Mar 2003 22:53:27 -0500 (EST) Resent-Message-Id: <200303040353.h243rRb03960@frink.w3.org> Received: from tux.w3.org (tux [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id h243rCI03568 for ; Mon, 3 Mar 2003 22:53:12 -0500 (EST) Received: from w3c2.w3.org (w3c2.w3.org [193.51.208.66]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id WAA32500 for ; Mon, 3 Mar 2003 22:53:10 -0500 Received: from mail.xythos.com (unknown [206.14.210.116]) by w3c2.w3.org (Postfix) with ESMTP id 20AD31466A for ; Tue, 4 Mar 2003 04:49:00 +0100 (MET) Received: from ravms by mail.xythos.com with mail-ok (Exim 3.36 #3) id 18q3R1-0006DA-00 for w3c-dist-auth@w3.org; Tue, 04 Mar 2003 03:49:43 +0000 Received: from [198.144.203.248] (helo=xythoslap) by mail.xythos.com with asmtp (Exim 3.36 #3) id 18q3R0-0006Cz-00 for w3c-dist-auth@w3.org; Tue, 04 Mar 2003 03:49:43 +0000 From: "Lisa Dusseault" To: "'WebDAV'" Date: Mon, 3 Mar 2003 19:48:59 -0800 Message-ID: <052301c2e200$fdac9aa0$f8cb90c6@xythoslap> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4024 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal In-Reply-To: Old-X-Envelope-To: w3c-dist-auth@w3.org Subject: RE: Move and Delete (was: bind draft issues) X-Archived-At: http://www.w3.org/mid/052301c2e200$fdac9aa0$f8cb90c6@xythoslap Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7319 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit > > 2518 correctly states that MOVE (and COPY) also may involve > > a DELETE with "Depth: infinity" operation in the case of > > overwrite. > It supports that. What you're possibly refering to is the fact that > 2518 let's the DELETE on a collection to delete some of the > children and abort before removing the colection itself and without > backing out what it did. In the Bind Spec, there is no requirement > to unbind those child resources and in many cases you definitely > don't want to do that. You only have to unbind the collection. > There is no partial DELETE. You just have to unmap that collection. > Whether that reclaims resources is a different matter. Would you be able to do that -- unmap a collection -- even if one of its children were locked? The person with the lock would then lose it and their resource, right? If on the other hand, you can't unmap a collection until all its children are unlocked, then you have a serious problem supporting that atomically on a filesystem. For example, by the time IIS 5.0 checks all the children of a collection to see if they're locked, one of them might have just gotten a new lock. Lisa From w3c-dist-auth-request@w3.org Mon Mar 3 22:52:17 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA22725 for ; Mon, 3 Mar 2003 22:52:17 -0500 (EST) Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id h243rLw03848; Mon, 3 Mar 2003 22:53:21 -0500 (EST) Resent-Date: Mon, 3 Mar 2003 22:53:21 -0500 (EST) Resent-Message-Id: <200303040353.h243rLw03848@frink.w3.org> Received: from tux.w3.org (tux [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id h243rBI03538 for ; Mon, 3 Mar 2003 22:53:11 -0500 (EST) Received: from w3c2.w3.org (w3c2.w3.org [193.51.208.66]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id WAA32451 for ; Mon, 3 Mar 2003 22:53:09 -0500 Received: from mail.xythos.com (unknown [206.14.210.116]) by w3c2.w3.org (Postfix) with ESMTP id CE05D14660 for ; Tue, 4 Mar 2003 04:46:33 +0100 (MET) Received: from ravms by mail.xythos.com with mail-ok (Exim 3.36 #3) id 18q3IX-000681-00; Tue, 04 Mar 2003 03:40:57 +0000 Received: from [198.144.203.248] (helo=xythoslap) by mail.xythos.com with asmtp (Exim 3.36 #3) id 18q3IX-00067q-00; Tue, 04 Mar 2003 03:40:57 +0000 From: "Lisa Dusseault" To: "'Clemm, Geoff'" , "'WebDAV'" Date: Mon, 3 Mar 2003 19:40:14 -0800 Message-ID: <052101c2e1ff$c48fbe60$f8cb90c6@xythoslap> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4024 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal In-Reply-To: Old-X-Envelope-To: gclemm@rational.com, w3c-dist-auth@w3.org Subject: RE: bind draft issues X-Archived-At: http://www.w3.org/mid/052101c2e1ff$c48fbe60$f8cb90c6@xythoslap Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7318 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit > RFC2518bis is in the process of finalizing the behavior of > locks, and we do not want the bind draft to say anything that > conflicts with this. Instead, we will make sure that the > locking model in RFC2518bis clearly defines locking behavior > in the presence of multiple bindings. I don't think that's a reasonable expectation of RFC2518bis. The bindings draft has to be clear in how it deals with locks -- RFC2518bis will not discuss bindings. Lisa From w3c-dist-auth-request@w3.org Mon Mar 3 23:08:15 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA23094 for ; Mon, 3 Mar 2003 23:08:15 -0500 (EST) Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id h2449Nt07008; Mon, 3 Mar 2003 23:09:23 -0500 (EST) Resent-Date: Mon, 3 Mar 2003 23:09:23 -0500 (EST) Resent-Message-Id: <200303040409.h2449Nt07008@frink.w3.org> Received: from tux.w3.org (tux [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id h2449MI06972 for ; Mon, 3 Mar 2003 23:09:22 -0500 (EST) Received: from mail.xythos.com ([206.14.210.116]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id XAA05091 for ; Mon, 3 Mar 2003 23:09:21 -0500 Received: from ravms by mail.xythos.com with mail-ok (Exim 3.36 #3) id 18q3ki-0006RF-00; Tue, 04 Mar 2003 04:10:04 +0000 Received: from [198.144.203.248] (helo=xythoslap) by mail.xythos.com with asmtp (Exim 3.36 #3) id 18q3ki-0006R4-00; Tue, 04 Mar 2003 04:10:04 +0000 From: "Lisa Dusseault" To: "'Julian Reschke'" , "'Brian Korver'" , "'WebDAV'" Date: Mon, 3 Mar 2003 20:09:20 -0800 Message-ID: <052401c2e203$d5966de0$f8cb90c6@xythoslap> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4024 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal In-Reply-To: Old-X-Envelope-To: briank@xythos.com, julian.reschke@gmx.de, w3c-dist-auth@w3.org Subject: RE: Bindings and Locks (was: bind draft issues) X-Archived-At: http://www.w3.org/mid/052401c2e203$d5966de0$f8cb90c6@xythoslap Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7320 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit > Of course does RFC2518 have a notion of bindings. What it > doesn't have is a > method to *create* multiple bindings, and the live properties > to inspect > them. > > Bindings always have been there implicitly. All the BIND spec > adds is the > machinery to create them, and to discover some more > information about them. > You can say that RFC2518 supports bindings, but only if you cover one eye when you look at it. RFC2518 contains definitions for operations that apply to resources and operations that apply to URLs. RFC2518 is in fact very ambiguous on this kind of thing, without a fixed model of how implementors must represent everything under the covers. A lot of the text is descriptive. For example, the definition of DELETE for a non-collection talks as if it applies to a binding: "If the DELETE method is issued to a non-collection resource whose URIs are an internal member of one or more collections, then during DELETE processing a server MUST remove any URI for the resource identified by the Request-URI from collections which contain it as a member." However, the definition of DELETE for a collection talks as if it applies to a set of underlying resources: "DELETE instructs that the collection specified in the Request-URI and all resources identified by its internal member URIs are to be deleted. " Locks apply more to URLs than to resources, yet property operations apply more to resources than to URLs, and neither locks nor properties are 100% pure. Really, what this means is that implementors of several kinds of systems can support RFC2518 simply by supporting a consistent behavior. For example, systems that model URLs as links to underlying resources, as well as systems that model URLs as properties of resources. There may be other kinds too. Lisa From w3c-dist-auth-request@w3.org Mon Mar 3 23:45:03 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA23775 for ; Mon, 3 Mar 2003 23:45:03 -0500 (EST) Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id h244kNJ12785; Mon, 3 Mar 2003 23:46:23 -0500 (EST) Resent-Date: Mon, 3 Mar 2003 23:46:23 -0500 (EST) Resent-Message-Id: <200303040446.h244kNJ12785@frink.w3.org> Received: from tux.w3.org (tux [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id h244kLI12753 for ; Mon, 3 Mar 2003 23:46:21 -0500 (EST) Received: from sunbelt.seagull.net (user34.net540.or.sprint-hsd.net [65.40.225.34]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id XAA11502 for ; Mon, 3 Mar 2003 23:46:20 -0500 Received: (mail@localhost) by sunbelt.seagull.net (8.9.3) id UAA23040 sender nn683849@smallcue.com for w3c-dist-auth@w3.org; Mon, 3 Mar 2003 20:46:19 -0800 Received: from e4.ny.us.ibm.com (e4.ny.us.ibm.com [32.97.182.104]) by sunbelt.seagull.net (8.9.3) with ESMTP id UAA23024 sender obsfucated@us.ibm.com; Mon, 3 Mar 2003 20:46:18 -0800 Received: from northrelay04.pok.ibm.com (northrelay04.pok.ibm.com [9.56.224.206]) by e4.ny.us.ibm.com (8.12.8/8.12.2) with ESMTP id h244jl4V084464; Mon, 3 Mar 2003 23:45:47 -0500 Received: from d01ml243.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by northrelay04.pok.ibm.com (8.12.3/NCO/VER6.5) with ESMTP id h244jilT108358; Mon, 3 Mar 2003 23:45:45 -0500 To: "Lisa Dusseault" Cc: "'WebDAV'" X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: Jason Crawford Date: Mon, 3 Mar 2003 23:42:08 -0500 X-MIMETrack: Serialize by Router on D01ML243/01/M/IBM(Release 6.0.1 [IBM]|February 28, 2003) at 03/03/2003 23:45:44 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Subject: RE: Move and Delete (was: bind draft issues) X-Archived-At: http://www.w3.org/mid/OFEC458113.2346D242-ON05256CDF.00161CA5@us.ibm.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7321 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: On Monday, 03/03/2003 at 07:48 PST, "Lisa Dusseault" wrote: > > > 2518 correctly states that MOVE (and COPY) also may involve > > > a DELETE with "Depth: infinity" operation in the case of > > > overwrite. > > It supports that. What you're possibly refering to is the fact that > > 2518 let's the DELETE on a collection to delete some of the > > children and abort before removing the colection itself and without > > backing out what it did. In the Bind Spec, there is no requirement > > to unbind those child resources and in many cases you definitely > > don't want to do that. You only have to unbind the collection. > > There is no partial DELETE. You just have to unmap that collection. > > Whether that reclaims resources is a different matter. > > Would you be able to do that -- unmap a collection -- even if one of its > children were locked? The person with the lock would then lose it and > their resource, right? What you are implying is correct. If a child is locked via a WebDAV lock and the binding to be DELETEd is protected by the protected URL of that lock, then it can't be unmapped. If the inode of the child is locked, then I believe it can be unmapped. If it's locked by a Win32 lock then it probably can't be unmapped in the file system, so it's probably best to reject the DELETE at the WebDAV layer. > If on the other hand, you can't unmap a collection until all its > children are unlocked, then you have a serious problem supporting that > atomically on a filesystem. > For example, by the time IIS 5.0 checks all > the children of a collection to see if they're locked, one of them might > have just gotten a new lock. If we're talking about webdav's locks, it should be handleable inside the server and it should be manageable. If we're talking about a file system lock, then it might depend on the OS. I believe on Linux for example that it doesn't matter if an inode is locked. The resource can move/delete and the resource remains locked and file handles are not broken. In the case of Win32, you probably can go through the same process as the Win32 CMD.EXE MOVE command does. It does take a few seconds looking for locks in descendents in large trees... but I assume it also deals with locks being created while it's looking. If that MOVE succeeds, then that binding should be WebDAV DELETE'able. If that MOVE is rejected, then you probably will need to reject the WebDAV bind-enabled DELETE. ------------------------------------------ Phone: 914-784-7569, ccjason@us.ibm.com I do not check nn621779@smallcue.com From w3c-dist-auth-request@w3.org Tue Mar 4 03:32:51 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA09034 for ; Tue, 4 Mar 2003 03:32:50 -0500 (EST) Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id h248XnX10432; Tue, 4 Mar 2003 03:33:49 -0500 (EST) Resent-Date: Tue, 4 Mar 2003 03:33:49 -0500 (EST) Resent-Message-Id: <200303040833.h248XnX10432@frink.w3.org> Received: from tux.w3.org (tux [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id h248XkI10396 for ; Tue, 4 Mar 2003 03:33:46 -0500 (EST) Received: from greenbytes.de (mail.greenbytes.de [217.5.201.10] (may be forged)) by tux.w3.org (8.9.3/8.9.3) with SMTP id DAA31202 for ; Tue, 4 Mar 2003 03:33:46 -0500 Received: from greenbytes.de ([192.168.1.23]) by greenbytes.de ([217.5.201.11]) with SMTP (MDaemon.PRO.v6.7.0.R) for ; Tue, 04 Mar 2003 09:33:02 +0100 Date: Tue, 4 Mar 2003 09:33:20 +0100 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: WebDAV To: "Clemm, Geoff" From: Stefan Eissing In-Reply-To: Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) X-MDRemoteIP: 192.168.1.23 X-Return-Path: stefan.eissing@greenbytes.de X-MDaemon-Deliver-To: w3c-dist-auth@w3.org Subject: Re: Bindings and Locks (was: bind draft issues) X-Archived-At: http://www.w3.org/mid/F4DD7CC4-4E1B-11D7-AB35-00039384827E@greenbytes.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7322 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit Ok with me. Am Montag, 03.03.03, um 21:31 Uhr (Europe/Berlin) schrieb Clemm, Geoff: > > OK, since the bind protocol only introduces one > new method, with simple behavior in the presence of > locks, I'm happy to add the appropriate precondition > to the BIND definition. In particular, I propose to > add the following precondition: > > (DAV:locked-update-allowed): if the collection identified by the > Request-URL > is write-locked, then the appropriate token MUST be specified in an If > request header. > > Anyone object to this addition? > > Cheers, > Geoff > > -----Original Message----- > From: Brian Korver [mailto:briank@xythos.com] > Sent: Monday, March 03, 2003 1:57 PM > To: WebDAV > Subject: Re: Bindings and Locks (was: bind draft issues) > > > > On Saturday, March 1, 2003, at 06:27 AM, Clemm, Geoff wrote: >> Bindings and Locks >> >> The relationship between bindings and locks is missing >> from the draft. I think the behavior of locks and the >> lock methods should be fully specified in this draft. >> >> RFC2518bis is in the process of finalizing the behavior of >> locks, and we do not want the bind draft to say anything that >> conflicts with this. Instead, we will make sure that the >> locking model in RFC2518bis clearly defines locking behavior >> in the presence of multiple bindings. > > It probably isn't a good idea to introduce a dependency > such as this, especially since 2518bis doesn't have any > notion of bindings. I don't believe that the binding > document can move forward. > > -brian > briank@xythos.com > From w3c-dist-auth-request@w3.org Tue Mar 4 03:40:12 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA09249 for ; Tue, 4 Mar 2003 03:40:11 -0500 (EST) Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id h248fIT11976; Tue, 4 Mar 2003 03:41:18 -0500 (EST) Resent-Date: Tue, 4 Mar 2003 03:41:18 -0500 (EST) Resent-Message-Id: <200303040841.h248fIT11976@frink.w3.org> Received: from tux.w3.org (tux [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id h248fDI11941 for ; Tue, 4 Mar 2003 03:41:14 -0500 (EST) Received: from mail.gmx.net (mail.gmx.net [213.165.65.60]) by tux.w3.org (8.9.3/8.9.3) with SMTP id DAA00327 for ; Tue, 4 Mar 2003 03:41:13 -0500 Received: (qmail 29255 invoked by uid 0); 4 Mar 2003 08:40:41 -0000 Received: from p3EE24743.dip.t-dialin.net (HELO lisa) (62.226.71.67) by mail.gmx.net (mp005-rz3) with SMTP; 4 Mar 2003 08:40:41 -0000 From: "Julian Reschke" To: "Lisa Dusseault" , "'Clemm, Geoff'" , "'WebDAV'" Date: Tue, 4 Mar 2003 09:40:37 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 In-Reply-To: <051701c2e1e4$56550240$f8cb90c6@xythoslap> Importance: Normal Subject: RE: FW: ETags again - basic question X-Archived-At: http://www.w3.org/mid/JIEGINCHMLABHJBIGKBCAEEKGKAA.julian.reschke@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7323 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Lisa Dusseault > Sent: Tuesday, March 04, 2003 1:24 AM > To: 'Clemm, Geoff'; 'WebDAV' > Subject: RE: FW: ETags again - basic question > > > > I strongly recommend servers to change Etag only when the entity > changes. After all, it's the "Entity" tag. Here are two to three > practical reasons. And I object again :-) This is yet another issue where theory and reality (implementation practice) collide. As Geoff noted, there are servers that store properties in the same file entitiy, and thus both DAV:getlastmodified and DAV:getetag change when dead properties change. Furthermore, there are servers that actually *modify* the entity contents upon PROPPATCH (I've seen IIS do this for Office files). All of these behaviours may be surprising, but *do* conform to RFC2518 and RFC2616, and I don't think we can forbid them without taking away a lot of implementation freedom. > If the ETag changes when the properties change, then: > 1. Clients who have cached based on the ETag will download the file > again unnecessarily. Perf problem only. Yes. > 2. Clients who are editing without a lock (including clients who lost > their lock accidentally due to network conditions) must compare Etag to > see if it's safe to upload their changes. This edit will fail and > confuse the user if somebody else changed the properties and makes their > upload fail. So they'd better take a lock as well. > 3. Clients who are editing with a lock might issue a PROPPATCH, then > try to issue a PUT with an ETag validation. If the ETag has changed due > to the PROPPATCH, then the client will be very confused whether or not > the file can be overwritten. The lock still appears to be there, yet the > ETag changed -- how did that happen? That's indeed a problem. I think the correct way to handle this would be to optionally return a new entity tag after PROPPATCH (just like PUT is doing it). > Geoff's comments are perfectly correct for client implementors -- it's > hard to predict how servers actually modify ETags. There's no rule > saying the content is actually different just because the ETag is > different. Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Tue Mar 4 03:44:32 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA09287 for ; Tue, 4 Mar 2003 03:44:32 -0500 (EST) Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id h248jhT12794; Tue, 4 Mar 2003 03:45:43 -0500 (EST) Resent-Date: Tue, 4 Mar 2003 03:45:43 -0500 (EST) Resent-Message-Id: <200303040845.h248jhT12794@frink.w3.org> Received: from tux.w3.org (tux [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id h248jfI12758 for ; Tue, 4 Mar 2003 03:45:41 -0500 (EST) Received: from mail.gmx.net (mail.gmx.net [213.165.65.60]) by tux.w3.org (8.9.3/8.9.3) with SMTP id DAA01200 for ; Tue, 4 Mar 2003 03:45:40 -0500 Received: (qmail 17241 invoked by uid 0); 4 Mar 2003 08:45:35 -0000 Received: from p3EE24743.dip.t-dialin.net (HELO lisa) (62.226.71.67) by mail.gmx.net (mp010-rz3) with SMTP; 4 Mar 2003 08:45:35 -0000 From: "Julian Reschke" To: "Lisa Dusseault" , "'Clemm, Geoff'" , "'WebDAV'" Date: Tue, 4 Mar 2003 09:45:32 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 In-Reply-To: <052101c2e1ff$c48fbe60$f8cb90c6@xythoslap> Importance: Normal Subject: RE: bind draft issues X-Archived-At: http://www.w3.org/mid/JIEGINCHMLABHJBIGKBCIEEKGKAA.julian.reschke@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7324 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Lisa Dusseault > Sent: Tuesday, March 04, 2003 4:40 AM > To: 'Clemm, Geoff'; 'WebDAV' > Subject: RE: bind draft issues > > > > > > RFC2518bis is in the process of finalizing the behavior of > > locks, and we do not want the bind draft to say anything that > > conflicts with this. Instead, we will make sure that the > > locking model in RFC2518bis clearly defines locking behavior > > in the presence of multiple bindings. > > I don't think that's a reasonable expectation of RFC2518bis. The > bindings draft has to be clear in how it deals with locks -- RFC2518bis > will not discuss bindings. I thought we had agreement that GULP is the currently best approach of explaining the WebDAV locking model. GULP also covers binds (implicitly!) and therefore either should be added to RFC2518bis, or be the basis for a rewrite: -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Tue Mar 4 03:44:48 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA09303 for ; Tue, 4 Mar 2003 03:44:48 -0500 (EST) Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id h248jjU12869; Tue, 4 Mar 2003 03:45:45 -0500 (EST) Resent-Date: Tue, 4 Mar 2003 03:45:45 -0500 (EST) Resent-Message-Id: <200303040845.h248jjU12869@frink.w3.org> Received: from tux.w3.org (tux [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id h248jhI12807 for ; Tue, 4 Mar 2003 03:45:43 -0500 (EST) Received: from greenbytes.de (mail.greenbytes.de [217.5.201.10] (may be forged)) by tux.w3.org (8.9.3/8.9.3) with SMTP id DAA01206 for ; Tue, 4 Mar 2003 03:45:41 -0500 Received: from greenbytes.de ([192.168.1.23]) by greenbytes.de ([217.5.201.11]) with SMTP (MDaemon.PRO.v6.7.0.R) for ; Tue, 04 Mar 2003 09:45:16 +0100 Date: Tue, 4 Mar 2003 09:45:34 +0100 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: WebDAV To: "Clemm, Geoff" From: Stefan Eissing In-Reply-To: Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) X-MDRemoteIP: 192.168.1.23 X-Return-Path: stefan.eissing@greenbytes.de X-MDaemon-Deliver-To: w3c-dist-auth@w3.org Subject: Re: Move and Delete (was: bind draft issues) X-Archived-At: http://www.w3.org/mid/A9E8403E-4E1D-11D7-AB35-00039384827E@greenbytes.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7325 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit Geoff, if I understand you correctly, you're saying that DELETE on a server with BINDings must always first *unbind* the target (in an atomic operation, similar to unlink in UNIX)? I certainly agree that this is the desired behaviour if the delete target has more than one binding. Question: is it possible to accept a partial sucess DELETE, iff the resource to be deleted has no other bindings? //Stefan Am Dienstag, 04.03.03, um 00:34 Uhr (Europe/Berlin) schrieb Clemm, Geoff: > > "Best effort" deletion is forbidden by the bind protocol, > because it can cause a DELETE in one collection to cause a change > in another collection, and this kind of "deletion side effect" > was something we explicitly were trying to avoid. For example, > suppose /henry/has-friend/jeff and /jim/has-friend/jeff > were bindings to the same collection, JEFF, and JEFF has a binding > named "wife" to a resource, MARI. Now suppose henry gets mad > at jeff, and issues a "DELETE /henry/has-friend/jeff" request. > But suppose at that moment someone else has a Depth:0 lock > on the /henry/has-friend collection. The result of a "best effort" > deletion is the removal of the "wife" binding from JEFF. That > may be OK if you were just updating the information accessible > from /henry (he isn't JEFF's friend anymore, and he's happy to > purge as much information about JEFF as he can), but with multiple > bindings, "best effort" deletion has now trashed the JEFF object > in all the other contexts in which it is still visible (and the > folks that still are his friends are still interested in that > information). > > So we're not saying that "best effort deletion" is always a bad thing, > but we are saying that "best effort deletion" is a bad thing when > you care about multiple bindings to the same resource. > > Cheers, > Geoff > > -----Original Message----- > From: Julian Reschke [mailto:julian.reschke@gmx.de] > Sent: Monday, March 03, 2003 5:08 PM > To: Clemm, Geoff; WebDAV > Subject: RE: Move and Delete (was: bind draft issues) > > >> From: w3c-dist-auth-request@w3.org >> [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Clemm, Geoff >> Sent: Monday, March 03, 2003 10:44 PM >> To: WebDAV >> Subject: RE: Move and Delete (was: bind draft issues) >> >> >> >> To emphasize an earlier comment, it is true that the bind protocol >> places constraints on how a server is allowed to implement the DELETE >> and MOVE methods. In particular, a server that supports the bind >> protocol is not allowed to do a partial MOVE or a partial DELETE (even >> though 2518 allows it). >> ... > > Good catch. I remember that we discussed that at some point of time, > but it > seems it was never added to the issues list. > > Our server indeed is able to support the BIND method and live > properties > with all their semantics, yet won't do an atomic DELETE on > collections. I > agree that *technically* a server that properly handles bindings > *could* do > atomic deletes, but in reality, there may be reasons why you don't > *want* > to. > > Therefore, I'd like the spec not to require a specific behaviou, or, > as a > minimum, change the MUST to a SHOULD. > > Julian > > -- > bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 > From w3c-dist-auth-request@w3.org Tue Mar 4 09:40:50 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA24026 for ; Tue, 4 Mar 2003 09:40:50 -0500 (EST) Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id h24Efep01026; Tue, 4 Mar 2003 09:41:40 -0500 (EST) Resent-Date: Tue, 4 Mar 2003 09:41:40 -0500 (EST) Resent-Message-Id: <200303041441.h24Efep01026@frink.w3.org> Received: from tux.w3.org (tux [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id h24EfcI00994 for ; Tue, 4 Mar 2003 09:41:38 -0500 (EST) Received: from sus-ma1it31.rational.com (sus-ma1it31.rational.com [130.213.73.33]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id JAA11470 for ; Tue, 4 Mar 2003 09:41:38 -0500 Received: from sus-ma1it00.rational.com ([10.64.1.25]) by 10.64.1.33 with InterScan Messaging Security Suite; Tue, 04 Mar 2003 09:25:02 -0500 Received: by sus-ma1it00.rational.com with Internet Mail Service (5.5.2656.59) id ; Tue, 4 Mar 2003 09:41:06 -0500 Message-ID: From: "Clemm, Geoff" To: "'WebDAV'" Date: Tue, 4 Mar 2003 09:41:06 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain Subject: Clarifying locking in RFC2518bis (was RE: bind draft issues) X-Archived-At: http://www.w3.org/mid/E4F2D33B98DF7E4880884B9F0E6FDEE2021C57F6@SUS-MA1IT01 Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7326 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: It has been several weeks since we posted the request for objections to the GULP model, and we have received no objections (either to the content or the terminology). So I propose that we add the GULP model (as described in the message quoted below by Julian) into RFC2518bis, and use that as the basis for our locking discussions. Lisa: Could you make this update? (Julian, Jason, or I would be happy to help, if you are pressed for time). This will significantly improve our ability to make progress with other protocol extensions that need to define their interactions with locks (i.e. we can stop discussing what might appear in 2518bis, and instead just refer to what is said in 2518bis). Cheers, Geoff From: Julian Reschke [mailto:julian.reschke@gmx.de] > From: Clemm, Geoff > > RFC2518bis is in the process of finalizing the behavior of > > locks, and we do not want the bind draft to say anything that > > conflicts with this. Instead, we will make sure that the > > locking model in RFC2518bis clearly defines locking behavior > > in the presence of multiple bindings. From: Dusseault, Lisa > I don't think that's a reasonable expectation of RFC2518bis. The > bindings draft has to be clear in how it deals with locks -- RFC2518bis > will not discuss bindings. I thought we had agreement that GULP is the currently best approach of explaining the WebDAV locking model. GULP also covers binds (implicitly!) and therefore either should be added to RFC2518bis, or be the basis for a rewrite: From w3c-dist-auth-request@w3.org Tue Mar 4 09:54:36 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA24762 for ; Tue, 4 Mar 2003 09:54:36 -0500 (EST) Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id h24EtjL02588; Tue, 4 Mar 2003 09:55:45 -0500 (EST) Resent-Date: Tue, 4 Mar 2003 09:55:45 -0500 (EST) Resent-Message-Id: <200303041455.h24EtjL02588@frink.w3.org> Received: from tux.w3.org (tux [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id h24EtiI02556 for ; Tue, 4 Mar 2003 09:55:44 -0500 (EST) Received: from mail.gmx.net (mail.gmx.net [213.165.65.60]) by tux.w3.org (8.9.3/8.9.3) with SMTP id JAA17318 for ; Tue, 4 Mar 2003 09:55:43 -0500 Received: (qmail 10594 invoked by uid 0); 4 Mar 2003 14:55:12 -0000 Received: from mail.greenbytes.de (HELO lisa) (217.5.201.10) by mail.gmx.net (mp009-rz3) with SMTP; 4 Mar 2003 14:55:12 -0000 From: "Julian Reschke" To: "Lisa Dusseault" , "'Julian Reschke'" , "'Brian Korver'" , "'WebDAV'" Date: Tue, 4 Mar 2003 15:55:11 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 In-Reply-To: <052401c2e203$d5966de0$f8cb90c6@xythoslap> Importance: Normal Subject: RE: Bindings and Locks (was: bind draft issues) X-Archived-At: http://www.w3.org/mid/JIEGINCHMLABHJBIGKBCCEFCGKAA.julian.reschke@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7327 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit > From: Lisa Dusseault [mailto:lisa@xythos.com] > Sent: Tuesday, March 04, 2003 5:09 AM > To: 'Julian Reschke'; 'Brian Korver'; 'WebDAV' > Subject: RE: Bindings and Locks (was: bind draft issues) > > > > Of course does RFC2518 have a notion of bindings. What it > > doesn't have is a > > method to *create* multiple bindings, and the live properties > > to inspect > > them. > > > > Bindings always have been there implicitly. All the BIND spec > > adds is the > > machinery to create them, and to discover some more > > information about them. > > > > You can say that RFC2518 supports bindings, but only if you cover one RFC2518 extends HTTP, and HTTP allows multiple URLs to be mapped to the same resource. > eye when you look at it. RFC2518 contains definitions for operations > that apply to resources and operations that apply to URLs. RFC2518 is > in fact very ambiguous on this kind of thing, without a fixed model of > how implementors must represent everything under the covers. A lot of Well, yes. The RFCs should describe server behaviour, not their internals. > the text is descriptive. Correct. > For example, the definition of DELETE for a non-collection talks as if > it applies to a binding: > > "If the DELETE method is issued to a non-collection resource whose URIs > are an internal member of one or more collections, then during DELETE > processing a server MUST remove any URI for the resource identified by > the Request-URI from collections which contain it as a member." > > However, the definition of DELETE for a collection talks as if it > applies to a set of underlying resources: > > "DELETE instructs that the collection specified in the Request-URI and > all resources identified by its internal member URIs are to be deleted. > " > > Locks apply more to URLs than to resources, yet property operations > apply more to resources than to URLs, and neither locks nor properties > are 100% pure. Locks apply both to resources and URLs (as clarified by GULP), and always did. Property operations *always* apply to resources, and there really is no exception to that rule. > Really, what this means is that implementors of several kinds of systems > can support RFC2518 simply by supporting a consistent behavior. For > example, systems that model URLs as links to underlying resources, as > well as systems that model URLs as properties of resources. There may be > other kinds too. The URL can only be a property of a resource if the system explicitly restricts itself to only single bindings. You can't have both multiple bindings, and also treat the URL as a property of the resource at the same time. Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Tue Mar 4 10:10:29 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26266 for ; Tue, 4 Mar 2003 10:10:29 -0500 (EST) Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id h24FBfq04559; Tue, 4 Mar 2003 10:11:41 -0500 (EST) Resent-Date: Tue, 4 Mar 2003 10:11:41 -0500 (EST) Resent-Message-Id: <200303041511.h24FBfq04559@frink.w3.org> Received: from tux.w3.org (tux [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id h24FBeI04523 for ; Tue, 4 Mar 2003 10:11:40 -0500 (EST) Received: from sus-ma1it31.rational.com (sus-ma1it31.rational.com [130.213.73.33]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id KAA22723 for ; Tue, 4 Mar 2003 10:11:40 -0500 Received: from sus-ma1it00.rational.com ([10.64.1.25]) by 10.64.1.33 with InterScan Messaging Security Suite; Tue, 04 Mar 2003 09:55:05 -0500 Received: by sus-ma1it00.rational.com with Internet Mail Service (5.5.2656.59) id ; Tue, 4 Mar 2003 10:11:09 -0500 Message-ID: From: "Clemm, Geoff" To: WebDAV Date: Tue, 4 Mar 2003 10:11:07 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain Subject: RE: Move and Delete (was: bind draft issues) X-Archived-At: http://www.w3.org/mid/E4F2D33B98DF7E4880884B9F0E6FDEE2021C5815@SUS-MA1IT01 Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7328 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: I believe it is simpler for a client if the DELETE model stays consistent (i.e. doesn't change when another binding is added to a member of the collection). Also note that it is actually quite complex to state under what conditions it is OK to partially delete nested bindings; namely, "when a collection is deleted, a nested binding can be deleted from the collection only if there is exactly one binding to any resource on the path from the collection to that nested binding". Cheers, Geoff -----Original Message----- From: Stefan Eissing [mailto:stefan.eissing@greenbytes.de] Sent: Tuesday, March 04, 2003 3:46 AM To: Clemm, Geoff Cc: WebDAV Subject: Re: Move and Delete (was: bind draft issues) Geoff, if I understand you correctly, you're saying that DELETE on a server with BINDings must always first *unbind* the target (in an atomic operation, similar to unlink in UNIX)? I certainly agree that this is the desired behaviour if the delete target has more than one binding. Question: is it possible to accept a partial sucess DELETE, iff the resource to be deleted has no other bindings? //Stefan Am Dienstag, 04.03.03, um 00:34 Uhr (Europe/Berlin) schrieb Clemm, Geoff: > > "Best effort" deletion is forbidden by the bind protocol, > because it can cause a DELETE in one collection to cause a change > in another collection, and this kind of "deletion side effect" > was something we explicitly were trying to avoid. For example, > suppose /henry/has-friend/jeff and /jim/has-friend/jeff > were bindings to the same collection, JEFF, and JEFF has a binding > named "wife" to a resource, MARI. Now suppose henry gets mad > at jeff, and issues a "DELETE /henry/has-friend/jeff" request. > But suppose at that moment someone else has a Depth:0 lock > on the /henry/has-friend collection. The result of a "best effort" > deletion is the removal of the "wife" binding from JEFF. That > may be OK if you were just updating the information accessible > from /henry (he isn't JEFF's friend anymore, and he's happy to > purge as much information about JEFF as he can), but with multiple > bindings, "best effort" deletion has now trashed the JEFF object > in all the other contexts in which it is still visible (and the > folks that still are his friends are still interested in that > information). > > So we're not saying that "best effort deletion" is always a bad thing, > but we are saying that "best effort deletion" is a bad thing when > you care about multiple bindings to the same resource. > > Cheers, > Geoff > > -----Original Message----- > From: Julian Reschke [mailto:julian.reschke@gmx.de] > Sent: Monday, March 03, 2003 5:08 PM > To: Clemm, Geoff; WebDAV > Subject: RE: Move and Delete (was: bind draft issues) > > >> From: w3c-dist-auth-request@w3.org >> [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Clemm, Geoff >> Sent: Monday, March 03, 2003 10:44 PM >> To: WebDAV >> Subject: RE: Move and Delete (was: bind draft issues) >> >> >> >> To emphasize an earlier comment, it is true that the bind protocol >> places constraints on how a server is allowed to implement the DELETE >> and MOVE methods. In particular, a server that supports the bind >> protocol is not allowed to do a partial MOVE or a partial DELETE (even >> though 2518 allows it). >> ... > > Good catch. I remember that we discussed that at some point of time, > but it > seems it was never added to the issues list. > > Our server indeed is able to support the BIND method and live > properties > with all their semantics, yet won't do an atomic DELETE on > collections. I > agree that *technically* a server that properly handles bindings > *could* do > atomic deletes, but in reality, there may be reasons why you don't > *want* > to. > > Therefore, I'd like the spec not to require a specific behaviou, or, > as a > minimum, change the MUST to a SHOULD. > > Julian > > -- > bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 > From w3c-dist-auth-request@w3.org Tue Mar 4 10:10:33 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26284 for ; Tue, 4 Mar 2003 10:10:32 -0500 (EST) Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id h24FBhj04615; Tue, 4 Mar 2003 10:11:43 -0500 (EST) Resent-Date: Tue, 4 Mar 2003 10:11:43 -0500 (EST) Resent-Message-Id: <200303041511.h24FBhj04615@frink.w3.org> Received: from tux.w3.org (tux [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id h24FBgI04583 for ; Tue, 4 Mar 2003 10:11:42 -0500 (EST) Received: from sus-ma1it31.rational.com (sus-ma1it31.rational.com [130.213.73.33]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id KAA22733 for ; Tue, 4 Mar 2003 10:11:42 -0500 Received: from sus-ma1it00.rational.com ([10.64.1.25]) by 10.64.1.33 with InterScan Messaging Security Suite; Tue, 04 Mar 2003 09:55:07 -0500 Received: by sus-ma1it00.rational.com with Internet Mail Service (5.5.2656.59) id ; Tue, 4 Mar 2003 10:11:11 -0500 Message-ID: From: "Clemm, Geoff" To: "'WebDAV'" Date: Tue, 4 Mar 2003 10:11:09 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain Subject: RE: Move and Delete (was: bind draft issues) X-Archived-At: http://www.w3.org/mid/E4F2D33B98DF7E4880884B9F0E6FDEE2021C5816@SUS-MA1IT01 Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7329 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: An important thing to keep in mind is that we do not expect all repositories to be capable of supporting the BIND method (in particular, the creation of multiple bindings to a collection). But we do require that a repository that supports the BIND method also supports atomic DELETE/MOVE. Just for interests sake, how many examples are there of repositories that do support multiple bindings to a collection but cannot support atomic DELETE/MOVE? Cheers, Geoff -----Original Message----- From: Jason Crawford [mailto:nn683849@smallcue.com] On Monday, 03/03/2003 at 07:48 PST, "Lisa Dusseault" wrote: > > > 2518 correctly states that MOVE (and COPY) also may involve > > > a DELETE with "Depth: infinity" operation in the case of > > > overwrite. > > It supports that. What you're possibly refering to is the fact that > > 2518 let's the DELETE on a collection to delete some of the > > children and abort before removing the colection itself and without > > backing out what it did. In the Bind Spec, there is no requirement > > to unbind those child resources and in many cases you definitely > > don't want to do that. You only have to unbind the collection. > > There is no partial DELETE. You just have to unmap that collection. > > Whether that reclaims resources is a different matter. > > Would you be able to do that -- unmap a collection -- even if one of its > children were locked? The person with the lock would then lose it and > their resource, right? What you are implying is correct. If a child is locked via a WebDAV lock and the binding to be DELETEd is protected by the protected URL of that lock, then it can't be unmapped. If the inode of the child is locked, then I believe it can be unmapped. If it's locked by a Win32 lock then it probably can't be unmapped in the file system, so it's probably best to reject the DELETE at the WebDAV layer. > If on the other hand, you can't unmap a collection until all its > children are unlocked, then you have a serious problem supporting that > atomically on a filesystem. > For example, by the time IIS 5.0 checks all > the children of a collection to see if they're locked, one of them might > have just gotten a new lock. If we're talking about webdav's locks, it should be handleable inside the server and it should be manageable. If we're talking about a file system lock, then it might depend on the OS. I believe on Linux for example that it doesn't matter if an inode is locked. The resource can move/delete and the resource remains locked and file handles are not broken. In the case of Win32, you probably can go through the same process as the Win32 CMD.EXE MOVE command does. It does take a few seconds looking for locks in descendents in large trees... but I assume it also deals with locks being created while it's looking. If that MOVE succeeds, then that binding should be WebDAV DELETE'able. If that MOVE is rejected, then you probably will need to reject the WebDAV bind-enabled DELETE. ------------------------------------------ Phone: 914-784-7569, ccjason@us.ibm.com I do not check nn621779@smallcue.com From w3c-dist-auth-request@w3.org Tue Mar 4 10:14:49 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26562 for ; Tue, 4 Mar 2003 10:14:48 -0500 (EST) Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id h24FFxr05149; Tue, 4 Mar 2003 10:15:59 -0500 (EST) Resent-Date: Tue, 4 Mar 2003 10:15:59 -0500 (EST) Resent-Message-Id: <200303041515.h24FFxr05149@frink.w3.org> Received: from tux.w3.org (tux [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id h24FFwI05117 for ; Tue, 4 Mar 2003 10:15:58 -0500 (EST) Received: from mail.gmx.net (mail.gmx.net [213.165.65.60]) by tux.w3.org (8.9.3/8.9.3) with SMTP id KAA23784 for ; Tue, 4 Mar 2003 10:15:58 -0500 Received: (qmail 13029 invoked by uid 0); 4 Mar 2003 15:15:48 -0000 Received: from mail.greenbytes.de (HELO lisa) (217.5.201.10) by mail.gmx.net (mp004-rz3) with SMTP; 4 Mar 2003 15:15:48 -0000 From: "Julian Reschke" To: "Clemm, Geoff" , "'WebDAV'" Date: Tue, 4 Mar 2003 16:15:47 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 In-Reply-To: Importance: Normal Subject: RE: Move and Delete (was: bind draft issues) X-Archived-At: http://www.w3.org/mid/JIEGINCHMLABHJBIGKBCMEFDGKAA.julian.reschke@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7330 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Clemm, Geoff > Sent: Tuesday, March 04, 2003 4:11 PM > To: 'WebDAV' > Subject: RE: Move and Delete (was: bind draft issues) > > > > An important thing to keep in mind is that we do not > expect all repositories to be capable of supporting the BIND > method (in particular, the creation of multiple bindings to > a collection). But we do require that a repository that > supports the BIND method also supports atomic DELETE/MOVE. > > Just for interests sake, how many examples are there of > repositories that do support multiple bindings to a collection > but cannot support atomic DELETE/MOVE? The Unix file system? Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Tue Mar 4 10:41:37 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27598 for ; Tue, 4 Mar 2003 10:41:37 -0500 (EST) Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id h24FgdS10413; Tue, 4 Mar 2003 10:42:39 -0500 (EST) Resent-Date: Tue, 4 Mar 2003 10:42:39 -0500 (EST) Resent-Message-Id: <200303041542.h24FgdS10413@frink.w3.org> Received: from tux.w3.org (tux [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id h24FgbI10362 for ; Tue, 4 Mar 2003 10:42:37 -0500 (EST) Received: from mail.gmx.net (mail.gmx.net [213.165.65.60]) by tux.w3.org (8.9.3/8.9.3) with SMTP id KAA01507 for ; Tue, 4 Mar 2003 10:42:34 -0500 Received: (qmail 3110 invoked by uid 0); 4 Mar 2003 15:42:03 -0000 Received: from mail.greenbytes.de (HELO lisa) (217.5.201.10) by mail.gmx.net (mp008-rz3) with SMTP; 4 Mar 2003 15:42:03 -0000 From: "Julian Reschke" To: "Clemm, Geoff" , "WebDAV" Date: Tue, 4 Mar 2003 16:42:02 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 In-Reply-To: Importance: Normal Subject: RE: Move and Delete (was: bind draft issues) X-Archived-At: http://www.w3.org/mid/JIEGINCHMLABHJBIGKBCAEFFGKAA.julian.reschke@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7331 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Clemm, Geoff > Sent: Tuesday, March 04, 2003 4:11 PM > To: WebDAV > Subject: RE: Move and Delete (was: bind draft issues) > > > > I believe it is simpler for a client if the DELETE model stays > consistent (i.e. doesn't change when another binding is added > to a member of the collection). Well, just because it's simpler doesn't necessarily make it an acceptable model (acceptable to everybody, that is). > Also note that it is actually quite complex to state under what > conditions it is OK to partially delete nested bindings; namely, > "when a collection is deleted, a nested binding can be deleted > from the collection only if there is exactly one binding to any > resource on the path from the collection to that nested binding". I don't think we want to say that. Some servers will want to implement DELETE as simply removing the binding, others will want to ensure that they can also cleanup all members (and fail if they can't). I think both models make sense, and that the presence of support for an explicit BIND call doesn't really indicate that the former model always applies. It certainly doesn't for the Unix file system (rmdir() is only allowed for empty directories) and our system. Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Tue Mar 4 10:47:05 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27857 for ; Tue, 4 Mar 2003 10:47:05 -0500 (EST) Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id h24Fm0j14071; Tue, 4 Mar 2003 10:48:00 -0500 (EST) Resent-Date: Tue, 4 Mar 2003 10:48:00 -0500 (EST) Resent-Message-Id: <200303041548.h24Fm0j14071@frink.w3.org> Received: from tux.w3.org (tux [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id h24FlvI14030 for ; Tue, 4 Mar 2003 10:47:57 -0500 (EST) Received: from mail.gmx.net (mail.gmx.net [213.165.65.60]) by tux.w3.org (8.9.3/8.9.3) with SMTP id KAA04441 for ; Tue, 4 Mar 2003 10:47:56 -0500 Received: (qmail 10369 invoked by uid 0); 4 Mar 2003 15:47:24 -0000 Received: from mail.greenbytes.de (HELO lisa) (217.5.201.10) by mail.gmx.net (mp007-rz3) with SMTP; 4 Mar 2003 15:47:24 -0000 From: "Julian Reschke" To: "Jason Crawford" , "Julian Reschke" Cc: "Clemm, Geoff" , "WebDAV" Date: Tue, 4 Mar 2003 16:47:21 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 In-Reply-To: Importance: Normal Subject: RE: Move and Delete (was: bind draft issues) X-Archived-At: http://www.w3.org/mid/JIEGINCHMLABHJBIGKBCKEFFGKAA.julian.reschke@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7332 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit > From: Jason Crawford [mailto:nn683849@smallcue.com] > Sent: Tuesday, March 04, 2003 1:45 AM > To: Julian Reschke > Cc: Clemm, Geoff; WebDAV > Subject: RE: Move and Delete (was: bind draft issues) > > > ... > > Saying that it doesn't support atomic deletes doesn't make sense to > me. The concept doesn't exist. The binding spec's DELETE command is > asking that only one thing be done. If you can't do that one thing you need And that's why we're discussing this right now. The BIND spec requires a very specific DELETE behaviour, and some people do not seem to find that acceptable. Therefore the need to come to a consensus. > to reject the DELETE request. But leaving a partial tree there is not an > option because the method didn't ask you to delete those other bindings > and in fact might not want them to be deleted. Can you define how I can delete the binding a (a being a collection) without also deleting the binding a/b (when b is present in a)? > I would hope it's possible though and that you wouldn't have to reject the > request. Even in a file system based server, I'd hope that the server could > simply unmap the collection and then in the background do the delete/move > of the whole tree incrementally if that were appropriate. But what if this simply is not what the system *should* do? > But if it can't, IMO it needs to reject the request. It may not be able to reject the request until after it has started removing resources. There's a reason why DELETE isn't atomic in RFC2518. -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Tue Mar 4 12:10:56 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01871 for ; Tue, 4 Mar 2003 12:10:56 -0500 (EST) Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id h24HBh529612; Tue, 4 Mar 2003 12:11:43 -0500 (EST) Resent-Date: Tue, 4 Mar 2003 12:11:43 -0500 (EST) Resent-Message-Id: <200303041711.h24HBh529612@frink.w3.org> Received: from tux.w3.org (tux [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id h24HBfI29564 for ; Tue, 4 Mar 2003 12:11:41 -0500 (EST) Received: from sunbelt.seagull.net (user34.net540.or.sprint-hsd.net [65.40.225.34]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id MAA32254 for ; Tue, 4 Mar 2003 12:11:31 -0500 Received: (mail@localhost) by sunbelt.seagull.net (8.9.3) id JAA28223 sender nn683849@smallcue.com for w3c-dist-auth@w3.org; Tue, 4 Mar 2003 09:11:29 -0800 Received: from e4.ny.us.ibm.com (e4.ny.us.ibm.com [32.97.182.104]) by sunbelt.seagull.net (8.9.3) with ESMTP id JAA28200 sender obsfucated@us.ibm.com; Tue, 4 Mar 2003 09:11:15 -0800 Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.56.224.150]) by e4.ny.us.ibm.com (8.12.8/8.12.2) with ESMTP id h24HAd4V077636; Tue, 4 Mar 2003 12:10:39 -0500 Received: from d01ml243.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by northrelay02.pok.ibm.com (8.12.3/NCO/VER6.5) with ESMTP id h24HAart028898; Tue, 4 Mar 2003 12:10:36 -0500 To: "Julian Reschke" Cc: "Clemm, Geoff" , "'WebDAV'" X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: Jason Crawford Date: Tue, 4 Mar 2003 12:05:20 -0500 X-MIMETrack: Serialize by Router on D01ML243/01/M/IBM(Release 6.0.1 [IBM]|March 3, 2003) at 03/04/2003 12:10:36 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Subject: RE: Move and Delete (was: bind draft issues) X-Archived-At: http://www.w3.org/mid/OF6DB3F705.71C83016-ON05256CDF.0055EA95@us.ibm.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7333 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: > > Just for interests sake, how many examples are there of > > repositories that do support multiple bindings to a collection > > but cannot support atomic DELETE/MOVE? > The Unix file system? Sort of. On most (all?) Unix file systems you can't create a hard link to a directory, but you can create a soft/symbolic link. In essence, all directories have one hard link and zero or more symbolic links to them. The symbolic link has no referential integrity, but that's probably not a major issue for a WebDAV server since the link can be traversed to confirm that the referee still exists. (See caveat below.) To simulate BIND support one can use symbolic links. In that case the action to take when doing a DELETE/UNBIND is fairly easy if the binding is implemented as a symbolic link, but not as easy if it's a hard link. If breaking a hard link, there are a number of options. I believe you can't just delete the subdirectory without deleting it's children. But you can move the directory to another location on the same file system. It can be moved out of the namespace or it can be moved to replace a symbolic link to the collection. Whether it's a symbolic link or a hard link being removed, you still need to do a fix up of symbolic links in to the subtree being removed. That obviously is not atomic, but at the WebDAV level you can block or remap access until that's completed. Or... you can just reject BIND requests to directories. :-) But more to the point of the discussion, there is nothing that will cause the file based Unix server to need to return a status code indicating that only "part" of the DELETE/UNBIND operation occured. J. From w3c-dist-auth-request@w3.org Tue Mar 4 12:26:39 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02518 for ; Tue, 4 Mar 2003 12:26:39 -0500 (EST) Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id h24HRgZ03300; Tue, 4 Mar 2003 12:27:42 -0500 (EST) Resent-Date: Tue, 4 Mar 2003 12:27:42 -0500 (EST) Resent-Message-Id: <200303041727.h24HRgZ03300@frink.w3.org> Received: from tux.w3.org (tux [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id h24HRfI03263 for ; Tue, 4 Mar 2003 12:27:41 -0500 (EST) Received: from mail.gmx.net (mail.gmx.net [213.165.65.60]) by tux.w3.org (8.9.3/8.9.3) with SMTP id MAA05685 for ; Tue, 4 Mar 2003 12:27:40 -0500 Received: (qmail 5859 invoked by uid 0); 4 Mar 2003 17:27:09 -0000 Received: from mail.greenbytes.de (HELO lisa) (217.5.201.10) by mail.gmx.net (mp009-rz3) with SMTP; 4 Mar 2003 17:27:09 -0000 From: "Julian Reschke" To: "Jason Crawford" , "Julian Reschke" Cc: "Clemm, Geoff" , "'WebDAV'" Date: Tue, 4 Mar 2003 18:27:08 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 In-Reply-To: Importance: Normal Subject: RE: Move and Delete (was: bind draft issues) X-Archived-At: http://www.w3.org/mid/JIEGINCHMLABHJBIGKBCEEFLGKAA.julian.reschke@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7334 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Jason Crawford > Sent: Tuesday, March 04, 2003 6:05 PM > To: Julian Reschke > Cc: Clemm, Geoff; 'WebDAV' > Subject: RE: Move and Delete (was: bind draft issues) > > > > > > > > > Just for interests sake, how many examples are there of > > > repositories that do support multiple bindings to a collection > > > but cannot support atomic DELETE/MOVE? > > The Unix file system? > > Sort of. On most (all?) Unix file systems you can't create a It may depend on the implementation and your permissions. > hard link to a directory, but you can create a soft/symbolic link. > In essence, all directories have one hard link and zero or more > symbolic links to them. The symbolic link has no referential Wrong. Any directory has two hard links (it's entry in the parent, and the "." entry as internal member). In addition, it gets hard links for each internal member that is a directory (through it's ".." entry). You can check this easily using ls. > integrity, but that's probably not a major issue for a WebDAV > server since the link can be traversed to confirm that the referee > still exists. (See caveat below.) > > To simulate BIND support one can use symbolic links. In that I'd be surprised if you could. If you delete a directory, how do you detect that there are symlinks left pointing to it? > ,... > > Whether it's a symbolic link or a > hard link being removed, you still need to do a fix up of symbolic > links in to the subtree being removed. That obviously is not Why do I need to fix up symlinks? It's their nature that they are weak links. I'd be surprised if they track another resource automatically. > atomic, but at the WebDAV level you can block or remap access > until that's completed.s I may be able to block that at the WebDAV level, but the WebDAV code may not be able to block other access types (such as filesystem access). > Or... you can just reject BIND requests to directories. :-) Even if I'd do that, the current wording of the BIND draft does not allow me to keep my current RFC2518-compliant DELETE implementation. I feel this is a problem. > But more to the point of the discussion, there is nothing that will cause > the file based Unix server to need to return a status code indicating that only > "part" of the DELETE/UNBIND operation occured. Because rmdir() only applies to empty directories and therefore doesn't need to consider this issue. Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Tue Mar 4 13:39:51 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04888 for ; Tue, 4 Mar 2003 13:39:50 -0500 (EST) Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id h24If6q14037; Tue, 4 Mar 2003 13:41:06 -0500 (EST) Resent-Date: Tue, 4 Mar 2003 13:41:06 -0500 (EST) Resent-Message-Id: <200303041841.h24If6q14037@frink.w3.org> Received: from tux.w3.org (tux [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id h24If3I14005 for ; Tue, 4 Mar 2003 13:41:03 -0500 (EST) Received: from mail.xythos.com ([206.14.210.116]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id NAA23011 for ; Tue, 4 Mar 2003 13:41:03 -0500 Received: from ravms by mail.xythos.com with mail-ok (Exim 3.36 #3) id 18qHMR-0003jA-00 for w3c-dist-auth@w3.org; Tue, 04 Mar 2003 18:41:55 +0000 Received: from ip-216-36-77-241.dsl.sjc.megapath.net ([216.36.77.241] helo=xythos.com) by mail.xythos.com with asmtp (Exim 3.36 #3) id 18qHMR-0003iz-00 for w3c-dist-auth@w3.org; Tue, 04 Mar 2003 18:41:55 +0000 Date: Tue, 4 Mar 2003 10:41:01 -0800 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) From: Brian Korver To: WebDAV Content-Transfer-Encoding: 7bit In-Reply-To: Message-Id: X-Mailer: Apple Mail (2.551) Old-X-Envelope-To: w3c-dist-auth@w3.org Subject: Re: Bindings and Locks (was: bind draft issues) X-Archived-At: http://www.w3.org/mid/D90A21B3-4E70-11D7-8A8F-000393751598@xythos.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7335 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit On Monday, March 3, 2003, at 01:35 PM, Jason Crawford wrote: > I suppose that covers it. Hopefully the reader understands the > situations > that > that covers. I'd like to vote in favor of providing enough specificity that the reader will understand the situations it covers. Are there any good arguments for not doing so? > > One question though... does it have to be a write-lock? I suspect > this precondition even applies to non-write locks. > > > -brian briank@xythos.com From w3c-dist-auth-request@w3.org Tue Mar 4 14:50:42 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07209 for ; Tue, 4 Mar 2003 14:50:37 -0500 (EST) Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id h24Jpck06756; Tue, 4 Mar 2003 14:51:38 -0500 (EST) Resent-Date: Tue, 4 Mar 2003 14:51:38 -0500 (EST) Resent-Message-Id: <200303041951.h24Jpck06756@frink.w3.org> Received: from tux.w3.org (tux [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id h24JpaI06651 for ; Tue, 4 Mar 2003 14:51:36 -0500 (EST) Received: from mail.xythos.com ([206.14.210.116]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id OAA18027 for ; Tue, 4 Mar 2003 14:51:33 -0500 Received: from ravms by mail.xythos.com with mail-ok (Exim 3.36 #3) id 18qISh-000568-00; Tue, 04 Mar 2003 19:52:27 +0000 Received: from [216.36.77.241] (helo=xythoslap) by mail.xythos.com with asmtp (Exim 3.36 #3) id 18qISg-00055x-00; Tue, 04 Mar 2003 19:52:26 +0000 From: "Lisa Dusseault" To: "'Jason Crawford'" Cc: "'WebDAV'" Date: Tue, 4 Mar 2003 11:51:31 -0800 Message-ID: <065401c2e287$75809aa0$f8cb90c6@xythoslap> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4024 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal In-Reply-To: Old-X-Envelope-To: nn683849@smallcue.com, w3c-dist-auth@w3.org Subject: RE: Move and Delete (was: bind draft issues) X-Archived-At: http://www.w3.org/mid/065401c2e287$75809aa0$f8cb90c6@xythoslap Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7336 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit > > Would you be able to do that -- unmap a collection -- even > if one of its > > children were locked? The person with the lock would then > lose it and > > their resource, right? > > What you are implying is correct. > If a child is locked via a WebDAV lock and the binding to be > DELETEd is > protected by the protected URL of that lock, then it can't be > unmapped. > If the inode of the child is locked, then I believe it can be > unmapped. > If it's locked by a Win32 lock then it probably can't be unmapped in > the file system, so it's probably best to reject the DELETE at the > WebDAV layer. I don't think the bindings specification makes clear what you've just said here. It's probably because you've internalized a data model that's been discussed on the list, and are making conclusions based on the model. This kind of information should be added to the specification, because even when models are written down, they can easily be interpreted differently by newcomers. Lisa From w3c-dist-auth-request@w3.org Tue Mar 4 15:13:18 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08685 for ; Tue, 4 Mar 2003 15:13:17 -0500 (EST) Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id h24KEHL11321; Tue, 4 Mar 2003 15:14:17 -0500 (EST) Resent-Date: Tue, 4 Mar 2003 15:14:17 -0500 (EST) Resent-Message-Id: <200303042014.h24KEHL11321@frink.w3.org> Received: from tux.w3.org (tux [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id h24KEFI11289 for ; Tue, 4 Mar 2003 15:14:15 -0500 (EST) Received: from sus-ma1it31.rational.com (sus-ma1it31.rational.com [130.213.73.33]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id PAA24506 for ; Tue, 4 Mar 2003 15:14:15 -0500 Received: from sus-ma1it00.rational.com ([10.64.1.25]) by 10.64.1.33 with InterScan Messaging Security Suite; Tue, 04 Mar 2003 14:57:40 -0500 Received: by sus-ma1it00.rational.com with Internet Mail Service (5.5.2656.59) id ; Tue, 4 Mar 2003 15:13:44 -0500 Message-ID: From: "Clemm, Geoff" To: WebDAV Date: Tue, 4 Mar 2003 15:13:44 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain Subject: RE: Bindings and Locks (was: bind draft issues) X-Archived-At: http://www.w3.org/mid/E4F2D33B98DF7E4880884B9F0E6FDEE25ED6D7@SUS-MA1IT01 Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7337 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: The only argument for not doing so is that being more specific probably requires including the entire GULP document, since that is needed to clearly define the difference between locking a resource and protecting a URL. But I don't think we want to include that information by copy in each protocol extension document, so I think it is more appropriate to get it into 2518bis, and refer to it from the other documents. Cheers, Geoff -----Original Message----- From: Brian Korver [mailto:briank@xythos.com] Sent: Tuesday, March 04, 2003 1:41 PM To: WebDAV Subject: Re: Bindings and Locks (was: bind draft issues) On Monday, March 3, 2003, at 01:35 PM, Jason Crawford wrote: > I suppose that covers it. Hopefully the reader understands the > situations > that > that covers. I'd like to vote in favor of providing enough specificity that the reader will understand the situations it covers. Are there any good arguments for not doing so? > > One question though... does it have to be a write-lock? I suspect > this precondition even applies to non-write locks. > > > -brian briank@xythos.com From w3c-dist-auth-request@w3.org Tue Mar 4 15:28:21 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09232 for ; Tue, 4 Mar 2003 15:28:21 -0500 (EST) Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id h24KSlF13880; Tue, 4 Mar 2003 15:28:47 -0500 (EST) Resent-Date: Tue, 4 Mar 2003 15:28:47 -0500 (EST) Resent-Message-Id: <200303042028.h24KSlF13880@frink.w3.org> Received: from tux.w3.org (tux [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id h24KSkI13834 for ; Tue, 4 Mar 2003 15:28:46 -0500 (EST) Received: from mail.xythos.com ([206.14.210.116]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id PAA29889 for ; Tue, 4 Mar 2003 15:28:46 -0500 Received: from ravms by mail.xythos.com with mail-ok (Exim 3.36 #3) id 18qJ2g-0005uS-00; Tue, 04 Mar 2003 20:29:38 +0000 Received: from ip-216-36-77-241.dsl.sjc.megapath.net ([216.36.77.241] helo=xythos.com) by mail.xythos.com with asmtp (Exim 3.36 #3) id 18qJ2g-0005uG-00; Tue, 04 Mar 2003 20:29:38 +0000 Date: Tue, 4 Mar 2003 12:28:42 -0800 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: WebDAV To: Jason Crawford From: Brian Korver In-Reply-To: Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) Old-X-Envelope-To: w3c-dist-auth@w3.org, nn683849@smallcue.com Subject: Re: bind draft issues X-Archived-At: http://www.w3.org/mid/E4491D6F-4E7F-11D7-8A8F-000393751598@xythos.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7339 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit On Monday, March 3, 2003, at 12:16 PM, Jason Crawford wrote: >> URLs have properties too. Think about how DAV:lockdiscovery >> works in the face of COPY/MOVE, > I'm not sure I understand what you're refering to, but it is true that > we protect the URL of a lock. And it's true that the > influence of a lock causes there to be a DAV:lockdiscovery property > shown on the resource, but I'm not sure I'd call that property a "URL > property". (It's more complex than that.) Could you expand on "more complex than that"? > > >> or DAV:displayname for that matter. > DAV:displayname is a property of the resource in every way that > I can think of. It is my understanding that there are implementations that permit (or even mandate) that the DAV:displayname property vary depending on URL. For instance, imagine if you have two different bindings to the same resource, say http://example.com/foo.html http://example.com/bar.html and display names which are the respective names of the resource, "foo.html" and "bar.html". Are you saying that such implementations would not be compliant with respect to 2518? > >> Regarding this issue, I was not suggesting that the problem >> is that the binding protocol changed the behavior of properties, >> just that the behavior needs to be fully specified. Do >> you feel that 2518 does fully specify the behavior of >> URL properties? > > Hold that thought until we resolve what it is you mean by > URL properties... Perhaps "URL properties" isn't the right term, but what is? In the face of bindings, "URL properties" are those properties which are (potentially) effected by operations on bindings, where "resource properties" are not effected by such operations. -brian briank@xythos.com From w3c-dist-auth-request@w3.org Tue Mar 4 15:28:31 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09256 for ; Tue, 4 Mar 2003 15:28:30 -0500 (EST) Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id h24KSk613847; Tue, 4 Mar 2003 15:28:46 -0500 (EST) Resent-Date: Tue, 4 Mar 2003 15:28:46 -0500 (EST) Resent-Message-Id: <200303042028.h24KSk613847@frink.w3.org> Received: from tux.w3.org (tux [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id h24KSiI13807 for ; Tue, 4 Mar 2003 15:28:44 -0500 (EST) Received: from mail.xythos.com ([206.14.210.116]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id PAA29852 for ; Tue, 4 Mar 2003 15:28:43 -0500 Received: from ravms by mail.xythos.com with mail-ok (Exim 3.36 #3) id 18qJ2f-0005u7-00; Tue, 04 Mar 2003 20:29:37 +0000 Received: from [216.36.77.241] (helo=xythoslap) by mail.xythos.com with asmtp (Exim 3.36 #3) id 18qJ2f-0005tw-00; Tue, 04 Mar 2003 20:29:37 +0000 From: "Lisa Dusseault" To: "'Julian Reschke'" , "'Clemm, Geoff'" , "'WebDAV'" Date: Tue, 4 Mar 2003 12:28:43 -0800 Message-ID: <065e01c2e28c$a693ad30$f8cb90c6@xythoslap> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4024 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal In-Reply-To: Old-X-Envelope-To: gclemm@rational.com, julian.reschke@gmx.de, w3c-dist-auth@w3.org Subject: RE: FW: ETags again - basic question X-Archived-At: http://www.w3.org/mid/065e01c2e28c$a693ad30$f8cb90c6@xythoslap Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7338 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit Comments inline > -----Original Message----- > From: Julian Reschke [mailto:julian.reschke@gmx.de] > Sent: Tuesday, March 04, 2003 12:41 AM > To: Lisa Dusseault; 'Clemm, Geoff'; 'WebDAV' > Subject: RE: FW: ETags again - basic question > > > > From: w3c-dist-auth-request@w3.org > > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Lisa Dusseault > > Sent: Tuesday, March 04, 2003 1:24 AM > > To: 'Clemm, Geoff'; 'WebDAV' > > Subject: RE: FW: ETags again - basic question > > > > > > > > I strongly recommend servers to change Etag only when the entity > > changes. After all, it's the "Entity" tag. Here are two to three > > practical reasons. > > And I object again :-) > > This is yet another issue where theory and reality > (implementation practice) > collide. As Geoff noted, there are servers that store > properties in the same > file entitiy, and thus both DAV:getlastmodified and > DAV:getetag change when > dead properties change. Furthermore, there are servers that actually > *modify* the entity contents upon PROPPATCH (I've seen IIS do this for > Office files). I absolutely agree with you, or rather, you agree with me, because that's what I meant. Servers that modify the entity (even due to property changes from PROPPATCH) should change the Etag :) > All of these behaviours may be surprising, but > *do* conform > to RFC2518 and RFC2616, and I don't think we can forbid them > without taking > away a lot of implementation freedom. It is within the rules of 2616 to change the Etag when the entity does not change. However, it is not expected behavior and causes interoperability problems (screws the user if they're making changes). Since WebDAV adds properties to resources, we need to explain how properties affect Etags and how Etags are used in a distributed authoring environment. So anyway, we agree with each other again -- we can't forbid servers to change an Etag when the entity doesn't change. All the spec can do is recommend with SHOULD. > > 2. Clients who are editing without a lock (including > clients who lost > > their lock accidentally due to network conditions) must > compare Etag to > > see if it's safe to upload their changes. This edit will fail and > > confuse the user if somebody else changed the properties > and makes their > > upload fail. > > So they'd better take a lock as well. Right, but there are several cases where a very responsible locking client might not have a lock at the point where the user wants to do a PUT. 1. The server doesn't support locks. 2. The user decided to open the file for reading only. Maybe somebody else had a lock initially, or the user didn't expect to go make changes, or the user didn't have permissions to write when the first did the GET and started editing. Later, when the user instructs the client to save changes, the client should be perfectly capable of seeing whether the entity changed since the GET request -- using the Entity Tag. 3. The client very responsibly got the lock, for a responsible period like 1 hour. The client refreshed the lock as required, until the user unplugged and walked onto the train with their laptop (hey, I do this every night). On the train, the user finally saves their changes. Now the client has a set of changes but no lock. When the client gets a network connection again, what does the client do? It needs to do a PUT with an If-Match header and an Etag. (a) If the Etag matches, then the client can synchronize the offline changes. (b) If the Etag doesn't match because the entity changed, the client has to find some way to error and ask the user what to do. (c) If the Etag doesn't match even though the entity has NOT changed, the client either has to download the entire entity again and compare for a literal match, or the client can screw the user by telling them the resource body changed when in fact it didn't. Yuck. > > > 3. Clients who are editing with a lock might issue a > PROPPATCH, then > > try to issue a PUT with an ETag validation. If the ETag has > changed due > > to the PROPPATCH, then the client will be very confused > whether or not > > the file can be overwritten. The lock still appears to be > there, yet the > > ETag changed -- how did that happen? > > That's indeed a problem. I think the correct way to handle > this would be to > optionally return a new entity tag after PROPPATCH (just like > PUT is doing > it). Unless this were part of the spec, I'm not sure clients would notice an Etag on a PROPPATCH response. Otherwise, that's a good idea. This list has discussed in the past defining a new calculated property to allow the client to tell when dead or unprotected properties have changed -- a Property Tag or PTag, perhaps. Has the day come for that idea? Lisa From w3c-dist-auth-request@w3.org Tue Mar 4 15:32:18 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09451 for ; Tue, 4 Mar 2003 15:32:17 -0500 (EST) Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id h24KXVN14245; Tue, 4 Mar 2003 15:33:31 -0500 (EST) Resent-Date: Tue, 4 Mar 2003 15:33:31 -0500 (EST) Resent-Message-Id: <200303042033.h24KXVN14245@frink.w3.org> Received: from tux.w3.org (tux [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id h24KXUI14213 for ; Tue, 4 Mar 2003 15:33:30 -0500 (EST) Received: from mail.xythos.com ([206.14.210.116]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id PAA31219 for ; Tue, 4 Mar 2003 15:33:29 -0500 Received: from ravms by mail.xythos.com with mail-ok (Exim 3.36 #3) id 18qJ7H-00061E-00; Tue, 04 Mar 2003 20:34:23 +0000 Received: from [216.36.77.241] (helo=xythoslap) by mail.xythos.com with asmtp (Exim 3.36 #3) id 18qJ7H-00060w-00; Tue, 04 Mar 2003 20:34:23 +0000 From: "Lisa Dusseault" To: "'Julian Reschke'" , "'Clemm, Geoff'" , "'WebDAV'" Date: Tue, 4 Mar 2003 12:33:29 -0800 Message-ID: <065f01c2e28d$5128f520$f8cb90c6@xythoslap> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4024 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal In-Reply-To: Old-X-Envelope-To: gclemm@rational.com, julian.reschke@gmx.de, w3c-dist-auth@w3.org Subject: RE: bind draft issues X-Archived-At: http://www.w3.org/mid/065f01c2e28d$5128f520$f8cb90c6@xythoslap Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7340 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit > I thought we had agreement that GULP is the currently best approach of > explaining the WebDAV locking model. GULP also covers binds > (implicitly!) > and therefore either should be added to RFC2518bis, or be the > basis for a > rewrite: > GULP should not cover bindings. That's the problem. It causes a problem because some RFC2518 servers just don't work that way. There's no need to say whether operations apply always to URLs, bindings or resources in RFC2518, because when you have 1:1 mappings between URLs and resources it just doesn't matter 95% of the time, and lets implementations expose their existing repository. Otherwise, I think there is a lot of useful specification language in GULP. Lisa From w3c-dist-auth-request@w3.org Tue Mar 4 16:17:21 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10751 for ; Tue, 4 Mar 2003 16:17:21 -0500 (EST) Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id h24LHsZ27860; Tue, 4 Mar 2003 16:17:54 -0500 (EST) Resent-Date: Tue, 4 Mar 2003 16:17:54 -0500 (EST) Resent-Message-Id: <200303042117.h24LHsZ27860@frink.w3.org> Received: from tux.w3.org (tux [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id h24LHpI27825 for ; Tue, 4 Mar 2003 16:17:51 -0500 (EST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by tux.w3.org (8.9.3/8.9.3) with SMTP id QAA18214 for ; Tue, 4 Mar 2003 16:17:51 -0500 Received: (qmail 2153 invoked by uid 0); 4 Mar 2003 21:17:19 -0000 Received: from p3EE2473A.dip.t-dialin.net (HELO lisa) (62.226.71.58) by mail.gmx.net (mp020-rz3) with SMTP; 4 Mar 2003 21:17:19 -0000 From: "Julian Reschke" To: "Brian Korver" , "Jason Crawford" Cc: "WebDAV" Date: Tue, 4 Mar 2003 22:17:18 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 In-Reply-To: Importance: Normal Subject: RE: bind draft issues X-Archived-At: http://www.w3.org/mid/JIEGINCHMLABHJBIGKBCIEGHGKAA.julian.reschke@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7341 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Brian Korver > Sent: Tuesday, March 04, 2003 9:29 PM > To: Jason Crawford > Cc: WebDAV > Subject: Re: bind draft issues > > ... > It is my understanding that there are implementations that > permit (or even mandate) that the DAV:displayname property > vary depending on URL. For instance, imagine if you have two > different bindings to the same resource, say > > http://example.com/foo.html > http://example.com/bar.html > > and display names which are the respective names of the resource, > "foo.html" and "bar.html". Are you saying that such implementations > would not be compliant with respect to 2518? Yes. Clearly they aren't. RFC2518 never talked about "URL properties". DAV:displayname is a property of the resource, and therefore it must be independant of the URL through which the property is accessed. BTW: I'm not aware of implementations that actually support multiple bindings and show this behaviour. > >> Regarding this issue, I was not suggesting that the problem > >> is that the binding protocol changed the behavior of properties, > >> just that the behavior needs to be fully specified. Do > >> you feel that 2518 does fully specify the behavior of > >> URL properties? > > > > Hold that thought until we resolve what it is you mean by > > URL properties... > > Perhaps "URL properties" isn't the right term, but what is? > In the face of bindings, "URL properties" are those properties > which are (potentially) effected by operations on bindings, where > "resource properties" are not effected by such operations. My understanding is that "URL properties" simply do not exist. Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Tue Mar 4 16:24:16 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10973 for ; Tue, 4 Mar 2003 16:24:16 -0500 (EST) Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id h24LPCt29082; Tue, 4 Mar 2003 16:25:12 -0500 (EST) Resent-Date: Tue, 4 Mar 2003 16:25:12 -0500 (EST) Resent-Message-Id: <200303042125.h24LPCt29082@frink.w3.org> Received: from tux.w3.org (tux [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id h24LPBI29046 for ; Tue, 4 Mar 2003 16:25:11 -0500 (EST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by tux.w3.org (8.9.3/8.9.3) with SMTP id QAA19902 for ; Tue, 4 Mar 2003 16:25:10 -0500 Received: (qmail 13959 invoked by uid 0); 4 Mar 2003 21:24:39 -0000 Received: from p3EE2473A.dip.t-dialin.net (HELO lisa) (62.226.71.58) by mail.gmx.net (mp023-rz3) with SMTP; 4 Mar 2003 21:24:39 -0000 From: "Julian Reschke" To: "Lisa Dusseault" , "'Julian Reschke'" , "'Clemm, Geoff'" , "'WebDAV'" Date: Tue, 4 Mar 2003 22:24:37 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 In-Reply-To: <065e01c2e28c$a693ad30$f8cb90c6@xythoslap> Importance: Normal Subject: RE: FW: ETags again - basic question X-Archived-At: http://www.w3.org/mid/JIEGINCHMLABHJBIGKBCEEGIGKAA.julian.reschke@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7342 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Lisa Dusseault > Sent: Tuesday, March 04, 2003 9:29 PM > To: 'Julian Reschke'; 'Clemm, Geoff'; 'WebDAV' > Subject: RE: FW: ETags again - basic question > > ... > > So anyway, we agree with each other again -- we can't forbid servers to > change an Etag when the entity doesn't change. All the spec can do is > recommend with SHOULD. Agreed. > > > 3. Clients who are editing with a lock might issue a > > PROPPATCH, then > > > try to issue a PUT with an ETag validation. If the ETag has > > changed due > > > to the PROPPATCH, then the client will be very confused > > whether or not > > > the file can be overwritten. The lock still appears to be > > there, yet the > > > ETag changed -- how did that happen? > > > > That's indeed a problem. I think the correct way to handle > > this would be to > > optionally return a new entity tag after PROPPATCH (just like > > PUT is doing > > it). > > Unless this were part of the spec, I'm not sure clients would notice an > Etag on a PROPPATCH response. Otherwise, that's a good idea. So we may want to add this to RFC2518bis (if a PROPPATCH modifies the etag, it SHOULD be returned in a PROPPATCH response). > This list has discussed in the past defining a new calculated property > to allow the client to tell when dead or unprotected properties have > changed -- a Property Tag or PTag, perhaps. Has the day come for that > idea? I always liked that for symmetry reasons. But how does this help with the original problem? Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Tue Mar 4 16:35:21 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11234 for ; Tue, 4 Mar 2003 16:35:21 -0500 (EST) Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id h24LaOH00318; Tue, 4 Mar 2003 16:36:24 -0500 (EST) Resent-Date: Tue, 4 Mar 2003 16:36:24 -0500 (EST) Resent-Message-Id: <200303042136.h24LaOH00318@frink.w3.org> Received: from tux.w3.org (tux [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id h24LaNI00281 for ; Tue, 4 Mar 2003 16:36:23 -0500 (EST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by tux.w3.org (8.9.3/8.9.3) with SMTP id QAA22169 for ; Tue, 4 Mar 2003 16:36:22 -0500 Received: (qmail 19750 invoked by uid 0); 4 Mar 2003 21:35:51 -0000 Received: from p3EE2473A.dip.t-dialin.net (HELO lisa) (62.226.71.58) by mail.gmx.net (mp018-rz3) with SMTP; 4 Mar 2003 21:35:51 -0000 From: "Julian Reschke" To: "Lisa Dusseault" , "'Julian Reschke'" , "'Clemm, Geoff'" , "'WebDAV'" Date: Tue, 4 Mar 2003 22:35:49 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 In-Reply-To: <065f01c2e28d$5128f520$f8cb90c6@xythoslap> Importance: Normal Subject: RE: bind draft issues X-Archived-At: http://www.w3.org/mid/JIEGINCHMLABHJBIGKBCGEGJGKAA.julian.reschke@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7343 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Lisa Dusseault > Sent: Tuesday, March 04, 2003 9:33 PM > To: 'Julian Reschke'; 'Clemm, Geoff'; 'WebDAV' > Subject: RE: bind draft issues > > > > > > I thought we had agreement that GULP is the currently best approach of > > explaining the WebDAV locking model. GULP also covers binds (implicitly!) > > and therefore either should be added to RFC2518bis, or be the basis for a > > rewrite: > > > > GULP should not cover bindings. That's the problem. It causes a I don't understand this statement. How is the fact that GULP indeed handles the effects of multiple bindings (internal member URIs) to the same resource affecting it's usability for servers that do not need to consider this case??? Maybe it's really time to re-read it: --- Grand Unified Lock Proposal (V5.2) - A lock either directly or indirectly locks a resource. - A LOCK request creates a new lock, and the resource identified by the request-URL is directly locked by that lock. The "lock-root" of the new lock is the request-URL. If at the time of the request, the request-URL is not mapped to a resource, a new resource with no content MUST be created by the request. - If a collection is directly locked by a depth:infinity lock, all members of that collection (other than the collection itself) are indirectly locked by that lock. In particular, if a binding to a resource is added to a collection that is locked by a depth:infinity lock, and if the resource is not locked by that lock, then the resource becomes indirectly locked by that lock. Conversely, if a resource is indirectly locked with a depth:infinity lock, and if the result of removing a binding to the resource is that the resource is no longer a member of the collection that is directly locked by that lock, then the resource is no longer locked by that lock. - An UNLOCK request deletes the lock with the specified lock token. The request-URL of the request MUST identify a resource that is either directly or indirectly locked by that lock. After a lock is deleted, no resource is locked by that lock. - A lock token is "submitted" in a request when it appears in an If header tagged-list whose tag is the lock-root of the lock. - If a request would modify the content for a locked resource, a dead property of a locked resource, a live property that is defined to be lockable for a locked resource, or a binding of a locked collection, the request MUST fail unless the lock-token for that lock is submitted in the request. - If a request causes a directly locked resource to no longer be mapped to the lock-root of that lock, then the request MUST fail unless the lock-token for that lock is submitted in the request. If the request succeeds, then that lock MUST have been deleted by that request. - If a request would cause a resource to be locked by two different exclusive locks, the request MUST fail. --- I really doubt that you make the description significantly simpler by removing this case. > problem because some RFC2518 servers just don't work that way. There's Could you explain? Are you saying that there are RFC2518-compliant servers that do not comply to the GULP lock model? In which case there's simply a problem in the model that needs to be fixed. Actually, Geoff and I have been asking for this kind of feedback for several months now. > no need to say whether operations apply always to URLs, bindings or > resources in RFC2518, because when you have 1:1 mappings between URLs No. You don't. Just because RFC2518 doesn't have a BIND method doesn't mean that multiple bindings do not exist. In fact, RFC2518bis talks about redirect resources, although it doesn't define a method to create them. This is a very similar issue. > and resources it just doesn't matter 95% of the time, and lets > implementations expose their existing repository. So how precisely have these implementations problems with GULP? Please explain! > Otherwise, I think there is a lot of useful specification language in > GULP. OK. So *please* specify in which way GULP is inconsistent with RFC2518. Things I don't like to hear are: - it contains the term "binding" - RFC2518 defines a 1:1 mapping between URL and resource (this is clearly wrong, because RFC2518 extends HTTP, and there's no such restriction in HTTP). Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Tue Mar 4 16:40:41 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11331 for ; Tue, 4 Mar 2003 16:40:41 -0500 (EST) Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id h24Lfq000952; Tue, 4 Mar 2003 16:41:52 -0500 (EST) Resent-Date: Tue, 4 Mar 2003 16:41:52 -0500 (EST) Resent-Message-Id: <200303042141.h24Lfq000952@frink.w3.org> Received: from tux.w3.org (tux [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id h24LfpI00916 for ; Tue, 4 Mar 2003 16:41:51 -0500 (EST) Received: from sus-ma1it31.rational.com (sus-ma1it31.rational.com [130.213.73.33]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id QAA23977 for ; Tue, 4 Mar 2003 16:41:51 -0500 Received: from sus-ma1it00.rational.com ([10.64.1.25]) by 10.64.1.33 with InterScan Messaging Security Suite; Tue, 04 Mar 2003 16:25:15 -0500 Received: by sus-ma1it00.rational.com with Internet Mail Service (5.5.2656.59) id ; Tue, 4 Mar 2003 16:41:20 -0500 Message-ID: From: "Clemm, Geoff" To: "'WebDAV'" Date: Tue, 4 Mar 2003 16:41:19 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain Subject: RE: Move and Delete (was: bind draft issues) X-Archived-At: http://www.w3.org/mid/E4F2D33B98DF7E4880884B9F0E6FDEE25ED6DE@SUS-MA1IT01 Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7344 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Several points that Jason made here were implementation issues (e.g. Win32 locking, and file system mappings), so those points are not something that would appear in the spec. The other statement he made is just locking functionality defined by RFC2518, not something new introduced by the binding protocol. As Julian has pointed out, multiple mappings to the same resource is part of HTTP, and was inherited by WebDAV, not something new defined by the binding protocol. So multiple bindings have always existed in WebDAV. The binding protocol just gives a client a way to create them. Cheers, Geoff -----Original Message----- From: Lisa Dusseault [mailto:lisa@xythos.com] Sent: Tuesday, March 04, 2003 2:52 PM To: 'Jason Crawford' Cc: 'WebDAV' Subject: RE: Move and Delete (was: bind draft issues) > > Would you be able to do that -- unmap a collection -- even > if one of its > > children were locked? The person with the lock would then > lose it and > > their resource, right? > > What you are implying is correct. > If a child is locked via a WebDAV lock and the binding to be > DELETEd is > protected by the protected URL of that lock, then it can't be > unmapped. > If the inode of the child is locked, then I believe it can be > unmapped. > If it's locked by a Win32 lock then it probably can't be unmapped in > the file system, so it's probably best to reject the DELETE at the > WebDAV layer. I don't think the bindings specification makes clear what you've just said here. It's probably because you've internalized a data model that's been discussed on the list, and are making conclusions based on the model. This kind of information should be added to the specification, because even when models are written down, they can easily be interpreted differently by newcomers. Lisa From w3c-dist-auth-request@w3.org Tue Mar 4 16:56:08 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11751 for ; Tue, 4 Mar 2003 16:56:03 -0500 (EST) Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id h24LudE04326; Tue, 4 Mar 2003 16:56:39 -0500 (EST) Resent-Date: Tue, 4 Mar 2003 16:56:39 -0500 (EST) Resent-Message-Id: <200303042156.h24LudE04326@frink.w3.org> Received: from tux.w3.org (tux [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id h24LucI04294 for ; Tue, 4 Mar 2003 16:56:38 -0500 (EST) Received: from sus-ma1it31.rational.com (sus-ma1it31.rational.com [130.213.73.33]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id QAA30817 for ; Tue, 4 Mar 2003 16:56:38 -0500 Received: from sus-ma1it00.rational.com ([10.64.1.25]) by 10.64.1.33 with InterScan Messaging Security Suite; Tue, 04 Mar 2003 16:40:02 -0500 Received: by sus-ma1it00.rational.com with Internet Mail Service (5.5.2656.59) id ; Tue, 4 Mar 2003 16:56:07 -0500 Message-ID: From: "Clemm, Geoff" To: "'WebDAV'" Date: Tue, 4 Mar 2003 16:56:05 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain Subject: RE: bind draft issues X-Archived-At: http://www.w3.org/mid/E4F2D33B98DF7E4880884B9F0E6FDEE25ED6DF@SUS-MA1IT01 Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7345 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: In case there remains any question about whether HTTP supports multiple URIs being mapped to the same resource, the following quote appears in section 9.6 of RFC-2616: "A single resource MAY be identified by many different URIs. For example, an article might have a URI for identifying "the current version" which is separate from the URI identifying each particular version. In this case, a PUT request on a general URI might result in several other URIs being defined by the origin server." The binding protocol does two things: - it provides terminology for us to unambiguously discuss concepts that already exist in HTTP (and therefore are inherited by WebDAV). - it provides a new method to allow a client to explicitly creating multiple mappings to a resource. It is important to distinguish the new terminology for existing concepts (e.g. "bindings") from new functionality (e.g. BIND). Cheers, Geoff -----Original Message----- From: Julian Reschke [mailto:julian.reschke@gmx.de] Sent: Tuesday, March 04, 2003 4:36 PM To: Lisa Dusseault; 'Julian Reschke'; 'Clemm, Geoff'; 'WebDAV' Subject: RE: bind draft issues > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Lisa Dusseault > Sent: Tuesday, March 04, 2003 9:33 PM > To: 'Julian Reschke'; 'Clemm, Geoff'; 'WebDAV' > Subject: RE: bind draft issues > > > I thought we had agreement that GULP is the currently best > > approach of explaining the WebDAV locking model. GULP also covers > > binds (implicitly!) and therefore either should be added to > > RFC2518bis, or be the basis for a rewrite: > GULP should not cover bindings. That's the problem. It causes a I don't understand this statement. How is the fact that GULP indeed handles the effects of multiple bindings (internal member URIs) to the same resource affecting it's usability for servers that do not need to consider this case??? Maybe it's really time to re-read it: ----------- Grand Unified Lock Proposal (V5.2) - A lock either directly or indirectly locks a resource. - A LOCK request creates a new lock, and the resource identified by the request-URL is directly locked by that lock. The "lock-root" of the new lock is the request-URL. If at the time of the request, the request-URL is not mapped to a resource, a new resource with no content MUST be created by the request. - If a collection is directly locked by a depth:infinity lock, all members of that collection (other than the collection itself) are indirectly locked by that lock. In particular, if a binding to a resource is added to a collection that is locked by a depth:infinity lock, and if the resource is not locked by that lock, then the resource becomes indirectly locked by that lock. Conversely, if a resource is indirectly locked with a depth:infinity lock, and if the result of removing a binding to the resource is that the resource is no longer a member of the collection that is directly locked by that lock, then the resource is no longer locked by that lock. - An UNLOCK request deletes the lock with the specified lock token. The request-URL of the request MUST identify a resource that is either directly or indirectly locked by that lock. After a lock is deleted, no resource is locked by that lock. - A lock token is "submitted" in a request when it appears in an If header tagged-list whose tag is the lock-root of the lock. - If a request would modify the content for a locked resource, a dead property of a locked resource, a live property that is defined to be lockable for a locked resource, or a binding of a locked collection, the request MUST fail unless the lock-token for that lock is submitted in the request. - If a request causes a directly locked resource to no longer be mapped to the lock-root of that lock, then the request MUST fail unless the lock-token for that lock is submitted in the request. If the request succeeds, then that lock MUST have been deleted by that request. - If a request would cause a resource to be locked by two different exclusive locks, the request MUST fail. ----------- I really doubt that you make the description significantly simpler by removing this case. > problem because some RFC2518 servers just don't work that way. There's Could you explain? Are you saying that there are RFC2518-compliant servers that do not comply to the GULP lock model? In which case there's simply a problem in the model that needs to be fixed. Actually, Geoff and I have been asking for this kind of feedback for several months now. > no need to say whether operations apply always to URLs, bindings or > resources in RFC2518, because when you have 1:1 mappings between > URLs No. You don't. Just because RFC2518 doesn't have a BIND method doesn't mean that multiple bindings do not exist. In fact, RFC2518bis talks about redirect resources, although it doesn't define a method to create them. This is a very similar issue. > and resources it just doesn't matter 95% of the time, and lets > implementations expose their existing repository. So how precisely have these implementations problems with GULP? Please explain! > Otherwise, I think there is a lot of useful specification language in > GULP. OK. So *please* specify in which way GULP is inconsistent with RFC2518. Things I don't like to hear are: - it contains the term "binding" - RFC2518 defines a 1:1 mapping between URL and resource (this is clearly wrong, because RFC2518 extends HTTP, and there's no such restriction in HTTP). From w3c-dist-auth-request@w3.org Tue Mar 4 17:22:40 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12545 for ; Tue, 4 Mar 2003 17:22:40 -0500 (EST) Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id h24MFfa07780; Tue, 4 Mar 2003 17:15:41 -0500 (EST) Resent-Date: Tue, 4 Mar 2003 17:15:41 -0500 (EST) Resent-Message-Id: <200303042215.h24MFfa07780@frink.w3.org> Received: from tux.w3.org (tux [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id h24MFdI07748 for ; Tue, 4 Mar 2003 17:15:39 -0500 (EST) Received: from sunbelt.seagull.net (user34.net540.or.sprint-hsd.net [65.40.225.34]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id RAA06523 for ; Tue, 4 Mar 2003 17:15:39 -0500 Received: (mail@localhost) by sunbelt.seagull.net (8.9.3) id OAA19624 sender nn683849@smallcue.com for w3c-dist-auth@w3.org; Tue, 4 Mar 2003 14:15:37 -0800 Received: from e6.ny.us.ibm.com (e6.ny.us.ibm.com [32.97.182.106]) by sunbelt.seagull.net (8.9.3) with ESMTP id OAA19601 sender obsfucated@us.ibm.com; Tue, 4 Mar 2003 14:15:35 -0800 Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.56.224.150]) by e6.ny.us.ibm.com (8.12.8/8.12.2) with ESMTP id h24MF4Zu036232; Tue, 4 Mar 2003 17:15:04 -0500 Received: from d01ml243.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by northrelay02.pok.ibm.com (8.12.3/NCO/VER6.5) with ESMTP id h24MF0rt032550; Tue, 4 Mar 2003 17:15:01 -0500 To: "Julian Reschke" Cc: "'Julian Reschke'" , "Lisa Dusseault" , "'WebDAV'" X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: Jason Crawford Date: Tue, 4 Mar 2003 17:13:12 -0500 X-MIMETrack: Serialize by Router on D01ML243/01/M/IBM(Release 6.0.1 [IBM]|March 3, 2003) at 03/04/2003 17:15:01 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Subject: RE: FW: ETags again - basic question X-Archived-At: http://www.w3.org/mid/OF16D37793.F4D4D564-ON05256CDF.0078FBA0@us.ibm.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7346 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: > > Unless this were part of the spec, I'm not sure clients would notice an > > Etag on a PROPPATCH response. Otherwise, that's a good idea. > > So we may want to add this to RFC2518bis (if a PROPPATCH modifies the etag, > it SHOULD be returned in a PROPPATCH response). Initially I'd say "We don't" because we have agreed previously that changing properties shouldn't change the etag. I'd rather keep the message to the reader as simple as that. ------------------------------------------ Phone: 914-784-7569, ccjason@us.ibm.com I do not check nn621779@smallcue.com From w3c-dist-auth-request@w3.org Tue Mar 4 17:39:20 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12953 for ; Tue, 4 Mar 2003 17:39:20 -0500 (EST) Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id h24MZL410570; Tue, 4 Mar 2003 17:35:21 -0500 (EST) Resent-Date: Tue, 4 Mar 2003 17:35:21 -0500 (EST) Resent-Message-Id: <200303042235.h24MZL410570@frink.w3.org> Received: from tux.w3.org (tux [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id h24MZJI10538 for ; Tue, 4 Mar 2003 17:35:19 -0500 (EST) Received: from sus-ma1it31.rational.com (sus-ma1it31.rational.com [130.213.73.33]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id RAA13027 for ; Tue, 4 Mar 2003 17:35:19 -0500 Received: from sus-ma1it00.rational.com ([10.64.1.25]) by 10.64.1.33 with InterScan Messaging Security Suite; Tue, 04 Mar 2003 17:18:43 -0500 Received: by sus-ma1it00.rational.com with Internet Mail Service (5.5.2656.59) id ; Tue, 4 Mar 2003 17:34:48 -0500 Message-ID: From: "Clemm, Geoff" To: "'WebDAV'" Date: Tue, 4 Mar 2003 17:34:46 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Move and Delete (was: bind draft issues) X-Archived-At: http://www.w3.org/mid/E4F2D33B98DF7E4880884B9F0E6FDEE25ED6E0@SUS-MA1IT01 Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7347 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: From: Julian Reschke [mailto:julian.reschke@gmx.de] > From: Clemm, Geoff > > Just for interests sake, how many examples are there of > repositories that do support multiple bindings to a collection > but cannot support atomic DELETE/MOVE? The Unix file system? I am familiar with two kinds of Unix file systems wrt this issue. The first are ones that allow you (with suitable privileges) to use link() to create a second link (a "binding") to a directory, and that also allow you (with suitable privileges) to use unlink() to (atomically) remove a link (a "binding") to a directory. The second are ones that do not allow you to use link() to create a link to a directory, and also do not allow you to use unlink() to remove a link to a directory (you have to use rmdir()). In either case, it is not an instance of a repository that "supports multiple bindings to a collection but cannot support atomic DELETE/MOVE". So to rephrase the question to target unix file systems, how many examples are there of unix file systems that allow you to use link() to create a second link to a directory, but do not allow you to use unlink() to remove a link to a directory? (I'm not saying there aren't any ... just that I'm not familiar with them). Julian: Just for interests sake, or you using link/unlink to create bindings in your Unix file system, or something else? Cheers, Geoff From w3c-dist-auth-request@w3.org Tue Mar 4 17:48:42 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA13293 for ; Tue, 4 Mar 2003 17:48:42 -0500 (EST) Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id h24Mnid12218; Tue, 4 Mar 2003 17:49:44 -0500 (EST) Resent-Date: Tue, 4 Mar 2003 17:49:44 -0500 (EST) Resent-Message-Id: <200303042249.h24Mnid12218@frink.w3.org> Received: from tux.w3.org (tux [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id h24MngI12152 for ; Tue, 4 Mar 2003 17:49:42 -0500 (EST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by tux.w3.org (8.9.3/8.9.3) with SMTP id RAA17643 for ; Tue, 4 Mar 2003 17:49:41 -0500 Received: (qmail 25638 invoked by uid 0); 4 Mar 2003 22:49:10 -0000 Received: from p3EE2477A.dip.t-dialin.net (HELO lisa) (62.226.71.122) by mail.gmx.net (mp013-rz3) with SMTP; 4 Mar 2003 22:49:10 -0000 From: "Julian Reschke" To: "Clemm, Geoff" , "'WebDAV'" Date: Tue, 4 Mar 2003 23:49:08 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 In-Reply-To: Importance: Normal Subject: RE: Move and Delete (was: bind draft issues) X-Archived-At: http://www.w3.org/mid/JIEGINCHMLABHJBIGKBCEEGNGKAA.julian.reschke@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7348 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Clemm, Geoff > Sent: Tuesday, March 04, 2003 11:35 PM > To: 'WebDAV' > Subject: RE: Move and Delete (was: bind draft issues) > > ... > So to rephrase the question to target unix file systems, how many > examples are there of unix file systems that allow you to use link() > to create a second link to a directory, but do not allow you to use > unlink() to remove a link to a directory? (I'm not saying there > aren't any ... just that I'm not familiar with them). > > Julian: Just for interests sake, or you using link/unlink to > create bindings in your Unix file system, or something else? No, I was just using this as an example because I thought it qualified as example. The UFS certainly uses hard links (bindings) internally on collections, but, as you said, it usually doesn't let people mess around with them explicitly. Anyway, the main issue for us is that we absolutely can not change the DELETE collection semantics (from what we have in RFC2518), yet we *do* support explicit BIND creation. This basically means that we can't be compliant to the spec as it's written, and I think this is a problem. IMHO, the spec simply should allow "both" behaviours (atomic delete with cleanup of child resources as possible side effect), and RFC2518 semantics. Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Tue Mar 4 18:20:12 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA14917 for ; Tue, 4 Mar 2003 18:20:11 -0500 (EST) Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id h24NL5S20467; Tue, 4 Mar 2003 18:21:05 -0500 (EST) Resent-Date: Tue, 4 Mar 2003 18:21:05 -0500 (EST) Resent-Message-Id: <200303042321.h24NL5S20467@frink.w3.org> Received: from tux.w3.org (tux [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id h24NL3I20435 for ; Tue, 4 Mar 2003 18:21:03 -0500 (EST) Received: from mail.xythos.com ([206.14.210.116]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id SAA30323 for ; Tue, 4 Mar 2003 18:21:03 -0500 Received: from ravms by mail.xythos.com with mail-ok (Exim 3.36 #3) id 18qLjS-0001KR-00 for w3c-dist-auth@w3.org; Tue, 04 Mar 2003 23:21:58 +0000 Received: from ip-216-36-77-241.dsl.sjc.megapath.net ([216.36.77.241] helo=xythos.com) by mail.xythos.com with asmtp (Exim 3.36 #3) id 18qLjR-0001KG-00 for w3c-dist-auth@w3.org; Tue, 04 Mar 2003 23:21:57 +0000 Date: Tue, 4 Mar 2003 15:21:00 -0800 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) From: Brian Korver To: WebDAV Content-Transfer-Encoding: 7bit In-Reply-To: Message-Id: X-Mailer: Apple Mail (2.551) Old-X-Envelope-To: w3c-dist-auth@w3.org Subject: Re: bind draft issues X-Archived-At: http://www.w3.org/mid/F6206FBF-4E97-11D7-8A8F-000393751598@xythos.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7349 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit Geoff and I had a short out-of-band conversation to discuss the issue I raised when I mentioned "URL properties". Geoff pointed out that there had been text in the binding spec that explained the behavior of properties in the face of different operation, and that it might be good to revisit the issue and include such explanatory material in draft. Would someone like to volunteer to draft that text? Since I'm not familiar with the previous text and the discussion that ensued, perhaps Geoff could explain what the text should include? -brian briank@xythos.com From w3c-dist-auth-request@w3.org Tue Mar 4 18:53:48 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA15921 for ; Tue, 4 Mar 2003 18:53:48 -0500 (EST) Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id h24NsJS24293; Tue, 4 Mar 2003 18:54:19 -0500 (EST) Resent-Date: Tue, 4 Mar 2003 18:54:19 -0500 (EST) Resent-Message-Id: <200303042354.h24NsJS24293@frink.w3.org> Received: from tux.w3.org (tux [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id h24NsHI24261 for ; Tue, 4 Mar 2003 18:54:17 -0500 (EST) Received: from mail.xythos.com ([206.14.210.116]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id SAA07441 for ; Tue, 4 Mar 2003 18:54:17 -0500 Received: from ravms by mail.xythos.com with mail-ok (Exim 3.36 #3) id 18qMFa-0002C0-00 for w3c-dist-auth@w3.org; Tue, 04 Mar 2003 23:55:10 +0000 Received: from ip-216-36-77-241.dsl.sjc.megapath.net ([216.36.77.241] helo=xythos.com) by mail.xythos.com with asmtp (Exim 3.36 #3) id 18qMFZ-0002Bh-00 for w3c-dist-auth@w3.org; Tue, 04 Mar 2003 23:55:10 +0000 Date: Tue, 4 Mar 2003 15:54:12 -0800 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) From: Brian Korver To: "'WebDAV'" Content-Transfer-Encoding: 7bit In-Reply-To: Message-Id: <99179691-4E9C-11D7-8A8F-000393751598@xythos.com> X-Mailer: Apple Mail (2.551) Old-X-Envelope-To: w3c-dist-auth@w3.org Subject: Re: Move and Delete (was: bind draft issues) X-Archived-At: http://www.w3.org/mid/99179691-4E9C-11D7-8A8F-000393751598@xythos.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7350 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit On Monday, March 3, 2003, at 08:42 PM, Jason Crawford wrote: [snip] > If we're talking about webdav's locks, it should be handleable inside > the > server and it should be manageable. If we're talking about > a file system lock, then it might depend on the OS. I > believe on Linux for example that it doesn't matter if an inode is > locked. [snip] Just FYI, in linux, it depends on the type of lock. See 'i' in chattr(1) for more info. -brian briank@xythos.com From w3c-dist-auth-request@w3.org Tue Mar 4 19:06:59 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA16335 for ; Tue, 4 Mar 2003 19:06:58 -0500 (EST) Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id h25080a04932; Tue, 4 Mar 2003 19:08:00 -0500 (EST) Resent-Date: Tue, 4 Mar 2003 19:08:00 -0500 (EST) Resent-Message-Id: <200303050008.h25080a04932@frink.w3.org> Received: from tux.w3.org (tux [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id h2507xI04900 for ; Tue, 4 Mar 2003 19:07:59 -0500 (EST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by tux.w3.org (8.9.3/8.9.3) with SMTP id TAA32222 for ; Tue, 4 Mar 2003 19:07:58 -0500 Received: (qmail 28346 invoked by uid 0); 5 Mar 2003 00:07:27 -0000 Received: from p3EE2477A.dip.t-dialin.net (HELO lisa) (62.226.71.122) by mail.gmx.net (mp014-rz3) with SMTP; 5 Mar 2003 00:07:27 -0000 From: "Julian Reschke" To: "Jason Crawford" , "Julian Reschke" Cc: "Clemm, Geoff" , "'WebDAV'" Date: Wed, 5 Mar 2003 01:07:25 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 In-Reply-To: Importance: Normal Subject: RE: Move and Delete (was: bind draft issues) X-Archived-At: http://www.w3.org/mid/JIEGINCHMLABHJBIGKBCKEHBGKAA.julian.reschke@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7353 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit > From: Jason Crawford [mailto:nn683849@smallcue.com] > Sent: Wednesday, March 05, 2003 12:56 AM > To: Julian Reschke > Cc: Clemm, Geoff; 'WebDAV' > Subject: RE: Move and Delete (was: bind draft issues) > > ... > > > > > Or... you can just reject BIND requests to directories. :-) > > > > Even if I'd do that, the current wording of the BIND draft does > not allow > me > > to keep my current RFC2518-compliant DELETE implementation. I feel this > is a > > problem. > > Right. To claim BIND spec support, you have enhance the implementation to > support *this* 2518 compliant approach.... or to avoid a situations where > bind spec > violations would happen. It's not unreasonable to expect one to have to > add code > in order to support a new feature like multiple-bindings. Actually, I'd have to remove code. The issue isn't that the server can't *technically* do this -- it's that the this semantics isn't compatible with the existing DELETE semantics of our system. Just removing the collection binding without checking that all internal members may be deleted as well simply is *not* an option. So basically we have the choice between - supporting multiple bindings, but not the BIND method described in the draft, or - simply ignore this requirement. I'd rather have a spec that I can implement without having to break a specific requirement (in particular if i'm not convinced it adds value to my use case). Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Tue Mar 4 19:11:15 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA16482 for ; Tue, 4 Mar 2003 19:11:15 -0500 (EST) Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id h25077H04708; Tue, 4 Mar 2003 19:07:07 -0500 (EST) Resent-Date: Tue, 4 Mar 2003 19:07:07 -0500 (EST) Resent-Message-Id: <200303050007.h25077H04708@frink.w3.org> Received: from tux.w3.org (tux [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id h25075I04643 for ; Tue, 4 Mar 2003 19:07:05 -0500 (EST) Received: from sunbelt.seagull.net (user34.net540.or.sprint-hsd.net [65.40.225.34]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id TAA31951 for ; Tue, 4 Mar 2003 19:07:04 -0500 Received: (mail@localhost) by sunbelt.seagull.net (8.9.3) id QAA28120 sender nn683849@smallcue.com for w3c-dist-auth@w3.org; Tue, 4 Mar 2003 16:07:03 -0800 Received: from e4.ny.us.ibm.com (e4.ny.us.ibm.com [32.97.182.104]) by sunbelt.seagull.net (8.9.3) with ESMTP id QAA28097 sender obsfucated@us.ibm.com; Tue, 4 Mar 2003 16:07:01 -0800 Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.56.224.150]) by e4.ny.us.ibm.com (8.12.8/8.12.2) with ESMTP id h2506U4V095076; Tue, 4 Mar 2003 19:06:30 -0500 Received: from d01ml243.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by northrelay02.pok.ibm.com (8.12.3/NCO/VER6.5) with ESMTP id h2506Rrt009490; Tue, 4 Mar 2003 19:06:27 -0500 To: "Julian Reschke" Cc: "Clemm, Geoff" , "Julian Reschke" "WebDAV" X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: Jason Crawford Date: Tue, 4 Mar 2003 19:02:19 -0500 X-MIMETrack: Serialize by Router on D01ML243/01/M/IBM(Release 6.0.1 [IBM]|March 3, 2003) at 03/04/2003 19:06:26 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Subject: RE: Move and Delete (was: bind draft issues) X-Archived-At: http://www.w3.org/mid/OFE7C7077D.54D454C0-ON05256CDF.005E3C10@us.ibm.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7352 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: On Tuesday, 03/04/2003 at 04:47 CET, "Julian Reschke" wrote: > > Saying that it doesn't support atomic deletes doesn't make sense to > > me. The concept doesn't exist. The binding spec's DELETE command is > > asking that only one thing be done. If you can't do that one thing you > > need > > And that's why we're discussing this right now. The BIND spec requires a > very specific DELETE behaviour, and some people do not seem to find that > acceptable. Therefore the need to come to a consensus. I've only heard that servers are forced in to this behavior, not that bind aware clients actually want this behavior. I'm arguing that servers can support this at the WebDAV level. And if they can't they need to reject the DELETE request, reject BIND's to collections, or not claim that they are supporting BIND functionality. > Can you define how I can delete the binding a (a being a collection) without > also deleting the binding a/b (when b is present in a)? See the rest of my posting. Plus the posting I just made. Plus what I say below. > > I would hope it's possible though and that you wouldn't have to reject the > > request. Even in a file system based server, I'd hope that the server > could > > simply unmap the collection and then in the background do the delete/move > > of the whole tree incrementally if that were appropriate. > > But what if this simply is not what the system *should* do? I did say that it can happen in the background. It doesn't have to. It can be done in the foreground. But no one has argued that they want partial results appearing as a result of a DELETE in the presence of bindings. What they have argued is that that servers are forced to leave partial results. I have shown that in the situations mentioned, they are not forced to leave partial results. But doing what I suggest is not the only acceptable approach. Server implementations can claim not to support bindings, reject BIND requests to collections, or reject DELETE requests that they aren't sure they can complete. But they can't return partial deletion in the presences of multiple bindings. > > But if it can't, IMO it needs to reject the request. > > It may not be able to reject the request until after it has started removing > resources. There's a reason why DELETE isn't atomic in RFC2518. See the rest of my posting. You probably can detect if you will not be able to complete the operation. If the MOVE completes, you have completed the request. If it fails, you have not. This does not leave partial results. What you will still need to do is clean up symbolic references.in to the tree. This might be possible to do in a simple remapping request or you can do it iteratively... or both ways. This can be done in a way that makes it unnecessary to have to return partial results. Finally... the server probably will want to reclaim (perhaps only in the absense of versioning) inaccessable resources. But that problem doesn't change the semantics of the WebDAV operation. If it needs to do that, it can do that in the foreground before completion (as it would have had to do anyway) or in the background, but it doesn't effect what the UNBIND/DELETE method should return to the client. ------------------------------------------ Phone: 914-784-7569, ccjason@us.ibm.com I do not check nn621779@smallcue.com From w3c-dist-auth-request@w3.org Tue Mar 4 19:15:47 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA16658 for ; Tue, 4 Mar 2003 19:15:47 -0500 (EST) Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id h250G8l07777; Tue, 4 Mar 2003 19:16:08 -0500 (EST) Resent-Date: Tue, 4 Mar 2003 19:16:08 -0500 (EST) Resent-Message-Id: <200303050016.h250G8l07777@frink.w3.org> Received: from tux.w3.org (tux [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id h250G6I07741 for ; Tue, 4 Mar 2003 19:16:06 -0500 (EST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by tux.w3.org (8.9.3/8.9.3) with SMTP id TAA04249 for ; Tue, 4 Mar 2003 19:16:06 -0500 Received: (qmail 29197 invoked by uid 0); 5 Mar 2003 00:15:33 -0000 Received: from p3EE2477A.dip.t-dialin.net (HELO lisa) (62.226.71.122) by mail.gmx.net (mp021-rz3) with SMTP; 5 Mar 2003 00:15:33 -0000 From: "Julian Reschke" To: "Clemm, Geoff" , "WebDAV" Date: Wed, 5 Mar 2003 01:15:28 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 In-Reply-To: Importance: Normal Subject: RE: Move and Delete (was: bind draft issues) X-Archived-At: http://www.w3.org/mid/JIEGINCHMLABHJBIGKBCGEHCGKAA.julian.reschke@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7354 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit Geoff, thanks for trying to come up with a scenario that benefits from the current required semantics. Comments inline. > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Clemm, Geoff > Sent: Tuesday, March 04, 2003 12:34 AM > To: WebDAV > Subject: RE: Move and Delete (was: bind draft issues) > > > > "Best effort" deletion is forbidden by the bind protocol, > because it can cause a DELETE in one collection to cause a change > in another collection, and this kind of "deletion side effect" > was something we explicitly were trying to avoid. For example, > suppose /henry/has-friend/jeff and /jim/has-friend/jeff > were bindings to the same collection, JEFF, and JEFF has a binding > named "wife" to a resource, MARI. Now suppose henry gets mad > at jeff, and issues a "DELETE /henry/has-friend/jeff" request. In this case I'd just remove that binding. The question where we disagree is about the required behaviour when the collection binding is the last one, i.e. when the server is then free to remove all internal members. > But suppose at that moment someone else has a Depth:0 lock > on the /henry/has-friend collection. The result of a "best effort" > deletion is the removal of the "wife" binding from JEFF. That Nope. I didn't say that. > may be OK if you were just updating the information accessible > from /henry (he isn't JEFF's friend anymore, and he's happy to > purge as much information about JEFF as he can), but with multiple > bindings, "best effort" deletion has now trashed the JEFF object > in all the other contexts in which it is still visible (and the > folks that still are his friends are still interested in that > information). > > So we're not saying that "best effort deletion" is always a bad thing, > but we are saying that "best effort deletion" is a bad thing when > you care about multiple bindings to the same resource. I'd rephrase that as "best effort deletion of internal members is a bad thing when you aren't destroying the last binding to the collection". I agree with that. Where I disagree is whether best effort deletion should be allowed when the binding that is removed is the last binding to a collection. In this particular case, I'd prefer to allow RFC2518 behaviour (if we don't, I don't see how can sell the implementation to my customer :-). Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Tue Mar 4 19:16:42 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA16695 for ; Tue, 4 Mar 2003 19:16:37 -0500 (EST) Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id h250HIA07957; Tue, 4 Mar 2003 19:17:18 -0500 (EST) Resent-Date: Tue, 4 Mar 2003 19:17:18 -0500 (EST) Resent-Message-Id: <200303050017.h250HIA07957@frink.w3.org> Received: from tux.w3.org (tux [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id h250HHI07924 for ; Tue, 4 Mar 2003 19:17:17 -0500 (EST) Received: from sunbelt.seagull.net (user34.net540.or.sprint-hsd.net [65.40.225.34]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id TAA04402 for ; Tue, 4 Mar 2003 19:17:16 -0500 Received: (mail@localhost) by sunbelt.seagull.net (8.9.3) id QAA28710 sender nn683849@smallcue.com for w3c-dist-auth@w3.org; Tue, 4 Mar 2003 16:17:15 -0800 Received: from e3.ny.us.ibm.com (e3.ny.us.ibm.com [32.97.182.103]) by sunbelt.seagull.net (8.9.3) with ESMTP id QAA28686 sender obsfucated@us.ibm.com; Tue, 4 Mar 2003 16:17:13 -0800 Received: from northrelay04.pok.ibm.com (northrelay04.pok.ibm.com [9.56.224.206]) by e3.ny.us.ibm.com (8.12.8/8.12.2) with ESMTP id h250Ggl9020014; Tue, 4 Mar 2003 19:16:42 -0500 Received: from d01ml243.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by northrelay04.pok.ibm.com (8.12.3/NCO/VER6.5) with ESMTP id h250GdMp065230; Tue, 4 Mar 2003 19:16:39 -0500 To: "Julian Reschke" Cc: "Clemm, Geoff" , "'WebDAV'" X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: Jason Crawford Date: Tue, 4 Mar 2003 19:14:57 -0500 X-MIMETrack: Serialize by Router on D01ML243/01/M/IBM(Release 6.0.1 [IBM]|March 3, 2003) at 03/04/2003 19:16:38 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Subject: RE: Move and Delete (was: bind draft issues) X-Archived-At: http://www.w3.org/mid/OF92E1A94A.6A01B307-ON05256CE0.000059BB@us.ibm.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7355 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: > Anyway, the main issue for us is that we absolutely can not change the > DELETE collection semantics (from what we have in RFC2518). Sure you can. The behavior the spec outlines is compliant with 2518. It does not break 2518 compliant clients. But it does require that server writers do some coding before they can claim to support this new feature. ------------------------------------------ Phone: 914-784-7569, ccjason@us.ibm.com I do not check nn621779@smallcue.com From w3c-dist-auth-request@w3.org Tue Mar 4 19:27:28 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA16944 for ; Tue, 4 Mar 2003 19:27:27 -0500 (EST) Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id h250SDb12129; Tue, 4 Mar 2003 19:28:13 -0500 (EST) Resent-Date: Tue, 4 Mar 2003 19:28:13 -0500 (EST) Resent-Message-Id: <200303050028.h250SDb12129@frink.w3.org> Received: from tux.w3.org (tux [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id h250SBI12097 for ; Tue, 4 Mar 2003 19:28:11 -0500 (EST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by tux.w3.org (8.9.3/8.9.3) with SMTP id TAA08235 for ; Tue, 4 Mar 2003 19:28:10 -0500 Received: (qmail 6578 invoked by uid 0); 5 Mar 2003 00:27:39 -0000 Received: from p3EE2477A.dip.t-dialin.net (HELO lisa) (62.226.71.122) by mail.gmx.net (mp019-rz3) with SMTP; 5 Mar 2003 00:27:39 -0000 From: "Julian Reschke" To: "Jason Crawford" , "Julian Reschke" Cc: "Clemm, Geoff" , "Julian Reschke WebDAV" Date: Wed, 5 Mar 2003 01:27:36 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 In-Reply-To: Importance: Normal Subject: RE: Move and Delete (was: bind draft issues) X-Archived-At: http://www.w3.org/mid/JIEGINCHMLABHJBIGKBCGEHDGKAA.julian.reschke@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7356 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit > From: Jason Crawford [mailto:nn683849@smallcue.com] > Sent: Wednesday, March 05, 2003 1:02 AM > To: Julian Reschke > Cc: Clemm, Geoff; Julian Reschke WebDAV > Subject: RE: Move and Delete (was: bind draft issues) > > > > > > On Tuesday, 03/04/2003 at 04:47 CET, "Julian Reschke" > wrote: > > > Saying that it doesn't support atomic deletes doesn't make sense to > > > me. The concept doesn't exist. The binding spec's DELETE > command is > > > asking that only one thing be done. If you can't do that one thing > you > > > need > > > > And that's why we're discussing this right now. The BIND spec requires a > > very specific DELETE behaviour, and some people do not seem to find that > > acceptable. Therefore the need to come to a consensus. > > I've only heard that servers are forced in to this behavior, not that bind aware > clients actually want this behavior. I'm arguing that servers can support this at the > WebDAV level. And if they can't they need to reject the DELETE request reject > BIND's to collections, or not claim that they are supporting BIND > functionality. a) what if they want to just implement RFC2518's DELETE? b) how do I not claim to support BIND functionality, when indeed I *do* implement the BIND live properties and the BIND method? > ... > > > I would hope it's possible though and that you wouldn't have to reject the > > > request. Even in a file system based server, I'd hope that the server could > > > simply unmap the collection and then in the background do the delete/move > > > of the whole tree incrementally if that were appropriate. > > > > But what if this simply is not what the system *should* do? > > I did say that it can happen in the background. It doesn't have to. It can be > done in the foreground. Yes. However: this was true for RFC2518's DELETE, yet after very long discussion the spec ended up with a non-atomic DELETE. I think this was correct (if only for the reason that an atomic delete on a large namespace partition can generate a transaction that's simply too big to handle properly). It seems that this is an attempt to "fix" RFC2518's DELETE through the backdoor. If this is the case, this should be made clear so that everybody is aware of that. > But no one has argued that they want partial results appearing as a result of a DELETE > in the presence of bindings. What they have argued is that that servers are forced to leave I do. > partial results. I have shown that in the situations mentioned, they are not forced to leave > partial results. > > But doing what I suggest is not the only acceptable approach. Server implementations can > claim not to support bindings, > reject BIND requests to collections, or reject DELETE requests that they aren't sure they can > complete. But they can't return partial deletion in the presences of multiple bindings. Again, the issue is NOT a DELETE in the presence of *multiple* bindings to a collection. The issue is a DELETE to a collection through it's only binding, which RFC2518 allows to be non-atomic, while the BIND draft requires it to be atomic. I think that's inacceptable. > > > But if it can't, IMO it needs to reject the request. > > > > It may not be able to reject the request until after it has started removing > > resources. There's a reason why DELETE isn't atomic in RFC2518. > > See the rest of my posting. You probably can detect if you will not be able to complete > the operation. If the MOVE completes, you have completed the > request. If it MOVE is different because it is just a namespace operation. DELETE may (may!) also destroy resources. > fails, you have not. This does not leave partial results. What you will still need > to do is clean up symbolic references.in to the tree. This might be possible to > do in a simple remapping request or you can do it iteratively... or both ways. This > can be done in a way that makes it unnecessary to have to return partial results. > Finally... the server probably will want to reclaim (perhaps only in the > absense of versioning) inaccessable resources. But that problem doesn't change the > semantics of the WebDAV operation. If it needs to do that, it can do that in the > foreground before completion (as it would have had to do anyway) or in the > background, but it doesn't effect what the UNBIND/DELETE method should return > to the client. So again: why is RFC2518's DELETE non-atomic? (I guess the answer is in the WebDAV Book Of Why). -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Tue Mar 4 19:36:03 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA17087 for ; Tue, 4 Mar 2003 19:36:02 -0500 (EST) Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id h250aj914724; Tue, 4 Mar 2003 19:36:45 -0500 (EST) Resent-Date: Tue, 4 Mar 2003 19:36:45 -0500 (EST) Resent-Message-Id: <200303050036.h250aj914724@frink.w3.org> Received: from tux.w3.org (tux [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id h250ahI14689 for ; Tue, 4 Mar 2003 19:36:43 -0500 (EST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by tux.w3.org (8.9.3/8.9.3) with SMTP id TAA10883 for ; Tue, 4 Mar 2003 19:36:42 -0500 Received: (qmail 9873 invoked by uid 0); 5 Mar 2003 00:36:11 -0000 Received: from p3EE2477A.dip.t-dialin.net (HELO lisa) (62.226.71.122) by mail.gmx.net (mp013-rz3) with SMTP; 5 Mar 2003 00:36:11 -0000 From: "Julian Reschke" To: "Jason Crawford" , "Julian Reschke" Cc: "Clemm, Geoff" , "'WebDAV'" Date: Wed, 5 Mar 2003 01:36:09 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 In-Reply-To: Importance: Normal Subject: RE: Move and Delete (was: bind draft issues) X-Archived-At: http://www.w3.org/mid/JIEGINCHMLABHJBIGKBCEEHEGKAA.julian.reschke@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7357 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit > From: Jason Crawford [mailto:nn683849@smallcue.com] > Sent: Wednesday, March 05, 2003 1:15 AM > To: Julian Reschke > Cc: Clemm, Geoff; 'WebDAV' > Subject: RE: Move and Delete (was: bind draft issues) > > > > > > > Anyway, the main issue for us is that we absolutely can not change the > > DELETE collection semantics (from what we have in RFC2518). > > Sure you can. The behavior the spec outlines is compliant with 2518. It may be compliant to RFC2518, but it may not be compliant to other non-WebDAV semantics of the server. Previously the server *was* able to support them, now it can't anymore. > It does not break 2518 compliant clients. But it does require that > server writers do some coding before they can claim to support > this new feature. Again: it's not a question of avoiding new code. A server that claims to understand bindings will need to have all the proper code in place anway. The question is whether the particular DELETE semantics is *desired*. Gentleman, we're (or at least some of us :-) aren't building servers just for fun, or only to implement specific RFCs. They also need to support private/proprietary semantics as well. WebDAV is just an (or another) open protocol that allows accessing these systems. Putting specific requirements into the specs that can't be implemented by these systems just means that these systems will - break the specs (leading to interop surprises), - do not offer the functionality through HTTP methods or - come up with proprietary protocol extensions. I think it's highly desirable to avoid this, and IMHO the solution is to give servers enough freedom so that they can make WebDAV and internal semantics compatible. Just like RFC2518 did. Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Tue Mar 4 19:37:23 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA17115 for ; Tue, 4 Mar 2003 19:37:18 -0500 (EST) Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id h250bdP14912; Tue, 4 Mar 2003 19:37:39 -0500 (EST) Resent-Date: Tue, 4 Mar 2003 19:37:39 -0500 (EST) Resent-Message-Id: <200303050037.h250bdP14912@frink.w3.org> Received: from tux.w3.org (tux [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id h250bcI14837 for ; Tue, 4 Mar 2003 19:37:38 -0500 (EST) Received: from sunbelt.seagull.net (user34.net540.or.sprint-hsd.net [65.40.225.34]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id TAA11356 for ; Tue, 4 Mar 2003 19:37:37 -0500 Received: (mail@localhost) by sunbelt.seagull.net (8.9.3) id QAA29748 sender nn683849@smallcue.com for w3c-dist-auth@w3.org; Tue, 4 Mar 2003 16:37:36 -0800 Received: from e5.ny.us.ibm.com (e5.ny.us.ibm.com [32.97.182.105]) by sunbelt.seagull.net (8.9.3) with ESMTP id QAA29725 sender obsfucated@us.ibm.com; Tue, 4 Mar 2003 16:37:34 -0800 Received: from northrelay04.pok.ibm.com (northrelay04.pok.ibm.com [9.56.224.206]) by e5.ny.us.ibm.com (8.12.8/8.12.2) with ESMTP id h250b3lO069424; Tue, 4 Mar 2003 19:37:03 -0500 Received: from d01ml243.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by northrelay04.pok.ibm.com (8.12.3/NCO/VER6.5) with ESMTP id h250axMp116956; Tue, 4 Mar 2003 19:37:00 -0500 To: "Julian Reschke" Cc: "Clemm, Geoff" , "'WebDAV'" X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: Jason Crawford Date: Tue, 4 Mar 2003 19:35:32 -0500 X-MIMETrack: Serialize by Router on D01ML243/01/M/IBM(Release 6.0.1 [IBM]|March 3, 2003) at 03/04/2003 19:37:00 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Subject: RE: Move and Delete (was: bind draft issues) X-Archived-At: http://www.w3.org/mid/OF0B4797B4.F5621482-ON05256CE0.00017C3A@us.ibm.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7358 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: > > Right. To claim BIND spec support, you have enhance the implementation to > > support *this* 2518 compliant approach.... or to avoid a situations where > > bind spec > > violations would happen. It's not unreasonable to expect one to have to > > add code > > in order to support a new feature like multiple-bindings. > > Actually, I'd have to remove code. > > The issue isn't that the server can't *technically* do this -- it's that the > this semantics isn't compatible with the existing DELETE semantics of our > system. Just removing the collection binding without checking that all > internal members may be deleted as well simply is *not* an option. Okay, so I'll stop talking about symbolic links :-) If there are multiple bindings to a collection and a WebDAV request asks you do DELETE one of them, will your server end up deleting all the descenent bindings also... or just the one requested? Is it not possible to freeze the system while your system checks this? Perhaps in a way similar to the way the Win32 has to before it allows a MOVE. In its case, is seems to find it acceptable to delay while it's checking this. It can cause a delay of a few seconds, but apparently the folks that implemented that found it acceptable. > So basically we have the choice between > > - supporting multiple bindings, but not the BIND method described in the > draft, or > - simply ignore this requirement. Or I suppose, "not allow multiple bindings to collections?" > I'd rather have a spec that I can implement without having to break a > specific requirement (in particular if i'm not convinced it adds value to my > use case). The other day I ran in to this in a non-WebDAV situation. I tried to move a huge directory. I found it frustrating to find that it was moving the files one at a time and ran in to a problem and left me with two partial trees. (This was across file systems.) I would have been similarly, although less problematically, frustrated if it had been a delete request. ------------------------------------------ Phone: 914-784-7569, ccjason@us.ibm.com I do not check nn621779@smallcue.com From w3c-dist-auth-request@w3.org Tue Mar 4 19:47:50 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA17266 for ; Tue, 4 Mar 2003 19:47:46 -0500 (EST) Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id h250mJT18581; Tue, 4 Mar 2003 19:48:19 -0500 (EST) Resent-Date: Tue, 4 Mar 2003 19:48:19 -0500 (EST) Resent-Message-Id: <200303050048.h250mJT18581@frink.w3.org> Received: from tux.w3.org (tux [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id h250mII18549 for ; Tue, 4 Mar 2003 19:48:18 -0500 (EST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by tux.w3.org (8.9.3/8.9.3) with SMTP id TAA15323 for ; Tue, 4 Mar 2003 19:48:17 -0500 Received: (qmail 26719 invoked by uid 0); 5 Mar 2003 00:48:07 -0000 Received: from p3EE2477A.dip.t-dialin.net (HELO lisa) (62.226.71.122) by mail.gmx.net (mp020-rz3) with SMTP; 5 Mar 2003 00:48:07 -0000 From: "Julian Reschke" To: "Jason Crawford" , "Julian Reschke" Cc: "Clemm, Geoff" , "'WebDAV'" Date: Wed, 5 Mar 2003 01:48:04 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 In-Reply-To: Importance: Normal Subject: RE: Move and Delete (was: bind draft issues) X-Archived-At: http://www.w3.org/mid/JIEGINCHMLABHJBIGKBCGEHFGKAA.julian.reschke@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7359 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit ailto:nn683849@smallcue.com] > Sent: Wednesday, March 05, 2003 1:36 AM > To: Julian Reschke > Cc: Clemm, Geoff; 'WebDAV' > Subject: RE: Move and Delete (was: bind draft issues) > > > > > > > > Right. To claim BIND spec support, you have enhance the > implementation > to > > > support *this* 2518 compliant approach.... or to avoid a situations > where > > > bind spec > > > violations would happen. It's not unreasonable to expect one to have > to > > > add code > > > in order to support a new feature like multiple-bindings. > > > > Actually, I'd have to remove code. > > > > The issue isn't that the server can't *technically* do this -- it's that > the > > this semantics isn't compatible with the existing DELETE > semantics of our > > system. Just removing the collection binding without checking that all > > internal members may be deleted as well simply is *not* an option. > > Okay, so I'll stop talking about symbolic links :-) > > If there are multiple bindings to a collection and a WebDAV request asks > you do DELETE one of them, will your server end up deleting all the > descenent bindings also... or just the one requested? If it's one of many bindings: just the binding. If it's the last binding, it will do a best effort DELETE as allowed in RFC2518. > Is it not possible to freeze the system while your system checks this? > Perhaps in a way similar to the way the Win32 has to before it allows > a MOVE. In its case, is seems to find it acceptable to delay while > it's checking this. It can cause a delay of a few seconds, but apparently > the folks that implemented that found it acceptable. A MOVE is a simple namespace operation. All it needs to do is check locks. A DELETE that cleans up in the foreground will need to check delete privileges on all descendants. This set can be very huge. I think it's an extremely bad idea to do this in a single transaction (yes, we tried). > > So basically we have the choice between > > > > - supporting multiple bindings, but not the BIND method described in the > > draft, or > > - simply ignore this requirement. > > Or I suppose, "not allow multiple bindings to collections?" Even then I can't complain conformance to the spec. It doesn't allow me to have a best effort DELETE on collections at all. > > I'd rather have a spec that I can implement without having to break a > > specific requirement (in particular if i'm not convinced it adds value to > my use case). > > The other day I ran in to this in a non-WebDAV situation. I tried to move > a huge > directory. I found it frustrating to find that it was moving the > files one > at a time and > ran in to a problem and left me with two partial trees. (This was across > file systems.) > I would have been similarly, although less problematically, frustrated if > it had been > a delete request. I notice you keep mention MOVE. We don't disagree here. MOVE must be atomic. If you can't MOVE, let if fail. If it fails the client still can do a COPY and the DELETE the source. DELETE is really a separate topic! Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Tue Mar 4 19:50:47 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA17313 for ; Tue, 4 Mar 2003 19:50:42 -0500 (EST) Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id h24NvFu00767; Tue, 4 Mar 2003 18:57:15 -0500 (EST) Resent-Date: Tue, 4 Mar 2003 18:57:15 -0500 (EST) Resent-Message-Id: <200303042357.h24NvFu00767@frink.w3.org> Received: from tux.w3.org (tux [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id h24Nv1I29935 for ; Tue, 4 Mar 2003 18:57:01 -0500 (EST) Received: from sunbelt.seagull.net (user34.net540.or.sprint-hsd.net [65.40.225.34]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id SAA14342 for ; Tue, 4 Mar 2003 18:56:53 -0500 Received: (mail@localhost) by sunbelt.seagull.net (8.9.3) id PAA27525 sender nn683849@smallcue.com for w3c-dist-auth@w3.org; Tue, 4 Mar 2003 15:56:52 -0800 Received: from e2.ny.us.ibm.com (e2.ny.us.ibm.com [32.97.182.102]) by sunbelt.seagull.net (8.9.3) with ESMTP id PAA27502 sender obsfucated@us.ibm.com; Tue, 4 Mar 2003 15:56:50 -0800 Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.56.224.150]) by e2.ny.us.ibm.com (8.12.8/8.12.2) with ESMTP id h24NuIWX100680; Tue, 4 Mar 2003 18:56:18 -0500 Received: from d01ml243.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by northrelay02.pok.ibm.com (8.12.3/NCO/VER6.5) with ESMTP id h24NuFrt043884; Tue, 4 Mar 2003 18:56:16 -0500 To: "Julian Reschke" Cc: "Clemm, Geoff" , "'WebDAV'" X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: Jason Crawford Date: Tue, 4 Mar 2003 18:55:31 -0500 X-MIMETrack: Serialize by Router on D01ML243/01/M/IBM(Release 6.0.1 [IBM]|March 3, 2003) at 03/04/2003 18:56:16 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Subject: RE: Move and Delete (was: bind draft issues) X-Archived-At: http://www.w3.org/mid/OF890D84D1.3B131C42-ON05256CDF.0060F7D2@us.ibm.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7351 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: On Tuesday, 03/04/2003 at 06:27 CET, "Julian Reschke" wrote: > > From: w3c-dist-auth-request@w3.org > > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Jason Crawford > > Sent: Tuesday, March 04, 2003 6:05 PM > > To: Julian Reschke > > Cc: Clemm, Geoff; 'WebDAV' > > Subject: RE: Move and Delete (was: bind draft issues) > > > > > > Just for interests sake, how many examples are there of > > > > repositories that do support multiple bindings to a collection > > > > but cannot support atomic DELETE/MOVE? > > > The Unix file system? > > > > Sort of. On most (all?) Unix file systems you can't create a > > It may depend on the implementation and your permissions. > > > hard link to a directory, but you can create a soft/symbolic link. > > In essence, all directories have one hard link and zero or more > > symbolic links to them. The symbolic link has no referential > > Wrong. > > Any directory has two hard links (it's entry in the parent, and the "." > entry as internal member). In addition, it gets hard links for each internal > member that is a directory (through it's ".." entry). You can check this > easily using ls. Thanks. But as far as the discussion goes, that back link to the parent doesn't change the point of the discussion. > > integrity, but that's probably not a major issue for a WebDAV > > server since the link can be traversed to confirm that the referee > > still exists. (See caveat below.) > > > > To simulate BIND support one can use symbolic links. In that > > I'd be surprised if you could. If you delete a directory, how do you detect > that there are symlinks left pointing to it? Yes, that can be difficult normally. IMO... If the server created the links, it can track them in a persisant database that it maintains. If they were already sitting around the file system when the server was installed, it probably doesn't need to track those since they weren't necessarily created as "bindings". If probably doesn't hurt to assume they are though when discovered. Again... this doesn't change the main point of all this. Atomic or not, you need to know about all the bindings to a resource. If you don't, you face the same problem atomic or not. > > Whether it's a symbolic link or a > > hard link being removed, you still need to do a fix up of symbolic > > links in to the subtree being removed. That obviously is not > > Why do I need to fix up symlinks? It's their nature that they are weak > links. I'd be surprised if they track another resource automatically. You're right. If the symbolic links were already there, then it's no big deal to let them break since they don't really represent a binding. But, I'm refering to an implementation where the symbolic links are used to implement some bindings. Those bindings within the deleted tree aren't allowed to break. So if you need to clean up some symbolic links to make sure the interior bindings don't break, then you must do that. > > > atomic, but at the WebDAV level you can block or remap access > > until that's completed.s > > I may be able to block that at the WebDAV level, but the WebDAV code may not > be able to block other access types (such as filesystem access). Yup. That's right. But if the WebDAV server has just moved it off to it's work directory, then it's unlikely that something else is going to interfering. Note... we're only trying to prevent access to the tree via that binding. When we did the move, we already prevented that. The folks that briefly won't be able to access the moved "files" are accessing them through symbolic links... and of course applications using symbolic links are already aware of the possibility of a symbolic link being broken. And for the most part, the link will only be broken briefly. And... none of this is visible at the level of WebDAV. It will look atomic to WebDAV clients. > > Or... you can just reject BIND requests to directories. :-) > > Even if I'd do that, the current wording of the BIND draft does not allow me > to keep my current RFC2518-compliant DELETE implementation. I feel this is a > problem. Right. To claim BIND spec support, you have enhance the implementation to support *this* 2518 compliant approach.... or to avoid a situations where bind spec violations would happen. It's not unreasonable to expect one to have to add code in order to support a new feature like multiple-bindings. ------------------------------------------ Phone: 914-784-7569, ccjason@us.ibm.com I do not check nn621779@smallcue.com From w3c-dist-auth-request@w3.org Tue Mar 4 20:20:21 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA17920 for ; Tue, 4 Mar 2003 20:20:21 -0500 (EST) Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id h251LBm24135; Tue, 4 Mar 2003 20:21:11 -0500 (EST) Resent-Date: Tue, 4 Mar 2003 20:21:11 -0500 (EST) Resent-Message-Id: <200303050121.h251LBm24135@frink.w3.org> Received: from tux.w3.org (tux [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id h251L1I23902 for ; Tue, 4 Mar 2003 20:21:01 -0500 (EST) Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by tux.w3.org (8.12.8/8.12.8) with ESMTP id h251InCo018995 for ; Tue, 4 Mar 2003 20:21:02 -0500 Received: from mail.xythos.com ([206.14.210.116]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id h25130I20444 for ; Tue, 4 Mar 2003 20:03:00 -0500 (EST) Received: from ravms by mail.xythos.com with mail-ok (Exim 3.36 #3) id 18qNK9-0003bx-00 for w3c-dist-auth@w3.org; Wed, 05 Mar 2003 01:03:57 +0000 Received: from ip-216-36-77-241.dsl.sjc.megapath.net ([216.36.77.241] helo=xythos.com) by mail.xythos.com with asmtp (Exim 3.36 #3) id 18qNK9-0003bm-00 for w3c-dist-auth@w3.org; Wed, 05 Mar 2003 01:03:57 +0000 Date: Tue, 4 Mar 2003 17:02:59 -0800 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) From: Brian Korver To: "WebDAV" Content-Transfer-Encoding: 7bit In-Reply-To: Message-Id: <350F9DF0-4EA6-11D7-8A8F-000393751598@xythos.com> X-Mailer: Apple Mail (2.551) Old-X-Envelope-To: w3c-dist-auth@w3.org Subject: Re: Operations not Atomic (was: bind draft issues) X-Archived-At: http://www.w3.org/mid/350F9DF0-4EA6-11D7-8A8F-000393751598@xythos.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7361 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit On Monday, March 3, 2003, at 02:09 PM, Julian Reschke wrote: > > Brian, > > I can follow for DELETE (see separate mail), but I'm at a loss about > how > MOVE and BIND can be non-atomic. Could you please explain? > > Julian Julian, Oops, I typed "BIND" when I meant "COPY". For MOVE, I mostly mean the DELETE that occurs when the MOVE causes an overwrite, although I could be convinced that ending up with 2 bindings to the collection in the event of an interrupted MOVE, while inadvisable, shouldn't be prohibited. -brian briank@xythos.com From w3c-dist-auth-request@w3.org Tue Mar 4 20:20:29 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA17935 for ; Tue, 4 Mar 2003 20:20:29 -0500 (EST) Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id h251L9L24026; Tue, 4 Mar 2003 20:21:09 -0500 (EST) Resent-Date: Tue, 4 Mar 2003 20:21:09 -0500 (EST) Resent-Message-Id: <200303050121.h251L9L24026@frink.w3.org> Received: from tux.w3.org (tux [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id h251L1I23875 for ; Tue, 4 Mar 2003 20:21:01 -0500 (EST) Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by tux.w3.org (8.12.8/8.12.8) with ESMTP id h251InCg018995 for ; Tue, 4 Mar 2003 20:21:01 -0500 Received: from mail.xythos.com ([206.14.210.116]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id h250wOI20013 for ; Tue, 4 Mar 2003 19:58:25 -0500 (EST) Received: from ravms by mail.xythos.com with mail-ok (Exim 3.36 #3) id 18qNFh-0003X3-00 for w3c-dist-auth@w3.org; Wed, 05 Mar 2003 00:59:21 +0000 Received: from ip-216-36-77-241.dsl.sjc.megapath.net ([216.36.77.241] helo=xythos.com) by mail.xythos.com with asmtp (Exim 3.36 #3) id 18qNFh-0003Ws-00 for w3c-dist-auth@w3.org; Wed, 05 Mar 2003 00:59:21 +0000 Date: Tue, 4 Mar 2003 16:58:23 -0800 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) From: Brian Korver To: WebDAV Content-Transfer-Encoding: 7bit In-Reply-To: Message-Id: <9081CCD4-4EA5-11D7-8A8F-000393751598@xythos.com> X-Mailer: Apple Mail (2.551) Old-X-Envelope-To: w3c-dist-auth@w3.org Subject: Re: Operations not Atomic (was: bind draft issues) X-Archived-At: http://www.w3.org/mid/9081CCD4-4EA5-11D7-8A8F-000393751598@xythos.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7360 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit On Monday, March 3, 2003, at 12:45 PM, Jason Crawford wrote: > > What non-atomic file system semantics in particular are you > refering to here that you feel should be acceptable but are > prohibited. Primarily delete, move, and copy on collections. -brian briank@xythos.com From w3c-dist-auth-request@w3.org Tue Mar 4 20:20:33 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA17950 for ; Tue, 4 Mar 2003 20:20:33 -0500 (EST) Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id h251LG424308; Tue, 4 Mar 2003 20:21:16 -0500 (EST) Resent-Date: Tue, 4 Mar 2003 20:21:16 -0500 (EST) Resent-Message-Id: <200303050121.h251LG424308@frink.w3.org> Received: from tux.w3.org (tux [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id h251L6I23978 for ; Tue, 4 Mar 2003 20:21:06 -0500 (EST) Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by tux.w3.org (8.12.8/8.12.8) with ESMTP id h251InCw018995 for ; Tue, 4 Mar 2003 20:21:06 -0500 Received: from mail.xythos.com ([206.14.210.116]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id h250uoI19880 for ; Tue, 4 Mar 2003 19:56:50 -0500 (EST) Received: from ravms by mail.xythos.com with mail-ok (Exim 3.36 #3) id 18qNEB-0003VF-00 for w3c-dist-auth@w3.org; Wed, 05 Mar 2003 00:57:47 +0000 Received: from ip-216-36-77-241.dsl.sjc.megapath.net ([216.36.77.241] helo=xythos.com) by mail.xythos.com with asmtp (Exim 3.36 #3) id 18qNEA-0003V4-00 for w3c-dist-auth@w3.org; Wed, 05 Mar 2003 00:57:46 +0000 Date: Tue, 4 Mar 2003 16:56:48 -0800 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) From: Brian Korver To: "'WebDAV'" Content-Transfer-Encoding: 7bit In-Reply-To: Message-Id: <581B4A92-4EA5-11D7-8A8F-000393751598@xythos.com> X-Mailer: Apple Mail (2.551) Old-X-Envelope-To: w3c-dist-auth@w3.org Subject: Re: Move and Delete (was: bind draft issues) X-Archived-At: http://www.w3.org/mid/581B4A92-4EA5-11D7-8A8F-000393751598@xythos.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7362 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Clemm, Geoff > Sent: Tuesday, March 04, 2003 4:11 PM > To: 'WebDAV' > Subject: RE: Move and Delete (was: bind draft issues) > > > An important thing to keep in mind is that we do not > expect all repositories to be capable of supporting the BIND > method (in particular, the creation of multiple bindings to > a collection). But we do require that a repository that > supports the BIND method also supports atomic DELETE/MOVE. > > Just for interests sake, how many examples are there of > repositories that do support multiple bindings to a collection > but cannot support atomic DELETE/MOVE? WFS (back when bindings were implemented). -brian briank@xythos.com From w3c-dist-auth-request@w3.org Tue Mar 4 20:22:08 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA18010 for ; Tue, 4 Mar 2003 20:22:08 -0500 (EST) Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id h251N3F26050; Tue, 4 Mar 2003 20:23:03 -0500 (EST) Resent-Date: Tue, 4 Mar 2003 20:23:03 -0500 (EST) Resent-Message-Id: <200303050123.h251N3F26050@frink.w3.org> Received: from tux.w3.org (tux [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id h251N1I26000 for ; Tue, 4 Mar 2003 20:23:01 -0500 (EST) Received: from mail.xythos.com ([206.14.210.116]) by tux.w3.org (8.12.8/8.12.8) with ESMTP id h251N09C020478 for ; Tue, 4 Mar 2003 20:23:01 -0500 Received: from ravms by mail.xythos.com with mail-ok (Exim 3.36 #3) id 18qNdR-0003x5-00 for w3c-dist-auth@w3.org; Wed, 05 Mar 2003 01:23:53 +0000 Received: from ip-216-36-77-241.dsl.sjc.megapath.net ([216.36.77.241] helo=xythos.com) by mail.xythos.com with asmtp (Exim 3.36 #3) id 18qNdQ-0003wu-00 for w3c-dist-auth@w3.org; Wed, 05 Mar 2003 01:23:52 +0000 Date: Tue, 4 Mar 2003 17:22:54 -0800 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) From: Brian Korver To: "'WebDAV'" Content-Transfer-Encoding: 7bit In-Reply-To: Message-Id: X-Mailer: Apple Mail (2.551) Old-X-Envelope-To: w3c-dist-auth@w3.org Subject: Re: Move and Delete (was: bind draft issues) X-Archived-At: http://www.w3.org/mid/FD53E8CB-4EA8-11D7-8A8F-000393751598@xythos.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7363 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit On Tuesday, March 4, 2003, at 04:48 PM, Julian Reschke wrote: [snip] > A MOVE is a simple namespace operation. All it needs to do is check > locks. > > A DELETE that cleans up in the foreground will need to check delete > privileges on all descendants. This set can be very huge. I think it's > an > extremely bad idea to do this in a single transaction (yes, we tried). [snip] Julian, I agree, but I think it's even worse than this. Semantically, MOVE is merely a simple namespace operation, but in practice it may be more than that. For instance, a move across unix filesystems must be implemented as a recursive copy (followed afterward by delete). -brian briank@xythos.com From w3c-dist-auth-request@w3.org Tue Mar 4 20:29:43 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA18200 for ; Tue, 4 Mar 2003 20:29:42 -0500 (EST) Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id h251Ufs29173; Tue, 4 Mar 2003 20:30:41 -0500 (EST) Resent-Date: Tue, 4 Mar 2003 20:30:41 -0500 (EST) Resent-Message-Id: <200303050130.h251Ufs29173@frink.w3.org> Received: from tux.w3.org (tux [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id h251UcI29137 for ; Tue, 4 Mar 2003 20:30:38 -0500 (EST) Received: from mail.xythos.com ([206.14.210.116]) by tux.w3.org (8.12.8/8.12.8) with ESMTP id h251Uc9C022809 for ; Tue, 4 Mar 2003 20:30:38 -0500 Received: from ravms by mail.xythos.com with mail-ok (Exim 3.36 #3) id 18qNkt-00045S-00 for w3c-dist-auth@w3.org; Wed, 05 Mar 2003 01:31:35 +0000 Received: from ip-216-36-77-241.dsl.sjc.megapath.net ([216.36.77.241] helo=xythos.com) by mail.xythos.com with asmtp (Exim 3.36 #3) id 18qNkt-00045H-00 for w3c-dist-auth@w3.org; Wed, 05 Mar 2003 01:31:35 +0000 Date: Tue, 4 Mar 2003 17:30:36 -0800 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) From: Brian Korver To: WebDAV Content-Transfer-Encoding: 7bit In-Reply-To: Message-Id: <1100C870-4EAA-11D7-8A8F-000393751598@xythos.com> X-Mailer: Apple Mail (2.551) Old-X-Envelope-To: w3c-dist-auth@w3.org Subject: Re: Bindings and Locks (was: bind draft issues) X-Archived-At: http://www.w3.org/mid/1100C870-4EAA-11D7-8A8F-000393751598@xythos.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7364 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit On Monday, March 3, 2003, at 01:50 PM, Clemm, Geoff wrote: > > I wouldn't want to tug any harder on that particular string (i.e. > defining precisely what "protect" means), or else we'd end up needing > to include most of the GULP (Grand Unified Locking Proposal) in the > binding draft. Given that I think that the binding draft needs to be more explicit about the behavior of locks, what would be so awful about including some of GULP? > Since we currently only have definitions of the semantics of write > locks, I try to avoid speculating on what semantics non-write locks > may have some day. > > Cheers, > Geoff -brian briank@xythos.com From w3c-dist-auth-request@w3.org Tue Mar 4 20:33:13 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA18275 for ; Tue, 4 Mar 2003 20:33:13 -0500 (EST) Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id h251Xxk00396; Tue, 4 Mar 2003 20:33:59 -0500 (EST) Resent-Date: Tue, 4 Mar 2003 20:33:59 -0500 (EST) Resent-Message-Id: <200303050133.h251Xxk00396@frink.w3.org> Received: from tux.w3.org (tux [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id h251XuI00363 for ; Tue, 4 Mar 2003 20:33:56 -0500 (EST) Received: from mail.xythos.com ([206.14.210.116]) by tux.w3.org (8.12.8/8.12.8) with ESMTP id h251Xt9C023415 for ; Tue, 4 Mar 2003 20:33:55 -0500 Received: from ravms by mail.xythos.com with mail-ok (Exim 3.36 #3) id 18qNo4-0004AH-00 for w3c-dist-auth@w3.org; Wed, 05 Mar 2003 01:34:52 +0000 Received: from ip-216-36-77-241.dsl.sjc.megapath.net ([216.36.77.241] helo=xythos.com) by mail.xythos.com with asmtp (Exim 3.36 #3) id 18qNo4-0004A6-00 for w3c-dist-auth@w3.org; Wed, 05 Mar 2003 01:34:52 +0000 Date: Tue, 4 Mar 2003 17:33:53 -0800 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) From: Brian Korver To: WebDAV Content-Transfer-Encoding: 7bit In-Reply-To: Message-Id: <868F0795-4EAA-11D7-8A8F-000393751598@xythos.com> X-Mailer: Apple Mail (2.551) Old-X-Envelope-To: w3c-dist-auth@w3.org Subject: Re: Bindings and Locks (was: bind draft issues) X-Archived-At: http://www.w3.org/mid/868F0795-4EAA-11D7-8A8F-000393751598@xythos.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7365 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit On Tuesday, March 4, 2003, at 12:13 PM, Clemm, Geoff wrote: > The only argument for not doing so is that being more > specific probably requires including the entire GULP > document, since that is needed to clearly define the difference > between locking a resource and protecting a URL. > But I don't think we want to include that information by > copy in each protocol extension document, so I think it > is more appropriate to get it into 2518bis, and refer to > it from the other documents. > > Cheers, > Geoff Geoff, As GULP frequently defines things in terms of bindings, the text as-is seems more appropriate to the binding spec. -brian briank@xythos.com From w3c-dist-auth-request@w3.org Tue Mar 4 21:27:09 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA19365 for ; Tue, 4 Mar 2003 21:27:09 -0500 (EST) Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id h252QDq17907; Tue, 4 Mar 2003 21:26:13 -0500 (EST) Resent-Date: Tue, 4 Mar 2003 21:26:13 -0500 (EST) Resent-Message-Id: <200303050226.h252QDq17907@frink.w3.org> Received: from tux.w3.org (tux [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id h252QBI17875 for ; Tue, 4 Mar 2003 21:26:11 -0500 (EST) Received: from sus-ma1it31.rational.com (sus-ma1it31.rational.com [130.213.73.33]) by tux.w3.org (8.12.8/8.12.8) with ESMTP id h252QA9C001876 for ; Tue, 4 Mar 2003 21:26:11 -0500 Received: from sus-ma1it00.rational.com ([10.64.1.25]) by 10.64.1.33 with InterScan Messaging Security Suite; Tue, 04 Mar 2003 21:09:53 -0500 Received: by sus-ma1it00.rational.com with Internet Mail Service (5.5.2656.59) id ; Tue, 4 Mar 2003 21:24:48 -0500 Message-ID: From: "Clemm, Geoff" To: WebDAV Date: Tue, 4 Mar 2003 21:24:47 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain Subject: RE: Bindings and Locks (was: bind draft issues) X-Archived-At: http://www.w3.org/mid/E4F2D33B98DF7E4880884B9F0E6FDEE2021C5988@SUS-MA1IT01 Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7366 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: GULP is actually pretty short, so I probably wouldn't mind adding a copy to the binding protocol *if* we get consensus that GULP correctly defines the WebDAV locking semantics. What I don't want to have happen is for the binding protocol to become a draft standard and then have RFC-2518bis decide that some GULP variant is needed, and have the binding RFC conflict with 2518bis RFC (with the resulting interoperability problems inevitably appearing). So I'll take this opportunity to again ask everyone to either explicitly support the current GULP proposal, or identify any problems in semantics or terminology, so we can get this language committed to 2518bis ASAP. Cheers, Geoff -----Original Message----- From: Brian Korver [mailto:briank@xythos.com] Sent: Tuesday, March 04, 2003 8:31 PM To: WebDAV Subject: Re: Bindings and Locks (was: bind draft issues) On Monday, March 3, 2003, at 01:50 PM, Clemm, Geoff wrote: > > I wouldn't want to tug any harder on that particular string (i.e. > defining precisely what "protect" means), or else we'd end up needing > to include most of the GULP (Grand Unified Locking Proposal) in the > binding draft. Given that I think that the binding draft needs to be more explicit about the behavior of locks, what would be so awful about including some of GULP? > Since we currently only have definitions of the semantics of write > locks, I try to avoid speculating on what semantics non-write locks > may have some day. > > Cheers, > Geoff -brian briank@xythos.com From w3c-dist-auth-request@w3.org Tue Mar 4 21:34:47 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA19495 for ; Tue, 4 Mar 2003 21:34:46 -0500 (EST) Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id h252Yt620527; Tue, 4 Mar 2003 21:34:55 -0500 (EST) Resent-Date: Tue, 4 Mar 2003 21:34:55 -0500 (EST) Resent-Message-Id: <200303050234.h252Yt620527@frink.w3.org> Received: from tux.w3.org (tux [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id h252YrI20493 for ; Tue, 4 Mar 2003 21:34:53 -0500 (EST) Received: from mail.xythos.com ([206.14.210.116]) by tux.w3.org (8.12.8/8.12.8) with ESMTP id h252Yq9C003177 for ; Tue, 4 Mar 2003 21:34:53 -0500 Received: from ravms by mail.xythos.com with mail-ok (Exim 3.36 #3) id 18qOky-0004xR-00; Wed, 05 Mar 2003 02:35:44 +0000 Received: from ip-216-36-77-241.dsl.sjc.megapath.net ([216.36.77.241] helo=xythos.com) by mail.xythos.com with asmtp (Exim 3.36 #3) id 18qOky-0004xG-00; Wed, 05 Mar 2003 02:35:44 +0000 Date: Tue, 4 Mar 2003 18:34:45 -0800 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: WebDAV To: "Clemm, Geoff" From: Brian Korver In-Reply-To: Message-Id: <07025085-4EB3-11D7-8A8F-000393751598@xythos.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) Old-X-Envelope-To: w3c-dist-auth@w3.org, gclemm@rational.com Subject: Re: Bindings and Locks (was: bind draft issues) X-Archived-At: http://www.w3.org/mid/07025085-4EB3-11D7-8A8F-000393751598@xythos.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7367 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit On Tuesday, March 4, 2003, at 06:24 PM, Clemm, Geoff wrote: > > GULP is actually pretty short, so I probably wouldn't mind > adding a copy to the binding protocol *if* we get consensus > that GULP correctly defines the WebDAV locking semantics. > What I don't want to have happen is for the binding protocol > to become a draft standard and then have RFC-2518bis decide > that some GULP variant is needed, and have the binding RFC > conflict with 2518bis RFC (with the resulting interoperability > problems inevitably appearing). > > So I'll take this opportunity to again ask everyone to either > explicitly support the current GULP proposal, or identify any > problems in semantics or terminology, so we can get this > language committed to 2518bis ASAP. > > Cheers, > Geoff Geoff, I'll get you comments RSN. -brian briank@xythos.com From w3c-dist-auth-request@w3.org Tue Mar 4 21:45:58 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA19661 for ; Tue, 4 Mar 2003 21:45:58 -0500 (EST) Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id h252cv622011; Tue, 4 Mar 2003 21:38:57 -0500 (EST) Resent-Date: Tue, 4 Mar 2003 21:38:57 -0500 (EST) Resent-Message-Id: <200303050238.h252cv622011@frink.w3.org> Received: from tux.w3.org (tux [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id h252cuI21976 for ; Tue, 4 Mar 2003 21:38:56 -0500 (EST) Received: from mail.xythos.com ([206.14.210.116]) by tux.w3.org (8.12.8/8.12.8) with ESMTP id h252ct9C003676 for ; Tue, 4 Mar 2003 21:38:56 -0500 Received: from ravms by mail.xythos.com with mail-ok (Exim 3.36 #3) id 18qOou-0004zB-00 for w3c-dist-auth@w3c.org; Wed, 05 Mar 2003 02:39:48 +0000 Received: from [198.144.203.248] (helo=xythoslap) by mail.xythos.com with asmtp (Exim 3.36 #3) id 18qOou-0004z0-00 for w3c-dist-auth@w3c.org; Wed, 05 Mar 2003 02:39:48 +0000 From: "Lisa Dusseault" To: "Webdav WG" Date: Tue, 4 Mar 2003 18:38:50 -0800 Message-ID: <069201c2e2c0$5afa0c50$f8cb90c6@xythoslap> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4024 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal Old-X-Envelope-To: w3c-dist-auth@w3c.org Subject: FW: response to comment ... X-Archived-At: http://www.w3.org/mid/069201c2e2c0$5afa0c50$f8cb90c6@xythoslap Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7368 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit > From: "Julian Reschke" > Date: Tue Mar 4, 2003 1:17:18 PM US/Pacific > Subject: RE: bind draft issues [snip] > Yes. Clearly they aren't. RFC2518 never talked about "URL properties". > DAV:displayname is a property of the resource, and therefore it must be > independant of the URL through which the property is accessed. > > BTW: I'm not aware of implementations that actually support multiple > bindings and show this behaviour. Here's an example. WFS used to support bindings, but we pulled them out because they were hard to maintain and nobody was using them, and the standard wasn't going anywhere at the time. Now, as then, WFS sets the display name to be the base name from the path part of the URL. So for us resourcename is a property which is constant as long as the resource's URL is constant, and changes when the URL changes. I don't know if we'd change this if we did support bindings. I have some vague memory that some Microsoft WebDAV client expects the resourcename to change to be equivalent to the last path segment of the URL, and that client behaves badly if that's not true. However, I'm afraid I can't substantiate this as I've forgotten all the details. Does that ring a bell for anybody else? Lisa From w3c-dist-auth-request@w3.org Wed Mar 5 02:28:28 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA18769 for ; Wed, 5 Mar 2003 02:28:28 -0500 (EST) Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id h257SQq19625; Wed, 5 Mar 2003 02:28:26 -0500 (EST) Resent-Date: Wed, 5 Mar 2003 02:28:26 -0500 (EST) Resent-Message-Id: <200303050728.h257SQq19625@frink.w3.org> Received: from tux.w3.org (tux [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id h257SOI19593 for ; Wed, 5 Mar 2003 02:28:24 -0500 (EST) Received: from sunbelt.seagull.net (user34.net540.or.sprint-hsd.net [65.40.225.34]) by tux.w3.org (8.12.8/8.12.8) with ESMTP id h257SB9C021376 for ; Wed, 5 Mar 2003 02:28:23 -0500 Received: (mail@localhost) by sunbelt.seagull.net (8.9.3) id XAA26524 sender nn683849@smallcue.com for w3c-dist-auth@w3.org; Tue, 4 Mar 2003 23:28:10 -0800 Received: from e2.ny.us.ibm.com (e2.ny.us.ibm.com [32.97.182.102]) by sunbelt.seagull.net (8.9.3) with ESMTP id XAA26508 sender obsfucated@us.ibm.com; Tue, 4 Mar 2003 23:28:08 -0800 Received: from northrelay04.pok.ibm.com (northrelay04.pok.ibm.com [9.56.224.206]) by e2.ny.us.ibm.com (8.12.8/8.12.2) with ESMTP id h257RbWX037564; Wed, 5 Mar 2003 02:27:37 -0500 Received: from d01ml243.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by northrelay04.pok.ibm.com (8.12.3/NCO/VER6.5) with ESMTP id h257RZMp172448; Wed, 5 Mar 2003 02:27:35 -0500 To: Brian Korver Cc: WebDAV X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: Jason Crawford Date: Wed, 5 Mar 2003 02:25:28 -0500 X-MIMETrack: Serialize by Router on D01ML243/01/M/IBM(Release 6.0.1 [IBM]|March 4, 2003) at 03/05/2003 02:27:35 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Subject: Re: Bindings and Locks (was: bind draft issues) X-Archived-At: http://www.w3.org/mid/OF8B8E963C.504642D7-ON85256CE0.00285205@us.ibm.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7369 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: On Tuesday, 03/04/2003 at 05:33 PST, Brian Korver wrote: > On Tuesday, March 4, 2003, at 12:13 PM, Clemm, Geoff wrote: > > The only argument for not doing so is that being more > > specific probably requires including the entire GULP > > document, since that is needed to clearly define the difference > > between locking a resource and protecting a URL. > > But I don't think we want to include that information by > > copy in each protocol extension document, so I think it > > is more appropriate to get it into 2518bis, and refer to > > it from the other documents. > > > > Cheers, > > Geoff > > Geoff, > > As GULP frequently defines things in terms of bindings, > the text as-is seems more appropriate to the binding > spec. Yah. That's a toughie. It lists things that are both important to the binding spec and the base 2518 spec. But it also apparently covers things that are outside the realm of each of these specs. It might need to be submitted as a seperate document that clarifies (and "unifies") both specs after they come out. ------------------------------------------ Phone: 914-784-7569, ccjason@us.ibm.com I do not check nn621779@smallcue.com From w3c-dist-auth-request@w3.org Wed Mar 5 02:52:07 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA21049 for ; Wed, 5 Mar 2003 02:52:07 -0500 (EST) Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id h257rAg22629; Wed, 5 Mar 2003 02:53:10 -0500 (EST) Resent-Date: Wed, 5 Mar 2003 02:53:10 -0500 (EST) Resent-Message-Id: <200303050753.h257rAg22629@frink.w3.org> Received: from tux.w3.org (tux [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id h257r8I22594 for ; Wed, 5 Mar 2003 02:53:08 -0500 (EST) Received: from ZASBSJNB002.SBSZA.NET ([196.44.70.100]) by tux.w3.org (8.12.8/8.12.8) with ESMTP id h257r49C024642 for ; Wed, 5 Mar 2003 02:53:05 -0500 Received: by zasbsjnb002.sbsza.net with Internet Mail Service (5.5.2653.19) id ; Wed, 5 Mar 2003 09:36:40 +0200 Message-ID: <377CAE249FD6C247BD5DF6B2DB5C9960AB45D0@zasbsjnb032.sbsza.net> From: "Verma, Nitin" To: "'w3c-dist-auth@w3.org'" Date: Wed, 5 Mar 2003 09:36:21 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Subject: RE: Bindings and Locks (was: bind draft issues) X-Archived-At: http://www.w3.org/mid/377CAE249FD6C247BD5DF6B2DB5C9960AB45D0@zasbsjnb032.sbsza.net Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7370 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Is anybody tell me... how to unsubscribe from this group. Am sick and tired of getting useless mails. Thanks and Regards, Nitin -----Original Message----- From: Jason Crawford [mailto:nn683849@smallcue.com] Sent: Wednesday, March 05, 2003 9:25 AM To: Brian Korver Cc: WebDAV Subject: Re: Bindings and Locks (was: bind draft issues) On Tuesday, 03/04/2003 at 05:33 PST, Brian Korver wrote: > On Tuesday, March 4, 2003, at 12:13 PM, Clemm, Geoff wrote: > > The only argument for not doing so is that being more > > specific probably requires including the entire GULP > > document, since that is needed to clearly define the difference > > between locking a resource and protecting a URL. > > But I don't think we want to include that information by > > copy in each protocol extension document, so I think it > > is more appropriate to get it into 2518bis, and refer to > > it from the other documents. > > > > Cheers, > > Geoff > > Geoff, > > As GULP frequently defines things in terms of bindings, > the text as-is seems more appropriate to the binding > spec. Yah. That's a toughie. It lists things that are both important to the binding spec and the base 2518 spec. But it also apparently covers things that are outside the realm of each of these specs. It might need to be submitted as a seperate document that clarifies (and "unifies") both specs after they come out. ------------------------------------------ Phone: 914-784-7569, ccjason@us.ibm.com I do not check nn621779@smallcue.com From w3c-dist-auth-request@w3.org Wed Mar 5 03:21:24 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA21507 for ; Wed, 5 Mar 2003 03:21:24 -0500 (EST) Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id h258MD525041; Wed, 5 Mar 2003 03:22:13 -0500 (EST) Resent-Date: Wed, 5 Mar 2003 03:22:13 -0500 (EST) Resent-Message-Id: <200303050822.h258MD525041@frink.w3.org> Received: from tux.w3.org (tux [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id h258M7I25004 for ; Wed, 5 Mar 2003 03:22:07 -0500 (EST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by tux.w3.org (8.12.8/8.12.8) with SMTP id h258M79C028068 for ; Wed, 5 Mar 2003 03:22:07 -0500 Received: (qmail 23981 invoked by uid 0); 5 Mar 2003 08:22:00 -0000 Received: from p3EE2477A.dip.t-dialin.net (HELO lisa) (62.226.71.122) by mail.gmx.net (mp013-rz3) with SMTP; 5 Mar 2003 08:22:00 -0000 From: "Julian Reschke" To: "Brian Korver" , "'WebDAV'" Date: Wed, 5 Mar 2003 09:21:57 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Subject: RE: Move and Delete (was: bind draft issues) X-Archived-At: http://www.w3.org/mid/JIEGINCHMLABHJBIGKBCEEIAGKAA.julian.reschke@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7371 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Brian Korver > Sent: Wednesday, March 05, 2003 2:23 AM > To: 'WebDAV' > Subject: Re: Move and Delete (was: bind draft issues) > > > > On Tuesday, March 4, 2003, at 04:48 PM, Julian Reschke wrote: > [snip] > > A MOVE is a simple namespace operation. All it needs to do is check > > locks. > > > > A DELETE that cleans up in the foreground will need to check delete > > privileges on all descendants. This set can be very huge. I think it's > > an > > extremely bad idea to do this in a single transaction (yes, we tried). > [snip] > > Julian, > > I agree, but I think it's even worse than this. Semantically, > MOVE is merely a simple namespace operation, but in practice > it may be more than that. For instance, a move across unix > filesystems must be implemented as a recursive copy (followed > afterward by delete). Brian, in the Unix API, you don't move at all -- you link() then unlink(). "mv" is just a user command that does it's best when the files reside in different partitions. I think WebDAV MOVE should just fail if the resource cannot really be moved (preserving all dead & live properties), and fail otherwise. Just like in the Unix API, the caller *then* can decide to do a COPY/DELETE instead. Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Wed Mar 5 03:31:38 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA21664 for ; Wed, 5 Mar 2003 03:31:38 -0500 (EST) Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id h258Wdd28121; Wed, 5 Mar 2003 03:32:39 -0500 (EST) Resent-Date: Wed, 5 Mar 2003 03:32:39 -0500 (EST) Resent-Message-Id: <200303050832.h258Wdd28121@frink.w3.org> Received: from tux.w3.org (tux [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id h258WbI28089 for ; Wed, 5 Mar 2003 03:32:37 -0500 (EST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by tux.w3.org (8.12.8/8.12.8) with SMTP id h258Wa9C030422 for ; Wed, 5 Mar 2003 03:32:37 -0500 Received: (qmail 2084 invoked by uid 0); 5 Mar 2003 08:32:30 -0000 Received: from p3EE2477A.dip.t-dialin.net (HELO lisa) (62.226.71.122) by mail.gmx.net (mp017-rz3) with SMTP; 5 Mar 2003 08:32:30 -0000 From: "Julian Reschke" To: "Clemm, Geoff" , "WebDAV" Date: Wed, 5 Mar 2003 09:32:27 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Subject: RE: Bindings and Locks (was: bind draft issues) X-Archived-At: http://www.w3.org/mid/JIEGINCHMLABHJBIGKBCOEIBGKAA.julian.reschke@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7373 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit I explicitly support GULP being added RFC2518. In particular, I ask everybody to either state - if they find GULP technically incorrect (so that we can fix it) or - otherwise explain why it can't be added to RFC2518bis as is. Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 > -----Original Message----- > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Clemm, Geoff > Sent: Wednesday, March 05, 2003 3:25 AM > To: WebDAV > Subject: RE: Bindings and Locks (was: bind draft issues) > > > > GULP is actually pretty short, so I probably wouldn't mind > adding a copy to the binding protocol *if* we get consensus > that GULP correctly defines the WebDAV locking semantics. > What I don't want to have happen is for the binding protocol > to become a draft standard and then have RFC-2518bis decide > that some GULP variant is needed, and have the binding RFC > conflict with 2518bis RFC (with the resulting interoperability > problems inevitably appearing). > > So I'll take this opportunity to again ask everyone to either > explicitly support the current GULP proposal, or identify any > problems in semantics or terminology, so we can get this > language committed to 2518bis ASAP. > > Cheers, > Geoff > > -----Original Message----- > From: Brian Korver [mailto:briank@xythos.com] > Sent: Tuesday, March 04, 2003 8:31 PM > To: WebDAV > Subject: Re: Bindings and Locks (was: bind draft issues) > > > > On Monday, March 3, 2003, at 01:50 PM, Clemm, Geoff wrote: > > > > I wouldn't want to tug any harder on that particular string (i.e. > > defining precisely what "protect" means), or else we'd end up needing > > to include most of the GULP (Grand Unified Locking Proposal) in the > > binding draft. > > Given that I think that the binding draft needs to be more > explicit about the behavior of locks, what would be so awful > about including some of GULP? > > > > Since we currently only have definitions of the semantics of write > > locks, I try to avoid speculating on what semantics non-write locks > > may have some day. > > > > Cheers, > > Geoff > > -brian > briank@xythos.com > From w3c-dist-auth-request@w3.org Wed Mar 5 03:34:03 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA21745 for ; Wed, 5 Mar 2003 03:34:03 -0500 (EST) Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id h258V4527775; Wed, 5 Mar 2003 03:31:04 -0500 (EST) Resent-Date: Wed, 5 Mar 2003 03:31:04 -0500 (EST) Resent-Message-Id: <200303050831.h258V4527775@frink.w3.org> Received: from tux.w3.org (tux [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id h258V1I27739 for ; Wed, 5 Mar 2003 03:31:01 -0500 (EST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by tux.w3.org (8.12.8/8.12.8) with SMTP id h258V09C030184 for ; Wed, 5 Mar 2003 03:31:01 -0500 Received: (qmail 5474 invoked by uid 0); 5 Mar 2003 08:30:54 -0000 Received: from p3EE2477A.dip.t-dialin.net (HELO lisa) (62.226.71.122) by mail.gmx.net (mp023-rz3) with SMTP; 5 Mar 2003 08:30:54 -0000 From: "Julian Reschke" To: "Brian Korver" , "WebDAV" Date: Wed, 5 Mar 2003 09:30:51 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) Importance: Normal In-Reply-To: <868F0795-4EAA-11D7-8A8F-000393751598@xythos.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Subject: RE: Bindings and Locks (was: bind draft issues) X-Archived-At: http://www.w3.org/mid/JIEGINCHMLABHJBIGKBCKEIBGKAA.julian.reschke@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7372 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Brian Korver > Sent: Wednesday, March 05, 2003 2:34 AM > To: WebDAV > Subject: Re: Bindings and Locks (was: bind draft issues) > > > > On Tuesday, March 4, 2003, at 12:13 PM, Clemm, Geoff wrote: > > The only argument for not doing so is that being more > > specific probably requires including the entire GULP > > document, since that is needed to clearly define the difference > > between locking a resource and protecting a URL. > > But I don't think we want to include that information by > > copy in each protocol extension document, so I think it > > is more appropriate to get it into 2518bis, and refer to > > it from the other documents. > > > > Cheers, > > Geoff > > Geoff, > > As GULP frequently defines things in terms of bindings, > the text as-is seems more appropriate to the binding > spec. Strong disagreement. The way to "fix" this is either to add the term "binding" to RFC2518, or to use the term "internal member" instead (which *will* make the text harder to read). Let's see: -- - A lock either directly or indirectly locks a resource. - A LOCK request creates a new lock, and the resource identified by the request-URL is directly locked by that lock. The "lock-root" of the new lock is the request-URL. If at the time of the request, the request-URL is not mapped to a resource, a new resource with no content MUST be created by the request. - If a collection is directly locked by a depth:infinity lock, all members of that collection (other than the collection itself) are indirectly locked by that lock. In particular, if a binding (1) to a resource is added to a collection that is locked by a depth:infinity lock, and if the resource is not locked by that lock, then the resource becomes indirectly locked by that lock. Conversely, if a resource is indirectly locked with a depth:infinity lock, and if the result of removing a binding (2) to the resource is that the resource is no longer a member of the collection that is directly locked by that lock, then the resource is no longer locked by that lock. - An UNLOCK request deletes the lock with the specified lock token. The request-URL of the request MUST identify a resource that is either directly or indirectly locked by that lock. After a lock is deleted, no resource is locked by that lock. - A lock token is "submitted" in a request when it appears in an If header tagged-list whose tag is the lock-root of the lock. - If a request would modify the content for a locked resource, a dead property of a locked resource, a live property that is defined to be lockable for a locked resource, or a binding (3) of a locked collection, the request MUST fail unless the lock-token for that lock is submitted in the request. - If a request causes a directly locked resource to no longer be mapped to the lock-root of that lock, then the request MUST fail unless the lock-token for that lock is submitted in the request. If the request succeeds, then that lock MUST have been deleted by that request. - If a request would cause a resource to be locked by two different exclusive locks, the request MUST fail. --- So, (1) "binding to a resource" -> "internal member" (2) "binding to the resource" -> "internal member URL identifying that resource" (3) "binding of a locked collection" -> "internal member URL in a locked collection" should be equivalent, just using RFC2518 terminology. Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Wed Mar 5 03:37:23 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA21783 for ; Wed, 5 Mar 2003 03:37:23 -0500 (EST) Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id h258cXT00035; Wed, 5 Mar 2003 03:38:33 -0500 (EST) Resent-Date: Wed, 5 Mar 2003 03:38:33 -0500 (EST) Resent-Message-Id: <200303050838.h258cXT00035@frink.w3.org> Received: from tux.w3.org (tux [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id h258cRI29949 for ; Wed, 5 Mar 2003 03:38:27 -0500 (EST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by tux.w3.org (8.12.8/8.12.8) with SMTP id h258cP9C031736 for ; Wed, 5 Mar 2003 03:38:26 -0500 Received: (qmail 10824 invoked by uid 0); 5 Mar 2003 08:38:20 -0000 Received: from p3EE2477A.dip.t-dialin.net (HELO lisa) (62.226.71.122) by mail.gmx.net (mp018-rz3) with SMTP; 5 Mar 2003 08:38:20 -0000 From: "Julian Reschke" To: "Lisa Dusseault" , "Webdav WG" Date: Wed, 5 Mar 2003 09:38:17 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) Importance: Normal In-Reply-To: <069201c2e2c0$5afa0c50$f8cb90c6@xythoslap> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Subject: RE: response to comment ... X-Archived-At: http://www.w3.org/mid/JIEGINCHMLABHJBIGKBCIEICGKAA.julian.reschke@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7374 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Lisa Dusseault > Sent: Wednesday, March 05, 2003 3:39 AM > To: Webdav WG > Subject: FW: response to comment ... > > > > > > > From: "Julian Reschke" > > Date: Tue Mar 4, 2003 1:17:18 PM US/Pacific > > Subject: RE: bind draft issues > [snip] > > Yes. Clearly they aren't. RFC2518 never talked about "URL properties". > > DAV:displayname is a property of the resource, and therefore it must > be > > independant of the URL through which the property is accessed. > > > > BTW: I'm not aware of implementations that actually support multiple > > bindings and show this behaviour. > > Here's an example. WFS used to support bindings, but we pulled them out > because they were hard to maintain and nobody was using them, and the > standard wasn't going anywhere at the time. > > Now, as then, WFS sets the display name to be the base name from the > path part of the URL. So for us resourcename is a property which is > constant as long as the resource's URL is constant, and changes when the > URL changes. I don't know if we'd change this if we did support > bindings. Well, I consider this a bug. It's not supported by the spec. > I have some vague memory that some Microsoft WebDAV client expects the > resourcename to change to be equivalent to the last path segment of the > URL, and that client behaves badly if that's not true. However, I'm > afraid I can't substantiate this as I've forgotten all the details. > Does that ring a bell for anybody else? The Webfolder client indeed displays the displayname instead of the last URI segment when present (and even uses in in the "href" column instead of the real URI). This works well when - the last part of the displayname consistently is identical to the last URI segment (mod. URI escaping) (IIS) - DAV:displayname is just a dead property that most of the time isn't set (moddav) The easiest fix is not to return a DAV:displayname when there is no specific one. Apache/moddav shows that this works, and I'm not aware of any Microsoft client failing in this case. If we consider this an interop problem, we should deprecate DAV:displayname (because that's the only way to "fix" the webfolder client) and come up with a new property with the same semantics. Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Wed Mar 5 03:39:06 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA21832 for ; Wed, 5 Mar 2003 03:39:06 -0500 (EST) Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id h258eMl00312; Wed, 5 Mar 2003 03:40:22 -0500 (EST) Resent-Date: Wed, 5 Mar 2003 03:40:22 -0500 (EST) Resent-Message-Id: <200303050840.h258eMl00312@frink.w3.org> Received: from tux.w3.org (tux [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id h258eKI00275 for ; Wed, 5 Mar 2003 03:40:20 -0500 (EST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by tux.w3.org (8.12.8/8.12.8) with SMTP id h258eJ9C032010 for ; Wed, 5 Mar 2003 03:40:20 -0500 Received: (qmail 31622 invoked by uid 0); 5 Mar 2003 08:40:14 -0000 Received: from p3EE2477A.dip.t-dialin.net (HELO lisa) (62.226.71.122) by mail.gmx.net (mp014-rz3) with SMTP; 5 Mar 2003 08:40:14 -0000 From: "Julian Reschke" To: "Jason Crawford" , "Brian Korver" Cc: "WebDAV" Date: Wed, 5 Mar 2003 09:40:11 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Subject: RE: Bindings and Locks (was: bind draft issues) X-Archived-At: http://www.w3.org/mid/JIEGINCHMLABHJBIGKBCMEICGKAA.julian.reschke@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7375 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Jason Crawford > Sent: Wednesday, March 05, 2003 8:25 AM > To: Brian Korver > Cc: WebDAV > Subject: Re: Bindings and Locks (was: bind draft issues) > > > > > > > On Tuesday, 03/04/2003 at 05:33 PST, Brian Korver > wrote: > > On Tuesday, March 4, 2003, at 12:13 PM, Clemm, Geoff wrote: > > > The only argument for not doing so is that being more > > > specific probably requires including the entire GULP > > > document, since that is needed to clearly define the difference > > > between locking a resource and protecting a URL. > > > But I don't think we want to include that information by > > > copy in each protocol extension document, so I think it > > > is more appropriate to get it into 2518bis, and refer to > > > it from the other documents. > > > > > > Cheers, > > > Geoff > > > > Geoff, > > > > As GULP frequently defines things in terms of bindings, > > the text as-is seems more appropriate to the binding > > spec. > > Yah. That's a toughie. It lists things that are both important to the > binding spec and the base 2518 spec. But it also apparently > covers things that are outside the realm of each of these specs. > It might need to be submitted as a seperate document that clarifies > (and "unifies") both specs after they come out. Again strong disagreement. Each of the paragraphs in GULP is needed to correctly explain RFC2518 locking semantics. If you think there's something which *isn't* needed for RFC2518, please point to it :-) Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Wed Mar 5 03:45:12 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA21920 for ; Wed, 5 Mar 2003 03:45:11 -0500 (EST) Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id h258gb900648; Wed, 5 Mar 2003 03:42:37 -0500 (EST) Resent-Date: Wed, 5 Mar 2003 03:42:37 -0500 (EST) Resent-Message-Id: <200303050842.h258gb900648@frink.w3.org> Received: from tux.w3.org (tux [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id h258gXI00580 for ; Wed, 5 Mar 2003 03:42:33 -0500 (EST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by tux.w3.org (8.12.8/8.12.8) with SMTP id h258gW9C032266 for ; Wed, 5 Mar 2003 03:42:32 -0500 Received: (qmail 3613 invoked by uid 0); 5 Mar 2003 08:42:27 -0000 Received: from p3EE2477A.dip.t-dialin.net (HELO lisa) (62.226.71.122) by mail.gmx.net (mp017-rz3) with SMTP; 5 Mar 2003 08:42:27 -0000 From: "Julian Reschke" To: "Brian Korver" , "WebDAV" Date: Wed, 5 Mar 2003 09:42:23 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) Importance: Normal In-Reply-To: <350F9DF0-4EA6-11D7-8A8F-000393751598@xythos.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Subject: RE: Operations not Atomic (was: bind draft issues) X-Archived-At: http://www.w3.org/mid/JIEGINCHMLABHJBIGKBCEEIDGKAA.julian.reschke@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7376 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Brian Korver > Sent: Wednesday, March 05, 2003 2:03 AM > To: WebDAV > Subject: Re: Operations not Atomic (was: bind draft issues) > > > > On Monday, March 3, 2003, at 02:09 PM, Julian Reschke wrote: > > > > Brian, > > > > I can follow for DELETE (see separate mail), but I'm at a loss about > > how > > MOVE and BIND can be non-atomic. Could you please explain? > > > > Julian > > Julian, > > Oops, I typed "BIND" when I meant "COPY". > > For MOVE, I mostly mean the DELETE that occurs when the MOVE causes > an overwrite, although I could be convinced that ending up with 2 > bindings to the collection in the event of an interrupted MOVE, > while inadvisable, shouldn't be prohibited. That's indeed a problem. All "overwrite" operations require a DELETE (this also applies to BIND (!)), so having them atomic when the target is a collection has the same problems has the collection DELETE itself. Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Wed Mar 5 08:57:45 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA00264 for ; Wed, 5 Mar 2003 08:57:45 -0500 (EST) Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id h25Dwh320118; Wed, 5 Mar 2003 08:58:43 -0500 (EST) Resent-Date: Wed, 5 Mar 2003 08:58:43 -0500 (EST) Resent-Message-Id: <200303051358.h25Dwh320118@frink.w3.org> Received: from tux.w3.org (tux [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id h25DwfI20086 for ; Wed, 5 Mar 2003 08:58:41 -0500 (EST) Received: from sus-ma1it31.rational.com (sus-ma1it31.rational.com [130.213.73.33]) by tux.w3.org (8.12.8/8.12.8) with ESMTP id h25Dwf9C002053 for ; Wed, 5 Mar 2003 08:58:41 -0500 Received: from sus-ma1it00.rational.com ([10.64.1.25]) by 10.64.1.33 with InterScan Messaging Security Suite; Wed, 05 Mar 2003 08:42:27 -0500 Received: by sus-ma1it00.rational.com with Internet Mail Service (5.5.2656.59) id ; Wed, 5 Mar 2003 08:58:34 -0500 Message-ID: From: "Clemm, Geoff" To: "'WebDAV'" Date: Wed, 5 Mar 2003 08:58:33 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain Subject: RE: Move and Delete (was: bind draft issues) X-Archived-At: http://www.w3.org/mid/E4F2D33B98DF7E4880884B9F0E6FDEE2021C59E2@SUS-MA1IT01 Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7377 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: I agree with Julian. The protocol that is used to implement something like "mv" should be an operation that preserves all characteristics of the objects, so the client (not the server) can decide whether to accept the information lossage inherent in copy/delete. Cheers, Geoff -----Original Message----- From: Julian Reschke [mailto:julian.reschke@gmx.de] > From: Brian Korver > > On Tuesday, March 4, 2003, at 04:48 PM, Julian Reschke wrote: > [snip] > > A MOVE is a simple namespace operation. All it needs to do is check > > locks. > > > > A DELETE that cleans up in the foreground will need to check delete > > privileges on all descendants. This set can be very huge. I think it's > > an > > extremely bad idea to do this in a single transaction (yes, we tried). > [snip] > > Julian, > > I agree, but I think it's even worse than this. Semantically, > MOVE is merely a simple namespace operation, but in practice > it may be more than that. For instance, a move across unix > filesystems must be implemented as a recursive copy (followed > afterward by delete). Brian, in the Unix API, you don't move at all -- you link() then unlink(). "mv" is just a user command that does it's best when the files reside in different partitions. I think WebDAV MOVE should just fail if the resource cannot really be moved (preserving all dead & live properties), and fail otherwise. Just like in the Unix API, the caller *then* can decide to do a COPY/DELETE instead. Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Wed Mar 5 11:05:56 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09207 for ; Wed, 5 Mar 2003 11:05:55 -0500 (EST) Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id h25G6Qb03618; Wed, 5 Mar 2003 11:06:26 -0500 (EST) Resent-Date: Wed, 5 Mar 2003 11:06:26 -0500 (EST) Resent-Message-Id: <200303051606.h25G6Qb03618@frink.w3.org> Received: from tux.w3.org (tux [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id h25G6OI03582 for ; Wed, 5 Mar 2003 11:06:24 -0500 (EST) Received: from mail.xythos.com ([206.14.210.116]) by tux.w3.org (8.12.8/8.12.8) with ESMTP id h25G6O9C003217 for ; Wed, 5 Mar 2003 11:06:24 -0500 Received: from ravms by mail.xythos.com with mail-ok (Exim 3.36 #3) id 18qbQX-00009G-00; Wed, 05 Mar 2003 16:07:29 +0000 Received: from [198.144.203.248] (helo=xythoslap) by mail.xythos.com with asmtp (Exim 3.36 #3) id 18qbQX-000094-00; Wed, 05 Mar 2003 16:07:29 +0000 From: "Lisa Dusseault" To: "'Julian Reschke'" , "'Webdav WG'" Date: Wed, 5 Mar 2003 08:06:23 -0800 Message-ID: <071801c2e331$2b4fd4f0$f8cb90c6@xythoslap> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4024 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal In-Reply-To: Old-X-Envelope-To: julian.reschke@gmx.de, w3c-dist-auth@w3c.org Subject: RE: response to comment ... X-Archived-At: http://www.w3.org/mid/071801c2e331$2b4fd4f0$f8cb90c6@xythoslap Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7378 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit > > Now, as then, WFS sets the display name to be the base name from the > > path part of the URL. So for us resourcename is a property which is > > constant as long as the resource's URL is constant, and > changes when the > > URL changes. I don't know if we'd change this if we did support > > bindings. > > Well, I consider this a bug. It's not supported by the spec. I've always thought this was against the spirit of the WebDAV specification. However, I don't think it can be considered a bug. RFC2518 doesn't require displayname to have a particular value, or to be writable, or to be empty. > The Webfolder client indeed displays the displayname instead > of the last URI > segment when present (and even uses in in the "href" column > instead of the > real URI). This works well when > > - the last part of the displayname consistently is identical > to the last URI segment (mod. URI escaping) (IIS) Yeah, this is what WFS does, I believe we consciously mimicked IIS in order to work well with Web Folders. > - DAV:displayname is just a dead property that most of the > time isn't set (moddav) Do you know what happens when it is set to some value other than the last URI segment? Does any client get confused when the URI ends in "index.html" but the displayname shows "Index of files here"? More interestingly, what happens if there are two resources in a collection which have the same resourcename -- does this confuse the client deeply? > If we consider this an interop problem, we should deprecate > DAV:displayname > (because that's the only way to "fix" the webfolder client) > and come up with > a new property with the same semantics. That might be cool. Exchange 2000 uses a "subject" property across many types of resources (emails, appointments, maybe even Office documents) to serve as a truly user-displayable value or "friendly name". Its value is not unique within a collection, so multiple emails in the same folder can have the subject "RE: response to comment ...". And it is writable, not protected, yet it is given a default value selected by the server when the resource is created, so that a collection doesn't show a lot of blank friendly names. Lisa From w3c-dist-auth-request@w3.org Wed Mar 5 11:15:31 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09872 for ; Wed, 5 Mar 2003 11:15:30 -0500 (EST) Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id h25GGLK12810; Wed, 5 Mar 2003 11:16:21 -0500 (EST) Resent-Date: Wed, 5 Mar 2003 11:16:21 -0500 (EST) Resent-Message-Id: <200303051616.h25GGLK12810@frink.w3.org> Received: from tux.w3.org (tux [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id h25GGKI12778 for ; Wed, 5 Mar 2003 11:16:20 -0500 (EST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by tux.w3.org (8.12.8/8.12.8) with SMTP id h25GGJ9C009136 for ; Wed, 5 Mar 2003 11:16:19 -0500 Received: (qmail 8924 invoked by uid 0); 5 Mar 2003 16:16:13 -0000 Received: from mail.greenbytes.de (HELO lisa) (217.5.201.10) by mail.gmx.net (mp016-rz3) with SMTP; 5 Mar 2003 16:16:13 -0000 From: "Julian Reschke" To: "Lisa Dusseault" , "'Julian Reschke'" , "'Webdav WG'" Date: Wed, 5 Mar 2003 17:16:13 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal In-Reply-To: <071801c2e331$2b4fd4f0$f8cb90c6@xythoslap> Subject: RE: response to comment ... X-Archived-At: http://www.w3.org/mid/JIEGINCHMLABHJBIGKBCGEJOGKAA.julian.reschke@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7379 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Lisa Dusseault > Sent: Wednesday, March 05, 2003 5:06 PM > To: 'Julian Reschke'; 'Webdav WG' > Subject: RE: response to comment ... > > > > > > Now, as then, WFS sets the display name to be the base name from the > > > path part of the URL. So for us resourcename is a property which is > > > constant as long as the resource's URL is constant, and > > changes when the > > > URL changes. I don't know if we'd change this if we did support > > > bindings. > > > > Well, I consider this a bug. It's not supported by the spec. > > I've always thought this was against the spirit of the WebDAV > specification. However, I don't think it can be considered a bug. > RFC2518 doesn't require displayname to have a particular value, or to be > writable, or to be empty. Correct. But it says that properties are on resources, not on URLs: "Properties are pieces of data that describe the state of a resource. Properties are data about data." > > The Webfolder client indeed displays the displayname instead of the last URI > > segment when present (and even uses in in the "href" column instead of the > > real URI). This works well when > > > > - the last part of the displayname consistently is identical > > to the last URI segment (mod. URI escaping) (IIS) > > Yeah, this is what WFS does, I believe we consciously mimicked IIS in > order to work well with Web Folders. > > > - DAV:displayname is just a dead property that most of the > > time isn't set (moddav) > > Do you know what happens when it is set to some value other than the > last URI segment? Does any client get confused when the URI ends in > "index.html" but the displayname shows "Index of files here"? Not that I'm aware of. > More interestingly, what happens if there are two resources in a > collection which have the same resourcename -- does this confuse the > client deeply? Not the (webfolder) client, but certainly the user :-) > > If we consider this an interop problem, we should deprecate DAV:displayname > > (because that's the only way to "fix" the webfolder client) and come up with > > a new property with the same semantics. > > That might be cool. Exchange 2000 uses a "subject" property across many > types of resources (emails, appointments, maybe even Office documents) > to serve as a truly user-displayable value or "friendly name". Its > value is not unique within a collection, so multiple emails in the same > folder can have the subject "RE: response to comment ...". And it is > writable, not protected, yet it is given a default value selected by the > server when the resource is created, so that a collection doesn't show a > lot of blank friendly names. OK. Maybe we should investigate that. Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Wed Mar 5 11:25:26 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10651 for ; Wed, 5 Mar 2003 11:25:21 -0500 (EST) Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id h25GPxR14948; Wed, 5 Mar 2003 11:25:59 -0500 (EST) Resent-Date: Wed, 5 Mar 2003 11:25:59 -0500 (EST) Resent-Message-Id: <200303051625.h25GPxR14948@frink.w3.org> Received: from tux.w3.org (tux [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id h25GPvI14916 for ; Wed, 5 Mar 2003 11:25:57 -0500 (EST) Received: from sunbelt.seagull.net (user34.net540.or.sprint-hsd.net [65.40.225.34]) by tux.w3.org (8.12.8/8.12.8) with ESMTP id h25GPq9C013733 for ; Wed, 5 Mar 2003 11:25:54 -0500 Received: (mail@localhost) by sunbelt.seagull.net (8.9.3) id IAA31168 sender nn683849@smallcue.com for w3c-dist-auth@w3.org; Wed, 5 Mar 2003 08:25:51 -0800 Received: from e2.ny.us.ibm.com (e2.ny.us.ibm.com [32.97.182.102]) by sunbelt.seagull.net (8.9.3) with ESMTP id IAA31152 sender obsfucated@us.ibm.com; Wed, 5 Mar 2003 08:25:50 -0800 Received: from northrelay04.pok.ibm.com (northrelay04.pok.ibm.com [9.56.224.206]) by e2.ny.us.ibm.com (8.12.8/8.12.2) with ESMTP id h25GPIWX049690; Wed, 5 Mar 2003 11:25:18 -0500 Received: from d01ml243.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by northrelay04.pok.ibm.com (8.12.3/NCO/VER6.5) with ESMTP id h25GPFMT076640; Wed, 5 Mar 2003 11:25:15 -0500 To: "Julian Reschke" Cc: "WebDAV" X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: Jason Crawford Date: Wed, 5 Mar 2003 11:22:43 -0500 X-MIMETrack: Serialize by Router on D01ML243/01/M/IBM(Release 6.0.1 [IBM]|March 4, 2003) at 03/05/2003 11:25:15 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Subject: RE: Bindings and Locks (was: bind draft issues) X-Archived-At: http://www.w3.org/mid/OFB6E2D312.1E78B313-ON85256CE0.0057EC00@us.ibm.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7380 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: > > Yah. That's a toughie. It lists things that are both important to the > > binding spec and the base 2518 spec. But it also apparently > > covers things that are outside the realm of each of these specs. > > It might need to be submitted as a seperate document that clarifies > > (and "unifies") both specs after they come out. > > Again strong disagreement. Is it ever not "strong"? :-) > Each of the paragraphs in GULP is needed to correctly explain RFC2518 > locking semantics. If you think there's something which *isn't* needed for > RFC2518, please point to it :-) I step back from what I said. I think it is possible to put the current GULP document in 2518bis. ------------------------------------------ Phone: 914-784-7569, ccjason@us.ibm.com I do not check nn621779@smallcue.com From w3c-dist-auth-request@w3.org Wed Mar 5 14:45:09 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24755 for ; Wed, 5 Mar 2003 14:45:09 -0500 (EST) Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id h25JjVT27755; Wed, 5 Mar 2003 14:45:31 -0500 (EST) Resent-Date: Wed, 5 Mar 2003 14:45:31 -0500 (EST) Resent-Message-Id: <200303051945.h25JjVT27755@frink.w3.org> Received: from tux.w3.org (tux [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id h25JjTI27693 for ; Wed, 5 Mar 2003 14:45:29 -0500 (EST) Received: from mail.xythos.com ([206.14.210.116]) by tux.w3.org (8.12.8/8.12.8) with ESMTP id h25JjS9C002281 for ; Wed, 5 Mar 2003 14:45:28 -0500 Received: from ravms by mail.xythos.com with mail-ok (Exim 3.36 #3) id 18qeqb-00049c-00 for w3c-dist-auth@w3.org; Wed, 05 Mar 2003 19:46:37 +0000 Received: from ip-216-36-77-241.dsl.sjc.megapath.net ([216.36.77.241] helo=xythos.com) by mail.xythos.com with asmtp (Exim 3.36 #3) id 18qeqb-00049K-00 for w3c-dist-auth@w3.org; Wed, 05 Mar 2003 19:46:37 +0000 Date: Wed, 5 Mar 2003 11:45:26 -0800 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) From: Brian Korver To: "WebDAV" Content-Transfer-Encoding: 7bit In-Reply-To: Message-Id: <034FAB2A-4F43-11D7-8A8F-000393751598@xythos.com> X-Mailer: Apple Mail (2.551) Old-X-Envelope-To: w3c-dist-auth@w3.org Subject: Re: Bindings and Locks (was: bind draft issues) X-Archived-At: http://www.w3.org/mid/034FAB2A-4F43-11D7-8A8F-000393751598@xythos.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7381 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit On Wednesday, March 5, 2003, at 12:32 AM, Julian Reschke wrote: > > I explicitly support GULP being added RFC2518. > > In particular, I ask everybody to either state > > - if they find GULP technically incorrect (so that we can fix it) or > > - otherwise explain why it can't be added to RFC2518bis as is. > > Julian Julian, I'm not convinced that the bindings that you see in 2518 are really there. In fact, I'm worried that inserting the semantics of bindings into 2518bis will prohibit the use of WebDAV in contexts where these bindings cannot be supported. -brian briank@xythos.com From w3c-dist-auth-request@w3.org Wed Mar 5 14:54:41 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25284 for ; Wed, 5 Mar 2003 14:54:41 -0500 (EST) Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id h25JtjA00389; Wed, 5 Mar 2003 14:55:45 -0500 (EST) Resent-Date: Wed, 5 Mar 2003 14:55:45 -0500 (EST) Resent-Message-Id: <200303051955.h25JtjA00389@frink.w3.org> Received: from tux.w3.org (tux [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id h25JthI00348 for ; Wed, 5 Mar 2003 14:55:43 -0500 (EST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by tux.w3.org (8.12.8/8.12.8) with SMTP id h25Jtg9C006127 for ; Wed, 5 Mar 2003 14:55:43 -0500 Received: (qmail 26183 invoked by uid 0); 5 Mar 2003 19:55:37 -0000 Received: from pD950C257.dip.t-dialin.net (HELO lisa) (217.80.194.87) by mail.gmx.net (mp018-rz3) with SMTP; 5 Mar 2003 19:55:37 -0000 From: "Julian Reschke" To: "Brian Korver" , "WebDAV" Date: Wed, 5 Mar 2003 20:55:35 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 In-Reply-To: <034FAB2A-4F43-11D7-8A8F-000393751598@xythos.com> Importance: Normal Subject: RE: Bindings and Locks (was: bind draft issues) X-Archived-At: http://www.w3.org/mid/JIEGINCHMLABHJBIGKBCEEKLGKAA.julian.reschke@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7382 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Brian Korver > Sent: Wednesday, March 05, 2003 8:45 PM > To: WebDAV > Subject: Re: Bindings and Locks (was: bind draft issues) > > > > On Wednesday, March 5, 2003, at 12:32 AM, Julian Reschke wrote: > > > > I explicitly support GULP being added RFC2518. > > > > In particular, I ask everybody to either state > > > > - if they find GULP technically incorrect (so that we can fix it) or > > > > - otherwise explain why it can't be added to RFC2518bis as is. > > > > Julian > > Julian, > > I'm not convinced that the bindings that you see in 2518 > are really there. In fact, I'm worried that inserting the Again, quoting Geoff quoting RFC2616: >In case there remains any question about whether HTTP supports >multiple URIs being mapped to the same resource, the following quote >appears in section 9.6 of RFC-2616: > >"A single resource MAY be identified by many different URIs. For > example, an article might have a URI for identifying "the current > version" which is separate from the URI identifying each > particular version. In this case, a PUT request on a general URI > might result in several other URIs being defined by the origin > server." So, please be more specific about where you see that problem. > semantics of bindings into 2518bis will prohibit the use > of WebDAV in contexts where these bindings cannot be > supported. How? Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Wed Mar 5 15:05:30 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25988 for ; Wed, 5 Mar 2003 15:05:30 -0500 (EST) Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id h25K6ff05548; Wed, 5 Mar 2003 15:06:41 -0500 (EST) Resent-Date: Wed, 5 Mar 2003 15:06:41 -0500 (EST) Resent-Message-Id: <200303052006.h25K6ff05548@frink.w3.org> Received: from tux.w3.org (tux [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id h25K6SI04818 for ; Wed, 5 Mar 2003 15:06:29 -0500 (EST) Received: from mail.xythos.com ([206.14.210.116]) by tux.w3.org (8.12.8/8.12.8) with ESMTP id h25K669C011394 for ; Wed, 5 Mar 2003 15:06:11 -0500 Received: from ravms by mail.xythos.com with mail-ok (Exim 3.36 #3) id 18qfAU-0004dr-00 for w3c-dist-auth@w3.org; Wed, 05 Mar 2003 20:07:10 +0000 Received: from ip-216-36-77-241.dsl.sjc.megapath.net ([216.36.77.241] helo=xythos.com) by mail.xythos.com with asmtp (Exim 3.36 #3) id 18qfAU-0004df-00 for w3c-dist-auth@w3.org; Wed, 05 Mar 2003 20:07:10 +0000 Date: Wed, 5 Mar 2003 12:06:00 -0800 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) From: Brian Korver To: "'WebDAV'" Content-Transfer-Encoding: 7bit In-Reply-To: Message-Id: X-Mailer: Apple Mail (2.551) Old-X-Envelope-To: w3c-dist-auth@w3.org Subject: Re: Move and Delete (was: bind draft issues) X-Archived-At: http://www.w3.org/mid/E27033AA-4F45-11D7-8A8F-000393751598@xythos.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7383 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit On Wednesday, March 5, 2003, at 12:21 AM, Julian Reschke wrote: > Brian, > > in the Unix API, you don't move at all -- you link() then unlink(). > "mv" is > just a user command that does it's best when the files reside in > different > partitions. I think WebDAV MOVE should just fail if the resource cannot > really be moved (preserving all dead & live properties), and fail > otherwise. > Just like in the Unix API, the caller *then* can decide to do a > COPY/DELETE > instead. > > Julian Julian, I don't think we can push this behavior out to the client. For the sake of illustration, let's take an hypothetical repository built on a unix filesystem: Filesystem 1K-blocks Used Avail Capacity Mounted on /dev/da0s1f 992239 372 912488 0% /users/briank /dev/da0s1g 3048942 2509636 295391 89% /users/briank/MP3s Now, let's say I've got a file sitting at /users/briank/tmp/groovy.mp3 that I'd like to copy to my MP3s collection. What is my WebDAV client going to do? We have two cases: 1) The server is "smart" and performs a copy/delete Ok, in this case my client issues a MOVE, the server performs a copy/delete (NOT rename(2) [link/unlink]). But notice, this is a server-side copy/delete, not client-side. 2) The server isn't "smart" and thus the client must perform a COPY/DELETE What happens here? The client issues a MOVE, but this must fail because rename(2) doesn't work across file systems. What error does the server return to tell the client that a COPY/DELETE must be performed instead? What is the point of this extra round trip? -brian briank@xythos.com From w3c-dist-auth-request@w3.org Wed Mar 5 15:33:33 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27389 for ; Wed, 5 Mar 2003 15:33:32 -0500 (EST) Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id h25KYVO16448; Wed, 5 Mar 2003 15:34:31 -0500 (EST) Resent-Date: Wed, 5 Mar 2003 15:34:31 -0500 (EST) Resent-Message-Id: <200303052034.h25KYVO16448@frink.w3.org> Received: from tux.w3.org (tux [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id h25KYSI16411 for ; Wed, 5 Mar 2003 15:34:29 -0500 (EST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by tux.w3.org (8.12.8/8.12.8) with SMTP id h25KYS9C026364 for ; Wed, 5 Mar 2003 15:34:28 -0500 Received: (qmail 6982 invoked by uid 0); 5 Mar 2003 20:34:23 -0000 Received: from pD950C257.dip.t-dialin.net (HELO lisa) (217.80.194.87) by mail.gmx.net (mp016-rz3) with SMTP; 5 Mar 2003 20:34:23 -0000 From: "Julian Reschke" To: "Brian Korver" , "'WebDAV'" Date: Wed, 5 Mar 2003 21:34:21 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 In-Reply-To: Importance: Normal Subject: RE: Move and Delete (was: bind draft issues) X-Archived-At: http://www.w3.org/mid/JIEGINCHMLABHJBIGKBCIEKOGKAA.julian.reschke@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7384 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Brian Korver > Sent: Wednesday, March 05, 2003 9:06 PM > To: 'WebDAV' > Subject: Re: Move and Delete (was: bind draft issues) > > > > On Wednesday, March 5, 2003, at 12:21 AM, Julian Reschke wrote: > > Brian, > > > > in the Unix API, you don't move at all -- you link() then unlink(). "mv" is > > just a user command that does it's best when the files reside in different > > partitions. I think WebDAV MOVE should just fail if the resource cannot > > really be moved (preserving all dead & live properties), and fail > > otherwise. > > Just like in the Unix API, the caller *then* can decide to do a COPY/DELETE > > instead. > > > > Julian > > Julian, > > I don't think we can push this behavior out to the client. > > For the sake of illustration, let's take an hypothetical > repository built on a unix filesystem: > > Filesystem 1K-blocks Used Avail Capacity Mounted on > /dev/da0s1f 992239 372 912488 0% /users/briank > /dev/da0s1g 3048942 2509636 295391 89% /users/briank/MP3s > > Now, let's say I've got a file sitting at /users/briank/tmp/groovy.mp3 > that I'd like to copy to my MP3s collection. What is my WebDAV I guess you meant to say "move" here. > client going to do? We have two cases: > > 1) The server is "smart" and performs a copy/delete > > Ok, in this case my client issues a MOVE, the server performs > a copy/delete (NOT rename(2) [link/unlink]). But notice, this is > a server-side copy/delete, not client-side. > > 2) The server isn't "smart" and thus the client must > perform a COPY/DELETE > > What happens here? The client issues a MOVE, but this > must fail because rename(2) doesn't work across file > systems. What error does the server return to tell > the client that a COPY/DELETE must be performed instead? I guess we want a specific precondition failure that can be signaled. For instance, DAV:preserve-versioning-properties. > What is the point of this extra round trip? The same thing as the failure you'll get upon trying to rename. MOVE is *not* the same thing (or should not be the same thing) as COPY/DELETE. If a MOVE can't preserve the resource's live properties, it should fail. Now I *do* agree that in many cases clients will actually *want* the "weak" MOVE. So maybe we should consider supporting both (either by a new method, or by adding parameters to MOVE). Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Wed Mar 5 16:47:51 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01238 for ; Wed, 5 Mar 2003 16:47:51 -0500 (EST) Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id h25LmVP05189; Wed, 5 Mar 2003 16:48:31 -0500 (EST) Resent-Date: Wed, 5 Mar 2003 16:48:31 -0500 (EST) Resent-Message-Id: <200303052148.h25LmVP05189@frink.w3.org> Received: from tux.w3.org (tux [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id h25LmTI05157 for ; Wed, 5 Mar 2003 16:48:29 -0500 (EST) Received: from mail.xythos.com ([206.14.210.116]) by tux.w3.org (8.12.8/8.12.8) with ESMTP id h25LmS9C021768 for ; Wed, 5 Mar 2003 16:48:29 -0500 Received: from ravms by mail.xythos.com with mail-ok (Exim 3.36 #3) id 18qgle-0006ex-00 for w3c-dist-auth@w3.org; Wed, 05 Mar 2003 21:49:38 +0000 Received: from ip-216-36-77-241.dsl.sjc.megapath.net ([216.36.77.241] helo=xythos.com) by mail.xythos.com with asmtp (Exim 3.36 #3) id 18qgle-0006em-00 for w3c-dist-auth@w3.org; Wed, 05 Mar 2003 21:49:38 +0000 Date: Wed, 5 Mar 2003 13:48:27 -0800 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) From: Brian Korver To: "'WebDAV'" Content-Transfer-Encoding: 7bit In-Reply-To: Message-Id: <32753DE6-4F54-11D7-8A8F-000393751598@xythos.com> X-Mailer: Apple Mail (2.551) Old-X-Envelope-To: w3c-dist-auth@w3.org Subject: Re: Move and Delete (was: bind draft issues) X-Archived-At: http://www.w3.org/mid/32753DE6-4F54-11D7-8A8F-000393751598@xythos.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7385 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit On Wednesday, March 5, 2003, at 12:34 PM, Julian Reschke wrote: >> >> Julian, >> >> I don't think we can push this behavior out to the client. >> >> For the sake of illustration, let's take an hypothetical >> repository built on a unix filesystem: >> >> Filesystem 1K-blocks Used Avail Capacity Mounted on >> /dev/da0s1f 992239 372 912488 0% /users/briank >> /dev/da0s1g 3048942 2509636 295391 89% >> /users/briank/MP3s >> >> Now, let's say I've got a file sitting at /users/briank/tmp/groovy.mp3 >> that I'd like to copy to my MP3s collection. What is my WebDAV > > I guess you meant to say "move" here. Oops. Yes. > >> client going to do? We have two cases: >> >> 1) The server is "smart" and performs a copy/delete >> >> Ok, in this case my client issues a MOVE, the server performs >> a copy/delete (NOT rename(2) [link/unlink]). But notice, this >> is >> a server-side copy/delete, not client-side. >> >> 2) The server isn't "smart" and thus the client must >> perform a COPY/DELETE >> >> What happens here? The client issues a MOVE, but this >> must fail because rename(2) doesn't work across file >> systems. What error does the server return to tell >> the client that a COPY/DELETE must be performed instead? > > I guess we want a specific precondition failure that can be signaled. > For > instance, DAV:preserve-versioning-properties. > >> What is the point of this extra round trip? > > The same thing as the failure you'll get upon trying to rename. MOVE is > *not* the same thing (or should not be the same thing) as COPY/DELETE. > If a > MOVE can't preserve the resource's live properties, it should fail. > > Now I *do* agree that in many cases clients will actually *want* the > "weak" > MOVE. So maybe we should consider supporting both (either by a new > method, > or by adding parameters to MOVE). That's an interesting idea. -brian briank@xythos.com From w3c-dist-auth-request@w3.org Wed Mar 5 17:26:17 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02827 for ; Wed, 5 Mar 2003 17:26:12 -0500 (EST) Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id h25MPTi01760; Wed, 5 Mar 2003 17:25:29 -0500 (EST) Resent-Date: Wed, 5 Mar 2003 17:25:29 -0500 (EST) Resent-Message-Id: <200303052225.h25MPTi01760@frink.w3.org> Received: from tux.w3.org (tux [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id h25MPRI01728 for ; Wed, 5 Mar 2003 17:25:27 -0500 (EST) Received: from mail.xythos.com ([206.14.210.116]) by tux.w3.org (8.12.8/8.12.8) with ESMTP id h25MP59C009133 for ; Wed, 5 Mar 2003 17:25:05 -0500 Received: from ravms by mail.xythos.com with mail-ok (Exim 3.36 #3) id 18qhL2-0007Ta-00 for w3c-dist-auth@w3.org; Wed, 05 Mar 2003 22:26:12 +0000 Received: from ip-216-36-77-241.dsl.sjc.megapath.net ([216.36.77.241] helo=xythos.com) by mail.xythos.com with asmtp (Exim 3.36 #3) id 18qhL1-0007TH-00 for w3c-dist-auth@w3.org; Wed, 05 Mar 2003 22:26:11 +0000 Date: Wed, 5 Mar 2003 14:24:59 -0800 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) From: Brian Korver To: "WebDAV" Content-Transfer-Encoding: 7bit In-Reply-To: Message-Id: <4D3481C8-4F59-11D7-8A8F-000393751598@xythos.com> X-Mailer: Apple Mail (2.551) Old-X-Envelope-To: w3c-dist-auth@w3.org Subject: Re: Bindings and Locks (was: bind draft issues) X-Archived-At: http://www.w3.org/mid/4D3481C8-4F59-11D7-8A8F-000393751598@xythos.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7386 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit On Wednesday, March 5, 2003, at 11:55 AM, Julian Reschke wrote: > Again, quoting Geoff quoting RFC2616: > >> In case there remains any question about whether HTTP supports >> multiple URIs being mapped to the same resource, the following quote >> appears in section 9.6 of RFC-2616: >> >> "A single resource MAY be identified by many different URIs. For >> example, an article might have a URI for identifying "the current >> version" which is separate from the URI identifying each >> particular version. In this case, a PUT request on a general URI >> might result in several other URIs being defined by the origin >> server." Julian, It doesn't follow from above that HTTP must have bindings as they are specified in the binding document (and GULP). One can imagine a number of scenarios where there are multiple URIs for a resource that have quite different semantics and behavior. In fact, it's easy to imagine a different binding draft that specifies, for instance, soft links. This binding draft would be perfectly consistent with both HTTP and WebDAV, but would behave very differently from the current draft. In fact, implementations which are built directly on top of unix file systems might prefer that draft to the current draft. Are there good reasons to prevent other binding models by forcing the binding model of the current bind draft into WebDAV? Especially given our lack of experience with deploying bindings, I'd prefer WebDAV to be agnostic for the time being. Let's face it, file systems find a need to support different binding models, so it's plausible that WebDAV might find this need as well. -brian briank@xythos.com From w3c-dist-auth-request@w3.org Wed Mar 5 17:40:00 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03451 for ; Wed, 5 Mar 2003 17:39:56 -0500 (EST) Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id h25MZBp04461; Wed, 5 Mar 2003 17:35:11 -0500 (EST) Resent-Date: Wed, 5 Mar 2003 17:35:11 -0500 (EST) Resent-Message-Id: <200303052235.h25MZBp04461@frink.w3.org> Received: from tux.w3.org (tux [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id h25MZAI04429 for ; Wed, 5 Mar 2003 17:35:10 -0500 (EST) Received: from mail.xythos.com ([206.14.210.116]) by tux.w3.org (8.12.8/8.12.8) with ESMTP id h25MZ99C013745 for ; Wed, 5 Mar 2003 17:35:09 -0500 Received: from ravms by mail.xythos.com with mail-ok (Exim 3.36 #3) id 18qhUp-0007d8-00 for w3c-dist-auth@w3.org; Wed, 05 Mar 2003 22:36:19 +0000 Received: from ip-216-36-77-241.dsl.sjc.megapath.net ([216.36.77.241] helo=xythos.com) by mail.xythos.com with asmtp (Exim 3.36 #3) id 18qhUp-0007cx-00 for w3c-dist-auth@w3.org; Wed, 05 Mar 2003 22:36:19 +0000 Date: Wed, 5 Mar 2003 14:35:07 -0800 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) From: Brian Korver To: "'WebDAV'" Content-Transfer-Encoding: 7bit In-Reply-To: <32753DE6-4F54-11D7-8A8F-000393751598@xythos.com> Message-Id: X-Mailer: Apple Mail (2.551) Old-X-Envelope-To: w3c-dist-auth@w3.org Subject: Re: Move and Delete (was: bind draft issues) X-Archived-At: http://www.w3.org/mid/B79D08D0-4F5A-11D7-8A8F-000393751598@xythos.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7387 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit On Wednesday, March 5, 2003, at 01:48 PM, Brian Korver wrote: > On Wednesday, March 5, 2003, at 12:34 PM, Julian Reschke wrote: [snip] >> The same thing as the failure you'll get upon trying to rename. MOVE >> is >> *not* the same thing (or should not be the same thing) as >> COPY/DELETE. If a >> MOVE can't preserve the resource's live properties, it should fail. >> >> Now I *do* agree that in many cases clients will actually *want* the >> "weak" >> MOVE. So maybe we should consider supporting both (either by a new >> method, >> or by adding parameters to MOVE). > > That's an interesting idea. Julian, Were you thinking that this header (say "Atomic-Operation:") would be used for only MOVE, or for all of the relevant operations (COPY, DELETE, etc.)? -brian briank@xythos.com From w3c-dist-auth-request@w3.org Wed Mar 5 17:46:20 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03783 for ; Wed, 5 Mar 2003 17:46:20 -0500 (EST) Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id h25MlQb07504; Wed, 5 Mar 2003 17:47:26 -0500 (EST) Resent-Date: Wed, 5 Mar 2003 17:47:26 -0500 (EST) Resent-Message-Id: <200303052247.h25MlQb07504@frink.w3.org> Received: from tux.w3.org (tux [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id h25MlOI07466 for ; Wed, 5 Mar 2003 17:47:24 -0500 (EST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by tux.w3.org (8.12.8/8.12.8) with SMTP id h25MlL9C020020 for ; Wed, 5 Mar 2003 17:47:21 -0500 Received: (qmail 26863 invoked by uid 0); 5 Mar 2003 22:47:14 -0000 Received: from pD950C257.dip.t-dialin.net (HELO lisa) (217.80.194.87) by mail.gmx.net (mp012-rz3) with SMTP; 5 Mar 2003 22:47:14 -0000 From: "Julian Reschke" To: "Brian Korver" , "WebDAV" Date: Wed, 5 Mar 2003 23:47:11 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 In-Reply-To: <4D3481C8-4F59-11D7-8A8F-000393751598@xythos.com> Importance: Normal Subject: RE: Bindings and Locks (was: bind draft issues) X-Archived-At: http://www.w3.org/mid/JIEGINCHMLABHJBIGKBCGELFGKAA.julian.reschke@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7388 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Brian Korver > Sent: Wednesday, March 05, 2003 11:25 PM > To: WebDAV > Subject: Re: Bindings and Locks (was: bind draft issues) > > > > On Wednesday, March 5, 2003, at 11:55 AM, Julian Reschke wrote: > > Again, quoting Geoff quoting RFC2616: > > > >> In case there remains any question about whether HTTP supports > >> multiple URIs being mapped to the same resource, the following quote > >> appears in section 9.6 of RFC-2616: > >> > >> "A single resource MAY be identified by many different URIs. For > >> example, an article might have a URI for identifying "the current > >> version" which is separate from the URI identifying each > >> particular version. In this case, a PUT request on a general URI > >> might result in several other URIs being defined by the origin > >> server." > > Julian, > > It doesn't follow from above that HTTP must have bindings as > they are specified in the binding document (and GULP). One can > imagine a number of scenarios where there are multiple > URIs for a resource that have quite different semantics and > behavior. > > In fact, it's easy to imagine a different binding draft > that specifies, for instance, soft links. This binding Nope. A symbolic link is a different resource than the resource it's pointing to. It can exist while it's target is removed. It can be created although it's target doesn't exist. It doesn't track it's target. Technically it does have it's own properties and ACLs. This is not what the BIND spec describes. > draft would be perfectly consistent with both HTTP and > WebDAV, but would behave very differently from the > current draft. In fact, implementations which are built > directly on top of unix file systems might prefer that > draft to the current draft. Are there good reasons to > prevent other binding models by forcing the binding > model of the current bind draft into WebDAV? Yes and no. Staying with the Unix terminology: hard (true) links and symbolic links are very different things. The BIND spec basically defines the HTTP equivalent of hard links. The (unfinished) redirect reference spec does specify the equivalent of symbolic links. If you want to base your linking implementation on symbolic links, the bind spec clearly isn't the right spec for you. > Especially given our lack of experience with deploying > bindings, I'd prefer WebDAV to be agnostic for the time > being. Let's face it, file systems find a need to > support different binding models, so it's plausible > that WebDAV might find this need as well. Nobody ever said that the binding spec can be the only protocol extension that describes links. As I said there *is* a companion spec that is closer to symbolic links which is the redirect ref spec [1]. We are discussing the BIND spec right now because - RFC3253 more or less requires it, and - somebody (Geoff) volunteered to pick up the abandoned draft and invest the time to drive it to completion. I absolutely agree that the BIND spec doesn't address all linking scenarios (just as hard links don't), and we (SAP/greenbytes) implement the (old) redirect ref spec as well. We intend to drive the redirect ref spec to completion as soon as time permits (in particular once we manage to get the other two advanced collectiom drafts -- BIND and ordering -- out of the door). Julian [1] -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Wed Mar 5 17:50:12 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03937 for ; Wed, 5 Mar 2003 17:50:12 -0500 (EST) Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id h25MpHj08448; Wed, 5 Mar 2003 17:51:17 -0500 (EST) Resent-Date: Wed, 5 Mar 2003 17:51:17 -0500 (EST) Resent-Message-Id: <200303052251.h25MpHj08448@frink.w3.org> Received: from tux.w3.org (tux [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id h25MpGI08416 for ; Wed, 5 Mar 2003 17:51:16 -0500 (EST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by tux.w3.org (8.12.8/8.12.8) with SMTP id h25MpF9C022116 for ; Wed, 5 Mar 2003 17:51:15 -0500 Received: (qmail 8403 invoked by uid 0); 5 Mar 2003 22:51:09 -0000 Received: from pD950C257.dip.t-dialin.net (HELO lisa) (217.80.194.87) by mail.gmx.net (mp022-rz3) with SMTP; 5 Mar 2003 22:51:09 -0000 From: "Julian Reschke" To: "Brian Korver" , "'WebDAV'" Date: Wed, 5 Mar 2003 23:51:06 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 In-Reply-To: Importance: Normal Subject: RE: Move and Delete (was: bind draft issues) X-Archived-At: http://www.w3.org/mid/JIEGINCHMLABHJBIGKBCAELGGKAA.julian.reschke@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7389 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Brian Korver > Sent: Wednesday, March 05, 2003 11:35 PM > To: 'WebDAV' > Subject: Re: Move and Delete (was: bind draft issues) > > > > On Wednesday, March 5, 2003, at 01:48 PM, Brian Korver wrote: > > On Wednesday, March 5, 2003, at 12:34 PM, Julian Reschke wrote: > [snip] > >> The same thing as the failure you'll get upon trying to rename. MOVE > >> is > >> *not* the same thing (or should not be the same thing) as > >> COPY/DELETE. If a > >> MOVE can't preserve the resource's live properties, it should fail. > >> > >> Now I *do* agree that in many cases clients will actually *want* the > >> "weak" > >> MOVE. So maybe we should consider supporting both (either by a new > >> method, > >> or by adding parameters to MOVE). > > > > That's an interesting idea. > > Julian, > > Were you thinking that this header (say "Atomic-Operation:") would be > used for only MOVE, or for all of the relevant operations (COPY, > DELETE, etc.)? Actually, I'd really prefer not to define additional headers. Thinking of it, we *also* can't agree on the right DELETE semantics (see separate discussion). So one way to address this would be to leave DELETE and MOVE as they are, and to add - UNBIND (that really really really removes bindings, thus has the DELETE semantics currently specified by the BIND draft) and - RENAME (which would be a true MOVE that would fail when the server can't implement it as internal namespace operation). This would make discovery of the new functionality much easier. Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Wed Mar 5 19:36:36 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA08241 for ; Wed, 5 Mar 2003 19:36:36 -0500 (EST) Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id h260bMq27009; Wed, 5 Mar 2003 19:37:22 -0500 (EST) Resent-Date: Wed, 5 Mar 2003 19:37:22 -0500 (EST) Resent-Message-Id: <200303060037.h260bMq27009@frink.w3.org> Received: from tux.w3.org (tux [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id h260bKI26958 for ; Wed, 5 Mar 2003 19:37:20 -0500 (EST) Received: from sunbelt.seagull.net (user34.net540.or.sprint-hsd.net [65.40.225.34]) by tux.w3.org (8.12.8/8.12.8) with ESMTP id h260bG9C010088 for ; Wed, 5 Mar 2003 19:37:17 -0500 Received: (mail@localhost) by sunbelt.seagull.net (8.9.3) id QAA03619 sender nn683849@smallcue.com for w3c-dist-auth@w3.org; Wed, 5 Mar 2003 16:37:15 -0800 Received: from e6.ny.us.ibm.com (e6.ny.us.ibm.com [32.97.182.106]) by sunbelt.seagull.net (8.9.3) with ESMTP id QAA03594 sender obsfucated@us.ibm.com; Wed, 5 Mar 2003 16:37:12 -0800 Received: from northrelay04.pok.ibm.com (northrelay04.pok.ibm.com [9.56.224.206]) by e6.ny.us.ibm.com (8.12.8/8.12.2) with ESMTP id h260aKZu080418; Wed, 5 Mar 2003 19:36:20 -0500 Received: from d01ml243.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by northrelay04.pok.ibm.com (8.12.3/NCO/VER6.5) with ESMTP id h260aHMT137996; Wed, 5 Mar 2003 19:36:18 -0500 To: "Julian Reschke" Cc: "Brian Korver" , "WebDAV" X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: Jason Crawford Date: Wed, 5 Mar 2003 19:31:29 -0500 X-MIMETrack: Serialize by Router on D01ML243/01/M/IBM(Release 6.0.1 [IBM]|March 4, 2003) at 03/05/2003 19:36:17 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Subject: RE: Operations not Atomic (was: bind draft issues) X-Archived-At: http://www.w3.org/mid/OFA7EB80DD.AB060CBC-ON85256CE1.0001D4D7@us.ibm.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7390 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: > > For MOVE, I mostly mean the DELETE that occurs when the MOVE causes > > an overwrite, although I could be convinced that ending up with 2 > > bindings to the collection in the event of an interrupted MOVE, > > while inadvisable, shouldn't be prohibited. > > That's indeed a problem. All "overwrite" operations require a DELETE (this > also applies to BIND (!)), so having them atomic when the target is a > collection has the same problems has the collection DELETE itself. I am curious... What does a system that doesn't support "atomic delete" do in this situation if it gets stuck midway though the deallocation portion of the DELETE? Does it leave the destination partially deleted and abort the operation leaving it up the client to figure out what state this was all left in? ------------------------------------------ Phone: 914-784-7569, ccjason@us.ibm.com I do not check nn621779@smallcue.com From w3c-dist-auth-request@w3.org Thu Mar 6 02:22:57 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA26529 for ; Thu, 6 Mar 2003 02:22:57 -0500 (EST) Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id h267Kxi13046; Thu, 6 Mar 2003 02:20:59 -0500 (EST) Resent-Date: Thu, 6 Mar 2003 02:20:59 -0500 (EST) Resent-Message-Id: <200303060720.h267Kxi13046@frink.w3.org> Received: from tux.w3.org (tux [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id h267KvI13013 for ; Thu, 6 Mar 2003 02:20:57 -0500 (EST) Received: from mail.gmx.net (mail.gmx.net [213.165.65.60]) by tux.w3.org (8.12.8/8.12.8) with SMTP id h267Ku9C012620 for ; Thu, 6 Mar 2003 02:20:56 -0500 Received: (qmail 4859 invoked by uid 0); 6 Mar 2003 07:20:50 -0000 Received: from p3EE2480F.dip.t-dialin.net (HELO lisa) (62.226.72.15) by mail.gmx.net (mp001-rz3) with SMTP; 6 Mar 2003 07:20:50 -0000 From: "Julian Reschke" To: "Jason Crawford" , "Julian Reschke" Cc: "Brian Korver" , "WebDAV" Date: Thu, 6 Mar 2003 08:20:43 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Subject: RE: Operations not Atomic (was: bind draft issues) X-Archived-At: http://www.w3.org/mid/JIEGINCHMLABHJBIGKBCKEMAGKAA.julian.reschke@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7391 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Jason Crawford > Sent: Thursday, March 06, 2003 1:31 AM > To: Julian Reschke > Cc: Brian Korver; WebDAV > Subject: RE: Operations not Atomic (was: bind draft issues) > > > > > > > > > For MOVE, I mostly mean the DELETE that occurs when the MOVE causes > > > an overwrite, although I could be convinced that ending up with 2 > > > bindings to the collection in the event of an interrupted MOVE, > > > while inadvisable, shouldn't be prohibited. > > > > That's indeed a problem. All "overwrite" operations require a DELETE > (this > > also applies to BIND (!)), so having them atomic when the target is a > > collection has the same problems has the collection DELETE itself. > > > I am curious... > > What does a system that doesn't support "atomic delete" > do in this situation if it gets stuck midway though the deallocation portion > of the DELETE? Does it leave the destination partially deleted and > abort the operation leaving it up the client to figure out what state this > was all left in? I think the answer is "yes". If the DELETE on the operation target isn't atomic, I don't think there's any way to avoid this. Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Thu Mar 6 04:26:15 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA29372 for ; Thu, 6 Mar 2003 04:26:15 -0500 (EST) Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id h269OPG08564; Thu, 6 Mar 2003 04:24:25 -0500 (EST) Resent-Date: Thu, 6 Mar 2003 04:24:25 -0500 (EST) Resent-Message-Id: <200303060924.h269OPG08564@frink.w3.org> Received: from tux.w3.org (tux [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id h269OMI08527 for ; Thu, 6 Mar 2003 04:24:22 -0500 (EST) Received: from omgo.iij.ad.jp (omgo.iij.ad.jp [202.232.30.157]) by tux.w3.org (8.12.8/8.12.8) with ESMTP id h269OL9C000433 for ; Thu, 6 Mar 2003 04:24:22 -0500 Received: from fw2 ([192.168.2.111]) by omgo.iij.ad.jp (8.12.7/8.12.7) with SMTP id h269OE1a023783 for ; Thu, 6 Mar 2003 18:24:14 +0900 (JST) Received: from mocha.iij.ad.jp ([192.168.4.175]) by fw2.iij.ad.jp; Thu, 06 Mar 2003 18:24:13 +0900 (JST) Received: by mocha.iij.ad.jp (Postfix, from userid 5292) id DCED133ABB; Thu, 6 Mar 2003 18:25:41 +0900 (JST) To: "WebDAV" References: From: Taisuke Yamada Date: Thu, 06 Mar 2003 18:25:41 +0900 In-Reply-To: (Jason Crawford's message of "Wed, 5 Mar 2003 19:31:29 -0500") Message-ID: User-Agent: Gnus/5.090015 (Oort Gnus v0.15) Emacs/21.2 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Re: Operations not Atomic (was: bind draft issues) X-Archived-At: http://www.w3.org/mid/vwzof4on8x6.fsf@mocha.iij.ad.jp Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7392 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: >> That's indeed a problem. All "overwrite" operations require a DELETE >> (this also applies to BIND (!)), so having them atomic when the target >> is a collection has the same problems has the collection DELETE itself. > > What does a system that doesn't support "atomic delete" > do in this situation if it gets stuck midway though the deallocation > portion of the DELETE? Why is "atomic DELETE" a problem? Couldn't it be implemented just by simply moving resource out of current namespace? My understanding is that any DELETE is just a MOVE to outerspace. IMHO, you shouldn't really DELETE it before full COPY/MOVE/BIND operation completes. If you do that, then you can't rollback these operations in case of an interrupt (unless you keep DAV resource content on RDB or something). -- Taisuke Yamada Internet Initiative Japan Inc., Technical Planning Division From w3c-dist-auth-request@w3.org Thu Mar 6 06:33:27 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA03932 for ; Thu, 6 Mar 2003 06:33:23 -0500 (EST) Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id h26BVO525373; Thu, 6 Mar 2003 06:31:24 -0500 (EST) Resent-Date: Thu, 6 Mar 2003 06:31:24 -0500 (EST) Resent-Message-Id: <200303061131.h26BVO525373@frink.w3.org> Received: from tux.w3.org (tux [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id h26BVMI25340 for ; Thu, 6 Mar 2003 06:31:22 -0500 (EST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by tux.w3.org (8.12.8/8.12.8) with ESMTP id h26BVL9C018602 for ; Thu, 6 Mar 2003 06:31:21 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA03497; Thu, 6 Mar 2003 06:29:16 -0500 (EST) Message-Id: <200303061129.GAA03497@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: w3c-dist-auth@w3.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Thu, 06 Mar 2003 06:29:16 -0500 Subject: I-D ACTION:draft-ietf-webdav-rfc2518bis-03.txt X-Archived-At: http://www.w3.org/mid/200303061129.GAA03497@ietf.org Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7393 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the WWW Distributed Authoring and Versioning Working Group of the IETF. Title : HTTP Extensions for Distributed Authoring - WebDAV RFC2518 bis Author(s) : Y. Goland et al. Filename : draft-ietf-webdav-rfc2518bis-03.txt Pages : 90 Date : 2003-3-5 WebDAV consists of a set of methods, headers, and content-types ancillary to HTTP/1.1 for the management of resource properties, creation and management of resource collections, namespace manipulation, and resource locking (collision avoidance). RFC2518 was published in February 1998, and this draft makes only minor revisions mostly due to interoperability experience. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-webdav-rfc2518bis-03.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-ietf-webdav-rfc2518bis-03.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-ietf-webdav-rfc2518bis-03.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: <2003-3-5141301.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-webdav-rfc2518bis-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-webdav-rfc2518bis-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-3-5141301.I-D@ietf.org> --OtherAccess-- --NextPart-- From w3c-dist-auth-request@w3.org Thu Mar 6 10:14:51 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19558 for ; Thu, 6 Mar 2003 10:14:51 -0500 (EST) Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id h26F87j02769; Thu, 6 Mar 2003 10:08:07 -0500 (EST) Resent-Date: Thu, 6 Mar 2003 10:08:07 -0500 (EST) Resent-Message-Id: <200303061508.h26F87j02769@frink.w3.org> Received: from tux.w3.org (tux [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id h26F84I02732 for ; Thu, 6 Mar 2003 10:08:04 -0500 (EST) Received: from sunbelt.seagull.net (user34.net540.or.sprint-hsd.net [65.40.225.34]) by tux.w3.org (8.12.8/8.12.8) with ESMTP id h26F829C012857 for ; Thu, 6 Mar 2003 10:08:03 -0500 Received: (mail@localhost) by sunbelt.seagull.net (8.9.3) id HAA27431 sender nn683849@smallcue.com for w3c-dist-auth@w3.org; Thu, 6 Mar 2003 07:07:59 -0800 Received: from e3.ny.us.ibm.com (e3.ny.us.ibm.com [32.97.182.103]) by sunbelt.seagull.net (8.9.3) with ESMTP id HAA27408 sender obsfucated@us.ibm.com; Thu, 6 Mar 2003 07:07:56 -0800 Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.56.224.150]) by e3.ny.us.ibm.com (8.12.8/8.12.2) with ESMTP id h26F7Ol9083992; Thu, 6 Mar 2003 10:07:24 -0500 Received: from d01ml243.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by northrelay02.pok.ibm.com (8.12.3/NCO/VER6.5) with ESMTP id h26F7L6R124492; Thu, 6 Mar 2003 10:07:22 -0500 To: "Julian Reschke" Cc: "Brian Korver" , "'WebDAV'" X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: Jason Crawford Date: Thu, 6 Mar 2003 10:03:41 -0500 X-MIMETrack: Serialize by Router on D01ML243/01/M/IBM(Release 6.0.1 [IBM]|March 4, 2003) at 03/06/2003 10:07:22 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Subject: RE: Move and Delete (was: bind draft issues) X-Archived-At: http://www.w3.org/mid/OF97781717.B1B84D41-ON85256CE1.005162FA@us.ibm.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7394 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: > > Were you thinking that this header (say "Atomic-Operation:") would be > > used for only MOVE, or for all of the relevant operations (COPY, > > DELETE, etc.)? > > Actually, I'd really prefer not to define additional headers. > > Thinking of it, we *also* can't agree on the right DELETE semantics (see > separate discussion). So one way to address this would be to leave DELETE > and MOVE as they are, and to add > > - UNBIND (that really really really removes bindings, thus has the DELETE > semantics currently specified by the BIND draft) and > - RENAME (which would be a true MOVE that would fail when the server can't > implement it as internal namespace operation). Just a couple thoughts that I'm not going to have time to join in a coherent manner... My initial opinion when I saw this posting a day ago was that RENAME wasn't necessary. I don't recall now why I said that. It might just have been that it's less necessary than DELETE... but the recent case of the deletion before MOVE overwrite would change that view. If I recall any other reason why I thought RENAME wasn't necessary, I'll speak up. I'm okay with UNBIND (and I can explain why later) except... We have shown that atomic DELETE it should be implementable and the case of a partially finished MOVE with overwrite looks really bad to me. I'm not sure we should let servers do that. (I have an equivocating thought on this that I'll hold in reserve. :-)) So if they can implement the apparently atomic DELETE for MOVE, then they should be able to do it for DELETE itself. Previously we've discussed both headers and UNBIND. They were rejected. I don't recall why though, so we probably should check on that. ------------------------------------------ Phone: 914-784-7569, ccjason@us.ibm.com I do not check nn621779@smallcue.com From w3c-dist-auth-request@w3.org Fri Mar 7 03:40:37 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA14718 for ; Fri, 7 Mar 2003 03:40:37 -0500 (EST) Received: from frink.w3.org (localhost [127.0.0.1]) by frink.w3.org (8.12.8/8.12.8) with ESMTP id h278OE03028927; Fri, 7 Mar 2003 03:41:52 -0500 (EST) Received: (from lists@localhost) by frink.w3.org (8.12.8/8.12.8/Submit) id h277olr8028589; Fri, 7 Mar 2003 02:50:47 -0500 (EST) Resent-Date: Fri, 7 Mar 2003 02:50:47 -0500 (EST) Resent-Message-Id: <200303070750.h277olr8028589@frink.w3.org> Received: from tux.w3.org (IDENT:root@tux [18.29.0.27]) by frink.w3.org (8.12.8/8.12.8) with ESMTP id h277lxHu023592 for ; Fri, 7 Mar 2003 02:50:26 -0500 (EST) Received: from sus-ma1it31.rational.com (sus-ma1it31.rational.com [130.213.73.33]) by tux.w3.org (8.12.8/8.12.8) with ESMTP id h26NoP9C029663 for ; Thu, 6 Mar 2003 18:50:25 -0500 Received: from sus-ma1it00.rational.com ([10.64.1.25]) by 10.64.1.33 with InterScan Messaging Security Suite; Thu, 06 Mar 2003 18:34:09 -0500 Received: by sus-ma1it00.rational.com with Internet Mail Service (5.5.2656.59) id ; Thu, 6 Mar 2003 18:50:19 -0500 Message-ID: From: "Clemm, Geoff" To: WebDAV Date: Thu, 6 Mar 2003 18:50:17 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain Subject: RE: bind draft issues X-Archived-At: http://www.w3.org/mid/E4F2D33B98DF7E4880884B9F0E6FDEE2021C5CBF@SUS-MA1IT01 Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7395 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: How about the following statement about PROPFIND: "If two URLs are mapped to the same resource, the property values returned by PROPFIND on those two URLs MUST be identical." Cheers, Geoff -----Original Message----- From: Brian Korver [mailto:briank@xythos.com] Sent: Tuesday, March 04, 2003 6:21 PM To: WebDAV Subject: Re: bind draft issues Geoff and I had a short out-of-band conversation to discuss the issue I raised when I mentioned "URL properties". Geoff pointed out that there had been text in the binding spec that explained the behavior of properties in the face of different operation, and that it might be good to revisit the issue and include such explanatory material in draft. Would someone like to volunteer to draft that text? Since I'm not familiar with the previous text and the discussion that ensued, perhaps Geoff could explain what the text should include? -brian briank@xythos.com From w3c-dist-auth-request@w3.org Fri Mar 7 03:40:41 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA14716 for ; Fri, 7 Mar 2003 03:40:36 -0500 (EST) Received: from frink.w3.org (localhost [127.0.0.1]) by frink.w3.org (8.12.8/8.12.8) with ESMTP id h278OE0D028927; Fri, 7 Mar 2003 03:41:54 -0500 (EST) Received: (from lists@localhost) by frink.w3.org (8.12.8/8.12.8/Submit) id h277sJlr009432; Fri, 7 Mar 2003 02:54:19 -0500 (EST) Resent-Date: Fri, 7 Mar 2003 02:54:19 -0500 (EST) Resent-Message-Id: <200303070754.h277sJlr009432@frink.w3.org> Received: from tux.w3.org (IDENT:root@tux [18.29.0.27]) by frink.w3.org (8.12.8/8.12.8) with ESMTP id h277lxSG023592 for ; Fri, 7 Mar 2003 02:53:46 -0500 (EST) Received: from mail.xythos.com ([206.14.210.116]) by tux.w3.org (8.12.8/8.12.8) with ESMTP id h26Mtu9C018059 for ; Thu, 6 Mar 2003 17:55:56 -0500 Received: from ravms by mail.xythos.com with mail-ok (Exim 3.36 #3) id 18r4Ik-0007YB-00 for w3c-dist-auth@w3.org; Thu, 06 Mar 2003 22:57:22 +0000 Received: from ip-216-36-77-241.dsl.sjc.megapath.net ([216.36.77.241] helo=xythos.com) by mail.xythos.com with asmtp (Exim 3.36 #3) id 18r4Ij-0007Xs-00 for w3c-dist-auth@w3.org; Thu, 06 Mar 2003 22:57:21 +0000 Date: Thu, 6 Mar 2003 14:55:49 -0800 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) From: Brian Korver To: "'WebDAV'" Content-Transfer-Encoding: 7bit In-Reply-To: Message-Id: X-Mailer: Apple Mail (2.551) Old-X-Envelope-To: w3c-dist-auth@w3.org Subject: Re: Move and Delete (was: bind draft issues) X-Archived-At: http://www.w3.org/mid/C6569B1E-5026-11D7-8A8F-000393751598@xythos.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7396 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit On Wednesday, March 5, 2003, at 12:21 AM, Julian Reschke wrote: >> Julian, >> >> I agree, but I think it's even worse than this. Semantically, >> MOVE is merely a simple namespace operation, but in practice >> it may be more than that. For instance, a move across unix >> filesystems must be implemented as a recursive copy (followed >> afterward by delete). > > Brian, > > in the Unix API, you don't move at all -- you link() then unlink(). > "mv" is > just a user command that does it's best when the files reside in > different > partitions. I think WebDAV MOVE should just fail if the resource cannot > really be moved (preserving all dead & live properties), and fail > otherwise. > Just like in the Unix API, the caller *then* can decide to do a > COPY/DELETE > instead. > > Julian Julian, If it is the goal to have WebDAV implement the semantics of the Unix API, then I would prefer that it more closely model those semantics -- for instance by making DELETE fail on non-empty collections. Personally, I don't think that WebDAV should implement the semantics of the Unix API, at the very least because of the overhead -- imagine having to issue a DELETE for every resource in order to delete a collection containing a million files. I feel that WebDAV should implement semantics that are closer to the Unix CLI, which of course was designed to be easier on the fingers (read: "lower overhead") than the API. -brian briank@xythos.com From w3c-dist-auth-request@w3.org Fri Mar 7 03:53:31 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA14995 for ; Fri, 7 Mar 2003 03:53:31 -0500 (EST) Received: from frink.w3.org (localhost [127.0.0.1]) by frink.w3.org (8.12.8/8.12.8) with ESMTP id h278smHB020672; Fri, 7 Mar 2003 03:54:48 -0500 (EST) Received: (from lists@localhost) by frink.w3.org (8.12.8/8.12.8/Submit) id h278sj8g020656; Fri, 7 Mar 2003 03:54:45 -0500 (EST) Resent-Date: Fri, 7 Mar 2003 03:54:45 -0500 (EST) Resent-Message-Id: <200303070854.h278sj8g020656@frink.w3.org> Received: from tux.w3.org (IDENT:root@tux [18.29.0.27]) by frink.w3.org (8.12.8/8.12.8) with ESMTP id h278rkHB020427 for ; Fri, 7 Mar 2003 03:53:46 -0500 (EST) Received: from greenbytes.de (mail.greenbytes.de [217.5.201.10] (may be forged)) by tux.w3.org (8.12.8/8.12.8) with SMTP id h278rirB029290 for ; Fri, 7 Mar 2003 03:53:45 -0500 Received: from greenbytes.de ([192.168.1.23]) by greenbytes.de ([217.5.201.11]) with SMTP (MDaemon.PRO.v6.7.0.R) for ; Fri, 07 Mar 2003 09:52:45 +0100 Date: Fri, 7 Mar 2003 09:52:44 +0100 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: WebDAV To: "Clemm, Geoff" From: Stefan Eissing In-Reply-To: Message-Id: <298A62F4-507A-11D7-B755-00039384827E@greenbytes.de> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) X-MDRemoteIP: 192.168.1.23 X-Return-Path: stefan.eissing@greenbytes.de X-MDaemon-Deliver-To: w3c-dist-auth@w3.org Subject: Re: bind draft issues X-Archived-At: http://www.w3.org/mid/298A62F4-507A-11D7-B755-00039384827E@greenbytes.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7397 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit Am Freitag, 07.03.03, um 00:50 Uhr (Europe/Berlin) schrieb Clemm, Geoff: > How about the following statement about PROPFIND: > > "If two URLs are mapped to the same resource, the property > values returned by PROPFIND on those two URLs MUST be > identical." Hmm, I think I know what you mean, however there are cases where you might want this to break: 1) variants. /news/english/ and /news/german/ might be the same resource with different content based on the "access" URL. All get* properties will probably vary. (They can already vary on a resource with a single binding) 2) live props with URI References can report different relative uri references. They are semantically equivalent, but the string value of such a property will differ. What exactly is it, you want to prevent to happen? //Stefan > Cheers, > Geoff > > -----Original Message----- > From: Brian Korver [mailto:briank@xythos.com] > Sent: Tuesday, March 04, 2003 6:21 PM > To: WebDAV > Subject: Re: bind draft issues > > > > Geoff and I had a short out-of-band conversation to discuss > the issue I raised when I mentioned "URL properties". > Geoff pointed out that there had been text in the binding > spec that explained the behavior of properties in the > face of different operation, and that it might be good > to revisit the issue and include such explanatory material > in draft. > > Would someone like to volunteer to draft that text? > Since I'm not familiar with the previous text and the > discussion that ensued, perhaps Geoff could explain > what the text should include? > > -brian > briank@xythos.com > From w3c-dist-auth-request@w3.org Fri Mar 7 03:57:03 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA15069 for ; Fri, 7 Mar 2003 03:57:02 -0500 (EST) Received: from frink.w3.org (localhost [127.0.0.1]) by frink.w3.org (8.12.8/8.12.8) with ESMTP id h278wBHB021624; Fri, 7 Mar 2003 03:58:11 -0500 (EST) Received: (from lists@localhost) by frink.w3.org (8.12.8/8.12.8/Submit) id h278wBs9021612; Fri, 7 Mar 2003 03:58:11 -0500 (EST) Resent-Date: Fri, 7 Mar 2003 03:58:11 -0500 (EST) Resent-Message-Id: <200303070858.h278wBs9021612@frink.w3.org> Received: from tux.w3.org (IDENT:root@tux [18.29.0.27]) by frink.w3.org (8.12.8/8.12.8) with ESMTP id h278w9HB021566 for ; Fri, 7 Mar 2003 03:58:09 -0500 (EST) Received: from mail.gmx.net (mail.gmx.net [213.165.65.60]) by tux.w3.org (8.12.8/8.12.8) with SMTP id h278w8rB029924 for ; Fri, 7 Mar 2003 03:58:08 -0500 Received: (qmail 7519 invoked by uid 0); 7 Mar 2003 08:57:58 -0000 Received: from p3EE2476D.dip.t-dialin.net (HELO lisa) (62.226.71.109) by mail.gmx.net (mp001-rz3) with SMTP; 7 Mar 2003 08:57:58 -0000 From: "Julian Reschke" To: "Brian Korver" , "'WebDAV'" Date: Fri, 7 Mar 2003 09:57:50 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal In-Reply-To: Subject: RE: Move and Delete (was: bind draft issues) X-Archived-At: http://www.w3.org/mid/JIEGINCHMLABHJBIGKBCGEPNGKAA.julian.reschke@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7398 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Brian Korver > Sent: Thursday, March 06, 2003 11:56 PM > To: 'WebDAV' > Subject: Re: Move and Delete (was: bind draft issues) > ... > > Julian, > > If it is the goal to have WebDAV implement the semantics of the > Unix API, then I would prefer that it more closely model those > semantics -- for instance by making DELETE fail on non-empty > collections. No, that's not the goal (at least I don't think so). > Personally, I don't think that WebDAV should implement the > semantics of the Unix API, at the very least because of > the overhead -- imagine having to issue a DELETE for every > resource in order to delete a collection containing a million Correct. The overhead my be ok in a local fs, probably is problematic with a network filesystem, and won't be acceptable for WebDAV. > files. I feel that WebDAV should implement semantics that > are closer to the Unix CLI, which of course was designed to > be easier on the fingers (read: "lower overhead") than > the API. Yes and no. I really think that there may be separate use case that require separate solutions. A client should be able to request a MOVE operation that will fail if the server can't support full MOVE semantics (for instance by changing the DAV:resource-id property). A client would then be able to reconsider, possibly issuing a COPY/DELETE sequence instead. Hopefully we can agree that this type of request should be supported. If we do, we're left with the alternatives of making this the standard behaviour for the RFC2518 MOVE, or to invent some new marshalling. I'd prefer the former, but I probably could live with the latter. A similar problem obviously exists with the DELETE collection atomicity issue. -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Fri Mar 7 03:58:06 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA15100 for ; Fri, 7 Mar 2003 03:58:05 -0500 (EST) Received: from frink.w3.org (localhost [127.0.0.1]) by frink.w3.org (8.12.8/8.12.8) with ESMTP id h278xkHB022007; Fri, 7 Mar 2003 03:59:46 -0500 (EST) Received: (from lists@localhost) by frink.w3.org (8.12.8/8.12.8/Submit) id h278xkip021999; Fri, 7 Mar 2003 03:59:46 -0500 (EST) Resent-Date: Fri, 7 Mar 2003 03:59:46 -0500 (EST) Resent-Message-Id: <200303070859.h278xkip021999@frink.w3.org> Received: from tux.w3.org (IDENT:root@tux [18.29.0.27]) by frink.w3.org (8.12.8/8.12.8) with ESMTP id h278xhHB021965 for ; Fri, 7 Mar 2003 03:59:43 -0500 (EST) Received: from mail.gmx.net (mail.gmx.net [213.165.65.60]) by tux.w3.org (8.12.8/8.12.8) with SMTP id h278xgrB030068 for ; Fri, 7 Mar 2003 03:59:42 -0500 Received: (qmail 31550 invoked by uid 0); 7 Mar 2003 08:59:34 -0000 Received: from p3EE2476D.dip.t-dialin.net (HELO lisa) (62.226.71.109) by mail.gmx.net (mp008-rz3) with SMTP; 7 Mar 2003 08:59:34 -0000 From: "Julian Reschke" To: "Clemm, Geoff" , "WebDAV" Date: Fri, 7 Mar 2003 09:59:26 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal In-Reply-To: Subject: RE: bind draft issues X-Archived-At: http://www.w3.org/mid/JIEGINCHMLABHJBIGKBCKEPNGKAA.julian.reschke@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7399 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Clemm, Geoff > Sent: Friday, March 07, 2003 12:50 AM > To: WebDAV > Subject: RE: bind draft issues > > > > How about the following statement about PROPFIND: > > "If two URLs are mapped to the same resource, the property > values returned by PROPFIND on those two URLs MUST be > identical." > > ... I think the statement is correct, and directly follows from RFC2518, section 4.1, first sentence. If this helps to clarify, it may be a good idea to add it. -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Fri Mar 7 04:05:25 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA15285 for ; Fri, 7 Mar 2003 04:05:25 -0500 (EST) Received: from frink.w3.org (localhost [127.0.0.1]) by frink.w3.org (8.12.8/8.12.8) with ESMTP id h2796vHB023307; Fri, 7 Mar 2003 04:06:57 -0500 (EST) Received: (from lists@localhost) by frink.w3.org (8.12.8/8.12.8/Submit) id h2796uG9023282; Fri, 7 Mar 2003 04:06:56 -0500 (EST) Resent-Date: Fri, 7 Mar 2003 04:06:56 -0500 (EST) Resent-Message-Id: <200303070906.h2796uG9023282@frink.w3.org> Received: from tux.w3.org (IDENT:root@tux [18.29.0.27]) by frink.w3.org (8.12.8/8.12.8) with ESMTP id h2796rHB023247 for ; Fri, 7 Mar 2003 04:06:53 -0500 (EST) Received: from mail.gmx.net (mail.gmx.net [213.165.65.60]) by tux.w3.org (8.12.8/8.12.8) with SMTP id h2796qrB031648 for ; Fri, 7 Mar 2003 04:06:52 -0500 Received: (qmail 9802 invoked by uid 0); 7 Mar 2003 09:06:44 -0000 Received: from p3EE2476D.dip.t-dialin.net (HELO lisa) (62.226.71.109) by mail.gmx.net (mp006-rz3) with SMTP; 7 Mar 2003 09:06:44 -0000 From: "Julian Reschke" To: "Stefan Eissing" , "Clemm, Geoff" Cc: "WebDAV" Date: Fri, 7 Mar 2003 10:06:36 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal In-Reply-To: <298A62F4-507A-11D7-B755-00039384827E@greenbytes.de> Subject: RE: bind draft issues X-Archived-At: http://www.w3.org/mid/JIEGINCHMLABHJBIGKBCEEPOGKAA.julian.reschke@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7400 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Stefan Eissing > Sent: Friday, March 07, 2003 9:53 AM > To: Clemm, Geoff > Cc: WebDAV > Subject: Re: bind draft issues > > > > > Am Freitag, 07.03.03, um 00:50 Uhr (Europe/Berlin) schrieb Clemm, Geoff: > > How about the following statement about PROPFIND: > > > > "If two URLs are mapped to the same resource, the property > > values returned by PROPFIND on those two URLs MUST be > > identical." > > Hmm, I think I know what you mean, however there are cases > where you might want this to break: > > 1) variants. /news/english/ and /news/german/ might be the same > resource with different content based on the "access" URL. All > get* properties will probably vary. (They can already vary on > a resource with a single binding) That would mean that entities may vary based on the request URI. Is this the case? > 2) live props with URI References can report different relative uri > references. They are semantically equivalent, but the string value > of such a property will differ. For instance? > What exactly is it, you want to prevent to happen? People falling into the trap of believing in "URL properties", I guess. -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Fri Mar 7 04:33:50 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA16112 for ; Fri, 7 Mar 2003 04:33:49 -0500 (EST) Received: from frink.w3.org (localhost [127.0.0.1]) by frink.w3.org (8.12.8/8.12.8) with ESMTP id h279ZHHB028945; Fri, 7 Mar 2003 04:35:17 -0500 (EST) Received: (from lists@localhost) by frink.w3.org (8.12.8/8.12.8/Submit) id h279Z1W4028901; Fri, 7 Mar 2003 04:35:01 -0500 (EST) Resent-Date: Fri, 7 Mar 2003 04:35:01 -0500 (EST) Resent-Message-Id: <200303070935.h279Z1W4028901@frink.w3.org> Received: from tux.w3.org (IDENT:root@tux [18.29.0.27]) by frink.w3.org (8.12.8/8.12.8) with ESMTP id h279Y6HB028787 for ; Fri, 7 Mar 2003 04:34:06 -0500 (EST) Received: from greenbytes.de (mail.greenbytes.de [217.5.201.10] (may be forged)) by tux.w3.org (8.12.8/8.12.8) with SMTP id h279Y5rB003173 for ; Fri, 7 Mar 2003 04:34:05 -0500 Received: from greenbytes.de ([192.168.1.23]) by greenbytes.de ([217.5.201.11]) with SMTP (MDaemon.PRO.v6.7.0.R) for ; Fri, 07 Mar 2003 10:33:43 +0100 Date: Fri, 7 Mar 2003 10:33:41 +0100 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: "Clemm, Geoff" , "WebDAV" To: "Julian Reschke" From: Stefan Eissing In-Reply-To: Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) X-MDRemoteIP: 192.168.1.23 X-Return-Path: stefan.eissing@greenbytes.de X-MDaemon-Deliver-To: w3c-dist-auth@w3.org Subject: Re: bind draft issues X-Archived-At: http://www.w3.org/mid/E2594BFB-507F-11D7-B755-00039384827E@greenbytes.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7401 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit Am Freitag, 07.03.03, um 10:06 Uhr (Europe/Berlin) schrieb Julian Reschke: >> From: w3c-dist-auth-request@w3.org >> [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Stefan Eissing >> Sent: Friday, March 07, 2003 9:53 AM >> To: Clemm, Geoff >> Cc: WebDAV >> Subject: Re: bind draft issues >> >> >> >> >> Am Freitag, 07.03.03, um 00:50 Uhr (Europe/Berlin) schrieb Clemm, >> Geoff: >>> How about the following statement about PROPFIND: >>> >>> "If two URLs are mapped to the same resource, the property >>> values returned by PROPFIND on those two URLs MUST be >>> identical." >> >> Hmm, I think I know what you mean, however there are cases >> where you might want this to break: >> >> 1) variants. /news/english/ and /news/german/ might be the same >> resource with different content based on the "access" URL. All >> get* properties will probably vary. (They can already vary on >> a resource with a single binding) > > That would mean that entities may vary based on the request URI. Is > this the > case? I thought that's what I wrote. >> 2) live props with URI References can report different relative uri >> references. They are semantically equivalent, but the string value >> of such a property will differ. > > For instance? ../../../../version-history/1/2/12 for PROPFIND result on /a/b/c/d/vcr and ../../../version-history/1/2/12 for PROPFIND result on /a/b/c/vcr with both "vcr" being bindings to the same resource. > >> What exactly is it, you want to prevent to happen? > > People falling into the trap of believing in "URL properties", I guess. Probably a good guess of Geoff's intentions. Why not give a guess what an "URL property" exactly is? That would be most welcome. //Stefan From w3c-dist-auth-request@w3.org Fri Mar 7 04:50:52 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA16724 for ; Fri, 7 Mar 2003 04:50:52 -0500 (EST) Received: from frink.w3.org (localhost [127.0.0.1]) by frink.w3.org (8.12.8/8.12.8) with ESMTP id h279lLHB001384; Fri, 7 Mar 2003 04:47:21 -0500 (EST) Received: (from lists@localhost) by frink.w3.org (8.12.8/8.12.8/Submit) id h279lJIa001347; Fri, 7 Mar 2003 04:47:19 -0500 (EST) Resent-Date: Fri, 7 Mar 2003 04:47:19 -0500 (EST) Resent-Message-Id: <200303070947.h279lJIa001347@frink.w3.org> Received: from tux.w3.org (IDENT:root@tux [18.29.0.27]) by frink.w3.org (8.12.8/8.12.8) with ESMTP id h279kXHB001245 for ; Fri, 7 Mar 2003 04:46:33 -0500 (EST) Received: from mail.gmx.net (mail.gmx.net [213.165.65.60]) by tux.w3.org (8.12.8/8.12.8) with SMTP id h279kSrB005339 for ; Fri, 7 Mar 2003 04:46:29 -0500 Received: (qmail 12117 invoked by uid 0); 7 Mar 2003 09:45:25 -0000 Received: from p3EE2476D.dip.t-dialin.net (HELO lisa) (62.226.71.109) by mail.gmx.net (mp005-rz3) with SMTP; 7 Mar 2003 09:45:25 -0000 From: "Julian Reschke" To: "Stefan Eissing" , "Julian Reschke" Cc: "Clemm, Geoff" , "WebDAV" Date: Fri, 7 Mar 2003 10:45:20 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal In-Reply-To: Subject: RE: bind draft issues X-Archived-At: http://www.w3.org/mid/JIEGINCHMLABHJBIGKBCCEAAGLAA.julian.reschke@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7402 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Stefan Eissing > Sent: Friday, March 07, 2003 10:34 AM > To: Julian Reschke > Cc: Clemm, Geoff; WebDAV > Subject: Re: bind draft issues > > ... > > >> Hmm, I think I know what you mean, however there are cases > >> where you might want this to break: > >> > >> 1) variants. /news/english/ and /news/german/ might be the same > >> resource with different content based on the "access" URL. All > >> get* properties will probably vary. (They can already vary on > >> a resource with a single binding) > > > > That would mean that entities may vary based on the request URI. Is > > this the > > case? > > I thought that's what I wrote. OK, I rephrase it: that would mean that a resource is *allowed* to vary based on the request URL. I don't think we all agree on that. > >> 2) live props with URI References can report different relative uri > >> references. They are semantically equivalent, but the string value > >> of such a property will differ. > > > > For instance? > > ../../../../version-history/1/2/12 > for PROPFIND result on /a/b/c/d/vcr > and > ../../../version-history/1/2/12 > for PROPFIND result on /a/b/c/vcr > with both "vcr" being bindings to the same resource. OK, this means that we'll have to clarify the "sameness" of property values. If a property value is a relative URI, it's to be resolved against the request URL. If they resolve to the same absoluteURI, the property value is the same. RFC2518bis issue: the spec normatively refers to RFC2616's term "URI", but RFC2616 does not formally define it. We need to rephrase this using the BNF terms URIreference and absoluteURI. > >> What exactly is it, you want to prevent to happen? > > > > People falling into the trap of believing in "URL properties", I guess. > > Probably a good guess of Geoff's intentions. Why not give a guess > what an "URL property" exactly is? That would be most welcome. Our (Geoff's any my) understanding is that there *are* no URL properties. A URL property would be something that varies with the request URL (under the relaxed "sameness" definition stated above). Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Fri Mar 7 05:00:03 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA17167 for ; Fri, 7 Mar 2003 05:00:02 -0500 (EST) Received: from frink.w3.org (localhost [127.0.0.1]) by frink.w3.org (8.12.8/8.12.8) with ESMTP id h27A1jHB002880; Fri, 7 Mar 2003 05:01:45 -0500 (EST) Received: (from lists@localhost) by frink.w3.org (8.12.8/8.12.8/Submit) id h27A1hHf002867; Fri, 7 Mar 2003 05:01:43 -0500 (EST) Resent-Date: Fri, 7 Mar 2003 05:01:43 -0500 (EST) Resent-Message-Id: <200303071001.h27A1hHf002867@frink.w3.org> Received: from tux.w3.org (IDENT:root@tux [18.29.0.27]) by frink.w3.org (8.12.8/8.12.8) with ESMTP id h27A1AHB002821 for ; Fri, 7 Mar 2003 05:01:10 -0500 (EST) Received: from greenbytes.de (mail.greenbytes.de [217.5.201.10] (may be forged)) by tux.w3.org (8.12.8/8.12.8) with SMTP id h27A19rB007348 for ; Fri, 7 Mar 2003 05:01:10 -0500 Received: from greenbytes.de ([192.168.1.23]) by greenbytes.de ([217.5.201.11]) with SMTP (MDaemon.PRO.v6.7.0.R) for ; Fri, 07 Mar 2003 11:00:05 +0100 Date: Fri, 7 Mar 2003 11:00:03 +0100 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: "Clemm, Geoff" , "WebDAV" To: "Julian Reschke" From: Stefan Eissing In-Reply-To: Message-Id: <911463B0-5083-11D7-B755-00039384827E@greenbytes.de> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) X-MDRemoteIP: 192.168.1.23 X-Return-Path: stefan.eissing@greenbytes.de X-MDaemon-Deliver-To: w3c-dist-auth@w3.org Subject: Re: bind draft issues X-Archived-At: http://www.w3.org/mid/911463B0-5083-11D7-B755-00039384827E@greenbytes.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7403 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit Am Freitag, 07.03.03, um 10:45 Uhr (Europe/Berlin) schrieb Julian Reschke: >> From: w3c-dist-auth-request@w3.org >> [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Stefan Eissing >> Sent: Friday, March 07, 2003 10:34 AM >> To: Julian Reschke >> Cc: Clemm, Geoff; WebDAV >> Subject: Re: bind draft issues >> >> ... >> >>>> Hmm, I think I know what you mean, however there are cases >>>> where you might want this to break: >>>> >>>> 1) variants. /news/english/ and /news/german/ might be the same >>>> resource with different content based on the "access" URL. All >>>> get* properties will probably vary. (They can already vary on >>>> a resource with a single binding) >>> >>> That would mean that entities may vary based on the request URI. Is >>> this the >>> case? >> >> I thought that's what I wrote. > > OK, I rephrase it: that would mean that a resource is *allowed* to vary > based on the request URL. I don't think we all agree on that. Uhh, it can vary based on "Accept-Language" request header. Why should it not vary on the request URI of the GET? [...] >>>> What exactly is it, you want to prevent to happen? >>> >>> People falling into the trap of believing in "URL properties", I >>> guess. >> >> Probably a good guess of Geoff's intentions. Why not give a guess >> what an "URL property" exactly is? That would be most welcome. > > Our (Geoff's any my) understanding is that there *are* no URL > properties. A > URL property would be something that varies with the request URL > (under the > relaxed "sameness" definition stated above). So: properties can vary based on HTTP request headers, but not based on the HTTP request URI? Or do you think they should not vary based on HTTP request headers either? Or that only the get* properties are allowed to do that? //Stefan From w3c-dist-auth-request@w3.org Fri Mar 7 05:25:40 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA17973 for ; Fri, 7 Mar 2003 05:25:35 -0500 (EST) Received: from frink.w3.org (localhost [127.0.0.1]) by frink.w3.org (8.12.8/8.12.8) with ESMTP id h27AQxHB005807; Fri, 7 Mar 2003 05:26:59 -0500 (EST) Received: (from lists@localhost) by frink.w3.org (8.12.8/8.12.8/Submit) id h27AQwhE005781; Fri, 7 Mar 2003 05:26:58 -0500 (EST) Resent-Date: Fri, 7 Mar 2003 05:26:58 -0500 (EST) Resent-Message-Id: <200303071026.h27AQwhE005781@frink.w3.org> Received: from tux.w3.org (IDENT:root@tux [18.29.0.27]) by frink.w3.org (8.12.8/8.12.8) with ESMTP id h27APxHB005684 for ; Fri, 7 Mar 2003 05:25:59 -0500 (EST) Received: from mail.gmx.net (mail.gmx.net [213.165.65.60]) by tux.w3.org (8.12.8/8.12.8) with SMTP id h27APwrB010515 for ; Fri, 7 Mar 2003 05:25:59 -0500 Received: (qmail 6289 invoked by uid 0); 7 Mar 2003 10:25:53 -0000 Received: from mail.greenbytes.de (HELO lisa) (217.5.201.10) by mail.gmx.net (mp003-rz3) with SMTP; 7 Mar 2003 10:25:53 -0000 From: "Julian Reschke" To: "Stefan Eissing" , "Julian Reschke" Cc: "Clemm, Geoff" , "WebDAV" Date: Fri, 7 Mar 2003 11:25:50 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) In-Reply-To: <911463B0-5083-11D7-B755-00039384827E@greenbytes.de> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal Subject: RE: bind draft issues X-Archived-At: http://www.w3.org/mid/JIEGINCHMLABHJBIGKBCIEACGLAA.julian.reschke@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7404 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit > From: Stefan Eissing [mailto:stefan.eissing@greenbytes.de] > Sent: Friday, March 07, 2003 11:00 AM > To: Julian Reschke > Cc: Clemm, Geoff; WebDAV > Subject: Re: bind draft issues > > > > Am Freitag, 07.03.03, um 10:45 Uhr (Europe/Berlin) schrieb Julian > Reschke: > > >> From: w3c-dist-auth-request@w3.org > >> [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Stefan Eissing > >> Sent: Friday, March 07, 2003 10:34 AM > >> To: Julian Reschke > >> Cc: Clemm, Geoff; WebDAV > >> Subject: Re: bind draft issues > >> > >> ... > >> > >>>> Hmm, I think I know what you mean, however there are cases > >>>> where you might want this to break: > >>>> > >>>> 1) variants. /news/english/ and /news/german/ might be the same > >>>> resource with different content based on the "access" URL. All > >>>> get* properties will probably vary. (They can already vary on > >>>> a resource with a single binding) > >>> > >>> That would mean that entities may vary based on the request URI. Is > >>> this the > >>> case? > >> > >> I thought that's what I wrote. > > > > OK, I rephrase it: that would mean that a resource is *allowed* to vary > > based on the request URL. I don't think we all agree on that. > > Uhh, it can vary based on "Accept-Language" request header. Why should > it not vary on the request URI of the GET? If we allow the entity to vary based on the URL, what exactly can I rely to be constant? What's the point of having the concept of "same" resource then? > [...] > >>>> What exactly is it, you want to prevent to happen? > >>> > >>> People falling into the trap of believing in "URL properties", I > >>> guess. > >> > >> Probably a good guess of Geoff's intentions. Why not give a guess > >> what an "URL property" exactly is? That would be most welcome. > > > > Our (Geoff's any my) understanding is that there *are* no URL > > properties. A > > URL property would be something that varies with the request URL > > (under the > > relaxed "sameness" definition stated above). > > So: properties can vary based on HTTP request headers, but not based on > the HTTP request URI? Or do you think they should not vary based on Yes. > HTTP request headers either? Or that only the get* properties are allowed > to do that? Properties right now do not distinguish between resource properties and entity properties. That's a design bug inherited from the HTTP header mechanism. I don't think there's an easy way to fix this. -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Fri Mar 7 06:56:59 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA22099 for ; Fri, 7 Mar 2003 06:56:54 -0500 (EST) Received: from frink.w3.org (localhost [127.0.0.1]) by frink.w3.org (8.12.8/8.12.8) with ESMTP id h27BwEHB026903; Fri, 7 Mar 2003 06:58:14 -0500 (EST) Received: (from lists@localhost) by frink.w3.org (8.12.8/8.12.8/Submit) id h27Bw0m9026869; Fri, 7 Mar 2003 06:58:00 -0500 (EST) Resent-Date: Fri, 7 Mar 2003 06:58:00 -0500 (EST) Resent-Message-Id: <200303071158.h27Bw0m9026869@frink.w3.org> Received: from tux.w3.org (IDENT:root@tux [18.29.0.27]) by frink.w3.org (8.12.8/8.12.8) with ESMTP id h27Bv5HB026828 for ; Fri, 7 Mar 2003 06:57:05 -0500 (EST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by tux.w3.org (8.12.8/8.12.8) with ESMTP id h27Bv4rB029601 for ; Fri, 7 Mar 2003 06:57:04 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA21728; Fri, 7 Mar 2003 06:54:58 -0500 (EST) Message-Id: <200303071154.GAA21728@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: w3c-dist-auth@w3.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Fri, 07 Mar 2003 06:54:58 -0500 Subject: I-D ACTION:draft-ietf-webdav-quota-01.txt X-Archived-At: http://www.w3.org/mid/200303071154.GAA21728@ietf.org Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7405 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the WWW Distributed Authoring and Versioning Working Group of the IETF. Title : Quota and Size Properties for DAV Collections Author(s) : B. Korver, L. Dusseault, C. Warner Filename : draft-ietf-webdav-quota-01.txt Pages : 9 Date : 2003-3-6 WebDAV servers are frequently deployed with collection quota (size) limitations. This Internet-Draft discusses the two properties and minor behaviors needed for clients to interoperate with quota implementations on WebDAV repositories. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-webdav-quota-01.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-ietf-webdav-quota-01.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-ietf-webdav-quota-01.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: <2003-3-6125529.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-webdav-quota-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-webdav-quota-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-3-6125529.I-D@ietf.org> --OtherAccess-- --NextPart-- From w3c-dist-auth-request@w3.org Fri Mar 7 08:55:12 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA02043 for ; Fri, 7 Mar 2003 08:55:07 -0500 (EST) Received: from frink.w3.org (localhost [127.0.0.1]) by frink.w3.org (8.12.8/8.12.8) with ESMTP id h27DuYHB013178; Fri, 7 Mar 2003 08:56:34 -0500 (EST) Received: (from lists@localhost) by frink.w3.org (8.12.8/8.12.8/Submit) id h27DuUJH013158; Fri, 7 Mar 2003 08:56:30 -0500 (EST) Resent-Date: Fri, 7 Mar 2003 08:56:30 -0500 (EST) Resent-Message-Id: <200303071356.h27DuUJH013158@frink.w3.org> Received: from tux.w3.org (IDENT:root@tux [18.29.0.27]) by frink.w3.org (8.12.8/8.12.8) with ESMTP id h27DtbHB013081 for ; Fri, 7 Mar 2003 08:55:37 -0500 (EST) Received: from sus-ma1it31.rational.com (sus-ma1it31.rational.com [130.213.73.33]) by tux.w3.org (8.12.8/8.12.8) with ESMTP id h27DtbrB020580 for ; Fri, 7 Mar 2003 08:55:37 -0500 Received: from sus-ma1it00.rational.com ([10.64.1.25]) by 10.64.1.33 with InterScan Messaging Security Suite; Fri, 07 Mar 2003 08:39:19 -0500 Received: by sus-ma1it00.rational.com with Internet Mail Service (5.5.2656.59) id ; Fri, 7 Mar 2003 08:55:30 -0500 Message-ID: From: "Clemm, Geoff" To: "'WebDAV'" Date: Fri, 7 Mar 2003 08:55:29 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain Subject: RE: Move and Delete (was: bind draft issues) X-Archived-At: http://www.w3.org/mid/E4F2D33B98DF7E4880884B9F0E6FDEE2021C5D54@SUS-MA1IT01 Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7406 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: A few years ago, we did discuss introducing new methods (I prefer UNBIND/REBIND, rather than UNBIND/RENAME) so that a client can specify when it requires atomic behavior rather than "best effort" behavior. Eventually, we concluded that any server that supported multiple bindings to a resource should also be capable of supporting atomic DELETE/MOVE behavior, and since no user would want non-atomic behavior if they could get atomic behavior, it is simplest just to associate the atomic behavior with the support of the BIND operation. But since we have folks who insist their users want non-atomic behavior (even when the server could support atomic behavior!), I'm willing to go back to the UNBIND/REBIND approach. But I'd like to at least provide guidance to implementors stating that DELETE/MOVE *should* be implemented atomically as UNBIND/REBIND if the server is capable of doing so. I've posted a revised version of the binding draft to the binding web site. Let me know what you think. Cheers, Geoff -----Original Message----- From: Julian Reschke [mailto:julian.reschke@gmx.de] > From: Brian Korver > > On Wednesday, March 5, 2003, at 01:48 PM, Brian Korver wrote: > > On Wednesday, March 5, 2003, at 12:34 PM, Julian Reschke wrote: > [snip] > >> Now I *do* agree that in many cases clients will actually *want* the > >> "weak" > >> MOVE. So maybe we should consider supporting both (either by a new > >> method, > >> or by adding parameters to MOVE). > > > > Were you thinking that this header (say "Atomic-Operation:") would be > used for only MOVE, or for all of the relevant operations (COPY, > DELETE, etc.)? Actually, I'd really prefer not to define additional headers. Thinking of it, we *also* can't agree on the right DELETE semantics (see separate discussion). So one way to address this would be to leave DELETE and MOVE as they are, and to add - UNBIND (that really really really removes bindings, thus has the DELETE semantics currently specified by the BIND draft) and - RENAME (which would be a true MOVE that would fail when the server can't implement it as internal namespace operation). This would make discovery of the new functionality much easier. From w3c-dist-auth-request@w3.org Fri Mar 7 09:10:10 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03116 for ; Fri, 7 Mar 2003 09:10:10 -0500 (EST) Received: from frink.w3.org (localhost [127.0.0.1]) by frink.w3.org (8.12.8/8.12.8) with ESMTP id h27EBfHB016452; Fri, 7 Mar 2003 09:11:41 -0500 (EST) Received: (from lists@localhost) by frink.w3.org (8.12.8/8.12.8/Submit) id h27EBet2016425; Fri, 7 Mar 2003 09:11:40 -0500 (EST) Resent-Date: Fri, 7 Mar 2003 09:11:40 -0500 (EST) Resent-Message-Id: <200303071411.h27EBet2016425@frink.w3.org> Received: from tux.w3.org (IDENT:root@tux [18.29.0.27]) by frink.w3.org (8.12.8/8.12.8) with ESMTP id h27EAtHB016379 for ; Fri, 7 Mar 2003 09:10:55 -0500 (EST) Received: from mail.gmx.net (mail.gmx.net [213.165.65.60]) by tux.w3.org (8.12.8/8.12.8) with SMTP id h27EAsrB025052 for ; Fri, 7 Mar 2003 09:10:54 -0500 Received: (qmail 32633 invoked by uid 0); 7 Mar 2003 14:10:48 -0000 Received: from mail.greenbytes.de (HELO lisa) (217.5.201.10) by mail.gmx.net (mp010-rz3) with SMTP; 7 Mar 2003 14:10:48 -0000 From: "Julian Reschke" To: "Clemm, Geoff" , "'WebDAV'" Date: Fri, 7 Mar 2003 15:10:47 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal Subject: RE: Move and Delete (was: bind draft issues) X-Archived-At: http://www.w3.org/mid/JIEGINCHMLABHJBIGKBCIEAIGLAA.julian.reschke@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7407 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit Geoff, thanks for the update. I think this will allow us to make progress towards getting the spec finished. One comment re: > rather than "best effort" behavior. Eventually, we concluded > that any server that supported multiple bindings to > a resource should also be capable of supporting atomic > DELETE/MOVE behavior, and since no user would want non-atomic A server may want to implement *parts* of the binding spec without actually allowing the explicit creation of new bindings. In particular, supporting DAV:resource-id seems to be a very useful thing even if a server doesn't plan to support *multiple* bindings. Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 > -----Original Message----- > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Clemm, Geoff > Sent: Friday, March 07, 2003 2:55 PM > To: 'WebDAV' > Subject: RE: Move and Delete (was: bind draft issues) > > > > A few years ago, we did discuss introducing new methods > (I prefer UNBIND/REBIND, rather than UNBIND/RENAME) so > that a client can specify when it requires atomic behavior > rather than "best effort" behavior. Eventually, we concluded > that any server that supported multiple bindings to > a resource should also be capable of supporting atomic > DELETE/MOVE behavior, and since no user would want non-atomic > behavior if they could get atomic behavior, it is simplest just > to associate the atomic behavior with the support of > the BIND operation. > > But since we have folks who insist their users want non-atomic > behavior (even when the server could support atomic behavior!), > I'm willing to go back to the UNBIND/REBIND approach. But I'd > like to at least provide guidance to implementors stating that > DELETE/MOVE *should* be implemented atomically as UNBIND/REBIND > if the server is capable of doing so. > > I've posted a revised version of the binding draft to the > binding web site. Let me know what you think. > > > Cheers, > Geoff > > -----Original Message----- > From: Julian Reschke [mailto:julian.reschke@gmx.de] > > > From: Brian Korver > > > > On Wednesday, March 5, 2003, at 01:48 PM, Brian Korver wrote: > > > > On Wednesday, March 5, 2003, at 12:34 PM, Julian Reschke wrote: > > [snip] > > > >> Now I *do* agree that in many cases clients will actually *want* the > > >> "weak" > > >> MOVE. So maybe we should consider supporting both (either by a new > > >> method, > > >> or by adding parameters to MOVE). > > > > > > > Were you thinking that this header (say "Atomic-Operation:") would be > > used for only MOVE, or for all of the relevant operations (COPY, > > DELETE, etc.)? > > Actually, I'd really prefer not to define additional headers. > > Thinking of it, we *also* can't agree on the right DELETE semantics (see > separate discussion). So one way to address this would be to leave DELETE > and MOVE as they are, and to add > > - UNBIND (that really really really removes bindings, thus has the DELETE > semantics currently specified by the BIND draft) and > - RENAME (which would be a true MOVE that would fail when the server can't > implement it as internal namespace operation). > > This would make discovery of the new functionality much easier. > From w3c-dist-auth-request@w3.org Fri Mar 7 09:24:06 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04159 for ; Fri, 7 Mar 2003 09:24:06 -0500 (EST) Received: from frink.w3.org (localhost [127.0.0.1]) by frink.w3.org (8.12.8/8.12.8) with ESMTP id h27EPcHB018721; Fri, 7 Mar 2003 09:25:39 -0500 (EST) Received: (from lists@localhost) by frink.w3.org (8.12.8/8.12.8/Submit) id h27EPY0q018674; Fri, 7 Mar 2003 09:25:34 -0500 (EST) Resent-Date: Fri, 7 Mar 2003 09:25:34 -0500 (EST) Resent-Message-Id: <200303071425.h27EPY0q018674@frink.w3.org> Received: from tux.w3.org (IDENT:root@tux [18.29.0.27]) by frink.w3.org (8.12.8/8.12.8) with ESMTP id h27EOmHB018445 for ; Fri, 7 Mar 2003 09:24:48 -0500 (EST) Received: from greenbytes.de (mail.greenbytes.de [217.5.201.10] (may be forged)) by tux.w3.org (8.12.8/8.12.8) with SMTP id h27EOlrB030419 for ; Fri, 7 Mar 2003 09:24:48 -0500 Received: from lisa ([192.168.1.23]) by greenbytes.de ([217.5.201.11]) with SMTP (MDaemon.PRO.v6.7.0.R) for ; Fri, 07 Mar 2003 15:23:41 +0100 From: "Julian Reschke" To: "'WebDAV'" Date: Fri, 7 Mar 2003 15:23:41 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal X-MDRemoteIP: 192.168.1.23 X-Return-Path: julian.reschke@greenbytes.de X-MDaemon-Deliver-To: w3c-dist-auth@w3.org Subject: GULP vs RFC2518bis X-Archived-At: http://www.w3.org/mid/JIEGINCHMLABHJBIGKBCIEAJGLAA.julian.reschke@greenbytes.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7408 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hi. I'd really like to see some progress regarding this issue. In http://lists.w3.org/Archives/Public/w3c-dist-auth/2003JanMar/0281.html I have tried to rephrase GULP so that it doesn't require the term "binding" anymore. This should address the concerns of those who fear that a dependency on the BIND spec is introduced. To those who did object to GULP being part of RFC2518bis *please* review this? Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Fri Mar 7 09:32:46 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04757 for ; Fri, 7 Mar 2003 09:32:46 -0500 (EST) Received: from frink.w3.org (localhost [127.0.0.1]) by frink.w3.org (8.12.8/8.12.8) with ESMTP id h27EYQHB020201; Fri, 7 Mar 2003 09:34:26 -0500 (EST) Received: (from lists@localhost) by frink.w3.org (8.12.8/8.12.8/Submit) id h27EYPVY020183; Fri, 7 Mar 2003 09:34:25 -0500 (EST) Resent-Date: Fri, 7 Mar 2003 09:34:25 -0500 (EST) Resent-Message-Id: <200303071434.h27EYPVY020183@frink.w3.org> Received: from tux.w3.org (IDENT:root@tux [18.29.0.27]) by frink.w3.org (8.12.8/8.12.8) with ESMTP id h27EXdHB020140 for ; Fri, 7 Mar 2003 09:33:39 -0500 (EST) Received: from mail.gmx.net (mail.gmx.net [213.165.65.60]) by tux.w3.org (8.12.8/8.12.8) with SMTP id h27EXcrB001668 for ; Fri, 7 Mar 2003 09:33:38 -0500 Received: (qmail 10255 invoked by uid 0); 7 Mar 2003 14:33:32 -0000 Received: from mail.greenbytes.de (HELO lisa) (217.5.201.10) by mail.gmx.net (mp007-rz3) with SMTP; 7 Mar 2003 14:33:32 -0000 From: "Julian Reschke" To: "Clemm, Geoff" , "'WebDAV'" Date: Fri, 7 Mar 2003 15:33:31 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal Subject: RE: Move and Delete (was: bind draft issues) X-Archived-At: http://www.w3.org/mid/JIEGINCHMLABHJBIGKBCIEAKGLAA.julian.reschke@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7409 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit Geoff, in 2.5 you say: "If the destination collection of a MOVE request supports the REBIND method (see Section 6), a MOVE of a resource into that collection SHOULD be implemented as a REBIND request. In this case, applying a MOVE to a Request-URI and a Destination URI has the effect of removing a binding to a resource (at the Request-URI), and creating a new binding to that resource (at the Destination URI)." I think it's a bit more complicated than that. For instance, if a WebDAV server is implemented on top of a Unix file system (using inode numbers to compute a part of the DAV:resource-id property), a target collection may indeed support REBIND, but not for all resources that are served by the server (in case it serves files from different filesystem partitions). So, how about something like: "If the destination collection of a MOVE request supports the REBIND method (...) for a request specifying the MOVE request URL as DAV:href...." Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 > -----Original Message----- > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Clemm, Geoff > Sent: Friday, March 07, 2003 2:55 PM > To: 'WebDAV' > Subject: RE: Move and Delete (was: bind draft issues) > > > > A few years ago, we did discuss introducing new methods > (I prefer UNBIND/REBIND, rather than UNBIND/RENAME) so > that a client can specify when it requires atomic behavior > rather than "best effort" behavior. Eventually, we concluded > that any server that supported multiple bindings to > a resource should also be capable of supporting atomic > DELETE/MOVE behavior, and since no user would want non-atomic > behavior if they could get atomic behavior, it is simplest just > to associate the atomic behavior with the support of > the BIND operation. > > But since we have folks who insist their users want non-atomic > behavior (even when the server could support atomic behavior!), > I'm willing to go back to the UNBIND/REBIND approach. But I'd > like to at least provide guidance to implementors stating that > DELETE/MOVE *should* be implemented atomically as UNBIND/REBIND > if the server is capable of doing so. > > I've posted a revised version of the binding draft to the > binding web site. Let me know what you think. > > > Cheers, > Geoff > > -----Original Message----- > From: Julian Reschke [mailto:julian.reschke@gmx.de] > > > From: Brian Korver > > > > On Wednesday, March 5, 2003, at 01:48 PM, Brian Korver wrote: > > > > On Wednesday, March 5, 2003, at 12:34 PM, Julian Reschke wrote: > > [snip] > > > >> Now I *do* agree that in many cases clients will actually *want* the > > >> "weak" > > >> MOVE. So maybe we should consider supporting both (either by a new > > >> method, > > >> or by adding parameters to MOVE). > > > > > > > Were you thinking that this header (say "Atomic-Operation:") would be > > used for only MOVE, or for all of the relevant operations (COPY, > > DELETE, etc.)? > > Actually, I'd really prefer not to define additional headers. > > Thinking of it, we *also* can't agree on the right DELETE semantics (see > separate discussion). So one way to address this would be to leave DELETE > and MOVE as they are, and to add > > - UNBIND (that really really really removes bindings, thus has the DELETE > semantics currently specified by the BIND draft) and > - RENAME (which would be a true MOVE that would fail when the server can't > implement it as internal namespace operation). > > This would make discovery of the new functionality much easier. > From w3c-dist-auth-request@w3.org Fri Mar 7 10:08:41 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08995 for ; Fri, 7 Mar 2003 10:08:41 -0500 (EST) Received: from frink.w3.org (localhost [127.0.0.1]) by frink.w3.org (8.12.8/8.12.8) with ESMTP id h27F9vHB005122; Fri, 7 Mar 2003 10:09:57 -0500 (EST) Received: (from lists@localhost) by frink.w3.org (8.12.8/8.12.8/Submit) id h27F9pwI005042; Fri, 7 Mar 2003 10:09:51 -0500 (EST) Resent-Date: Fri, 7 Mar 2003 10:09:51 -0500 (EST) Resent-Message-Id: <200303071509.h27F9pwI005042@frink.w3.org> Received: from tux.w3.org (IDENT:root@tux [18.29.0.27]) by frink.w3.org (8.12.8/8.12.8) with ESMTP id h27F8vHB004796 for ; Fri, 7 Mar 2003 10:08:57 -0500 (EST) Received: from sus-ma1it31.rational.com (sus-ma1it31.rational.com [130.213.73.33]) by tux.w3.org (8.12.8/8.12.8) with ESMTP id h27F8vrB022159 for ; Fri, 7 Mar 2003 10:08:57 -0500 Received: from sus-ma1it00.rational.com ([10.64.1.25]) by 10.64.1.33 with InterScan Messaging Security Suite; Fri, 07 Mar 2003 09:52:39 -0500 Received: by sus-ma1it00.rational.com with Internet Mail Service (5.5.2656.59) id ; Fri, 7 Mar 2003 10:08:50 -0500 Message-ID: From: "Clemm, Geoff" To: "'WebDAV'" Date: Fri, 7 Mar 2003 10:08:49 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Move and Delete (was: bind draft issues) X-Archived-At: http://www.w3.org/mid/E4F2D33B98DF7E4880884B9F0E6FDEE2021C5D7D@SUS-MA1IT01 Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7410 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: I think the "SHOULD" gives the implementor enough leeway in this case, so it would be better to leave it in its slightly simpler current form. Cheers, Geoff -----Original Message----- From: Julian Reschke [mailto:julian.reschke@gmx.de] Sent: Friday, March 07, 2003 9:34 AM To: Clemm, Geoff; 'WebDAV' Subject: RE: Move and Delete (was: bind draft issues) Geoff, in 2.5 you say: "If the destination collection of a MOVE request supports the REBIND method (see Section 6), a MOVE of a resource into that collection SHOULD be implemented as a REBIND request. In this case, applying a MOVE to a Request-URI and a Destination URI has the effect of removing a binding to a resource (at the Request-URI), and creating a new binding to that resource (at the Destination URI)." I think it's a bit more complicated than that. For instance, if a WebDAV server is implemented on top of a Unix file system (using inode numbers to compute a part of the DAV:resource-id property), a target collection may indeed support REBIND, but not for all resources that are served by the server (in case it serves files from different filesystem partitions). So, how about something like: "If the destination collection of a MOVE request supports the REBIND method (...) for a request specifying the MOVE request URL as DAV:href...." Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 > -----Original Message----- > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Clemm, Geoff > Sent: Friday, March 07, 2003 2:55 PM > To: 'WebDAV' > Subject: RE: Move and Delete (was: bind draft issues) > > > > A few years ago, we did discuss introducing new methods > (I prefer UNBIND/REBIND, rather than UNBIND/RENAME) so > that a client can specify when it requires atomic behavior > rather than "best effort" behavior. Eventually, we concluded > that any server that supported multiple bindings to > a resource should also be capable of supporting atomic > DELETE/MOVE behavior, and since no user would want non-atomic > behavior if they could get atomic behavior, it is simplest just > to associate the atomic behavior with the support of > the BIND operation. > > But since we have folks who insist their users want non-atomic > behavior (even when the server could support atomic behavior!), > I'm willing to go back to the UNBIND/REBIND approach. But I'd > like to at least provide guidance to implementors stating that > DELETE/MOVE *should* be implemented atomically as UNBIND/REBIND > if the server is capable of doing so. > > I've posted a revised version of the binding draft to the > binding web site. Let me know what you think. > > > Cheers, > Geoff > > -----Original Message----- > From: Julian Reschke [mailto:julian.reschke@gmx.de] > > > From: Brian Korver > > > > On Wednesday, March 5, 2003, at 01:48 PM, Brian Korver wrote: > > > > On Wednesday, March 5, 2003, at 12:34 PM, Julian Reschke wrote: > > [snip] > > > >> Now I *do* agree that in many cases clients will actually *want* the > > >> "weak" > > >> MOVE. So maybe we should consider supporting both (either by a new > > >> method, > > >> or by adding parameters to MOVE). > > > > > > > Were you thinking that this header (say "Atomic-Operation:") would be > > used for only MOVE, or for all of the relevant operations (COPY, > > DELETE, etc.)? > > Actually, I'd really prefer not to define additional headers. > > Thinking of it, we *also* can't agree on the right DELETE semantics (see > separate discussion). So one way to address this would be to leave DELETE > and MOVE as they are, and to add > > - UNBIND (that really really really removes bindings, thus has the DELETE > semantics currently specified by the BIND draft) and > - RENAME (which would be a true MOVE that would fail when the server can't > implement it as internal namespace operation). > > This would make discovery of the new functionality much easier. > From w3c-dist-auth-request@w3.org Fri Mar 7 10:28:03 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10669 for ; Fri, 7 Mar 2003 10:28:03 -0500 (EST) Received: from frink.w3.org (localhost [127.0.0.1]) by frink.w3.org (8.12.8/8.12.8) with ESMTP id h27FTNHB023234; Fri, 7 Mar 2003 10:29:23 -0500 (EST) Received: (from lists@localhost) by frink.w3.org (8.12.8/8.12.8/Submit) id h27FOmPH019175; Fri, 7 Mar 2003 10:24:59 -0500 (EST) Resent-Date: Fri, 7 Mar 2003 10:24:59 -0500 (EST) Resent-Message-Id: <200303071524.h27FOmPH019175@frink.w3.org> Received: from tux.w3.org (IDENT:root@tux [18.29.0.27]) by frink.w3.org (8.12.8/8.12.8) with ESMTP id h27FM9HB013750 for ; Fri, 7 Mar 2003 10:22:12 -0500 (EST) Received: from sus-ma1it31.rational.com (sus-ma1it31.rational.com [130.213.73.33]) by tux.w3.org (8.12.8/8.12.8) with ESMTP id h27FJ2rB028828 for ; Fri, 7 Mar 2003 10:19:03 -0500 Received: from sus-ma1it00.rational.com ([10.64.1.25]) by 10.64.1.33 with InterScan Messaging Security Suite; Fri, 07 Mar 2003 10:02:45 -0500 Received: by sus-ma1it00.rational.com with Internet Mail Service (5.5.2656.59) id ; Fri, 7 Mar 2003 10:18:56 -0500 Message-ID: From: "Clemm, Geoff" To: WebDAV Date: Fri, 7 Mar 2003 10:18:56 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain Subject: RE: bind draft issues X-Archived-At: http://www.w3.org/mid/E4F2D33B98DF7E4880884B9F0E6FDEE2021C5D84@SUS-MA1IT01 Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7411 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Brian: These are the kinds of issues that led us to remove any discussion of PROPFIND from the bindings draft. My conclusion is that our best approach is to leave it up to 2518bis to define generically how property values behave in the presence of multiple URL mappings to the same resource (since that is base WebDAV functionality, not something introduced by the binding spec), and the binding draft will focus on the semantics it introduces (such as the DAV:resource-id property, whose behavior in the presence of multiple URL mappings is defined). The binding spec can then focus on the semantics that it is introducing, i.e. client creation of multiple URL mappings, the resource-id property, and atomic MOVE/DELETE via REBIND/UNBIND. Cheers, Geoff -----Original Message----- From: Julian Reschke [mailto:julian.reschke@gmx.de] Sent: Friday, March 07, 2003 5:26 AM To: Stefan Eissing; Julian Reschke Cc: Clemm, Geoff; WebDAV Subject: RE: bind draft issues > From: Stefan Eissing [mailto:stefan.eissing@greenbytes.de] > Sent: Friday, March 07, 2003 11:00 AM > To: Julian Reschke > Cc: Clemm, Geoff; WebDAV > Subject: Re: bind draft issues > > > > Am Freitag, 07.03.03, um 10:45 Uhr (Europe/Berlin) schrieb Julian > Reschke: > > >> From: w3c-dist-auth-request@w3.org > >> [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Stefan Eissing > >> Sent: Friday, March 07, 2003 10:34 AM > >> To: Julian Reschke > >> Cc: Clemm, Geoff; WebDAV > >> Subject: Re: bind draft issues > >> > >> ... > >> > >>>> Hmm, I think I know what you mean, however there are cases > >>>> where you might want this to break: > >>>> > >>>> 1) variants. /news/english/ and /news/german/ might be the same > >>>> resource with different content based on the "access" URL. All > >>>> get* properties will probably vary. (They can already vary on > >>>> a resource with a single binding) > >>> > >>> That would mean that entities may vary based on the request URI. Is > >>> this the > >>> case? > >> > >> I thought that's what I wrote. > > > > OK, I rephrase it: that would mean that a resource is *allowed* to vary > > based on the request URL. I don't think we all agree on that. > > Uhh, it can vary based on "Accept-Language" request header. Why should > it not vary on the request URI of the GET? If we allow the entity to vary based on the URL, what exactly can I rely to be constant? What's the point of having the concept of "same" resource then? > [...] > >>>> What exactly is it, you want to prevent to happen? > >>> > >>> People falling into the trap of believing in "URL properties", I > >>> guess. > >> > >> Probably a good guess of Geoff's intentions. Why not give a guess > >> what an "URL property" exactly is? That would be most welcome. > > > > Our (Geoff's any my) understanding is that there *are* no URL > > properties. A > > URL property would be something that varies with the request URL > > (under the > > relaxed "sameness" definition stated above). > > So: properties can vary based on HTTP request headers, but not based on > the HTTP request URI? Or do you think they should not vary based on Yes. > HTTP request headers either? Or that only the get* properties are allowed > to do that? Properties right now do not distinguish between resource properties and entity properties. That's a design bug inherited from the HTTP header mechanism. I don't think there's an easy way to fix this. -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Fri Mar 7 11:27:40 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14476 for ; Fri, 7 Mar 2003 11:27:39 -0500 (EST) Received: from frink.w3.org (localhost [127.0.0.1]) by frink.w3.org (8.12.8/8.12.8) with ESMTP id h27GNqHB001447; Fri, 7 Mar 2003 11:23:52 -0500 (EST) Received: (from lists@localhost) by frink.w3.org (8.12.8/8.12.8/Submit) id h27GNmiR001409; Fri, 7 Mar 2003 11:23:48 -0500 (EST) Resent-Date: Fri, 7 Mar 2003 11:23:48 -0500 (EST) Resent-Message-Id: <200303071623.h27GNmiR001409@frink.w3.org> Received: from tux.w3.org (IDENT:root@tux [18.29.0.27]) by frink.w3.org (8.12.8/8.12.8) with ESMTP id h27GN6HB001335 for ; Fri, 7 Mar 2003 11:23:06 -0500 (EST) Received: from greenbytes.de (mail.greenbytes.de [217.5.201.10] (may be forged)) by tux.w3.org (8.12.8/8.12.8) with SMTP id h27GN6rB031055 for ; Fri, 7 Mar 2003 11:23:06 -0500 Received: from greenbytes.de ([192.168.1.23]) by greenbytes.de ([217.5.201.11]) with SMTP (MDaemon.PRO.v6.7.0.R) for ; Fri, 07 Mar 2003 17:22:41 +0100 Date: Fri, 7 Mar 2003 17:22:41 +0100 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: "'WebDAV'" To: "Julian Reschke" From: Stefan Eissing In-Reply-To: Message-Id: <051189C4-50B9-11D7-B755-00039384827E@greenbytes.de> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) X-MDRemoteIP: 192.168.1.23 X-Return-Path: stefan.eissing@greenbytes.de X-MDaemon-Deliver-To: w3c-dist-auth@w3.org Subject: Re: GULP vs RFC2518bis X-Archived-At: http://www.w3.org/mid/051189C4-50B9-11D7-B755-00039384827E@greenbytes.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7412 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit I think GULP should, with the proposed changes, go into RFC2518 bis. LOCKing semantics need to be defined in 2518bis and not in any side-track specification (sorry Goeff ;). //Stefan Am Freitag, 07.03.03, um 15:23 Uhr (Europe/Berlin) schrieb Julian Reschke: > > Hi. > > I'd really like to see some progress regarding this issue. In > > http://lists.w3.org/Archives/Public/w3c-dist-auth/2003JanMar/0281.html > > I have tried to rephrase GULP so that it doesn't require the term > "binding" > anymore. This should address the concerns of those who fear that a > dependency on the BIND spec is introduced. > > To those who did object to GULP being part of RFC2518bis *please* > review > this? > > Julian > > -- > bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 > From w3c-dist-auth-request@w3.org Fri Mar 7 12:18:59 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17995 for ; Fri, 7 Mar 2003 12:18:59 -0500 (EST) Received: from frink.w3.org (localhost [127.0.0.1]) by frink.w3.org (8.12.8/8.12.8) with ESMTP id h27HKIHB020018; Fri, 7 Mar 2003 12:20:18 -0500 (EST) Received: (from lists@localhost) by frink.w3.org (8.12.8/8.12.8/Submit) id h27HKFFp019997; Fri, 7 Mar 2003 12:20:15 -0500 (EST) Resent-Date: Fri, 7 Mar 2003 12:20:15 -0500 (EST) Resent-Message-Id: <200303071720.h27HKFFp019997@frink.w3.org> Received: from tux.w3.org (IDENT:root@tux [18.29.0.27]) by frink.w3.org (8.12.8/8.12.8) with ESMTP id h27HJJHB019900 for ; Fri, 7 Mar 2003 12:19:19 -0500 (EST) Received: from sunbelt.seagull.net (user34.net540.or.sprint-hsd.net [65.40.225.34]) by tux.w3.org (8.12.8/8.12.8) with ESMTP id h27HJCrB021038 for ; Fri, 7 Mar 2003 12:19:17 -0500 Received: (mail@localhost) by sunbelt.seagull.net (8.9.3) id JAA05643 sender nn683849@smallcue.com for w3c-dist-auth@w3.org; Fri, 7 Mar 2003 09:19:10 -0800 Received: from e3.ny.us.ibm.com (e3.ny.us.ibm.com [32.97.182.103]) by sunbelt.seagull.net (8.9.3) with ESMTP id JAA05627 sender obsfucated@us.ibm.com; Fri, 7 Mar 2003 09:19:08 -0800 Received: from northrelay04.pok.ibm.com (northrelay04.pok.ibm.com [9.56.224.206]) by e3.ny.us.ibm.com (8.12.8/8.12.2) with ESMTP id h27HIal9027522; Fri, 7 Mar 2003 12:18:36 -0500 Received: from d01ml243.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by northrelay04.pok.ibm.com (8.12.8/NCO/VER6.5) with ESMTP id h27HIXPL081432; Fri, 7 Mar 2003 12:18:33 -0500 To: "Clemm, Geoff" Cc: "'WebDAV'" X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: Jason Crawford Date: Fri, 7 Mar 2003 12:17:55 -0500 X-MIMETrack: Serialize by Router on D01ML243/01/M/IBM(Release 6.0.1 [IBM]|March 6, 2003) at 03/07/2003 12:18:33 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Subject: RE: Move and Delete (was: bind draft issues) X-Archived-At: http://www.w3.org/mid/OFC1A2B704.6358E356-ON85256CE2.005BCF8C@us.ibm.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7413 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: > I've posted a revised version of the binding draft to the > binding web site. Let me know what you think. > Sorry to be a pain, but the reason we say that we are splitting in to DELETE and UNBIND is because some people claim that clients prefer the non-atomic DELETE functionality. But the new bindings document says that if the server can implement UNBIND, then DELETE should be implemented that way. This leaves me scratching my head. 1) Do users ever want the old DELETE functionality if they can have UNBIND? 2) If we really believe that they do, why do we suggest that the server do the UNBIND anyway? It sounds like we really haven't decided (1). Let's really decide that and then spec this to match what we resolve. J. ------------------------------------------ Phone: 914-784-7569, ccjason@us.ibm.com I do not check nn621779@smallcue.com From w3c-dist-auth-request@w3.org Fri Mar 7 13:10:49 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21094 for ; Fri, 7 Mar 2003 13:10:48 -0500 (EST) Received: from frink.w3.org (localhost [127.0.0.1]) by frink.w3.org (8.12.8/8.12.8) with ESMTP id h27IC2HB001861; Fri, 7 Mar 2003 13:12:02 -0500 (EST) Received: (from lists@localhost) by frink.w3.org (8.12.8/8.12.8/Submit) id h27IBpqa001830; Fri, 7 Mar 2003 13:11:51 -0500 (EST) Resent-Date: Fri, 7 Mar 2003 13:11:51 -0500 (EST) Resent-Message-Id: <200303071811.h27IBpqa001830@frink.w3.org> Received: from tux.w3.org (IDENT:root@tux [18.29.0.27]) by frink.w3.org (8.12.8/8.12.8) with ESMTP id h27IB8HB001754 for ; Fri, 7 Mar 2003 13:11:08 -0500 (EST) Received: from mail.gmx.net (mail.gmx.net [213.165.65.60]) by tux.w3.org (8.12.8/8.12.8) with SMTP id h27IB6rB001178 for ; Fri, 7 Mar 2003 13:11:07 -0500 Received: (qmail 8442 invoked by uid 0); 7 Mar 2003 18:11:00 -0000 Received: from mail.greenbytes.de (HELO lisa) (217.5.201.10) by mail.gmx.net (mp003-rz3) with SMTP; 7 Mar 2003 18:11:00 -0000 From: "Julian Reschke" To: "Jason Crawford" , "Clemm, Geoff" Cc: "'WebDAV'" Date: Fri, 7 Mar 2003 19:10:59 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal Subject: RE: Move and Delete (was: bind draft issues) X-Archived-At: http://www.w3.org/mid/JIEGINCHMLABHJBIGKBCCEBGGLAA.julian.reschke@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7414 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Jason Crawford > Sent: Friday, March 07, 2003 6:18 PM > To: Clemm, Geoff > Cc: 'WebDAV' > Subject: RE: Move and Delete (was: bind draft issues) > > > > > > > > I've posted a revised version of the binding draft to the > > binding web site. Let me know what you think. > > > > > Sorry to be a pain, but the reason we say that we are splitting in to DELETE and UNBIND is > because some people claim that clients prefer the non-atomic DELETE functionality. But the > new bindings document says that if the server can implement UNBIND, then DELETE should > be implemented that way. This leaves me scratching my head. > > 1) Do users ever want the old DELETE functionality if they can > have UNBIND? I think so. Where it's not really (only) about what the user (client) wants, but it also depends on what the server is willing to offer. It maybe technically possible to implement UNBIND (that's very likely if you have a proper BIND implementation), yet still undesired. > 2) If we really believe that they do, why do we suggest that the server do > the UNBIND anyway? Do we? I think what the spec says is that if a server supports UNBIND on a collection, DELETE should behave the same. So the choice is on the server's side. This doesn't give the *client* the ability to decide, though. Do we need that? > It sounds like we really haven't decided (1). Let's really decide that and then spec this to match > what we resolve. Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Fri Mar 7 13:29:50 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21798 for ; Fri, 7 Mar 2003 13:29:49 -0500 (EST) Received: from frink.w3.org (localhost [127.0.0.1]) by frink.w3.org (8.12.8/8.12.8) with ESMTP id h27IVFHB003983; Fri, 7 Mar 2003 13:31:15 -0500 (EST) Received: (from lists@localhost) by frink.w3.org (8.12.8/8.12.8/Submit) id h27IVCfU003963; Fri, 7 Mar 2003 13:31:12 -0500 (EST) Resent-Date: Fri, 7 Mar 2003 13:31:12 -0500 (EST) Resent-Message-Id: <200303071831.h27IVCfU003963@frink.w3.org> Received: from tux.w3.org (IDENT:root@tux [18.29.0.27]) by frink.w3.org (8.12.8/8.12.8) with ESMTP id h27IUNHB003851 for ; Fri, 7 Mar 2003 13:30:23 -0500 (EST) Received: from mta6.snfc21.pbi.net (mta6.snfc21.pbi.net [206.13.28.240]) by tux.w3.org (8.12.8/8.12.8) with ESMTP id h27IUNrB005487 for ; Fri, 7 Mar 2003 13:30:23 -0500 Received: from cse.ucsc.edu ([63.194.88.161]) by mta6.snfc21.pbi.net (iPlanet Messaging Server 5.1 HotFix 1.6 (built Oct 18 2002)) with ESMTP id <0HBE002Q862I8M@mta6.snfc21.pbi.net> for w3c-dist-auth@w3.org; Fri, 07 Mar 2003 10:30:18 -0800 (PST) Date: Fri, 07 Mar 2003 10:33:40 -0800 From: Elias To: Stefan Eissing Cc: Julian Reschke , "'WebDAV'" Message-id: <3E68E604.3080903@cse.ucsc.edu> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 References: <051189C4-50B9-11D7-B755-00039384827E@greenbytes.de> Subject: Re: GULP vs RFC2518bis X-Archived-At: http://www.w3.org/mid/3E68E604.3080903@cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7415 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7BIT I agree, the specification should clearly define all of the WebDAV methods such that referring to a secondary text is not necessary. The proposed changes to remove the references to bindings don't seem to affect GULP semantics so I would support adding the revised version to 2518bis. Elias Stefan Eissing wrote: > > I think GULP should, with the proposed changes, go into RFC2518 bis. > > LOCKing semantics need to be defined in 2518bis and not in any > side-track specification (sorry Goeff ;). > > //Stefan > > Am Freitag, 07.03.03, um 15:23 Uhr (Europe/Berlin) schrieb Julian > Reschke: > >> >> Hi. >> >> I'd really like to see some progress regarding this issue. In >> >> http://lists.w3.org/Archives/Public/w3c-dist-auth/2003JanMar/0281.html >> >> I have tried to rephrase GULP so that it doesn't require the term >> "binding" >> anymore. This should address the concerns of those who fear that a >> dependency on the BIND spec is introduced. >> >> To those who did object to GULP being part of RFC2518bis *please* review >> this? >> >> Julian >> >> -- >> bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 >> > From w3c-dist-auth-request@w3.org Fri Mar 7 13:58:40 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23086 for ; Fri, 7 Mar 2003 13:58:39 -0500 (EST) Received: from frink.w3.org (localhost [127.0.0.1]) by frink.w3.org (8.12.8/8.12.8) with ESMTP id h27IxwHB027109; Fri, 7 Mar 2003 13:59:58 -0500 (EST) Received: (from lists@localhost) by frink.w3.org (8.12.8/8.12.8/Submit) id h27Ixu75027088; Fri, 7 Mar 2003 13:59:56 -0500 (EST) Resent-Date: Fri, 7 Mar 2003 13:59:56 -0500 (EST) Resent-Message-Id: <200303071859.h27Ixu75027088@frink.w3.org> Received: from tux.w3.org (IDENT:root@tux [18.29.0.27]) by frink.w3.org (8.12.8/8.12.8) with ESMTP id h27IxEHB027052 for ; Fri, 7 Mar 2003 13:59:14 -0500 (EST) Received: from sus-ma1it31.rational.com (sus-ma1it31.rational.com [130.213.73.33]) by tux.w3.org (8.12.8/8.12.8) with ESMTP id h27IxCrB022116 for ; Fri, 7 Mar 2003 13:59:12 -0500 Received: from sus-ma1it00.rational.com ([10.64.1.25]) by 10.64.1.33 with InterScan Messaging Security Suite; Fri, 07 Mar 2003 13:41:47 -0500 Received: by sus-ma1it00.rational.com with Internet Mail Service (5.5.2656.59) id ; Fri, 7 Mar 2003 13:07:54 -0500 Message-ID: From: "Clemm, Geoff" To: "'WebDAV'" Date: Fri, 7 Mar 2003 13:07:53 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain Subject: RE: Move and Delete (was: bind draft issues) X-Archived-At: http://www.w3.org/mid/E4F2D33B98DF7E4880884B9F0E6FDEE25ED6EA@SUS-MA1IT01 Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7416 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: My reading of the consensus of the working group (although certainly not universal agreement) is that atomic behavior on the part of the server is preferable when the server is capable of doing so, especially when multiple bindings to a resource is possible. But since some servers cannot guarantee atomic behavior, this was made a "SHOULD" instead of a "MUST". Similarly, any server implementors that feel their clients want non-atomic behavior can present non-atomic behavior and still be compatible with the spec (because it is a SHOULD, not a MUST). In addition, I believe there was consensus that allowing the client to explicitly request atomic behavior was desireable, and this is achieved through the introduction of UNBIND/REBIND. Cheers, Geoff -----Original Message----- From: Jason Crawford [mailto:nn683849@smallcue.com] > I've posted a revised version of the binding draft to the > binding web site. Let me know what you think. > Sorry to be a pain, but the reason we say that we are splitting in to DELETE and UNBIND is because some people claim that clients prefer the non-atomic DELETE functionality. But the new bindings document says that if the server can implement UNBIND, then DELETE should be implemented that way. This leaves me scratching my head. 1) Do users ever want the old DELETE functionality if they can have UNBIND? 2) If we really believe that they do, why do we suggest that the server do the UNBIND anyway? It sounds like we really haven't decided (1). Let's really decide that and then spec this to match what we resolve. J. ------------------------------------------ Phone: 914-784-7569, ccjason@us.ibm.com I do not check nn621779@smallcue.com From w3c-dist-auth-request@w3.org Fri Mar 7 14:36:13 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24498 for ; Fri, 7 Mar 2003 14:36:12 -0500 (EST) Received: from frink.w3.org (localhost [127.0.0.1]) by frink.w3.org (8.12.8/8.12.8) with ESMTP id h27JbfHB014609; Fri, 7 Mar 2003 14:37:41 -0500 (EST) Received: (from lists@localhost) by frink.w3.org (8.12.8/8.12.8/Submit) id h27Jbcjd014596; Fri, 7 Mar 2003 14:37:38 -0500 (EST) Resent-Date: Fri, 7 Mar 2003 14:37:38 -0500 (EST) Resent-Message-Id: <200303071937.h27Jbcjd014596@frink.w3.org> Received: from tux.w3.org (IDENT:root@tux [18.29.0.27]) by frink.w3.org (8.12.8/8.12.8) with ESMTP id h27JaiHB014516 for ; Fri, 7 Mar 2003 14:36:44 -0500 (EST) Received: from mail.xythos.com ([206.14.210.116]) by tux.w3.org (8.12.8/8.12.8) with ESMTP id h27JahrB010203 for ; Fri, 7 Mar 2003 14:36:43 -0500 Received: from ravms by mail.xythos.com with mail-ok (Exim 3.36 #3) id 18rNfi-0001x1-00 for w3c-dist-auth@w3.org; Fri, 07 Mar 2003 19:38:22 +0000 Received: from ip-216-36-77-241.dsl.sjc.megapath.net ([216.36.77.241] helo=xythos.com) by mail.xythos.com with asmtp (Exim 3.36 #3) id 18rNfi-0001wq-00 for w3c-dist-auth@w3.org; Fri, 07 Mar 2003 19:38:22 +0000 Date: Fri, 7 Mar 2003 11:36:41 -0800 Mime-Version: 1.0 (Apple Message framework v551) Content-Type: text/plain; charset=US-ASCII; format=flowed From: Brian Korver To: WebDAV Content-Transfer-Encoding: 7bit Message-Id: <1F3FAD04-50D4-11D7-8A8F-000393751598@xythos.com> X-Mailer: Apple Mail (2.551) Old-X-Envelope-To: w3c-dist-auth@w3.org Subject: Re: I-D ACTION:draft-ietf-webdav-quota-01.txt X-Archived-At: http://www.w3.org/mid/1F3FAD04-50D4-11D7-8A8F-000393751598@xythos.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7417 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit The new version differs rather substantially from the previous, incorporating the borrowed-from-NFS model that we discussed at the last get together. -brian briank@xythos.com From w3c-dist-auth-request@w3.org Fri Mar 7 14:57:47 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25542 for ; Fri, 7 Mar 2003 14:57:47 -0500 (EST) Received: from frink.w3.org (localhost [127.0.0.1]) by frink.w3.org (8.12.8/8.12.8) with ESMTP id h27JxMHB018500; Fri, 7 Mar 2003 14:59:22 -0500 (EST) Received: (from lists@localhost) by frink.w3.org (8.12.8/8.12.8/Submit) id h27JxJIe018482; Fri, 7 Mar 2003 14:59:19 -0500 (EST) Resent-Date: Fri, 7 Mar 2003 14:59:19 -0500 (EST) Resent-Message-Id: <200303071959.h27JxJIe018482@frink.w3.org> Received: from tux.w3.org (IDENT:root@tux [18.29.0.27]) by frink.w3.org (8.12.8/8.12.8) with ESMTP id h27JwaHB018439 for ; Fri, 7 Mar 2003 14:58:36 -0500 (EST) Received: from mail.xythos.com ([206.14.210.116]) by tux.w3.org (8.12.8/8.12.8) with ESMTP id h27JwarB018586 for ; Fri, 7 Mar 2003 14:58:36 -0500 Received: from ravms by mail.xythos.com with mail-ok (Exim 3.36 #3) id 18rO0t-0002SH-00 for w3c-dist-auth@w3.org; Fri, 07 Mar 2003 20:00:15 +0000 Received: from ip-216-36-77-241.dsl.sjc.megapath.net ([216.36.77.241] helo=xythos.com) by mail.xythos.com with asmtp (Exim 3.36 #3) id 18rO0t-0002S6-00 for w3c-dist-auth@w3.org; Fri, 07 Mar 2003 20:00:15 +0000 Date: Fri, 7 Mar 2003 11:58:34 -0800 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) From: Brian Korver To: "WebDAV" Content-Transfer-Encoding: 7bit In-Reply-To: <911463B0-5083-11D7-B755-00039384827E@greenbytes.de> Message-Id: <2DE8374C-50D7-11D7-8A8F-000393751598@xythos.com> X-Mailer: Apple Mail (2.551) Old-X-Envelope-To: w3c-dist-auth@w3.org Subject: Re: bind draft issues X-Archived-At: http://www.w3.org/mid/2DE8374C-50D7-11D7-8A8F-000393751598@xythos.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7418 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit [snip] > Probably a good guess of Geoff's intentions. Why not give a guess > what an "URL property" exactly is? That would be most welcome. I think I gave that the other day: Perhaps "URL properties" isn't the right term, but what is? In the face of bindings, "URL properties" are those properties which are (potentially) effected by operations on bindings, where "resource properties" are not effected by such operations. In other words, they are the class of properties whose values (potentially) differ based on the URL specified in the PROPFIND (when more than one binding exists to a resource). "URL properties" isn't intended to imply that the property is stored with the URL or anything else like that: it is merely descriptive of behavior. As we discussed earlier, some implementations treat DAV:displayname as just such a property. -brian briank@xythos.com From w3c-dist-auth-request@w3.org Fri Mar 7 14:58:34 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25564 for ; Fri, 7 Mar 2003 14:58:33 -0500 (EST) Received: from frink.w3.org (localhost [127.0.0.1]) by frink.w3.org (8.12.8/8.12.8) with ESMTP id h27JxuHB018651; Fri, 7 Mar 2003 14:59:56 -0500 (EST) Received: (from lists@localhost) by frink.w3.org (8.12.8/8.12.8/Submit) id h27Jxt0N018644; Fri, 7 Mar 2003 14:59:55 -0500 (EST) Resent-Date: Fri, 7 Mar 2003 14:59:55 -0500 (EST) Resent-Message-Id: <200303071959.h27Jxt0N018644@frink.w3.org> Received: from tux.w3.org (IDENT:root@tux [18.29.0.27]) by frink.w3.org (8.12.8/8.12.8) with ESMTP id h27JxrHB018603 for ; Fri, 7 Mar 2003 14:59:53 -0500 (EST) Received: from mail.xythos.com ([206.14.210.116]) by tux.w3.org (8.12.8/8.12.8) with ESMTP id h27JxrrB018861 for ; Fri, 7 Mar 2003 14:59:53 -0500 Received: from ravms by mail.xythos.com with mail-ok (Exim 3.36 #3) id 18rO28-0002U0-00 for w3c-dist-auth@w3.org; Fri, 07 Mar 2003 20:01:32 +0000 Received: from ip-216-36-77-241.dsl.sjc.megapath.net ([216.36.77.241] helo=xythos.com) by mail.xythos.com with asmtp (Exim 3.36 #3) id 18rO28-0002Tp-00 for w3c-dist-auth@w3.org; Fri, 07 Mar 2003 20:01:32 +0000 Date: Fri, 7 Mar 2003 11:59:52 -0800 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) From: Brian Korver To: "'WebDAV'" Content-Transfer-Encoding: 7bit In-Reply-To: Message-Id: <5BF4D840-50D7-11D7-8A8F-000393751598@xythos.com> X-Mailer: Apple Mail (2.551) Old-X-Envelope-To: w3c-dist-auth@w3.org Subject: Re: GULP vs RFC2518bis X-Archived-At: http://www.w3.org/mid/5BF4D840-50D7-11D7-8A8F-000393751598@xythos.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7419 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit On Friday, March 7, 2003, at 06:23 AM, Julian Reschke wrote: > Hi. > > I'd really like to see some progress regarding this issue. In > > http://lists.w3.org/Archives/Public/w3c-dist-auth/2003JanMar/0281.html > > I have tried to rephrase GULP so that it doesn't require the term > "binding" > anymore. This should address the concerns of those who fear that a > dependency on the BIND spec is introduced. > > To those who did object to GULP being part of RFC2518bis *please* > review > this? > > Julian Julian, I plan to review GULP ASAP. -brian briank@xythos.com From w3c-dist-auth-request@w3.org Fri Mar 7 15:09:37 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26558 for ; Fri, 7 Mar 2003 15:09:37 -0500 (EST) Received: from frink.w3.org (localhost [127.0.0.1]) by frink.w3.org (8.12.8/8.12.8) with ESMTP id h27K66HB023922; Fri, 7 Mar 2003 15:06:06 -0500 (EST) Received: (from lists@localhost) by frink.w3.org (8.12.8/8.12.8/Submit) id h27K66ZO023909; Fri, 7 Mar 2003 15:06:06 -0500 (EST) Resent-Date: Fri, 7 Mar 2003 15:06:06 -0500 (EST) Resent-Message-Id: <200303072006.h27K66ZO023909@frink.w3.org> Received: from tux.w3.org (IDENT:root@tux [18.29.0.27]) by frink.w3.org (8.12.8/8.12.8) with ESMTP id h27K5LHB023671 for ; Fri, 7 Mar 2003 15:05:21 -0500 (EST) Received: from mail.xythos.com ([206.14.210.116]) by tux.w3.org (8.12.8/8.12.8) with ESMTP id h27K5LrB021860 for ; Fri, 7 Mar 2003 15:05:21 -0500 Received: from ravms by mail.xythos.com with mail-ok (Exim 3.36 #3) id 18rO7Q-0002b4-00 for w3c-dist-auth@w3.org; Fri, 07 Mar 2003 20:07:00 +0000 Received: from ip-216-36-77-241.dsl.sjc.megapath.net ([216.36.77.241] helo=xythos.com) by mail.xythos.com with asmtp (Exim 3.36 #3) id 18rO7Q-0002at-00 for w3c-dist-auth@w3.org; Fri, 07 Mar 2003 20:07:00 +0000 Date: Fri, 7 Mar 2003 12:05:19 -0800 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) From: Brian Korver To: WebDAV Content-Transfer-Encoding: 7bit In-Reply-To: Message-Id: <1F59FBEB-50D8-11D7-8A8F-000393751598@xythos.com> X-Mailer: Apple Mail (2.551) Old-X-Envelope-To: w3c-dist-auth@w3.org Subject: Re: bind draft issues X-Archived-At: http://www.w3.org/mid/1F59FBEB-50D8-11D7-8A8F-000393751598@xythos.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7420 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit On Friday, March 7, 2003, at 07:18 AM, Clemm, Geoff wrote: > Brian: > > These are the kinds of issues that led us to remove any discussion > of PROPFIND from the bindings draft. My conclusion is that our best > approach is to leave it up to 2518bis to define generically > how property values behave in the presence of multiple URL mappings > to the same resource (since that is base WebDAV functionality, not > something introduced by the binding spec), and the binding draft > will focus on the semantics it introduces (such as the DAV:resource-id > property, whose behavior in the presence of multiple URL mappings is > defined). > > The binding spec can then focus on the semantics that it is > introducing, > i.e. client creation of multiple URL mappings, the resource-id > property, > and atomic MOVE/DELETE via REBIND/UNBIND. > > Cheers, > Geoff Geoff, I doubt the consensus would be any easier to reach for text to go into 2518bis. The text has to go into at least one of the documents tho', so it's a good we're having this discussion. -brian briank@xythos.com From w3c-dist-auth-request@w3.org Fri Mar 7 15:14:17 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27070 for ; Fri, 7 Mar 2003 15:14:17 -0500 (EST) Received: from frink.w3.org (localhost [127.0.0.1]) by frink.w3.org (8.12.8/8.12.8) with ESMTP id h27KFnHB027964; Fri, 7 Mar 2003 15:15:49 -0500 (EST) Received: (from lists@localhost) by frink.w3.org (8.12.8/8.12.8/Submit) id h27KFiw7027855; Fri, 7 Mar 2003 15:15:44 -0500 (EST) Resent-Date: Fri, 7 Mar 2003 15:15:44 -0500 (EST) Resent-Message-Id: <200303072015.h27KFiw7027855@frink.w3.org> Received: from tux.w3.org (IDENT:root@tux [18.29.0.27]) by frink.w3.org (8.12.8/8.12.8) with ESMTP id h27KExHB027691 for ; Fri, 7 Mar 2003 15:14:59 -0500 (EST) Received: from mail.xythos.com ([206.14.210.116]) by tux.w3.org (8.12.8/8.12.8) with ESMTP id h27KEwrB026250 for ; Fri, 7 Mar 2003 15:14:59 -0500 Received: from ravms by mail.xythos.com with mail-ok (Exim 3.36 #3) id 18rOGk-0002o3-00 for w3c-dist-auth@w3.org; Fri, 07 Mar 2003 20:16:38 +0000 Received: from ip-216-36-77-241.dsl.sjc.megapath.net ([216.36.77.241] helo=xythos.com) by mail.xythos.com with asmtp (Exim 3.36 #3) id 18rOGj-0002nl-00 for w3c-dist-auth@w3.org; Fri, 07 Mar 2003 20:16:37 +0000 Date: Fri, 7 Mar 2003 12:14:57 -0800 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) From: Brian Korver To: "'WebDAV'" Content-Transfer-Encoding: 7bit In-Reply-To: Message-Id: <778524F0-50D9-11D7-8A8F-000393751598@xythos.com> X-Mailer: Apple Mail (2.551) Old-X-Envelope-To: w3c-dist-auth@w3.org Subject: Re: Move and Delete (was: bind draft issues) X-Archived-At: http://www.w3.org/mid/778524F0-50D9-11D7-8A8F-000393751598@xythos.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7421 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit On Friday, March 7, 2003, at 10:07 AM, Clemm, Geoff wrote: > My reading of the consensus of the working group (although certainly > not universal agreement) is that atomic behavior > on the part of the server is preferable when the server is capable of > doing so, especially when multiple bindings to a resource is possible. > But since some servers cannot guarantee atomic behavior, this > was made a "SHOULD" instead of a "MUST". Similarly, any server > implementors > that feel their clients want non-atomic behavior can present non-atomic > behavior and still be compatible with the spec (because it is a SHOULD, > not a MUST). > > In addition, I believe there was consensus that allowing the > client to explicitly request atomic behavior was desireable, and this > is achieved through the introduction of UNBIND/REBIND. > > Cheers, > Geoff Geoff, My reading of the consensus was that the atomic behavior should be a "MAY", not a "SHOULD" as you suggest, but I don't have religion on the issue. -brian briank@xythos.com From w3c-dist-auth-request@w3.org Fri Mar 7 15:14:25 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27102 for ; Fri, 7 Mar 2003 15:14:25 -0500 (EST) Received: from frink.w3.org (localhost [127.0.0.1]) by frink.w3.org (8.12.8/8.12.8) with ESMTP id h27KFmHB027957; Fri, 7 Mar 2003 15:15:48 -0500 (EST) Received: (from lists@localhost) by frink.w3.org (8.12.8/8.12.8/Submit) id h27KFlf7027919; Fri, 7 Mar 2003 15:15:47 -0500 (EST) Resent-Date: Fri, 7 Mar 2003 15:15:47 -0500 (EST) Resent-Message-Id: <200303072015.h27KFlf7027919@frink.w3.org> Received: from tux.w3.org (IDENT:root@tux [18.29.0.27]) by frink.w3.org (8.12.8/8.12.8) with ESMTP id h27KFKHB027794 for ; Fri, 7 Mar 2003 15:15:20 -0500 (EST) Received: from mail.gmx.net (mail.gmx.net [213.165.65.60]) by tux.w3.org (8.12.8/8.12.8) with SMTP id h27KFJrB026460 for ; Fri, 7 Mar 2003 15:15:20 -0500 Received: (qmail 22629 invoked by uid 0); 7 Mar 2003 20:15:09 -0000 Received: from p3EE2480B.dip.t-dialin.net (HELO lisa) (62.226.72.11) by mail.gmx.net (mp011-rz3) with SMTP; 7 Mar 2003 20:15:09 -0000 From: "Julian Reschke" To: "Brian Korver" , "WebDAV" Date: Fri, 7 Mar 2003 21:15:00 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 In-Reply-To: <2DE8374C-50D7-11D7-8A8F-000393751598@xythos.com> Importance: Normal Subject: RE: bind draft issues X-Archived-At: http://www.w3.org/mid/JIEGINCHMLABHJBIGKBCKEBLGLAA.julian.reschke@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7422 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Brian Korver > Sent: Friday, March 07, 2003 8:59 PM > To: WebDAV > Subject: Re: bind draft issues > > > > [snip] > > Probably a good guess of Geoff's intentions. Why not give a guess > > what an "URL property" exactly is? That would be most welcome. > > I think I gave that the other day: > > Perhaps "URL properties" isn't the right term, but what is? > In the face of bindings, "URL properties" are those properties > which are (potentially) effected by operations on bindings, where > "resource properties" are not effected by such operations. > > In other words, they are the class of properties whose values > (potentially) differ based on the URL specified in the PROPFIND > (when more than one binding exists to a resource). "URL properties" > isn't intended to imply that the property is stored with the > URL or anything else like that: it is merely descriptive of > behavior. > > As we discussed earlier, some implementations treat DAV:displayname > as just such a property. I'll comment based on my understanding of the URL-to-resource relationship in HTTP and WebDAV. The URL is an identifier for the resource, which allows the client to interact with the resource (in HTTP mainly by retrieving and manipulating representations of these resources). WebDAV has added collections and properties, but these do not really change the underlying model. When I submit a request to an HTTP server, it uses the request URL to locate an internal resource object. HTTP allows multiple URLs for the same resource. Once the object was located, the name (the request URL) becomes irrelevant -- the results of the interaction should be independant of the way the server located the resource. Using my favorite analogy (the Unix filesystem :-): path name and file name of a file are stored separately of the inode (which holds metadata and has a reference to content). Once a filesystem has located the internal file object, one only interacts with the resource and the filename becomes irrelevant. In particular, I can interact with an open file even though all bindings (hard links) pointing to it are already gone. Stefan has raised two issues: - properties that use relative URIs -- these may vary depending on the request URL, but the resource that is identified by the relativeURI will be the same, - variant handling -- based on the model described above I think this is a really really bad idea (anyone else?). Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Fri Mar 7 15:21:58 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27449 for ; Fri, 7 Mar 2003 15:21:58 -0500 (EST) Received: from frink.w3.org (localhost [127.0.0.1]) by frink.w3.org (8.12.8/8.12.8) with ESMTP id h27KNEHB000093; Fri, 7 Mar 2003 15:23:14 -0500 (EST) Received: (from lists@localhost) by frink.w3.org (8.12.8/8.12.8/Submit) id h27KNA1W000027; Fri, 7 Mar 2003 15:23:10 -0500 (EST) Resent-Date: Fri, 7 Mar 2003 15:23:10 -0500 (EST) Resent-Message-Id: <200303072023.h27KNA1W000027@frink.w3.org> Received: from tux.w3.org (IDENT:root@tux [18.29.0.27]) by frink.w3.org (8.12.8/8.12.8) with ESMTP id h27KMHHB029961 for ; Fri, 7 Mar 2003 15:22:17 -0500 (EST) Received: from mail.xythos.com ([206.14.210.116]) by tux.w3.org (8.12.8/8.12.8) with ESMTP id h27KMHrB029209 for ; Fri, 7 Mar 2003 15:22:17 -0500 Received: from ravms by mail.xythos.com with mail-ok (Exim 3.36 #3) id 18rONo-0002z7-00 for w3c-dist-auth@w3.org; Fri, 07 Mar 2003 20:23:56 +0000 Received: from ip-216-36-77-241.dsl.sjc.megapath.net ([216.36.77.241] helo=xythos.com) by mail.xythos.com with asmtp (Exim 3.36 #3) id 18rONo-0002yw-00 for w3c-dist-auth@w3.org; Fri, 07 Mar 2003 20:23:56 +0000 Date: Fri, 7 Mar 2003 12:22:14 -0800 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) From: Brian Korver To: "'WebDAV'" Content-Transfer-Encoding: 7bit In-Reply-To: Message-Id: <7C2F822B-50DA-11D7-8A8F-000393751598@xythos.com> X-Mailer: Apple Mail (2.551) Old-X-Envelope-To: w3c-dist-auth@w3.org Subject: Re: Move and Delete (was: bind draft issues) X-Archived-At: http://www.w3.org/mid/7C2F822B-50DA-11D7-8A8F-000393751598@xythos.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7423 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit On Friday, March 7, 2003, at 12:57 AM, Julian Reschke wrote: [snip] > Yes and no. I really think that there may be separate use case that > require > separate solutions. > > A client should be able to request a MOVE operation that will fail if > the > server can't support full MOVE semantics (for instance by changing the > DAV:resource-id property). A client would then be able to reconsider, > possibly issuing a COPY/DELETE sequence instead. > > Hopefully we can agree that this type of request should be supported. > If we > do, we're left with the alternatives of making this the standard > behaviour > for the RFC2518 MOVE, or to invent some new marshalling. I'd prefer the > former, but I probably could live with the latter. > > A similar problem obviously exists with the DELETE collection atomicity > issue. Julian, We are in agreement here. Even if a server is able (or desirable) to support atomic operations in some cases, there needs to be a way for these servers to communicate to clients when an atomic operation cannot be performed so that the client can retry using the non-atomic operation (if so desired). MOVEs across unix file systems are one example, but (as Jason pointed out to my off-line), so are cross-repository MOVEs in the case of cross-repository bindings. A client has no way to know beforehand whether a cross-repository MOVE will succeed, but may want to attempt one before performing a COPY/DELETE instead. -brian briank@xythos.com From w3c-dist-auth-request@w3.org Fri Mar 7 15:38:01 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29802 for ; Fri, 7 Mar 2003 15:37:46 -0500 (EST) Received: from frink.w3.org (localhost [127.0.0.1]) by frink.w3.org (8.12.8/8.12.8) with ESMTP id h27Kd1HB004435; Fri, 7 Mar 2003 15:39:01 -0500 (EST) Received: (from lists@localhost) by frink.w3.org (8.12.8/8.12.8/Submit) id h27Kcsbd004381; Fri, 7 Mar 2003 15:38:54 -0500 (EST) Resent-Date: Fri, 7 Mar 2003 15:38:54 -0500 (EST) Resent-Message-Id: <200303072038.h27Kcsbd004381@frink.w3.org> Received: from tux.w3.org (IDENT:root@tux [18.29.0.27]) by frink.w3.org (8.12.8/8.12.8) with ESMTP id h27Kc6HB004162 for ; Fri, 7 Mar 2003 15:38:06 -0500 (EST) Received: from mail.gmx.net (mail.gmx.net [213.165.65.60]) by tux.w3.org (8.12.8/8.12.8) with SMTP id h27Kc5rB002481 for ; Fri, 7 Mar 2003 15:38:05 -0500 Received: (qmail 26084 invoked by uid 0); 7 Mar 2003 20:37:55 -0000 Received: from p3EE2480B.dip.t-dialin.net (HELO lisa) (62.226.72.11) by mail.gmx.net (mp008-rz3) with SMTP; 7 Mar 2003 20:37:55 -0000 From: "Julian Reschke" To: "Brian Korver" , "'WebDAV'" Date: Fri, 7 Mar 2003 21:37:45 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 In-Reply-To: <778524F0-50D9-11D7-8A8F-000393751598@xythos.com> Importance: Normal Subject: RE: Move and Delete (was: bind draft issues) X-Archived-At: http://www.w3.org/mid/JIEGINCHMLABHJBIGKBCGEBNGLAA.julian.reschke@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7424 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Brian Korver > Sent: Friday, March 07, 2003 9:15 PM > To: 'WebDAV' > Subject: Re: Move and Delete (was: bind draft issues) > > ... > > Geoff, > > My reading of the consensus was that the atomic behavior should > be a "MAY", not a "SHOULD" as you suggest, but I don't have religion > on the issue. I think Brian is right here. SHOULD is really strong in RFC-speak, and if we really expect servers to show this behaviour, ir probably needs to be specified as "MAY". Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Fri Mar 7 16:05:00 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03221 for ; Fri, 7 Mar 2003 16:04:59 -0500 (EST) Received: from frink.w3.org (localhost [127.0.0.1]) by frink.w3.org (8.12.8/8.12.8) with ESMTP id h27L6BHB010801; Fri, 7 Mar 2003 16:06:11 -0500 (EST) Received: (from lists@localhost) by frink.w3.org (8.12.8/8.12.8/Submit) id h27L68xK010765; Fri, 7 Mar 2003 16:06:08 -0500 (EST) Resent-Date: Fri, 7 Mar 2003 16:06:08 -0500 (EST) Resent-Message-Id: <200303072106.h27L68xK010765@frink.w3.org> Received: from tux.w3.org (IDENT:root@tux [18.29.0.27]) by frink.w3.org (8.12.8/8.12.8) with ESMTP id h27L5HHB010715 for ; Fri, 7 Mar 2003 16:05:17 -0500 (EST) Received: from sunbelt.seagull.net (user34.net540.or.sprint-hsd.net [65.40.225.34]) by tux.w3.org (8.12.8/8.12.8) with ESMTP id h27L5GrB011409 for ; Fri, 7 Mar 2003 16:05:17 -0500 Received: (mail@localhost) by sunbelt.seagull.net (8.9.3) id NAA22907 sender nn683849@smallcue.com for w3c-dist-auth@w3.org; Fri, 7 Mar 2003 13:05:15 -0800 Received: from e5.ny.us.ibm.com (e5.ny.us.ibm.com [32.97.182.105]) by sunbelt.seagull.net (8.9.3) with ESMTP id NAA22877 sender obsfucated@us.ibm.com; Fri, 7 Mar 2003 13:05:13 -0800 Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.56.224.150]) by e5.ny.us.ibm.com (8.12.8/8.12.2) with ESMTP id h27L4clO039124; Fri, 7 Mar 2003 16:04:38 -0500 Received: from d01ml243.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by northrelay02.pok.ibm.com (8.12.8/NCO/VER6.5) with ESMTP id h27L4Yoe163488; Fri, 7 Mar 2003 16:04:35 -0500 To: Elias Cc: Julian Reschke , Stefan Eissing , "'WebDAV'" X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: Jason Crawford Date: Fri, 7 Mar 2003 16:03:00 -0500 X-MIMETrack: Serialize by Router on D01ML243/01/M/IBM(Release 6.0.1 [IBM]|March 6, 2003) at 03/07/2003 16:04:35 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Subject: Re: GULP vs RFC2518bis X-Archived-At: http://www.w3.org/mid/OFD82A362F.0DCAA5AA-ON85256CE2.007365C4@us.ibm.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7425 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: I also support the inclusion of GULP in 2518bis. The copy I read was the copy that still included the term bindings a few times, but it didn't seem to be a problem as I read it. But if folks can remove those without impacting the document, that's also fine by me. ------------------------------------------ Phone: 914-784-7569, ccjason@us.ibm.com I do not check nn621779@smallcue.com From w3c-dist-auth-request@w3.org Fri Mar 7 19:30:26 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA18801 for ; Fri, 7 Mar 2003 19:30:26 -0500 (EST) Received: from frink.w3.org (localhost [127.0.0.1]) by frink.w3.org (8.12.8/8.12.8) with ESMTP id h280PR9C019723; Fri, 7 Mar 2003 19:25:27 -0500 (EST) Received: (from lists@localhost) by frink.w3.org (8.12.8/8.12.8/Submit) id h280PNhq019667; Fri, 7 Mar 2003 19:25:23 -0500 (EST) Resent-Date: Fri, 7 Mar 2003 19:25:23 -0500 (EST) Resent-Message-Id: <200303080025.h280PNhq019667@frink.w3.org> Received: from tux.w3.org (IDENT:root@tux [18.29.0.27]) by frink.w3.org (8.12.8/8.12.8) with ESMTP id h280PL9C019635 for ; Fri, 7 Mar 2003 19:25:21 -0500 (EST) Received: from mac.wakasoft.com (64-60-92-50.cust.telepacific.net [64.60.92.50]) by tux.w3.org (8.12.8/8.12.8) with ESMTP id h280PHrB022286 for ; Fri, 7 Mar 2003 19:25:20 -0500 Received: from apache.org (localhost [127.0.0.1]) by mac.wakasoft.com (8.12.6/8.12.2) with ESMTP id h280Qo6g001031; Fri, 7 Mar 2003 16:26:50 -0800 (PST) Date: Fri, 7 Mar 2003 16:26:49 -0800 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: "Brian Korver" , "WebDAV" To: "Julian Reschke" From: "Roy T. Fielding" In-Reply-To: Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) Subject: Re: bind draft issues X-Archived-At: http://www.w3.org/mid/A706075A-50FC-11D7-932C-000393753936@apache.org Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7430 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit > The URL is an identifier for the resource, which allows the client to > interact with the resource (in HTTP mainly by retrieving and > manipulating > representations of these resources). WebDAV has added collections and > properties, but these do not really change the underlying model. > > When I submit a request to an HTTP server, it uses the request URL to > locate > an internal resource object. HTTP allows multiple URLs for the same > resource. Once the object was located, the name (the request URL) > becomes > irrelevant -- the results of the interaction should be independant of > the > way the server located the resource. It uses the request URI to locate an implementation object. Neither is the HTTP resource. The name is always relevant in this process, even after the implementation object is found, because the implementation will use the name to determine which representation should be returned in response to a GET. Each representation has its own set of properties. It is therefore false to say that two bindings to the same WebDAV resource will have the same properties because WebDAV defines the resource to be the implementation object (unlike HTTP). WebDAV doesn't understand server-side content negotiation because it doesn't deal with negotiated URIs. The bindings spec has no choice but to understand it, since that is the primary reason to have bindings (as opposed to redirects). In order to make sense of bindings it is necessary to return to the proper definition of resource and representations, wherein it never makes sense to say that the binding attaches to a resource, because the binding is part of what defines the HTTP resource (the mapping function). > Using my favorite analogy (the Unix filesystem :-) The Web is not a distributed filesystem. Resources are not files. Why use broken analogies to explain a process which is self-evident in almost all general-purpose HTTP origin servers? Just use what has already been implemented. ....Roy From w3c-dist-auth-request@w3.org Fri Mar 7 19:44:26 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA20452 for ; Fri, 7 Mar 2003 19:44:26 -0500 (EST) Received: from frink.w3.org (localhost [127.0.0.1]) by frink.w3.org (8.12.8/8.12.8) with ESMTP id h280d3Oa022244; Fri, 7 Mar 2003 19:46:06 -0500 (EST) Received: (from lists@localhost) by frink.w3.org (8.12.8/8.12.8/Submit) id h280E0MD009324; Fri, 7 Mar 2003 19:14:00 -0500 (EST) Resent-Date: Fri, 7 Mar 2003 19:14:00 -0500 (EST) Resent-Message-Id: <200303080014.h280E0MD009324@frink.w3.org> Received: from tux.w3.org (IDENT:root@tux [18.29.0.27]) by frink.w3.org (8.12.8/8.12.8) with ESMTP id h280A5L8000508 for ; Fri, 7 Mar 2003 19:13:27 -0500 (EST) Received: from mail.xythos.com ([206.14.210.116]) by tux.w3.org (8.12.8/8.12.8) with ESMTP id h27LbBrB020983 for ; Fri, 7 Mar 2003 16:37:11 -0500 Received: from ravms by mail.xythos.com with mail-ok (Exim 3.36 #3) id 18rPYJ-0004aA-00; Fri, 07 Mar 2003 21:38:51 +0000 Received: from [216.36.77.241] (helo=xythoslap) by mail.xythos.com with asmtp (Exim 3.36 #3) id 18rPYJ-0004Zz-00; Fri, 07 Mar 2003 21:38:51 +0000 From: "Lisa Dusseault" To: "'Julian Reschke'" , "'Jason Crawford'" Cc: "'Clemm, Geoff'" , "'WebDAV'" Date: Fri, 7 Mar 2003 13:37:05 -0800 Message-ID: <04e401c2e4f1$b4d0f6c0$bb01a8c0@xythoslap> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4024 Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Old-X-Envelope-To: gclemm@Rational.Com, julian.reschke@gmx.de, nn683849@smallcue.com, w3c-dist-auth@w3.org Subject: RE: Move and Delete (was: bind draft issues) X-Archived-At: http://www.w3.org/mid/04e401c2e4f1$b4d0f6c0$bb01a8c0@xythoslap Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7429 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit > A MOVE is a simple namespace operation. All it needs to do is > check locks. > > A DELETE that cleans up in the foreground will need to check delete > privileges on all descendants. This set can be very huge. I > think it's an > extremely bad idea to do this in a single transaction (yes, we tried). > Actually, collection MOVE suffers from the same problems as collection DELETE. Here are some of them. - You can't MOVE a file you don't have permission to write. Therefore, the server must check write privileges on all descendants. - A WebDAV application server may be used to unify a number of back-end storage servers under the same namespace. So the server's URL http://www.example.com/software/ may contain files stored on //davfiles/software, whereas the server's URL http://www.example.com/userdocs/ may contain files stored on //davfiles/userdocs. A server moving a collection from one of these top-level-directories to the other would have to do a network cross-repository move under the covers. This may not be feasible to do atomically. Lisa From w3c-dist-auth-request@w3.org Fri Mar 7 19:44:28 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA20467 for ; Fri, 7 Mar 2003 19:44:28 -0500 (EST) Received: from frink.w3.org (localhost [127.0.0.1]) by frink.w3.org (8.12.8/8.12.8) with ESMTP id h280d3Oc022244; Fri, 7 Mar 2003 19:46:07 -0500 (EST) Received: (from lists@localhost) by frink.w3.org (8.12.8/8.12.8/Submit) id h280Ds3a009056; Fri, 7 Mar 2003 19:13:54 -0500 (EST) Resent-Date: Fri, 7 Mar 2003 19:13:54 -0500 (EST) Resent-Message-Id: <200303080013.h280Ds3a009056@frink.w3.org> Received: from tux.w3.org (IDENT:root@tux [18.29.0.27]) by frink.w3.org (8.12.8/8.12.8) with ESMTP id h280A5L4000508 for ; Fri, 7 Mar 2003 19:13:26 -0500 (EST) Received: from mail.xythos.com ([206.14.210.116]) by tux.w3.org (8.12.8/8.12.8) with ESMTP id h27LUjrB019823 for ; Fri, 7 Mar 2003 16:30:45 -0500 Received: from ravms by mail.xythos.com with mail-ok (Exim 3.36 #3) id 18rPS4-0004Rm-00; Fri, 07 Mar 2003 21:32:24 +0000 Received: from [216.36.77.241] (helo=xythoslap) by mail.xythos.com with asmtp (Exim 3.36 #3) id 18rPS3-0004Rb-00; Fri, 07 Mar 2003 21:32:24 +0000 From: "Lisa Dusseault" To: "'Jason Crawford'" , "'Julian Reschke'" Cc: "'Clemm, Geoff'" , "'WebDAV'" Date: Fri, 7 Mar 2003 13:30:41 -0800 Message-ID: <049601c2e4f0$ce4927e0$bb01a8c0@xythoslap> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4024 Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Old-X-Envelope-To: gclemm@Rational.Com, julian.reschke@gmx.de, nn683849@smallcue.com, w3c-dist-auth@w3.org Subject: RE: Move and Delete (was: bind draft issues) X-Archived-At: http://www.w3.org/mid/049601c2e4f0$ce4927e0$bb01a8c0@xythoslap Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7428 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit > > > Anyway, the main issue for us is that we absolutely can not > change the > > DELETE collection semantics (from what we have in RFC2518). > > Sure you can. The behavior the spec outlines is compliant with 2518. > It does not break 2518 compliant clients. But it does require that > server writers do some coding before they can claim to support > this new feature. > Well, yes, one can change the required behavior from 2518 to 2518bis. However, we don't want to do that unless there are existing interoperability problems. I don't think changing the model so that some servers have difficulty being compliant with the new model is a good idea for 2518bis. Lisa From w3c-dist-auth-request@w3.org Fri Mar 7 19:44:35 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA20482 for ; Fri, 7 Mar 2003 19:44:30 -0500 (EST) Received: from frink.w3.org (localhost [127.0.0.1]) by frink.w3.org (8.12.8/8.12.8) with ESMTP id h280d3OY022244; Fri, 7 Mar 2003 19:46:06 -0500 (EST) Received: (from lists@localhost) by frink.w3.org (8.12.8/8.12.8/Submit) id h280Amck002352; Fri, 7 Mar 2003 19:10:48 -0500 (EST) Resent-Date: Fri, 7 Mar 2003 19:10:48 -0500 (EST) Resent-Message-Id: <200303080010.h280Amck002352@frink.w3.org> Received: from tux.w3.org (IDENT:root@tux [18.29.0.27]) by frink.w3.org (8.12.8/8.12.8) with ESMTP id h280A5BI000508 for ; Fri, 7 Mar 2003 19:10:32 -0500 (EST) Received: from sus-ma1it31.rational.com (sus-ma1it31.rational.com [130.213.73.33]) by tux.w3.org (8.12.8/8.12.8) with ESMTP id h27NYNrB012565 for ; Fri, 7 Mar 2003 18:34:23 -0500 Received: from sus-ma1it00.rational.com ([10.64.1.25]) by 10.64.1.33 with InterScan Messaging Security Suite; Fri, 07 Mar 2003 18:18:05 -0500 Received: by sus-ma1it00.rational.com with Internet Mail Service (5.5.2656.59) id ; Fri, 7 Mar 2003 18:34:17 -0500 Message-ID: From: "Clemm, Geoff" To: "'WebDAV'" Date: Fri, 7 Mar 2003 18:34:16 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain Subject: RE: Move and Delete (was: bind draft issues) X-Archived-At: http://www.w3.org/mid/E4F2D33B98DF7E4880884B9F0E6FDEE25ED6F2@SUS-MA1IT01 Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7426 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: I still vote for "SHOULD". In particular, given the problems partial DELETE and partial MOVE can produce in a multiple binding context, a server that supports multiple bindings to a resource SHOULD do those operations atomically unless it has a very good reason to do otherwise (e.g. the scenario I posted earlier). Cheers, Geoff -----Original Message----- From: Julian Reschke [mailto:julian.reschke@gmx.de] Sent: Friday, March 07, 2003 3:38 PM To: Brian Korver; 'WebDAV' Subject: RE: Move and Delete (was: bind draft issues) > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Brian Korver > Sent: Friday, March 07, 2003 9:15 PM > To: 'WebDAV' > Subject: Re: Move and Delete (was: bind draft issues) > > ... > > Geoff, > > My reading of the consensus was that the atomic behavior should > be a "MAY", not a "SHOULD" as you suggest, but I don't have religion > on the issue. I think Brian is right here. SHOULD is really strong in RFC-speak, and if we really expect servers to show this behaviour, ir probably needs to be specified as "MAY". Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Fri Mar 7 19:44:51 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA20497 for ; Fri, 7 Mar 2003 19:44:51 -0500 (EST) Received: from frink.w3.org (localhost [127.0.0.1]) by frink.w3.org (8.12.8/8.12.8) with ESMTP id h280d3OW022244; Fri, 7 Mar 2003 19:46:06 -0500 (EST) Received: (from lists@localhost) by frink.w3.org (8.12.8/8.12.8/Submit) id h280DffX008824; Fri, 7 Mar 2003 19:13:41 -0500 (EST) Resent-Date: Fri, 7 Mar 2003 19:13:41 -0500 (EST) Resent-Message-Id: <200303080013.h280DffX008824@frink.w3.org> Received: from tux.w3.org (IDENT:root@tux [18.29.0.27]) by frink.w3.org (8.12.8/8.12.8) with ESMTP id h280A5L6000508 for ; Fri, 7 Mar 2003 19:13:27 -0500 (EST) Received: from sus-ma1it31.rational.com (sus-ma1it31.rational.com [130.213.73.33]) by tux.w3.org (8.12.8/8.12.8) with ESMTP id h27LLprB017250 for ; Fri, 7 Mar 2003 16:21:52 -0500 Received: from sus-ma1it00.rational.com ([10.64.1.25]) by 10.64.1.33 with InterScan Messaging Security Suite; Fri, 07 Mar 2003 16:05:31 -0500 Received: by sus-ma1it00.rational.com with Internet Mail Service (5.5.2656.59) id ; Fri, 7 Mar 2003 16:21:43 -0500 Message-ID: From: "Clemm, Geoff" To: "'WebDAV'" Date: Fri, 7 Mar 2003 16:21:41 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain Subject: RE: GULP vs RFC2518bis X-Archived-At: http://www.w3.org/mid/E4F2D33B98DF7E4880884B9F0E6FDEE25ED6EE@SUS-MA1IT01 Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7427 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Just to explicitly vote on this thread, I also support the inclusion of GULP in 2518bis (I'm sure this comes as no surprise to anyone :-). I think the text is simplest if we clearly define bindings in terms of existing 2518 concepts (as Julian did in his referenced message), and then use the term binding where appropriate in the GULP text (and anywhere else in the body of 2518bis where it would simplify the language). Once we actually insert the text into 2518bis, it probably will be clearer in context what terminology is simpler. Cheers, Geoff -----Original Message----- From: Jason Crawford [mailto:nn683849@smallcue.com] Sent: Friday, March 07, 2003 4:03 PM To: Elias Cc: Julian Reschke; Stefan Eissing; 'WebDAV' Subject: Re: GULP vs RFC2518bis I also support the inclusion of GULP in 2518bis. The copy I read was the copy that still included the term bindings a few times, but it didn't seem to be a problem as I read it. But if folks can remove those without impacting the document, that's also fine by me. ------------------------------------------ Phone: 914-784-7569, ccjason@us.ibm.com I do not check nn621779@smallcue.com From w3c-dist-auth-request@w3.org Fri Mar 7 19:52:22 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA21119 for ; Fri, 7 Mar 2003 19:52:21 -0500 (EST) Received: from frink.w3.org (localhost [127.0.0.1]) by frink.w3.org (8.12.8/8.12.8) with ESMTP id h280rf9C001147; Fri, 7 Mar 2003 19:53:41 -0500 (EST) Received: (from lists@localhost) by frink.w3.org (8.12.8/8.12.8/Submit) id h280reWU001139; Fri, 7 Mar 2003 19:53:40 -0500 (EST) Resent-Date: Fri, 7 Mar 2003 19:53:40 -0500 (EST) Resent-Message-Id: <200303080053.h280reWU001139@frink.w3.org> Received: from tux.w3.org (IDENT:root@tux [18.29.0.27]) by frink.w3.org (8.12.8/8.12.8) with ESMTP id h280rd9C001107 for ; Fri, 7 Mar 2003 19:53:39 -0500 (EST) Received: from mail.xythos.com ([206.14.210.116]) by tux.w3.org (8.12.8/8.12.8) with ESMTP id h280rcrB031573 for ; Fri, 7 Mar 2003 19:53:38 -0500 Received: from ravms by mail.xythos.com with mail-ok (Exim 3.36 #3) id 18rScS-000069-00 for w3c-dist-auth@w3.org; Sat, 08 Mar 2003 00:55:20 +0000 Received: from ip-216-36-77-241.dsl.sjc.megapath.net ([216.36.77.241] helo=xythos.com) by mail.xythos.com with asmtp (Exim 3.36 #3) id 18rScS-00005y-00 for w3c-dist-auth@w3.org; Sat, 08 Mar 2003 00:55:20 +0000 Date: Fri, 7 Mar 2003 16:53:37 -0800 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) From: Brian Korver To: "'WebDAV'" Content-Transfer-Encoding: 7bit In-Reply-To: Message-Id: <657536D9-5100-11D7-9669-000393751598@xythos.com> X-Mailer: Apple Mail (2.551) Old-X-Envelope-To: w3c-dist-auth@w3.org Subject: Re: Move and Delete (was: bind draft issues) X-Archived-At: http://www.w3.org/mid/657536D9-5100-11D7-9669-000393751598@xythos.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7431 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit On Friday, March 7, 2003, at 03:34 PM, Clemm, Geoff wrote: > > I still vote for "SHOULD". In particular, given the problems > partial DELETE and partial MOVE can produce in a multiple binding > context, a server that supports multiple bindings to a resource > SHOULD do those operations atomically unless it > has a very good reason to do otherwise (e.g. the scenario I > posted earlier). > > Cheers, > Geoff > Geoff, Other than loops, what are the problems unique to multiple bindings and partial MOVE? -brian briank@xythos.com From w3c-dist-auth-request@w3.org Fri Mar 7 20:34:12 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA26021 for ; Fri, 7 Mar 2003 20:34:12 -0500 (EST) Received: from frink.w3.org (localhost [127.0.0.1]) by frink.w3.org (8.12.8/8.12.8) with ESMTP id h281SI9C008188; Fri, 7 Mar 2003 20:28:18 -0500 (EST) Received: (from lists@localhost) by frink.w3.org (8.12.8/8.12.8/Submit) id h281SB79008161; Fri, 7 Mar 2003 20:28:11 -0500 (EST) Resent-Date: Fri, 7 Mar 2003 20:28:11 -0500 (EST) Resent-Message-Id: <200303080128.h281SB79008161@frink.w3.org> Received: from tux.w3.org (IDENT:root@tux [18.29.0.27]) by frink.w3.org (8.12.8/8.12.8) with ESMTP id h281S89C008125 for ; Fri, 7 Mar 2003 20:28:08 -0500 (EST) Received: from sunbelt.seagull.net (user34.net540.or.sprint-hsd.net [65.40.225.34]) by tux.w3.org (8.12.8/8.12.8) with ESMTP id h281S7rB005952 for ; Fri, 7 Mar 2003 20:28:08 -0500 Received: (mail@localhost) by sunbelt.seagull.net (8.9.3) id RAA09720 sender nn683849@smallcue.com for w3c-dist-auth@w3.org; Fri, 7 Mar 2003 17:28:06 -0800 Received: from e6.ny.us.ibm.com (e6.ny.us.ibm.com [32.97.182.106]) by sunbelt.seagull.net (8.9.3) with ESMTP id RAA09703 sender obsfucated@us.ibm.com; Fri, 7 Mar 2003 17:28:04 -0800 Received: from northrelay04.pok.ibm.com (northrelay04.pok.ibm.com [9.56.224.206]) by e6.ny.us.ibm.com (8.12.8/8.12.2) with ESMTP id h281RTZu033240; Fri, 7 Mar 2003 20:27:29 -0500 Received: from d01ml243.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by northrelay04.pok.ibm.com (8.12.8/NCO/VER6.5) with ESMTP id h281RPPL104374; Fri, 7 Mar 2003 20:27:26 -0500 To: "Clemm, Geoff" Cc: "'WebDAV'" X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: Jason Crawford Date: Fri, 7 Mar 2003 20:25:33 -0500 X-MIMETrack: Serialize by Router on D01ML243/01/M/IBM(Release 6.0.1 [IBM]|March 6, 2003) at 03/07/2003 20:27:25 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Subject: RE: Move and Delete (was: bind draft issues) X-Archived-At: http://www.w3.org/mid/OFC3798CA1.9493D9A5-ON85256CE3.0007CA4F@us.ibm.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7432 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: On Friday, 03/07/2003 at 06:34 EST, "Clemm, Geoff" wrote: > I still vote for "SHOULD". In particular, given the problems > partial DELETE and partial MOVE can produce in a multiple binding > context, a server that supports multiple bindings to a resource > SHOULD do those operations atomically unless it > has a very good reason to do otherwise (e.g. the scenario I > posted earlier). I agree. From w3c-dist-auth-request@w3.org Fri Mar 7 20:39:30 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA26838 for ; Fri, 7 Mar 2003 20:39:30 -0500 (EST) Received: from frink.w3.org (localhost [127.0.0.1]) by frink.w3.org (8.12.8/8.12.8) with ESMTP id h281XS9C008865; Fri, 7 Mar 2003 20:33:28 -0500 (EST) Received: (from lists@localhost) by frink.w3.org (8.12.8/8.12.8/Submit) id h281XS8H008859; Fri, 7 Mar 2003 20:33:28 -0500 (EST) Resent-Date: Fri, 7 Mar 2003 20:33:28 -0500 (EST) Resent-Message-Id: <200303080133.h281XS8H008859@frink.w3.org> Received: from tux.w3.org (IDENT:root@tux [18.29.0.27]) by frink.w3.org (8.12.8/8.12.8) with ESMTP id h281XP9C008827 for ; Fri, 7 Mar 2003 20:33:25 -0500 (EST) Received: from sunbelt.seagull.net (user34.net540.or.sprint-hsd.net [65.40.225.34]) by tux.w3.org (8.12.8/8.12.8) with ESMTP id h281XNrB006700 for ; Fri, 7 Mar 2003 20:33:24 -0500 Received: (mail@localhost) by sunbelt.seagull.net (8.9.3) id RAA09991 sender nn683849@smallcue.com for w3c-dist-auth@w3.org; Fri, 7 Mar 2003 17:33:23 -0800 Received: from e5.ny.us.ibm.com (e5.ny.us.ibm.com [32.97.182.105]) by sunbelt.seagull.net (8.9.3) with ESMTP id RAA09961 sender obsfucated@us.ibm.com; Fri, 7 Mar 2003 17:33:21 -0800 Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.56.224.150]) by e5.ny.us.ibm.com (8.12.8/8.12.2) with ESMTP id h281WolO051444; Fri, 7 Mar 2003 20:32:50 -0500 Received: from d01ml243.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by northrelay02.pok.ibm.com (8.12.8/NCO/VER6.5) with ESMTP id h281Wkoe055308; Fri, 7 Mar 2003 20:32:47 -0500 To: "Lisa Dusseault" Cc: "'Clemm, Geoff'" , "'Julian Reschke'" , "'WebDAV'" X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: Jason Crawford Date: Fri, 7 Mar 2003 20:28:38 -0500 X-MIMETrack: Serialize by Router on D01ML243/01/M/IBM(Release 6.0.1 [IBM]|March 6, 2003) at 03/07/2003 20:32:46 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Subject: RE: Move and Delete (was: bind draft issues) X-Archived-At: http://www.w3.org/mid/OFAC6EC97F.3F333061-ON85256CE3.0007F4CE@us.ibm.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7433 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: On Friday, 03/07/2003 at 01:30 PST, "Lisa Dusseault" wrote: > > > > > Anyway, the main issue for us is that we absolutely can not > > change the > > > DELETE collection semantics (from what we have in RFC2518). > > > > Sure you can. The behavior the spec outlines is compliant with 2518. > > It does not break 2518 compliant clients. But it does require that > > server writers do some coding before they can claim to support > > this new feature. > > > > Well, yes, one can change the required behavior from 2518 to 2518bis. > However, we don't want to do that unless there are existing > interoperability problems. I don't think changing the model so that > some servers have difficulty being compliant with the new model is a > good idea for 2518bis. They'd still be compliant. SHOULD is not MUST ------------------------------------------ Phone: 914-784-7569, ccjason@us.ibm.com I do not check nn621779@smallcue.com From w3c-dist-auth-request@w3.org Fri Mar 7 21:07:05 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA01361 for ; Fri, 7 Mar 2003 21:07:05 -0500 (EST) Received: from frink.w3.org (localhost [127.0.0.1]) by frink.w3.org (8.12.8/8.12.8) with ESMTP id h2828k9C014429; Fri, 7 Mar 2003 21:08:46 -0500 (EST) Received: (from lists@localhost) by frink.w3.org (8.12.8/8.12.8/Submit) id h2828iDk014417; Fri, 7 Mar 2003 21:08:44 -0500 (EST) Resent-Date: Fri, 7 Mar 2003 21:08:44 -0500 (EST) Resent-Message-Id: <200303080208.h2828iDk014417@frink.w3.org> Received: from tux.w3.org (IDENT:root@tux [18.29.0.27]) by frink.w3.org (8.12.8/8.12.8) with ESMTP id h2828c9C014307 for ; Fri, 7 Mar 2003 21:08:38 -0500 (EST) Received: from sus-ma1it31.rational.com (sus-ma1it31.rational.com [130.213.73.33]) by tux.w3.org (8.12.8/8.12.8) with ESMTP id h2828crB012269 for ; Fri, 7 Mar 2003 21:08:38 -0500 Received: from sus-ma1it00.rational.com ([10.64.1.25]) by 10.64.1.33 with InterScan Messaging Security Suite; Fri, 07 Mar 2003 20:52:19 -0500 Received: by sus-ma1it00.rational.com with Internet Mail Service (5.5.2656.59) id ; Fri, 7 Mar 2003 21:08:32 -0500 Message-ID: From: "Clemm, Geoff" To: "'WebDAV'" Date: Fri, 7 Mar 2003 21:08:31 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain Subject: RE: Move and Delete (was: bind draft issues) X-Archived-At: http://www.w3.org/mid/E4F2D33B98DF7E4880884B9F0E6FDEE2021C5EBA@SUS-MA1IT01 Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7434 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: From: Brian Korver [mailto:briank@xythos.com] Other than loops, what are the problems unique to multiple bindings and partial MOVE? One example was posted in the message below: From: Clemm, Geoff [gclemm@Rational.Com] Sent: Monday, March 03, 2003 6:34 PM Subject: RE: Move and Delete (was: bind draft issues) ... because it can cause a DELETE in one collection to cause a change in another collection, and this kind of "deletion side effect" was something we explicitly were trying to avoid. For example, suppose /henry/has-friend/jeff and /jim/has-friend/jeff were bindings to the same collection, JEFF, and JEFF has a binding named "wife" to a resource, MARI. Now suppose henry gets mad at jeff, and issues a "DELETE /henry/has-friend/jeff" request. But suppose at that moment someone else has a Depth:0 lock on the /henry/has-friend collection. The result of a "best effort" deletion is the removal of the "wife" binding from JEFF. That may be OK if you were just updating the information accessible from /henry (he isn't JEFF's friend anymore, and he's happy to purge as much information about JEFF as he can), but with multiple bindings, "best effort" deletion has now trashed the JEFF object in all the other contexts in which it is still visible (and the folks that still are his friends are still interested in that information). So we're not saying that "best effort deletion" is always a bad thing, but we are saying that "best effort deletion" is a bad thing when you care about multiple bindings to the same resource. From w3c-dist-auth-request@w3.org Sat Mar 8 02:34:45 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA07498 for ; Sat, 8 Mar 2003 02:34:44 -0500 (EST) Received: from frink.w3.org (localhost [127.0.0.1]) by frink.w3.org (8.12.8/8.12.8) with ESMTP id h287ao9C025273; Sat, 8 Mar 2003 02:36:50 -0500 (EST) Received: (from lists@localhost) by frink.w3.org (8.12.8/8.12.8/Submit) id h287ZT4r025205; Sat, 8 Mar 2003 02:35:29 -0500 (EST) Resent-Date: Sat, 8 Mar 2003 02:35:29 -0500 (EST) Resent-Message-Id: <200303080735.h287ZT4r025205@frink.w3.org> Received: from tux.w3.org (IDENT:root@tux [18.29.0.27]) by frink.w3.org (8.12.8/8.12.8) with ESMTP id h287ZQ9C025173 for ; Sat, 8 Mar 2003 02:35:26 -0500 (EST) Received: from mail.gmx.net (mail.gmx.net [213.165.65.60]) by tux.w3.org (8.12.8/8.12.8) with SMTP id h287ZPrB024712 for ; Sat, 8 Mar 2003 02:35:26 -0500 Received: (qmail 23490 invoked by uid 0); 8 Mar 2003 07:35:19 -0000 Received: from pD950C246.dip.t-dialin.net (HELO lisa) (217.80.194.70) by mail.gmx.net (mp001-rz3) with SMTP; 08 Mar 2003 08:35:19 +0100 From: "Julian Reschke" To: "Clemm, Geoff" , "'WebDAV'" Date: Sat, 8 Mar 2003 08:35:13 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Subject: RE: Move and Delete (was: bind draft issues) X-Archived-At: http://www.w3.org/mid/JIEGINCHMLABHJBIGKBCIECNGLAA.julian.reschke@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7435 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Clemm, Geoff > Sent: Saturday, March 08, 2003 3:09 AM > To: 'WebDAV' > Subject: RE: Move and Delete (was: bind draft issues) > > > > From: Brian Korver [mailto:briank@xythos.com] > > Other than loops, what are the problems unique to multiple > bindings and partial MOVE? > > One example was posted in the message below: > > From: Clemm, Geoff [gclemm@Rational.Com] > Sent: Monday, March 03, 2003 6:34 PM > Subject: RE: Move and Delete (was: bind draft issues) > > ... > because it can cause a DELETE in one collection to cause a change > in another collection, and this kind of "deletion side effect" > was something we explicitly were trying to avoid. For example, > suppose /henry/has-friend/jeff and /jim/has-friend/jeff > were bindings to the same collection, JEFF, and JEFF has a binding > named "wife" to a resource, MARI. Now suppose henry gets mad > at jeff, and issues a "DELETE /henry/has-friend/jeff" request. > But suppose at that moment someone else has a Depth:0 lock > on the /henry/has-friend collection. The result of a "best effort" > deletion is the removal of the "wife" binding from JEFF. That > may be OK if you were just updating the information accessible > from /henry (he isn't JEFF's friend anymore, and he's happy to > purge as much information about JEFF as he can), but with multiple > bindings, "best effort" deletion has now trashed the JEFF object > in all the other contexts in which it is still visible (and the > folks that still are his friends are still interested in that > information). > > So we're not saying that "best effort deletion" is always a bad thing, > but we are saying that "best effort deletion" is a bad thing when > you care about multiple bindings to the same resource. Geoff, I don't think this issue exists if a server does UNBIND when removing one of multiple bindings and non-atomic-DELETE when removing the last binding (see [1]). [1] -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Sat Mar 8 02:40:08 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA08478 for ; Sat, 8 Mar 2003 02:40:07 -0500 (EST) Received: from frink.w3.org (localhost [127.0.0.1]) by frink.w3.org (8.12.8/8.12.8) with ESMTP id h287gD9C025809; Sat, 8 Mar 2003 02:42:13 -0500 (EST) Received: (from lists@localhost) by frink.w3.org (8.12.8/8.12.8/Submit) id h287f46C025655; Sat, 8 Mar 2003 02:41:04 -0500 (EST) Resent-Date: Sat, 8 Mar 2003 02:41:04 -0500 (EST) Resent-Message-Id: <200303080741.h287f46C025655@frink.w3.org> Received: from tux.w3.org (IDENT:root@tux [18.29.0.27]) by frink.w3.org (8.12.8/8.12.8) with ESMTP id h287f39C025623 for ; Sat, 8 Mar 2003 02:41:03 -0500 (EST) Received: from mail.gmx.net (mail.gmx.net [213.165.65.60]) by tux.w3.org (8.12.8/8.12.8) with SMTP id h287f2rB025357 for ; Sat, 8 Mar 2003 02:41:02 -0500 Received: (qmail 1995 invoked by uid 0); 8 Mar 2003 07:40:55 -0000 Received: from pD950C246.dip.t-dialin.net (HELO lisa) (217.80.194.70) by mail.gmx.net (mp008-rz3) with SMTP; 8 Mar 2003 07:40:55 -0000 From: "Julian Reschke" To: "Lisa Dusseault" , "'WebDAV'" Date: Sat, 8 Mar 2003 08:40:51 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) In-Reply-To: <04e401c2e4f1$b4d0f6c0$bb01a8c0@xythoslap> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Subject: RE: Move and Delete (was: bind draft issues) X-Archived-At: http://www.w3.org/mid/JIEGINCHMLABHJBIGKBCOECNGLAA.julian.reschke@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7436 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Lisa Dusseault > Sent: Friday, March 07, 2003 10:37 PM > To: 'Julian Reschke'; 'Jason Crawford' > Cc: 'Clemm, Geoff'; 'WebDAV' > Subject: RE: Move and Delete (was: bind draft issues) > > > > > > A MOVE is a simple namespace operation. All it needs to do is > > check locks. > > > > A DELETE that cleans up in the foreground will need to check delete > > privileges on all descendants. This set can be very huge. I > > think it's an > > extremely bad idea to do this in a single transaction (yes, we tried). > > > > Actually, collection MOVE suffers from the same problems as collection > DELETE. Here are some of them. > - You can't MOVE a file you don't have permission to write. Therefore, > the server must check write privileges on all descendants. I think I disagree. I *can* MOVE a resource without having write permissions to the resource itself. What I need is the write permission on source and targer collection (+ some more when overwriting something else). > - A WebDAV application server may be used to unify a number of back-end > storage servers under the same namespace. So the server's URL > http://www.example.com/software/ may contain files stored on > //davfiles/software, whereas the server's URL > http://www.example.com/userdocs/ may contain files stored on > //davfiles/userdocs. A server moving a collection from one of these Sure. > top-level-directories to the other would have to do a network > cross-repository move under the covers. This may not be feasible to do > atomically. Yes, that's why many people would prefer it to fail (leaving the client the choice to explicitly COPY/DELETE) rather than doing something the client din't really want. -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Sat Mar 8 02:41:26 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA08729 for ; Sat, 8 Mar 2003 02:41:25 -0500 (EST) Received: from frink.w3.org (localhost [127.0.0.1]) by frink.w3.org (8.12.8/8.12.8) with ESMTP id h287hV9C026134; Sat, 8 Mar 2003 02:43:31 -0500 (EST) Received: (from lists@localhost) by frink.w3.org (8.12.8/8.12.8/Submit) id h287gMPJ025844; Sat, 8 Mar 2003 02:42:22 -0500 (EST) Resent-Date: Sat, 8 Mar 2003 02:42:22 -0500 (EST) Resent-Message-Id: <200303080742.h287gMPJ025844@frink.w3.org> Received: from tux.w3.org (IDENT:root@tux [18.29.0.27]) by frink.w3.org (8.12.8/8.12.8) with ESMTP id h287gL9C025812 for ; Sat, 8 Mar 2003 02:42:21 -0500 (EST) Received: from mail.gmx.net (mail.gmx.net [213.165.65.60]) by tux.w3.org (8.12.8/8.12.8) with SMTP id h287gKrB025503 for ; Sat, 8 Mar 2003 02:42:21 -0500 Received: (qmail 6063 invoked by uid 0); 8 Mar 2003 07:42:14 -0000 Received: from pD950C246.dip.t-dialin.net (HELO lisa) (217.80.194.70) by mail.gmx.net (mp001-rz3) with SMTP; 08 Mar 2003 08:42:14 +0100 From: "Julian Reschke" To: "Clemm, Geoff" , "'WebDAV'" Date: Sat, 8 Mar 2003 08:42:07 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Subject: RE: Move and Delete (was: bind draft issues) X-Archived-At: http://www.w3.org/mid/JIEGINCHMLABHJBIGKBCCECOGLAA.julian.reschke@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7437 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit Geoff, I think we should get back to this issue once we do agree whether or not the problem you mentioned really exists (see separate thread). Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 > -----Original Message----- > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Clemm, Geoff > Sent: Saturday, March 08, 2003 12:34 AM > To: 'WebDAV' > Subject: RE: Move and Delete (was: bind draft issues) > > > > I still vote for "SHOULD". In particular, given the problems > partial DELETE and partial MOVE can produce in a multiple binding > context, a server that supports multiple bindings to a resource > SHOULD do those operations atomically unless it > has a very good reason to do otherwise (e.g. the scenario I > posted earlier). > > Cheers, > Geoff > > -----Original Message----- > From: Julian Reschke [mailto:julian.reschke@gmx.de] > Sent: Friday, March 07, 2003 3:38 PM > To: Brian Korver; 'WebDAV' > Subject: RE: Move and Delete (was: bind draft issues) > > > > > From: w3c-dist-auth-request@w3.org > > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Brian Korver > > Sent: Friday, March 07, 2003 9:15 PM > > To: 'WebDAV' > > Subject: Re: Move and Delete (was: bind draft issues) > > > > ... > > > > Geoff, > > > > My reading of the consensus was that the atomic behavior should > > be a "MAY", not a "SHOULD" as you suggest, but I don't have religion > > on the issue. > > I think Brian is right here. SHOULD is really strong in > RFC-speak, and if we > really expect servers to show this behaviour, ir probably needs to be > specified as "MAY". > > Julian > -- > bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 > From w3c-dist-auth-request@w3.org Sat Mar 8 03:28:43 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA15689 for ; Sat, 8 Mar 2003 03:28:42 -0500 (EST) Received: from frink.w3.org (localhost [127.0.0.1]) by frink.w3.org (8.12.8/8.12.8) with ESMTP id h288Um9C002321; Sat, 8 Mar 2003 03:30:48 -0500 (EST) Received: (from lists@localhost) by frink.w3.org (8.12.8/8.12.8/Submit) id h288Tc3w002092; Sat, 8 Mar 2003 03:29:38 -0500 (EST) Resent-Date: Sat, 8 Mar 2003 03:29:38 -0500 (EST) Resent-Message-Id: <200303080829.h288Tc3w002092@frink.w3.org> Received: from tux.w3.org (IDENT:root@tux [18.29.0.27]) by frink.w3.org (8.12.8/8.12.8) with ESMTP id h288TZ9C002020 for ; Sat, 8 Mar 2003 03:29:35 -0500 (EST) Received: from mail.gmx.net (mail.gmx.net [213.165.65.60]) by tux.w3.org (8.12.8/8.12.8) with SMTP id h288TYrB031371 for ; Sat, 8 Mar 2003 03:29:35 -0500 Received: (qmail 16348 invoked by uid 0); 8 Mar 2003 08:29:27 -0000 Received: from pD950C246.dip.t-dialin.net (HELO lisa) (217.80.194.70) by mail.gmx.net (mp005-rz3) with SMTP; 8 Mar 2003 08:29:27 -0000 From: "Julian Reschke" To: "Roy T. Fielding" , "Julian Reschke" Cc: "Brian Korver" , "WebDAV" Date: Sat, 8 Mar 2003 09:29:21 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Subject: RE: bind draft issues X-Archived-At: http://www.w3.org/mid/JIEGINCHMLABHJBIGKBCGECPGLAA.julian.reschke@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7438 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit Roy, it's good you're stepping in. We badly need to make progress on 1) the definition of "sameness" for resources (BIND spec vs RFC2616) 2) the relationship between variant handling and WebDAV Regarding 1): the BIND spec tries to define when two resources identified by distinct URLs are the same. BIND says that if they are the same they share the same DAV:resource-id property. In the absence of this WebDAV property, the only other hint I can think of is that modifications (PUT/PROPPATCH) applied to one of the URLs will affect the resource identified by the other URL as well. - Is this concept compatible with what RFC2616 describes as "A single resource MAY be identified by many different URIs." (section 9.6)? If this is the case, I don't really see how selecting a variant based on the request URL fits in. If I have /index-en.html and /index-de.html and model index-en.html and index-de.html as WebDAV bindings to the same resource and vary the GET content based on the URL the above assumption will *not* be true (because modifiying the content for /index-en.html will not affect /index-de.html, and thus both do *not* identify the same resource). BTW: what will happen if I MOVE /index-de.html to /index-en.html? Will the resource identified by the URL left behave like the english or the german variant? So it seems that we need a stronger definition of "sameness" to be able to clarify. Geoff, as RFC3253 relies on the concept of bindings, could you please attempt to fill in what *you* think an identical DAV:resource-id needs to indicate? Regarding 2): that's another interesting issue. RFC2518 says that the DAV:get* properties must reflect the value of their counterparts returned by a GET, minus "Accept headers". Accept headers are defined in RFC2616, section 14.1. As far as I can tell, "accept-language" (section 14.2) does not fall into this restriction. I'm not sure what the original intent of this restriction was (does anybody remember?). Fact is, it breaks the symmetry of PROPFIND and GET/HEAD, which I find confusing. To define proper variant handling for WebDAV we will have to - to clarify how WebDAV DAV:get* properties react to *all* request headers (may choice would be to say: just like GET and HEAD) - come up with some theory how properties that vary with the selected entitiy can be distinguished from those that don't (unless the previous issue is resolved in a way that says that PROPFIND responses may not vary, in which case we may need some new marshalling) - define whether dead properties apply to the resource itself or the selected variant (with the same caveat). Some more comments: > It uses the request URI to locate an implementation object. Neither is > the HTTP resource. The name is always relevant in this process, even after > the implementation object is found, because the implementation will use > the name to determine which representation should be returned in response > to a GET. Each representation has its own set of properties. It is > therefore false to say that two bindings to the same WebDAV resource will > have the same properties because WebDAV defines the resource to be the > implementation object (unlike HTTP). So then what *is* the definition of sameness in RFC2616? Is there any observable quality of two URLs (i.e., the responses when interacting with them) through which I can detect they identify the same resource? If there isn't, does the concept really exist? > WebDAV doesn't understand server-side content negotiation because it > doesn't deal with negotiated URIs. The bindings spec has no choice Well, my understanding was WebDAV *does* deal with it (see above). > but to understand it, since that is the primary reason to have bindings > (as opposed to redirects). In order to make sense of bindings it is I have the feeling that we don't have agreement for why we need the BIND spec. As far as I understand, server-side content negotiation never played a role here. It's interesting that we're getting into a discussion about variant handling based on open BIND questions. As I always felt that the relation between variant handling and WebDAV is underspecified, I guess that's a good thing. > necessary to return to the proper definition of resource and > representations, wherein it never makes sense to say that the binding > attaches to a resource, because the binding is part of what defines > the HTTP resource (the mapping function). So if the binding is part of what defines the HTTP resource, how can *ever* to bindings point to the "same" resource? Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Sat Mar 8 05:28:53 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA07406 for ; Sat, 8 Mar 2003 05:28:53 -0500 (EST) Received: from frink.w3.org (localhost [127.0.0.1]) by frink.w3.org (8.12.8/8.12.8) with ESMTP id h28AUl9C013323; Sat, 8 Mar 2003 05:30:47 -0500 (EST) Received: (from lists@localhost) by frink.w3.org (8.12.8/8.12.8/Submit) id h28ASVsE013072; Sat, 8 Mar 2003 05:28:31 -0500 (EST) Resent-Date: Sat, 8 Mar 2003 05:28:31 -0500 (EST) Resent-Message-Id: <200303081028.h28ASVsE013072@frink.w3.org> Received: from tux.w3.org (IDENT:root@tux [18.29.0.27]) by frink.w3.org (8.12.8/8.12.8) with ESMTP id h28ASS9C013021 for ; Sat, 8 Mar 2003 05:28:28 -0500 (EST) Received: from mail.gmx.net (mail.gmx.net [213.165.65.60]) by tux.w3.org (8.12.8/8.12.8) with SMTP id h28ASRrB011617 for ; Sat, 8 Mar 2003 05:28:27 -0500 Received: (qmail 29085 invoked by uid 0); 8 Mar 2003 10:28:26 -0000 Received: from pD950C246.dip.t-dialin.net (HELO lisa) (217.80.194.70) by mail.gmx.net (mp001-rz3) with SMTP; 08 Mar 2003 11:28:26 +0100 From: "Julian Reschke" To: "Lisa Dusseault" , "'WebDAV'" Date: Sat, 8 Mar 2003 11:28:19 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) In-Reply-To: <049601c2e4f0$ce4927e0$bb01a8c0@xythoslap> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Subject: RE: Move and Delete (was: bind draft issues) X-Archived-At: http://www.w3.org/mid/JIEGINCHMLABHJBIGKBCKEDBGLAA.julian.reschke@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7439 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit > From: Lisa Dusseault [mailto:lisa@xythos.com] > Sent: Friday, March 07, 2003 10:31 PM > To: 'Jason Crawford'; 'Julian Reschke' > Cc: 'Clemm, Geoff'; 'WebDAV' > Subject: RE: Move and Delete (was: bind draft issues) > > > > > > > > > Anyway, the main issue for us is that we absolutely can not change the > > > DELETE collection semantics (from what we have in RFC2518). > > > > Sure you can. The behavior the spec outlines is compliant with 2518. > > It does not break 2518 compliant clients. But it does require that > > server writers do some coding before they can claim to support > > this new feature. > > > > Well, yes, one can change the required behavior from 2518 to 2518bis. > However, we don't want to do that unless there are existing > interoperability problems. I don't think changing the model so that > some servers have difficulty being compliant with the new model is a > good idea for 2518bis. I think what Geoff is saying that the BIND spec *can* tighten RFC2518(bis) requirements. A server has the freedom not to claim BIND spec support, and then won't be affected (just like some people want to tighten RFC2616 requirements in RFC2518bis... :-) What is (or was) open to discussion whether servers may want to support - multiple bindings - BIND live properties - BIND MOVE semantics without supporting UNBIND semantics (or actually without supporting UNBIND semantics on the *last* binding to a collection). That's what we planned to do in our server, and I think this behaviour should be allowed. Making the "new" behaviour explicit in UNBIND/REBIND instead of DELETE/MOVE allows a server to support clients that are only RFC2518-aware as before, yet offers newer clients the ability to rely on the tightened semantics (or reliably get the request failed if the semantics cannot be offered). Coming back to the new methods: REBIND/MOVE: I think everybody agrees that it would be a good if new clients could request a resource MOVE that will leave all dead and live properties intact. If we can't put that into RFC2518-MOVE, we'll need a new way of marshall the request. Do we have consensus here? UNBIND/DELETE: I think there was some confusion here about why people did not like requiring DELETE to use UNBIND semantics. If a server *does* support multiple bindings, DELETEing one of many bindings indeed should only remove that binding, and thus be atomic (does anybody disagree here?). I only have an issue to require this particular semantics for the *last* binding to a collection (in which case I'd prefer to use the old RFC2518 DELETE semantics). Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Sat Mar 8 10:56:04 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10088 for ; Sat, 8 Mar 2003 10:56:04 -0500 (EST) Received: from frink.w3.org (localhost [127.0.0.1]) by frink.w3.org (8.12.8/8.12.8) with ESMTP id h28FvC9C028734; Sat, 8 Mar 2003 10:57:12 -0500 (EST) Received: (from lists@localhost) by frink.w3.org (8.12.8/8.12.8/Submit) id h28Fux4U028678; Sat, 8 Mar 2003 10:56:59 -0500 (EST) Resent-Date: Sat, 8 Mar 2003 10:56:59 -0500 (EST) Resent-Message-Id: <200303081556.h28Fux4U028678@frink.w3.org> Received: from tux.w3.org (IDENT:root@tux [18.29.0.27]) by frink.w3.org (8.12.8/8.12.8) with ESMTP id h28Fuv9C028646 for ; Sat, 8 Mar 2003 10:56:57 -0500 (EST) Received: from mail.xythos.com ([206.14.210.116]) by tux.w3.org (8.12.8/8.12.8) with ESMTP id h28FuurB025842 for ; Sat, 8 Mar 2003 10:56:57 -0500 Received: from ravms by mail.xythos.com with mail-ok (Exim 3.36 #3) id 18rgim-00036L-00; Sat, 08 Mar 2003 15:58:48 +0000 Received: from [198.144.203.248] (helo=xythoslap) by mail.xythos.com with asmtp (Exim 3.36 #3) id 18rgil-00035x-00; Sat, 08 Mar 2003 15:58:48 +0000 From: "Lisa Dusseault" To: "'Clemm, Geoff'" , "'WebDAV'" Date: Sat, 8 Mar 2003 07:56:54 -0800 Message-ID: <065301c2e58b$578787f0$bb01a8c0@xythoslap> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4024 Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Old-X-Envelope-To: gclemm@rational.com, w3c-dist-auth@w3.org Subject: RE: Move and Delete (was: bind draft issues) X-Archived-At: http://www.w3.org/mid/065301c2e58b$578787f0$bb01a8c0@xythoslap Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7440 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit > The protocol that is used to implement something like "mv" should > be an operation that preserves all characteristics of the objects, > so the client (not the server) can decide whether to accept the > information lossage inherent in copy/delete. > That seems unrealistic to me. Clients have shown that they don't care about propertybehavior -- none of them implemented that part of RFC2518. They just want to do a move! A server can often do a better job of move than the client's copy/delete attempt. Even if the server must transfer resources from one partition to another, the server can at least set properties like "creationdate" to the creation date. A user doing a COPY will cause "creationdate" to be initialized to the time of the COPY, and many servers don't allow that property to be written. Neither the client nor the server can guarantee a 100% perfect cross-partition move operation, but because the server can short-circuit some permissions issues, the server is much more likely to do a much better job. lisa From w3c-dist-auth-request@w3.org Sat Mar 8 11:10:44 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12847 for ; Sat, 8 Mar 2003 11:10:44 -0500 (EST) Received: from frink.w3.org (localhost [127.0.0.1]) by frink.w3.org (8.12.8/8.12.8) with ESMTP id h28GCJ9C000518; Sat, 8 Mar 2003 11:12:19 -0500 (EST) Received: (from lists@localhost) by frink.w3.org (8.12.8/8.12.8/Submit) id h28GCH6d000456; Sat, 8 Mar 2003 11:12:17 -0500 (EST) Resent-Date: Sat, 8 Mar 2003 11:12:17 -0500 (EST) Resent-Message-Id: <200303081612.h28GCH6d000456@frink.w3.org> Received: from tux.w3.org (IDENT:root@tux [18.29.0.27]) by frink.w3.org (8.12.8/8.12.8) with ESMTP id h28GCG9C000424 for ; Sat, 8 Mar 2003 11:12:16 -0500 (EST) Received: from sunbelt.seagull.net (user34.net540.or.sprint-hsd.net [65.40.225.34]) by tux.w3.org (8.12.8/8.12.8) with ESMTP id h28GCErB028546 for ; Sat, 8 Mar 2003 11:12:15 -0500 Received: (mail@localhost) by sunbelt.seagull.net (8.9.3) id IAA31355 sender nn683849@smallcue.com for w3c-dist-auth@w3.org; Sat, 8 Mar 2003 08:12:14 -0800 Received: from e4.ny.us.ibm.com (e4.ny.us.ibm.com [32.97.182.104]) by sunbelt.seagull.net (8.9.3) with ESMTP id IAA31339 sender obsfucated@us.ibm.com; Sat, 8 Mar 2003 08:12:12 -0800 Received: from northrelay04.pok.ibm.com (northrelay04.pok.ibm.com [9.56.224.206]) by e4.ny.us.ibm.com (8.12.8/8.12.2) with ESMTP id h28GBe4V073064; Sat, 8 Mar 2003 11:11:40 -0500 Received: from d01ml243.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by northrelay04.pok.ibm.com (8.12.8/NCO/VER6.5) with ESMTP id h28GBcri094274; Sat, 8 Mar 2003 11:11:38 -0500 To: "Julian Reschke" Cc: "'WebDAV'" X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: Jason Crawford Date: Sat, 8 Mar 2003 11:06:49 -0500 X-MIMETrack: Serialize by Router on D01ML243/01/M/IBM(Release 6.0.1 [IBM]|March 7, 2003) at 03/08/2003 11:11:38 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Subject: RE: Move and Delete (was: bind draft issues) X-Archived-At: http://www.w3.org/mid/OFA19A99D8.E5ECBD03-ON85256CE3.0054B6B1@us.ibm.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7441 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: > What is (or was) open to discussion whether servers may want to support > > - multiple bindings > - BIND live properties > - BIND MOVE semantics > > without supporting UNBIND semantics (or actually without supporting UNBIND > semantics on the *last* binding to a collection). That's what we planned to > do in our server, and I think this behaviour should be allowed. > > Making the "new" behaviour explicit in UNBIND/REBIND instead of DELETE/MOVE > allows a server to support clients that are only RFC2518-aware as before, > yet offers newer clients the ability to rely on the tightened semantics (or > reliably get the request failed if the semantics cannot be offered). > > Coming back to the new methods: > > REBIND/MOVE: I think everybody agrees that it would be a good if new clients > could request a resource MOVE that will leave all dead and live properties > intact. If we can't put that into RFC2518-MOVE, we'll need a new way of > marshall the request. Do we have consensus here? That seems valuable and I must have overlooked that view on it in the previous discussions. > UNBIND/DELETE: I think there was some confusion here about why people did > not like requiring DELETE to use UNBIND semantics. If a server *does* > support multiple bindings, DELETEing one of many bindings indeed should only > remove that binding, and thus be atomic (does anybody disagree here?). I > only have an issue to require this particular semantics for the *last* > binding to a collection (in which case I'd prefer to use the old RFC2518 > DELETE semantics). I know Julian knows this, but just in case others don't... that "last-binding" (from outside the tree) check applies to all bindings in the subtree. Julian, would you be willing to support both in your server. If you think clients prefer the non-atomic delete on the final binding, you could implement that for DELETE and you'd still implement UNBIND atomicly? The reason I ask is that if servers are going to implement these operations only one way, that limits the value of having two methods. Clients will only get the one way that the server implements anyway (or they can buy a new server). There is little point in a client implementor calling UNBIND if few servers will implement it unless he knows that his user wants only that behavior. But unless he knows that, he has to make DELETE the default thing he calls. A seperate UNBIND method becomes almost pointless. Whereas if server vendors implement each semantic and each semantic are invokable with a predictable method, the clients can specify what they want to happen. Anyway, that's why I ask what you (and other server vendors) would do with your server if the current proposal were passed. J. ------------------------------------------ Phone: 914-784-7569, ccjason@us.ibm.com I do not check nn621779@smallcue.com From w3c-dist-auth-request@w3.org Sat Mar 8 12:59:04 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02421 for ; Sat, 8 Mar 2003 12:59:04 -0500 (EST) Received: from frink.w3.org (localhost [127.0.0.1]) by frink.w3.org (8.12.8/8.12.8) with ESMTP id h28I0b9C019763; Sat, 8 Mar 2003 13:00:37 -0500 (EST) Received: (from lists@localhost) by frink.w3.org (8.12.8/8.12.8/Submit) id h28I0M69019725; Sat, 8 Mar 2003 13:00:22 -0500 (EST) Resent-Date: Sat, 8 Mar 2003 13:00:22 -0500 (EST) Resent-Message-Id: <200303081800.h28I0M69019725@frink.w3.org> Received: from tux.w3.org (IDENT:root@tux [18.29.0.27]) by frink.w3.org (8.12.8/8.12.8) with ESMTP id h28I0K9C019689 for ; Sat, 8 Mar 2003 13:00:20 -0500 (EST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by tux.w3.org (8.12.8/8.12.8) with SMTP id h28I0JrB013232 for ; Sat, 8 Mar 2003 13:00:20 -0500 Received: (qmail 20871 invoked by uid 0); 8 Mar 2003 18:00:13 -0000 Received: from pD950C246.dip.t-dialin.net (HELO lisa) (217.80.194.70) by mail.gmx.net (mp020-rz3) with SMTP; 8 Mar 2003 18:00:13 -0000 From: "Julian Reschke" To: "Jason Crawford" , "Julian Reschke" Cc: "'WebDAV'" Date: Sat, 8 Mar 2003 19:00:04 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 In-Reply-To: Importance: Normal Subject: RE: Move and Delete (was: bind draft issues) X-Archived-At: http://www.w3.org/mid/JIEGINCHMLABHJBIGKBCKEDFGLAA.julian.reschke@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7442 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Jason Crawford > Sent: Saturday, March 08, 2003 5:07 PM > To: Julian Reschke > Cc: 'WebDAV' > Subject: RE: Move and Delete (was: bind draft issues) > > > ... > > Julian, > would you be willing to support both in your server. If you think clients prefer > the non-atomic delete on the final binding, you could implement that for DELETE > and you'd still implement UNBIND atomicly? It's more a matter of server policy. I don't think we *want* to support the atomic UNBIND functionality when deleting the last binding to a collection. Thus our server might support UNBIND if and only if the binding being removed is not the last one. > ... -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Sat Mar 8 13:18:25 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06003 for ; Sat, 8 Mar 2003 13:18:24 -0500 (EST) Received: from frink.w3.org (localhost [127.0.0.1]) by frink.w3.org (8.12.8/8.12.8) with ESMTP id h28IK69C021833; Sat, 8 Mar 2003 13:20:06 -0500 (EST) Received: (from lists@localhost) by frink.w3.org (8.12.8/8.12.8/Submit) id h28IK2j1021763; Sat, 8 Mar 2003 13:20:02 -0500 (EST) Resent-Date: Sat, 8 Mar 2003 13:20:02 -0500 (EST) Resent-Message-Id: <200303081820.h28IK2j1021763@frink.w3.org> Received: from tux.w3.org (IDENT:root@tux [18.29.0.27]) by frink.w3.org (8.12.8/8.12.8) with ESMTP id h28IJv9C021713 for ; Sat, 8 Mar 2003 13:19:57 -0500 (EST) Received: from mail.xythos.com ([206.14.210.116]) by tux.w3.org (8.12.8/8.12.8) with ESMTP id h28IJurB016694 for ; Sat, 8 Mar 2003 13:19:57 -0500 Received: from ravms by mail.xythos.com with mail-ok (Exim 3.36 #3) id 18rixB-0003Xj-00; Sat, 08 Mar 2003 18:21:49 +0000 Received: from [198.144.203.248] (helo=xythoslap) by mail.xythos.com with asmtp (Exim 3.36 #3) id 18rixA-0003XY-00; Sat, 08 Mar 2003 18:21:49 +0000 From: "Lisa Dusseault" To: "'Julian Reschke'" , "'WebDAV'" Date: Sat, 8 Mar 2003 10:19:53 -0800 Message-ID: <067001c2e59f$512a1b70$bb01a8c0@xythoslap> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4024 Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Old-X-Envelope-To: julian.reschke@greenbytes.de, w3c-dist-auth@w3.org Subject: RE: GULP vs RFC2518bis X-Archived-At: http://www.w3.org/mid/067001c2e59f$512a1b70$bb01a8c0@xythoslap Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7443 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit Here's some initial feedback on the latest GULP. I much prefer replacing the "bindings" terminology with the "internal member" terminology. That said, I'm still thinking about the model. I think it's worth considering carefully. "An UNLOCK request deletes the lock with the specified lock token. The request-URL of the request MUST identify a resource that is either directly or indirectly locked by that lock. After a lock is deleted, no resource is locked by that lock." Do we really want to allow an UNLOCK to an indirectly-locked resource to remove the lock on the directly locked parent? I'd like to know whether implementations either already support this or are willing to add support for this. I don't have time to verify WFS at the moment but I'm assuming it's better to send a partial response now than a more complete response later when I dig myself out from a large amount of work. "A lock token is "submitted" in a request when it appears in an If header tagged-list whose tag is the lock-root of the lock." This doesn't mention untagged-list syntax in If header. Is a corollary of this proposal that we remove the untagged-list syntax? Or was the omission of untagged-list accidental? I'd prefer to keep the untagged list syntax, so I believe this should read: "A lock token is "submitted" in a request when it appears in an If header." Then this paragraph, with the substitution to "internal member" made as Julian suggested... "If a request would modify the content for a locked resource, a dead property of a locked resource, a live property that is defined to be lockable for a locked resource, or a member URL in a locked collection, the request MUST fail unless the lock-token for that lock is submitted in the request." Being picky here, this sentence is conditional on a request modifying "a member URL" in a locked collection. Isn't it any modifications to the internal member, not just the URL? E.g. this definition must encompass a PUT to a indirectly locked internal member, as well as a MOVE. Lisa > -----Original Message----- > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org] On Behalf Of Julian Reschke > Sent: Friday, March 07, 2003 6:24 AM > To: 'WebDAV' > Subject: GULP vs RFC2518bis > > > > Hi. > > I'd really like to see some progress regarding this issue. In > http://lists.w3.org/Archives/Public/w3c-dist-auth/2003JanMar/0281.html I have tried to rephrase GULP so that it doesn't require the term "binding" anymore. This should address the concerns of those who fear that a dependency on the BIND spec is introduced. To those who did object to GULP being part of RFC2518bis *please* review this? Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Sat Mar 8 13:24:52 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07424 for ; Sat, 8 Mar 2003 13:24:51 -0500 (EST) Received: from frink.w3.org (localhost [127.0.0.1]) by frink.w3.org (8.12.8/8.12.8) with ESMTP id h28IQ49C023587; Sat, 8 Mar 2003 13:26:04 -0500 (EST) Received: (from lists@localhost) by frink.w3.org (8.12.8/8.12.8/Submit) id h28IQ3FG023580; Sat, 8 Mar 2003 13:26:03 -0500 (EST) Resent-Date: Sat, 8 Mar 2003 13:26:03 -0500 (EST) Resent-Message-Id: <200303081826.h28IQ3FG023580@frink.w3.org> Received: from tux.w3.org (IDENT:root@tux [18.29.0.27]) by frink.w3.org (8.12.8/8.12.8) with ESMTP id h28IQ19C023544 for ; Sat, 8 Mar 2003 13:26:01 -0500 (EST) Received: from post.webmailer.de (natsmtp00.webmailer.de [192.67.198.74]) by tux.w3.org (8.12.8/8.12.8) with ESMTP id h28IQ0rB018196 for ; Sat, 8 Mar 2003 13:26:01 -0500 Received: from x.oberon.ethz.ch (dialin-212-144-129-050.arcor-ip.net [212.144.129.50]) by post.webmailer.de (8.12.8/8.8.7) with SMTP id h28IPuCZ011070; Sat, 8 Mar 2003 19:25:58 +0100 (MET) Date: Sat, 8 Mar 2003 19:25:56 +0100 (MET) Message-Id: <200303081825.h28IPuCZ011070@post.webmailer.de> From: Edgar@edgarschwarz.de X-Mailer: Oberon Mail (ejz) on Aos 13.08.2002 To: w3c-dist-auth@w3.org Cc: Edgar@edgarschwarz.de Subject: Re (2): Move and Delete (was: bind draft issues) X-Archived-At: http://www.w3.org/mid/200303081825.h28IPuCZ011070@post.webmailer.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7444 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Hi, I don't have time to follow the discussion in detail at the moment but this post provokes a comment. "Clemm, Geoff" wrote: > From: Brian Korver [mailto:briank@xythos.com] > > Other than loops, what are the problems unique to multiple > bindings and partial MOVE? > > One example was posted in the message below: > > From: Clemm, Geoff [gclemm@Rational.Com] > Sent: Monday, March 03, 2003 6:34 PM > Subject: RE: Move and Delete (was: bind draft issues) > > ... > because it can cause a DELETE in one collection to cause a change > in another collection, and this kind of "deletion side effect" > was something we explicitly were trying to avoid. For example, > suppose /henry/has-friend/jeff and /jim/has-friend/jeff > were bindings to the same collection, JEFF, and JEFF has a binding > named "wife" to a resource, MARI. Now suppose henry gets mad > at jeff, and issues a "DELETE /henry/has-friend/jeff" request. > But suppose at that moment someone else has a Depth:0 lock > on the /henry/has-friend collection. The result of a "best effort" > deletion is the removal of the "wife" binding from JEFF. That > may be OK if you were just updating the information accessible > from /henry (he isn't JEFF's friend anymore, and he's happy to > purge as much information about JEFF as he can), but with multiple > bindings, "best effort" deletion has now trashed the JEFF object > in all the other contexts in which it is still visible (and the > folks that still are his friends are still interested in that > information). > > So we're not saying that "best effort deletion" is always a bad thing, > but we are saying that "best effort deletion" is a bad thing when > you care about multiple bindings to the same resource. Goeff, I don't think your scenario is valid for our discussion. If no lock had existed then all information would have been deleted. So for the folks that still are his friends JEFF/* would be "completely" trashed. Would have this have been a better or worse situation for them ? IMHO this usecase doesn't say anything about the "badness" of "best effort deletion". Either jeff gives jim and henry the rights to delete JEFF/* even if it's shared, or he doesn't allow it. It's jeffs decision. Cheers, Edgar -- edgar@edgarschwarz.de "http://www.edgarschwarz.de" "http://www.edgar-schwarz.de/forum/oberon" Running Active Oberon Make it as simple as possible, but not simpler. Albert Einstein From w3c-dist-auth-request@w3.org Sat Mar 8 13:32:26 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09081 for ; Sat, 8 Mar 2003 13:32:26 -0500 (EST) Received: from frink.w3.org (localhost [127.0.0.1]) by frink.w3.org (8.12.8/8.12.8) with ESMTP id h28IXv9C024945; Sat, 8 Mar 2003 13:33:57 -0500 (EST) Received: (from lists@localhost) by frink.w3.org (8.12.8/8.12.8/Submit) id h28IXtro024911; Sat, 8 Mar 2003 13:33:55 -0500 (EST) Resent-Date: Sat, 8 Mar 2003 13:33:55 -0500 (EST) Resent-Message-Id: <200303081833.h28IXtro024911@frink.w3.org> Received: from tux.w3.org (IDENT:root@tux [18.29.0.27]) by frink.w3.org (8.12.8/8.12.8) with ESMTP id h28IXr9C024877 for ; Sat, 8 Mar 2003 13:33:53 -0500 (EST) Received: from mail.xythos.com ([206.14.210.116]) by tux.w3.org (8.12.8/8.12.8) with ESMTP id h28IXqrB019361 for ; Sat, 8 Mar 2003 13:33:52 -0500 Received: from ravms by mail.xythos.com with mail-ok (Exim 3.36 #3) id 18rjAc-0003bZ-00; Sat, 08 Mar 2003 18:35:42 +0000 Received: from [198.144.203.248] (helo=xythoslap) by mail.xythos.com with asmtp (Exim 3.36 #3) id 18rjAc-0003bO-00; Sat, 08 Mar 2003 18:35:42 +0000 From: "Lisa Dusseault" To: "'Jason Crawford'" Cc: "'Clemm, Geoff'" , "'Julian Reschke'" , "'WebDAV'" Date: Sat, 8 Mar 2003 10:33:47 -0800 Message-ID: <067301c2e5a1$41d4b6b0$bb01a8c0@xythoslap> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4024 Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Old-X-Envelope-To: gclemm@rational.com, julian.reschke@gmx.de, nn683849@smallcue.com, w3c-dist-auth@w3.org Subject: RE: Move and Delete (was: bind draft issues) X-Archived-At: http://www.w3.org/mid/067301c2e5a1$41d4b6b0$bb01a8c0@xythoslap Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7445 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit > On Friday, 03/07/2003 at 01:30 PST, "Lisa Dusseault" > wrote: > > > > > > > Anyway, the main issue for us is that we absolutely can not > > > change the > > > > DELETE collection semantics (from what we have in RFC2518). > > > > > > Sure you can. The behavior the spec outlines is > compliant with 2518. > > > It does not break 2518 compliant clients. But it does > require that > > > server writers do some coding before they can claim to support > > > this new feature. > > > > > > > Well, yes, one can change the required behavior from 2518 > to 2518bis. > > However, we don't want to do that unless there are existing > > interoperability problems. I don't think changing the model so that > > some servers have difficulty being compliant with the new model is a > > good idea for 2518bis. > > They'd still be compliant. SHOULD is not MUST > I don't think we're talking about the same thing any more. Perhaps too much context was deleted. I was talking about what I thought was a suggestion to use "MUST" with respect to DELETE being atomic in 2518bis. Lisa From w3c-dist-auth-request@w3.org Sat Mar 8 13:43:11 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA11054 for ; Sat, 8 Mar 2003 13:43:11 -0500 (EST) Received: from frink.w3.org (localhost [127.0.0.1]) by frink.w3.org (8.12.8/8.12.8) with ESMTP id h28IiO9C026850; Sat, 8 Mar 2003 13:44:24 -0500 (EST) Received: (from lists@localhost) by frink.w3.org (8.12.8/8.12.8/Submit) id h28IiMmg026818; Sat, 8 Mar 2003 13:44:22 -0500 (EST) Resent-Date: Sat, 8 Mar 2003 13:44:22 -0500 (EST) Resent-Message-Id: <200303081844.h28IiMmg026818@frink.w3.org> Received: from tux.w3.org (IDENT:root@tux [18.29.0.27]) by frink.w3.org (8.12.8/8.12.8) with ESMTP id h28IiJ9C026786 for ; Sat, 8 Mar 2003 13:44:19 -0500 (EST) Received: from mail.xythos.com ([206.14.210.116]) by tux.w3.org (8.12.8/8.12.8) with ESMTP id h28IiJrB020886 for ; Sat, 8 Mar 2003 13:44:19 -0500 Received: from ravms by mail.xythos.com with mail-ok (Exim 3.36 #3) id 18rjKm-0003eK-00; Sat, 08 Mar 2003 18:46:12 +0000 Received: from [198.144.203.248] (helo=xythoslap) by mail.xythos.com with asmtp (Exim 3.36 #3) id 18rjKm-0003e9-00; Sat, 08 Mar 2003 18:46:12 +0000 From: "Lisa Dusseault" To: "'Clemm, Geoff'" , "'WebDAV'" Date: Sat, 8 Mar 2003 10:44:16 -0800 Message-ID: <067401c2e5a2$b91c7db0$bb01a8c0@xythoslap> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4024 Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Old-X-Envelope-To: gclemm@rational.com, w3c-dist-auth@w3.org Subject: RE: Move and Delete (was: bind draft issues) X-Archived-At: http://www.w3.org/mid/067401c2e5a2$b91c7db0$bb01a8c0@xythoslap Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7446 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit What about this model with respect to DELETE and bindings? Rough specification-like language follows... --- When a client issues a DELETE request to a collection that has internal bindings, the preferred server behavior is naturally to achieve a complete success, whenever possible. However, servers may behave differently depending on what bindings exist in the rest of the system. The collection being deleted may contain the last bindings to one or more resources. When the last binding to a resource is deleted, the server may be implemented to perform some cleanup (e.g. release tied-up storage resources). If the server is unable to complete its cleanup, the server MAY do an incomplete recursive delete operation, leaving some resources behind. The server MAY leave parent collections of undeletable bindings/resources in place in order to preserve a consistent URL namespace -- this is equivalent to the behavior specified in RFC2518 [section ref]. The benefit of maintaining a consistent namespace, to a server implementation, is that orphaned resources remain findable by clients, so that clients can take actions like changing permissions or removing locks and finish their DELETE operation. In case of a partial DELETE success, the server MUST report individual undeleted bindings/resources, URL by URL, using the multi-status response body. At the other extreme, a DELETE request to a collection may be as simple as an atomic unbind, which is clearly preferable because to the client's point of view this is a complete success. --- Lisa > -----Original Message----- > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org] On Behalf Of Clemm, Geoff > Sent: Friday, March 07, 2003 6:09 PM > To: 'WebDAV' > Subject: RE: Move and Delete (was: bind draft issues) > > > > From: Brian Korver [mailto:briank@xythos.com] > > Other than loops, what are the problems unique to multiple > bindings and partial MOVE? > > One example was posted in the message below: > > From: Clemm, Geoff [gclemm@Rational.Com] > Sent: Monday, March 03, 2003 6:34 PM > Subject: RE: Move and Delete (was: bind draft issues) > > ... > because it can cause a DELETE in one collection to cause a change > in another collection, and this kind of "deletion side effect" > was something we explicitly were trying to avoid. For example, > suppose /henry/has-friend/jeff and /jim/has-friend/jeff > were bindings to the same collection, JEFF, and JEFF has a binding > named "wife" to a resource, MARI. Now suppose henry gets mad > at jeff, and issues a "DELETE /henry/has-friend/jeff" request. > But suppose at that moment someone else has a Depth:0 lock > on the /henry/has-friend collection. The result of a "best effort" > deletion is the removal of the "wife" binding from JEFF. That > may be OK if you were just updating the information accessible > from /henry (he isn't JEFF's friend anymore, and he's happy to > purge as much information about JEFF as he can), but with multiple > bindings, "best effort" deletion has now trashed the JEFF object > in all the other contexts in which it is still visible (and the > folks that still are his friends are still interested in that > information). > > So we're not saying that "best effort deletion" is always > a bad thing, > but we are saying that "best effort deletion" is a bad thing when > you care about multiple bindings to the same resource. > > From w3c-dist-auth-request@w3.org Sat Mar 8 14:01:30 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14579 for ; Sat, 8 Mar 2003 14:01:30 -0500 (EST) Received: from frink.w3.org (localhost [127.0.0.1]) by frink.w3.org (8.12.8/8.12.8) with ESMTP id h28J2o9C028985; Sat, 8 Mar 2003 14:02:50 -0500 (EST) Received: (from lists@localhost) by frink.w3.org (8.12.8/8.12.8/Submit) id h28J2eLu028943; Sat, 8 Mar 2003 14:02:40 -0500 (EST) Resent-Date: Sat, 8 Mar 2003 14:02:40 -0500 (EST) Resent-Message-Id: <200303081902.h28J2eLu028943@frink.w3.org> Received: from tux.w3.org (IDENT:root@tux [18.29.0.27]) by frink.w3.org (8.12.8/8.12.8) with ESMTP id h28J2b9C028911 for ; Sat, 8 Mar 2003 14:02:37 -0500 (EST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by tux.w3.org (8.12.8/8.12.8) with SMTP id h28J2arB024005 for ; Sat, 8 Mar 2003 14:02:36 -0500 Received: (qmail 15148 invoked by uid 0); 8 Mar 2003 19:02:29 -0000 Received: from pD950C246.dip.t-dialin.net (HELO lisa) (217.80.194.70) by mail.gmx.net (mp021-rz3) with SMTP; 8 Mar 2003 19:02:29 -0000 From: "Julian Reschke" To: "Lisa Dusseault" , "'WebDAV'" Date: Sat, 8 Mar 2003 20:02:21 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 In-Reply-To: <067001c2e59f$512a1b70$bb01a8c0@xythoslap> Importance: Normal Subject: RE: GULP vs RFC2518bis X-Archived-At: http://www.w3.org/mid/JIEGINCHMLABHJBIGKBCAEDJGLAA.julian.reschke@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7447 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Lisa Dusseault > Sent: Saturday, March 08, 2003 7:20 PM > To: 'Julian Reschke'; 'WebDAV' > Subject: RE: GULP vs RFC2518bis > > > > Here's some initial feedback on the latest GULP. > > I much prefer replacing the "bindings" terminology with the "internal > member" terminology. That said, I'm still thinking about the model. I > think it's worth considering carefully. > > "An UNLOCK request deletes the lock with the specified lock token. > The request-URL of the request MUST identify a resource that > is either directly or indirectly locked by that lock. > After a lock is deleted, no resource is locked by that lock." > > Do we really want to allow an UNLOCK to an indirectly-locked resource to > remove the lock on the directly locked parent? I'd like to know whether RFC2518 says about UNLOCK: "The UNLOCK method removes the lock identified by the lock token in the Lock-Token request header from the Request-URI, and all other resources included in the lock. If all resources which have been locked under the submitted lock token can not be unlocked then the UNLOCK request MUST fail. " So I think GULP only repeats what RFC2518 has been saying all the time (BTW: this is issue UNLOCK_WHAT_URL on the open issues list). > implementations either already support this or are willing to add > support for this. I don't have time to verify WFS at the moment but I'm > assuming it's better to send a partial response now than a more complete > response later when I dig myself out from a large amount of work. > > > "A lock token is "submitted" in a request when it appears in an If > header tagged-list whose tag is the lock-root of the lock." > > This doesn't mention untagged-list syntax in If header. Is a corollary > of this proposal that we remove the untagged-list syntax? Or was the > omission of untagged-list accidental? I'd prefer to keep the untagged > list syntax, so I believe this should read: > "A lock token is "submitted" in a request when it appears in an If > header." I'd prefer "when it appears in an If header tagged-list whose tag is the lock-root of the lock, or if it appears in an untagged list and the request-URL is the lock-root of the lock". > Then this paragraph, with the substitution to "internal member" made as > Julian suggested... > > "If a request would modify the content for a locked resource, a dead > property of a locked resource, a live property that is defined to be > lockable for a locked resource, or a member URL in a locked collection, > the request MUST fail unless the lock-token for that lock is > submitted in the request." > > Being picky here, this sentence is conditional on a request modifying "a > member URL" in a locked collection. Isn't it any modifications to the > internal member, not just the URL? E.g. this definition must encompass > a PUT to a indirectly locked internal member, as well as a MOVE. No. The *shallow* lock on a collection locks it's member URLs. If the lock on the collection isn't deep, you can modify internal members without the lock token, as long as you don't change their name (affecting the state of the collection itself). -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Sat Mar 8 14:01:55 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14669 for ; Sat, 8 Mar 2003 14:01:54 -0500 (EST) Received: from frink.w3.org (localhost [127.0.0.1]) by frink.w3.org (8.12.8/8.12.8) with ESMTP id h28J3Q9C029636; Sat, 8 Mar 2003 14:03:26 -0500 (EST) Received: (from lists@localhost) by frink.w3.org (8.12.8/8.12.8/Submit) id h28J3PGD029626; Sat, 8 Mar 2003 14:03:25 -0500 (EST) Resent-Date: Sat, 8 Mar 2003 14:03:25 -0500 (EST) Resent-Message-Id: <200303081903.h28J3PGD029626@frink.w3.org> Received: from tux.w3.org (IDENT:root@tux [18.29.0.27]) by frink.w3.org (8.12.8/8.12.8) with ESMTP id h28J3O9C029590 for ; Sat, 8 Mar 2003 14:03:24 -0500 (EST) Received: from mail.xythos.com ([206.14.210.116]) by tux.w3.org (8.12.8/8.12.8) with ESMTP id h28J3NrB024281 for ; Sat, 8 Mar 2003 14:03:24 -0500 Received: from ravms by mail.xythos.com with mail-ok (Exim 3.36 #3) id 18rjdF-0003ic-00; Sat, 08 Mar 2003 19:05:17 +0000 Received: from [198.144.203.248] (helo=xythoslap) by mail.xythos.com with asmtp (Exim 3.36 #3) id 18rjdE-0003iR-00; Sat, 08 Mar 2003 19:05:16 +0000 From: "Lisa Dusseault" To: "'Julian Reschke'" , "'WebDAV'" Cc: Date: Sat, 8 Mar 2003 11:03:21 -0800 Message-ID: <067501c2e5a5$633de340$bb01a8c0@xythoslap> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4024 Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Old-X-Envelope-To: acl@webdav.org, julian.reschke@gmx.de, w3c-dist-auth@w3.org Subject: Atomic MOVE and move permissions X-Archived-At: http://www.w3.org/mid/067501c2e5a5$633de340$bb01a8c0@xythoslap Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7448 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit > > Actually, collection MOVE suffers from the same problems as > collection > > DELETE. Here are some of them. > > - You can't MOVE a file you don't have permission to > write. Therefore, > > the server must check write privileges on all descendants. > > I think I disagree. I *can* MOVE a resource without having > write permissions > to the resource itself. What I need is the write permission > on source and > targer collection (+ some more when overwriting something else). That's really interesting. This is a tangent, but an important one, I think. I had assumed that if I have 'write' permission on a collection "home/", but I do *not* have write permission on an internal member "foo.txt", that an attempt to MOVE home/foo.txt (either to another collection or a rename) would fail. In the absence of the ACL specification, my assumption is as good as yours! Now, I did check the ACL specification to see how servers supporting that specification would have to behave. I don't think the ACL specification is totally clear on that issue. Is this a bug in the ACL draft? Even if we can't specify one or the other, the ACL draft should specify that a user may or may not need write permission specifically on a resource to move it, as well as write permission to the source and target parent collections. But back to the atomic vs. non-atomic move, the permissions example was just an example. You still have to recursively check privileges on all descendent _collections_ if one accepts your permissions model. And you still have to recursively check locks, etc. The basic argument for non-atomic move was that in some situations, the server will have to implement it as a super-user COPY-->DELETE. > Yes, that's why many people would prefer it to fail (leaving > the client the > choice to explicitly COPY/DELETE) rather than doing something > the client > din't really want. Right, but did you read the part about how the server might be able to do a much better job of the under-the-cover copy-and-delete than the client possibly could? A client can only do operations based on its authenticated context, whereas the server process may have more power to change things. My first example, and it's only one of many, was that a client may not have permission to set "creationdate" but a server obviously can. So if the server accomplishes the MOVE by doing a copy-and-delete behind the scenes, the server can clean up "creationdate" so that it's the date of the original resource. However, the client may not be allowed to set the value of "creationdate" to the most correct value after it does a manual COPY operation. Lisa From w3c-dist-auth-request@w3.org Sat Mar 8 14:06:09 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15442 for ; Sat, 8 Mar 2003 14:06:09 -0500 (EST) Received: from frink.w3.org (localhost [127.0.0.1]) by frink.w3.org (8.12.8/8.12.8) with ESMTP id h28J7R9C000306; Sat, 8 Mar 2003 14:07:27 -0500 (EST) Received: (from lists@localhost) by frink.w3.org (8.12.8/8.12.8/Submit) id h28J7QU9000286; Sat, 8 Mar 2003 14:07:26 -0500 (EST) Resent-Date: Sat, 8 Mar 2003 14:07:26 -0500 (EST) Resent-Message-Id: <200303081907.h28J7QU9000286@frink.w3.org> Received: from tux.w3.org (IDENT:root@tux [18.29.0.27]) by frink.w3.org (8.12.8/8.12.8) with ESMTP id h28J7N9C000246 for ; Sat, 8 Mar 2003 14:07:23 -0500 (EST) Received: from mail.xythos.com ([206.14.210.116]) by tux.w3.org (8.12.8/8.12.8) with ESMTP id h28J7NrB024903 for ; Sat, 8 Mar 2003 14:07:23 -0500 Received: from ravms by mail.xythos.com with mail-ok (Exim 3.36 #3) id 18rjh7-0003jy-00; Sat, 08 Mar 2003 19:09:17 +0000 Received: from [198.144.203.248] (helo=xythoslap) by mail.xythos.com with asmtp (Exim 3.36 #3) id 18rjh6-0003jn-00; Sat, 08 Mar 2003 19:09:17 +0000 From: "Lisa Dusseault" To: "'Jason Crawford'" Cc: "'WebDAV'" Date: Sat, 8 Mar 2003 11:07:21 -0800 Message-ID: <067601c2e5a5$f2644fa0$bb01a8c0@xythoslap> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4024 Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Old-X-Envelope-To: nn683849@smallcue.com, w3c-dist-auth@w3.org Subject: RE: Move and Delete (was: bind draft issues) X-Archived-At: http://www.w3.org/mid/067601c2e5a5$f2644fa0$bb01a8c0@xythoslap Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7449 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit I second what Jason said -- based on the lack of client support for "propertybehavior" I'd like to see a couple client implementors say they would implement a feature which would allow them to choose, on some servers supporting atomic MOVE/DELETE, whether to force that behavior or not. A light-weight approach is that since some servers will be atomic and some won't, merely define some string in a header or body in response to OPTIONS which says "I do atomic delete always" or "I don't always do atomic delete". Clients may or may not use that information, but at least it's really easy for a server to advertise. Lisa > Julian, > would you be willing to support both in your server. If you think > clients prefer > the non-atomic delete on the final binding, you could > implement that for > DELETE > and you'd still implement UNBIND atomicly? > > The reason I ask is that if servers are going to implement > these operations > only > one way, that limits the value of having two methods. > Clients will only > get the one way > that the server implements anyway (or they can buy a new > server). There is > little point > in a client implementor calling UNBIND if few servers will > implement it > unless he knows > that his user wants only that behavior. But unless he knows > that, he has > to make DELETE > the default thing he calls. A seperate UNBIND method becomes almost > pointless. > Whereas if server vendors implement each semantic and each > semantic are > invokable > with a predictable method, the clients can specify what they want to > happen. > > Anyway, that's why I ask what you (and other server vendors) > would do with > your server > if the current proposal were passed. > > J. > > ------------------------------------------ > Phone: 914-784-7569, ccjason@us.ibm.com > I do not check nn621779@smallcue.com > > From w3c-dist-auth-request@w3.org Sat Mar 8 14:08:40 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16001 for ; Sat, 8 Mar 2003 14:08:40 -0500 (EST) Received: from frink.w3.org (localhost [127.0.0.1]) by frink.w3.org (8.12.8/8.12.8) with ESMTP id h28JAD9C000879; Sat, 8 Mar 2003 14:10:13 -0500 (EST) Received: (from lists@localhost) by frink.w3.org (8.12.8/8.12.8/Submit) id h28JADvt000873; Sat, 8 Mar 2003 14:10:13 -0500 (EST) Resent-Date: Sat, 8 Mar 2003 14:10:13 -0500 (EST) Resent-Message-Id: <200303081910.h28JADvt000873@frink.w3.org> Received: from tux.w3.org (IDENT:root@tux [18.29.0.27]) by frink.w3.org (8.12.8/8.12.8) with ESMTP id h28JAB9C000841 for ; Sat, 8 Mar 2003 14:10:11 -0500 (EST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by tux.w3.org (8.12.8/8.12.8) with SMTP id h28JABrB025396 for ; Sat, 8 Mar 2003 14:10:11 -0500 Received: (qmail 16314 invoked by uid 0); 8 Mar 2003 19:10:03 -0000 Received: from pD950C246.dip.t-dialin.net (HELO lisa) (217.80.194.70) by mail.gmx.net (mp022-rz3) with SMTP; 8 Mar 2003 19:10:03 -0000 From: "Julian Reschke" To: "Lisa Dusseault" , "'Clemm, Geoff'" , "'WebDAV'" Date: Sat, 8 Mar 2003 20:09:52 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 In-Reply-To: <067401c2e5a2$b91c7db0$bb01a8c0@xythoslap> Importance: Normal Subject: RE: Move and Delete (was: bind draft issues) X-Archived-At: http://www.w3.org/mid/JIEGINCHMLABHJBIGKBCEEDKGLAA.julian.reschke@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7450 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Lisa Dusseault > Sent: Saturday, March 08, 2003 7:44 PM > To: 'Clemm, Geoff'; 'WebDAV' > Subject: RE: Move and Delete (was: bind draft issues) > > > > > What about this model with respect to DELETE and bindings? Rough > specification-like language follows... > > --- > When a client issues a DELETE request to a collection that has internal > bindings, the preferred server behavior is naturally to achieve a > complete success, whenever possible. However, servers may behave > differently depending on what bindings exist in the rest of the system. > The collection being deleted may contain the last bindings to one or > more resources. When the last binding to a resource is deleted, the > server may be implemented to perform some cleanup (e.g. release tied-up > storage resources). If the server is unable to complete its cleanup, > the server MAY do an incomplete recursive delete operation, leaving some > resources behind. The server MAY leave parent collections of undeletable ...I think that's MUST... > bindings/resources in place in order to preserve a consistent URL > namespace -- this is equivalent to the behavior specified in RFC2518 > [section ref]. The benefit of maintaining a consistent namespace, to a > server implementation, is that orphaned resources remain findable by > clients, so that clients can take actions like changing permissions or > removing locks and finish their DELETE operation. In case of a partial > DELETE success, the server MUST report individual undeleted > bindings/resources, URL by URL, using the multi-status response body. (except for result minimization as mandated by RFC2518, section 8.6.2. > At the other extreme, a DELETE request to a collection may be as simple > as an atomic unbind, which is clearly preferable because to the client's > point of view this is a complete success. -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Sat Mar 8 14:15:06 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17210 for ; Sat, 8 Mar 2003 14:15:06 -0500 (EST) Received: from frink.w3.org (localhost [127.0.0.1]) by frink.w3.org (8.12.8/8.12.8) with ESMTP id h28JGU9C001852; Sat, 8 Mar 2003 14:16:30 -0500 (EST) Received: (from lists@localhost) by frink.w3.org (8.12.8/8.12.8/Submit) id h28JGSUG001825; Sat, 8 Mar 2003 14:16:28 -0500 (EST) Resent-Date: Sat, 8 Mar 2003 14:16:28 -0500 (EST) Resent-Message-Id: <200303081916.h28JGSUG001825@frink.w3.org> Received: from tux.w3.org (IDENT:root@tux [18.29.0.27]) by frink.w3.org (8.12.8/8.12.8) with ESMTP id h28JGN9C001709 for ; Sat, 8 Mar 2003 14:16:23 -0500 (EST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by tux.w3.org (8.12.8/8.12.8) with SMTP id h28JGMrB026318 for ; Sat, 8 Mar 2003 14:16:23 -0500 Received: (qmail 30989 invoked by uid 0); 8 Mar 2003 19:16:16 -0000 Received: from pD950C246.dip.t-dialin.net (HELO lisa) (217.80.194.70) by mail.gmx.net (mp023-rz3) with SMTP; 8 Mar 2003 19:16:16 -0000 From: "Julian Reschke" To: "Lisa Dusseault" , "'Julian Reschke'" , "'WebDAV'" Cc: Date: Sat, 8 Mar 2003 20:16:06 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 In-Reply-To: <067501c2e5a5$633de340$bb01a8c0@xythoslap> Importance: Normal Subject: RE: Atomic MOVE and move permissions X-Archived-At: http://www.w3.org/mid/JIEGINCHMLABHJBIGKBCEEDLGLAA.julian.reschke@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7451 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Lisa Dusseault > Sent: Saturday, March 08, 2003 8:03 PM > To: 'Julian Reschke'; 'WebDAV' > Cc: acl@webdav.org > Subject: Atomic MOVE and move permissions > > > > > > Actually, collection MOVE suffers from the same problems as > > collection > > > DELETE. Here are some of them. > > > - You can't MOVE a file you don't have permission to > > write. Therefore, > > > the server must check write privileges on all descendants. > > > > I think I disagree. I *can* MOVE a resource without having > > write permissions > > to the resource itself. What I need is the write permission > > on source and > > targer collection (+ some more when overwriting something else). > > That's really interesting. This is a tangent, but an important one, I > think. I had assumed that if I have 'write' permission on a collection > "home/", but I do *not* have write permission on an internal member > "foo.txt", that an attempt to MOVE home/foo.txt (either to another > collection or a rename) would fail. In the absence of the ACL > specification, my assumption is as good as yours! Yes. Eric, could you please publish the latest state of the ACL spec (which includes the required-permission-per-method table)? > Now, I did check the ACL specification to see how servers supporting > that specification would have to behave. I don't think the ACL > specification is totally clear on that issue. Is this a bug in the ACL > draft? Even if we can't specify one or the other, the ACL draft should > specify that a user may or may not need write permission specifically on > a resource to move it, as well as write permission to the source and > target parent collections. I think a rename operation should not require write access to the resource itself (it only affects the state of the parent collection). I also think this was the consensus of the attendees of the January meeting. > But back to the atomic vs. non-atomic move, the permissions example was > just an example. You still have to recursively check privileges on all > descendent _collections_ if one accepts your permissions model. And you Why? > still have to recursively check locks, etc. The basic argument for Yes. > non-atomic move was that in some situations, the server will have to > implement it as a super-user COPY-->DELETE. Yes. And the basic argument for RENAME is that in some cases a client doesn't *wan't* that to happen, because the resulting resource may behave differently than the original. > > Yes, that's why many people would prefer it to fail (leaving the client the > > choice to explicitly COPY/DELETE) rather than doing something the client > > din't really want. > > Right, but did you read the part about how the server might be able to > do a much better job of the under-the-cover copy-and-delete than the > client possibly could? A client can only do operations based on its > authenticated context, whereas the server process may have more power to > change things. My first example, and it's only one of many, was that a > client may not have permission to set "creationdate" but a server > obviously can. So if the server accomplishes the MOVE by doing a > copy-and-delete behind the scenes, the server can clean up > "creationdate" so that it's the date of the original resource. However, > the client may not be allowed to set the value of "creationdate" to the > most correct value after it does a manual COPY operation. Yes. That's why the current proposal says that MOVE can use the RFC2518 semantics, while REBIND will be really atomic. Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Sat Mar 8 14:16:15 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17461 for ; Sat, 8 Mar 2003 14:16:15 -0500 (EST) Received: from frink.w3.org (localhost [127.0.0.1]) by frink.w3.org (8.12.8/8.12.8) with ESMTP id h28JHl9C002169; Sat, 8 Mar 2003 14:17:47 -0500 (EST) Received: (from lists@localhost) by frink.w3.org (8.12.8/8.12.8/Submit) id h28JHl4b002161; Sat, 8 Mar 2003 14:17:47 -0500 (EST) Resent-Date: Sat, 8 Mar 2003 14:17:47 -0500 (EST) Resent-Message-Id: <200303081917.h28JHl4b002161@frink.w3.org> Received: from tux.w3.org (IDENT:root@tux [18.29.0.27]) by frink.w3.org (8.12.8/8.12.8) with ESMTP id h28JHk9C002108 for ; Sat, 8 Mar 2003 14:17:46 -0500 (EST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by tux.w3.org (8.12.8/8.12.8) with SMTP id h28JHjrB026521 for ; Sat, 8 Mar 2003 14:17:45 -0500 Received: (qmail 28792 invoked by uid 0); 8 Mar 2003 19:17:40 -0000 Received: from pD950C246.dip.t-dialin.net (HELO lisa) (217.80.194.70) by mail.gmx.net (mp019-rz3) with SMTP; 8 Mar 2003 19:17:40 -0000 From: "Julian Reschke" To: "Lisa Dusseault" , "'Jason Crawford'" Cc: "'WebDAV'" Date: Sat, 8 Mar 2003 20:17:28 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 In-Reply-To: <067601c2e5a5$f2644fa0$bb01a8c0@xythoslap> Importance: Normal Subject: RE: Move and Delete (was: bind draft issues) X-Archived-At: http://www.w3.org/mid/JIEGINCHMLABHJBIGKBCIEDLGLAA.julian.reschke@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7452 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Lisa Dusseault > Sent: Saturday, March 08, 2003 8:07 PM > To: 'Jason Crawford' > Cc: 'WebDAV' > Subject: RE: Move and Delete (was: bind draft issues) > > > > > I second what Jason said -- based on the lack of client support for > "propertybehavior" I'd like to see a couple client implementors say they > would implement a feature which would allow them to choose, on some > servers supporting atomic MOVE/DELETE, whether to force that behavior or > not. We do. > A light-weight approach is that since some servers will be atomic and > some won't, merely define some string in a header or body in response to > OPTIONS which says "I do atomic delete always" or "I don't always do > atomic delete". Clients may or may not use that information, but at > least it's really easy for a server to advertise. I think this approach is too simple. Whether a MOVE will be atomic or not may depend on source, destination and state of resources. That isn't something I want to compute upon OPTIONS. Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Sat Mar 8 16:12:50 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09642 for ; Sat, 8 Mar 2003 16:12:50 -0500 (EST) Received: from frink.w3.org (localhost [127.0.0.1]) by frink.w3.org (8.12.8/8.12.8) with ESMTP id h28LEF9C002017; Sat, 8 Mar 2003 16:14:15 -0500 (EST) Received: (from lists@localhost) by frink.w3.org (8.12.8/8.12.8/Submit) id h28LE8Rm001999; Sat, 8 Mar 2003 16:14:08 -0500 (EST) Resent-Date: Sat, 8 Mar 2003 16:14:08 -0500 (EST) Resent-Message-Id: <200303082114.h28LE8Rm001999@frink.w3.org> Received: from tux.w3.org (IDENT:root@tux [18.29.0.27]) by frink.w3.org (8.12.8/8.12.8) with ESMTP id h28LE59C001967 for ; Sat, 8 Mar 2003 16:14:05 -0500 (EST) Received: from sunbelt.seagull.net (sunbelt.seagull.net [199.254.168.249]) by tux.w3.org (8.12.8/8.12.8) with ESMTP id h28LE5rB013382 for ; Sat, 8 Mar 2003 16:14:05 -0500 Received: (mail@localhost) by sunbelt.seagull.net (8.9.3) id NAA06437 sender nn683849@smallcue.com for w3c-dist-auth@w3.org; Sat, 8 Mar 2003 13:14:04 -0800 Received: from e4.ny.us.ibm.com (e4.ny.us.ibm.com [32.97.182.104]) by sunbelt.seagull.net (8.9.3) with ESMTP id NAA06407 sender obsfucated@us.ibm.com; Sat, 8 Mar 2003 13:14:02 -0800 Received: from northrelay04.pok.ibm.com (northrelay04.pok.ibm.com [9.56.224.206]) by e4.ny.us.ibm.com (8.12.8/8.12.2) with ESMTP id h28LDU4V080872; Sat, 8 Mar 2003 16:13:30 -0500 Received: from d01ml243.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by northrelay04.pok.ibm.com (8.12.8/NCO/VER6.5) with ESMTP id h28LDRri075678; Sat, 8 Mar 2003 16:13:28 -0500 To: "Lisa Dusseault" Cc: acl@webdav.org, "'Julian Reschke'" , "'WebDAV'" X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: Jason Crawford Date: Sat, 8 Mar 2003 16:09:27 -0500 X-MIMETrack: Serialize by Router on D01ML243/01/M/IBM(Release 6.0.1 [IBM]|March 7, 2003) at 03/08/2003 16:13:27 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Subject: Re: Atomic MOVE and move permissions X-Archived-At: http://www.w3.org/mid/OF6BCD1243.80A678BE-ON85256CE3.0072F48A@us.ibm.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7453 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: > But back to the atomic vs. non-atomic move, the permissions example was > just an example. You still have to recursively check privileges on all > descendent _collections_ if one accepts your permissions model. And you > still have to recursively check locks, etc. The basic argument for > non-atomic move was that in some situations, the server will have to > implement it as a super-user COPY-->DELETE. Again... even in situations where it has to implement it under the covers as a DELETE(dest)/COPY/DELETE(src), it can still be atomic or nearly so because it can be backed out up to and including the atomic remap. After that it's committed and the WebDAV MOVE's response's status code is not sensitive to how the subsequent cleanup goes. > Right, but did you read the part about how the server might be able to > do a much better job of the under-the-cover copy-and-delete than the > client possibly could? A client can only do operations based on its > authenticated context, whereas the server process may have more power to > change things. My first example, and it's only one of many, was that a > client may not have permission to set "creationdate" but a server > obviously can. So if the server accomplishes the MOVE by doing a > copy-and-delete behind the scenes, the server can clean up > "creationdate" so that it's the date of the original resource. However, > the client may not be allowed to set the value of "creationdate" to the > most correct value after it does a manual COPY operation. Right, if it fails, the client needs to evaluate what it was trying to achieve. It is possible that it has no acceptable recourse. Even for the atomic version, we should insure that our responses are descriptive enough that the client can understand why the MOVE or DELETE failed. ------------------------------------------ Phone: 914-784-7569, ccjason@us.ibm.com I do not check nn621779@smallcue.com From w3c-dist-auth-request@w3.org Sun Mar 9 12:18:46 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24991 for ; Sun, 9 Mar 2003 12:18:45 -0500 (EST) Received: from frink.w3.org (localhost [127.0.0.1]) by frink.w3.org (8.12.8/8.12.8) with ESMTP id h29HJt9C020831; Sun, 9 Mar 2003 12:19:55 -0500 (EST) Received: (from lists@localhost) by frink.w3.org (8.12.8/8.12.8/Submit) id h29HIpie020804; Sun, 9 Mar 2003 12:18:51 -0500 (EST) Resent-Date: Sun, 9 Mar 2003 12:18:51 -0500 (EST) Resent-Message-Id: <200303091718.h29HIpie020804@frink.w3.org> Received: from tux.w3.org (IDENT:root@tux [18.29.0.27]) by frink.w3.org (8.12.8/8.12.8) with ESMTP id h29HIl9C020768 for ; Sun, 9 Mar 2003 12:18:47 -0500 (EST) Received: from mail.xythos.com ([206.14.210.116]) by tux.w3.org (8.12.8/8.12.8) with ESMTP id h29HIlrB030074 for ; Sun, 9 Mar 2003 12:18:47 -0500 Received: from ravms by mail.xythos.com with mail-ok (Exim 3.36 #3) id 18s4Tm-000896-00; Sun, 09 Mar 2003 17:20:54 +0000 Received: from [198.144.203.248] (helo=xythoslap) by mail.xythos.com with asmtp (Exim 3.36 #3) id 18s4Tl-00088v-00; Sun, 09 Mar 2003 17:20:53 +0000 From: "Lisa Dusseault" To: "'Jason Crawford'" Cc: , "'Julian Reschke'" , "'WebDAV'" Date: Sun, 9 Mar 2003 09:18:45 -0800 Message-ID: <069c01c2e65f$f0f0f500$bb01a8c0@xythoslap> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4024 Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Old-X-Envelope-To: acl@webdav.org, julian.reschke@gmx.de, nn683849@smallcue.com, w3c-dist-auth@w3.org Subject: RE: Atomic MOVE and move permissions X-Archived-At: http://www.w3.org/mid/069c01c2e65f$f0f0f500$bb01a8c0@xythoslap Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7454 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit > > But back to the atomic vs. non-atomic move, the permissions > example was > > just an example. You still have to recursively check > privileges on all > > descendent _collections_ if one accepts your permissions > model. And you > > still have to recursively check locks, etc. The basic argument for > > non-atomic move was that in some situations, the server will have to > > implement it as a super-user COPY-->DELETE. > > Again... even in situations where it has to implement it under the > covers as a DELETE(dest)/COPY/DELETE(src), it can still be > atomic or nearly so because it can be backed out up to and including > the atomic remap. After that it's committed and the WebDAV MOVE's > response's > status code is not sensitive to how the subsequent cleanup goes. OK, now we're getting to pinpoint our different assumptions. Do you assume it's better for the server to do the atomic remap, return "success", and worry about cleanup later? That's valid for some servers, certainly. If there are "orphaned" resources, the administrator can clean them up later. However, that assumption isn't valid for all servers. For a server like Sharemation, we count each file stored against some user's quota. If a collection MOVE or DELETE fails, and we can't free up that quota, we need to let the user know so they can fix it up. It's quite possible the user will be able to fix up the operation by removing locks, getting permissions changed, or simply trying again. Finally, the server needs to consider if rollback is feasible or desirable. In theory, it would be reasonable to say that servers SHOULD succeed 100%, or failing that SHOULD rollback 100%, or only if both those fail should the server report a partial success. That's not the model WebDAV has had so far, however. So that might be a reasonable position for the bindings specification to take but I'm not sure people would support changing RFC2518 in that manner. Lisa From w3c-dist-auth-request@w3.org Sun Mar 9 12:51:08 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA00831 for ; Sun, 9 Mar 2003 12:51:08 -0500 (EST) Received: from frink.w3.org (localhost [127.0.0.1]) by frink.w3.org (8.12.8/8.12.8) with ESMTP id h29HqZ9C026426; Sun, 9 Mar 2003 12:52:35 -0500 (EST) Received: (from lists@localhost) by frink.w3.org (8.12.8/8.12.8/Submit) id h29HqXnc026408; Sun, 9 Mar 2003 12:52:33 -0500 (EST) Resent-Date: Sun, 9 Mar 2003 12:52:33 -0500 (EST) Resent-Message-Id: <200303091752.h29HqXnc026408@frink.w3.org> Received: from tux.w3.org (IDENT:root@tux [18.29.0.27]) by frink.w3.org (8.12.8/8.12.8) with ESMTP id h29HqW9C026376 for ; Sun, 9 Mar 2003 12:52:32 -0500 (EST) Received: from sunbelt.seagull.net (sunbelt.seagull.net [199.254.168.249]) by tux.w3.org (8.12.8/8.12.8) with ESMTP id h29HqVrB001977 for ; Sun, 9 Mar 2003 12:52:31 -0500 Received: (mail@localhost) by sunbelt.seagull.net (8.9.3) id JAA16425 sender nn683849@smallcue.com for w3c-dist-auth@w3.org; Sun, 9 Mar 2003 09:52:25 -0800 Received: from e5.ny.us.ibm.com (e5.ny.us.ibm.com [32.97.182.105]) by sunbelt.seagull.net (8.9.3) with ESMTP id JAA16409 sender obsfucated@us.ibm.com; Sun, 9 Mar 2003 09:52:24 -0800 Received: from northrelay04.pok.ibm.com (northrelay04.pok.ibm.com [9.56.224.206]) by e5.ny.us.ibm.com (8.12.8/8.12.2) with ESMTP id h29HprlO033490; Sun, 9 Mar 2003 12:51:53 -0500 Received: from d01ml243.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by northrelay04.pok.ibm.com (8.12.8/NCO/VER6.5) with ESMTP id h29Hppdp114410; Sun, 9 Mar 2003 12:51:51 -0500 To: Edgar@edgarschwarz.de Cc: w3c-dist-auth@w3.org X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: Jason Crawford Date: Sun, 9 Mar 2003 12:47:56 -0500 X-MIMETrack: Serialize by Router on D01ML243/01/M/IBM(Release 6.0.1 [IBM]|March 7, 2003) at 03/09/2003 12:51:51 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Subject: Re: Re (2): Move and Delete (was: bind draft issues) X-Archived-At: http://www.w3.org/mid/OFA81417CA.CC023A19-ON85256CE4.005FA280@us.ibm.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7455 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: On Saturday, 03/08/2003 at 07:25 CET, nnEdgar___at___EdgarSchwarz.de@smallcue.com wrote: > Hi, > I don't have time to follow the discussion in detail at the moment > but this post provokes a comment. > "Clemm, Geoff" wrote: > > From: Brian Korver [mailto:briank@xythos.com] > > > > Other than loops, what are the problems unique to multiple > > bindings and partial MOVE? > > > > One example was posted in the message below: > > > > From: Clemm, Geoff [gclemm@Rational.Com] > > Sent: Monday, March 03, 2003 6:34 PM > > Subject: RE: Move and Delete (was: bind draft issues) > > > > ... > > because it can cause a DELETE in one collection to cause a change > > in another collection, and this kind of "deletion side effect" > > was something we explicitly were trying to avoid. For example, > > suppose /henry/has-friend/jeff and /jim/has-friend/jeff > > were bindings to the same collection, JEFF, and JEFF has a binding > > named "wife" to a resource, MARI. Now suppose henry gets mad > > at jeff, and issues a "DELETE /henry/has-friend/jeff" request. > > But suppose at that moment someone else has a Depth:0 lock > > on the /henry/has-friend collection. The result of a "best effort" > > deletion is the removal of the "wife" binding from JEFF. That > > may be OK if you were just updating the information accessible > > from /henry (he isn't JEFF's friend anymore, and he's happy to > > purge as much information about JEFF as he can), but with multiple > > bindings, "best effort" deletion has now trashed the JEFF object > > in all the other contexts in which it is still visible (and the > > folks that still are his friends are still interested in that > > information). What Geoff describes is very very very bad. But I hope that even the folks that can't implement atomic DELETE are not considering making their incremental delete this broken. Even if you can't implement atomic delete, you still can't delete bindings that would still be accessable after you did it atomically if you could. If this prohibition is not clear from the spec, then the spec needs to be fixed. > > So we're not saying that "best effort deletion" is always a bad thing, > > but we are saying that "best effort deletion" is a bad thing when > > you care about multiple bindings to the same resource. > Goeff, I don't think your scenario is valid for our discussion. I tend to agree, but it sounds like it might be for a different reason than what I think you're saying below. (omitted) My reason is mentioned above. It basically is that I think (hope) that no server is considering doing what Geoff mentions and the non-atomic folks are only considering something more benign if they can't do the DELETE atomicly. I'm hoping that the discussion is only "that more benign behavior" vs "true atomic DELETE". ------------------------------------------ Phone: 914-784-7569, ccjason@us.ibm.com I do not check nn621779@smallcue.com From w3c-dist-auth-request@w3.org Sun Mar 9 14:10:39 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15656 for ; Sun, 9 Mar 2003 14:10:39 -0500 (EST) Received: from frink.w3.org (localhost [127.0.0.1]) by frink.w3.org (8.12.8/8.12.8) with ESMTP id h29JC19C007868; Sun, 9 Mar 2003 14:12:01 -0500 (EST) Received: (from lists@localhost) by frink.w3.org (8.12.8/8.12.8/Submit) id h29JBsVA007836; Sun, 9 Mar 2003 14:11:54 -0500 (EST) Resent-Date: Sun, 9 Mar 2003 14:11:54 -0500 (EST) Resent-Message-Id: <200303091911.h29JBsVA007836@frink.w3.org> Received: from tux.w3.org (IDENT:root@tux [18.29.0.27]) by frink.w3.org (8.12.8/8.12.8) with ESMTP id h29JBp9C007802 for ; Sun, 9 Mar 2003 14:11:51 -0500 (EST) Received: from sus-ma1it31.rational.com (sus-ma1it31.rational.com [130.213.73.33]) by tux.w3.org (8.12.8/8.12.8) with ESMTP id h29JBprB013309 for ; Sun, 9 Mar 2003 14:11:51 -0500 Received: from sus-ma1it00.rational.com ([10.64.1.25]) by 10.64.1.33 with InterScan Messaging Security Suite; Sun, 09 Mar 2003 13:55:23 -0500 Received: by sus-ma1it00.rational.com with Internet Mail Service (5.5.2656.59) id ; Sun, 9 Mar 2003 14:11:39 -0500 Message-ID: From: "Clemm, Geoff" To: "'WebDAV'" Date: Sun, 9 Mar 2003 14:11:30 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain Subject: RE: GULP vs RFC2518bis X-Archived-At: http://www.w3.org/mid/E4F2D33B98DF7E4880884B9F0E6FDEE2021C5F26@SUS-MA1IT01 Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7456 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: From: Julian Reschke [mailto:julian.reschke@gmx.de] > From: Lisa Dusseault > > Here's some initial feedback on the latest GULP. > > "An UNLOCK request deletes the lock with the specified lock token. > The request-URL of the request MUST identify a resource that > is either directly or indirectly locked by that lock. > After a lock is deleted, no resource is locked by that lock." > > Do we really want to allow an UNLOCK to an indirectly-locked > resource to remove the lock on the directly locked parent? I'd > like to know whether RFC2518 says about UNLOCK: "The UNLOCK method removes the lock identified by the lock token in the Lock-Token request header from the Request-URI, and all other resources included in the lock. If all resources which have been locked under the submitted lock token can not be unlocked then the UNLOCK request MUST fail. " So I think GULP only repeats what RFC2518 has been saying all the time (BTW: this is issue UNLOCK_WHAT_URL on the open issues list). Yes, this was just echoing what appeared to be in 2518. I'd probably go with the tighter restriction (i.e. the client must issue the UNLOCK against the URL that was specified in the LOCK request), but either one is fine with me. Since this issue is already been tracked, I suggest we handle this issue independently of GULP (the change to GULP is obvious and trivial, i.e. replace "either directly or indirectly" with just "directly"). > "A lock token is "submitted" in a request when it appears in an If > header tagged-list whose tag is the lock-root of the lock." > > This doesn't mention untagged-list syntax in If header. Is a corollary > of this proposal that we remove the untagged-list syntax? Or was the > omission of untagged-list accidental? I'd prefer to keep the untagged > list syntax, so I believe this should read: > "A lock token is "submitted" in a request when it appears in an If > header." I'd prefer "when it appears in an If header tagged-list whose tag is the lock-root of the lock, or if it appears in an untagged list and the request-URL is the lock-root of the lock". I agree this change should be made, and I prefer Julian's rewording, as it is more precise. I'll post a new version of GULP with this change. > Then this paragraph, with the substitution to "internal member" > made as Julian suggested... > > "If a request would modify the content for a locked resource, a > dead property of a locked resource, a live property that is > defined to be lockable for a locked resource, or a member URL > in a locked collection, the request MUST fail unless the > lock-token for that lock is submitted in the request." > > Being picky here, this sentence is conditional on a request > modifying "a member URL" in a locked collection. Isn't it any > modifications to the internal member, not just the URL? > E.g. this definition must encompass a PUT to a indirectly locked > internal member, as well as a MOVE. No. The *shallow* lock on a collection locks it's member URLs. If the lock on the collection isn't deep, you can modify internal members without the lock token, as long as you don't change their name (affecting the state of the collection itself). Julian is correct. If the lock is deep, then the first phrase of of this section handles the lock on the content of the member resource. Cheers, Geoff From w3c-dist-auth-request@w3.org Sun Mar 9 14:25:07 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18206 for ; Sun, 9 Mar 2003 14:25:07 -0500 (EST) Received: from frink.w3.org (localhost [127.0.0.1]) by frink.w3.org (8.12.8/8.12.8) with ESMTP id h29JQd9C009602; Sun, 9 Mar 2003 14:26:39 -0500 (EST) Received: (from lists@localhost) by frink.w3.org (8.12.8/8.12.8/Submit) id h29JQbGx009583; Sun, 9 Mar 2003 14:26:37 -0500 (EST) Resent-Date: Sun, 9 Mar 2003 14:26:37 -0500 (EST) Resent-Message-Id: <200303091926.h29JQbGx009583@frink.w3.org> Received: from tux.w3.org (IDENT:root@tux [18.29.0.27]) by frink.w3.org (8.12.8/8.12.8) with ESMTP id h29JQa9C009551 for ; Sun, 9 Mar 2003 14:26:36 -0500 (EST) Received: from sus-ma1it31.rational.com (sus-ma1it31.rational.com [130.213.73.33]) by tux.w3.org (8.12.8/8.12.8) with ESMTP id h29JQarB015557 for ; Sun, 9 Mar 2003 14:26:36 -0500 Received: from sus-ma1it00.rational.com ([10.64.1.25]) by 10.64.1.33 with InterScan Messaging Security Suite; Sun, 09 Mar 2003 14:10:14 -0500 Received: by sus-ma1it00.rational.com with Internet Mail Service (5.5.2656.59) id ; Sun, 9 Mar 2003 14:26:30 -0500 Message-ID: From: "Clemm, Geoff" To: "'WebDAV'" Date: Sun, 9 Mar 2003 14:26:22 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain Subject: GULP (version 5.3) X-Archived-At: http://www.w3.org/mid/E4F2D33B98DF7E4880884B9F0E6FDEE2021C5F27@SUS-MA1IT01 Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7457 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: The changes from version 5.2 are: - replacing the term "binding" with the term "internal member URI", and - handling untagged-list If headers. This handles all issues raised so far with adding GULP to 2518bis (except for the UNLOCK_WHAT_URL which will be pursued independently). Cheers, Geoff -------------- - A lock either directly or indirectly locks a resource. - A LOCK request creates a new lock, and the resource identified by the request-URL is directly locked by that lock. The "lock-root" of the new lock is the request-URL. If at the time of the request, the request-URL is not mapped to a resource, a new resource with no content MUST be created by the request. - If a collection is directly locked by a depth:infinity lock, all members of that collection (other than the collection itself) are indirectly locked by that lock. In particular, if an internal member resource is added to a collection that is locked by a depth:infinity lock, and if the resource is not locked by that lock, then the resource becomes indirectly locked by that lock. Conversely, if a resource is indirectly locked with a depth:infinity lock, and if the result of deleting an internal member URI is that the resource is no longer a member of the collection that is directly locked by that lock, then the resource is no longer locked by that lock. - An UNLOCK request deletes the lock with the specified lock token. The request-URL of the request MUST identify a resource that is either directly or indirectly locked by that lock. After a lock is deleted, no resource is locked by that lock. - A lock token is "submitted" in a request when it appears in an If header tagged-list whose tag is the lock-root of the lock, or when it appears in an untagged list and the request-URL is the lock-root of the lock. - If a request would modify the content for a locked resource, a dead property of a locked resource, a live property that is defined to be lockable for a locked resource, or an internal member URI of a locked collection, the request MUST fail unless the lock-token for that lock is submitted in the request. - If a request causes a directly locked resource to no longer be mapped to the lock-root of that lock, then the request MUST fail unless the lock-token for that lock is submitted in the request. If the request succeeds, then that lock MUST have been deleted by that request. - If a request would cause a resource to be locked by two different exclusive locks, the request MUST fail. -------------- From w3c-dist-auth-request@w3.org Sun Mar 9 15:07:27 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26018 for ; Sun, 9 Mar 2003 15:07:22 -0500 (EST) Received: from frink.w3.org (localhost [127.0.0.1]) by frink.w3.org (8.12.8/8.12.8) with ESMTP id h29K8n9C018476; Sun, 9 Mar 2003 15:08:49 -0500 (EST) Received: (from lists@localhost) by frink.w3.org (8.12.8/8.12.8/Submit) id h29K8eEX018462; Sun, 9 Mar 2003 15:08:40 -0500 (EST) Resent-Date: Sun, 9 Mar 2003 15:08:40 -0500 (EST) Resent-Message-Id: <200303092008.h29K8eEX018462@frink.w3.org> Received: from tux.w3.org (IDENT:root@tux [18.29.0.27]) by frink.w3.org (8.12.8/8.12.8) with ESMTP id h29K8c9C018426 for ; Sun, 9 Mar 2003 15:08:38 -0500 (EST) Received: from sus-ma1it31.rational.com (sus-ma1it31.rational.com [130.213.73.33]) by tux.w3.org (8.12.8/8.12.8) with ESMTP id h29K8crB022568 for ; Sun, 9 Mar 2003 15:08:38 -0500 Received: from sus-ma1it00.rational.com ([10.64.1.25]) by 10.64.1.33 with InterScan Messaging Security Suite; Sun, 09 Mar 2003 14:52:16 -0500 Received: by sus-ma1it00.rational.com with Internet Mail Service (5.5.2656.59) id ; Sun, 9 Mar 2003 15:08:33 -0500 Message-ID: From: "Clemm, Geoff" To: "'WebDAV'" Date: Sun, 9 Mar 2003 15:08:30 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain Subject: GULP (version 5.4) X-Archived-At: http://www.w3.org/mid/E4F2D33B98DF7E4880884B9F0E6FDEE2021C5F28@SUS-MA1IT01 Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7458 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: It occurs to me that the meaning of "modifying an internal member URI of a collection" might be unclear. So I suggest we add the explanation: "An internal member URI of a collection is considered to be modified if it is added, removed, or identifies a different resource." Here's a modified version of GULP with that addition. Cheers, Geoff -------------- - A lock either directly or indirectly locks a resource. - A LOCK request creates a new lock, and the resource identified by the request-URL is directly locked by that lock. The "lock-root" of the new lock is the request-URL. If at the time of the request, the request-URL is not mapped to a resource, a new resource with no content MUST be created by the request. - If a collection is directly locked by a depth:infinity lock, all members of that collection (other than the collection itself) are indirectly locked by that lock. In particular, if an internal member resource is added to a collection that is locked by a depth:infinity lock, and if the resource is not locked by that lock, then the resource becomes indirectly locked by that lock. Conversely, if a resource is indirectly locked with a depth:infinity lock, and if the result of deleting an internal member URI is that the resource is no longer a member of the collection that is directly locked by that lock, then the resource is no longer locked by that lock. - An UNLOCK request deletes the lock with the specified lock token. The request-URL of the request MUST identify a resource that is either directly or indirectly locked by that lock. After a lock is deleted, no resource is locked by that lock. - A lock token is "submitted" in a request when it appears in an If header tagged-list whose tag is the lock-root of the lock, or when it appears in an untagged list and the request-URL is the lock-root of the lock. - If a request would modify the content for a locked resource, a dead property of a locked resource, a live property that is defined to be lockable for a locked resource, or an internal member URI of a locked collection, the request MUST fail unless the lock-token for that lock is submitted in the request. An internal member URI of a collection is considered to be modified if it is added, removed, or identifies a different resource. - If a request causes a directly locked resource to no longer be mapped to the lock-root of that lock, then the request MUST fail unless the lock-token for that lock is submitted in the request. If the request succeeds, then that lock MUST have been deleted by that request. - If a request would cause a resource to be locked by two different exclusive locks, the request MUST fail. -------------- From w3c-dist-auth-request@w3.org Mon Mar 10 01:29:44 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA17097 for ; Mon, 10 Mar 2003 01:29:43 -0500 (EST) Received: from frink.w3.org (localhost [127.0.0.1]) by frink.w3.org (8.12.8/8.12.8) with ESMTP id h2A6V79C000714; Mon, 10 Mar 2003 01:31:07 -0500 (EST) Received: (from lists@localhost) by frink.w3.org (8.12.8/8.12.8/Submit) id h2A6Ux0E000701; Mon, 10 Mar 2003 01:30:59 -0500 (EST) Resent-Date: Mon, 10 Mar 2003 01:30:59 -0500 (EST) Resent-Message-Id: <200303100630.h2A6Ux0E000701@frink.w3.org> Received: from tux.w3.org (IDENT:root@tux [18.29.0.27]) by frink.w3.org (8.12.8/8.12.8) with ESMTP id h2A6Uk9C000665 for ; Mon, 10 Mar 2003 01:30:46 -0500 (EST) Received: from sunbelt.seagull.net (sunbelt.seagull.net [199.254.168.249]) by tux.w3.org (8.12.8/8.12.8) with ESMTP id h2A6UjrB006333 for ; Mon, 10 Mar 2003 01:30:46 -0500 Received: (mail@localhost) by sunbelt.seagull.net (8.9.3) id WAA31286 sender nn683849@smallcue.com for w3c-dist-auth@w3.org; Sun, 9 Mar 2003 22:30:45 -0800 Received: from e1.ny.us.ibm.com (e1.ny.us.ibm.com [32.97.182.101]) by sunbelt.seagull.net (8.9.3) with ESMTP id WAA31256 sender obsfucated@us.ibm.com; Sun, 9 Mar 2003 22:30:42 -0800 Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.56.224.150]) by e1.ny.us.ibm.com (8.12.8/8.12.2) with ESMTP id h2A6UBW8087272; Mon, 10 Mar 2003 01:30:11 -0500 Received: from d01ml243.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by northrelay02.pok.ibm.com (8.12.8/NCO/VER6.5) with ESMTP id h2A6U9dU125386; Mon, 10 Mar 2003 01:30:09 -0500 To: "Lisa Dusseault" Cc: acl@webdav.org, "'Julian Reschke'" , "'WebDAV'" X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: Jason Crawford Date: Mon, 10 Mar 2003 01:25:10 -0500 X-MIMETrack: Serialize by Router on D01ML243/01/M/IBM(Release 6.0.1 [IBM]|March 7, 2003) at 03/10/2003 01:30:09 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Subject: RE: Atomic MOVE and move permissions X-Archived-At: http://www.w3.org/mid/OFCA6511B8.44E8BE34-ON85256CE4.006210AD@us.ibm.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7459 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: On Sunday, 03/09/2003 at 09:18 PST, "Lisa Dusseault" wrote: > > > But back to the atomic vs. non-atomic move, the permissions > > example was > > > just an example. You still have to recursively check > > privileges on all > > > descendent _collections_ if one accepts your permissions > > model. And you > > > still have to recursively check locks, etc. The basic argument for > > > non-atomic move was that in some situations, the server will have to > > > implement it as a super-user COPY-->DELETE. > > > > Again... even in situations where it has to implement it under the > > covers as a DELETE(dest)/COPY/DELETE(src), it can still be > > atomic or nearly so because it can be backed out up to and including > > the atomic remap. After that it's committed and the WebDAV MOVE's > > response's > > status code is not sensitive to how the subsequent cleanup goes. > > OK, now we're getting to pinpoint our different assumptions. Do you > assume it's better for the server to do the atomic remap, return > "success", and worry about cleanup later? Yes/No. It's an option that I find appealing since it lets the protocol stay away from allocation issues which are invisible at the 2518 level. But I will concede that not all servers can do that. For those servers, I'm saying that you put the resources in the destination storage system (if necessary) and can get to the point where you've confirmed that all the problems that might go wrong are eliminated and that you can now commit the operation. Everything is ready to be remapped from a WebDAV perspective. If a given server really has to do a reclamation check at source and dest, it can be done next, immediately before the commit/remap. After that, the actual irreversible reclamation can occur. > That's valid for some > servers, certainly. If there are "orphaned" resources, the administrator > can clean them up later. And perhaps users can also use something like a trash can. Allocated and inaccessable resources are already put in trash cans in many OS's. It is a familiar enough concept to most users. But even if you can't do the trash can, I'd hope that you could do the reclamation check I mentioned above. If your server needs to do that check, you'd have to do later anyway, so do it just before the commit instead. > However, that assumption isn't valid for all servers. For a server like > Sharemation, we count each file stored against some user's quota. If a > collection MOVE or DELETE fails, and we can't free up that quota, we > need to let the user know so they can fix it up. It's quite possible > the user will be able to fix up the operation by removing locks, getting > permissions changed, or simply trying again. Yup. Atomic or not, we do need to make sure that we provide reasonably descriptive response codes so that the client can figure out why the operation failed or was only partially completed. > Finally, the server needs to consider if rollback is feasible or > desirable. In theory, it would be reasonable to say that servers SHOULD > succeed 100%, or failing that SHOULD rollback 100%, or only if both > those fail should the server report a partial success. That's not the > model WebDAV has had so far, however. So that might be a reasonable > position for the bindings specification to take but I'm not sure people > would support changing RFC2518 in that manner. Right. I don't think anyone is going to say that servers MUST act atomically. It's too difficult to know with certainty that there is no situation where it's necessary to leave the implemented DELETE half finished. We might still invent one. But because I'm afraid server vendors will be quick to decide that they can't support atomic DELETE, I have a tendency to speak up to point out options they seem to have to allow them to support it. From w3c-dist-auth-request@w3.org Mon Mar 10 02:00:43 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA23406 for ; Mon, 10 Mar 2003 02:00:43 -0500 (EST) Received: from frink.w3.org (localhost [127.0.0.1]) by frink.w3.org (8.12.8/8.12.8) with ESMTP id h2A71J9C002625; Mon, 10 Mar 2003 02:01:19 -0500 (EST) Received: (from lists@localhost) by frink.w3.org (8.12.8/8.12.8/Submit) id h2A71Hj4002613; Mon, 10 Mar 2003 02:01:17 -0500 (EST) Resent-Date: Mon, 10 Mar 2003 02:01:17 -0500 (EST) Resent-Message-Id: <200303100701.h2A71Hj4002613@frink.w3.org> Received: from tux.w3.org (IDENT:root@tux [18.29.0.27]) by frink.w3.org (8.12.8/8.12.8) with ESMTP id h2A71C9C002581 for ; Mon, 10 Mar 2003 02:01:12 -0500 (EST) Received: from sunbelt.seagull.net (sunbelt.seagull.net [199.254.168.249]) by tux.w3.org (8.12.8/8.12.8) with ESMTP id h2A71BrB009951 for ; Mon, 10 Mar 2003 02:01:12 -0500 Received: (mail@localhost) by sunbelt.seagull.net (8.9.3) id XAA32512 sender nn683849@smallcue.com for w3c-dist-auth@w3.org; Sun, 9 Mar 2003 23:01:11 -0800 Received: from e1.ny.us.ibm.com (e1.ny.us.ibm.com [32.97.182.101]) by sunbelt.seagull.net (8.9.3) with ESMTP id XAA32496 sender obsfucated@us.ibm.com; Sun, 9 Mar 2003 23:01:10 -0800 Received: from northrelay04.pok.ibm.com (northrelay04.pok.ibm.com [9.56.224.206]) by e1.ny.us.ibm.com (8.12.8/8.12.2) with ESMTP id h2A70cW8128910; Mon, 10 Mar 2003 02:00:38 -0500 Received: from d01ml243.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by northrelay04.pok.ibm.com (8.12.8/NCO/VER6.5) with ESMTP id h2A70adp022126; Mon, 10 Mar 2003 02:00:36 -0500 To: "Lisa Dusseault" Cc: "'WebDAV'" X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: Jason Crawford Date: Mon, 10 Mar 2003 01:57:58 -0500 X-MIMETrack: Serialize by Router on D01ML243/01/M/IBM(Release 6.0.1 [IBM]|March 7, 2003) at 03/10/2003 02:00:36 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Subject: MOVEs across file systems X-Archived-At: http://www.w3.org/mid/OF4E451EBE.0BE8791C-ON85256CE5.00248132@us.ibm.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7460 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: BTW... I just had an interesting thought about MOVE's across file systems. We've been talking about having to do that as a COPY/DELETE. And on occasion we've said that it truly isn't necessary to actually move the resource implementations as long as they respond at the right URL's. For the most part though, that comment has felt a bit academic to me. Anyway... the thought I just wanted to point out is that if you have a resource on one file system with multiple bindings to it, and you MOVE that resource via one of those bindings "to another file system"... you might actually want to NOT "copy/delete" it since you still also have several bindings to it from the original file system. You might *need* to keep a cross file system binding and not necessarily move implementations around during MOVE/BIND and other namespace operations. And if you're forced to support cross file system bindings, then perhaps you never really need to take the COPY/DELETE approach? Anyway... it's just a stray thought. :-) J. ------------------------------------------ Phone: 914-784-7569, ccjason@us.ibm.com I do not check nn621779@smallcue.com From w3c-dist-auth-request@w3.org Mon Mar 10 03:16:40 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA17679 for ; Mon, 10 Mar 2003 03:16:39 -0500 (EST) Received: from frink.w3.org (localhost [127.0.0.1]) by frink.w3.org (8.12.8/8.12.8) with ESMTP id h2A8Hg9C012031; Mon, 10 Mar 2003 03:17:42 -0500 (EST) Received: (from lists@localhost) by frink.w3.org (8.12.8/8.12.8/Submit) id h2A8HYaa012013; Mon, 10 Mar 2003 03:17:34 -0500 (EST) Resent-Date: Mon, 10 Mar 2003 03:17:34 -0500 (EST) Resent-Message-Id: <200303100817.h2A8HYaa012013@frink.w3.org> Received: from tux.w3.org (IDENT:root@tux [18.29.0.27]) by frink.w3.org (8.12.8/8.12.8) with ESMTP id h2A8HV9C011981 for ; Mon, 10 Mar 2003 03:17:32 -0500 (EST) Received: from mail.gmx.net (mail.gmx.net [213.165.65.60]) by tux.w3.org (8.12.8/8.12.8) with SMTP id h2A8HUrB019877 for ; Mon, 10 Mar 2003 03:17:31 -0500 Received: (qmail 22740 invoked by uid 0); 10 Mar 2003 08:17:24 -0000 Received: from pD950C266.dip.t-dialin.net (HELO lisa) (217.80.194.102) by mail.gmx.net (mp001-rz3) with SMTP; 10 Mar 2003 09:17:24 +0100 From: "Julian Reschke" To: "Jason Crawford" , "Lisa Dusseault" Cc: "'WebDAV'" Date: Mon, 10 Mar 2003 09:17:12 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 In-Reply-To: Subject: RE: MOVEs across file systems X-Archived-At: http://www.w3.org/mid/JIEGINCHMLABHJBIGKBCKEFKGLAA.julian.reschke@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7461 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Jason Crawford > Sent: Monday, March 10, 2003 7:58 AM > To: Lisa Dusseault > Cc: 'WebDAV' > Subject: MOVEs across file systems > > > > > > > BTW... I just had an interesting thought about MOVE's across file systems. > We've been talking about having to do that as a COPY/DELETE. And on occasion > we've said that it truly isn't necessary to actually move the resource > implementations as long as they respond at the right URL's. For the most > part though, that comment has felt a bit academic to me. > > Anyway... the thought I just wanted to point out is that if you have a > resource on one file system with multiple bindings to it, and you MOVE > that resource via one of those bindings "to another file system"... > you might actually want to NOT "copy/delete" it since you still also have > several bindings to it from the original file system. You might > *need* to keep a cross file system binding and not necessarily > move implementations around during MOVE/BIND and other > namespace operations. And if you're forced to support cross > file system bindings, then perhaps you never really need to take the > COPY/DELETE approach? > > Anyway... it's just a stray thought. :-) Jason, that's one of the reasons why I think we'll need REBIND in addition to MOVE, unless we can get a consensus that MOVE should indeed behave as REBIND. If you have a system that supports BIND and multiple bindings, but not across the full namespace (the common example with multiple filesystem backends, where you don't want to add an additional layer on top of the basic FS functionality). Let /a and /b represent namespace partitions that reside in different filesystem partitions. An obvious approach would be just to mirror what the filesystem backend allows -- a BIND within /a would work, while a BIND from /a to /b would fail (same for REBIND). However, a client that doesn't expect this error condition would still be able to MOVE the resource. In this case, the resource at the target URL of the MOVE request would *not* be the "same" resource anymore (it would have a different DAV:resource-id). Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Mon Mar 10 09:08:06 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22924 for ; Mon, 10 Mar 2003 09:08:06 -0500 (EST) Received: from frink.w3.org (localhost [127.0.0.1]) by frink.w3.org (8.12.8/8.12.8) with ESMTP id h2AE9Y9C015593; Mon, 10 Mar 2003 09:09:34 -0500 (EST) Received: (from lists@localhost) by frink.w3.org (8.12.8/8.12.8/Submit) id h2AE9J48015500; Mon, 10 Mar 2003 09:09:19 -0500 (EST) Resent-Date: Mon, 10 Mar 2003 09:09:19 -0500 (EST) Resent-Message-Id: <200303101409.h2AE9J48015500@frink.w3.org> Received: from tux.w3.org (IDENT:root@tux [18.29.0.27]) by frink.w3.org (8.12.8/8.12.8) with ESMTP id h2AE9F9C015416 for ; Mon, 10 Mar 2003 09:09:15 -0500 (EST) Received: from sus-ma1it31.rational.com (sus-ma1it31.rational.com [130.213.73.33]) by tux.w3.org (8.12.8/8.12.8) with ESMTP id h2AE9FrB022778 for ; Mon, 10 Mar 2003 09:09:15 -0500 Received: from sus-ma1it00.rational.com ([10.64.1.25]) by 10.64.1.33 with InterScan Messaging Security Suite; Mon, 10 Mar 2003 08:52:50 -0500 Received: by sus-ma1it00.rational.com with Internet Mail Service (5.5.2656.59) id ; Mon, 10 Mar 2003 09:09:08 -0500 Message-ID: From: "Clemm, Geoff" To: w3c-dist-auth@w3.org Date: Mon, 10 Mar 2003 09:09:03 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain Subject: RE: Re (2): Move and Delete (was: bind draft issues) X-Archived-At: http://www.w3.org/mid/E4F2D33B98DF7E4880884B9F0E6FDEE2021C5F86@SUS-MA1IT01 Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7462 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: From: Edgar@EdgarSchwarz.de [mailto:Edgar@EdgarSchwarz.de] I don't have time to follow the discussion in detail at the moment but this post provokes a comment. "Clemm, Geoff" wrote: > From: Brian Korver [mailto:briank@xythos.com] > > Other than loops, what are the problems unique to multiple > bindings and partial MOVE? > > One example was posted in the message below: > > From: Clemm, Geoff [gclemm@Rational.Com] > Sent: Monday, March 03, 2003 6:34 PM > Subject: RE: Move and Delete (was: bind draft issues) > > ... > because it can cause a DELETE in one collection to cause a change > in another collection, and this kind of "deletion side effect" > was something we explicitly were trying to avoid. For example, > suppose /henry/has-friend/jeff and /jim/has-friend/jeff > were bindings to the same collection, JEFF, and JEFF has a binding > named "wife" to a resource, MARI. Now suppose henry gets mad > at jeff, and issues a "DELETE /henry/has-friend/jeff" request. > But suppose at that moment someone else has a Depth:0 lock > on the /henry/has-friend collection. The result of a "best effort" > deletion is the removal of the "wife" binding from JEFF. That > may be OK if you were just updating the information accessible > from /henry (he isn't JEFF's friend anymore, and he's happy to > purge as much information about JEFF as he can), but with multiple > bindings, "best effort" deletion has now trashed the JEFF object > in all the other contexts in which it is still visible (and the > folks that still are his friends are still interested in that > information). > > So we're not saying that "best effort deletion" is always a bad thing, > but we are saying that "best effort deletion" is a bad thing when > you care about multiple bindings to the same resource. Geoff, I don't think your scenario is valid for our discussion. If no lock had existed then all information would have been deleted. So for the folks that still are his friends JEFF/* would be "completely" trashed. Not if DELETE were implemented as UNBIND. The only thing the DELETE would do would remove the binding named "jeff" from "/henry/has-friend". All of the bindings in JEFF would remain untouched. Since there are still other bindings to JEFF, JEFF would not be garbage-collected, and all of its bindings remain intact for use by those other bindings. Would have this have been a better or worse situation for them ? IMHO this usecase doesn't say anything about the "badness" of "best effort deletion". "Best Effort" (probably better characterized as "worst effort" :-) deletion, goes down trashing all the bindings in the collection being deleted. Whereas "unbind" deletion only affects the single binding identified in the DELETE request, and leaves the others untouched (although they could subsequently be garbage collected if that was the last binding to those resources). Either jeff gives jim and henry the rights to delete JEFF/* even if it's shared, or he doesn't allow it. It's jeffs decision. A client shouldn't have to count on locks and access control to prevent it from trashing information by mistake that it didn't intend to trash. Note that as has been pointed out, if there is at most one binding to every resource in the collection being deleted, it is fine to trash all the bindings, because that is what the garbage collector would have done anyway. So we should revise the binding protocol to say that, i.e. that DELETE should be UNBIND if their is a second binding to any resource in the collection being deleted. Cheers, Geoff From w3c-dist-auth-request@w3.org Mon Mar 10 09:13:09 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA23869 for ; Mon, 10 Mar 2003 09:13:08 -0500 (EST) Received: from frink.w3.org (localhost [127.0.0.1]) by frink.w3.org (8.12.8/8.12.8) with ESMTP id h2AE9U9C015568; Mon, 10 Mar 2003 09:09:30 -0500 (EST) Received: (from lists@localhost) by frink.w3.org (8.12.8/8.12.8/Submit) id h2AE9PqJ015544; Mon, 10 Mar 2003 09:09:25 -0500 (EST) Resent-Date: Mon, 10 Mar 2003 09:09:25 -0500 (EST) Resent-Message-Id: <200303101409.h2AE9PqJ015544@frink.w3.org> Received: from tux.w3.org (IDENT:root@tux [18.29.0.27]) by frink.w3.org (8.12.8/8.12.8) with ESMTP id h2AE9F9C015415 for ; Mon, 10 Mar 2003 09:09:15 -0500 (EST) Received: from sus-ma1it31.rational.com (sus-ma1it31.rational.com [130.213.73.33]) by tux.w3.org (8.12.8/8.12.8) with ESMTP id h2AE9FrB022779 for ; Mon, 10 Mar 2003 09:09:15 -0500 Received: from sus-ma1it00.rational.com ([10.64.1.25]) by 10.64.1.33 with InterScan Messaging Security Suite; Mon, 10 Mar 2003 08:52:50 -0500 Received: by sus-ma1it00.rational.com with Internet Mail Service (5.5.2656.59) id ; Mon, 10 Mar 2003 09:09:08 -0500 Message-ID: From: "Clemm, Geoff" To: WebDAV , "Roy T. Fielding" Date: Mon, 10 Mar 2003 09:08:59 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain Subject: RE: bind draft issues X-Archived-At: http://www.w3.org/mid/E4F2D33B98DF7E4880884B9F0E6FDEE2021C5F85@SUS-MA1IT01 Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7463 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: From: Julian Reschke [mailto:julian.reschke@gmx.de] Geoff, as RFC3253 relies on the concept of bindings, could you please attempt to fill in what *you* think an identical DAV:resource-id needs to indicate? For RFC3253, two version-controlled resources are the "same" when they have the same version history. So the obvious implementation of the DAV:resource-id property for a version-controlled resources is the DAV:version-history property. Version and Version-History resources cannot be moved, so the URL at which the were created can act as their DAV:resource-id. So this allows RFC3253 to remain neutral on the question of what does "resource identity" mean about the results of various other HTTP and WebDAV methods. Note: the question of resource identity for an activity resource is not addressed by RFC3253, so that remains an open question. Since most versioning repositories store activity resources in some kind of database, resource identity for activities ends up not being much of a problem in practice though, since there usually will be some obvious implementation property that could be used as the DAV:resource-id property. Cheers, Geoff From w3c-dist-auth-request@w3.org Mon Mar 10 09:23:23 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA25681 for ; Mon, 10 Mar 2003 09:23:23 -0500 (EST) Received: from frink.w3.org (localhost [127.0.0.1]) by frink.w3.org (8.12.8/8.12.8) with ESMTP id h2AEOe9C019880; Mon, 10 Mar 2003 09:24:40 -0500 (EST) Received: (from lists@localhost) by frink.w3.org (8.12.8/8.12.8/Submit) id h2AEOUfk019750; Mon, 10 Mar 2003 09:24:30 -0500 (EST) Resent-Date: Mon, 10 Mar 2003 09:24:30 -0500 (EST) Resent-Message-Id: <200303101424.h2AEOUfk019750@frink.w3.org> Received: from tux.w3.org (IDENT:root@tux [18.29.0.27]) by frink.w3.org (8.12.8/8.12.8) with ESMTP id h2AEOO9C019678 for ; Mon, 10 Mar 2003 09:24:24 -0500 (EST) Received: from sus-ma1it31.rational.com (sus-ma1it31.rational.com [130.213.73.33]) by tux.w3.org (8.12.8/8.12.8) with ESMTP id h2AEOOrB029365 for ; Mon, 10 Mar 2003 09:24:24 -0500 Received: from sus-ma1it00.rational.com ([10.64.1.25]) by 10.64.1.33 with InterScan Messaging Security Suite; Mon, 10 Mar 2003 09:08:00 -0500 Received: by sus-ma1it00.rational.com with Internet Mail Service (5.5.2656.59) id ; Mon, 10 Mar 2003 09:24:18 -0500 Message-ID: From: "Clemm, Geoff" To: WebDAV , "Roy T. Fielding" Date: Mon, 10 Mar 2003 09:24:15 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain Subject: RE: bind draft issues X-Archived-At: http://www.w3.org/mid/E4F2D33B98DF7E4880884B9F0E6FDEE2021C5F95@SUS-MA1IT01 Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7464 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Actually, my suggestion below that RFC3253 is neutral wrt to the meaning of "resource identity" is probably somewhat misleading. In particular, there is the underlying assumption that you can make any version of a version-controlled resource appear at the location of that version-controlled resource (e.g. with an UPDATE request). This assumption is not very compatible with an attempt to have a URL define the "variant" of a resource (e.g. the Swedish variant), since any version checked-in at the Swedish variant URL would go into the version history and then be accessible at any other version-controlled resource for that version history. In addition, wrt to PROPFIND semantics, many important use cases would be broken if PROPFIND of a live versioning property could return different values at different URL locations. So there is a basic leaning towards "content and properties are the same at all URL locations of a given resource" semantics for a versioning server (at least, for version-controlled resources). Cheers, Geoff -----Original Message----- From: Clemm, Geoff [mailto:gclemm@Rational.Com] Sent: Monday, March 10, 2003 9:09 AM To: WebDAV; Roy T. Fielding Subject: RE: bind draft issues From: Julian Reschke [mailto:julian.reschke@gmx.de] Geoff, as RFC3253 relies on the concept of bindings, could you please attempt to fill in what *you* think an identical DAV:resource-id needs to indicate? For RFC3253, two version-controlled resources are the "same" when they have the same version history. So the obvious implementation of the DAV:resource-id property for a version-controlled resources is the DAV:version-history property. Version and Version-History resources cannot be moved, so the URL at which the were created can act as their DAV:resource-id. So this allows RFC3253 to remain neutral on the question of what does "resource identity" mean about the results of various other HTTP and WebDAV methods. Note: the question of resource identity for an activity resource is not addressed by RFC3253, so that remains an open question. Since most versioning repositories store activity resources in some kind of database, resource identity for activities ends up not being much of a problem in practice though, since there usually will be some obvious implementation property that could be used as the DAV:resource-id property. Cheers, Geoff From w3c-dist-auth-request@w3.org Mon Mar 10 14:00:34 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08300 for ; Mon, 10 Mar 2003 14:00:29 -0500 (EST) Received: from frink.w3.org (localhost [127.0.0.1]) by frink.w3.org (8.12.8/8.12.8) with ESMTP id h2AJ1KZg006878; Mon, 10 Mar 2003 14:01:20 -0500 (EST) Received: (from lists@localhost) by frink.w3.org (8.12.8/8.12.8/Submit) id h2AJ0qTP006720; Mon, 10 Mar 2003 14:00:52 -0500 (EST) Resent-Date: Mon, 10 Mar 2003 14:00:52 -0500 (EST) Resent-Message-Id: <200303101900.h2AJ0qTP006720@frink.w3.org> Received: from tux.w3.org (IDENT:root@tux [18.29.0.27]) by frink.w3.org (8.12.8/8.12.8) with ESMTP id h2AJ0mZg006684 for ; Mon, 10 Mar 2003 14:00:48 -0500 (EST) Received: from sunbelt.seagull.net (sunbelt.seagull.net [199.254.168.249]) by tux.w3.org (8.12.8/8.12.8) with ESMTP id h2AJ0lrB009215 for ; Mon, 10 Mar 2003 14:00:47 -0500 Received: (mail@localhost) by sunbelt.seagull.net (8.9.3) id LAA16396 sender nn683849@smallcue.com for w3c-dist-auth@w3.org; Mon, 10 Mar 2003 11:00:40 -0800 Received: from e3.ny.us.ibm.com (e3.ny.us.ibm.com [32.97.182.103]) by sunbelt.seagull.net (8.9.3) with ESMTP id LAA16373 sender obsfucated@us.ibm.com; Mon, 10 Mar 2003 11:00:39 -0800 Received: from northrelay04.pok.ibm.com (northrelay04.pok.ibm.com [9.56.224.206]) by e3.ny.us.ibm.com (8.12.8/8.12.2) with ESMTP id h2AJ00l9193060; Mon, 10 Mar 2003 14:00:00 -0500 Received: from d01ml243.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by northrelay04.pok.ibm.com (8.12.8/NCO/VER6.5) with ESMTP id h2AIxvwZ070666; Mon, 10 Mar 2003 13:59:58 -0500 To: "Julian Reschke" Cc: "Lisa Dusseault" , "'WebDAV'" X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: Jason Crawford Date: Mon, 10 Mar 2003 13:55:29 -0500 X-MIMETrack: Serialize by Router on D01ML243/01/M/IBM(Release 6.0.1 [IBM]|March 7, 2003) at 03/10/2003 13:59:57 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Subject: RE: MOVEs across file systems X-Archived-At: http://www.w3.org/mid/OF2F2A9B2B.BC9997BA-ON85256CE5.00672B9F@us.ibm.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7465 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: > If you have a system that supports BIND and multiple bindings, but not > across the full namespace (the common example with multiple filesystem > backends, where you don't want to add an additional layer on top of the > basic FS functionality). Let /a and /b represent namespace partitions that > reside in different filesystem partitions. An obvious approach would be just > to mirror what the filesystem backend allows -- a BIND within /a would work, > while a BIND from /a to /b would fail (same for REBIND). However, a client > that doesn't expect this error condition would still be able to MOVE the > resource. I don't understand this statement. > In this case, the resource at the target URL of the MOVE request > would *not* be the "same" resource anymore (it would have a different > DAV:resource-id). We might have to accept that for the single binding cases and encourage them to do better, but if they don't support cross-file system bindings and they do a move to another file system and the source resource also has additional bindings to it from the original file system, then the request MUST be rejected. If it is not, the server can not claim to support the bind spec. ------------------------------------------ Phone: 914-784-7569, ccjason@us.ibm.com I do not check nn621779@smallcue.com From w3c-dist-auth-request@w3.org Mon Mar 10 14:19:06 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09137 for ; Mon, 10 Mar 2003 14:19:05 -0500 (EST) Received: from frink.w3.org (localhost [127.0.0.1]) by frink.w3.org (8.12.8/8.12.8) with ESMTP id h2AJKDZg012665; Mon, 10 Mar 2003 14:20:13 -0500 (EST) Received: (from lists@localhost) by frink.w3.org (8.12.8/8.12.8/Submit) id h2AJKAJQ012582; Mon, 10 Mar 2003 14:20:10 -0500 (EST) Resent-Date: Mon, 10 Mar 2003 14:20:10 -0500 (EST) Resent-Message-Id: <200303101920.h2AJKAJQ012582@frink.w3.org> Received: from tux.w3.org (IDENT:root@tux [18.29.0.27]) by frink.w3.org (8.12.8/8.12.8) with ESMTP id h2AJK3a2012095 for ; Mon, 10 Mar 2003 14:20:06 -0500 (EST) Received: from mail.gmx.net (mail.gmx.net [213.165.65.60]) by tux.w3.org (8.12.8/8.12.8) with SMTP id h2AJDNrB013826 for ; Mon, 10 Mar 2003 14:13:24 -0500 Received: (qmail 22494 invoked by uid 0); 10 Mar 2003 19:13:16 -0000 Received: from p3EE24838.dip.t-dialin.net (HELO lisa) (62.226.72.56) by mail.gmx.net (mp005-rz3) with SMTP; 10 Mar 2003 19:13:16 -0000 From: "Julian Reschke" To: "Jason Crawford" , "Julian Reschke" Cc: "Lisa Dusseault" , "'WebDAV'" Date: Mon, 10 Mar 2003 20:13:13 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 In-Reply-To: Importance: Normal Subject: RE: MOVEs across file systems X-Archived-At: http://www.w3.org/mid/JIEGINCHMLABHJBIGKBCKEHGGLAA.julian.reschke@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7466 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Jason Crawford > Sent: Monday, March 10, 2003 7:55 PM > To: Julian Reschke > Cc: Lisa Dusseault; 'WebDAV' > Subject: RE: MOVEs across file systems > > ... > > > If you have a system that supports BIND and multiple bindings, but not > > across the full namespace (the common example with multiple filesystem > > backends, where you don't want to add an additional layer on top of the > > basic FS functionality). Let /a and /b represent namespace partitions that > > reside in different filesystem partitions. An obvious approach would be just > > to mirror what the filesystem backend allows -- a BIND within /a would work, > > while a BIND from /a to /b would fail (same for REBIND). However, a client > > that doesn't expect this error condition would still be able to MOVE the resource. > I don't understand this statement. If you want me to to explain, you'll have to point me to the part you don't understand :-) Assume a Unix fs, /a and /b being on different filesystems. ln /a/a /a/b will work. ln /a/a /b/a won't. However mv /a/a /b/a will work. However the result will not be the "same" resource (it will have a different inode, and will reside in a different filesystem). > > In this case, the resource at the target URL of the MOVE request > > would *not* be the "same" resource anymore (it would have a different > > DAV:resource-id). > We might have to accept that for the single binding cases and encourage them > to do better, but if they don't > support cross-file system bindings and they do a move to another file system > and the source resource also has additional bindings to it from the original file > system, then the request MUST be rejected. If it is not, the server can not claim > to support the bind spec. Well, I think that's up to discussion. MOVE suffers from it's RFC2518 definition (COPY then DELETE). REBIND doesn't. I don't see a problem with a system supporting both (REBIND will fail for some operations, while MOVE won't). Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Mon Mar 10 14:39:14 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09912 for ; Mon, 10 Mar 2003 14:39:13 -0500 (EST) Received: from frink.w3.org (localhost [127.0.0.1]) by frink.w3.org (8.12.8/8.12.8) with ESMTP id h2AJefZg021431; Mon, 10 Mar 2003 14:40:41 -0500 (EST) Received: (from lists@localhost) by frink.w3.org (8.12.8/8.12.8/Submit) id h2AJed3Y021395; Mon, 10 Mar 2003 14:40:39 -0500 (EST) Resent-Date: Mon, 10 Mar 2003 14:40:39 -0500 (EST) Resent-Message-Id: <200303101940.h2AJed3Y021395@frink.w3.org> Received: from tux.w3.org (IDENT:root@tux [18.29.0.27]) by frink.w3.org (8.12.8/8.12.8) with ESMTP id h2AJebZg021348 for ; Mon, 10 Mar 2003 14:40:37 -0500 (EST) Received: from sus-ma1it31.rational.com (sus-ma1it31.rational.com [130.213.73.33]) by tux.w3.org (8.12.8/8.12.8) with ESMTP id h2AJebrB022043 for ; Mon, 10 Mar 2003 14:40:37 -0500 Received: from sus-ma1it00.rational.com ([10.64.1.25]) by 10.64.1.33 with InterScan Messaging Security Suite; Mon, 10 Mar 2003 14:24:12 -0500 Received: by sus-ma1it00.rational.com with Internet Mail Service (5.5.2656.59) id ; Mon, 10 Mar 2003 14:40:31 -0500 Message-ID: From: "Clemm, Geoff" To: "'WebDAV'" Date: Mon, 10 Mar 2003 14:40:19 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain Subject: RE: MOVEs across file systems X-Archived-At: http://www.w3.org/mid/E4F2D33B98DF7E4880884B9F0E6FDEE25ED6F8@SUS-MA1IT01 Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7467 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: I think the comments in the recent threads have pointed to the appropriate path forward. In particular, we can replace the SHOULD statements with stronger MUST statements that have a narrower target (SHOULD statements are pretty useless in a spec anyway, so getting rid of them is a good thing). In particular, instead of saying: "DELETE SHOULD be UNBIND if UNBIND is supported" we should say something like: "When DELETE is applied to a collection, it MUST NOT modify the membership of another collection, except when the collection being deleted is itself a member of that other collection. For example, suppose /a/b/.../x identifies a collection C, and there is a second binding to C in a collection that is not a member of /a/b, then "DELETE /a/b" MUST NOT delete the internal member named "y" from C. And instead of saying: "MOVE SHOULD be REBIND if REBIND is supported" we should say something like: "When MOVE is applied to a resource, the other bindings to that resource MUST be unaffected, and if the resource being moved is a collection, the bindings to any members of that collection MUST be unaffected. Also, if MOVE is used with Overwrite:T to delete an existing resource, the constraints specified for DELETE apply." Clearly, these constraints can be addressed by implementing DELETE as an UNBIND and MOVE as REBIND, but in those situations that are "safe" (i.e. there are not multiple bindings to the resources being moved or deleted), the "best effort" semantics allowed by 2518 can be applied. Is this an acceptable compromise? Cheers, Geoff -----Original Message----- From: Jason Crawford [mailto:nn683849@smallcue.com] > In this case, the resource at the target URL of the MOVE request > would *not* be the "same" resource anymore (it would have a > different DAV:resource-id). We might have to accept that for the single binding cases and encourage them to do better, but if they don't support cross-file system bindings and they do a move to another file system and the source resource also has additional bindings to it from the original file system, then the request MUST be rejected. If it is not, the server can not claim to support the bind spec. From w3c-dist-auth-request@w3.org Mon Mar 10 14:55:16 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10504 for ; Mon, 10 Mar 2003 14:55:16 -0500 (EST) Received: from frink.w3.org (localhost [127.0.0.1]) by frink.w3.org (8.12.8/8.12.8) with ESMTP id h2AJuUZg025783; Mon, 10 Mar 2003 14:56:30 -0500 (EST) Received: (from lists@localhost) by frink.w3.org (8.12.8/8.12.8/Submit) id h2AJuTkO025744; Mon, 10 Mar 2003 14:56:29 -0500 (EST) Resent-Date: Mon, 10 Mar 2003 14:56:29 -0500 (EST) Resent-Message-Id: <200303101956.h2AJuTkO025744@frink.w3.org> Received: from tux.w3.org (IDENT:root@tux [18.29.0.27]) by frink.w3.org (8.12.8/8.12.8) with ESMTP id h2AJuQZg025705 for ; Mon, 10 Mar 2003 14:56:26 -0500 (EST) Received: from sus-ma1it31.rational.com (sus-ma1it31.rational.com [130.213.73.33]) by tux.w3.org (8.12.8/8.12.8) with ESMTP id h2AJuQrB027141 for ; Mon, 10 Mar 2003 14:56:26 -0500 Received: from sus-ma1it00.rational.com ([10.64.1.25]) by 10.64.1.33 with InterScan Messaging Security Suite; Mon, 10 Mar 2003 14:40:02 -0500 Received: by sus-ma1it00.rational.com with Internet Mail Service (5.5.2656.59) id ; Mon, 10 Mar 2003 14:56:20 -0500 Message-ID: From: "Clemm, Geoff" To: "'WebDAV'" Date: Mon, 10 Mar 2003 14:56:16 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain Subject: RE: MOVEs across file systems X-Archived-At: http://www.w3.org/mid/E4F2D33B98DF7E4880884B9F0E6FDEE25ED6F9@SUS-MA1IT01 Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7468 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: From: Julian Reschke [mailto:julian.reschke@gmx.de] > From: Jason Crawford > We might have to accept that for the single binding cases and > encourage them to do better, but if they don't support cross-file > system bindings and they do a move to another file system and the > source resource also has additional bindings to it from the > original file system, then the request MUST be rejected. If it > is not, the server can not claim to support the bind spec. Well, I think that's up to discussion. MOVE suffers from it's RFC2518 definition (COPY then DELETE). REBIND doesn't. I don't see a problem with a system supporting both (REBIND will fail for some operations, while MOVE won't). The problem with this approach (leaving the behavior of MOVE and DELETE unconstrained in the presence of multiple bindings) is that it makes multiple bindings relatively useless, since most people will be coming at these advanced servers with legacy clients that support MOVE and DELETE, not REBIND and UNBIND. If you leave the multiple binding semantics of MOVE and DELETE undefined, these legacy clients will just trash the multiple bindings you've created. So I'm happy to limit the constraints on MOVE and DELETE to exactly what is needed to preserve the semantics of multiple bindings, but leaving them unconstrained makes the binding protocol pointless in practice. Cheers, Geoff From w3c-dist-auth-request@w3.org Mon Mar 10 14:58:31 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10592 for ; Mon, 10 Mar 2003 14:58:31 -0500 (EST) Received: from frink.w3.org (localhost [127.0.0.1]) by frink.w3.org (8.12.8/8.12.8) with ESMTP id h2AJxwZg026212; Mon, 10 Mar 2003 14:59:58 -0500 (EST) Received: (from lists@localhost) by frink.w3.org (8.12.8/8.12.8/Submit) id h2AJxsUk026185; Mon, 10 Mar 2003 14:59:54 -0500 (EST) Resent-Date: Mon, 10 Mar 2003 14:59:54 -0500 (EST) Resent-Message-Id: <200303101959.h2AJxsUk026185@frink.w3.org> Received: from tux.w3.org (IDENT:root@tux [18.29.0.27]) by frink.w3.org (8.12.8/8.12.8) with ESMTP id h2AJxrZg026153 for ; Mon, 10 Mar 2003 14:59:53 -0500 (EST) Received: from sus-ma1it31.rational.com (sus-ma1it31.rational.com [130.213.73.33]) by tux.w3.org (8.12.8/8.12.8) with ESMTP id h2AJxrrB028030 for ; Mon, 10 Mar 2003 14:59:53 -0500 Received: from sus-ma1it00.rational.com ([10.64.1.25]) by 10.64.1.33 with InterScan Messaging Security Suite; Mon, 10 Mar 2003 14:43:28 -0500 Received: by sus-ma1it00.rational.com with Internet Mail Service (5.5.2656.59) id ; Mon, 10 Mar 2003 14:59:46 -0500 Message-ID: From: "Clemm, Geoff" To: "'WebDAV'" Date: Mon, 10 Mar 2003 14:59:45 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Move and Delete (was: bind draft issues) X-Archived-At: http://www.w3.org/mid/E4F2D33B98DF7E4880884B9F0E6FDEE25ED6FA@SUS-MA1IT01 Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7469 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: The check for "is this the last binding" is not sufficient, because the multiple binding might be to a parent of the resource. In the example I gave below, the "wife" binding might be the only binding to the wife resource, but deleting it is a problem because there is another binding to JEFF. Cheers, Geoff -----Original Message----- From: Julian Reschke [mailto:julian.reschke@gmx.de] Sent: Saturday, March 08, 2003 2:35 AM To: Clemm, Geoff; 'WebDAV' Subject: RE: Move and Delete (was: bind draft issues) > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Clemm, Geoff > Sent: Saturday, March 08, 2003 3:09 AM > To: 'WebDAV' > Subject: RE: Move and Delete (was: bind draft issues) > > > > From: Brian Korver [mailto:briank@xythos.com] > > Other than loops, what are the problems unique to multiple > bindings and partial MOVE? > > One example was posted in the message below: > > From: Clemm, Geoff [gclemm@Rational.Com] > Sent: Monday, March 03, 2003 6:34 PM > Subject: RE: Move and Delete (was: bind draft issues) > > ... > because it can cause a DELETE in one collection to cause a change > in another collection, and this kind of "deletion side effect" > was something we explicitly were trying to avoid. For example, > suppose /henry/has-friend/jeff and /jim/has-friend/jeff > were bindings to the same collection, JEFF, and JEFF has a binding > named "wife" to a resource, MARI. Now suppose henry gets mad > at jeff, and issues a "DELETE /henry/has-friend/jeff" request. > But suppose at that moment someone else has a Depth:0 lock > on the /henry/has-friend collection. The result of a "best effort" > deletion is the removal of the "wife" binding from JEFF. That > may be OK if you were just updating the information accessible > from /henry (he isn't JEFF's friend anymore, and he's happy to > purge as much information about JEFF as he can), but with multiple > bindings, "best effort" deletion has now trashed the JEFF object > in all the other contexts in which it is still visible (and the > folks that still are his friends are still interested in that > information). > > So we're not saying that "best effort deletion" is always a bad thing, > but we are saying that "best effort deletion" is a bad thing when > you care about multiple bindings to the same resource. Geoff, I don't think this issue exists if a server does UNBIND when removing one of multiple bindings and non-atomic-DELETE when removing the last binding (see [1]). [1] -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Mon Mar 10 15:02:10 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10750 for ; Mon, 10 Mar 2003 15:02:06 -0500 (EST) Received: from frink.w3.org (localhost [127.0.0.1]) by frink.w3.org (8.12.8/8.12.8) with ESMTP id h2AK3LZg028267; Mon, 10 Mar 2003 15:03:21 -0500 (EST) Received: (from lists@localhost) by frink.w3.org (8.12.8/8.12.8/Submit) id h2AK3Jvn028207; Mon, 10 Mar 2003 15:03:19 -0500 (EST) Resent-Date: Mon, 10 Mar 2003 15:03:19 -0500 (EST) Resent-Message-Id: <200303102003.h2AK3Jvn028207@frink.w3.org> Received: from tux.w3.org (IDENT:root@tux [18.29.0.27]) by frink.w3.org (8.12.8/8.12.8) with ESMTP id h2AK3GZg028030 for ; Mon, 10 Mar 2003 15:03:16 -0500 (EST) Received: from mail.gmx.net (mail.gmx.net [213.165.65.60]) by tux.w3.org (8.12.8/8.12.8) with SMTP id h2AK3FrB030627 for ; Mon, 10 Mar 2003 15:03:16 -0500 Received: (qmail 7867 invoked by uid 0); 10 Mar 2003 20:03:09 -0000 Received: from p3EE24838.dip.t-dialin.net (HELO lisa) (62.226.72.56) by mail.gmx.net (mp004-rz3) with SMTP; 10 Mar 2003 20:03:09 -0000 From: "Julian Reschke" To: "Clemm, Geoff" , "'WebDAV'" Date: Mon, 10 Mar 2003 21:03:05 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 In-Reply-To: Importance: Normal Subject: RE: MOVEs across file systems X-Archived-At: http://www.w3.org/mid/JIEGINCHMLABHJBIGKBCGEHJGLAA.julian.reschke@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7470 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Clemm, Geoff > Sent: Monday, March 10, 2003 8:56 PM > To: 'WebDAV' > Subject: RE: MOVEs across file systems > > > > From: Julian Reschke [mailto:julian.reschke@gmx.de] > > > From: Jason Crawford > > > We might have to accept that for the single binding cases and > > encourage them to do better, but if they don't support cross-file > > system bindings and they do a move to another file system and the > > source resource also has additional bindings to it from the > > original file system, then the request MUST be rejected. If it > > is not, the server can not claim to support the bind spec. > > Well, I think that's up to discussion. MOVE suffers from it's > RFC2518 definition (COPY then DELETE). REBIND doesn't. I don't see > a problem with a system supporting both (REBIND will fail for some > operations, while MOVE won't). > > The problem with this approach (leaving the behavior of MOVE and > DELETE unconstrained in the presence of multiple bindings) is that it > makes multiple bindings relatively useless, since most people will be > coming at these advanced servers with legacy clients that support MOVE > and DELETE, not REBIND and UNBIND. If you leave the multiple binding > semantics of MOVE and DELETE undefined, these legacy clients will just > trash the multiple bindings you've created. > > So I'm happy to limit the constraints on MOVE and DELETE to exactly > what is needed to preserve the semantics of multiple bindings, but > leaving them unconstrained makes the binding protocol pointless in > practice. On the other hand, a system that allows a "weak" MOVE if and only if there aren't any multiple bindings seems very weird to me. So maybe we should consider make MOVE "strong" by default, and only allow the old COPY/DELETE semantics upon specific request? Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Mon Mar 10 15:06:49 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11227 for ; Mon, 10 Mar 2003 15:06:44 -0500 (EST) Received: from frink.w3.org (localhost [127.0.0.1]) by frink.w3.org (8.12.8/8.12.8) with ESMTP id h2AK7gZg001845; Mon, 10 Mar 2003 15:07:42 -0500 (EST) Received: (from lists@localhost) by frink.w3.org (8.12.8/8.12.8/Submit) id h2AK7bsv001757; Mon, 10 Mar 2003 15:07:37 -0500 (EST) Resent-Date: Mon, 10 Mar 2003 15:07:37 -0500 (EST) Resent-Message-Id: <200303102007.h2AK7bsv001757@frink.w3.org> Received: from tux.w3.org (IDENT:root@tux [18.29.0.27]) by frink.w3.org (8.12.8/8.12.8) with ESMTP id h2AK7ZZg001672 for ; Mon, 10 Mar 2003 15:07:35 -0500 (EST) Received: from sus-ma1it31.rational.com (sus-ma1it31.rational.com [130.213.73.33]) by tux.w3.org (8.12.8/8.12.8) with ESMTP id h2AK7YrB001538 for ; Mon, 10 Mar 2003 15:07:34 -0500 Received: from sus-ma1it00.rational.com ([10.64.1.25]) by 10.64.1.33 with InterScan Messaging Security Suite; Mon, 10 Mar 2003 14:51:10 -0500 Received: by sus-ma1it00.rational.com with Internet Mail Service (5.5.2656.59) id ; Mon, 10 Mar 2003 15:07:29 -0500 Message-ID: From: "Clemm, Geoff" To: "'WebDAV'" Date: Mon, 10 Mar 2003 15:07:21 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain Subject: RE: Move and Delete (was: bind draft issues) X-Archived-At: http://www.w3.org/mid/E4F2D33B98DF7E4880884B9F0E6FDEE25ED6FB@SUS-MA1IT01 Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7471 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: This language is moving in the right direction, but it doesn't handle the case where the additional binding is to a parent of the resource being considered for "best effort" delete. In this case, even if this is the only binding to the resource, deleting it as part of the "best effort" delete would have a side effect of also deleting it as a member of the other collection, which violates the desired semantics of multiple bindings. Cheers, Geoff -----Original Message----- From: Lisa Dusseault [mailto:lisa@xythos.com] Sent: Saturday, March 08, 2003 1:44 PM To: 'Clemm, Geoff'; 'WebDAV' Subject: RE: Move and Delete (was: bind draft issues) What about this model with respect to DELETE and bindings? Rough specification-like language follows... --- When a client issues a DELETE request to a collection that has internal bindings, the preferred server behavior is naturally to achieve a complete success, whenever possible. However, servers may behave differently depending on what bindings exist in the rest of the system. The collection being deleted may contain the last bindings to one or more resources. When the last binding to a resource is deleted, the server may be implemented to perform some cleanup (e.g. release tied-up storage resources). If the server is unable to complete its cleanup, the server MAY do an incomplete recursive delete operation, leaving some resources behind. The server MAY leave parent collections of undeletable bindings/resources in place in order to preserve a consistent URL namespace -- this is equivalent to the behavior specified in RFC2518 [section ref]. The benefit of maintaining a consistent namespace, to a server implementation, is that orphaned resources remain findable by clients, so that clients can take actions like changing permissions or removing locks and finish their DELETE operation. In case of a partial DELETE success, the server MUST report individual undeleted bindings/resources, URL by URL, using the multi-status response body. At the other extreme, a DELETE request to a collection may be as simple as an atomic unbind, which is clearly preferable because to the client's point of view this is a complete success. --- Lisa > -----Original Message----- > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org] On Behalf Of Clemm, Geoff > Sent: Friday, March 07, 2003 6:09 PM > To: 'WebDAV' > Subject: RE: Move and Delete (was: bind draft issues) > > > > From: Brian Korver [mailto:briank@xythos.com] > > Other than loops, what are the problems unique to multiple > bindings and partial MOVE? > > One example was posted in the message below: > > From: Clemm, Geoff [gclemm@Rational.Com] > Sent: Monday, March 03, 2003 6:34 PM > Subject: RE: Move and Delete (was: bind draft issues) > > ... > because it can cause a DELETE in one collection to cause a change > in another collection, and this kind of "deletion side effect" > was something we explicitly were trying to avoid. For example, > suppose /henry/has-friend/jeff and /jim/has-friend/jeff > were bindings to the same collection, JEFF, and JEFF has a binding > named "wife" to a resource, MARI. Now suppose henry gets mad > at jeff, and issues a "DELETE /henry/has-friend/jeff" request. > But suppose at that moment someone else has a Depth:0 lock > on the /henry/has-friend collection. The result of a "best effort" > deletion is the removal of the "wife" binding from JEFF. That > may be OK if you were just updating the information accessible > from /henry (he isn't JEFF's friend anymore, and he's happy to > purge as much information about JEFF as he can), but with multiple > bindings, "best effort" deletion has now trashed the JEFF object > in all the other contexts in which it is still visible (and the > folks that still are his friends are still interested in that > information). > > So we're not saying that "best effort deletion" is always > a bad thing, > but we are saying that "best effort deletion" is a bad thing when > you care about multiple bindings to the same resource. > > From w3c-dist-auth-request@w3.org Mon Mar 10 15:23:21 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12236 for ; Mon, 10 Mar 2003 15:23:20 -0500 (EST) Received: from frink.w3.org (localhost [127.0.0.1]) by frink.w3.org (8.12.8/8.12.8) with ESMTP id h2AKHIZg011942; Mon, 10 Mar 2003 15:17:18 -0500 (EST) Received: (from lists@localhost) by frink.w3.org (8.12.8/8.12.8/Submit) id h2AKHF3W011813; Mon, 10 Mar 2003 15:17:15 -0500 (EST) Resent-Date: Mon, 10 Mar 2003 15:17:15 -0500 (EST) Resent-Message-Id: <200303102017.h2AKHF3W011813@frink.w3.org> Received: from tux.w3.org (IDENT:root@tux [18.29.0.27]) by frink.w3.org (8.12.8/8.12.8) with ESMTP id h2AKH8Zg011526 for ; Mon, 10 Mar 2003 15:17:08 -0500 (EST) Received: from sunbelt.seagull.net (sunbelt.seagull.net [199.254.168.249]) by tux.w3.org (8.12.8/8.12.8) with ESMTP id h2AKH7rB008930 for ; Mon, 10 Mar 2003 15:17:07 -0500 Received: (mail@localhost) by sunbelt.seagull.net (8.9.3) id MAA23139 sender nn683849@smallcue.com for w3c-dist-auth@w3.org; Mon, 10 Mar 2003 12:17:06 -0800 Received: from e4.ny.us.ibm.com (e4.ny.us.ibm.com [32.97.182.104]) by sunbelt.seagull.net (8.9.3) with ESMTP id MAA23116 sender obsfucated@us.ibm.com; Mon, 10 Mar 2003 12:17:04 -0800 Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.56.224.150]) by e4.ny.us.ibm.com (8.12.8/8.12.2) with ESMTP id h2AKGW4V164466; Mon, 10 Mar 2003 15:16:32 -0500 Received: from d01ml243.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by northrelay02.pok.ibm.com (8.12.8/NCO/VER6.5) with ESMTP id h2AKGT2q137902; Mon, 10 Mar 2003 15:16:29 -0500 To: "Julian Reschke" Cc: "Julian Reschke" , "Lisa Dusseault" , "'WebDAV'" X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: Jason Crawford Date: Mon, 10 Mar 2003 15:15:34 -0500 X-MIMETrack: Serialize by Router on D01ML243/01/M/IBM(Release 6.0.1 [IBM]|March 7, 2003) at 03/10/2003 15:16:28 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Subject: RE: MOVEs across file systems X-Archived-At: http://www.w3.org/mid/OF2657A6F4.8DED614D-ON85256CE5.006D227E@us.ibm.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7472 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: > If you want me to to explain, you'll have to point me to the part you don't > understand :-) > > Assume a Unix fs, /a and /b being on different filesystems. > > ln /a/a /a/b > > will work. > > ln /a/a /b/a > > won't. > > However > > mv /a/a /b/a > > will work. However the result will not be the "same" resource (it will have > a different inode, and will reside in a different filesystem). Thanks. That; explains it for me. Although not ideal since you said it would change resource ID's and we know it might not "fully complete", that is probably acceptable if there are no resources with two bindings to them being moved. And even that's fine if the diamonds are totally internal to the moved subtree. As mentioned though, it is not acceptable if it breaks bindings that are not even part of the subtree being MOVE'd. This is not something a client can recover from. > > > In this case, the resource at the target URL of the MOVE request > > > would *not* be the "same" resource anymore (it would have a different > > > DAV:resource-id). > > We might have to accept that for the single binding cases and encourage > > them to do better, but if they don't > > support cross-file system bindings and they do a move to another file > > system and the source resource also has additional bindings to it from the > > original file system, then the request MUST be rejected. If it is not, the > > server can not claim to support the bind spec. > > Well, I think that's up to discussion. MOVE suffers from it's RFC2518 > definition (COPY then DELETE). REBIND doesn't. I don't see a problem with a > system supporting both (REBIND will fail for some operations, while MOVE > won't). :-) Have we scared everyone away from this discussion yet? Okay folks, jump right in. :-) From w3c-dist-auth-request@w3.org Mon Mar 10 15:24:29 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12307 for ; Mon, 10 Mar 2003 15:24:28 -0500 (EST) Received: from frink.w3.org (localhost [127.0.0.1]) by frink.w3.org (8.12.8/8.12.8) with ESMTP id h2AKINZg012883; Mon, 10 Mar 2003 15:18:23 -0500 (EST) Received: (from lists@localhost) by frink.w3.org (8.12.8/8.12.8/Submit) id h2AKILeT012854; Mon, 10 Mar 2003 15:18:21 -0500 (EST) Resent-Date: Mon, 10 Mar 2003 15:18:21 -0500 (EST) Resent-Message-Id: <200303102018.h2AKILeT012854@frink.w3.org> Received: from tux.w3.org (IDENT:root@tux [18.29.0.27]) by frink.w3.org (8.12.8/8.12.8) with ESMTP id h2AKIKZg012822 for ; Mon, 10 Mar 2003 15:18:20 -0500 (EST) Received: from sus-ma1it31.rational.com (sus-ma1it31.rational.com [130.213.73.33]) by tux.w3.org (8.12.8/8.12.8) with ESMTP id h2AKIKrB009868 for ; Mon, 10 Mar 2003 15:18:20 -0500 Received: from sus-ma1it00.rational.com ([10.64.1.25]) by 10.64.1.33 with InterScan Messaging Security Suite; Mon, 10 Mar 2003 15:01:55 -0500 Received: by sus-ma1it00.rational.com with Internet Mail Service (5.5.2656.59) id ; Mon, 10 Mar 2003 15:18:14 -0500 Message-ID: From: "Clemm, Geoff" To: "'WebDAV'" Date: Mon, 10 Mar 2003 15:18:11 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain; charset="iso-8859-1" Subject: RE: MOVEs across file systems X-Archived-At: http://www.w3.org/mid/E4F2D33B98DF7E4880884B9F0E6FDEE25ED6FC@SUS-MA1IT01 Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7473 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: That would be fine with me as well. Just to be clear, this means the binding spec would state: A server that supports BIND MUST implement MOVE/DELETE with rebind/unbind semantics. We will also define a parameter to MOVE/DELETE that allows a user to explicitly request the "best effort" style processing (that is OK because the user is explicitly stating that trashing multiple binding semantics is what they want). Cheers, Geoff -----Original Message----- From: Julian Reschke [mailto:julian.reschke@gmx.de] > From: Clemm, Geoff > So I'm happy to limit the constraints on MOVE and DELETE to exactly > what is needed to preserve the semantics of multiple bindings, but > leaving them unconstrained makes the binding protocol pointless in > practice. On the other hand, a system that allows a "weak" MOVE if and only if there aren't any multiple bindings seems very weird to me. So maybe we should consider make MOVE "strong" by default, and only allow the old COPY/DELETE semantics upon specific request? From w3c-dist-auth-request@w3.org Tue Mar 11 08:47:45 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA19188 for ; Tue, 11 Mar 2003 08:47:44 -0500 (EST) Received: from frink.w3.org (localhost [127.0.0.1]) by frink.w3.org (8.12.8/8.12.8) with ESMTP id h2BDnHZg017783; Tue, 11 Mar 2003 08:49:17 -0500 (EST) Received: (from lists@localhost) by frink.w3.org (8.12.8/8.12.8/Submit) id h2BDnBWC017743; Tue, 11 Mar 2003 08:49:11 -0500 (EST) Resent-Date: Tue, 11 Mar 2003 08:49:11 -0500 (EST) Resent-Message-Id: <200303111349.h2BDnBWC017743@frink.w3.org> Received: from tux.w3.org (IDENT:root@tux [18.29.0.27]) by frink.w3.org (8.12.8/8.12.8) with ESMTP id h2BDn6Zg017689 for ; Tue, 11 Mar 2003 08:49:06 -0500 (EST) Received: from matrixmail.matrixone.net (mail.matrix-one.com [4.17.165.4]) by tux.w3.org (8.12.8/8.12.8) with ESMTP id h2BDn4rB026277 for ; Tue, 11 Mar 2003 08:49:05 -0500 Received: from msx2am.matrixone.net by matrixmail.matrixone.net (8.10.1/8.10.1) with ESMTP id h2BDmZf25263; Tue, 11 Mar 2003 08:48:35 -0500 (EST) Received: by msx2am.matrixone.net with Internet Mail Service (5.5.2653.19) id ; Tue, 11 Mar 2003 08:48:34 -0500 Message-ID: <9150DCE0CCB4D411A7DB00508BB0DBF2052084ED@msx1am.matrixone.net> From: "Dyer, Kevin" To: "'Clemm, Geoff'" , "'WebDAV'" Date: Tue, 11 Mar 2003 08:48:31 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2E7D4.E6F25780" Subject: RE: MOVEs across file systems X-Archived-At: http://www.w3.org/mid/9150DCE0CCB4D411A7DB00508BB0DBF2052084ED@msx1am.matrixone.net Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7474 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C2E7D4.E6F25780 Content-Type: text/plain; charset="iso-8859-1" Just putting in my 0.02 Galactic credits to make sure we keep in mind that some implementations will not be limited by a file system paradigm as the underlying engines will provide an abstraction to the actual source data. These systems use meta-data as the pointer to the actual source data which can exist on completely different servers and file systems. So moving data across a resources is as easy as creating a DB relationship. The actual source data is not moved and the system retains one version of the truth. Kevin >-----Original Message----- >From: Clemm, Geoff [mailto:gclemm@rational.com] >Sent: Monday, March 10, 2003 3:18 PM >To: 'WebDAV' >Subject: RE: MOVEs across file systems > > > >That would be fine with me as well. > >Just to be clear, this means the binding spec would state: > >A server that supports BIND MUST implement MOVE/DELETE with >rebind/unbind semantics. We will also define a parameter to >MOVE/DELETE that allows a user to explicitly request the >"best effort" style processing (that is OK because the user is >explicitly stating that trashing multiple binding semantics is >what they want). > >Cheers, >Geoff > ------_=_NextPart_001_01C2E7D4.E6F25780 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: MOVEs across file systems

Just putting in my 0.02 Galactic credits to make sure = we keep in mind that some implementations will not be limited by a file = system paradigm as the underlying engines will provide an abstraction = to the actual source data. These systems use meta-data as the pointer = to the actual source data which can exist on completely different = servers and file systems. So moving data across a resources is as easy = as creating a DB relationship. The actual source data is not moved and = the system retains one version of the truth.

Kevin

  >-----Original Message-----
  >From: Clemm, Geoff [mailto:gclemm@rational.com]
  >Sent: Monday, March 10, 2003 3:18 = PM
  >To: 'WebDAV'
  >Subject: RE: MOVEs across file = systems
  >
  >
  >
  >That would be fine with me as = well.
  >
  >Just to be clear, this means the binding = spec would state:
  >
  >A server that supports BIND MUST = implement MOVE/DELETE with
  >rebind/unbind semantics.  We will = also define a parameter to
  >MOVE/DELETE that allows a user to = explicitly request the
  >"best effort" style processing = (that is OK because the user is
  >explicitly stating that trashing multiple = binding semantics is
  >what they want).
  >
  >Cheers,
  >Geoff
  >

------_=_NextPart_001_01C2E7D4.E6F25780-- From w3c-dist-auth-request@w3.org Tue Mar 11 09:24:31 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20388 for ; Tue, 11 Mar 2003 09:24:31 -0500 (EST) Received: from frink.w3.org (localhost [127.0.0.1]) by frink.w3.org (8.12.8/8.12.8) with ESMTP id h2BEQ5Zg027059; Tue, 11 Mar 2003 09:26:05 -0500 (EST) Received: (from lists@localhost) by frink.w3.org (8.12.8/8.12.8/Submit) id h2BEQ4Na027035; Tue, 11 Mar 2003 09:26:04 -0500 (EST) Resent-Date: Tue, 11 Mar 2003 09:26:04 -0500 (EST) Resent-Message-Id: <200303111426.h2BEQ4Na027035@frink.w3.org> Received: from tux.w3.org (IDENT:root@tux [18.29.0.27]) by frink.w3.org (8.12.8/8.12.8) with ESMTP id h2BEQ1Zg027003 for ; Tue, 11 Mar 2003 09:26:01 -0500 (EST) Received: from sus-ma1it31.rational.com (sus-ma1it31.rational.com [130.213.73.33]) by tux.w3.org (8.12.8/8.12.8) with ESMTP id h2BEQ1rB004463 for ; Tue, 11 Mar 2003 09:26:01 -0500 Received: from sus-ma1it00.rational.com ([10.64.1.25]) by 10.64.1.33 with InterScan Messaging Security Suite; Tue, 11 Mar 2003 09:09:35 -0500 Received: by sus-ma1it00.rational.com with Internet Mail Service (5.5.2656.59) id ; Tue, 11 Mar 2003 09:25:55 -0500 Message-ID: From: "Clemm, Geoff" To: "'WebDAV'" Date: Tue, 11 Mar 2003 09:25:55 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain; charset="iso-8859-1" Subject: RE: MOVEs across file systems X-Archived-At: http://www.w3.org/mid/E4F2D33B98DF7E4880884B9F0E6FDEE2021C6161@SUS-MA1IT01 Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7475 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Yes, one of the challenges of the binding protocol is to make sure that we provide a simple and sensible model for the kind of system that Kevin describes (since they are the systems that are most likely to require and use a multiple-binding model), while still providing sensible interoperation with file-system based implementations. In particular, I believe it is likely that a repository such as the one Kevin describes is likely to refuse to do anything other than REBIND for MOVE and UNBIND for DELETE, both for performance and semantic reasons. Cheers, Geoff -----Original Message----- From: Dyer, Kevin [mailto:kevin.dyer@matrixone.com] Sent: Tuesday, March 11, 2003 8:49 AM To: 'Clemm, Geoff'; 'WebDAV' Subject: RE: MOVEs across file systems Just putting in my 0.02 Galactic credits to make sure we keep in mind that some implementations will not be limited by a file system paradigm as the underlying engines will provide an abstraction to the actual source data. These systems use meta-data as the pointer to the actual source data which can exist on completely different servers and file systems. So moving data across a resources is as easy as creating a DB relationship. The actual source data is not moved and the system retains one version of the truth. Kevin From w3c-dist-auth-request@w3.org Tue Mar 11 11:18:32 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25581 for ; Tue, 11 Mar 2003 11:18:32 -0500 (EST) Received: from frink.w3.org (localhost [127.0.0.1]) by frink.w3.org (8.12.8/8.12.8) with ESMTP id h2BGKcZg023088; Tue, 11 Mar 2003 11:20:38 -0500 (EST) Received: (from lists@localhost) by frink.w3.org (8.12.8/8.12.8/Submit) id h2BGJF9C022919; Tue, 11 Mar 2003 11:19:15 -0500 (EST) Resent-Date: Tue, 11 Mar 2003 11:19:15 -0500 (EST) Resent-Message-Id: <200303111619.h2BGJF9C022919@frink.w3.org> Received: from tux.w3.org (IDENT:root@tux [18.29.0.27]) by frink.w3.org (8.12.8/8.12.8) with ESMTP id h2BGJCZg022886 for ; Tue, 11 Mar 2003 11:19:12 -0500 (EST) Received: from mail.xythos.com ([206.14.210.116]) by tux.w3.org (8.12.8/8.12.8) with ESMTP id h2BGJBrB019321 for ; Tue, 11 Mar 2003 11:19:12 -0500 Received: from ravms by mail.xythos.com with mail-ok (Exim 3.36 #3) id 18smVg-0002jm-00; Tue, 11 Mar 2003 16:21:48 +0000 Received: from [216.36.77.241] (helo=xythoslap) by mail.xythos.com with asmtp (Exim 3.36 #3) id 18smVg-0002jb-00; Tue, 11 Mar 2003 16:21:48 +0000 From: "Lisa Dusseault" To: "'Clemm, Geoff'" , "'WebDAV'" Date: Tue, 11 Mar 2003 08:18:56 -0800 Message-ID: <073f01c2e7e9$f3581ef0$bb01a8c0@xythoslap> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4024 Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Old-X-Envelope-To: gclemm@rational.com, w3c-dist-auth@w3.org Subject: RE: GULP vs RFC2518bis X-Archived-At: http://www.w3.org/mid/073f01c2e7e9$f3581ef0$bb01a8c0@xythoslap Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7476 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit GULP changes the way the If header works in a fairly way in all the proposed wordings I've seen. Some of the recent discussion: > > This doesn't mention untagged-list syntax in If header. > Is a corollary > > of this proposal that we remove the untagged-list > syntax? Or was the > > omission of untagged-list accidental? I'd prefer to > keep the untagged > > list syntax, so I believe this should read: > > "A lock token is "submitted" in a request when it > appears in an If > > header." > > I'd prefer > > "when it appears in an If header tagged-list whose tag is > the lock-root > of > the lock, or if it appears in an untagged list and the > request-URL is the > lock-root of the lock". > > I agree this change should be made, and I prefer Julian's > rewording, as > it is more precise. I'll post a new version of GULP with this change. > This changes the way the If header is parsed. It means the client can't submit an untagged token list without matching the lock-root of the token against the Request-URI. That's not how the If header worked before. I'll give an example of what should work today, and what GULP forbids. Let's say I want to DELETE an unlocked collection, and in that collection are two independently locked descendants. The descendants have these two Etags: and The following request should allow the lock tokens to match and the server should accept both tokens, because they are in an OR list: DELETE /tld/ HTTP/1.1 If: () () I don't want to change this behaviour, because it's a very convenient way for a client to provide a bunch of lock tokens in exactly the situation of deleting or moving a collection with locked descendants. Lisa From w3c-dist-auth-request@w3.org Tue Mar 11 11:25:45 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25908 for ; Tue, 11 Mar 2003 11:25:44 -0500 (EST) Received: from frink.w3.org (localhost [127.0.0.1]) by frink.w3.org (8.12.8/8.12.8) with ESMTP id h2BGRqZg026467; Tue, 11 Mar 2003 11:27:52 -0500 (EST) Received: (from lists@localhost) by frink.w3.org (8.12.8/8.12.8/Submit) id h2BGRqKd026455; Tue, 11 Mar 2003 11:27:52 -0500 (EST) Resent-Date: Tue, 11 Mar 2003 11:27:52 -0500 (EST) Resent-Message-Id: <200303111627.h2BGRqKd026455@frink.w3.org> Received: from tux.w3.org (IDENT:root@tux [18.29.0.27]) by frink.w3.org (8.12.8/8.12.8) with ESMTP id h2BGRoZg026413 for ; Tue, 11 Mar 2003 11:27:50 -0500 (EST) Received: from mail.xythos.com ([206.14.210.116]) by tux.w3.org (8.12.8/8.12.8) with ESMTP id h2BGRnrB022945 for ; Tue, 11 Mar 2003 11:27:50 -0500 Received: from ravms by mail.xythos.com with mail-ok (Exim 3.36 #3) id 18sme3-0002qD-00; Tue, 11 Mar 2003 16:30:27 +0000 Received: from [216.36.77.241] (helo=xythoslap) by mail.xythos.com with asmtp (Exim 3.36 #3) id 18sme3-0002q2-00; Tue, 11 Mar 2003 16:30:27 +0000 From: "Lisa Dusseault" To: "'Jason Crawford'" Cc: "'WebDAV'" Date: Tue, 11 Mar 2003 08:27:47 -0800 Message-ID: <075001c2e7eb$28782b10$bb01a8c0@xythoslap> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4024 Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Old-X-Envelope-To: nn683849@smallcue.com, w3c-dist-auth@w3.org Subject: RE: MOVEs across file systems X-Archived-At: http://www.w3.org/mid/075001c2e7eb$28782b10$bb01a8c0@xythoslap Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7477 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit > Anyway... the thought I just wanted to point out is that if you have a > resource on one file system with multiple bindings to it, and you MOVE > that resource via one of those bindings "to another file system"... > you might actually want to NOT "copy/delete" it since you > still also have > several bindings to it from the original file system. You might > *need* to keep a cross file system binding and not necessarily > move implementations around during MOVE/BIND and other > namespace operations. And if you're forced to support cross > file system bindings, then perhaps you never really need to take the > COPY/DELETE approach? A couple counter-reasons: - Quota within the system (top level directories or lower directories limiting space) this may depend on how the quota is counted - the system, through its acknowledged limitations, may need to actually move the resources (not leave them and rebind them) in order to calculate quota. - Disk space outside the system - different parts of the namespace are frequently literally stored on different disks. Users/Administrators may move content from one part of the namespace to another *in order* to transfer to a less-used disk. Jason, you've clearly got the right instincts for designing a WebDAV server -- thinking carefully about how to do the best possible job. It's just a question of can the *protocol* enforce a good job on server implementors? Sometimes it can, but sometimes it can't. We wouldn't want to force atomic DELETEs and have an implementation choose to reject a great number of large DELETE requests just because it can't guarantee them all atomic. In the extreme, that would be an even worse tradeoff. Lisa From w3c-dist-auth-request@w3.org Tue Mar 11 11:38:22 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26558 for ; Tue, 11 Mar 2003 11:38:22 -0500 (EST) Received: from frink.w3.org (localhost [127.0.0.1]) by frink.w3.org (8.12.8/8.12.8) with ESMTP id h2BGeUZg029947; Tue, 11 Mar 2003 11:40:30 -0500 (EST) Received: (from lists@localhost) by frink.w3.org (8.12.8/8.12.8/Submit) id h2BGeQjt029895; Tue, 11 Mar 2003 11:40:26 -0500 (EST) Resent-Date: Tue, 11 Mar 2003 11:40:26 -0500 (EST) Resent-Message-Id: <200303111640.h2BGeQjt029895@frink.w3.org> Received: from tux.w3.org (IDENT:root@tux [18.29.0.27]) by frink.w3.org (8.12.8/8.12.8) with ESMTP id h2BGeOZg029858 for ; Tue, 11 Mar 2003 11:40:24 -0500 (EST) Received: from mail.xythos.com ([206.14.210.116]) by tux.w3.org (8.12.8/8.12.8) with ESMTP id h2BGeOrB027571 for ; Tue, 11 Mar 2003 11:40:24 -0500 Received: from ravms by mail.xythos.com with mail-ok (Exim 3.36 #3) id 18smqD-0002yB-00; Tue, 11 Mar 2003 16:43:01 +0000 Received: from [216.36.77.241] (helo=xythoslap) by mail.xythos.com with asmtp (Exim 3.36 #3) id 18smqD-0002y0-00; Tue, 11 Mar 2003 16:43:01 +0000 From: "Lisa Dusseault" To: "'Clemm, Geoff'" , "'WebDAV'" Date: Tue, 11 Mar 2003 08:40:24 -0800 Message-ID: <075201c2e7ec$ea010a30$bb01a8c0@xythoslap> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4024 Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Old-X-Envelope-To: gclemm@rational.com, w3c-dist-auth@w3.org Subject: RE: MOVEs across file systems X-Archived-At: http://www.w3.org/mid/075201c2e7ec$ea010a30$bb01a8c0@xythoslap Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7478 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit This is equivalent to the previous behavior as long as clients continue to issue the same MOVE and DELETE requests they have in the past (which they will for quite a while). Therefore, I don't see how this is a change, or how this could possibly be acceptable if the previous behavior was unacceptable. Servers must be able to support the binding specification, and to support ordinary WebDAV clients, and to do what the server implementors consider to be the most appropriate and best job they can of fulfilling the request, and to report the results. This proposed statement does not meet that requirement because it forces all servers to do atomic MOVE/DELETE in handling requests from ordinary WebDAV clients. Lisa > -----Original Message----- > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org] On Behalf Of Clemm, Geoff > Sent: Monday, March 10, 2003 12:18 PM > To: 'WebDAV' > Subject: RE: MOVEs across file systems > > > > That would be fine with me as well. > > Just to be clear, this means the binding spec would state: > > A server that supports BIND MUST implement MOVE/DELETE with > rebind/unbind semantics. We will also define a parameter to > MOVE/DELETE that allows a user to explicitly request the > "best effort" style processing (that is OK because the user is > explicitly stating that trashing multiple binding semantics is > what they want). > > Cheers, > Geoff > > -----Original Message----- > From: Julian Reschke [mailto:julian.reschke@gmx.de] > > > From: Clemm, Geoff > > So I'm happy to limit the constraints on MOVE and DELETE to exactly > > what is needed to preserve the semantics of multiple bindings, but > > leaving them unconstrained makes the binding protocol pointless in > > practice. > > On the other hand, a system that allows a "weak" MOVE if and > only if there > aren't any multiple bindings seems very weird to me. So maybe > we should > consider make MOVE "strong" by default, and only allow the > old COPY/DELETE > semantics upon specific request? > > From w3c-dist-auth-request@w3.org Tue Mar 11 11:44:32 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26849 for ; Tue, 11 Mar 2003 11:44:32 -0500 (EST) Received: from frink.w3.org (localhost [127.0.0.1]) by frink.w3.org (8.12.8/8.12.8) with ESMTP id h2BGkdZg002024; Tue, 11 Mar 2003 11:46:39 -0500 (EST) Received: (from lists@localhost) by frink.w3.org (8.12.8/8.12.8/Submit) id h2BGkdoI001999; Tue, 11 Mar 2003 11:46:39 -0500 (EST) Resent-Date: Tue, 11 Mar 2003 11:46:39 -0500 (EST) Resent-Message-Id: <200303111646.h2BGkdoI001999@frink.w3.org> Received: from tux.w3.org (IDENT:root@tux [18.29.0.27]) by frink.w3.org (8.12.8/8.12.8) with ESMTP id h2BGkbZg001940 for ; Tue, 11 Mar 2003 11:46:37 -0500 (EST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by tux.w3.org (8.12.8/8.12.8) with SMTP id h2BGkZrB029536 for ; Tue, 11 Mar 2003 11:46:36 -0500 Received: (qmail 9494 invoked by uid 0); 11 Mar 2003 16:46:28 -0000 Received: from mail.greenbytes.de (HELO lisa) (217.5.201.10) by mail.gmx.net (mp015-rz3) with SMTP; 11 Mar 2003 16:46:28 -0000 From: "Julian Reschke" To: "Lisa Dusseault" , "'Clemm, Geoff'" , "'WebDAV'" Date: Tue, 11 Mar 2003 17:46:23 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) In-Reply-To: <073f01c2e7e9$f3581ef0$bb01a8c0@xythoslap> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal Subject: RE: GULP vs RFC2518bis X-Archived-At: http://www.w3.org/mid/JIEGINCHMLABHJBIGKBCEEKMGLAA.julian.reschke@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7479 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit Lisa, > The following request should allow the lock tokens to match and the > server should accept both tokens, because they are in an OR list: > > DELETE /tld/ HTTP/1.1 > If: () > () I just checked this format with 1) moddav 2) IIS 3) SAP EP 4) sharemation and none of the servers accept it (and I think that's correct). Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Tue Mar 11 12:08:26 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28127 for ; Tue, 11 Mar 2003 12:08:26 -0500 (EST) Received: from frink.w3.org (localhost [127.0.0.1]) by frink.w3.org (8.12.8/8.12.8) with ESMTP id h2BHAYZg012354; Tue, 11 Mar 2003 12:10:34 -0500 (EST) Received: (from lists@localhost) by frink.w3.org (8.12.8/8.12.8/Submit) id h2BHAW3E012332; Tue, 11 Mar 2003 12:10:32 -0500 (EST) Resent-Date: Tue, 11 Mar 2003 12:10:32 -0500 (EST) Resent-Message-Id: <200303111710.h2BHAW3E012332@frink.w3.org> Received: from tux.w3.org (IDENT:root@tux [18.29.0.27]) by frink.w3.org (8.12.8/8.12.8) with ESMTP id h2BHAUZg012299 for ; Tue, 11 Mar 2003 12:10:30 -0500 (EST) Received: from sus-ma1it31.rational.com (sus-ma1it31.rational.com [130.213.73.33]) by tux.w3.org (8.12.8/8.12.8) with ESMTP id h2BHAUrB006632 for ; Tue, 11 Mar 2003 12:10:30 -0500 Received: from sus-ma1it00.rational.com ([10.64.1.25]) by 10.64.1.33 with InterScan Messaging Security Suite; Tue, 11 Mar 2003 11:54:04 -0500 Received: by sus-ma1it00.rational.com with Internet Mail Service (5.5.2656.59) id ; Tue, 11 Mar 2003 12:10:25 -0500 Message-ID: From: "Clemm, Geoff" To: "'WebDAV'" Date: Tue, 11 Mar 2003 12:10:24 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain Subject: RE: MOVEs across file systems X-Archived-At: http://www.w3.org/mid/E4F2D33B98DF7E4880884B9F0E6FDEE2021C61B4@SUS-MA1IT01 Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7480 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Yeah, I didn't think that Julian's suggestion would be popular (:-). So I think realistically, we should focus on constraining the behavior of MOVE/DELETE in the presence of multiple bindings to the same resource, so that they don't violate the basic requirements of multiple bindings. The current form of that proposal is: ---------------------------- Instead of saying: "DELETE SHOULD be UNBIND if UNBIND is supported" we should say something like: "When DELETE is applied to a collection, it MUST NOT modify the membership of another collection, except when the collection being deleted is itself a member of that other collection. For example, suppose /a/b/.../x identifies a collection C, and there is a second binding to C in a collection that is not a member of /a/b, then "DELETE /a/b" MUST NOT delete the internal member named "y" from C. And instead of saying: "MOVE SHOULD be REBIND if REBIND is supported" we should say something like: "When MOVE is applied to a resource, the other bindings to that resource MUST be unaffected, and if the resource being moved is a collection, the bindings to any members of that collection MUST be unaffected. Also, if MOVE is used with Overwrite:T to delete an existing resource, the constraints specified for DELETE apply." ------------------ Cheers, Geoff -----Original Message----- From: Lisa Dusseault [mailto:lisa@xythos.com] Sent: Tuesday, March 11, 2003 11:40 AM To: 'Clemm, Geoff'; 'WebDAV' Subject: RE: MOVEs across file systems This is equivalent to the previous behavior as long as clients continue to issue the same MOVE and DELETE requests they have in the past (which they will for quite a while). Therefore, I don't see how this is a change, or how this could possibly be acceptable if the previous behavior was unacceptable. Servers must be able to support the binding specification, and to support ordinary WebDAV clients, and to do what the server implementors consider to be the most appropriate and best job they can of fulfilling the request, and to report the results. This proposed statement does not meet that requirement because it forces all servers to do atomic MOVE/DELETE in handling requests from ordinary WebDAV clients. Lisa > -----Original Message----- > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org] On Behalf Of Clemm, Geoff > Sent: Monday, March 10, 2003 12:18 PM > To: 'WebDAV' > Subject: RE: MOVEs across file systems > > > > That would be fine with me as well. > > Just to be clear, this means the binding spec would state: > > A server that supports BIND MUST implement MOVE/DELETE with > rebind/unbind semantics. We will also define a parameter to > MOVE/DELETE that allows a user to explicitly request the > "best effort" style processing (that is OK because the user is > explicitly stating that trashing multiple binding semantics is > what they want). > > Cheers, > Geoff > > -----Original Message----- > From: Julian Reschke [mailto:julian.reschke@gmx.de] > > > From: Clemm, Geoff > > So I'm happy to limit the constraints on MOVE and DELETE to exactly > > what is needed to preserve the semantics of multiple bindings, but > > leaving them unconstrained makes the binding protocol pointless in > > practice. > > On the other hand, a system that allows a "weak" MOVE if and > only if there > aren't any multiple bindings seems very weird to me. So maybe > we should > consider make MOVE "strong" by default, and only allow the > old COPY/DELETE > semantics upon specific request? > > From w3c-dist-auth-request@w3.org Tue Mar 11 13:09:23 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00037 for ; Tue, 11 Mar 2003 13:09:23 -0500 (EST) Received: from frink.w3.org (localhost [127.0.0.1]) by frink.w3.org (8.12.8/8.12.8) with ESMTP id h2BIBVZg025790; Tue, 11 Mar 2003 13:11:31 -0500 (EST) Received: (from lists@localhost) by frink.w3.org (8.12.8/8.12.8/Submit) id h2BIBPOr025626; Tue, 11 Mar 2003 13:11:25 -0500 (EST) Resent-Date: Tue, 11 Mar 2003 13:11:25 -0500 (EST) Resent-Message-Id: <200303111811.h2BIBPOr025626@frink.w3.org> Received: from tux.w3.org (IDENT:root@tux [18.29.0.27]) by frink.w3.org (8.12.8/8.12.8) with ESMTP id h2BIBNZg025575 for ; Tue, 11 Mar 2003 13:11:23 -0500 (EST) Received: from mail.xythos.com ([206.14.210.116]) by tux.w3.org (8.12.8/8.12.8) with ESMTP id h2BIBMrB025485 for ; Tue, 11 Mar 2003 13:11:22 -0500 Received: from ravms by mail.xythos.com with mail-ok (Exim 3.36 #3) id 18soGG-0004Fg-00; Tue, 11 Mar 2003 18:14:00 +0000 Received: from [216.36.77.241] (helo=xythoslap) by mail.xythos.com with asmtp (Exim 3.36 #3) id 18soGG-0004FV-00; Tue, 11 Mar 2003 18:14:00 +0000 From: "Lisa Dusseault" To: "'Clemm, Geoff'" , "'WebDAV'" Date: Tue, 11 Mar 2003 10:11:22 -0800 Message-ID: <076501c2e7f9$9f441f70$bb01a8c0@xythoslap> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4024 Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Old-X-Envelope-To: gclemm@rational.com, w3c-dist-auth@w3.org Subject: RE: MOVEs across file systems X-Archived-At: http://www.w3.org/mid/076501c2e7f9$9f441f70$bb01a8c0@xythoslap Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7481 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit This is pretty good! I look forward to seeing it in context of the draft, when we can submit drafts again of course. > -----Original Message----- > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org] On Behalf Of Clemm, Geoff > Sent: Tuesday, March 11, 2003 9:10 AM > To: 'WebDAV' > Subject: RE: MOVEs across file systems > > > > Yeah, I didn't think that Julian's suggestion would be popular (:-). > > So I think realistically, we should focus on constraining the > behavior of MOVE/DELETE in the presence of multiple bindings > to the same resource, so that they don't violate the basic > requirements of multiple bindings. > > The current form of that proposal is: > > ---------------------------- > > Instead of saying: > > "DELETE SHOULD be UNBIND if UNBIND is supported" > > we should say something like: > > "When DELETE is applied to a collection, it MUST NOT modify the > membership of another collection, except when the collection > being deleted is itself a member of that other collection. > > For example, suppose /a/b/.../x identifies a collection C, > and there > is a second binding to C in a collection that is not a member of > /a/b, then "DELETE /a/b" MUST NOT delete the internal member > named "y" from C. > > And instead of saying: > > "MOVE SHOULD be REBIND if REBIND is supported" > > we should say something like: > > "When MOVE is applied to a resource, the other bindings > to that resource MUST be unaffected, and if the > resource being moved is a collection, the bindings to any > members of that collection MUST be unaffected. > Also, if MOVE is used with Overwrite:T to delete an > existing resource, the constraints specified for DELETE apply." > > ------------------ > > Cheers, > Geoff > > -----Original Message----- > From: Lisa Dusseault [mailto:lisa@xythos.com] > Sent: Tuesday, March 11, 2003 11:40 AM > To: 'Clemm, Geoff'; 'WebDAV' > Subject: RE: MOVEs across file systems > > > This is equivalent to the previous behavior as long as > clients continue > to issue the same MOVE and DELETE requests they have in the > past (which > they will for quite a while). Therefore, I don't see how this is a > change, or how this could possibly be acceptable if the previous > behavior was unacceptable. > > Servers must be able to support the binding specification, and to > support ordinary WebDAV clients, and to do what the server > implementors > consider to be the most appropriate and best job they can of > fulfilling > the request, and to report the results. This proposed statement does > not meet that requirement because it forces all servers to do atomic > MOVE/DELETE in handling requests from ordinary WebDAV clients. > > Lisa > > > -----Original Message----- > > From: w3c-dist-auth-request@w3.org > > [mailto:w3c-dist-auth-request@w3.org] On Behalf Of Clemm, Geoff > > Sent: Monday, March 10, 2003 12:18 PM > > To: 'WebDAV' > > Subject: RE: MOVEs across file systems > > > > > > > > That would be fine with me as well. > > > > Just to be clear, this means the binding spec would state: > > > > A server that supports BIND MUST implement MOVE/DELETE with > > rebind/unbind semantics. We will also define a parameter to > > MOVE/DELETE that allows a user to explicitly request the > > "best effort" style processing (that is OK because the user is > > explicitly stating that trashing multiple binding semantics is > > what they want). > > > > Cheers, > > Geoff > > > > -----Original Message----- > > From: Julian Reschke [mailto:julian.reschke@gmx.de] > > > > > From: Clemm, Geoff > > > So I'm happy to limit the constraints on MOVE and DELETE > to exactly > > > what is needed to preserve the semantics of multiple bindings, but > > > leaving them unconstrained makes the binding protocol pointless in > > > practice. > > > > On the other hand, a system that allows a "weak" MOVE if and > > only if there > > aren't any multiple bindings seems very weird to me. So maybe > > we should > > consider make MOVE "strong" by default, and only allow the > > old COPY/DELETE > > semantics upon specific request? > > > > > > From w3c-dist-auth-request@w3.org Tue Mar 11 13:57:01 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA02604 for ; Tue, 11 Mar 2003 13:57:00 -0500 (EST) Received: from frink.w3.org (localhost [127.0.0.1]) by frink.w3.org (8.12.8/8.12.8) with ESMTP id h2BIwaZg005852; Tue, 11 Mar 2003 13:58:36 -0500 (EST) Received: (from lists@localhost) by frink.w3.org (8.12.8/8.12.8/Submit) id h2BIwZDc005827; Tue, 11 Mar 2003 13:58:35 -0500 (EST) Resent-Date: Tue, 11 Mar 2003 13:58:35 -0500 (EST) Resent-Message-Id: <200303111858.h2BIwZDc005827@frink.w3.org> Received: from tux.w3.org (IDENT:root@tux [18.29.0.27]) by frink.w3.org (8.12.8/8.12.8) with ESMTP id h2BIwTZg005789 for ; Tue, 11 Mar 2003 13:58:29 -0500 (EST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by tux.w3.org (8.12.8/8.12.8) with SMTP id h2BIwSrB009831 for ; Tue, 11 Mar 2003 13:58:29 -0500 Received: (qmail 25316 invoked by uid 0); 11 Mar 2003 18:58:21 -0000 Received: from pD950C384.dip.t-dialin.net (HELO lisa) (217.80.195.132) by mail.gmx.net (mp018-rz3) with SMTP; 11 Mar 2003 18:58:21 -0000 From: "Julian Reschke" To: "Lisa Dusseault" , "'Clemm, Geoff'" , "'WebDAV'" Date: Tue, 11 Mar 2003 19:58:18 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) Importance: Normal In-Reply-To: <076501c2e7f9$9f441f70$bb01a8c0@xythoslap> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Subject: RE: MOVEs across file systems X-Archived-At: http://www.w3.org/mid/JIEGINCHMLABHJBIGKBCEELFGLAA.julian.reschke@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7482 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit Of course that doesn't require the ability to *submit* drafts, as long as the current edits are published on the BIND home page (as they usually are) :-) -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 > -----Original Message----- > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Lisa Dusseault > Sent: Tuesday, March 11, 2003 7:11 PM > To: 'Clemm, Geoff'; 'WebDAV' > Subject: RE: MOVEs across file systems > > > > This is pretty good! I look forward to seeing it in context of the > draft, when we can submit drafts again of course. > > > -----Original Message----- > > From: w3c-dist-auth-request@w3.org > > [mailto:w3c-dist-auth-request@w3.org] On Behalf Of Clemm, Geoff > > Sent: Tuesday, March 11, 2003 9:10 AM > > To: 'WebDAV' > > Subject: RE: MOVEs across file systems > > > > > > > > Yeah, I didn't think that Julian's suggestion would be popular (:-). > > > > So I think realistically, we should focus on constraining the > > behavior of MOVE/DELETE in the presence of multiple bindings > > to the same resource, so that they don't violate the basic > > requirements of multiple bindings. > > > > The current form of that proposal is: > > > > ---------------------------- > > > > Instead of saying: > > > > "DELETE SHOULD be UNBIND if UNBIND is supported" > > > > we should say something like: > > > > "When DELETE is applied to a collection, it MUST NOT modify the > > membership of another collection, except when the collection > > being deleted is itself a member of that other collection. > > > > For example, suppose /a/b/.../x identifies a collection C, > > and there > > is a second binding to C in a collection that is not a member of > > /a/b, then "DELETE /a/b" MUST NOT delete the internal member > > named "y" from C. > > > > And instead of saying: > > > > "MOVE SHOULD be REBIND if REBIND is supported" > > > > we should say something like: > > > > "When MOVE is applied to a resource, the other bindings > > to that resource MUST be unaffected, and if the > > resource being moved is a collection, the bindings to any > > members of that collection MUST be unaffected. > > Also, if MOVE is used with Overwrite:T to delete an > > existing resource, the constraints specified for DELETE apply." > > > > ------------------ > > > > Cheers, > > Geoff > > > > -----Original Message----- > > From: Lisa Dusseault [mailto:lisa@xythos.com] > > Sent: Tuesday, March 11, 2003 11:40 AM > > To: 'Clemm, Geoff'; 'WebDAV' > > Subject: RE: MOVEs across file systems > > > > > > This is equivalent to the previous behavior as long as > > clients continue > > to issue the same MOVE and DELETE requests they have in the > > past (which > > they will for quite a while). Therefore, I don't see how this is a > > change, or how this could possibly be acceptable if the previous > > behavior was unacceptable. > > > > Servers must be able to support the binding specification, and to > > support ordinary WebDAV clients, and to do what the server > > implementors > > consider to be the most appropriate and best job they can of > > fulfilling > > the request, and to report the results. This proposed statement does > > not meet that requirement because it forces all servers to do atomic > > MOVE/DELETE in handling requests from ordinary WebDAV clients. > > > > Lisa > > > > > -----Original Message----- > > > From: w3c-dist-auth-request@w3.org > > > [mailto:w3c-dist-auth-request@w3.org] On Behalf Of Clemm, Geoff > > > Sent: Monday, March 10, 2003 12:18 PM > > > To: 'WebDAV' > > > Subject: RE: MOVEs across file systems > > > > > > > > > > > > That would be fine with me as well. > > > > > > Just to be clear, this means the binding spec would state: > > > > > > A server that supports BIND MUST implement MOVE/DELETE with > > > rebind/unbind semantics. We will also define a parameter to > > > MOVE/DELETE that allows a user to explicitly request the > > > "best effort" style processing (that is OK because the user is > > > explicitly stating that trashing multiple binding semantics is > > > what they want). > > > > > > Cheers, > > > Geoff > > > > > > -----Original Message----- > > > From: Julian Reschke [mailto:julian.reschke@gmx.de] > > > > > > > From: Clemm, Geoff > > > > So I'm happy to limit the constraints on MOVE and DELETE > > to exactly > > > > what is needed to preserve the semantics of multiple bindings, but > > > > leaving them unconstrained makes the binding protocol pointless in > > > > practice. > > > > > > On the other hand, a system that allows a "weak" MOVE if and > > > only if there > > > aren't any multiple bindings seems very weird to me. So maybe > > > we should > > > consider make MOVE "strong" by default, and only allow the > > > old COPY/DELETE > > > semantics upon specific request? > > > > > > > > > > > > From w3c-dist-auth-request@w3.org Tue Mar 11 15:00:03 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08228 for ; Tue, 11 Mar 2003 15:00:02 -0500 (EST) Received: from frink.w3.org (localhost [127.0.0.1]) by frink.w3.org (8.12.8/8.12.8) with ESMTP id h2BJuVNe025552; Tue, 11 Mar 2003 14:56:31 -0500 (EST) Received: (from lists@localhost) by frink.w3.org (8.12.8/8.12.8/Submit) id h2BJuEh2025521; Tue, 11 Mar 2003 14:56:14 -0500 (EST) Resent-Date: Tue, 11 Mar 2003 14:56:14 -0500 (EST) Resent-Message-Id: <200303111956.h2BJuEh2025521@frink.w3.org> Received: from tux.w3.org (IDENT:root@tux [18.29.0.27]) by frink.w3.org (8.12.8/8.12.8) with ESMTP id h2BJuANe025488 for ; Tue, 11 Mar 2003 14:56:10 -0500 (EST) Received: from sunbelt.seagull.net (sunbelt.seagull.net [199.254.168.249]) by tux.w3.org (8.12.8/8.12.8) with ESMTP id h2BJu9rB002886 for ; Tue, 11 Mar 2003 14:56:09 -0500 Received: (mail@localhost) by sunbelt.seagull.net (8.9.3) id LAA31124 sender nn683849@smallcue.com for w3c-dist-auth@w3.org; Tue, 11 Mar 2003 11:56:00 -0800 Received: from e3.ny.us.ibm.com (e3.ny.us.ibm.com [32.97.182.103]) by sunbelt.seagull.net (8.9.3) with ESMTP id LAA31099 sender obsfucated@us.ibm.com; Tue, 11 Mar 2003 11:55:59 -0800 Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.56.224.150]) by e3.ny.us.ibm.com (8.12.8/8.12.2) with ESMTP id h2BJtRkD145398; Tue, 11 Mar 2003 14:55:27 -0500 Received: from d01ml243.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by northrelay02.pok.ibm.com (8.12.8/NCO/VER6.5) with ESMTP id h2BJtO3g149408; Tue, 11 Mar 2003 14:55:25 -0500 To: "Lisa Dusseault" Cc: "'WebDAV'" X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: Jason Crawford Date: Tue, 11 Mar 2003 14:54:43 -0500 X-MIMETrack: Serialize by Router on D01ML243/01/M/IBM(Release 6.0.1 [IBM]NP|March 10, 2003) at 03/11/2003 14:55:24 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Subject: RE: MOVEs across file systems X-Archived-At: http://www.w3.org/mid/OFF79B160F.7238439C-ON85256CE6.005B8168@us.ibm.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7483 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Warning... this note is more interesting to server designers than spec designers.... :-) On Tuesday, 03/11/2003 at 08:27 PST, "Lisa Dusseault" wrote: > > Anyway... the thought I just wanted to point out is that if you have a > > resource on one file system with multiple bindings to it, and you MOVE > > that resource via one of those bindings "to another file system"... > > you might actually want to NOT "copy/delete" it since you > > still also have > > several bindings to it from the original file system. You might > > *need* to keep a cross file system binding and not necessarily > > move implementations around during MOVE/BIND and other > > namespace operations. And if you're forced to support cross > > file system bindings, then perhaps you never really need to take the > > COPY/DELETE approach? > > A couple counter-reasons: > - Quota within the system (top level directories or lower directories > limiting space) this may depend on how the quota is counted - the > system, through its acknowledged limitations, may need to actually move > the resources (not leave them and rebind them) in order to calculate > quota. > > - Disk space outside the system - different parts of the namespace are > frequently literally stored on different disks. Users/Administrators may > move content from one part of the namespace to another *in order* to > transfer to a less-used disk. The system *might* not want to move the implementation to the other file system because it has reason to keep it on the current file system also. But as you say, perhaps it might want to move it for reasons of it's own. Either way, the server has to support cross file system bindings. And the choice of which file system it will chose to keep it on becomes arbitrary from the WebDAV perspective. I would expect that it would actually end up keeping it where it was and just get the operation done quickly. You are probably talking about a situation where it's the last binding, so it's probably best to move it to the same file system used by its final parent. Again, it probably could get away not moving it, but as you say, users might make assumptions about certain parts of the URI space being stored in certain file stores. One complication with this approach is that in order to try to maintain that relationship, the operation will try to move the reources to file store that might not have enough quota from one that already has enough. That might make the operation abort despite the fact that the user has enough quota overall. Another is that if there is a global quota, the safe copy approach might cause the global quota to be exceeded (because for some period there will be two copies of one or more resources) and possibly abort the operation despite there being plenty of quota overall. Either way, the half finished MOVE can be a real pain for clients. How bad this is depends on how the COPY/DELETE operations are ordered and when the abort occurs. (I know I find it a real mess when I've encountered this situation. It's tedious to fix if it's even fixable and the user knows how to fix it.) Interestingly enough... even if the root of a subtree ends up changing file systems because it has only one parent binding, many of it's children might not migrate if there are links from the original file system to them. So in the presence of multiple bindings, this association between URI and the file store used for the implementation is weak and sometimes problematic. For this reason it doesn't seem well advised to be compromising WebDAV operations to maintain this mapping that it can't really guarantee anyway. It does seem like there needs to be some other way for the user to move resources between various storage systems in order to manage the consumption of his quotas. -- I repeat though... this is only in the presence of multiple bindings. In the absense of multiple bindings, if we ignore the issue of aborts due to secondary issues, and ignoring the unfortunate possibility that resource-id's might change as implementations migrate, the server should be able to maintain the URL to file store mappings and that can be attractive from a UI perspective. > Jason, you've clearly got the right instincts for designing a WebDAV > server -- thinking carefully about how to do the best possible job. > It's just a question of can the *protocol* enforce a good job on server > implementors? Sometimes it can, but sometimes it can't. Agreed. In this thread I'm just pointing out possibilities that I, for one, hadn't thought about or noticed mentioned before. Thank you for responding and cleaning up weaknesses in the message that started this thread. :-) > We wouldn't > want to force atomic DELETEs and have an implementation choose to reject > a great number of large DELETE requests just because it can't guarantee > them all atomic. In the extreme, that would be an even worse tradeoff. Yes, for DELETE, there is a possibility that a client doesn't care if it's atomic or not. He just "wants to free resources eating up [his] quota... and if [he] can't get all of the subtree freed, that's okay for now." I will point out weakly though, that if that's the user's thinking, even in an atomic server, if the error message provided is informative enough, there is a significant possibility that user will be able to free up the portion of the subtree that isn't resisting the DELETE. Obviously a server can do that more efficiently though than the client can if the server understands what the user/client wants. Speaking of the server knowing what the user wants, that does bring up another point... is the best effort DELETE operation allowed to stop the first time it encounters a resource that prevents the unbinding of the request-URI binding (for example to keep it reachable)? Or must it continue to find as many resources that it's free to delete as possible? Or in the case of request URI is "protected" by a lock in the subtree, the server will almost certainly be aware of the "protection" issue right away, so is the server required to not remove any bindings at all? -- Anyway, if we really think clients will *want* best effort DELETE available, we'll have to specify what the prefered/required behavior is for that. (Maybe later if we don't see the demand yet.) J. ------------------------------------------ Phone: 914-784-7569, ccjason@us.ibm.com I do not check nn621779@smallcue.com From w3c-dist-auth-request@w3.org Tue Mar 11 15:20:42 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10500 for ; Tue, 11 Mar 2003 15:20:42 -0500 (EST) Received: from frink.w3.org (localhost [127.0.0.1]) by frink.w3.org (8.12.8/8.12.8) with ESMTP id h2BKMPNe029887; Tue, 11 Mar 2003 15:22:25 -0500 (EST) Received: (from lists@localhost) by frink.w3.org (8.12.8/8.12.8/Submit) id h2BKMNLa029856; Tue, 11 Mar 2003 15:22:23 -0500 (EST) Resent-Date: Tue, 11 Mar 2003 15:22:23 -0500 (EST) Resent-Message-Id: <200303112022.h2BKMNLa029856@frink.w3.org> Received: from tux.w3.org (IDENT:root@tux [18.29.0.27]) by frink.w3.org (8.12.8/8.12.8) with ESMTP id h2BKMJNe029819 for ; Tue, 11 Mar 2003 15:22:19 -0500 (EST) Received: from mail.xythos.com ([206.14.210.116]) by tux.w3.org (8.12.8/8.12.8) with ESMTP id h2BKMDrB012489 for ; Tue, 11 Mar 2003 15:22:13 -0500 Received: from ravms by mail.xythos.com with mail-ok (Exim 3.36 #3) id 18sqIv-0007LG-00; Tue, 11 Mar 2003 20:24:53 +0000 Received: from [216.36.77.241] (helo=xythoslap) by mail.xythos.com with asmtp (Exim 3.36 #3) id 18sqIu-0007L5-00; Tue, 11 Mar 2003 20:24:52 +0000 From: "Lisa Dusseault" To: "'Julian Reschke'" , "'Clemm, Geoff'" , "'WebDAV'" Date: Tue, 11 Mar 2003 12:22:12 -0800 Message-ID: <078101c2e80b$e69e1800$bb01a8c0@xythoslap> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4024 Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Old-X-Envelope-To: gclemm@rational.com, julian.reschke@gmx.de, w3c-dist-auth@w3.org Subject: RE: GULP vs RFC2518bis X-Archived-At: http://www.w3.org/mid/078101c2e80b$e69e1800$bb01a8c0@xythoslap Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7484 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit Sorry, I omitted one important detail for this to work. You need one clause in the OR statement that will succeed, otherwise you'll get a 412 Precondition Failed response. So take 2, this should work: DELETE /tld/ HTTP/1.1 If: () () (Not ) (No line returns, of course) The request should work because: (1) The required lock tokens for the two locked descendants are there (2) the precondition succeeds because one Ored condition is true (Not Nolock) With the proposed changes in GULP, part (1) would fail because the server would have to make sure the tokens were tagged correctly or matched the Request-URI exactly. I suppose the intention would be to respond with 423 Locked because although the lock tokens are there, they're not tagged correctly, even though the precondition is successful? I think that's a bad idea. The lock tokens are provided; take them. Lisa > -----Original Message----- > From: Julian Reschke [mailto:julian.reschke@gmx.de] > Sent: Tuesday, March 11, 2003 8:46 AM > To: Lisa Dusseault; 'Clemm, Geoff'; 'WebDAV' > Subject: RE: GULP vs RFC2518bis > > > Lisa, > > > The following request should allow the lock tokens to match and the > > server should accept both tokens, because they are in an OR list: > > > > DELETE /tld/ HTTP/1.1 > > If: () > > () > > I just checked this format with > > 1) moddav > 2) IIS > 3) SAP EP > 4) sharemation > > and none of the servers accept it (and I think that's correct). > > Julian > > -- > bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 > > From w3c-dist-auth-request@w3.org Tue Mar 11 15:32:50 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11059 for ; Tue, 11 Mar 2003 15:32:49 -0500 (EST) Received: from frink.w3.org (localhost [127.0.0.1]) by frink.w3.org (8.12.8/8.12.8) with ESMTP id h2BKYXNe002549; Tue, 11 Mar 2003 15:34:33 -0500 (EST) Received: (from lists@localhost) by frink.w3.org (8.12.8/8.12.8/Submit) id h2BKYVKY002519; Tue, 11 Mar 2003 15:34:31 -0500 (EST) Resent-Date: Tue, 11 Mar 2003 15:34:31 -0500 (EST) Resent-Message-Id: <200303112034.h2BKYVKY002519@frink.w3.org> Received: from tux.w3.org (IDENT:root@tux [18.29.0.27]) by frink.w3.org (8.12.8/8.12.8) with ESMTP id h2BKYTNe002486 for ; Tue, 11 Mar 2003 15:34:29 -0500 (EST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by tux.w3.org (8.12.8/8.12.8) with SMTP id h2BKYSrB016234 for ; Tue, 11 Mar 2003 15:34:28 -0500 Received: (qmail 30298 invoked by uid 0); 11 Mar 2003 20:34:21 -0000 Received: from pD950C384.dip.t-dialin.net (HELO lisa) (217.80.195.132) by mail.gmx.net (mp019-rz3) with SMTP; 11 Mar 2003 20:34:21 -0000 From: "Julian Reschke" To: "Lisa Dusseault" , "'Julian Reschke'" , "'Clemm, Geoff'" , "'WebDAV'" Date: Tue, 11 Mar 2003 21:34:19 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) Importance: Normal In-Reply-To: <078101c2e80b$e69e1800$bb01a8c0@xythoslap> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Subject: RE: GULP vs RFC2518bis X-Archived-At: http://www.w3.org/mid/JIEGINCHMLABHJBIGKBCIELLGLAA.julian.reschke@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7485 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Lisa Dusseault > Sent: Tuesday, March 11, 2003 9:22 PM > To: 'Julian Reschke'; 'Clemm, Geoff'; 'WebDAV' > Subject: RE: GULP vs RFC2518bis > > > > > Sorry, I omitted one important detail for this to work. You need one > clause in the OR statement that will succeed, otherwise you'll get a 412 > Precondition Failed response. So take 2, this should work: > > DELETE /tld/ HTTP/1.1 > If: () > () > (Not ) > > (No line returns, of course) > > The request should work because: > (1) The required lock tokens for the two locked descendants are there But they haven't been submitted for the right URL. Is this really sufficient? > (2) the precondition succeeds because one Ored condition is true (Not > Nolock) "" isn't a valid Coded-URL. Using "" instead fails both on moddav and Sharemation (can't try with IIS right now). > With the proposed changes in GULP, part (1) would fail because the > server would have to make sure the tokens were tagged correctly or > matched the Request-URI exactly. I suppose the intention would be to > respond with 423 Locked because although the lock tokens are there, > they're not tagged correctly, even though the precondition is > successful? I think that's a bad idea. The lock tokens are provided; > take them. My understanding is that a client needs to supply the lock tokens tagged for the right URLs. Where's the problem with that approach? It's interoperable and works right now. Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Wed Mar 12 20:00:26 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA02021 for ; Wed, 12 Mar 2003 20:00:26 -0500 (EST) Received: from frink.w3.org (localhost [127.0.0.1]) by frink.w3.org (8.12.8/8.12.8) with ESMTP id h2D11UNe007836; Wed, 12 Mar 2003 20:01:30 -0500 (EST) Received: (from lists@localhost) by frink.w3.org (8.12.8/8.12.8/Submit) id h2D10rou007599; Wed, 12 Mar 2003 20:00:53 -0500 (EST) Resent-Date: Wed, 12 Mar 2003 20:00:53 -0500 (EST) Resent-Message-Id: <200303130100.h2D10rou007599@frink.w3.org> Received: from tux.w3.org (IDENT:root@tux [18.29.0.27]) by frink.w3.org (8.12.8/8.12.8) with ESMTP id h2D10pNe007567 for ; Wed, 12 Mar 2003 20:00:51 -0500 (EST) Received: from mail.xythos.com ([206.14.210.116]) by tux.w3.org (8.12.8/8.12.8) with ESMTP id h2D10orB022426 for ; Wed, 12 Mar 2003 20:00:51 -0500 Received: from ravms by mail.xythos.com with mail-ok (Exim 3.36 #3) id 18tH8J-0003qT-00; Thu, 13 Mar 2003 01:03:43 +0000 Received: from [198.144.203.248] (helo=xythoslap) by mail.xythos.com with asmtp (Exim 3.36 #3) id 18tH8I-0003qI-00; Thu, 13 Mar 2003 01:03:43 +0000 From: "Lisa Dusseault" To: "Webdav WG" Cc: Date: Wed, 12 Mar 2003 17:00:39 -0800 Message-ID: <082001c2e8fb$f95c5b50$bb01a8c0@xythoslap> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4024 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Old-X-Envelope-To: agenda@ietf.org, w3c-dist-auth@w3c.org Subject: WebDAV wg agenda X-Archived-At: http://www.w3.org/mid/082001c2e8fb$f95c5b50$bb01a8c0@xythoslap Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7486 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit Here's a rough agenda for the meeting in no particular order. I'm having trouble nailing down some times and volunteers, hopefully these will be more fixed next week, but I wanted to get this out as a stake in the ground. WebDAV WG - Tuesday 15:45, Continental 7. RFC2518bis: Lisa Dusseault - GULP = Grand Unified Lock Proposal - Changes made in last draft Quota: Brian Korver Bindings: Geoff Clemm Ordered Collections: Geoff Clemm ACL: volunteer?? DASL: volunteer?? Thanks, Lisa From w3c-dist-auth-request@w3.org Wed Mar 12 22:41:50 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA06153 for ; Wed, 12 Mar 2003 22:41:50 -0500 (EST) Received: from frink.w3.org (localhost [127.0.0.1]) by frink.w3.org (8.12.8/8.12.8) with ESMTP id h2D3hQNe015588; Wed, 12 Mar 2003 22:43:26 -0500 (EST) Received: (from lists@localhost) by frink.w3.org (8.12.8/8.12.8/Submit) id h2D3hLkj015570; Wed, 12 Mar 2003 22:43:21 -0500 (EST) Resent-Date: Wed, 12 Mar 2003 22:43:21 -0500 (EST) Resent-Message-Id: <200303130343.h2D3hLkj015570@frink.w3.org> Received: from tux.w3.org (IDENT:root@tux [18.29.0.27]) by frink.w3.org (8.12.8/8.12.8) with ESMTP id h2D3hJNe015538 for ; Wed, 12 Mar 2003 22:43:19 -0500 (EST) Received: from sus-ma1it31.rational.com (sus-ma1it31.rational.com [130.213.73.33]) by tux.w3.org (8.12.8/8.12.8) with ESMTP id h2D3hIrB018894 for ; Wed, 12 Mar 2003 22:43:19 -0500 Received: from sus-ma1it00.rational.com ([10.64.1.25]) by 10.64.1.33 with InterScan Messaging Security Suite; Wed, 12 Mar 2003 21:47:36 -0500 Received: by sus-ma1it00.rational.com with Internet Mail Service (5.5.2656.59) id ; Wed, 12 Mar 2003 22:04:00 -0500 Message-ID: From: "Clemm, Geoff" To: Lisa Dusseault , Webdav WG Date: Wed, 12 Mar 2003 22:03:59 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain Subject: RE: WebDAV wg agenda X-Archived-At: http://www.w3.org/mid/E4F2D33B98DF7E4880884B9F0E6FDEE2023C8D02@SUS-MA1IT01 Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7487 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: I don't think we need more than 5 minutes for the ordering draft. I believe there are no outstanding issues, so this is likely to go something like: "any new issues?" "no?" "ok then, the next topic is ..." The binding protocol will probably need a good 15 minutes to discuss the latest proposal for resolving the MOVE/DELETE semantics. We could go as long as 30 minutes if other issues are raised, and could be as short as 10 minutes if time is in short supply. Eric or I would be happy to lead the ACL discussion. I believe most of the issues are details that have been resolved on the mailing list, but it would be good to review them before last call. Cheers, Geoff -----Original Message----- From: Lisa Dusseault [mailto:lisa@xythos.com] Sent: Wednesday, March 12, 2003 8:01 PM To: Webdav WG Cc: agenda@ietf.org Subject: WebDAV wg agenda Here's a rough agenda for the meeting in no particular order. I'm having trouble nailing down some times and volunteers, hopefully these will be more fixed next week, but I wanted to get this out as a stake in the ground. WebDAV WG - Tuesday 15:45, Continental 7. RFC2518bis: Lisa Dusseault - GULP = Grand Unified Lock Proposal - Changes made in last draft Quota: Brian Korver Bindings: Geoff Clemm Ordered Collections: Geoff Clemm ACL: volunteer?? DASL: volunteer?? Thanks, Lisa From w3c-dist-auth-request@w3.org Thu Mar 13 10:51:33 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06284 for ; Thu, 13 Mar 2003 10:51:28 -0500 (EST) Received: from frink.w3.org (localhost [127.0.0.1]) by frink.w3.org (8.12.8/8.12.8) with ESMTP id h2DFouNe019729; Thu, 13 Mar 2003 10:50:56 -0500 (EST) Received: (from lists@localhost) by frink.w3.org (8.12.8/8.12.8/Submit) id h2DFocND019704; Thu, 13 Mar 2003 10:50:38 -0500 (EST) Resent-Date: Thu, 13 Mar 2003 10:50:38 -0500 (EST) Resent-Message-Id: <200303131550.h2DFocND019704@frink.w3.org> Received: from tux.w3.org (IDENT:root@tux [18.29.0.27]) by frink.w3.org (8.12.8/8.12.8) with ESMTP id h2DFoZNe019668 for ; Thu, 13 Mar 2003 10:50:35 -0500 (EST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by tux.w3.org (8.12.8/8.12.8) with SMTP id h2DFoYrB027969 for ; Thu, 13 Mar 2003 10:50:35 -0500 Received: (qmail 6389 invoked by uid 0); 13 Mar 2003 15:50:28 -0000 Received: from mail.greenbytes.de (HELO lisa) (217.5.201.10) by mail.gmx.net (mp018-rz3) with SMTP; 13 Mar 2003 15:50:28 -0000 From: "Julian Reschke" To: Date: Thu, 13 Mar 2003 16:50:27 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) In-Reply-To: <200303061129.GAA03497@ietf.org> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Subject: RE: I-D ACTION:draft-ietf-webdav-rfc2518bis-03.txt X-Archived-At: http://www.w3.org/mid/JIEGINCHMLABHJBIGKBCOEAIGMAA.julian.reschke@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7488 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hi, I just reviewed the current draft, checking the issues I raised for draft 02 in September 2002: http://lists.w3.org/Archives/Public/w3c-dist-auth/2002JulSep/0372.html Unfortunately, it seems that almost all the issues I raised haven't been addressed. Below is an updated list: 1) References to RFC2616 References have been updated to point to RFC2616 rather than RFC2068, but it seems that all (most?) section numbers still need to be updated. 2) Section 4.4 Replace "MUST not" by "MUST NOT" 4) Section 6.3, p1 Replace "A lock token is returned by every successful LOCK operation in the lockdiscovery property in the response body, and can also be found through lock discovery on a resource." by "A lock token is returned by every successful LOCK operation in the lock-token header of the response, and can also be found through lock discovery on a resource" 5) Section 6.3, p3 Replace "However resources are free to return any URI scheme so long as it meets the uniqueness requirements." by "However servers are free to use any IETF-registered URI scheme so long as it meets the uniqueness requirements." (If it's not IETF-registered, I don't see how it can possibly meet the uniqueness criterium). 6) Section 8.1.1 (use of XML) Replace "Some of the following new HTTP methods use XML as a request and response format. All DAV compliant clients and resources MUST use XML parsers that are compliant with [REC-XML]. All XML used in either requests or responses MUST be, at minimum, well formed. If a server receives ill-formed XML in a request it MUST reject the entire request with a 400 (Bad Request)." by "Some of the following new HTTP methods use XML as a request and response format. All DAV compliant clients and resources MUST use XML parsers that are compliant with [REC-XML] and [REC-XML-NAMES]. All XML used in either requests or responses MUST be, at minimum, well formed and namespace-well-formed. If a server receives ill-formed XML in a request it MUST reject the entire request with a 400 (Bad Request)." 7) Section 8.1.2 (required bodies) says...: "In cases where a request body is present but would be ignored by a server, the server MUST reject the request with 415 (Unsupported Media Type)." I don't understand this requirement. If a body isn't defined, it should be ignored, right? (isn't MKCOL a special case?) 8) Section 8.1.4 (required headers) "Note that HTTP 1.1 requires the Date header in all responses." -> not true - clockless origin servers are treated as a special case 9) Section 8.2 "URLs for collections appearing in the results MUST end in a '/' character." -> I don't think we have consensus on this. Furthermore, this section seems to attempt to define a subset of relative URI resolution -- I think this is a VERY bad idea. Clients should properly resolve URIs against the request URI -- if we must, we can simplify this requirement by restricting the set of allowed relative URIs to those starting with an absolute path. 10) Section 8.2.2 "The resource http://www.foo.bar/container/index.html, a member of the "container" collection, has nine properties defined on it, http://www.foo.bar/boxschema/bigbox, DAV:creationdate, DAV:displayname, DAV:getcontentlength, DAV:getcontenttype, DAV:getetag, DAV:getlastmodified, DAV:resourcetype, and DAV:supportedlock." -> bad syntax for property names. Also: the example for propfind/allprop is missing. 11) Section 8.3 "All DAV compliant resources MUST support the PROPPATCH method and MUST process instructions that are specified using the propertyupdate, set, and remove XML elements of the DAV schema" -> What is the "DAV schema"??? Also, replace "Instruction processing MUST occur in the order instructions are received (i.e., from top to bottom)" by "Instruction processing MUST occur in document order" (standard XML processing term) 12) Section 8.7 Replace "424 (Failed Dependency) errors SHOULD NOT be in the 207 (Multi-Status)." by "424 (Failed Dependency) errors SHOULD NOT appear in the 207 (Multi-Status)." 13) Section 8.11, refreshing locks "A locks is refreshed by sending a new LOCK request to the resource which is the root of the lock." Question: does it really need to be the root? 14) Section 8.11, The Effect of Locks on Properties and Collections "This means that if a collection is locked, its lock-token is required in all these cases: - DELETE a collection's direct internal member - MOVE a member out of the collection - MOVE a member into the collection, unless it overwrites a pre-existing member" I think the latter is not really consistent with RFC3253. 15) Section 8.11, Locking unmapped URLs "A server MUST respond successfully to a GET request to an empty resource, either by using a 204 No Content response, or by using 200 OK with a Content-Length header indicating zero length and an server-determined Content-Type." Do not mention the content type at all. No content type is fine as well. 16) Section 8.11.2 Replace "Lock-Token: ()" by "Lock-Token: " 17) Section 8.12 Replace "A successful response to an UNLOCK method does not mean that the resource is unlocked." by "A successful response to an UNLOCK method does not mean that there are no locks left on the resource." (at least I think this is the intent of the sentence, otherwise it needs to be rephrased differently) 18) Section 9.1 I'd like to see the rational for the "extend" production. 19) Section 9.3 Language describing the process of relative URI resolution should go. 21) Section 11.4 Replace " - The server does not ever accept this method on this kind of resource. For example, a PUT is not accepted on a collection." by " - The server does not ever accept this method on this kind of resource. For example, if a PUT is not accepted on a collection." 22) Section 11.5 I think that there are *many* more cases that can cause a 409 (see RFC3253) 23) Section 12 Again, an attempt to define relative URI resolution. Don't do that, just refer to RFC2396 and say that URIs in a multistatus response are resolved against the request URI. 24) Section 12.1 Proposal: add an example. 25) Section 13.4 (lockroot) Proposal: only require it for deep locks. 26) Section 13.6 Replace: "Identifies the associated resource as a collection. The resourcetype property of a collection resource MUST have this value" by "Identifies the associated resource as a collection. The resourcetype property of a collection resource MUST contain this element." 27) Section 13.16 Remove "May contain additional elements not defined in this document." That's true for *all* XML in request/response bodies (also reccurs in other places) 28) Section 13.24 Replace "Language tagging information in the property's value (in the "xml:lang" attribute, if present MUST be persistently stored along with the property, and MUST be subsequently retrievable using PROPFIND." by "Language tagging information in scope of the property (in the "xml:lang" attribute, if present MUST be persistently stored along with the property, and MUST be subsequently retrievable using PROPFIND." 29) Section 13.26 Replace "The allprop XML element specifies that all property names and values on the resource are to be returned." by "The allprop XML element specifies that all names and values of all dead properties and the live properties defined by this document on the resource are to be returned." 30) Section 14.7 "A change in a property SHOULD NOT cause the last-modified date to change, because clients MAY rely on the last-modified date to know when to overwrite the existing body." I think this is a new requirement that hasn't been discussed. BTW: it's inconsistent with the attempt to make ETags a MUST -- if you have Etags, you don't have to rely on the last modified date anyway. 31) Section 18.6, Reduction of Security due to Source Link can be removed 32) Section 19, IANA consideration (old text) "URIs are used for both names, for several reasons. Assignment of a URI does not require a request to a central naming authority, and hence allow WebDAV property names and XML elements to be quickly defined by any WebDAV user or application. URIs also provide a unique address space, ensuring that the distributed users of WebDAV will not have collisions among the property names and XML elements they create" This is wrong. Properties are NOT identified by URIs. They are identified by XML QNames. 33) Editorial note I think that removing the section numbers from the 3rd-level section names is a bad idea. -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Thu Mar 13 13:51:40 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12561 for ; Thu, 13 Mar 2003 13:51:39 -0500 (EST) Received: from frink.w3.org (localhost [127.0.0.1]) by frink.w3.org (8.12.8/8.12.8) with ESMTP id h2DIod4g027204; Thu, 13 Mar 2003 13:50:39 -0500 (EST) Received: (from lists@localhost) by frink.w3.org (8.12.8/8.12.8/Submit) id h2DIoO2B027186; Thu, 13 Mar 2003 13:50:24 -0500 (EST) Resent-Date: Thu, 13 Mar 2003 13:50:24 -0500 (EST) Resent-Message-Id: <200303131850.h2DIoO2B027186@frink.w3.org> Received: from tux.w3.org (IDENT:root@tux [18.29.0.27]) by frink.w3.org (8.12.8/8.12.8) with ESMTP id h2DIoJ4g027154 for ; Thu, 13 Mar 2003 13:50:19 -0500 (EST) Received: from mac.wakasoft.com (64-60-92-50.cust.telepacific.net [64.60.92.50]) by tux.w3.org (8.12.8/8.12.8) with ESMTP id h2DIoJrB001642 for ; Thu, 13 Mar 2003 13:50:19 -0500 Received: from apache.org (localhost [127.0.0.1]) by mac.wakasoft.com (8.12.8/8.12.8) with ESMTP id h2DIUQ0V001016; Thu, 13 Mar 2003 10:30:26 -0800 (PST) Date: Thu, 13 Mar 2003 10:30:25 -0800 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: To: "Julian Reschke" From: "Roy T. Fielding" In-Reply-To: Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) Subject: Re: I-D ACTION:draft-ietf-webdav-rfc2518bis-03.txt X-Archived-At: http://www.w3.org/mid/DBB1ECCA-5581-11D7-AB36-000393753936@apache.org Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7489 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit > 6) Section 8.1.1 (use of XML) > > Replace > > "Some of the following new HTTP methods use XML as a request and > response > format. All DAV compliant clients and resources MUST use XML > parsers that > are compliant with [REC-XML]. All XML used in either requests or > responses > MUST be, at minimum, well formed. If a server receives ill-formed XML > in a > request it MUST reject the entire request with a 400 (Bad Request)." > > by > > "Some of the following new HTTP methods use XML as a request and > response > format. All DAV compliant clients and resources MUST use XML > parsers that > are compliant with [REC-XML] and [REC-XML-NAMES]. All XML used in > either > requests or responses MUST be, at minimum, well formed and > namespace-well-formed. If a server receives ill-formed XML in a > request it > MUST reject the entire request with a 400 (Bad Request)." Please note that use of an XML-compliant parser for an Internet protocol will introduce a simple and well-known denial-of-service problem involving recursive entity declarations. ....Roy From w3c-dist-auth-request@w3.org Thu Mar 13 14:00:56 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12897 for ; Thu, 13 Mar 2003 14:00:55 -0500 (EST) Received: from frink.w3.org (localhost [127.0.0.1]) by frink.w3.org (8.12.8/8.12.8) with ESMTP id h2DJ244g029218; Thu, 13 Mar 2003 14:02:04 -0500 (EST) Received: (from lists@localhost) by frink.w3.org (8.12.8/8.12.8/Submit) id h2DJ1uNI029192; Thu, 13 Mar 2003 14:01:56 -0500 (EST) Resent-Date: Thu, 13 Mar 2003 14:01:56 -0500 (EST) Resent-Message-Id: <200303131901.h2DJ1uNI029192@frink.w3.org> Received: from tux.w3.org (IDENT:root@tux [18.29.0.27]) by frink.w3.org (8.12.8/8.12.8) with ESMTP id h2DJ1q4g029159 for ; Thu, 13 Mar 2003 14:01:52 -0500 (EST) Received: from sus-ma1it31.rational.com (sus-ma1it31.rational.com [130.213.73.33]) by tux.w3.org (8.12.8/8.12.8) with ESMTP id h2DJ1qrB006312 for ; Thu, 13 Mar 2003 14:01:52 -0500 Received: from sus-ma1it00.rational.com ([10.64.1.25]) by 10.64.1.33 with InterScan Messaging Security Suite; Thu, 13 Mar 2003 13:45:20 -0500 Received: by sus-ma1it00.rational.com with Internet Mail Service (5.5.2656.59) id ; Thu, 13 Mar 2003 14:01:45 -0500 Message-ID: From: "Clemm, Geoff" To: "'WebDAV'" Date: Thu, 13 Mar 2003 14:01:45 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain Subject: RE: MOVEs across file systems X-Archived-At: http://www.w3.org/mid/E4F2D33B98DF7E4880884B9F0E6FDEE25ED71E@SUS-MA1IT01 Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7490 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: I've made the proposed modifications to the MOVE and DELETE constraints in the binding protocol in a new revision (01.3) of the binding protocol, as well as added a constraint to COPY, and posted it to the webdav binding web site. Here are the modified sections. This will be on the agenda for the WebDAV meeting next week, so if possible, please review this before then. Cheers, Geoff ------------------------------------------------ 2.3 COPY and Bindings As defined in Section 8.8 of [RFC2518], COPY causes the resource identified by the Request-URI to be duplicated, and makes the new resource accessible using the URI spechified in the Destination header. Upon successful completion of a COPY, a new binding is created between the last path segment of the Destination header, and the destination resource. The new binding is added to its parent collection, identified by the Destination header minus its final segment. The following figure shows an example: Suppose that a COPY is issued to URI-3 for resource R (which is also mapped to URI-1 and URI-2), with the Destination header set to URI-X. After successful completion of the COPY operation, resource R is duplicated to create resource R', and a new binding has been created which creates at least the URI mapping between URI-X and the new resource (although other URI mappings may also have been created). URI-1 URI-2 URI-3 URI-X | | | | | | | <---- URI Mappings ----> | | | | | +---------------------+ +------------------------+ | Resource R | | Resource R' | +---------------------+ +------------------------+ It might be thought that a COPY request with "Depth: 0" on a collection would duplicate its bindings, since bindings are part of the collection's state. This is not the case, however. The definition of Depth in [RFC2518] makes it clear that a "Depth: 0" request does not apply to a collection's members. Consequently, a COPY with "Depth: 0" does not duplicate the bindings contained by the collection. If a COPY causes one or more existing resources to be updated, the bindings to those resources MUST be unaffected by the COPY. Using the preceding example, suppose that a COPY is issued to URI-X for resource R', with the Destination header set to URI-2. The content and dead properties of resource R would be updated to be a copy of those of resource R', but the mappings from URI-1, URI-2, and URI-3 to resource R remain unaffected. 2.4 DELETE and Bindings When there are multiple bindings to a resource, a DELETE applied to that resource MUST NOT remove any bindings to that resource other than the one identified by the request URI. For example, suppose the collection identified by the URI "/a" has a binding named "x" to a resource R, and another collection identified by "/b" has a binding named "y" to the same resource R. Then a DELETE applied to "/a/x" removes the binding named "x" from "/a" but MUST NOT remove the binding named "y" from "/b" (i.e. after the DELETE, "/y/b" continues to identify the resource R). In particular, although Section 8.6.1 of [RFC2518] states that during DELETE processing, a server "MUST remove any URI for the resource identified by the Request-URI from collections which contain it as a member", a server that supports the binding protocol MUST NOT follow this requirement. When DELETE is applied to a collection, it MUST NOT modify the membership of any other collection that is not itself a member of the collection being deleted. For example, if both "/a/.../x" and "/b/.../y" identify the same collection, C, then applying DELETE to "/a" MUST NOT delete an internal member from C or from any other collection that is a member of C, because that would modify the membership of "/b". If a collection supports the UNBIND method (see Section 5), a DELETE of an internal member of a collection MAY be implemented as an UNBIND request. In this case, applying DELETE to a Request-URI has the effect of removing the binding identified by the final segment of the Request-URI from the collection identified by the Request-URI minus its final segment. Although [RFC2518] allows a DELETE to be a non-atomic operation, when the DELETE operation is implemented as an UNBIND, the operation is atomic. In particular, a DELETE on a hierarchy of resources is simply the removal of a binding to the collection identified by the Request-URI. 2.5 MOVE and Bindings When MOVE is applied to a resource, the other bindings to that resource MUST be unaffected, and if the resource being moved is a collection, the bindings to any members of that collection MUST be unaffected. Also, if MOVE is used with Overwrite:T to delete an existing resource, the constraints specified for DELETE apply. If the destination collection of a MOVE request supports the REBIND method (see Section 6), a MOVE of a resource into that collection MAY be implemented as a REBIND request. Although [RFC2518] allows a MOVE to be a non-atomic operation, when the MOVE operation is implemented as a REBIND, the operation is atomic. In particular, applying a MOVE to a Request-URI and a Destination URI has the effect of removing a binding to a resource (at the Request-URI), and creating a new binding to that resource (at the Destination URI). As an example, suppose that a MOVE is issued to URI-3 for resource R below (which is also mapped to URI-1 and URI-2), with the Destination header set to URI-X. After successful completion of the MOVE operation, a new binding has been created which creates the URI mapping between URI-X and resource R. The binding corresponding to the final segment of URI-3 has been removed, which also causes the URI mapping between URI-3 and R to be removed. If resource R were a collection, old URI-3 based mappings to members of R would have been removed, and new URI-X based mappings to members of R would have been created. >> Before Request: URI-1 URI-2 URI-3 | | | | | | <---- URI Mappings | | | +---------------------+ | Resource R | +---------------------+ >> After Request: URI-1 URI-2 URI-X | | | | | | <---- URI Mappings | | | +---------------------+ | Resource R | +---------------------+ Although [RFC2518] allows a MOVE on a collection to be a non-atomic operation, a MOVE implemented as an UNBIND MUST be atomic. Even when the Request-URI identifies a collection, the MOVE operation involves only removing one binding to that collection and adding another. There are no operations on bindings to any of its children, so the case of MOVE on a collection is the same as the case of MOVE on a non-collection resource. Both are atomic. ------------------------------------------------ -----Original Message----- From: Lisa Dusseault [mailto:lisa@xythos.com] Sent: Tuesday, March 11, 2003 1:11 PM To: 'Clemm, Geoff'; 'WebDAV' Subject: RE: MOVEs across file systems This is pretty good! I look forward to seeing it in context of the draft, when we can submit drafts again of course. > -----Original Message----- > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org] On Behalf Of Clemm, Geoff > Sent: Tuesday, March 11, 2003 9:10 AM > To: 'WebDAV' > Subject: RE: MOVEs across file systems > > > > Yeah, I didn't think that Julian's suggestion would be popular (:-). > > So I think realistically, we should focus on constraining the > behavior of MOVE/DELETE in the presence of multiple bindings > to the same resource, so that they don't violate the basic > requirements of multiple bindings. > > The current form of that proposal is: > > ---------------------------- > > Instead of saying: > > "DELETE SHOULD be UNBIND if UNBIND is supported" > > we should say something like: > > "When DELETE is applied to a collection, it MUST NOT modify the > membership of another collection, except when the collection > being deleted is itself a member of that other collection. > > For example, suppose /a/b/.../x identifies a collection C, > and there > is a second binding to C in a collection that is not a member of > /a/b, then "DELETE /a/b" MUST NOT delete the internal member > named "y" from C. > > And instead of saying: > > "MOVE SHOULD be REBIND if REBIND is supported" > > we should say something like: > > "When MOVE is applied to a resource, the other bindings > to that resource MUST be unaffected, and if the > resource being moved is a collection, the bindings to any > members of that collection MUST be unaffected. > Also, if MOVE is used with Overwrite:T to delete an > existing resource, the constraints specified for DELETE apply." > > ------------------ > > Cheers, > Geoff > > -----Original Message----- > From: Lisa Dusseault [mailto:lisa@xythos.com] > Sent: Tuesday, March 11, 2003 11:40 AM > To: 'Clemm, Geoff'; 'WebDAV' > Subject: RE: MOVEs across file systems > > > This is equivalent to the previous behavior as long as > clients continue > to issue the same MOVE and DELETE requests they have in the > past (which > they will for quite a while). Therefore, I don't see how this is a > change, or how this could possibly be acceptable if the previous > behavior was unacceptable. > > Servers must be able to support the binding specification, and to > support ordinary WebDAV clients, and to do what the server > implementors > consider to be the most appropriate and best job they can of > fulfilling > the request, and to report the results. This proposed statement does > not meet that requirement because it forces all servers to do atomic > MOVE/DELETE in handling requests from ordinary WebDAV clients. > > Lisa > > > -----Original Message----- > > From: w3c-dist-auth-request@w3.org > > [mailto:w3c-dist-auth-request@w3.org] On Behalf Of Clemm, Geoff > > Sent: Monday, March 10, 2003 12:18 PM > > To: 'WebDAV' > > Subject: RE: MOVEs across file systems > > > > > > > > That would be fine with me as well. > > > > Just to be clear, this means the binding spec would state: > > > > A server that supports BIND MUST implement MOVE/DELETE with > > rebind/unbind semantics. We will also define a parameter to > > MOVE/DELETE that allows a user to explicitly request the > > "best effort" style processing (that is OK because the user is > > explicitly stating that trashing multiple binding semantics is > > what they want). > > > > Cheers, > > Geoff > > > > -----Original Message----- > > From: Julian Reschke [mailto:julian.reschke@gmx.de] > > > > > From: Clemm, Geoff > > > So I'm happy to limit the constraints on MOVE and DELETE > to exactly > > > what is needed to preserve the semantics of multiple bindings, but > > > leaving them unconstrained makes the binding protocol pointless in > > > practice. > > > > On the other hand, a system that allows a "weak" MOVE if and > > only if there > > aren't any multiple bindings seems very weird to me. So maybe > > we should > > consider make MOVE "strong" by default, and only allow the > > old COPY/DELETE > > semantics upon specific request? > > > > > > From w3c-dist-auth-request@w3.org Thu Mar 13 14:38:28 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14568 for ; Thu, 13 Mar 2003 14:38:28 -0500 (EST) Received: from frink.w3.org (localhost [127.0.0.1]) by frink.w3.org (8.12.8/8.12.8) with ESMTP id h2DJdo4g005164; Thu, 13 Mar 2003 14:39:50 -0500 (EST) Received: (from lists@localhost) by frink.w3.org (8.12.8/8.12.8/Submit) id h2DJdmjE005098; Thu, 13 Mar 2003 14:39:48 -0500 (EST) Resent-Date: Thu, 13 Mar 2003 14:39:48 -0500 (EST) Resent-Message-Id: <200303131939.h2DJdmjE005098@frink.w3.org> Received: from tux.w3.org (IDENT:root@tux [18.29.0.27]) by frink.w3.org (8.12.8/8.12.8) with ESMTP id h2DJdj4g005065 for ; Thu, 13 Mar 2003 14:39:45 -0500 (EST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by tux.w3.org (8.12.8/8.12.8) with SMTP id h2DJdhrB016837 for ; Thu, 13 Mar 2003 14:39:44 -0500 Received: (qmail 3010 invoked by uid 0); 13 Mar 2003 19:39:38 -0000 Received: from p3EE24818.dip.t-dialin.net (HELO lisa) (62.226.72.24) by mail.gmx.net (mp017-rz3) with SMTP; 13 Mar 2003 19:39:38 -0000 From: "Julian Reschke" To: "Roy T. Fielding" , "Julian Reschke" Cc: Date: Thu, 13 Mar 2003 20:39:36 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 In-Reply-To: Importance: Normal Subject: RE: I-D ACTION:draft-ietf-webdav-rfc2518bis-03.txt X-Archived-At: http://www.w3.org/mid/JIEGINCHMLABHJBIGKBCCEBIGMAA.julian.reschke@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7491 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit Roy, known issue. RFC2518bis specifically allows rejection of requests using external entities (this should take care of the "one million laughs" attach). Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 > -----Original Message----- > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Roy T. Fielding > Sent: Thursday, March 13, 2003 7:30 PM > To: Julian Reschke > Cc: w3c-dist-auth@w3.org > Subject: Re: I-D ACTION:draft-ietf-webdav-rfc2518bis-03.txt > > > > > 6) Section 8.1.1 (use of XML) > > > > Replace > > > > "Some of the following new HTTP methods use XML as a request and > > response > > format. All DAV compliant clients and resources MUST use XML > > parsers that > > are compliant with [REC-XML]. All XML used in either requests or > > responses > > MUST be, at minimum, well formed. If a server receives ill-formed XML > > in a > > request it MUST reject the entire request with a 400 (Bad Request)." > > > > by > > > > "Some of the following new HTTP methods use XML as a request and > > response > > format. All DAV compliant clients and resources MUST use XML > > parsers that > > are compliant with [REC-XML] and [REC-XML-NAMES]. All XML used in > > either > > requests or responses MUST be, at minimum, well formed and > > namespace-well-formed. If a server receives ill-formed XML in a > > request it > > MUST reject the entire request with a 400 (Bad Request)." > > Please note that use of an XML-compliant parser for an Internet protocol > will introduce a simple and well-known denial-of-service problem > involving > recursive entity declarations. > > ....Roy > From w3c-dist-auth-request@w3.org Thu Mar 13 15:48:38 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18524 for ; Thu, 13 Mar 2003 15:48:38 -0500 (EST) Received: from frink.w3.org (localhost [127.0.0.1]) by frink.w3.org (8.12.8/8.12.8) with ESMTP id h2DKoA4g016041; Thu, 13 Mar 2003 15:50:10 -0500 (EST) Received: (from lists@localhost) by frink.w3.org (8.12.8/8.12.8/Submit) id h2DKo0P5015969; Thu, 13 Mar 2003 15:50:00 -0500 (EST) Resent-Date: Thu, 13 Mar 2003 15:50:00 -0500 (EST) Resent-Message-Id: <200303132050.h2DKo0P5015969@frink.w3.org> Received: from tux.w3.org (IDENT:root@tux [18.29.0.27]) by frink.w3.org (8.12.8/8.12.8) with ESMTP id h2DKnu4g015932 for ; Thu, 13 Mar 2003 15:49:57 -0500 (EST) Received: from mac.wakasoft.com (64-60-92-50.cust.telepacific.net [64.60.92.50]) by tux.w3.org (8.12.8/8.12.8) with ESMTP id h2DKnurB004214 for ; Thu, 13 Mar 2003 15:49:56 -0500 Received: from apache.org (localhost [127.0.0.1]) by mac.wakasoft.com (8.12.8/8.12.8) with ESMTP id h2DJpo0V001029; Thu, 13 Mar 2003 11:51:51 -0800 (PST) Date: Thu, 13 Mar 2003 11:51:50 -0800 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: To: "Julian Reschke" From: "Roy T. Fielding" In-Reply-To: Message-Id: <3B5C2F9F-558D-11D7-AB36-000393753936@apache.org> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) Subject: Re: I-D ACTION:draft-ietf-webdav-rfc2518bis-03.txt X-Archived-At: http://www.w3.org/mid/3B5C2F9F-558D-11D7-AB36-000393753936@apache.org Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7492 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit > known issue. Good, but that sentence you quoted contradicts it. XML doesn't allow subsetting. > RFC2518bis specifically allows rejection of requests using external > entities (this should take care of the "one million laughs" attach). Recursive entity declarations are internal entities. :( ....Roy From w3c-dist-auth-request@w3.org Thu Mar 13 16:06:38 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19161 for ; Thu, 13 Mar 2003 16:06:37 -0500 (EST) Received: from frink.w3.org (localhost [127.0.0.1]) by frink.w3.org (8.12.8/8.12.8) with ESMTP id h2DL5j4g019501; Thu, 13 Mar 2003 16:05:45 -0500 (EST) Received: (from lists@localhost) by frink.w3.org (8.12.8/8.12.8/Submit) id h2DL5hI0019483; Thu, 13 Mar 2003 16:05:43 -0500 (EST) Resent-Date: Thu, 13 Mar 2003 16:05:43 -0500 (EST) Resent-Message-Id: <200303132105.h2DL5hI0019483@frink.w3.org> Received: from tux.w3.org (IDENT:root@tux [18.29.0.27]) by frink.w3.org (8.12.8/8.12.8) with ESMTP id h2DL5f4g019451 for ; Thu, 13 Mar 2003 16:05:41 -0500 (EST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by tux.w3.org (8.12.8/8.12.8) with SMTP id h2DL5erB008156 for ; Thu, 13 Mar 2003 16:05:40 -0500 Received: (qmail 4160 invoked by uid 0); 13 Mar 2003 21:05:33 -0000 Received: from p3EE24818.dip.t-dialin.net (HELO lisa) (62.226.72.24) by mail.gmx.net (mp023-rz3) with SMTP; 13 Mar 2003 21:05:33 -0000 From: "Julian Reschke" To: "Roy T. Fielding" , "Julian Reschke" Cc: Date: Thu, 13 Mar 2003 22:05:30 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 In-Reply-To: <3B5C2F9F-558D-11D7-AB36-000393753936@apache.org> Importance: Normal Subject: RE: I-D ACTION:draft-ietf-webdav-rfc2518bis-03.txt X-Archived-At: http://www.w3.org/mid/JIEGINCHMLABHJBIGKBCEEBNGMAA.julian.reschke@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7493 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit > From: Roy T. Fielding [mailto:fielding@apache.org] > Sent: Thursday, March 13, 2003 8:52 PM > To: Julian Reschke > Cc: w3c-dist-auth@w3.org > Subject: Re: I-D ACTION:draft-ietf-webdav-rfc2518bis-03.txt > > > > known issue. > > Good, but that sentence you quoted contradicts it. XML doesn't > allow subsetting. Do you have a proposal how we can refer to the specs, and still allow subsetting (allowing rejection of internal entities)? > > RFC2518bis specifically allows rejection of requests using external > > entities (this should take care of the "one million laughs" attach). > > Recursive entity declarations are internal entities. :( Indeed. So I must take back what I said: the problem is known but has *not* been considered yet in the draft. Jason, Lisa: we badly need to add this to the issues list and fix it in the next draft. (the issue being: recursive entity declarations can be used for effective DOS attacks, and thus WebDAV MUST allow servers to reject these kind of requests, even though they may be well-formed). Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Thu Mar 13 16:35:57 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20082 for ; Thu, 13 Mar 2003 16:35:57 -0500 (EST) Received: from frink.w3.org (localhost [127.0.0.1]) by frink.w3.org (8.12.8/8.12.8) with ESMTP id h2DLb04g027957; Thu, 13 Mar 2003 16:37:00 -0500 (EST) Received: (from lists@localhost) by frink.w3.org (8.12.8/8.12.8/Submit) id h2DLap9K027921; Thu, 13 Mar 2003 16:36:51 -0500 (EST) Resent-Date: Thu, 13 Mar 2003 16:36:51 -0500 (EST) Resent-Message-Id: <200303132136.h2DLap9K027921@frink.w3.org> Received: from tux.w3.org (IDENT:root@tux [18.29.0.27]) by frink.w3.org (8.12.8/8.12.8) with ESMTP id h2DLam4g027885 for ; Thu, 13 Mar 2003 16:36:48 -0500 (EST) Received: from mac.wakasoft.com (64-60-92-50.cust.telepacific.net [64.60.92.50]) by tux.w3.org (8.12.8/8.12.8) with ESMTP id h2DLakrB017265 for ; Thu, 13 Mar 2003 16:36:47 -0500 Received: from apache.org (localhost [127.0.0.1]) by mac.wakasoft.com (8.12.8/8.12.8) with ESMTP id h2DLcK0V001036; Thu, 13 Mar 2003 13:38:20 -0800 (PST) Date: Thu, 13 Mar 2003 13:38:19 -0800 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: To: "Julian Reschke" From: "Roy T. Fielding" In-Reply-To: Message-Id: <1B60C21A-559C-11D7-A376-000393753936@apache.org> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) Subject: Re: I-D ACTION:draft-ietf-webdav-rfc2518bis-03.txt X-Archived-At: http://www.w3.org/mid/1B60C21A-559C-11D7-A376-000393753936@apache.org Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7494 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit > Do you have a proposal how we can refer to the specs, and still allow > subsetting (allowing rejection of internal entities)? Not a good one. The TAG has discussed it, and SOAP 1.2 has its own wording, but there is no general agreement on how it should be spec'd. SOAP disallows any form of internal DTD-style declaration. http://www.w3.org/2001/tag/ilist#xmlProfiles-29 ....Roy From w3c-dist-auth-request@w3.org Thu Mar 13 16:40:02 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20149 for ; Thu, 13 Mar 2003 16:40:02 -0500 (EST) Received: from frink.w3.org (localhost [127.0.0.1]) by frink.w3.org (8.12.8/8.12.8) with ESMTP id h2DLfA4g028555; Thu, 13 Mar 2003 16:41:10 -0500 (EST) Received: (from lists@localhost) by frink.w3.org (8.12.8/8.12.8/Submit) id h2DLf9Vo028549; Thu, 13 Mar 2003 16:41:09 -0500 (EST) Resent-Date: Thu, 13 Mar 2003 16:41:09 -0500 (EST) Resent-Message-Id: <200303132141.h2DLf9Vo028549@frink.w3.org> Received: from tux.w3.org (IDENT:root@tux [18.29.0.27]) by frink.w3.org (8.12.8/8.12.8) with ESMTP id h2DLf84g028517 for ; Thu, 13 Mar 2003 16:41:08 -0500 (EST) Received: from sunbelt.seagull.net (sunbelt.seagull.net [199.254.168.249]) by tux.w3.org (8.12.8/8.12.8) with ESMTP id h2DLf7rB018166 for ; Thu, 13 Mar 2003 16:41:08 -0500 Received: (mail@localhost) by sunbelt.seagull.net (8.9.3) id NAA15996 sender nn683849@smallcue.com for w3c-dist-auth@w3.org; Thu, 13 Mar 2003 13:40:59 -0800 Received: from e1.ny.us.ibm.com (e1.ny.us.ibm.com [32.97.182.101]) by sunbelt.seagull.net (8.9.3) with ESMTP id NAA15980 sender obsfucated@us.ibm.com; Thu, 13 Mar 2003 13:40:56 -0800 Received: from northrelay04.pok.ibm.com (northrelay04.pok.ibm.com [9.56.224.206]) by e1.ny.us.ibm.com (8.12.8/8.12.2) with ESMTP id h2DLeNW8041050; Thu, 13 Mar 2003 16:40:24 -0500 Received: from d01ml243.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by northrelay04.pok.ibm.com (8.12.8/NCO/VER6.5) with ESMTP id h2DLeKIn150882; Thu, 13 Mar 2003 16:40:20 -0500 To: "Julian Reschke" Cc: w3c-dist-auth@w3.org X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: Jason Crawford Date: Thu, 13 Mar 2003 16:35:11 -0500 X-MIMETrack: Serialize by Router on D01ML243/01/M/IBM(Release 6.0.1 [IBM]|March 12, 2003) at 03/13/2003 16:40:20 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Subject: RE: I-D ACTION:draft-ietf-webdav-rfc2518bis-03.txt X-Archived-At: http://www.w3.org/mid/OFCA04A573.B513BFFC-ON05256CE8.00767B5F@us.ibm.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7495 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: > (the issue being: recursive entity declarations can be used for effective > DOS attacks, and thus WebDAV MUST allow servers to reject these kind of > requests, even though they may be well-formed). Done. From w3c-dist-auth-request@w3.org Thu Mar 13 19:27:45 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA26849 for ; Thu, 13 Mar 2003 19:27:45 -0500 (EST) Received: from frink.w3.org (localhost [127.0.0.1]) by frink.w3.org (8.12.8/8.12.8) with ESMTP id h2E0T34g026651; Thu, 13 Mar 2003 19:29:03 -0500 (EST) Received: (from lists@localhost) by frink.w3.org (8.12.8/8.12.8/Submit) id h2E0Skjp026625; Thu, 13 Mar 2003 19:28:46 -0500 (EST) Resent-Date: Thu, 13 Mar 2003 19:28:46 -0500 (EST) Resent-Message-Id: <200303140028.h2E0Skjp026625@frink.w3.org> Received: from tux.w3.org (IDENT:root@tux [18.29.0.27]) by frink.w3.org (8.12.8/8.12.8) with ESMTP id h2E0Sh4g026593 for ; Thu, 13 Mar 2003 19:28:43 -0500 (EST) Received: from sunbelt.seagull.net (sunbelt.seagull.net [199.254.168.249]) by tux.w3.org (8.12.8/8.12.8) with ESMTP id h2E0ShrB024294 for ; Thu, 13 Mar 2003 19:28:43 -0500 Received: (mail@localhost) by sunbelt.seagull.net (8.9.3) id QAA27542 sender nn683849@smallcue.com for w3c-dist-auth@w3.org; Thu, 13 Mar 2003 16:28:42 -0800 Received: from e1.ny.us.ibm.com (e1.ny.us.ibm.com [32.97.182.101]) by sunbelt.seagull.net (8.9.3) with ESMTP id QAA27525 sender obsfucated@us.ibm.com; Thu, 13 Mar 2003 16:28:40 -0800 Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.56.224.150]) by e1.ny.us.ibm.com (8.12.8/8.12.2) with ESMTP id h2E0S8W8020662; Thu, 13 Mar 2003 19:28:08 -0500 Received: from d01ml243.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by northrelay02.pok.ibm.com (8.12.8/NCO/VER6.5) with ESMTP id h2E0S5Kn121178; Thu, 13 Mar 2003 19:28:05 -0500 To: "Julian Reschke" Cc: w3c-dist-auth@w3.org X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: Jason Crawford Date: Thu, 13 Mar 2003 19:26:14 -0500 X-MIMETrack: Serialize by Router on D01ML243/01/M/IBM(Release 6.0.1 [IBM]|March 12, 2003) at 03/13/2003 19:28:05 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Subject: RE: I-D ACTION:draft-ietf-webdav-rfc2518bis-03.txt X-Archived-At: http://www.w3.org/mid/OF95E611C0.3605CD13-ON05256CE8.007FDF4A@us.ibm.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7496 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: > 4) Section 6.3, p1 > > Replace > > "A lock token is returned by every successful LOCK operation in the > lockdiscovery property in the response body, and can also be found through > lock discovery on a resource." > > by > > "A lock token is returned by every successful LOCK operation in the > lock-token header of the response, and can also be found through lock > discovery on a resource" If we go with this wording, could we include a reference to the section that defines what "lock discovery" is. I did a quick search of the 2518bis and I don't think that's clear. We don't need to redefine it, but a pointer to the definition we're refering to would be good. > 5) Section 6.3, p3 > > Replace > > "However resources are free to return any URI scheme so long as it meets the > uniqueness requirements." > > by > > "However servers are free to use any IETF-registered URI scheme so long as > it meets the uniqueness requirements." I'd vote for leaving the old text. > 14) Section 8.11, The Effect of Locks on Properties and Collections > > "This means that if a collection is locked, its lock-token is required in > all these cases: > - DELETE a collection's direct internal member > - MOVE a member out of the collection > - MOVE a member into the collection, unless it overwrites a pre-existing > member" > > I think the latter is not really consistent with RFC3253. I think Lisa pointed it out, but the spec doesn't talk about URI protection. This section is probably a good place to mention it. Geoff came up with some wording that I don't have handy now. He and I disagreed with whether we should say that lock protection is for write locks or just locks. Anyway... The Effect of Locks on URL Mappings The resource located at the request-URI of the LOCK request MUST remain at that URI until the lock is removed via UNLOCK or until an operation with the proper lock-token header alters or destroys that mapping. This contraint insures that the principal that locked the resource will be able to find that resource at the same location as long as it holds the lock. Feel free to offer a better wording. > 15) Section 8.11, Locking unmapped URLs > > "A server MUST respond successfully to a GET request to an empty resource, > either by using a 204 No Content response, or by using 200 OK with a > Content-Length header indicating zero length and an server-determined > Content-Type." > > Do not mention the content type at all. No content type is fine as well. Interesting. Has this been discussed and resolved? (It just seems a bit odd.) > 19) Section 9.3 > > Language describing the process of relative URI resolution should go. I actually like it telling me (the reader) this explicitly. > 23) Section 12 > > Again, an attempt to define relative URI resolution. Don't do that, just > refer to RFC2396 and say that URIs in a multistatus response are resolved > against the request URI. I do agree that it should not be described more than once in 2518. A reference to a single place in the same document is fine with me. > > > 24) Section 12.1 > > Proposal: add an example. We might as well also say what 303 is just so that folks don't have to go searching for it. "302 (Found) and 303 (whatever)..." > 25) Section 13.4 (lockroot) > > Proposal: only require it for deep locks. I have no preference... unless we have a reason to want to know what URI mapping is protected. If we do, then it should apply even to depth 0 locks. FWIW... there is some sort of quotation marks around "rooted" in that section on that html page that don't show up right on my browsers. > 29) Section 13.26 > > Replace > > "The allprop XML element specifies that all property names and values on > the resource are to be returned." > > by > > "The allprop XML element specifies that all names and values of all dead > properties and the live properties defined by this document on the resource > are to be returned." I guess this is fine, although I think "this document" might be ambiguous. Perhaps, "this spec". > 30) Section 14.7 > > "A change in a property SHOULD NOT cause the last-modified date to change, > because clients MAY rely on the last-modified date to know when to overwrite > the existing body." > > I think this is a new requirement that hasn't been discussed. BTW: it's > inconsistent with the attempt to make ETags a MUST -- if you have Etags, you > don't have to rely on the last modified date anyway. I support what Lisa has added until we show that saying this is a bad idea. > 31) Section 18.6, Reduction of Security due to Source Link > > can be removed I tend to think 18.6 isn't necessary. I'm not heavily in to a lot of this sort of thing any more, but even to me it seems obvious. > 32) Section 19, IANA consideration (old text) > > "URIs are used for both names, for several reasons. Assignment of a URI does > not require a request to a central naming authority, and hence allow WebDAV > property names and XML elements to be quickly defined by any WebDAV user or > application. URIs also provide a unique address space, ensuring that the > distributed users of WebDAV will not have collisions among the property > names and XML elements they create" > > This is wrong. Properties are NOT identified by URIs. They are identified by > XML QNames. I tend to think the first part of section 19 is no longer necessary. It's not quite accurate and the information isn't really important and it's well known to anyone that has had to deal with XML namespaces... which will be everyone reading this. ------------------------------------------ Phone: 914-784-7569, ccjason@us.ibm.com I do not check nn621779@smallcue.com From w3c-dist-auth-request@w3.org Fri Mar 14 09:15:02 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA25836 for ; Fri, 14 Mar 2003 09:15:02 -0500 (EST) Received: from frink.w3.org (localhost [127.0.0.1]) by frink.w3.org (8.12.8/8.12.8) with ESMTP id h2EEGJ4g003756; Fri, 14 Mar 2003 09:16:19 -0500 (EST) Received: (from lists@localhost) by frink.w3.org (8.12.8/8.12.8/Submit) id h2EEG4pJ003737; Fri, 14 Mar 2003 09:16:04 -0500 (EST) Resent-Date: Fri, 14 Mar 2003 09:16:04 -0500 (EST) Resent-Message-Id: <200303141416.h2EEG4pJ003737@frink.w3.org> Received: from tux.w3.org (IDENT:root@tux [18.29.0.27]) by frink.w3.org (8.12.8/8.12.8) with ESMTP id h2EEG14g003705 for ; Fri, 14 Mar 2003 09:16:01 -0500 (EST) Received: from mail.gmx.net (mail.gmx.net [213.165.65.60]) by tux.w3.org (8.12.8/8.12.8) with SMTP id h2EEG1rB020073 for ; Fri, 14 Mar 2003 09:16:01 -0500 Received: (qmail 409 invoked by uid 0); 14 Mar 2003 14:15:55 -0000 Received: from unknown (HELO lisa) (217.5.201.10) by mail.gmx.net (mp001-rz3) with SMTP; 14 Mar 2003 15:15:55 +0100 From: "Julian Reschke" To: Date: Fri, 14 Mar 2003 15:15:55 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal In-reply-to: Subject: lock token URI schemes, RE: I-D ACTION:draft-ietf-webdav-rfc2518bis-03.txt X-Archived-At: http://www.w3.org/mid/JIEGINCHMLABHJBIGKBCMEDHGMAA.julian.reschke@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7497 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Jason Crawford > Sent: Friday, March 14, 2003 1:26 AM > To: Julian Reschke > Cc: w3c-dist-auth@w3.org > Subject: RE: I-D ACTION:draft-ietf-webdav-rfc2518bis-03.txt > > > ... > > > 5) Section 6.3, p3 > > > > Replace > > > > "However resources are free to return any URI scheme so long as it meets the > > uniqueness requirements." > > > > by > > > > "However servers are free to use any IETF-registered URI scheme so long as > > it meets the uniqueness requirements." > > I'd vote for leaving the old text. Hmmm. Do we disagree on a) the fact that it must be registered, or b) whether or not it needs to be stated? For a), my answer is that unless it is registered, it by definition can't meed the uniqueness requirements. For b), my answer is that I've seen servers inventing their "ad hoc" schemes, and this is exactly I want to warn about. See also: : "While "myscheme:blort" is a URI that satisfies the syntactic constraints of [RFC2396], if "myscheme" is not registered, you are not guaranteed that somebody else isn't already using it for something else." > ... Regards, Julian From w3c-dist-auth-request@w3.org Fri Mar 14 09:18:30 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA25861 for ; Fri, 14 Mar 2003 09:18:30 -0500 (EST) Received: from frink.w3.org (localhost [127.0.0.1]) by frink.w3.org (8.12.8/8.12.8) with ESMTP id h2EEK84g004481; Fri, 14 Mar 2003 09:20:08 -0500 (EST) Received: (from lists@localhost) by frink.w3.org (8.12.8/8.12.8/Submit) id h2EEK81k004473; Fri, 14 Mar 2003 09:20:08 -0500 (EST) Resent-Date: Fri, 14 Mar 2003 09:20:08 -0500 (EST) Resent-Message-Id: <200303141420.h2EEK81k004473@frink.w3.org> Received: from tux.w3.org (IDENT:root@tux [18.29.0.27]) by frink.w3.org (8.12.8/8.12.8) with ESMTP id h2EEK74g004418 for ; Fri, 14 Mar 2003 09:20:07 -0500 (EST) Received: from mail.gmx.net (mail.gmx.net [213.165.65.60]) by tux.w3.org (8.12.8/8.12.8) with SMTP id h2EEK5rB021082 for ; Fri, 14 Mar 2003 09:20:06 -0500 Received: (qmail 17403 invoked by uid 0); 14 Mar 2003 14:20:00 -0000 Received: from mail.greenbytes.de (HELO lisa) (217.5.201.10) by mail.gmx.net (mp005-rz3) with SMTP; 14 Mar 2003 14:20:00 -0000 From: "Julian Reschke" To: Date: Fri, 14 Mar 2003 15:19:59 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal In-reply-to: Subject: effects of locks on collections, was: RE: I-D ACTION:draft-ietf-webdav-rfc2518bis-03.txt X-Archived-At: http://www.w3.org/mid/JIEGINCHMLABHJBIGKBCCEDIGMAA.julian.reschke@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7498 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Jason Crawford > Sent: Friday, March 14, 2003 1:26 AM > To: Julian Reschke > Cc: w3c-dist-auth@w3.org > Subject: RE: I-D ACTION:draft-ietf-webdav-rfc2518bis-03.txt > > ... > > > 14) Section 8.11, The Effect of Locks on Properties and Collections > > > > "This means that if a collection is locked, its lock-token is > required in > > all these cases: > > - DELETE a collection's direct internal member > > - MOVE a member out of the collection > > - MOVE a member into the collection, unless it overwrites a pre-existing > > member" > > > > I think the latter is not really consistent with RFC3253. > > I think Lisa pointed it out, but the spec doesn't talk about URI protection. This > section is probably a good place to mention it. Geoff came up with some > wording that I don't have handy now. He and I disagreed with whether we > should say that lock protection is for write locks or just locks. > Anyway... Maybe this gets resolved by the adoption of GULP. I just wanted to clarify that a MOVE into a collection A overwriting a member *does* modify the state of the collection. > The Effect of Locks on URL Mappings > The resource located at the request-URI of the LOCK request MUST remain > at that URI until the lock is removed via UNLOCK or until an operation with the > proper lock-token header alters or destroys that mapping. This contraint insures > that the principal that locked the resource will be able to find that resource at the > same location as long as it holds the lock. > > Feel free to offer a better wording. I think the way to go is to get agreement on the current or a revised version of GULP, and use that in a single place within the spec. > ... Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Fri Mar 14 09:24:17 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA25948 for ; Fri, 14 Mar 2003 09:24:16 -0500 (EST) Received: from frink.w3.org (localhost [127.0.0.1]) by frink.w3.org (8.12.8/8.12.8) with ESMTP id h2EEPl4g009045; Fri, 14 Mar 2003 09:25:47 -0500 (EST) Received: (from lists@localhost) by frink.w3.org (8.12.8/8.12.8/Submit) id h2EEPl7R009039; Fri, 14 Mar 2003 09:25:47 -0500 (EST) Resent-Date: Fri, 14 Mar 2003 09:25:47 -0500 (EST) Resent-Message-Id: <200303141425.h2EEPl7R009039@frink.w3.org> Received: from tux.w3.org (IDENT:root@tux [18.29.0.27]) by frink.w3.org (8.12.8/8.12.8) with ESMTP id h2EEPj4g009007 for ; Fri, 14 Mar 2003 09:25:45 -0500 (EST) Received: from mail.gmx.net (mail.gmx.net [213.165.65.60]) by tux.w3.org (8.12.8/8.12.8) with SMTP id h2EEPirB022787 for ; Fri, 14 Mar 2003 09:25:45 -0500 Received: (qmail 9385 invoked by uid 0); 14 Mar 2003 14:25:39 -0000 Received: from mail.greenbytes.de (HELO lisa) (217.5.201.10) by mail.gmx.net (mp005-rz3) with SMTP; 14 Mar 2003 14:25:39 -0000 From: "Julian Reschke" To: Date: Fri, 14 Mar 2003 15:25:38 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal In-reply-to: Subject: resolving relative URIs, RE: I-D ACTION:draft-ietf-webdav-rfc2518bis-03.txt X-Archived-At: http://www.w3.org/mid/JIEGINCHMLABHJBIGKBCOEDIGMAA.julian.reschke@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7499 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Jason Crawford > Sent: Friday, March 14, 2003 1:26 AM > To: Julian Reschke > Cc: w3c-dist-auth@w3.org > Subject: RE: I-D ACTION:draft-ietf-webdav-rfc2518bis-03.txt > > ... > > > 19) Section 9.3 > > > > Language describing the process of relative URI resolution should go. > > I actually like it telling me (the reader) this explicitly. > > > 23) Section 12 > > > > Again, an attempt to define relative URI resolution. Don't do that, just > > refer to RFC2396 and say that URIs in a multistatus response are resolved > > against the request URI. > > I do agree that it should not be described more than once in 2518. A reference to > a single place in the same document is fine with me. OK, no matter what we do, there should only be *one* place in the spec describing it. The choices that I see are 1) we just define that RFC2396-defined relative URI resolution takes place (also defining what the base URL is in each case), 2) 1) + descriptive text or 3) something different that is compatible to 1), but disallows some specific cases. I'd vote for 1) (because that's what RFC2518 says and I haven't seen any convincing reason to change it yet). > .. Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Fri Mar 14 09:38:41 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA26399 for ; Fri, 14 Mar 2003 09:38:41 -0500 (EST) Received: from frink.w3.org (localhost [127.0.0.1]) by frink.w3.org (8.12.8/8.12.8) with ESMTP id h2EEeK4g019875; Fri, 14 Mar 2003 09:40:20 -0500 (EST) Received: (from lists@localhost) by frink.w3.org (8.12.8/8.12.8/Submit) id h2EEeKYk019863; Fri, 14 Mar 2003 09:40:20 -0500 (EST) Resent-Date: Fri, 14 Mar 2003 09:40:20 -0500 (EST) Resent-Message-Id: <200303141440.h2EEeKYk019863@frink.w3.org> Received: from tux.w3.org (IDENT:root@tux [18.29.0.27]) by frink.w3.org (8.12.8/8.12.8) with ESMTP id h2EEeI4g019830 for ; Fri, 14 Mar 2003 09:40:18 -0500 (EST) Received: from mail.xythos.com ([206.14.210.116]) by tux.w3.org (8.12.8/8.12.8) with ESMTP id h2EEe7rB029497 for ; Fri, 14 Mar 2003 09:40:07 -0500 Received: from ravms by mail.xythos.com with mail-ok (Exim 3.36 #3) id 18tqPA-0005tb-00 for w3c-dist-auth@w3c.org; Fri, 14 Mar 2003 14:43:28 +0000 Received: from [198.144.203.248] (helo=xythoslap) by mail.xythos.com with asmtp (Exim 3.36 #3) id 18tqPA-0005tQ-00 for w3c-dist-auth@w3c.org; Fri, 14 Mar 2003 14:43:28 +0000 From: "Lisa Dusseault" To: "Webdav WG" Date: Fri, 14 Mar 2003 06:40:05 -0800 Message-ID: <009601c2ea37$9a98ef10$f8cb90c6@xythoslap> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4024 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal Old-X-Envelope-To: w3c-dist-auth@w3c.org Subject: Supper after meeting? X-Archived-At: http://www.w3.org/mid/009601c2ea37$9a98ef10$f8cb90c6@xythoslap Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7501 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit Jim suggested an informal supper after the WebDAV meeting Tuesday. Does anybody have any suggestions where to go? If we get a bunch of rsvps by Monday, we could make a reservation somewhere. Lisa From w3c-dist-auth-request@w3.org Fri Mar 14 09:40:11 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA26469 for ; Fri, 14 Mar 2003 09:40:10 -0500 (EST) Received: from frink.w3.org (localhost [127.0.0.1]) by frink.w3.org (8.12.8/8.12.8) with ESMTP id h2EEfr4g022267; Fri, 14 Mar 2003 09:41:53 -0500 (EST) Received: (from lists@localhost) by frink.w3.org (8.12.8/8.12.8/Submit) id h2EEfppZ022166; Fri, 14 Mar 2003 09:41:51 -0500 (EST) Resent-Date: Fri, 14 Mar 2003 09:41:51 -0500 (EST) Resent-Message-Id: <200303141441.h2EEfppZ022166@frink.w3.org> Received: from tux.w3.org (IDENT:root@tux [18.29.0.27]) by frink.w3.org (8.12.8/8.12.8) with ESMTP id h2EEfg4g021904 for ; Fri, 14 Mar 2003 09:41:42 -0500 (EST) Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by tux.w3.org (8.12.8/8.12.8) with ESMTP id h2EEfItT029982 for ; Fri, 14 Mar 2003 09:41:36 -0500 Received: from mail.gmx.net (mail.gmx.net [213.165.65.60]) by frink.w3.org (8.12.8/8.12.8) with SMTP id h2EEWw4g015076 for ; Fri, 14 Mar 2003 09:32:58 -0500 (EST) Received: (qmail 24608 invoked by uid 0); 14 Mar 2003 14:32:52 -0000 Received: from mail.greenbytes.de (HELO lisa) (217.5.201.10) by mail.gmx.net (mp009-rz3) with SMTP; 14 Mar 2003 14:32:52 -0000 From: "Julian Reschke" To: Date: Fri, 14 Mar 2003 15:32:51 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal In-reply-to: Subject: source link, was: RE: I-D ACTION:draft-ietf-webdav-rfc2518bis-03.txt X-Archived-At: http://www.w3.org/mid/JIEGINCHMLABHJBIGKBCOEDJGMAA.julian.reschke@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7502 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Jason Crawford > Sent: Friday, March 14, 2003 1:26 AM > To: Julian Reschke > Cc: w3c-dist-auth@w3.org > Subject: RE: I-D ACTION:draft-ietf-webdav-rfc2518bis-03.txt > > ... > > > 31) Section 18.6, Reduction of Security due to Source Link > > > > can be removed > I tend to think 18.6 isn't necessary. I'm not heavily in to a lot of this sort of thing > any more, but even to me it seems obvious. :-) My point was that if there's no description of a source link in the document, we don't need to discuss it's security risk as well. > .. Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Fri Mar 14 10:41:15 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA26400 for ; Fri, 14 Mar 2003 09:38:41 -0500 (EST) Received: from frink.w3.org (localhost [127.0.0.1]) by frink.w3.org (8.12.8/8.12.8) with ESMTP id h2EEe74g019809; Fri, 14 Mar 2003 09:40:07 -0500 (EST) Received: (from lists@localhost) by frink.w3.org (8.12.8/8.12.8/Submit) id h2EEe506019785; Fri, 14 Mar 2003 09:40:05 -0500 (EST) Resent-Date: Fri, 14 Mar 2003 09:40:05 -0500 (EST) Resent-Message-Id: <200303141440.h2EEe506019785@frink.w3.org> Received: from tux.w3.org (IDENT:root@tux [18.29.0.27]) by frink.w3.org (8.12.8/8.12.8) with ESMTP id h2EEe34g019725 for ; Fri, 14 Mar 2003 09:40:03 -0500 (EST) Received: from mail.gmx.net (mail.gmx.net [213.165.65.60]) by tux.w3.org (8.12.8/8.12.8) with SMTP id h2EELvrB021400 for ; Fri, 14 Mar 2003 09:21:57 -0500 Received: (qmail 24552 invoked by uid 0); 14 Mar 2003 14:21:51 -0000 Received: from mail.greenbytes.de (HELO lisa) (217.5.201.10) by mail.gmx.net (mp006-rz3) with SMTP; 14 Mar 2003 14:21:51 -0000 From: "Julian Reschke" To: Date: Fri, 14 Mar 2003 15:21:51 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal In-reply-to: Subject: RE: I-D ACTION:draft-ietf-webdav-rfc2518bis-03.txt X-Archived-At: http://www.w3.org/mid/JIEGINCHMLABHJBIGKBCGEDIGMAA.julian.reschke@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7500 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Jason Crawford > Sent: Friday, March 14, 2003 1:26 AM > To: Julian Reschke > Cc: w3c-dist-auth@w3.org > Subject: RE: I-D ACTION:draft-ietf-webdav-rfc2518bis-03.txt > > ... > > > 15) Section 8.11, Locking unmapped URLs > > > > "A server MUST respond successfully to a GET request to an empty resource, > > either by using a 204 No Content response, or by using 200 OK with a > > Content-Length header indicating zero length and an server-determined > > Content-Type." > > > > Do not mention the content type at all. No content type is fine as well. > > Interesting. Has this been discussed and resolved? (It just seems a bit > odd.) I think it's odd to require the server to invent a content type if there actually isn't any content. I don't see how this would help any existing client. > ... Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Fri Mar 14 14:14:08 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09185 for ; Fri, 14 Mar 2003 14:14:07 -0500 (EST) Received: from frink.w3.org (localhost [127.0.0.1]) by frink.w3.org (8.12.8/8.12.8) with ESMTP id h2EJFW4g004739; Fri, 14 Mar 2003 14:15:32 -0500 (EST) Received: (from lists@localhost) by frink.w3.org (8.12.8/8.12.8/Submit) id h2EJFHMH004705; Fri, 14 Mar 2003 14:15:17 -0500 (EST) Resent-Date: Fri, 14 Mar 2003 14:15:17 -0500 (EST) Resent-Message-Id: <200303141915.h2EJFHMH004705@frink.w3.org> Received: from tux.w3.org (IDENT:root@tux [18.29.0.27]) by frink.w3.org (8.12.8/8.12.8) with ESMTP id h2EJFE4g004673 for ; Fri, 14 Mar 2003 14:15:14 -0500 (EST) Received: from sunbelt.seagull.net (sunbelt.seagull.net [199.254.168.249]) by tux.w3.org (8.12.8/8.12.8) with ESMTP id h2EJFDrB019084 for ; Fri, 14 Mar 2003 14:15:14 -0500 Received: (mail@localhost) by sunbelt.seagull.net (8.9.3) id LAA09780 sender nn683849@smallcue.com for w3c-dist-auth@w3.org; Fri, 14 Mar 2003 11:15:11 -0800 Received: from e4.ny.us.ibm.com (e4.ny.us.ibm.com [32.97.182.104]) by sunbelt.seagull.net (8.9.3) with ESMTP id LAA09764 sender obsfucated@us.ibm.com; Fri, 14 Mar 2003 11:15:09 -0800 Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.56.224.150]) by e4.ny.us.ibm.com (8.12.8/8.12.2) with ESMTP id h2EJEahF052598; Fri, 14 Mar 2003 14:14:36 -0500 Received: from d01ml243.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by northrelay02.pok.ibm.com (8.12.8/NCO/VER6.5) with ESMTP id h2EJEX99022832; Fri, 14 Mar 2003 14:14:34 -0500 To: "Julian Reschke" Cc: w3c-dist-auth@w3.org X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: Jason Crawford Date: Fri, 14 Mar 2003 14:09:54 -0500 X-MIMETrack: Serialize by Router on D01ML243/01/M/IBM(Release 6.0.1 [IBM]|March 12, 2003) at 03/14/2003 14:14:33 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Subject: Re: resolving relative URIs, RE: I-D ACTION:draft-ietf-webdav-rfc2518bis-03.txt X-Archived-At: http://www.w3.org/mid/OFECD2C570.DB984C7E-ON05256CE9.00692006@us.ibm.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7503 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: > The choices that I see are > > 1) we just define that RFC2396-defined relative URI resolution takes place > (also defining what the base URL is in each case), > > 2) 1) + descriptive text or > > 3) something different that is compatible to 1), but disallows some specific > cases. > > I'd vote for 1) (because that's what RFC2518 says and I haven't seen any > convincing reason to change it yet). Any of these are fine with me. (1) is fine with me if it indicates what the base URL is as you suggest. ------------------------------------------ Phone: 914-784-7569, ccjason@us.ibm.com I do not check nn621779@smallcue.com From w3c-dist-auth-request@w3.org Fri Mar 14 14:28:56 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09815 for ; Fri, 14 Mar 2003 14:28:55 -0500 (EST) Received: from frink.w3.org (localhost [127.0.0.1]) by frink.w3.org (8.12.8/8.12.8) with ESMTP id h2EJUO4g007402; Fri, 14 Mar 2003 14:30:24 -0500 (EST) Received: (from lists@localhost) by frink.w3.org (8.12.8/8.12.8/Submit) id h2EJUNQH007390; Fri, 14 Mar 2003 14:30:23 -0500 (EST) Resent-Date: Fri, 14 Mar 2003 14:30:23 -0500 (EST) Resent-Message-Id: <200303141930.h2EJUNQH007390@frink.w3.org> Received: from tux.w3.org (IDENT:root@tux [18.29.0.27]) by frink.w3.org (8.12.8/8.12.8) with ESMTP id h2EJUK4g007354 for ; Fri, 14 Mar 2003 14:30:20 -0500 (EST) Received: from sunbelt.seagull.net (sunbelt.seagull.net [199.254.168.249]) by tux.w3.org (8.12.8/8.12.8) with ESMTP id h2EJUJrB022511 for ; Fri, 14 Mar 2003 14:30:20 -0500 Received: (mail@localhost) by sunbelt.seagull.net (8.9.3) id LAA10827 sender nn683849@smallcue.com for w3c-dist-auth@w3.org; Fri, 14 Mar 2003 11:30:19 -0800 Received: from e4.ny.us.ibm.com (e4.ny.us.ibm.com [32.97.182.104]) by sunbelt.seagull.net (8.9.3) with ESMTP id LAA10811 sender obsfucated@us.ibm.com; Fri, 14 Mar 2003 11:30:17 -0800 Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.56.224.150]) by e4.ny.us.ibm.com (8.12.8/8.12.2) with ESMTP id h2EJTkhF068452; Fri, 14 Mar 2003 14:29:46 -0500 Received: from d01ml243.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by northrelay02.pok.ibm.com (8.12.8/NCO/VER6.5) with ESMTP id h2EJTh99054530; Fri, 14 Mar 2003 14:29:43 -0500 To: "Julian Reschke" Cc: w3c-dist-auth@w3.org X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: Jason Crawford Date: Fri, 14 Mar 2003 14:29:04 -0500 X-MIMETrack: Serialize by Router on D01ML243/01/M/IBM(Release 6.0.1 [IBM]|March 12, 2003) at 03/14/2003 14:29:43 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Subject: Re: lock token URI schemes, RE: I-D ACTION:draft-ietf-webdav-rfc2518bis-03.txt X-Archived-At: http://www.w3.org/mid/OF01E967AD.C39B53BD-ON05256CE9.00699AAC@us.ibm.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7504 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: > > > 5) Section 6.3, p3 > > > > > > Replace > > > > > > "However resources are free to return any URI scheme so long as it meets > the > > > uniqueness requirements." > > > > > > by > > > > > > "However servers are free to use any IETF-registered URI scheme so long > as > > > it meets the uniqueness requirements." > > > > I'd vote for leaving the old text. > > Hmmm. > > Do we disagree on > > a) the fact that it must be registered, or > > b) whether or not it needs to be stated? b) There are a number of issues about how to insure uniqueness. We don't need to cover all the mistakes they might make doing it. > See also: > > : If available, a reference to another document advising how to insure uniqueness should be fine. ------------------------------------------ Phone: 914-784-7569, ccjason@us.ibm.com I do not check nn621779@smallcue.com From w3c-dist-auth-request@w3.org Fri Mar 14 20:11:09 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA21871 for ; Fri, 14 Mar 2003 20:11:08 -0500 (EST) Received: from frink.w3.org (localhost [127.0.0.1]) by frink.w3.org (8.12.8/8.12.8) with ESMTP id h2F1CY4g026006; Fri, 14 Mar 2003 20:12:34 -0500 (EST) Received: (from lists@localhost) by frink.w3.org (8.12.8/8.12.8/Submit) id h2F1BmXp025987; Fri, 14 Mar 2003 20:11:48 -0500 (EST) Resent-Date: Fri, 14 Mar 2003 20:11:48 -0500 (EST) Resent-Message-Id: <200303150111.h2F1BmXp025987@frink.w3.org> Received: from tux.w3.org (IDENT:root@tux [18.29.0.27]) by frink.w3.org (8.12.8/8.12.8) with ESMTP id h2F1Bi4g025955 for ; Fri, 14 Mar 2003 20:11:44 -0500 (EST) Received: from ucsc.edu (cats-mx2.ucsc.edu [128.114.129.35]) by tux.w3.org (8.12.8/8.12.8) with ESMTP id h2F1BirB011791 for ; Fri, 14 Mar 2003 20:11:44 -0500 Received: from Tycho (dhcp-60-114.cse.ucsc.edu [128.114.60.114]) by ucsc.edu (8.10.1/8.10.1) with SMTP id h2F1BVG01482; Fri, 14 Mar 2003 17:11:31 -0800 (PST) From: "Jim Whitehead" To: "Lisa Dusseault" , "Webdav WG" Date: Fri, 14 Mar 2003 17:08:29 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <009601c2ea37$9a98ef10$f8cb90c6@xythoslap> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 X-UCSC-CATS-MailScanner: Found to be clean Subject: RE: Supper after meeting? X-Archived-At: http://www.w3.org/mid/AMEPKEBLDJJCCDEJHAMIEEOCGKAA.ejw@cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7505 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit > Jim suggested an informal supper after the WebDAV meeting Tuesday. Does > anybody have any suggestions where to go? If we get a bunch of rsvps by > Monday, we could make a reservation somewhere. Yes, meeting other DAV-interested people sounds like *much* more fun than sitting in traffic. :-) - Jim From w3c-dist-auth-request@w3.org Mon Mar 17 10:10:43 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15928 for ; Mon, 17 Mar 2003 10:10:43 -0500 (EST) Received: from frink.w3.org (localhost [127.0.0.1]) by frink.w3.org (8.12.8/8.12.8) with ESMTP id h2HFBs4g009287; Mon, 17 Mar 2003 10:11:54 -0500 (EST) Received: (from lists@localhost) by frink.w3.org (8.12.8/8.12.8/Submit) id h2HFBc38009259; Mon, 17 Mar 2003 10:11:38 -0500 (EST) Resent-Date: Mon, 17 Mar 2003 10:11:38 -0500 (EST) Resent-Message-Id: <200303171511.h2HFBc38009259@frink.w3.org> Received: from tux.w3.org (IDENT:root@tux [18.29.0.27]) by frink.w3.org (8.12.8/8.12.8) with ESMTP id h2HFBZ4g009197 for ; Mon, 17 Mar 2003 10:11:35 -0500 (EST) Received: from mail.gmx.net (mail.gmx.net [213.165.65.60]) by tux.w3.org (8.12.8/8.12.8) with SMTP id h2HFBYrB004199 for ; Mon, 17 Mar 2003 10:11:35 -0500 Received: (qmail 10498 invoked by uid 0); 17 Mar 2003 15:11:28 -0000 Received: from mail.greenbytes.de (HELO lisa) (217.5.201.10) by mail.gmx.net (mp009-rz3) with SMTP; 17 Mar 2003 15:11:28 -0000 From: "Julian Reschke" To: Date: Mon, 17 Mar 2003 16:11:28 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Subject: lock root, was: I-D ACTION:draft-ietf-webdav-rfc2518bis-03.txt X-Archived-At: http://www.w3.org/mid/JIEGINCHMLABHJBIGKBCIEJEGMAA.julian.reschke@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7506 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit > > 25) Section 13.4 (lockroot) > > > > Proposal: only require it for deep locks. > > I have no preference... unless we have a reason to want to know what URI mapping > is protected. If we do, then it should apply even to depth 0 locks. Right. I think I originally wrote this when I hadn't thought through the implications of multiple bindings to locks. The idea was to break old, mis-behaving clients (that do not use the WebDAV XML extensibility rules) only when we must (i.e., when it was collection lock with depth != 0). So yes, DAV:lockroot should always be present. > FWIW... there is some sort of quotation > marks around "rooted" in that section on that > html page that don't show up > right on my browsers. Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Mon Mar 17 13:44:03 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24493 for ; Mon, 17 Mar 2003 13:44:02 -0500 (EST) Received: from frink.w3.org (localhost [127.0.0.1]) by frink.w3.org (8.12.8/8.12.8) with ESMTP id h2HIj74g028029; Mon, 17 Mar 2003 13:45:07 -0500 (EST) Received: (from lists@localhost) by frink.w3.org (8.12.8/8.12.8/Submit) id h2HIij4E027889; Mon, 17 Mar 2003 13:44:45 -0500 (EST) Resent-Date: Mon, 17 Mar 2003 13:44:45 -0500 (EST) Resent-Message-Id: <200303171844.h2HIij4E027889@frink.w3.org> Received: from tux.w3.org (IDENT:root@tux [18.29.0.27]) by frink.w3.org (8.12.8/8.12.8) with ESMTP id h2HIig4g027840 for ; Mon, 17 Mar 2003 13:44:42 -0500 (EST) Received: from mail.gmx.net (mail.gmx.net [213.165.65.60]) by tux.w3.org (8.12.8/8.12.8) with SMTP id h2HIierB020899 for ; Mon, 17 Mar 2003 13:44:40 -0500 Received: (qmail 11066 invoked by uid 0); 17 Mar 2003 18:44:34 -0000 Received: from mail.greenbytes.de (HELO lisa) (217.5.201.10) by mail.gmx.net (mp008-rz3) with SMTP; 17 Mar 2003 18:44:34 -0000 From: "Julian Reschke" To: Date: Mon, 17 Mar 2003 19:44:34 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Subject: DAV properties / PROPFIND vs GET/HEAD X-Archived-At: http://www.w3.org/mid/JIEGINCHMLABHJBIGKBCKEJOGMAA.julian.reschke@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7507 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hi, RFC2518 currently says that the values of get* properties must match those HTTP headers returned upon a GET/HEAD request "without accept headers" (for instance, see 13.3). I'd like to see clarified a) the rational for this restriction, and b) a precise definition of what "accept" headers are. Looking at RFC2616, the only "accept" header is actually the one called "accept", while "accept-language" does not qualify. My personal preference would be to get rid of this language, unless we can agree on what it's supposed to accomplish, and rephrase it accordingly. I personally think that PROPFIND should be just an extended syntax for HEAD, supporting additional properties and allowing collection member retrieval, but stay completely compatible with the GET/HEAD response headers where possible. Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Tue Mar 18 01:34:12 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA20493 for ; Tue, 18 Mar 2003 01:34:12 -0500 (EST) Received: from frink.w3.org (localhost [127.0.0.1]) by frink.w3.org (8.12.8/8.12.8) with ESMTP id h2I6a04g010941; Tue, 18 Mar 2003 01:36:00 -0500 (EST) Received: (from lists@localhost) by frink.w3.org (8.12.8/8.12.8/Submit) id h2I6ZVRZ010878; Tue, 18 Mar 2003 01:35:31 -0500 (EST) Resent-Date: Tue, 18 Mar 2003 01:35:31 -0500 (EST) Resent-Message-Id: <200303180635.h2I6ZVRZ010878@frink.w3.org> Received: from tux.w3.org (IDENT:root@tux [18.29.0.27]) by frink.w3.org (8.12.8/8.12.8) with ESMTP id h2I6ZP4g010842 for ; Tue, 18 Mar 2003 01:35:25 -0500 (EST) Received: from mail.cruzio.com (mail.cruzio.com [63.249.95.37]) by tux.w3.org (8.12.8/8.12.8) with ESMTP id h2I6ZOrB012901 for ; Tue, 18 Mar 2003 01:35:25 -0500 Received: from Tycho (dsl3-63-249-68-18.cruzio.com [63.249.68.18]) by mail.cruzio.com with SMTP id h2I6aaR1015364 for ; Mon, 17 Mar 2003 22:36:37 -0800 (PST) From: "Jim Whitehead" To: "WebDAV" Date: Mon, 17 Mar 2003 22:32:10 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal Subject: FYI: DAV-related buffer overflow exploit in IIS 5 X-Archived-At: http://www.w3.org/mid/AMEPKEBLDJJCCDEJHAMIIEDMGLAA.ejw@cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7508 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 8bit FYI. So, how many implementors on the list are confident *you* don't also have a buffer overflow exploit lurking in your code? - Jim http://www.cert.org/advisories/CA-2003-09.html CERT® Advisory CA-2003-09 Buffer Overflow in Microsoft IIS 5.0 Original issue date: March 17, 2003 Last revised: Mon Mar 17 14:34:35 EST 2003 Source: CERT/CC A complete revision history is at the end of this file. Systems Affected Systems running Microsoft Windows 2000 with IIS 5.0 enabled Overview A buffer overflow vulnerability exists in Microsoft IIS 5.0 running on Microsoft Windows 2000. IIS 5.0 is installed and running by default on Microsoft Windows 2000 server products. This vulnerability may allow a remote attacker to run arbitrary code on the victim machine. An exploit is publicly available for this vulnerability, which increases the urgency that system administrators apply a patch. From w3c-dist-auth-request@w3.org Tue Mar 18 07:50:42 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA09765 for ; Tue, 18 Mar 2003 07:50:42 -0500 (EST) Received: from frink.w3.org (localhost [127.0.0.1]) by frink.w3.org (8.12.8/8.12.8) with ESMTP id h2ICq44g017884; Tue, 18 Mar 2003 07:52:04 -0500 (EST) Received: (from lists@localhost) by frink.w3.org (8.12.8/8.12.8/Submit) id h2ICprPr017698; Tue, 18 Mar 2003 07:51:53 -0500 (EST) Resent-Date: Tue, 18 Mar 2003 07:51:53 -0500 (EST) Resent-Message-Id: <200303181251.h2ICprPr017698@frink.w3.org> Received: from tux.w3.org (IDENT:root@tux [18.29.0.27]) by frink.w3.org (8.12.8/8.12.8) with ESMTP id h2ICpp4g017665 for ; Tue, 18 Mar 2003 07:51:51 -0500 (EST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by tux.w3.org (8.12.8/8.12.8) with SMTP id h2ICporB018539 for ; Tue, 18 Mar 2003 07:51:50 -0500 Received: (qmail 20174 invoked by uid 0); 18 Mar 2003 12:51:43 -0000 Received: from mail.greenbytes.de (HELO lisa) (217.5.201.10) by mail.gmx.net (mp012-rz3) with SMTP; 18 Mar 2003 12:51:43 -0000 From: "Julian Reschke" To: Date: Tue, 18 Mar 2003 13:51:43 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 In-Reply-To: <200303061129.GAA03497@ietf.org> Importance: Normal Subject: RE: I-D ACTION:draft-ietf-webdav-rfc2518bis-03.txt X-Archived-At: http://www.w3.org/mid/JIEGINCHMLABHJBIGKBCCEMGGMAA.julian.reschke@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7509 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 8bit Here's a set of both -bis03 and generic RFC2518 comments: Content: 03-C01 Paragraph 1: “A DTD is provided…” -> “An informational DTD is provided…” 03-C02 4.4: “…or when they may be shown to a human user and hence require encoding in…” I’m not sure what the requirement “may be shown to a human user” is supposed to mean here. Proposal: just write: “…or when they require encoding in…” 03-C03 4.4: “Note that the use of a new top-level URI identifier as a namespace is considered by many to be a bad thing…” Rewrite as: “Note that both defining a new URI scheme just for the purpose of identifying protocol elements, and using just the scheme name as a namespace name is to be considered a bad practice, and should not be copied”. 03-C04 4.5: “The value of a property when expressed in XML MUST be well formed.” The value of a property always is expressed in XML (or more precisely: an XML fragment). XML by definition is well-formed. 03-C05 4.5: “The value of a property appears inside the property name element. The value may be any text, including valid XML. When the value is structured as XML, namespaces that are in scope for that part of the XML document apply within the property value as well, and MUST be preserved in server storage for retransmission later. Namespace prefixes need not be preserved due to the rules of prefix declaration in XML.” 1) I think this needs to rephrased to use proper XML terminology, also 2) I think that namespace prefixes within the property value do need to be round.tripped. Proposal: “The value of a property appears inside the property name element and may be any kind of well-formed XML content, including both text-only and mixed content. When the property value contains further XML elements, namespaces and namespace prefixes that are in scope for that part of the XML document apply within the property value as well, and MUST be preserved in server storage for retransmission later.” 03-C06: 6.3: “A lock token is returned by every successful LOCK operation in the lockdiscovery property in the response body, and can also be found through lock discovery on a resource. Each lock has only one unique lock token.” Change to: “A lock token is returned by every successful LOCK operation in the lock-token header, and can also be found through lock discovery on a resource. Each lock has exactly one unique lock token.” 03-C07: 6.4: “All resources MUST recognize the opaquelocktoken scheme and, at minimum, recognize that the lock token does not refer to an outstanding lock on the resource.” (old text) I think this is misleading. Any resource must recognize any valid URI. If a URI uses a scheme it doesn’t know of, this simply means it doesn’t identify any particular lock assigned by this server. So I’d recommend to get rid of this sentence, and possibly add a clarification to 6.3 instead. 03-C08: 7.4: “However, interoperability and compliance problems have been found with lock-null resources. Therefore, they are deprecated. WebDAV servers compliant with this document SHOULD create regular locked empty resources, which behave in every way as if they were a normal resource.” This sort of suggests that lock-null resources indeed are still something different than a normal resource, which isn’t true. 03-C09: 7.4: “Can be downloaded, deleted, moved, copied, and in all ways behave as a regular resource, not a lock-null resource.” I think the term “downloaded” is misleading here. From a WebDAV protocol p.o.v., it probably should be “read”. 03-C10: 7.4.: “SHOULD default to a content-type of "application/octet-stream". “ No. I don’t think there’s consensus for that, and requiring a specific content type seems to have no value at all to clients (see also 8.11, “Locking Unmapped URLs”). 03-C11: 7.8: “If an error is received in response to a refresh LOCK request the client SHOULD assume that the lock was not refreshed.” I think we should make that a “MUST”. 03-C12: 8.1.1.: “Some of the following new HTTP methods use XML as a request and response format. All DAV compliant clients and resources MUST use XML parsers that are compliant with [REC-XML].” Add “…and [REC-XMLNS]”. We also need allow servers and clients to rejects a certain set of request/response that are indeed well-formed, in particular: - when it exceeds some predefined size or - when expansion of internal entities may cause a denial of service. 03-C13: 8.1.2: “Some of these new methods do not define bodies. Servers MUST examine all requests for a body, even when a body was not expected. In cases where a request body is present but would be ignored by a server, the server MUST reject the request with 415 (Unsupported Media Type). This informs the client (which may have been attempting to use an extension) that the body could not be processed as they intended.” I’d like to understand whether this affects methods other than MKCOL. 03-C14: 8.1.3: “When the Location header is used in a response, it is used by the server to indicate the preferred address for the target resource of the request. Whenever the server has a preferred address, it should use that address consistently. This means that when a response contains a Location header, all the URLs in the response body (e.g. a Multi-Status) should be consistent.” If we keep this paragraph, we’ll have to define what “consistent” means here. 03-C15: 8.1.4.: “Note that HTTP 1.1 requires the Date header in all responses.” That’s not true. HTTP 1.1 specifically supports clockless servers. 03-C16: 8.1.5: “If ETags are supported for a resource, the server MUST return the ETag header in all PUT and GET responses to that resource, as well as provide the same value for the 'getetag' property.” Note that this breaks the “etag promotion” strategy used both by IIS and Moddav (PUT usually returns weak etags which later are promoted to strong etags when there was no other change to that resource within a specific time window). Therefore I’d make that a SHOULD (at least for PUT). 03-C17: 8.1.5.: “Because clients may be forced to prompt users or throw away changed content if the ETag changes, a WebDAV server MUST not change the ETag (or getlastmodified value) for a resource when only its property values change.” Some servers do, and I don’t think we can change that. Therefore I think this change at least needs explicit consensus on the mailing list. 03-C18: 8.1.6: “HTTP and WebDAV did not use the bodies of most error responses until DeltaV introduced a mechanism to include more specific information in the body of an error response (section 1.6 of [RFC3253]).” That’s not really true. HTTP indeed recommends to send error descriptions in the response bodies as well. 03-C19: General comment re: 8.1.6: I really like that change (actually, I like it so much that I’d like to have condition names for all frequently signalled problems….). However, if it uses the same format as RFC3253, it should be consistent with it. In particular, the names should identify conditions that must be met. For instance, use “allow-external-entities” rather than “forbid-internal-entities”. We may also want to note that one DAV:error element can hold multiple elements identifying failed conditions. 03-C20: 8.2.: “DAV compliant servers MUST support the "0", "1" and "infinity" behaviors.” Change to: “DAV compliant servers MUST support the "0" and "1" behaviors and MAY support the "infinity" behavior.” 03-C21: 8.2.: “Note that ‘allprop’ does not return values for all properties.” Change to: “Note that ‘allprop’ does not return values for all live properties.” 03-C22: 8.2: “URLs for collections appearing in the results MUST end in a slash character.” I don’t think we have consensus for this being a MUST. 03-C23: 8.2: “Note that URLs and URIs in XML must always be fully legal URIs. For example, it is illegal to use a space character or double-quote in a URI [RFC2396]. URL-escaping is commonly used (e.g. replace a space with a sequence such as %20). The URI must not appear in XML "unescaped", it must be in its legal URI format.” This is misleading. Of course URIs must conform to the URI syntax – that’s the whole point, right? In particular, there’s no such thing as a “unescaped form” of a URI. URIs do not allow the space character, and therefore a URI never ever contains a space character. What we should say here is how servers should behave when their internal implementation model of collections allow member names that aren’t legal URL path segments (answer: encode as UTF-8 octet stream, then URI-escape). 03-C24: 8.2.2: “This example also demonstrates the use of XML namespace scoping, and the default namespace. Since the "xmlns" attribute does not contain an explicit "shorthand name" (prefix) letter, the namespace applies by default to all enclosed elements. Hence, all elements which do not explicitly state the namespace to which they belong are members of the "DAV:" namespace schema.” Change to: “This example also demonstrates the use of XML namespace scoping, and the default namespace. Since the "xmlns" attribute does not contain a prefix, the namespace applies by default to all non-prefixed enclosed elements. Hence, all elements which do not explicitly state the namespace to which they belong are members of the "DAV:" namespace.” (Actually I’d rather prefer to get rid of this. RFC2518bis shouldn’t try to give XML lessons). 03-C25: 8.7: “If the DELETE method is issued to a non-collection resource whose URIs are an internal member of one or more collections, then during DELETE processing a server MUST remove any URI for the resource identified by the Request-URI from collections which contain it as a member.” I think we want to get rid of this statement. Does anybody implement this right now? 03-C26: 8.11: “The LOCK request may have a Timeout header.” “may” -> “MAY”. 03-C27: 8.11, “Interaction with other Methods”: “However, independent of lock type, a successful DELETE of a resource MUST cause all of its locks to be removed.” (old text) I think this is misleading. A DELETE on a resource only removes those locks that aren’t inherited. 03-C28: 8.12: “A successful response to an UNLOCK method does not mean that the resource is unlocked. At most, it means that the specified token no longer identifies a lock on the resource.” Change to: “A successful response to an UNLOCK method does not mean that the resource is unlocked. At most, it means that the specified token no longer identifies a lock on any resource.” 03-C29: 9.1 (DAV header) allows coded URLs in the DAV header. I’d like to see the rationale for that. 03-C30: 9.4 (force-authenticate): is this the consensus we reached in January? Ilyas, did you take notes? 03-C31: 9.5 defines “” as a new special state token. I think this is unneeded – any URI which is known not to identify a lock MUST work as well, so we can simply recommend using something like “” (which is something that RFC2518-compliant servers already support). 03-C32: (old text) The example in 9.5.2 uses an invalid lock token (the URI scheme “locktoken” isn’t IETF-registered, so it can’t claim conformance to the uniqueness requirements). Just use a sample token using the “opaquelocktoken” scheme instead). 03-C33: 9.5.5: “The not production is used to reverse that value.” Change to: “The ‘Not’ production is used to reverse that value.” 03-C34: Section 13: XML element definitions I don’t like the syntax change in the DTDs. For instance, activelock now is defined as: ANY value: Any number of elements, including one of each of (lockscope, locktype, depth, owner, timeout, locktoken, lockroot) It used to be: For consistency with RFC2518, RFC3253 and the ACL spec we really should stay with the old notation. 03-C35: Section 17: “which has explicit provisions for character set tagging and encoding, and requires that XML processors read XML elements encoded, at minimum, using the UTF-8 [UTF-8] encoding of the ISO 10646 multilingual plane.” Unless we get rid of this section, we’ll have to add UTF-16. 03-C36: Section 17: “Names used within this specification fall into three categories: names of protocol elements such as methods and headers, names of XML elements, and names of properties.” We may want to add a new category (condition names). Editorial notes: 03-E01 Expiry date is wrong. 03-E02 IETF wants a maximum of 5 authors. 03-E03 Paragraph 1: “marshall” -> “marshal” 03-E04 There are many places where example URLs do not use the set of example host names allowed by the IETF. 03-E05 8.1.5 uses the term “etag”. HTTP uses “etag” only as header names, and talks about “entity tags” everywhere else. So should we. 03-E06 8.2.2 uses the term “progeny”, which I haven’t seen before in this context. Maybe replace by something more common, such as “members”. 03-E07: 8.2.2. still uses concatenation of namespace names and element names to identify property names. -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Tue Mar 18 14:47:20 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26510 for ; Tue, 18 Mar 2003 14:47:19 -0500 (EST) Received: from frink.w3.org (localhost [127.0.0.1]) by frink.w3.org (8.12.8/8.12.8) with ESMTP id h2IJmp4g020573; Tue, 18 Mar 2003 14:48:51 -0500 (EST) Received: (from lists@localhost) by frink.w3.org (8.12.8/8.12.8/Submit) id h2IJmFCp020383; Tue, 18 Mar 2003 14:48:15 -0500 (EST) Resent-Date: Tue, 18 Mar 2003 14:48:15 -0500 (EST) Resent-Message-Id: <200303181948.h2IJmFCp020383@frink.w3.org> Received: from tux.w3.org (IDENT:root@tux [18.29.0.27]) by frink.w3.org (8.12.8/8.12.8) with ESMTP id h2IJmC4g020351 for ; Tue, 18 Mar 2003 14:48:12 -0500 (EST) Received: from mail.xythos.com ([206.14.210.116]) by tux.w3.org (8.12.8/8.12.8) with ESMTP id h2IJmBrB024869 for ; Tue, 18 Mar 2003 14:48:11 -0500 Received: from ravms by mail.xythos.com with mail-ok (Exim 3.36 #3) id 18vN8W-0006Fh-00 for w3c-dist-auth@w3.org; Tue, 18 Mar 2003 19:52:36 +0000 Received: from [130.129.135.170] (helo=xythoslap) by mail.xythos.com with asmtp (Exim 3.36 #3) id 18vN8W-0006FW-00 for w3c-dist-auth@w3.org; Tue, 18 Mar 2003 19:52:36 +0000 From: "Lisa Dusseault" To: "'WebDAV'" Date: Tue, 18 Mar 2003 11:48:09 -0800 Message-ID: <006c01c2ed87$4daf7ef0$57868182@xythoslap> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4024 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal In-Reply-To: Old-X-Envelope-To: w3c-dist-auth@w3.org Subject: Submitting drafts via official channels X-Archived-At: http://www.w3.org/mid/006c01c2ed87$4daf7ef0$57868182@xythoslap Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7510 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit I've talked to a couple people about why the IETF has draft deadlines, since we've slipped a couple times in how we meet the deadlines and what we do about changes post-deadline. Basically the issue is fairness to everyone. 1. Participants need a chance to prepare. We all need about a week to read a reasonable number of drafts to prepare properly for an IETF meeting. 2. There needs to be a clear understanding what version we're all talking about. A version-number-less Web URL doesn't provide this clarity. It's likely to result in arguments about what version something appeared in. 3. People who don't participate in the mailing list very closely still ought to be able to catch up with the working group by reading drafts before showing up in the meeting. They won't know about drafts submitted after the deadline. Please make a greater effort to meet the draft deadline. We do deeply appreciate all the work that goes into drafts, and it is hard to meet deadlines. We also understand that the authors of the drafts benefit from unofficial side channels like Web pages to discuss work in progress, and that the draft authors may beneficially share these URLs with the whole working group. However, anything discussed in an official WG meeting ought to be submitted by the deadline. Lisa and Jim From w3c-dist-auth-request@w3.org Tue Mar 18 15:13:29 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28227 for ; Tue, 18 Mar 2003 15:13:29 -0500 (EST) Received: from frink.w3.org (localhost [127.0.0.1]) by frink.w3.org (8.12.8/8.12.8) with ESMTP id h2IKF84g024626; Tue, 18 Mar 2003 15:15:09 -0500 (EST) Received: (from lists@localhost) by frink.w3.org (8.12.8/8.12.8/Submit) id h2IKF4pk024576; Tue, 18 Mar 2003 15:15:04 -0500 (EST) Resent-Date: Tue, 18 Mar 2003 15:15:04 -0500 (EST) Resent-Message-Id: <200303182015.h2IKF4pk024576@frink.w3.org> Received: from tux.w3.org (IDENT:root@tux [18.29.0.27]) by frink.w3.org (8.12.8/8.12.8) with ESMTP id h2IKF14g024519 for ; Tue, 18 Mar 2003 15:15:01 -0500 (EST) Received: from post.webmailer.de (natsmtp00.webmailer.de [192.67.198.74]) by tux.w3.org (8.12.8/8.12.8) with ESMTP id h2IKF0rB001671 for ; Tue, 18 Mar 2003 15:15:01 -0500 Received: from x.oberon.ethz.ch (dialin-145-254-254-139.arcor-ip.net [145.254.254.139]) by post.webmailer.de (8.12.8/8.8.7) with SMTP id h2IKEt0f023735; Tue, 18 Mar 2003 21:14:57 +0100 (MET) Date: Tue, 18 Mar 2003 21:14:55 +0100 (MET) Message-Id: <200303182014.h2IKEt0f023735@post.webmailer.de> From: Edgar@edgarschwarz.de X-Mailer: Oberon Mail (ejz) on Aos 13.08.2002 To: w3c-dist-auth@w3.org Cc: frey@inf.ethz.ch Cc: Edgar@edgarschwarz.de Subject: Re: FYI: DAV-related buffer overflow exploit in IIS 5 X-Archived-At: http://www.w3.org/mid/200303182014.h2IKEt0f023735@post.webmailer.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7511 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: "Jim Whitehead" > FYI. > > So, how many implementors on the list are confident *you* don't also have a > buffer overflow exploit lurking in your code? > > - Jim > > http://www.cert.org/advisories/CA-2003-09.html > > CERTr Advisory CA-2003-09 Buffer Overflow in Microsoft IIS 5.0 > Original issue date: March 17, 2003 > Last revised: Mon Mar 17 14:34:35 EST 2003 > Source: CERT/CC A provocing question. So I think I will answer it: I'm pretty sure :-) I won't have a single line of C (The mother of all viruses) in my code and also on the whole server. In Oberon a buffer overflow can at most crash my WebDAV process and that's it. Edgar -- edgar@edgarschwarz.de "http://www.edgarschwarz.de" "http://www.edgar-schwarz.de/forum/oberon" Running Active Oberon Make it as simple as possible, but not simpler. Albert Einstein From w3c-dist-auth-request@w3.org Tue Mar 18 17:32:34 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03162 for ; Tue, 18 Mar 2003 17:32:33 -0500 (EST) Received: from frink.w3.org (localhost [127.0.0.1]) by frink.w3.org (8.12.8/8.12.8) with ESMTP id h2IMXr4g020013; Tue, 18 Mar 2003 17:33:53 -0500 (EST) Received: (from lists@localhost) by frink.w3.org (8.12.8/8.12.8/Submit) id h2IMXo49020006; Tue, 18 Mar 2003 17:33:50 -0500 (EST) Resent-Date: Tue, 18 Mar 2003 17:33:50 -0500 (EST) Resent-Message-Id: <200303182233.h2IMXo49020006@frink.w3.org> Received: from tux.w3.org (IDENT:root@tux [18.29.0.27]) by frink.w3.org (8.12.8/8.12.8) with ESMTP id h2IMXl4g019970 for ; Tue, 18 Mar 2003 17:33:47 -0500 (EST) Received: from sunbelt.seagull.net (sunbelt.seagull.net [199.254.168.249]) by tux.w3.org (8.12.8/8.12.8) with ESMTP id h2IMXirB012708 for ; Tue, 18 Mar 2003 17:33:46 -0500 Received: (mail@localhost) by sunbelt.seagull.net (8.9.3) id OAA28859 sender nn683849@smallcue.com for w3c-dist-auth@w3.org; Tue, 18 Mar 2003 14:33:38 -0800 Received: from e6.ny.us.ibm.com (e6.ny.us.ibm.com [32.97.182.106]) by sunbelt.seagull.net (8.9.3) with ESMTP id OAA28837 sender obsfucated@us.ibm.com; Tue, 18 Mar 2003 14:33:37 -0800 Received: from northrelay04.pok.ibm.com (northrelay04.pok.ibm.com [9.56.224.206]) by e6.ny.us.ibm.com (8.12.8/8.12.2) with ESMTP id h2IMX5MY189690; Tue, 18 Mar 2003 17:33:05 -0500 Received: from d01ml243.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by northrelay04.pok.ibm.com (8.12.8/NCO/VER6.5) with ESMTP id h2IMX24r168708; Tue, 18 Mar 2003 17:33:03 -0500 To: "Julian Reschke" Cc: w3c-dist-auth@w3.org X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: Jason Crawford Date: Tue, 18 Mar 2003 17:31:35 -0500 X-MIMETrack: Serialize by Router on D01ML243/01/M/IBM(Release 6.0.1 [IBM]|March 12, 2003) at 03/18/2003 17:33:02 MIME-Version: 1.0 Content-type: text/plain; charset=UTF-8 Subject: RE: I-D ACTION:draft-ietf-webdav-rfc2518bis-03.txt X-Archived-At: http://www.w3.org/mid/OF13D307B8.AA48555C-ON05256CED.0079FE8B@us.ibm.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7512 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: DQoNCg0KDQo8PA0KNC40OiDigJxOb3RlIHRoYXQgdGhlIHVzZSBvZiBhIG5ldyB0b3AtbGV2ZWwg VVJJIGlkZW50aWZpZXIgYXMgYSBuYW1lc3BhY2UgaXMNCmNvbnNpZGVyZWQgYnkgbWFueSB0byBi ZSBhIGJhZCB0aGluZ+KApuKAnQ0KDQpSZXdyaXRlIGFzOg0KDQrigJxOb3RlIHRoYXQgYm90aCBk ZWZpbmluZyBhIG5ldyBVUkkgc2NoZW1lIGp1c3QgZm9yIHRoZSBwdXJwb3NlIG9mDQppZGVudGlm eWluZyBwcm90b2NvbCBlbGVtZW50cywgYW5kIHVzaW5nIGp1c3QgdGhlIHNjaGVtZSBuYW1lIGFz IGENCm5hbWVzcGFjZQ0KbmFtZSBpcyB0byBiZSBjb25zaWRlcmVkIGEgYmFkIHByYWN0aWNlLCBh bmQgc2hvdWxkIG5vdCBiZSBjb3BpZWTigJ0uDQo+Pg0KSSBhZ3JlZSB0aGF0IHdlJ3ZlIGFsbCBk ZWNpZGVkIGl0J3Mgbm90IGdvb2QuICBJJ20gYW1iaXZhbGVudCBhYm91dA0Kd2hhdCB0byBkbyBh Ym91dCB0aGF0LCBhbmQgSSBoYXZlIG5vIHByb2JsZW0gd2l0aCB3aGF0IEp1bGlhbiBwcm9wb3Nl cy4NCg0KPDwNCjQuNTog4oCcVGhlIHZhbHVlIG9mIGEgcHJvcGVydHkgYXBwZWFycyBpbnNpZGUg dGhlIHByb3BlcnR5IG5hbWUgZWxlbWVudC4NClRoZQ0KdmFsdWUgbWF5IGJlIGFueSB0ZXh0LCBp bmNsdWRpbmcgdmFsaWQgWE1MLiAgV2hlbiB0aGUgdmFsdWUgaXMgIHN0cnVjdHVyZWQNCmFzIFhN TCwgbmFtZXNwYWNlcyB0aGF0IGFyZSBpbiBzY29wZSBmb3IgdGhhdCBwYXJ0IG9mIHRoZSAgWE1M IGRvY3VtZW50DQphcHBseSB3aXRoaW4gdGhlIHByb3BlcnR5IHZhbHVlIGFzIHdlbGwsIGFuZCBN VVNUIGJlICBwcmVzZXJ2ZWQgaW4gc2VydmVyDQpzdG9yYWdlIGZvciByZXRyYW5zbWlzc2lvbiBs YXRlci4gTmFtZXNwYWNlIHByZWZpeGVzIG5lZWQgbm90IGJlIHByZXNlcnZlZA0KZHVlIHRvIHRo ZSBydWxlcyBvZiBwcmVmaXggZGVjbGFyYXRpb24gaW4gWE1MLuKAnQ0KDQoxKSAgICAgICAgICAg SSB0aGluayB0aGlzIG5lZWRzIHRvIHJlcGhyYXNlZCB0byB1c2UgcHJvcGVyIFhNTCB0ZXJtaW5v bG9neSwNCmFsc28NCj4+DQpJIGRlZmVyIHRvIEp1bGlhbidzIGV4cGVydGlzZSBvbiB0aGF0Lg0K DQo8PA0KMikgICAgICAgICAgIEkgdGhpbmsgdGhhdCBuYW1lc3BhY2UgcHJlZml4ZXMgd2l0aGlu IHRoZSBwcm9wZXJ0eSB2YWx1ZSBkbw0KbmVlZCB0byBiZQ0Kcm91bmQudHJpcHBlZC4NCj4+DQpQ bGVhc2UgcmVtaW5kIHVzIHdoeSB0aGF0J3MgaW1wb3J0YW50Lg0KDQoNCjw8DQowMy1DMDY6DQoN CjYuMzog4oCcQSBsb2NrIHRva2VuIGlzIHJldHVybmVkIGJ5IGV2ZXJ5IHN1Y2Nlc3NmdWwgTE9D SyBvcGVyYXRpb24gaW4gdGhlDQpsb2NrZGlzY292ZXJ5IHByb3BlcnR5IGluIHRoZSByZXNwb25z ZSBib2R5LCBhbmQgY2FuIGFsc28gYmUgZm91bmQgdGhyb3VnaA0KbG9jayBkaXNjb3Zlcnkgb24g YSAgcmVzb3VyY2UuIEVhY2ggbG9jayBoYXMgb25seSBvbmUgdW5pcXVlIGxvY2sgdG9rZW4u4oCd DQoNCkNoYW5nZSB0bzoNCg0K4oCcQSBsb2NrIHRva2VuIGlzIHJldHVybmVkIGJ5IGV2ZXJ5IHN1 Y2Nlc3NmdWwgTE9DSyBvcGVyYXRpb24gaW4gdGhlDQpsb2NrLXRva2VuIGhlYWRlciwgYW5kIGNh biBhbHNvIGJlIGZvdW5kIHRocm91Z2ggbG9jayBkaXNjb3Zlcnkgb24gYQ0KcmVzb3VyY2UuIEVh Y2ggbG9jayBoYXMgZXhhY3RseSBvbmUgdW5pcXVlIGxvY2sgdG9rZW4u4oCdDQo+Pg0KR29vZCBj YXRjaCA6LSkNCg0KSSdsbCBoYXZlIHRvIGdvIHRocm91Z2ggdGhlIHJlc3Qgb2YgdGhlIG5vdGUg bGF0ZXIuLi4NCg0KSi4NCg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tDQpQaG9uZTogOTE0LTc4NC03NTY5LCAgIGNjamFzb25AdXMuaWJtLmNvbQ0KSSBkbyBub3Qg Y2hlY2sgbm42MjE3NzlAc21hbGxjdWUuY29tDQoNCg0KDQogICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICANCiAgICAgICAgICAgICAgICAgICAgICAiSnVsaWFuIFJlc2Noa2UiICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIA0KICAgICAgICAgICAgICAgICAgICAg IDxubmp1bGlhbi5yZXNjaGtlX19fYXRfX19nbXguZGVAc21hbGxjdSAgICAgICAgVG86ICAgICAg IDxubnczYy1kaXN0LWF1dGhfX19hdF9fX3czLm9yZ0BzbWFsbGN1ZS5jb20+ICAgICAgICAgICAg ICAgICAgDQogICAgICAgICAgICAgICAgICAgICAgZS5jb20+ICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICBjYzogICAgICAgImNjamFzb25AdXMuaWJtLmNvbSIgPGFwcGVh cmFzX25uNjgzODQ5QHNtYWxsY3VlLmNvbT4gICAgICAgICANCiAgICAgICAgICAgICAgICAgICAg ICBTZW50IGJ5OiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFN1YmplY3Q6 ICBSRTogSS1EIEFDVElPTjpkcmFmdC1pZXRmLXdlYmRhdi1yZmMyNTE4YmlzLTAzLnR4dCAgICAg ICAgICAgIA0KICAgICAgICAgICAgICAgICAgICAgIG5udzNjLWRpc3QtYXV0aC1yZXF1ZXN0X19f YXRfX193My5vcmdAcyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgDQogICAgICAgICAgICAgICAgICAg ICAgbWFsbGN1ZS5jb20gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICANCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIA0KICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgDQogICAgICAgICAgICAgICAgICAgICAgMDMvMTgvMjAwMyAwNzo1MSBBTSAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICANCiAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgDQoNCg0KDQoNCkhlcmUncyBh IHNldCBvZiBib3RoIC1iaXMwMyBhbmQgZ2VuZXJpYyBSRkMyNTE4IGNvbW1lbnRzOg0KDQpDb250 ZW50Og0KDQowMy1DMDENCg0KUGFyYWdyYXBoIDE6IOKAnEEgRFREIGlzIHByb3ZpZGVk4oCm4oCd IC0+IOKAnEFuIGluZm9ybWF0aW9uYWwgRFREIGlzIHByb3ZpZGVk4oCm4oCdDQoNCg0KMDMtQzAy DQoNCjQuNDog4oCc4oCmb3Igd2hlbiB0aGV5IG1heSBiZSBzaG93biB0byBhIGh1bWFuIHVzZXIg YW5kIGhlbmNlIHJlcXVpcmUgZW5jb2RpbmcNCmlu4oCm4oCdDQoNCknigJltIG5vdCBzdXJlIHdo YXQgdGhlIHJlcXVpcmVtZW50IOKAnG1heSBiZSBzaG93biB0byBhIGh1bWFuIHVzZXLigJ0gaXMN CnN1cHBvc2VkDQp0byBtZWFuIGhlcmUuIFByb3Bvc2FsOiBqdXN0IHdyaXRlOg0KDQrigJzigKZv ciB3aGVuIHRoZXkgcmVxdWlyZSBlbmNvZGluZyBpbuKApuKAnQ0KDQoNCjAzLUMwMw0KDQoNCjAz LUMwNA0KDQo0LjU6IOKAnFRoZSB2YWx1ZSBvZiBhIHByb3BlcnR5IHdoZW4gZXhwcmVzc2VkIGlu IFhNTCBNVVNUIGJlIHdlbGwgZm9ybWVkLuKAnQ0KDQpUaGUgdmFsdWUgb2YgYSBwcm9wZXJ0eSBh bHdheXMgaXMgZXhwcmVzc2VkIGluIFhNTCAob3IgbW9yZSBwcmVjaXNlbHk6IGFuDQpYTUwgZnJh Z21lbnQpLiBYTUwgYnkgZGVmaW5pdGlvbiBpcyB3ZWxsLWZvcm1lZC4NCg0KDQowMy1DMDUNCg0K NC41OiDigJxUaGUgdmFsdWUgb2YgYSBwcm9wZXJ0eSBhcHBlYXJzIGluc2lkZSB0aGUgcHJvcGVy dHkgbmFtZSBlbGVtZW50Lg0KVGhlDQp2YWx1ZSBtYXkgYmUgYW55IHRleHQsIGluY2x1ZGluZyB2 YWxpZCBYTUwuICBXaGVuIHRoZSB2YWx1ZSBpcyAgc3RydWN0dXJlZA0KYXMgWE1MLCBuYW1lc3Bh Y2VzIHRoYXQgYXJlIGluIHNjb3BlIGZvciB0aGF0IHBhcnQgb2YgdGhlICBYTUwgZG9jdW1lbnQN CmFwcGx5IHdpdGhpbiB0aGUgcHJvcGVydHkgdmFsdWUgYXMgd2VsbCwgYW5kIE1VU1QgYmUgIHBy ZXNlcnZlZCBpbiBzZXJ2ZXINCnN0b3JhZ2UgZm9yIHJldHJhbnNtaXNzaW9uIGxhdGVyLiBOYW1l c3BhY2UgcHJlZml4ZXMgbmVlZCBub3QgYmUgcHJlc2VydmVkDQpkdWUgdG8gdGhlIHJ1bGVzIG9m IHByZWZpeCBkZWNsYXJhdGlvbiBpbiBYTUwu4oCdDQoNCjEpICAgICAgICAgICBJIHRoaW5rIHRo aXMgbmVlZHMgdG8gcmVwaHJhc2VkIHRvIHVzZSBwcm9wZXIgWE1MIHRlcm1pbm9sb2d5LA0KYWxz bw0KMikgICAgICAgICAgIEkgdGhpbmsgdGhhdCBuYW1lc3BhY2UgcHJlZml4ZXMgd2l0aGluIHRo ZSBwcm9wZXJ0eSB2YWx1ZSBkbw0KbmVlZCB0byBiZQ0Kcm91bmQudHJpcHBlZC4NCg0KUHJvcG9z YWw6DQoNCuKAnFRoZSB2YWx1ZSBvZiBhIHByb3BlcnR5IGFwcGVhcnMgaW5zaWRlIHRoZSBwcm9w ZXJ0eSBuYW1lIGVsZW1lbnQgYW5kIG1heQ0KYmUNCmFueSBraW5kIG9mIHdlbGwtZm9ybWVkIFhN TCBjb250ZW50LCBpbmNsdWRpbmcgYm90aCB0ZXh0LW9ubHkgYW5kIG1peGVkDQpjb250ZW50LiBX aGVuIHRoZSBwcm9wZXJ0eSB2YWx1ZSBjb250YWlucyBmdXJ0aGVyIFhNTCBlbGVtZW50cywgbmFt ZXNwYWNlcw0KYW5kIG5hbWVzcGFjZSBwcmVmaXhlcyB0aGF0IGFyZSBpbiBzY29wZSBmb3IgdGhh dCBwYXJ0IG9mIHRoZSBYTUwgZG9jdW1lbnQNCmFwcGx5IHdpdGhpbiB0aGUgcHJvcGVydHkgdmFs dWUgYXMgd2VsbCwgYW5kIE1VU1QgYmUgcHJlc2VydmVkIGluIHNlcnZlcg0Kc3RvcmFnZSBmb3Ig cmV0cmFuc21pc3Npb24gbGF0ZXIu4oCdDQoNCg0KMDMtQzA2Og0KDQo2LjM6IOKAnEEgbG9jayB0 b2tlbiBpcyByZXR1cm5lZCBieSBldmVyeSBzdWNjZXNzZnVsIExPQ0sgb3BlcmF0aW9uIGluIHRo ZQ0KbG9ja2Rpc2NvdmVyeSBwcm9wZXJ0eSBpbiB0aGUgcmVzcG9uc2UgYm9keSwgYW5kIGNhbiBh bHNvIGJlIGZvdW5kIHRocm91Z2gNCmxvY2sgZGlzY292ZXJ5IG9uIGEgIHJlc291cmNlLiBFYWNo IGxvY2sgaGFzIG9ubHkgb25lIHVuaXF1ZSBsb2NrIHRva2VuLuKAnQ0KDQpDaGFuZ2UgdG86DQoN CuKAnEEgbG9jayB0b2tlbiBpcyByZXR1cm5lZCBieSBldmVyeSBzdWNjZXNzZnVsIExPQ0sgb3Bl cmF0aW9uIGluIHRoZQ0KbG9jay10b2tlbiBoZWFkZXIsIGFuZCBjYW4gYWxzbyBiZSBmb3VuZCB0 aHJvdWdoIGxvY2sgZGlzY292ZXJ5IG9uIGENCnJlc291cmNlLiBFYWNoIGxvY2sgaGFzIGV4YWN0 bHkgb25lIHVuaXF1ZSBsb2NrIHRva2VuLuKAnQ0KDQoNCjAzLUMwNzoNCg0KNi40OiDigJxBbGwg cmVzb3VyY2VzIE1VU1QgcmVjb2duaXplIHRoZSBvcGFxdWVsb2NrdG9rZW4gc2NoZW1lIGFuZCwg YXQNCm1pbmltdW0sIHJlY29nbml6ZSB0aGF0IHRoZSBsb2NrIHRva2VuIGRvZXMgbm90IHJlZmVy IHRvIGFuIG91dHN0YW5kaW5nDQpsb2NrDQpvbiB0aGUgcmVzb3VyY2Uu4oCdDQoNCihvbGQgdGV4 dCkgSSB0aGluayB0aGlzIGlzIG1pc2xlYWRpbmcuIEFueSByZXNvdXJjZSBtdXN0IHJlY29nbml6 ZSBhbnkNCnZhbGlkDQpVUkkuIElmIGEgVVJJIHVzZXMgYSBzY2hlbWUgaXQgZG9lc27igJl0IGtu b3cgb2YsIHRoaXMgc2ltcGx5IG1lYW5zIGl0DQpkb2VzbuKAmXQNCmlkZW50aWZ5IGFueSBwYXJ0 aWN1bGFyIGxvY2sgYXNzaWduZWQgYnkgdGhpcyBzZXJ2ZXIuIFNvIEnigJlkIHJlY29tbWVuZCB0 bw0KZ2V0IHJpZCBvZiB0aGlzIHNlbnRlbmNlLCBhbmQgcG9zc2libHkgYWRkIGEgY2xhcmlmaWNh dGlvbiB0byA2LjMgaW5zdGVhZC4NCg0KDQowMy1DMDg6DQoNCjcuNDog4oCcSG93ZXZlciwgaW50 ZXJvcGVyYWJpbGl0eSBhbmQgY29tcGxpYW5jZSBwcm9ibGVtcyBoYXZlIGJlZW4gZm91bmQNCndp dGgNCmxvY2stbnVsbCByZXNvdXJjZXMuICBUaGVyZWZvcmUsIHRoZXkgYXJlIGRlcHJlY2F0ZWQu ICBXZWJEQVYgc2VydmVycw0KY29tcGxpYW50IHdpdGggdGhpcyBkb2N1bWVudCBTSE9VTEQgY3Jl YXRlIHJlZ3VsYXIgbG9ja2VkIGVtcHR5IHJlc291cmNlcywNCndoaWNoIGJlaGF2ZSBpbiBldmVy eSB3YXkgYXMgaWYgdGhleSB3ZXJlIGEgbm9ybWFsIHJlc291cmNlLuKAnQ0KDQpUaGlzIHNvcnQg b2Ygc3VnZ2VzdHMgdGhhdCBsb2NrLW51bGwgcmVzb3VyY2VzIGluZGVlZCBhcmUgc3RpbGwgc29t ZXRoaW5nDQpkaWZmZXJlbnQgdGhhbiBhIG5vcm1hbCByZXNvdXJjZSwgd2hpY2ggaXNu4oCZdCB0 cnVlLg0KDQoNCjAzLUMwOToNCg0KNy40OiDigJxDYW4gYmUgZG93bmxvYWRlZCwgZGVsZXRlZCwg bW92ZWQsIGNvcGllZCwgYW5kIGluIGFsbCB3YXlzIGJlaGF2ZSBhcw0KYQ0KcmVndWxhciByZXNv dXJjZSwgbm90IGEgbG9jay1udWxsIHJlc291cmNlLuKAnQ0KDQpJIHRoaW5rIHRoZSB0ZXJtIOKA nGRvd25sb2FkZWTigJ0gaXMgbWlzbGVhZGluZyBoZXJlLiBGcm9tIGEgV2ViREFWIHByb3RvY29s DQpwLm8udi4sIGl0IHByb2JhYmx5IHNob3VsZCBiZSDigJxyZWFk4oCdLg0KDQoNCjAzLUMxMDoN Cg0KNy40Ljog4oCcU0hPVUxEIGRlZmF1bHQgdG8gYSBjb250ZW50LXR5cGUgb2YgImFwcGxpY2F0 aW9uL29jdGV0LXN0cmVhbSIuIOKAnA0KDQpOby4gSSBkb27igJl0IHRoaW5rIHRoZXJl4oCZcyBj b25zZW5zdXMgZm9yIHRoYXQsIGFuZCByZXF1aXJpbmcgYSBzcGVjaWZpYw0KY29udGVudCB0eXBl IHNlZW1zIHRvIGhhdmUgbm8gdmFsdWUgYXQgYWxsIHRvIGNsaWVudHMgKHNlZSBhbHNvIDguMTEs DQrigJxMb2NraW5nIFVubWFwcGVkIFVSTHPigJ0pLg0KDQoNCjAzLUMxMToNCg0KNy44OiDigJxJ ZiBhbiBlcnJvciBpcyByZWNlaXZlZCBpbiByZXNwb25zZSB0byBhIHJlZnJlc2ggTE9DSyByZXF1 ZXN0IHRoZQ0KY2xpZW50IFNIT1VMRCBhc3N1bWUgdGhhdCB0aGUgbG9jayB3YXMgbm90IHJlZnJl c2hlZC7igJ0NCg0KSSB0aGluayB3ZSBzaG91bGQgbWFrZSB0aGF0IGEg4oCcTVVTVOKAnS4NCg0K DQowMy1DMTI6DQoNCjguMS4xLjog4oCcU29tZSBvZiB0aGUgZm9sbG93aW5nIG5ldyBIVFRQIG1l dGhvZHMgdXNlIFhNTCBhcyBhIHJlcXVlc3QgYW5kDQpyZXNwb25zZSBmb3JtYXQuICBBbGwgREFW IGNvbXBsaWFudCBjbGllbnRzIGFuZCByZXNvdXJjZXMgTVVTVCB1c2UgIFhNTA0KcGFyc2VycyB0 aGF0IGFyZSBjb21wbGlhbnQgd2l0aCBbUkVDLVhNTF0u4oCdDQoNCkFkZCDigJzigKZhbmQgW1JF Qy1YTUxOU13igJ0uDQoNCldlIGFsc28gbmVlZCBhbGxvdyBzZXJ2ZXJzIGFuZCBjbGllbnRzIHRv IHJlamVjdHMgYSBjZXJ0YWluIHNldCBvZg0KcmVxdWVzdC9yZXNwb25zZSB0aGF0IGFyZSBpbmRl ZWQgd2VsbC1mb3JtZWQsIGluIHBhcnRpY3VsYXI6DQoNCi0gICAgICAgICAgICB3aGVuIGl0IGV4 Y2VlZHMgc29tZSBwcmVkZWZpbmVkIHNpemUgb3INCi0gICAgICAgICAgICB3aGVuIGV4cGFuc2lv biBvZiBpbnRlcm5hbCBlbnRpdGllcyBtYXkgY2F1c2UgYSBkZW5pYWwgb2YNCnNlcnZpY2UuDQoN CjAzLUMxMzoNCg0KOC4xLjI6IOKAnFNvbWUgb2YgdGhlc2UgbmV3IG1ldGhvZHMgZG8gbm90IGRl ZmluZSBib2RpZXMuICBTZXJ2ZXJzIE1VU1QNCmV4YW1pbmUgYWxsIHJlcXVlc3RzIGZvciBhIGJv ZHksIGV2ZW4gd2hlbiBhIGJvZHkgd2FzIG5vdCBleHBlY3RlZC4gIEluDQpjYXNlcyB3aGVyZSBh IHJlcXVlc3QgYm9keSBpcyBwcmVzZW50IGJ1dCB3b3VsZCBiZSBpZ25vcmVkIGJ5IGEgIHNlcnZl ciwNCnRoZQ0Kc2VydmVyIE1VU1QgcmVqZWN0IHRoZSByZXF1ZXN0IHdpdGggNDE1IChVbnN1cHBv cnRlZCAgTWVkaWEgVHlwZSkuICBUaGlzDQppbmZvcm1zIHRoZSBjbGllbnQgKHdoaWNoIG1heSBo YXZlIGJlZW4gYXR0ZW1wdGluZyB0byB1c2UgYW4gZXh0ZW5zaW9uKQ0KdGhhdA0KdGhlIGJvZHkg Y291bGQgbm90IGJlIHByb2Nlc3NlZCBhcyB0aGV5IGludGVuZGVkLuKAnQ0KDQpJ4oCZZCBsaWtl IHRvIHVuZGVyc3RhbmQgd2hldGhlciB0aGlzIGFmZmVjdHMgbWV0aG9kcyBvdGhlciB0aGFuIE1L Q09MLg0KDQoNCjAzLUMxNDoNCg0KOC4xLjM6IOKAnFdoZW4gdGhlIExvY2F0aW9uIGhlYWRlciBp cyB1c2VkIGluIGEgcmVzcG9uc2UsIGl0IGlzIHVzZWQgYnkgdGhlDQpzZXJ2ZXIgdG8gaW5kaWNh dGUgdGhlIHByZWZlcnJlZCBhZGRyZXNzIGZvciB0aGUgdGFyZ2V0IHJlc291cmNlIG9mICB0aGUN CnJlcXVlc3QuICBXaGVuZXZlciB0aGUgc2VydmVyIGhhcyBhIHByZWZlcnJlZCBhZGRyZXNzLCBp dCBzaG91bGQgIHVzZSB0aGF0DQphZGRyZXNzIGNvbnNpc3RlbnRseS4gIFRoaXMgbWVhbnMgdGhh dCB3aGVuIGEgcmVzcG9uc2UgY29udGFpbnMgYSBMb2NhdGlvbg0KaGVhZGVyLCBhbGwgdGhlIFVS THMgaW4gdGhlIHJlc3BvbnNlIGJvZHkgKGUuZy4gYSBNdWx0aS1TdGF0dXMpIHNob3VsZCBiZQ0K Y29uc2lzdGVudC7igJ0NCg0KSWYgd2Uga2VlcCB0aGlzIHBhcmFncmFwaCwgd2XigJlsbCBoYXZl IHRvIGRlZmluZSB3aGF0IOKAnGNvbnNpc3RlbnTigJ0gbWVhbnMNCmhlcmUuDQoNCg0KMDMtQzE1 Og0KDQo4LjEuNC46IOKAnE5vdGUgdGhhdCBIVFRQIDEuMSByZXF1aXJlcyB0aGUgRGF0ZSBoZWFk ZXIgaW4gYWxsIHJlc3BvbnNlcy7igJ0NCg0KVGhhdOKAmXMgbm90IHRydWUuIEhUVFAgMS4xIHNw ZWNpZmljYWxseSBzdXBwb3J0cyBjbG9ja2xlc3Mgc2VydmVycy4NCg0KDQowMy1DMTY6DQoNCjgu MS41OiDigJxJZiBFVGFncyBhcmUgc3VwcG9ydGVkIGZvciBhIHJlc291cmNlLCB0aGUgc2VydmVy IE1VU1QgcmV0dXJuIHRoZQ0KRVRhZyBoZWFkZXIgaW4gYWxsIFBVVCBhbmQgR0VUIHJlc3BvbnNl cyB0byB0aGF0IHJlc291cmNlLCBhcyB3ZWxsIGFzDQpwcm92aWRlIHRoZSBzYW1lIHZhbHVlIGZv ciB0aGUgJ2dldGV0YWcnICBwcm9wZXJ0eS7igJ0NCg0KTm90ZSB0aGF0IHRoaXMgYnJlYWtzIHRo ZSDigJxldGFnIHByb21vdGlvbuKAnSBzdHJhdGVneSB1c2VkIGJvdGggYnkgSUlTIGFuZA0KTW9k ZGF2IChQVVQgdXN1YWxseSByZXR1cm5zIHdlYWsgZXRhZ3Mgd2hpY2ggbGF0ZXIgYXJlIHByb21v dGVkIHRvIHN0cm9uZw0KZXRhZ3Mgd2hlbiB0aGVyZSB3YXMgbm8gb3RoZXIgY2hhbmdlIHRvIHRo YXQgcmVzb3VyY2Ugd2l0aGluIGEgc3BlY2lmaWMNCnRpbWUNCndpbmRvdykuIFRoZXJlZm9yZSBJ 4oCZZCBtYWtlIHRoYXQgYSBTSE9VTEQgKGF0IGxlYXN0IGZvciBQVVQpLg0KDQoNCjAzLUMxNzoN Cg0KOC4xLjUuOiDigJxCZWNhdXNlIGNsaWVudHMgbWF5IGJlIGZvcmNlZCB0byBwcm9tcHQgdXNl cnMgb3IgdGhyb3cgYXdheQ0KY2hhbmdlZA0KY29udGVudCBpZiB0aGUgRVRhZyBjaGFuZ2VzLCBh IFdlYkRBViBzZXJ2ZXIgTVVTVCBub3QgY2hhbmdlIHRoZSAgRVRhZyAob3INCmdldGxhc3Rtb2Rp ZmllZCB2YWx1ZSkgZm9yIGEgcmVzb3VyY2Ugd2hlbiBvbmx5IGl0cyBwcm9wZXJ0eSB2YWx1ZXMN CmNoYW5nZS7igJ0NCg0KU29tZSBzZXJ2ZXJzIGRvLCBhbmQgSSBkb27igJl0IHRoaW5rIHdlIGNh biBjaGFuZ2UgdGhhdC4gVGhlcmVmb3JlIEkgdGhpbmsNCnRoaXMgY2hhbmdlIGF0IGxlYXN0IG5l ZWRzIGV4cGxpY2l0IGNvbnNlbnN1cyBvbiB0aGUgbWFpbGluZyBsaXN0Lg0KDQoNCjAzLUMxODoN Cg0KOC4xLjY6IOKAnEhUVFAgYW5kIFdlYkRBViBkaWQgbm90IHVzZSB0aGUgYm9kaWVzIG9mIG1v c3QgZXJyb3IgcmVzcG9uc2VzDQp1bnRpbA0KRGVsdGFWIGludHJvZHVjZWQgYSBtZWNoYW5pc20g dG8gaW5jbHVkZSBtb3JlIHNwZWNpZmljIGluZm9ybWF0aW9uIGluIHRoZQ0KYm9keSBvZiBhbiBl cnJvciByZXNwb25zZSAoc2VjdGlvbiAxLjYgb2YgW1JGQzMyNTNdKS7igJ0NCg0KVGhhdOKAmXMg bm90IHJlYWxseSB0cnVlLiBIVFRQIGluZGVlZCByZWNvbW1lbmRzIHRvIHNlbmQgZXJyb3IgZGVz Y3JpcHRpb25zDQppbg0KdGhlIHJlc3BvbnNlIGJvZGllcyBhcyB3ZWxsLg0KDQoNCjAzLUMxOToN Cg0KR2VuZXJhbCBjb21tZW50IHJlOiA4LjEuNjogSSByZWFsbHkgbGlrZSB0aGF0IGNoYW5nZSAo YWN0dWFsbHksIEkgbGlrZSBpdA0Kc28NCm11Y2ggdGhhdCBJ4oCZZCBsaWtlIHRvIGhhdmUgY29u ZGl0aW9uIG5hbWVzIGZvciBhbGwgZnJlcXVlbnRseSBzaWduYWxsZWQNCnByb2JsZW1z4oCmLiku IEhvd2V2ZXIsIGlmIGl0IHVzZXMgdGhlIHNhbWUgZm9ybWF0IGFzIFJGQzMyNTMsIGl0IHNob3Vs ZCBiZQ0KY29uc2lzdGVudCB3aXRoIGl0LiBJbiBwYXJ0aWN1bGFyLCB0aGUgbmFtZXMgc2hvdWxk IGlkZW50aWZ5IGNvbmRpdGlvbnMNCnRoYXQNCm11c3QgYmUgbWV0LiBGb3IgaW5zdGFuY2UsIHVz ZSDigJxhbGxvdy1leHRlcm5hbC1lbnRpdGllc+KAnSByYXRoZXIgdGhhbg0K4oCcZm9yYmlkLWlu dGVybmFsLWVudGl0aWVz4oCdLiBXZSBtYXkgYWxzbyB3YW50IHRvIG5vdGUgdGhhdCBvbmUgREFW OmVycm9yDQplbGVtZW50IGNhbiBob2xkIG11bHRpcGxlIGVsZW1lbnRzIGlkZW50aWZ5aW5nIGZh aWxlZCBjb25kaXRpb25zLg0KDQoNCjAzLUMyMDoNCg0KOC4yLjog4oCcREFWIGNvbXBsaWFudCBz ZXJ2ZXJzIE1VU1Qgc3VwcG9ydCB0aGUgIjAiLCAiMSIgYW5kICJpbmZpbml0eSINCmJlaGF2aW9y cy7igJ0NCg0KQ2hhbmdlIHRvOg0KDQrigJxEQVYgY29tcGxpYW50IHNlcnZlcnMgTVVTVCBzdXBw b3J0IHRoZSAiMCIgYW5kICIxIiBiZWhhdmlvcnMgYW5kIE1BWQ0Kc3VwcG9ydCB0aGUgImluZmlu aXR5IiBiZWhhdmlvci7igJ0NCg0KDQowMy1DMjE6DQoNCjguMi46IOKAnE5vdGUgdGhhdCDigJhh bGxwcm9w4oCZIGRvZXMgbm90IHJldHVybiB2YWx1ZXMgZm9yIGFsbCBwcm9wZXJ0aWVzLuKAnQ0K DQpDaGFuZ2UgdG86DQoNCuKAnE5vdGUgdGhhdCDigJhhbGxwcm9w4oCZIGRvZXMgbm90IHJldHVy biB2YWx1ZXMgZm9yIGFsbCBsaXZlIHByb3BlcnRpZXMu4oCdDQoNCg0KDQowMy1DMjI6DQoNCjgu Mjog4oCcVVJMcyBmb3IgY29sbGVjdGlvbnMgYXBwZWFyaW5nIGluIHRoZSByZXN1bHRzIE1VU1Qg ZW5kICBpbiBhIHNsYXNoDQpjaGFyYWN0ZXIu4oCdDQoNCkkgZG9u4oCZdCB0aGluayB3ZSBoYXZl IGNvbnNlbnN1cyBmb3IgdGhpcyBiZWluZyBhIE1VU1QuDQoNCg0KMDMtQzIzOg0KDQo4LjI6IOKA nE5vdGUgdGhhdCBVUkxzIGFuZCBVUklzIGluIFhNTCBtdXN0IGFsd2F5cyBiZSBmdWxseSBsZWdh bCBVUklzLiBGb3INCmV4YW1wbGUsIGl0IGlzIGlsbGVnYWwgdG8gdXNlIGEgc3BhY2UgY2hhcmFj dGVyIG9yIGRvdWJsZS1xdW90ZSBpbiBhICBVUkkNCltSRkMyMzk2XS4gIFVSTC1lc2NhcGluZyBp cyBjb21tb25seSB1c2VkIChlLmcuIHJlcGxhY2UgYSBzcGFjZSB3aXRoIGENCnNlcXVlbmNlIHN1 Y2ggYXMgJTIwKS4gVGhlIFVSSSBtdXN0IG5vdCBhcHBlYXIgaW4gWE1MICJ1bmVzY2FwZWQiLCBp dCBtdXN0DQpiZSBpbiBpdHMgbGVnYWwgVVJJIGZvcm1hdC7igJ0NCg0KVGhpcyBpcyBtaXNsZWFk aW5nLiBPZiBjb3Vyc2UgVVJJcyBtdXN0IGNvbmZvcm0gdG8gdGhlIFVSSSBzeW50YXgg4oCTIHRo YXTigJlzDQp0aGUgd2hvbGUgcG9pbnQsIHJpZ2h0PyBJbiBwYXJ0aWN1bGFyLCB0aGVyZeKAmXMg bm8gc3VjaCB0aGluZyBhcyBhDQrigJx1bmVzY2FwZWQNCmZvcm3igJ0gb2YgYSBVUkkuIFVSSXMg ZG8gbm90IGFsbG93IHRoZSBzcGFjZSBjaGFyYWN0ZXIsIGFuZCB0aGVyZWZvcmUgYSBVUkkNCm5l dmVyIGV2ZXIgY29udGFpbnMgYSBzcGFjZSBjaGFyYWN0ZXIuDQoNCldoYXQgd2Ugc2hvdWxkIHNh eSBoZXJlIGlzIGhvdyBzZXJ2ZXJzIHNob3VsZCBiZWhhdmUgd2hlbiB0aGVpciBpbnRlcm5hbA0K aW1wbGVtZW50YXRpb24gbW9kZWwgb2YgY29sbGVjdGlvbnMgYWxsb3cgbWVtYmVyIG5hbWVzIHRo YXQgYXJlbuKAmXQgbGVnYWwNClVSTA0KcGF0aCBzZWdtZW50cyAoYW5zd2VyOiBlbmNvZGUgYXMg VVRGLTggb2N0ZXQgc3RyZWFtLCB0aGVuIFVSSS1lc2NhcGUpLg0KDQoNCjAzLUMyNDoNCg0KOC4y LjI6IOKAnFRoaXMgZXhhbXBsZSBhbHNvIGRlbW9uc3RyYXRlcyB0aGUgdXNlIG9mIFhNTCBuYW1l c3BhY2Ugc2NvcGluZywNCmFuZA0KdGhlIGRlZmF1bHQgbmFtZXNwYWNlLiAgU2luY2UgdGhlICJ4 bWxucyIgYXR0cmlidXRlIGRvZXMgbm90IGNvbnRhaW4gIGFuDQpleHBsaWNpdCAic2hvcnRoYW5k IG5hbWUiIChwcmVmaXgpIGxldHRlciwgdGhlIG5hbWVzcGFjZSBhcHBsaWVzIGJ5IGRlZmF1bHQN CnRvIGFsbCBlbmNsb3NlZCBlbGVtZW50cy4gIEhlbmNlLCBhbGwgZWxlbWVudHMgd2hpY2ggZG8g bm90IGV4cGxpY2l0bHkNCnN0YXRlDQp0aGUgbmFtZXNwYWNlIHRvIHdoaWNoIHRoZXkgYmVsb25n IGFyZSBtZW1iZXJzICBvZiB0aGUgIkRBVjoiIG5hbWVzcGFjZQ0Kc2NoZW1hLuKAnQ0KDQpDaGFu Z2UgdG86DQoNCuKAnFRoaXMgZXhhbXBsZSBhbHNvIGRlbW9uc3RyYXRlcyB0aGUgdXNlIG9mIFhN TCBuYW1lc3BhY2Ugc2NvcGluZywgYW5kICB0aGUNCmRlZmF1bHQgbmFtZXNwYWNlLiAgU2luY2Ug dGhlICJ4bWxucyIgYXR0cmlidXRlIGRvZXMgbm90IGNvbnRhaW4gYSBwcmVmaXgsDQp0aGUgbmFt ZXNwYWNlIGFwcGxpZXMgYnkgZGVmYXVsdCB0byBhbGwgbm9uLXByZWZpeGVkIGVuY2xvc2VkIGVs ZW1lbnRzLg0KSGVuY2UsIGFsbCBlbGVtZW50cyB3aGljaCBkbyBub3QgZXhwbGljaXRseSBzdGF0 ZSB0aGUgbmFtZXNwYWNlIHRvIHdoaWNoDQp0aGV5IGJlbG9uZyBhcmUgbWVtYmVycyAgb2YgdGhl ICJEQVY6IiBuYW1lc3BhY2Uu4oCdDQoNCihBY3R1YWxseSBJ4oCZZCByYXRoZXIgcHJlZmVyIHRv IGdldCByaWQgb2YgdGhpcy4gUkZDMjUxOGJpcyBzaG91bGRu4oCZdCB0cnkgdG8NCmdpdmUgWE1M IGxlc3NvbnMpLg0KDQoNCjAzLUMyNToNCg0KOC43OiDigJxJZiB0aGUgREVMRVRFIG1ldGhvZCBp cyBpc3N1ZWQgdG8gYSBub24tY29sbGVjdGlvbiByZXNvdXJjZSB3aG9zZQ0KVVJJcyBhcmUgYW4g aW50ZXJuYWwgbWVtYmVyIG9mIG9uZSBvciBtb3JlIGNvbGxlY3Rpb25zLCB0aGVuIGR1cmluZyAg REVMRVRFDQpwcm9jZXNzaW5nIGEgc2VydmVyIE1VU1QgcmVtb3ZlIGFueSBVUkkgZm9yIHRoZSBy ZXNvdXJjZSBpZGVudGlmaWVkIGJ5IHRoZQ0KUmVxdWVzdC1VUkkgZnJvbSBjb2xsZWN0aW9ucyB3 aGljaCBjb250YWluIGl0IGFzIGEgbWVtYmVyLuKAnQ0KDQpJIHRoaW5rIHdlIHdhbnQgdG8gZ2V0 IHJpZCBvZiB0aGlzIHN0YXRlbWVudC4gRG9lcyBhbnlib2R5IGltcGxlbWVudCB0aGlzDQpyaWdo dCBub3c/DQoNCg0KMDMtQzI2Og0KDQo4LjExOiDigJxUaGUgTE9DSyByZXF1ZXN0IG1heSBoYXZl IGEgVGltZW91dCAgaGVhZGVyLuKAnQ0KDQrigJxtYXnigJ0gLT4g4oCcTUFZ4oCdLg0KDQoNCjAz LUMyNzoNCg0KOC4xMSwg4oCcSW50ZXJhY3Rpb24gd2l0aCBvdGhlciBNZXRob2Rz4oCdOiDigJxI b3dldmVyLCBpbmRlcGVuZGVudCBvZiBsb2NrIHR5cGUsDQphIHN1Y2Nlc3NmdWwgREVMRVRFICBv ZiBhIHJlc291cmNlIE1VU1QgY2F1c2UgYWxsIG9mIGl0cyBsb2NrcyB0byBiZQ0KcmVtb3ZlZC7i gJ0NCg0KKG9sZCB0ZXh0KSBJIHRoaW5rIHRoaXMgaXMgbWlzbGVhZGluZy4gQSBERUxFVEUgb24g YSByZXNvdXJjZSBvbmx5IHJlbW92ZXMNCnRob3NlIGxvY2tzIHRoYXQgYXJlbuKAmXQgaW5oZXJp dGVkLg0KDQoNCjAzLUMyODoNCg0KOC4xMjog4oCcQSBzdWNjZXNzZnVsIHJlc3BvbnNlIHRvIGFu IFVOTE9DSyBtZXRob2QgZG9lcyBub3QgbWVhbiB0aGF0IHRoZQ0KcmVzb3VyY2UgaXMgdW5sb2Nr ZWQuICBBdCBtb3N0LCBpdCBtZWFucyB0aGF0IHRoZSBzcGVjaWZpZWQgdG9rZW4gbm8gbG9uZ2Vy DQppZGVudGlmaWVzIGEgbG9jayBvbiB0aGUgcmVzb3VyY2Uu4oCdDQoNCkNoYW5nZSB0bzoNCg0K 4oCcQSBzdWNjZXNzZnVsIHJlc3BvbnNlIHRvIGFuIFVOTE9DSyBtZXRob2QgZG9lcyBub3QgbWVh biB0aGF0IHRoZSByZXNvdXJjZQ0KaXMgdW5sb2NrZWQuICBBdCBtb3N0LCBpdCBtZWFucyB0aGF0 IHRoZSBzcGVjaWZpZWQgdG9rZW4gbm8gIGxvbmdlcg0KaWRlbnRpZmllcyBhIGxvY2sgb24gYW55 IHJlc291cmNlLuKAnQ0KDQoNCjAzLUMyOToNCg0KOS4xIChEQVYgaGVhZGVyKSBhbGxvd3MgY29k ZWQgVVJMcyBpbiB0aGUgREFWIGhlYWRlci4gSeKAmWQgbGlrZSB0byBzZWUgdGhlDQpyYXRpb25h bGUgZm9yIHRoYXQuDQoNCg0KMDMtQzMwOg0KDQo5LjQgKGZvcmNlLWF1dGhlbnRpY2F0ZSk6IGlz IHRoaXMgdGhlIGNvbnNlbnN1cyB3ZSByZWFjaGVkIGluIEphbnVhcnk/DQpJbHlhcywgZGlkIHlv dSB0YWtlIG5vdGVzPw0KDQoNCjAzLUMzMToNCg0KOS41IGRlZmluZXMg4oCcPG5vLWxvY2s+4oCd IGFzIGEgbmV3IHNwZWNpYWwgc3RhdGUgdG9rZW4uIEkgdGhpbmsgdGhpcyBpcw0KdW5uZWVkZWQg 4oCTIGFueSBVUkkgd2hpY2ggaXMga25vd24gbm90IHRvIGlkZW50aWZ5IGEgbG9jayBNVVNUIHdv cmsgYXMgd2VsbCwNCnNvIHdlIGNhbiBzaW1wbHkgcmVjb21tZW5kIHVzaW5nIHNvbWV0aGluZyBs aWtlIOKAnDxEQVY6bm8tbG9jaz7igJ0gKHdoaWNoIGlzDQpzb21ldGhpbmcgdGhhdCBSRkMyNTE4 LWNvbXBsaWFudCBzZXJ2ZXJzIGFscmVhZHkgc3VwcG9ydCkuDQoNCg0KMDMtQzMyOg0KDQoob2xk IHRleHQpIFRoZSBleGFtcGxlIGluIDkuNS4yIHVzZXMgYW4gaW52YWxpZCBsb2NrIHRva2VuICh0 aGUgVVJJIHNjaGVtZQ0K4oCcbG9ja3Rva2Vu4oCdIGlzbuKAmXQgSUVURi1yZWdpc3RlcmVkLCBz byBpdCBjYW7igJl0IGNsYWltIGNvbmZvcm1hbmNlIHRvIHRoZQ0KdW5pcXVlbmVzcyByZXF1aXJl bWVudHMpLiBKdXN0IHVzZSBhIHNhbXBsZSB0b2tlbiB1c2luZyB0aGUNCiDigJxvcGFxdWVsb2Nr dG9rZW7igJ0gc2NoZW1lIGluc3RlYWQpLg0KDQoNCjAzLUMzMzoNCg0KOS41LjU6IOKAnFRoZSBu b3QgcHJvZHVjdGlvbiBpcyB1c2VkIHRvIHJldmVyc2UgdGhhdCB2YWx1ZS7igJ0NCg0KQ2hhbmdl IHRvOg0KDQrigJxUaGUg4oCYTm904oCZIHByb2R1Y3Rpb24gaXMgdXNlZCB0byByZXZlcnNlIHRo YXQgdmFsdWUu4oCdDQoNCg0KMDMtQzM0Og0KDQpTZWN0aW9uIDEzOiBYTUwgZWxlbWVudCBkZWZp bml0aW9ucw0KDQpJIGRvbuKAmXQgbGlrZSB0aGUgc3ludGF4IGNoYW5nZSBpbiB0aGUgRFREcy4g Rm9yIGluc3RhbmNlLCBhY3RpdmVsb2NrIG5vdyBpcw0KZGVmaW5lZCBhczoNCg0KICAgPCFFTEVN RU5UIGFjdGl2ZWxvY2sgQU5ZPg0KICAgQU5ZIHZhbHVlOiBBbnkgbnVtYmVyIG9mIGVsZW1lbnRz LCBpbmNsdWRpbmcgb25lIG9mIGVhY2ggb2YNCiAgIChsb2Nrc2NvcGUsIGxvY2t0eXBlLCBkZXB0 aCwgb3duZXIsIHRpbWVvdXQsIGxvY2t0b2tlbiwgbG9ja3Jvb3QpDQoNCkl0IHVzZWQgdG8gYmU6 DQoNCiAgIDwhRUxFTUVOVCBhY3RpdmVsb2NrIChsb2Nrc2NvcGUsIGxvY2t0eXBlLCBkZXB0aCwg b3duZXI/LCB0aW1lb3V0PywNCiAgIGxvY2t0b2tlbj8pID4NCg0KRm9yIGNvbnNpc3RlbmN5IHdp dGggUkZDMjUxOCwgUkZDMzI1MyBhbmQgdGhlIEFDTCBzcGVjIHdlIHJlYWxseSBzaG91bGQNCnN0 YXkNCndpdGggdGhlIG9sZCBub3RhdGlvbi4NCg0KDQowMy1DMzU6DQoNClNlY3Rpb24gMTc6IOKA nHdoaWNoIGhhcyBleHBsaWNpdCBwcm92aXNpb25zIGZvciBjaGFyYWN0ZXIgc2V0IHRhZ2dpbmcg YW5kDQplbmNvZGluZywgYW5kIHJlcXVpcmVzIHRoYXQgWE1MIHByb2Nlc3NvcnMgcmVhZCBYTUwg ZWxlbWVudHMgZW5jb2RlZCwgYXQNCm1pbmltdW0sIHVzaW5nIHRoZSBVVEYtOCBbVVRGLThdIGVu Y29kaW5nIG9mIHRoZSBJU08gIDEwNjQ2IG11bHRpbGluZ3VhbA0KcGxhbmUu4oCdDQoNClVubGVz cyB3ZSBnZXQgcmlkIG9mIHRoaXMgc2VjdGlvbiwgd2XigJlsbCBoYXZlIHRvIGFkZCBVVEYtMTYu DQoNCg0KMDMtQzM2Og0KDQpTZWN0aW9uIDE3OiDigJxOYW1lcyB1c2VkIHdpdGhpbiB0aGlzIHNw ZWNpZmljYXRpb24gZmFsbCBpbnRvIHRocmVlDQpjYXRlZ29yaWVzOiAgbmFtZXMgb2YgcHJvdG9j b2wgZWxlbWVudHMgc3VjaCBhcyBtZXRob2RzIGFuZCBoZWFkZXJzLCBuYW1lcw0Kb2YgWE1MIGVs ZW1lbnRzLCBhbmQgbmFtZXMgb2YgcHJvcGVydGllcy7igJ0NCg0KV2UgbWF5IHdhbnQgdG8gYWRk IGEgbmV3IGNhdGVnb3J5IChjb25kaXRpb24gbmFtZXMpLg0KDQoNCg0KDQoNCkVkaXRvcmlhbCBu b3RlczoNCg0KDQowMy1FMDENCg0KRXhwaXJ5IGRhdGUgaXMgd3JvbmcuDQoNCg0KMDMtRTAyDQoN CklFVEYgd2FudHMgYSBtYXhpbXVtIG9mIDUgYXV0aG9ycy4NCg0KDQowMy1FMDMNCg0KUGFyYWdy YXBoIDE6IOKAnG1hcnNoYWxs4oCdICAtPiDigJxtYXJzaGFs4oCdDQoNCg0KMDMtRTA0DQoNClRo ZXJlIGFyZSBtYW55IHBsYWNlcyB3aGVyZSBleGFtcGxlIFVSTHMgZG8gbm90IHVzZSB0aGUgc2V0 IG9mIGV4YW1wbGUgaG9zdA0KbmFtZXMgYWxsb3dlZCBieSB0aGUgSUVURi4NCg0KDQowMy1FMDUN Cg0KOC4xLjUgdXNlcyB0aGUgdGVybSDigJxldGFn4oCdLiBIVFRQIHVzZXMg4oCcZXRhZ+KAnSBv bmx5IGFzIGhlYWRlciBuYW1lcywgYW5kDQp0YWxrcw0KYWJvdXQg4oCcZW50aXR5IHRhZ3PigJ0g ZXZlcnl3aGVyZSBlbHNlLiBTbyBzaG91bGQgd2UuDQoNCg0KMDMtRTA2DQoNCjguMi4yIHVzZXMg dGhlIHRlcm0g4oCccHJvZ2VueeKAnSwgd2hpY2ggSSBoYXZlbuKAmXQgc2VlbiBiZWZvcmUgaW4g dGhpcyBjb250ZXh0Lg0KTWF5YmUgcmVwbGFjZSBieSBzb21ldGhpbmcgbW9yZSBjb21tb24sIHN1 Y2ggYXMg4oCcbWVtYmVyc+KAnS4NCg0KDQowMy1FMDc6DQoNCjguMi4yLiBzdGlsbCB1c2VzIGNv bmNhdGVuYXRpb24gb2YgbmFtZXNwYWNlIG5hbWVzIGFuZCBlbGVtZW50IG5hbWVzIHRvDQppZGVu dGlmeSBwcm9wZXJ0eSBuYW1lcy4NCg0KDQoNCg0KDQoNCi0tDQo8Z3JlZW4vPmJ5dGVzIEdtYkgg LS0gaHR0cDovL3d3dy5ncmVlbmJ5dGVzLmRlIC0tIHRlbDorNDkyNTEyODA3NzYwDQoNCg0K From w3c-dist-auth-request@w3.org Tue Mar 18 20:04:41 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA10152 for ; Tue, 18 Mar 2003 20:04:41 -0500 (EST) Received: from frink.w3.org (localhost [127.0.0.1]) by frink.w3.org (8.12.8/8.12.8) with ESMTP id h2J16D4g018418; Tue, 18 Mar 2003 20:06:13 -0500 (EST) Received: (from lists@localhost) by frink.w3.org (8.12.8/8.12.8/Submit) id h2J162ig018400; Tue, 18 Mar 2003 20:06:02 -0500 (EST) Resent-Date: Tue, 18 Mar 2003 20:06:02 -0500 (EST) Resent-Message-Id: <200303190106.h2J162ig018400@frink.w3.org> Received: from tux.w3.org (IDENT:root@tux [18.29.0.27]) by frink.w3.org (8.12.8/8.12.8) with ESMTP id h2J15x4g018368 for ; Tue, 18 Mar 2003 20:05:59 -0500 (EST) Received: from sunserver1.ietf56.ietf.org ([130.129.16.49]) by tux.w3.org (8.12.8/8.12.8) with ESMTP id h2J15xrB012095 for ; Tue, 18 Mar 2003 20:05:59 -0500 Received: from wl-138-90.wireless.ietf56.ietf.org ([130.129.138.90] helo=Tycho) by sunserver1.ietf56.ietf.org with smtp (Exim 4.12) id 18vS1b-0000tn-00 for w3c-dist-auth@w3.org; Tue, 18 Mar 2003 20:05:47 -0500 From: "Jim Whitehead" To: "WebDAV" Date: Tue, 18 Mar 2003 17:02:41 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Subject: WebDAV BOF location X-Archived-At: http://www.w3.org/mid/AMEPKEBLDJJCCDEJHAMIGEGIGLAA.ejw@cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7513 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit For those wishing to join us for the post-IETF WebDAV WG meeting BOF this evening, we will be meeting at the restaurant Kim Thanh, 697 Geary Street, San Francisco. It's about 2 1/2 blocks from the conference hotel (see www.ietf.org for the meeting hotel). We will be meeting there starting at about 6:45PM. - Jim From w3c-dist-auth-request@w3.org Tue Mar 18 21:17:48 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA12133 for ; Tue, 18 Mar 2003 21:17:47 -0500 (EST) Received: from frink.w3.org (localhost [127.0.0.1]) by frink.w3.org (8.12.8/8.12.8) with ESMTP id h2J2Br4g006637; Tue, 18 Mar 2003 21:11:53 -0500 (EST) Received: (from lists@localhost) by frink.w3.org (8.12.8/8.12.8/Submit) id h2J2BkOv006446; Tue, 18 Mar 2003 21:11:46 -0500 (EST) Resent-Date: Tue, 18 Mar 2003 21:11:46 -0500 (EST) Resent-Message-Id: <200303190211.h2J2BkOv006446@frink.w3.org> Received: from tux.w3.org (IDENT:root@tux [18.29.0.27]) by frink.w3.org (8.12.8/8.12.8) with ESMTP id h2J2Bd4g006316 for ; Tue, 18 Mar 2003 21:11:39 -0500 (EST) Received: from sunserver1.ietf56.ietf.org ([130.129.16.49]) by tux.w3.org (8.12.8/8.12.8) with ESMTP id h2J2BcrB029074 for ; Tue, 18 Mar 2003 21:11:38 -0500 Received: from wl-138-90.wireless.ietf56.ietf.org ([130.129.138.90] helo=Tycho) by sunserver1.ietf56.ietf.org with smtp (Exim 4.12) id 18vT32-000100-00 for w3c-dist-auth@w3.org; Tue, 18 Mar 2003 21:11:20 -0500 From: "Jim Whitehead" To: "WebDAV" Date: Tue, 18 Mar 2003 18:08:13 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Subject: Raw meeting notes from WebDAV WG meeting X-Archived-At: http://www.w3.org/mid/AMEPKEBLDJJCCDEJHAMIEEGMGLAA.ejw@cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7514 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit WebDAV Working Group Meeting San Francisco IETF, March 18 Co-Chairs: Lisa Dusseault, Jim Whitehead Notetaker: Jim Whitehead ----------- A meeting of the IETF WebDAV Working Group was held at IETF-56, held in San Francisco. Approximately 25 people attended the meeting over its duration. Lisa Dusseault began by going over the agenda. She noted that DASL discussion was dropped since there were not enough people present to discuss the issues in depth. Lisa then led a discussion of 2518bis. * Discussion of locking issues in 2518bis. Slide "Agreed text so far" - Discussion of the content type of the resource created by a LOCK when the content type doesn't exist. One thought: pick one type. Another choice: do whatever a server does when you send a PUT with no Content-Type header, and a non-empty body. Rough consensus: be silent on the issue (most likely defaulting to what happens when a PUT with no Content-Type header). * Discussion of the definition of a collection. Should we use binding terminology in 2518bis, or keep internal member terminology. Tempest in a teakettle over internal member terminology. In the end, decided to keep using internal member term. * Discussion of "First problem" slide. What should be the behavior on a LOCK on an indirectly locked resource? Should the lock remove the entire depth lock, or should it be redirected, or should it fail? Rough consensus for failure, error code to be determined later. * Discussion of "Second problem" slide. When an If header is submitted against a depth locked resource, must a client use the lockroot URL, or is any URL in the locked tree OK? If the untagged If header's referred to resource is the same as the request URL, will this break any existing clients? One approach is to better identify interoperability failures in lock token handling. Need to make the text in the specification in 2518bis on the If header more clear. No consensus. Lisa will write a message to the mailing list summarizing both sides of the issue, and explicitly solicit feedback from Dan Brotsky, Julian Reschke, and Max Dunn on this, as well as generally from the mailing list. * Discussion of "what is locked" draft. Discussed effect of locks on live properties. Agreement of lock affecting dead properties. Also tentative agreement that a lock should affect all PROPPATCH operations on all properties, live and dead. Briefly noted that locks do not prevent live properties from updating their values (e.g., getcontentlength updating after a PUT -- this is OK, even when the resource is locked). * The "Last Piece" slide. No disagreement. Refined lock-root to "lock root URL" to avoid ambiguity over what "mapping" means. * "Allprop replacement proposal." Agreement in the room that the proposal listed on the slide was fine. Some concern over interoperability implications of adding new XML tag into PROPFIND prop requests to ask for all dead properties. * Discussion on whether there should be an additional 4xx or 5xx status code for multistatus cases. Several viewpoints. Aesthetic: 207 is for complete success, while a 207 can have 4xx inside it, so this is a contradiction. Interoperability: clients may not know how to correctly handle a new 4xx that expresses a multistatus case, or only use the new 4xx for cases where it is OK for the client to treat the entire response as a failure. Functional: some tools may not understand WebDAV, but still come into contact with 207 responses. An example is an HTTP logging tool that might be trying to tally success and failure, and won't properly handle 207. Rough consensus to *not* make any changes to 2518bis. Keep current semantics of 207, do not add new status codes. Main motivation is to not break current implementations, or add a new status code that might cause interoperability problems. * Discussion of entity tags, and support level. Not strong support for moving to SHOULD. Roy Fielding argued that there is already strong motivation for supporting entity tags, since they provide significant caching benefits. But, there is experience that many DAV servers do not support entity tags at all, and hence interoperability might benefit from language in the specification recommending, or giving a SHOULD level requirement on support of entity tags. Some agreement that use of entity tags should be RECOMMENDED (defined in 2119 to be the same strength as SHOULD) on all PUTable resources. Also makes sense to add an implementation note providing rationale for why entity tags are a good thing to implement. ----------- Brian Korver, discussion of Quota specification. Brian began with an overview of the latest draft of the quota specification. Some questions on the semantics of the new properties. Brian mentioned that the definitions were taken from the definition of the NSF quota system. The quota properties are strictly live. Quotas are defined on resources -- there is no mechanism to ask about the quota for a particular user. People who volunteered to read and review the specification. Jim Whitehead, a grad. student of Jim's. Jim stated that the specification is close to WG last call, look for this in a few months, after a few people in the WG have read and provided feedback on the quota specification. ----------- Brief discussion of the ordering specification. Geoff Clemm overviewed recent changes. Jim asked whether there were any objections to moving this to a working group last call. None surfaced. ----------- Geoff Clemm then led discussion on the binding protocol. Geoff began with a brief overview of the binding protocol. Discussion of copy language in the binding specification. No objections on the language in the specification. Some discussion on Copy, Depth infinity case. *** Need to add description of the behavior of Copy, Depth infinity case, since it's not currently covered in the specification. Discussion of delete and bindings. Will take this to the list -- raised the issue. Binding specification is at a point where, if you have issues with the specification, they should be surfaced now. Will work to resolve open issues soon, want to drive specification to closure in the near future. --------- Geoff then led a brief discussion of the ACL protocol. Brief review of IESG feedback on the recent last call. There is a new draft in preparation, and will submit this as an I-D in the near future. Like binding specification, want to quickly move to closure on this. --------- *** End of Meeting *** From w3c-dist-auth-request@w3.org Wed Mar 19 06:04:34 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA18584 for ; Wed, 19 Mar 2003 06:04:34 -0500 (EST) Received: from frink.w3.org (localhost [127.0.0.1]) by frink.w3.org (8.12.8/8.12.8) with ESMTP id h2JB4n4g022779; Wed, 19 Mar 2003 06:04:49 -0500 (EST) Received: (from lists@localhost) by frink.w3.org (8.12.8/8.12.8/Submit) id h2JB4OmM022756; Wed, 19 Mar 2003 06:04:24 -0500 (EST) Resent-Date: Wed, 19 Mar 2003 06:04:24 -0500 (EST) Resent-Message-Id: <200303191104.h2JB4OmM022756@frink.w3.org> Received: from tux.w3.org (IDENT:root@tux [18.29.0.27]) by frink.w3.org (8.12.8/8.12.8) with ESMTP id h2JB4L4g022724 for ; Wed, 19 Mar 2003 06:04:21 -0500 (EST) Received: from mail.gmx.net (mail.gmx.net [213.165.65.60]) by tux.w3.org (8.12.8/8.12.8) with SMTP id h2JB4JrB023915 for ; Wed, 19 Mar 2003 06:04:20 -0500 Received: (qmail 18101 invoked by uid 0); 19 Mar 2003 11:04:14 -0000 Received: from mail.greenbytes.de (HELO lisa) (217.5.201.10) by mail.gmx.net (mp007-rz3) with SMTP; 19 Mar 2003 11:04:14 -0000 From: "Julian Reschke" To: "Jim Whitehead" , "WebDAV" Date: Wed, 19 Mar 2003 12:04:13 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Subject: RE: Raw meeting notes from WebDAV WG meeting X-Archived-At: http://www.w3.org/mid/JIEGINCHMLABHJBIGKBCGEPCGMAA.julian.reschke@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7515 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit Jim, thanks for taking notes (and for posting them that fast!). Some comments: > Lisa Dusseault began by going over the agenda. She noted that DASL > discussion was dropped since there were not enough people present to > discuss the issues in depth. Lisa then led a discussion of 2518bis. In fact, DASL status has changed little since the meeting in January. I added the new issues/ideas to the draft, closed some issues and submitted a new Internet Draft in February [1]. > Brian Korver, discussion of Quota specification. I'll try to do a review of the current spec in the next few days. I think it could greatly be simplified by splitting generic terminology/definitions from the property descriptions. > Brief discussion of the ordering specification. Geoff Clemm overviewed > recent changes. Jim asked whether there were any objections to moving > this to a working group last call. None surfaced. Great. The last version that was submitted is draft 06 ([2]), the "latest" version ([3]) only differs in that it explicitly states that ORDERPATCH is atomic. I'll submit that as a new "last call" draft ASAP. Julian [1] [2] [3] -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Wed Mar 19 11:06:43 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24633 for ; Wed, 19 Mar 2003 11:06:43 -0500 (EST) Received: from frink.w3.org (localhost [127.0.0.1]) by frink.w3.org (8.12.8/8.12.8) with ESMTP id h2JG8F4g025973; Wed, 19 Mar 2003 11:08:15 -0500 (EST) Received: (from lists@localhost) by frink.w3.org (8.12.8/8.12.8/Submit) id h2JG7xE0025918; Wed, 19 Mar 2003 11:07:59 -0500 (EST) Resent-Date: Wed, 19 Mar 2003 11:07:59 -0500 (EST) Resent-Message-Id: <200303191607.h2JG7xE0025918@frink.w3.org> Received: from tux.w3.org (IDENT:root@tux [18.29.0.27]) by frink.w3.org (8.12.8/8.12.8) with ESMTP id h2JG7u4g025886 for ; Wed, 19 Mar 2003 11:07:56 -0500 (EST) Received: from mail.gmx.net (mail.gmx.net [213.165.65.60]) by tux.w3.org (8.12.8/8.12.8) with SMTP id h2JG7trB008095 for ; Wed, 19 Mar 2003 11:07:55 -0500 Received: (qmail 21432 invoked by uid 0); 19 Mar 2003 16:07:49 -0000 Received: from mail.greenbytes.de (HELO lisa) (217.5.201.10) by mail.gmx.net (mp002-rz3) with SMTP; 19 Mar 2003 16:07:49 -0000 From: "Julian Reschke" To: "Brian Korver" , "WebDAV" Date: Wed, 19 Mar 2003 17:07:48 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) In-Reply-To: <1F3FAD04-50D4-11D7-8A8F-000393751598@xythos.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Subject: RE: I-D ACTION:draft-ietf-webdav-quota-01.txt X-Archived-At: http://www.w3.org/mid/JIEGINCHMLABHJBIGKBCAEPPGMAA.julian.reschke@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7516 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Brian Korver > Sent: Friday, March 07, 2003 8:37 PM > To: WebDAV > Subject: Re: I-D ACTION:draft-ietf-webdav-quota-01.txt > > > > The new version differs rather substantially from > the previous, incorporating the borrowed-from-NFS > model that we discussed at the last get together. Hi Brian, I just re-read the current draft and I think it's a significant step into the right direction. However, I think the draft can be made much easier to read and more generic, without harming the "client experience". Here's my proposal: 1) Properly define the technical term "quota space", and use it when describing the live properties. The definition should be similar to what RFC3010 uses, and I think the text from the description for DAV:quota-used-bytes can be used as a basis: " The DAV:quota-used-bytes value is the value in octets representing the amount of space used by this file or directory and possibly a number of other similar files or directories, where the set of osimilaro meets at least the criterion that allocating space to any file or directory in the set will count against the quota-limit. It MUST include the total count including usage derived from sub- resources if appropriate. It SHOULD include metadata storage size if metadata storage is counted against the quota-limit. " 2) Then simply define (for *any* resource): DAV:quota-limit-bytes: number of octets that has been assigned to the currently authenticated user in the quota-space in which the resource identified by the request URL resides. DAV:quota-used-bytes: number of octets that have been allocated towards the limit above (again in the quota-space in which the resource identified by the request URL resides). (keeping the language that gives servers a lot of freedom how to count) This should give clients all the information they need to display the "percentage used" thingy. 3) The new draft introduces a new optional property DAV:quota-assigned-bytes that seems to be used to support implementations where quota spaces can be nested, so for example /A/B resides in a different quota space than /A. I'd really like to understand whether this really requires a new property, or whether the simple model above would suffice for this as well. Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Wed Mar 19 16:29:19 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09307 for ; Wed, 19 Mar 2003 16:29:19 -0500 (EST) Received: from frink.w3.org (localhost [127.0.0.1]) by frink.w3.org (8.12.8/8.12.8) with ESMTP id h2JLUh4g019078; Wed, 19 Mar 2003 16:30:43 -0500 (EST) Received: (from lists@localhost) by frink.w3.org (8.12.8/8.12.8/Submit) id h2JLUVvR018725; Wed, 19 Mar 2003 16:30:31 -0500 (EST) Resent-Date: Wed, 19 Mar 2003 16:30:31 -0500 (EST) Resent-Message-Id: <200303192130.h2JLUVvR018725@frink.w3.org> Received: from tux.w3.org (IDENT:root@tux [18.29.0.27]) by frink.w3.org (8.12.8/8.12.8) with ESMTP id h2JLUS4g018581 for ; Wed, 19 Mar 2003 16:30:28 -0500 (EST) Received: from mail.xythos.com ([206.14.210.116]) by tux.w3.org (8.12.8/8.12.8) with ESMTP id h2JLURrB014854 for ; Wed, 19 Mar 2003 16:30:27 -0500 Received: from ravms by mail.xythos.com with mail-ok (Exim 3.36 #3) id 18vlDI-000764-00; Wed, 19 Mar 2003 21:35:08 +0000 Received: from [216.36.77.241] (helo=xythoslap) by mail.xythos.com with asmtp (Exim 3.36 #3) id 18vlDI-00075t-00; Wed, 19 Mar 2003 21:35:08 +0000 From: "Lisa Dusseault" To: "'Jim Whitehead'" , "'WebDAV'" Cc: Date: Wed, 19 Mar 2003 13:30:25 -0800 Message-ID: <011001c2ee5e$c165dc90$57868182@xythoslap> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4024 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal In-Reply-To: Old-X-Envelope-To: ejw@cse.ucsc.edu, minutes@ietf.org, w3c-dist-auth@w3.org Subject: RE: Raw meeting notes from WebDAV WG meeting X-Archived-At: http://www.w3.org/mid/011001c2ee5e$c165dc90$57868182@xythoslap Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7517 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit Here are the slides, to go along with the minutes http://www.sharemation.com/~milele/public/dav/presentations/WebDAV-IETF5 6.ppt > -----Original Message----- > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org] On Behalf Of Jim Whitehead > Sent: Tuesday, March 18, 2003 6:08 PM > To: WebDAV > Subject: Raw meeting notes from WebDAV WG meeting > > > > WebDAV Working Group Meeting > San Francisco IETF, March 18 > Co-Chairs: Lisa Dusseault, Jim Whitehead > Notetaker: Jim Whitehead > > ----------- > > A meeting of the IETF WebDAV Working Group was held at IETF-56, held > in San Francisco. Approximately 25 people attended the > meeting over its > duration. > > Lisa Dusseault began by going over the agenda. She noted that DASL > discussion was dropped since there were not enough people present to > discuss the issues in depth. Lisa then led a discussion of 2518bis. > > * Discussion of locking issues in 2518bis. Slide "Agreed text so far" > - Discussion of the content type of the resource created by a LOCK > when the content type doesn't exist. One thought: pick one type. > Another choice: do whatever a server does when you send a PUT with > no Content-Type header, and a non-empty body. Rough consensus: > be silent on the issue (most likely defaulting to what happens > when a PUT with no Content-Type header). > > * Discussion of the definition of a collection. Should we use binding > terminology in 2518bis, or keep internal member terminology. Tempest > in a teakettle over internal member terminology. In the end, decided > to keep using internal member term. > > * Discussion of "First problem" slide. What should be the behavior on > a LOCK on an indirectly locked resource? Should the lock remove the > entire depth lock, or should it be redirected, or should it fail? > Rough consensus for failure, error code to be determined later. > > * Discussion of "Second problem" slide. When an If header is submitted > against a depth locked resource, must a client use the lockroot URL, > or is any URL in the locked tree OK? If the untagged If > header's referred > to resource is the same as the request URL, will this break > any existing > clients? One approach is to better identify > interoperability failures > in lock token handling. Need to make the text in the > specification in > 2518bis on the If header more clear. No consensus. Lisa will write > a message to the mailing list summarizing both sides of the issue, > and explicitly solicit feedback from Dan Brotsky, Julian > Reschke, and > Max Dunn on this, as well as generally from the mailing list. > > * Discussion of "what is locked" draft. Discussed effect of locks on > live properties. Agreement of lock affecting dead properties. Also > tentative agreement that a lock should affect all PROPPATCH > operations > on all properties, live and dead. Briefly noted that locks > do not prevent > live properties from updating their values (e.g., getcontentlength > updating after a PUT -- this is OK, even when the resource > is locked). > > * The "Last Piece" slide. No disagreement. Refined lock-root to > "lock root URL" to avoid ambiguity over what "mapping" means. > > * "Allprop replacement proposal." Agreement in the room that the > proposal listed on the slide was fine. Some concern over > interoperability > implications of adding new XML tag into PROPFIND prop requests to > ask for all dead properties. > > * Discussion on whether there should be an additional 4xx or > 5xx status > code for multistatus cases. Several viewpoints. Aesthetic: 207 is > for complete success, while a 207 can have 4xx inside it, so this is > a contradiction. Interoperability: clients may not know how > to correctly > handle a new 4xx that expresses a multistatus case, or only > use the new > 4xx for cases where it is OK for the client to treat the > entire response > as a failure. Functional: some tools may not understand > WebDAV, but still > come into contact with 207 responses. An example is an HTTP > logging tool > that might be trying to tally success and failure, and > won't properly > handle 207. Rough consensus to *not* make any changes to > 2518bis. Keep > current semantics of 207, do not add new status codes. > Main motivation > is to not break current implementations, or add a new > status code that > might cause interoperability problems. > > * Discussion of entity tags, and support level. Not strong support for > moving to SHOULD. Roy Fielding argued that there is already strong > motivation for supporting entity tags, since they provide > significant > caching benefits. But, there is experience that many DAV > servers do not > support entity tags at all, and hence interoperability might benefit > from language in the specification recommending, or giving a SHOULD > level requirement on support of entity tags. Some agreement that use > of entity tags should be RECOMMENDED (defined in 2119 to be the same > strength as SHOULD) on all PUTable resources. Also makes sense to > add an implementation note providing rationale for why entity tags > are a good thing to implement. > > ----------- > > Brian Korver, discussion of Quota specification. > > Brian began with an overview of the latest draft of the quota > specification. Some questions on the semantics of the new properties. > Brian mentioned that the definitions were taken from the definition of > the NSF quota system. The quota properties are strictly live. Quotas > are defined on resources -- there is no mechanism to ask about the > quota for a particular user. > > People who volunteered to read and review the specification. > Jim Whitehead, a grad. student of Jim's. > > Jim stated that the specification is close to WG last call, look for > this in a few months, after a few people in the WG have read and > provided feedback on the quota specification. > > ----------- > > Brief discussion of the ordering specification. Geoff Clemm overviewed > recent changes. Jim asked whether there were any objections to moving > this to a working group last call. None surfaced. > > ----------- > > Geoff Clemm then led discussion on the binding protocol. > > Geoff began with a brief overview of the binding protocol. > > Discussion of copy language in the binding specification. No > objections > on the language in the specification. Some discussion on Copy, Depth > infinity case. *** Need to add description of the behavior of > Copy, Depth > infinity case, since it's not currently covered in the specification. > > Discussion of delete and bindings. Will take this to the list > -- raised > the issue. > > Binding specification is at a point where, if you have issues with the > specification, they should be surfaced now. Will work to resolve open > issues soon, want to drive specification to closure in the > near future. > > --------- > > Geoff then led a brief discussion of the ACL protocol. Brief review of > IESG feedback on the recent last call. There is a new draft in > preparation, and will submit this as an I-D in the near future. Like > binding specification, want to quickly move to closure on this. > > --------- > > *** End of Meeting *** > > From w3c-dist-auth-request@w3.org Wed Mar 19 18:16:04 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA15121 for ; Wed, 19 Mar 2003 18:15:59 -0500 (EST) Received: from frink.w3.org (localhost [127.0.0.1]) by frink.w3.org (8.12.8/8.12.8) with ESMTP id h2JNHV4g013474; Wed, 19 Mar 2003 18:17:31 -0500 (EST) Received: (from lists@localhost) by frink.w3.org (8.12.8/8.12.8/Submit) id h2JNHKau013449; Wed, 19 Mar 2003 18:17:20 -0500 (EST) Resent-Date: Wed, 19 Mar 2003 18:17:20 -0500 (EST) Resent-Message-Id: <200303192317.h2JNHKau013449@frink.w3.org> Received: from tux.w3.org (IDENT:root@tux [18.29.0.27]) by frink.w3.org (8.12.8/8.12.8) with ESMTP id h2JNHH4g013413 for ; Wed, 19 Mar 2003 18:17:17 -0500 (EST) Received: from mail.xythos.com ([206.14.210.116]) by tux.w3.org (8.12.8/8.12.8) with ESMTP id h2JNHHrB009929 for ; Wed, 19 Mar 2003 18:17:17 -0500 Received: from ravms by mail.xythos.com with mail-ok (Exim 3.36 #3) id 18vmsf-0000Ut-00; Wed, 19 Mar 2003 23:21:57 +0000 Received: from ip-216-36-77-241.dsl.sjc.megapath.net ([216.36.77.241] helo=xythos.com) by mail.xythos.com with asmtp (Exim 3.36 #3) id 18vmsf-0000Ui-00; Wed, 19 Mar 2003 23:21:57 +0000 Date: Wed, 19 Mar 2003 15:17:12 -0800 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: "WebDAV" To: "Julian Reschke" From: Brian Korver In-Reply-To: Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) Old-X-Envelope-To: w3c-dist-auth@w3.org, julian.reschke@gmx.de Subject: Re: I-D ACTION:draft-ietf-webdav-quota-01.txt X-Archived-At: http://www.w3.org/mid/EA3803E6-5A60-11D7-894D-000393751598@xythos.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7518 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit On Wednesday, March 19, 2003, at 08:07 AM, Julian Reschke wrote: > > Hi Brian, > > I just re-read the current draft and I think it's a significant step > into > the right direction. > > However, I think the draft can be made much easier to read and more > generic, > without harming the "client experience". Here's my proposal: > > > 1) Properly define the technical term "quota space", and use it when > describing the live properties. The definition should be similar to > what > RFC3010 uses, I couldn't find the term "quota space" in 3010 at all. What definition in 3010 are you thinking of? > and I think the text from the description for > DAV:quota-used-bytes can be used as a basis: > > " The DAV:quota-used-bytes value is the value in octets representing > the amount of space used by this file or directory and possibly a > number of other similar files or directories, where the set of > osimilaro meets at least the criterion that allocating space to any > file or directory in the set will count against the quota-limit. It > MUST include the total count including usage derived from sub- > resources if appropriate. It SHOULD include metadata storage size > if metadata storage is counted against the quota-limit. " > > > 2) Then simply define (for *any* resource): > > DAV:quota-limit-bytes: number of octets that has been assigned to the > currently authenticated user in the quota-space in which the resource > identified by the request URL resides. > > DAV:quota-used-bytes: number of octets that have been allocated > towards the > limit above (again in the quota-space in which the resource identified > by > the request URL resides). Personally, I think I'd rather we stick with the definitions pulled from RFC3010. They seem pretty clear to me. > > (keeping the language that gives servers a lot of freedom how to count) > > This should give clients all the information they need to display the > "percentage used" thingy. > > > 3) The new draft introduces a new optional property > DAV:quota-assigned-bytes > that seems to be used to support implementations where quota spaces > can be > nested, so for example /A/B resides in a different quota space than > /A. I'd > really like to understand whether this really requires a new property, > or > whether the simple model above would suffice for this as well. Hmm, that was only intended as an example (and is identified as such), not as an implementation requirement. I'll add another example so that this isn't confusing. DAV:quota-assigned-bytes is merely to support implementations that allow quota to be PROPPATCHed. I'll try to make that clearer as well. > Julian > > -- > bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 > > > -brian briank@xythos.com From w3c-dist-auth-request@w3.org Thu Mar 20 03:37:47 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA11766 for ; Thu, 20 Mar 2003 03:37:36 -0500 (EST) Received: from frink.w3.org (localhost [127.0.0.1]) by frink.w3.org (8.12.8/8.12.8) with ESMTP id h2K8cq4g013186; Thu, 20 Mar 2003 03:38:52 -0500 (EST) Received: (from lists@localhost) by frink.w3.org (8.12.8/8.12.8/Submit) id h2K8ciZn013167; Thu, 20 Mar 2003 03:38:44 -0500 (EST) Resent-Date: Thu, 20 Mar 2003 03:38:44 -0500 (EST) Resent-Message-Id: <200303200838.h2K8ciZn013167@frink.w3.org> Received: from tux.w3.org (IDENT:root@tux [18.29.0.27]) by frink.w3.org (8.12.8/8.12.8) with ESMTP id h2K8cc4g013135 for ; Thu, 20 Mar 2003 03:38:38 -0500 (EST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by tux.w3.org (8.12.8/8.12.8) with SMTP id h2K8cbrB006303 for ; Thu, 20 Mar 2003 03:38:38 -0500 Received: (qmail 10476 invoked by uid 0); 20 Mar 2003 08:38:36 -0000 Received: from p3EE2470E.dip.t-dialin.net (HELO lisa) (62.226.71.14) by mail.gmx.net (mp016-rz3) with SMTP; 20 Mar 2003 08:38:36 -0000 From: "Julian Reschke" To: "Brian Korver" , "Julian Reschke" Cc: "WebDAV" Date: Thu, 20 Mar 2003 09:38:32 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal Subject: RE: I-D ACTION:draft-ietf-webdav-quota-01.txt X-Archived-At: http://www.w3.org/mid/JIEGINCHMLABHJBIGKBCCEBOGNAA.julian.reschke@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7519 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Brian Korver > Sent: Thursday, March 20, 2003 12:17 AM > To: Julian Reschke > Cc: WebDAV > Subject: Re: I-D ACTION:draft-ietf-webdav-quota-01.txt > > ... > > > 1) Properly define the technical term "quota space", and use it when > > describing the live properties. The definition should be similar to > > what > > RFC3010 uses, > > I couldn't find the term "quota space" in 3010 at all. What definition > in 3010 are you thinking of? Right, RFC3010 doesn't define the term, but it uses the concept. I just think that it makes sense to give the concept a name: The value in bytes which represent the amount of disc space used by this file or directory and possibly a number of other similar files or directories, where the set of "similar" meets at least the criterion that allocating space to any file or directory in the set will reduce the "quota_avail_hard" of every other file or directory in the set. Note that there may be a number of distinct but overlapping sets of files or directories for which a quota_used value is maintained. E.g. "all files with a given owner", "all files with a given group owner". etc. The server is at liberty to choose any of those sets but should do so in a repeatable way. The rule may be configured per- filesystem or may be "choose the set with the smallest quota". So basically, a "quota space" is the set of resources that share the same quota. > > and I think the text from the description for > > DAV:quota-used-bytes can be used as a basis: > > > > " The DAV:quota-used-bytes value is the value in octets representing > > the amount of space used by this file or directory and possibly a > > number of other similar files or directories, where the set of > > osimilaro meets at least the criterion that allocating space to any > > file or directory in the set will count against the quota-limit. It > > MUST include the total count including usage derived from sub- > > resources if appropriate. It SHOULD include metadata storage size > > if metadata storage is counted against the quota-limit. " > > > > > > 2) Then simply define (for *any* resource): > > > > DAV:quota-limit-bytes: number of octets that has been assigned to the > > currently authenticated user in the quota-space in which the resource > > identified by the request URL resides. > > > > DAV:quota-used-bytes: number of octets that have been allocated > > towards the > > limit above (again in the quota-space in which the resource identified > > by > > the request URL resides). > > Personally, I think I'd rather we stick with the definitions > pulled from RFC3010. They seem pretty clear to me. For the record, i'm absolutely in favor to stick with the definitions from RFC3010. Why don't we just steal them verbatim, or just refer to 3010? IMHO, The value in bytes which represents the amount of additional disk space that can be allocated to this file or directory before the user may reasonably be warned. It is understood that this space may be consumed by allocations to other files or directories though there is a rule as to which other files or directories. is very clear (we may have to map some terms though). If we stick with this language it's also much clearer why the distinction between plain resources and collections (and other types) really doesn't make sense at all -- I'd prfer the spec not to say anything about that. > > (keeping the language that gives servers a lot of freedom how to count) > > > > This should give clients all the information they need to display the > > "percentage used" thingy. > > > > > > 3) The new draft introduces a new optional property > > DAV:quota-assigned-bytes > > that seems to be used to support implementations where quota spaces > > can be > > nested, so for example /A/B resides in a different quota space than > > /A. I'd > > really like to understand whether this really requires a new property, > > or > > whether the simple model above would suffice for this as well. > > Hmm, that was only intended as an example (and is identified as such), > not > as an implementation requirement. I'll add another example so that this > isn't confusing. > > DAV:quota-assigned-bytes is merely to support implementations that allow > quota to be PROPPATCHed. I'll try to make that clearer as well. That didn't come through. Now it reads: The value of this property will usually be protected, although a user with sufficient privileges may be permitted to change the value. The property is useful even if it is protected. A 403 Forbidden response is RECOMMENDED for attempts to write a protected property. That sounds as if *usually* the property is read-only. BTW: why do we need an additional property for that? Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Thu Mar 20 16:11:58 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA06886 for ; Thu, 20 Mar 2003 16:11:57 -0500 (EST) Received: from frink.w3.org (localhost [127.0.0.1]) by frink.w3.org (8.12.8/8.12.8) with ESMTP id h2KLDL4g000246; Thu, 20 Mar 2003 16:13:21 -0500 (EST) Received: (from lists@localhost) by frink.w3.org (8.12.8/8.12.8/Submit) id h2KLCnn8000145; Thu, 20 Mar 2003 16:12:49 -0500 (EST) Resent-Date: Thu, 20 Mar 2003 16:12:49 -0500 (EST) Resent-Message-Id: <200303202112.h2KLCnn8000145@frink.w3.org> Received: from tux.w3.org (IDENT:root@tux [18.29.0.27]) by frink.w3.org (8.12.8/8.12.8) with ESMTP id h2KLCk4g000113 for ; Thu, 20 Mar 2003 16:12:46 -0500 (EST) Received: from ucsc.edu (cats-mx1.ucsc.edu [128.114.129.36]) by tux.w3.org (8.12.8/8.12.8) with ESMTP id h2KLCkrB032344 for ; Thu, 20 Mar 2003 16:12:46 -0500 Received: from Tycho (dhcp-55-196.cse.ucsc.edu [128.114.55.196]) by ucsc.edu (8.10.1/8.10.1) with SMTP id h2KLCOk00950 for ; Thu, 20 Mar 2003 13:12:24 -0800 (PST) From: "Jim Whitehead" To: "WebDAV" Date: Thu, 20 Mar 2003 13:09:12 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 In-Reply-To: X-UCSC-CATS-MailScanner: Found to be clean Subject: RE: Raw meeting notes from WebDAV WG meeting X-Archived-At: http://www.w3.org/mid/AMEPKEBLDJJCCDEJHAMIAELJGLAA.ejw@cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7520 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit Jason Crawford writes: > << > * Discussion of "First problem" slide. What should be the behavior on > a LOCK on an indirectly locked resource? Should the lock remove the > entire depth lock, or should it be redirected, or should it fail? > Rough consensus for failure, error code to be determined later. > >> > Jim, could you publicly clarify this one. I'm not sure what it's refering > to. Sure. For example, say you have the following set of resources: C1 / | \ a C2 b / \ d e C1, C2 are collections a, b, d, e are non-collection resources C1 contains a, C2, b C2 contains d, e If a Depth infinity lock is taken out on C1, using the terminology from the meeting (really from Geoff Clemm's GULP proposal), resource C1 is directly locked, and resources a, C2, b, d, e are indirectly locked (that is, they were not the target of the LOCK request). Given this terminological background, the question is, what is the behavior of "UNLOCK" (the raw meeting notes are in error -- they say LOCK, and should say UNLOCK) if applied to any of a, C2, b, d, or e? The three choices discussed were: 1) remove the entire depth lock (i.e., is equivalent to an UNLOCK on C1) 2) be redirected to C1 using HTTP redirection (3xx) 3) fail (4xx) The rough consensus in the meeting was that the response should fail (choice #3). - Jim From w3c-dist-auth-request@w3.org Thu Mar 20 16:32:53 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07863 for ; Thu, 20 Mar 2003 16:32:53 -0500 (EST) Received: from frink.w3.org (localhost [127.0.0.1]) by frink.w3.org (8.12.8/8.12.8) with ESMTP id h2KLYf4g004964; Thu, 20 Mar 2003 16:34:41 -0500 (EST) Received: (from lists@localhost) by frink.w3.org (8.12.8/8.12.8/Submit) id h2KLYe7Z004927; Thu, 20 Mar 2003 16:34:40 -0500 (EST) Resent-Date: Thu, 20 Mar 2003 16:34:40 -0500 (EST) Resent-Message-Id: <200303202134.h2KLYe7Z004927@frink.w3.org> Received: from tux.w3.org (IDENT:root@tux [18.29.0.27]) by frink.w3.org (8.12.8/8.12.8) with ESMTP id h2KLYc4g004852 for ; Thu, 20 Mar 2003 16:34:38 -0500 (EST) Received: from mail.gmx.net (mail.gmx.net [213.165.65.60]) by tux.w3.org (8.12.8/8.12.8) with SMTP id h2KLYarB004865 for ; Thu, 20 Mar 2003 16:34:37 -0500 Received: (qmail 30374 invoked by uid 0); 20 Mar 2003 21:34:30 -0000 Received: from p3EE24774.dip.t-dialin.net (HELO lisa) (62.226.71.116) by mail.gmx.net (mp002-rz3) with SMTP; 20 Mar 2003 21:34:30 -0000 From: "Julian Reschke" To: "Jim Whitehead" , "WebDAV" Date: Thu, 20 Mar 2003 22:34:26 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Subject: RE: Raw meeting notes from WebDAV WG meeting X-Archived-At: http://www.w3.org/mid/JIEGINCHMLABHJBIGKBCMEEEGNAA.julian.reschke@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7521 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Jim Whitehead > Sent: Thursday, March 20, 2003 10:09 PM > To: WebDAV > Subject: RE: Raw meeting notes from WebDAV WG meeting > > > > > Jason Crawford writes: > > << > > * Discussion of "First problem" slide. What should be the behavior on > > a LOCK on an indirectly locked resource? Should the lock remove the > > entire depth lock, or should it be redirected, or should it fail? > > Rough consensus for failure, error code to be determined later. > > >> > > Jim, could you publicly clarify this one. I'm not sure what > it's refering > > to. > > Sure. For example, say you have the following set of resources: > > C1 > / | \ > a C2 b > / \ > d e > > C1, C2 are collections > a, b, d, e are non-collection resources > C1 contains a, C2, b > C2 contains d, e > > If a Depth infinity lock is taken out on C1, using the > terminology from the > meeting (really from Geoff Clemm's GULP proposal), resource C1 is directly > locked, and resources a, C2, b, d, e are indirectly locked (that is, they > were not the target of the LOCK request). > > Given this terminological background, the question is, what is > the behavior > of "UNLOCK" (the raw meeting notes are in error -- they say LOCK, > and should > say UNLOCK) if applied to any of a, C2, b, d, or e? The three choices > discussed were: > > 1) remove the entire depth lock (i.e., is equivalent to an UNLOCK on C1) > 2) be redirected to C1 using HTTP redirection (3xx) > 3) fail (4xx) > > The rough consensus in the meeting was that the response should > fail (choice > #3). In theory, this makes a lot of sense (UNLOCK should be applied to the URL to which the original LOCK request was sent). In practice, old clients that want to break a lock (after finding it using lock discovery) may get into trouble by that change (if it is a change), because in RFC2518, there was no cheap way to find the root of a lock. Note that issue "UNLOCK_WHAT_URL" (on the issues list) says that you can use any of the URLs protected by the lock. Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Thu Mar 20 23:36:14 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA21368 for ; Thu, 20 Mar 2003 23:36:13 -0500 (EST) Received: from frink.w3.org (localhost [127.0.0.1]) by frink.w3.org (8.12.8/8.12.8) with ESMTP id h2L4UP4g025951; Thu, 20 Mar 2003 23:30:25 -0500 (EST) Received: (from lists@localhost) by frink.w3.org (8.12.8/8.12.8/Submit) id h2L4UOp6025897; Thu, 20 Mar 2003 23:30:24 -0500 (EST) Resent-Date: Thu, 20 Mar 2003 23:30:24 -0500 (EST) Resent-Message-Id: <200303210430.h2L4UOp6025897@frink.w3.org> Received: from tux.w3.org (IDENT:root@tux [18.29.0.27]) by frink.w3.org (8.12.8/8.12.8) with ESMTP id h2L4UE4g025749 for ; Thu, 20 Mar 2003 23:30:14 -0500 (EST) Received: from sus-ma1it31.rational.com (sus-ma1it31.rational.com [130.213.73.33]) by tux.w3.org (8.12.8/8.12.8) with ESMTP id h2L4UErB025906 for ; Thu, 20 Mar 2003 23:30:14 -0500 Received: from sus-ma1it00.rational.com ([10.64.1.25]) by 10.64.1.33 with InterScan Messaging Security Suite; Thu, 20 Mar 2003 23:13:27 -0500 Received: by sus-ma1it00.rational.com with Internet Mail Service (5.5.2656.59) id ; Thu, 20 Mar 2003 23:30:07 -0500 Message-ID: From: "Clemm, Geoff" To: w3c-dist-auth@w3.org Date: Thu, 20 Mar 2003 23:30:07 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain; charset="iso-8859-1" Subject: RE: DAV properties / PROPFIND vs GET/HEAD X-Archived-At: http://www.w3.org/mid/E4F2D33B98DF7E4880884B9F0E6FDEE2023C97B1@SUS-MA1IT01 Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7524 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: I agree that we should clarify what is meant by "accept headers". But I'd be concerned about dropping this language, because it could introduce incompatibility between new clients (that would then expect accept headers to be respected) and old servers (that would ignore them). Cheers, Geoff -----Original Message----- From: Julian Reschke [mailto:julian.reschke@gmx.de] Sent: Monday, March 17, 2003 1:45 PM To: w3c-dist-auth@w3.org Subject: DAV properties / PROPFIND vs GET/HEAD Hi, RFC2518 currently says that the values of get* properties must match those HTTP headers returned upon a GET/HEAD request "without accept headers" (for instance, see 13.3). I'd like to see clarified a) the rational for this restriction, and b) a precise definition of what "accept" headers are. Looking at RFC2616, the only "accept" header is actually the one called "accept", while "accept-language" does not qualify. My personal preference would be to get rid of this language, unless we can agree on what it's supposed to accomplish, and rephrase it accordingly. I personally think that PROPFIND should be just an extended syntax for HEAD, supporting additional properties and allowing collection member retrieval, but stay completely compatible with the GET/HEAD response headers where possible. Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Thu Mar 20 23:36:16 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA21382 for ; Thu, 20 Mar 2003 23:36:16 -0500 (EST) Received: from frink.w3.org (localhost [127.0.0.1]) by frink.w3.org (8.12.8/8.12.8) with ESMTP id h2L4UP4g025949; Thu, 20 Mar 2003 23:30:25 -0500 (EST) Received: (from lists@localhost) by frink.w3.org (8.12.8/8.12.8/Submit) id h2L4UHrX025789; Thu, 20 Mar 2003 23:30:17 -0500 (EST) Resent-Date: Thu, 20 Mar 2003 23:30:17 -0500 (EST) Resent-Message-Id: <200303210430.h2L4UHrX025789@frink.w3.org> Received: from tux.w3.org (IDENT:root@tux [18.29.0.27]) by frink.w3.org (8.12.8/8.12.8) with ESMTP id h2L4UE4g025732 for ; Thu, 20 Mar 2003 23:30:14 -0500 (EST) Received: from sus-ma1it31.rational.com (sus-ma1it31.rational.com [130.213.73.33]) by tux.w3.org (8.12.8/8.12.8) with ESMTP id h2L4UErB025902 for ; Thu, 20 Mar 2003 23:30:14 -0500 Received: from sus-ma1it00.rational.com ([10.64.1.25]) by 10.64.1.33 with InterScan Messaging Security Suite; Thu, 20 Mar 2003 23:13:21 -0500 Received: by sus-ma1it00.rational.com with Internet Mail Service (5.5.2656.59) id ; Thu, 20 Mar 2003 23:30:01 -0500 Message-ID: From: "Clemm, Geoff" To: w3c-dist-auth@w3.org Date: Thu, 20 Mar 2003 23:30:01 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain; charset="iso-8859-1" Subject: RE: I-D ACTION:draft-ietf-webdav-rfc2518bis-03.txt X-Archived-At: http://www.w3.org/mid/E4F2D33B98DF7E4880884B9F0E6FDEE2023C97B0@SUS-MA1IT01 Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7522 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: I'd like to thank Julian for this excellent and careful review! I agree with all of his points. The only one I was tempted to question was "Section 13: XML element definitions", where he suggested going back to the old syntax for DTD's. But upon further reflection, although I believe the new more flexible notation should be used when defining all new elements, for compatibility with old servers, we should probably maintain the element order defined by 2518, so I actually agree with that point as well (:-). So I vote that all of the changes suggested by Julian be made to the next draft of 2518bis. Note: I have no good idea about how to deal with the 5 author limit question (:-). Cheers, Geoff -----Original Message----- From: Julian Reschke [mailto:julian.reschke@gmx.de] Sent: Tuesday, March 18, 2003 7:52 AM To: w3c-dist-auth@w3.org Subject: RE: I-D ACTION:draft-ietf-webdav-rfc2518bis-03.txt Here's a set of both -bis03 and generic RFC2518 comments: Content: 03-C01 Paragraph 1: "A DTD is provided..." -> "An informational DTD is provided..." 03-C02 4.4: "...or when they may be shown to a human user and hence require encoding in..." I'm not sure what the requirement "may be shown to a human user" is supposed to mean here. Proposal: just write: "...or when they require encoding in..." 03-C03 4.4: "Note that the use of a new top-level URI identifier as a namespace is considered by many to be a bad thing..." Rewrite as: "Note that both defining a new URI scheme just for the purpose of identifying protocol elements, and using just the scheme name as a namespace name is to be considered a bad practice, and should not be copied". 03-C04 4.5: "The value of a property when expressed in XML MUST be well formed." The value of a property always is expressed in XML (or more precisely: an XML fragment). XML by definition is well-formed. 03-C05 4.5: "The value of a property appears inside the property name element. The value may be any text, including valid XML. When the value is structured as XML, namespaces that are in scope for that part of the XML document apply within the property value as well, and MUST be preserved in server storage for retransmission later. Namespace prefixes need not be preserved due to the rules of prefix declaration in XML." 1) I think this needs to rephrased to use proper XML terminology, also 2) I think that namespace prefixes within the property value do need to be round.tripped. Proposal: "The value of a property appears inside the property name element and may be any kind of well-formed XML content, including both text-only and mixed content. When the property value contains further XML elements, namespaces and namespace prefixes that are in scope for that part of the XML document apply within the property value as well, and MUST be preserved in server storage for retransmission later." 03-C06: 6.3: "A lock token is returned by every successful LOCK operation in the lockdiscovery property in the response body, and can also be found through lock discovery on a resource. Each lock has only one unique lock token." Change to: "A lock token is returned by every successful LOCK operation in the lock-token header, and can also be found through lock discovery on a resource. Each lock has exactly one unique lock token." 03-C07: 6.4: "All resources MUST recognize the opaquelocktoken scheme and, at minimum, recognize that the lock token does not refer to an outstanding lock on the resource." (old text) I think this is misleading. Any resource must recognize any valid URI. If a URI uses a scheme it doesn't know of, this simply means it doesn't identify any particular lock assigned by this server. So I'd recommend to get rid of this sentence, and possibly add a clarification to 6.3 instead. 03-C08: 7.4: "However, interoperability and compliance problems have been found with lock-null resources. Therefore, they are deprecated. WebDAV servers compliant with this document SHOULD create regular locked empty resources, which behave in every way as if they were a normal resource." This sort of suggests that lock-null resources indeed are still something different than a normal resource, which isn't true. 03-C09: 7.4: "Can be downloaded, deleted, moved, copied, and in all ways behave as a regular resource, not a lock-null resource." I think the term "downloaded" is misleading here. From a WebDAV protocol p.o.v., it probably should be "read". 03-C10: 7.4.: "SHOULD default to a content-type of "application/octet-stream". " No. I don't think there's consensus for that, and requiring a specific content type seems to have no value at all to clients (see also 8.11, "Locking Unmapped URLs"). 03-C11: 7.8: "If an error is received in response to a refresh LOCK request the client SHOULD assume that the lock was not refreshed." I think we should make that a "MUST". 03-C12: 8.1.1.: "Some of the following new HTTP methods use XML as a request and response format. All DAV compliant clients and resources MUST use XML parsers that are compliant with [REC-XML]." Add "...and [REC-XMLNS]". We also need allow servers and clients to rejects a certain set of request/response that are indeed well-formed, in particular: - when it exceeds some predefined size or - when expansion of internal entities may cause a denial of service. 03-C13: 8.1.2: "Some of these new methods do not define bodies. Servers MUST examine all requests for a body, even when a body was not expected. In cases where a request body is present but would be ignored by a server, the server MUST reject the request with 415 (Unsupported Media Type). This informs the client (which may have been attempting to use an extension) that the body could not be processed as they intended." I'd like to understand whether this affects methods other than MKCOL. 03-C14: 8.1.3: "When the Location header is used in a response, it is used by the server to indicate the preferred address for the target resource of the request. Whenever the server has a preferred address, it should use that address consistently. This means that when a response contains a Location header, all the URLs in the response body (e.g. a Multi-Status) should be consistent." If we keep this paragraph, we'll have to define what "consistent" means here. 03-C15: 8.1.4.: "Note that HTTP 1.1 requires the Date header in all responses." That's not true. HTTP 1.1 specifically supports clockless servers. 03-C16: 8.1.5: "If ETags are supported for a resource, the server MUST return the ETag header in all PUT and GET responses to that resource, as well as provide the same value for the 'getetag' property." Note that this breaks the "etag promotion" strategy used both by IIS and Moddav (PUT usually returns weak etags which later are promoted to strong etags when there was no other change to that resource within a specific time window). Therefore I'd make that a SHOULD (at least for PUT). 03-C17: 8.1.5.: "Because clients may be forced to prompt users or throw away changed content if the ETag changes, a WebDAV server MUST not change the ETag (or getlastmodified value) for a resource when only its property values change." Some servers do, and I don't think we can change that. Therefore I think this change at least needs explicit consensus on the mailing list. 03-C18: 8.1.6: "HTTP and WebDAV did not use the bodies of most error responses until DeltaV introduced a mechanism to include more specific information in the body of an error response (section 1.6 of [RFC3253])." That's not really true. HTTP indeed recommends to send error descriptions in the response bodies as well. 03-C19: General comment re: 8.1.6: I really like that change (actually, I like it so much that I'd like to have condition names for all frequently signalled problems....). However, if it uses the same format as RFC3253, it should be consistent with it. In particular, the names should identify conditions that must be met. For instance, use "allow-external-entities" rather than "forbid-internal-entities". We may also want to note that one DAV:error element can hold multiple elements identifying failed conditions. 03-C20: 8.2.: "DAV compliant servers MUST support the "0", "1" and "infinity" behaviors." Change to: "DAV compliant servers MUST support the "0" and "1" behaviors and MAY support the "infinity" behavior." 03-C21: 8.2.: "Note that 'allprop' does not return values for all properties." Change to: "Note that 'allprop' does not return values for all live properties." 03-C22: 8.2: "URLs for collections appearing in the results MUST end in a slash character." I don't think we have consensus for this being a MUST. 03-C23: 8.2: "Note that URLs and URIs in XML must always be fully legal URIs. For example, it is illegal to use a space character or double-quote in a URI [RFC2396]. URL-escaping is commonly used (e.g. replace a space with a sequence such as %20). The URI must not appear in XML "unescaped", it must be in its legal URI format." This is misleading. Of course URIs must conform to the URI syntax - that's the whole point, right? In particular, there's no such thing as a "unescaped form" of a URI. URIs do not allow the space character, and therefore a URI never ever contains a space character. What we should say here is how servers should behave when their internal implementation model of collections allow member names that aren't legal URL path segments (answer: encode as UTF-8 octet stream, then URI-escape). 03-C24: 8.2.2: "This example also demonstrates the use of XML namespace scoping, and the default namespace. Since the "xmlns" attribute does not contain an explicit "shorthand name" (prefix) letter, the namespace applies by default to all enclosed elements. Hence, all elements which do not explicitly state the namespace to which they belong are members of the "DAV:" namespace schema." Change to: "This example also demonstrates the use of XML namespace scoping, and the default namespace. Since the "xmlns" attribute does not contain a prefix, the namespace applies by default to all non-prefixed enclosed elements. Hence, all elements which do not explicitly state the namespace to which they belong are members of the "DAV:" namespace." (Actually I'd rather prefer to get rid of this. RFC2518bis shouldn't try to give XML lessons). 03-C25: 8.7: "If the DELETE method is issued to a non-collection resource whose URIs are an internal member of one or more collections, then during DELETE processing a server MUST remove any URI for the resource identified by the Request-URI from collections which contain it as a member." I think we want to get rid of this statement. Does anybody implement this right now? 03-C26: 8.11: "The LOCK request may have a Timeout header." "may" -> "MAY". 03-C27: 8.11, "Interaction with other Methods": "However, independent of lock type, a successful DELETE of a resource MUST cause all of its locks to be removed." (old text) I think this is misleading. A DELETE on a resource only removes those locks that aren't inherited. 03-C28: 8.12: "A successful response to an UNLOCK method does not mean that the resource is unlocked. At most, it means that the specified token no longer identifies a lock on the resource." Change to: "A successful response to an UNLOCK method does not mean that the resource is unlocked. At most, it means that the specified token no longer identifies a lock on any resource." 03-C29: 9.1 (DAV header) allows coded URLs in the DAV header. I'd like to see the rationale for that. 03-C30: 9.4 (force-authenticate): is this the consensus we reached in January? Ilyas, did you take notes? 03-C31: 9.5 defines "" as a new special state token. I think this is unneeded - any URI which is known not to identify a lock MUST work as well, so we can simply recommend using something like "" (which is something that RFC2518-compliant servers already support). 03-C32: (old text) The example in 9.5.2 uses an invalid lock token (the URI scheme "locktoken" isn't IETF-registered, so it can't claim conformance to the uniqueness requirements). Just use a sample token using the "opaquelocktoken" scheme instead). 03-C33: 9.5.5: "The not production is used to reverse that value." Change to: "The 'Not' production is used to reverse that value." 03-C34: Section 13: XML element definitions I don't like the syntax change in the DTDs. For instance, activelock now is defined as: ANY value: Any number of elements, including one of each of (lockscope, locktype, depth, owner, timeout, locktoken, lockroot) It used to be: For consistency with RFC2518, RFC3253 and the ACL spec we really should stay with the old notation. 03-C35: Section 17: "which has explicit provisions for character set tagging and encoding, and requires that XML processors read XML elements encoded, at minimum, using the UTF-8 [UTF-8] encoding of the ISO 10646 multilingual plane." Unless we get rid of this section, we'll have to add UTF-16. 03-C36: Section 17: "Names used within this specification fall into three categories: names of protocol elements such as methods and headers, names of XML elements, and names of properties." We may want to add a new category (condition names). Editorial notes: 03-E01 Expiry date is wrong. 03-E02 IETF wants a maximum of 5 authors. 03-E03 Paragraph 1: "marshall" -> "marshal" 03-E04 There are many places where example URLs do not use the set of example host names allowed by the IETF. 03-E05 8.1.5 uses the term "etag". HTTP uses "etag" only as header names, and talks about "entity tags" everywhere else. So should we. 03-E06 8.2.2 uses the term "progeny", which I haven't seen before in this context. Maybe replace by something more common, such as "members". 03-E07: 8.2.2. still uses concatenation of namespace names and element names to identify property names. -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Thu Mar 20 23:36:20 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA21396 for ; Thu, 20 Mar 2003 23:36:20 -0500 (EST) Received: from frink.w3.org (localhost [127.0.0.1]) by frink.w3.org (8.12.8/8.12.8) with ESMTP id h2L4UQ4g025953; Thu, 20 Mar 2003 23:30:26 -0500 (EST) Received: (from lists@localhost) by frink.w3.org (8.12.8/8.12.8/Submit) id h2L4UK88025842; Thu, 20 Mar 2003 23:30:20 -0500 (EST) Resent-Date: Thu, 20 Mar 2003 23:30:20 -0500 (EST) Resent-Message-Id: <200303210430.h2L4UK88025842@frink.w3.org> Received: from tux.w3.org (IDENT:root@tux [18.29.0.27]) by frink.w3.org (8.12.8/8.12.8) with ESMTP id h2L4UI4g025794 for ; Thu, 20 Mar 2003 23:30:18 -0500 (EST) Received: from sus-ma1it31.rational.com (sus-ma1it31.rational.com [130.213.73.33]) by tux.w3.org (8.12.8/8.12.8) with ESMTP id h2L4UIrB025914 for ; Thu, 20 Mar 2003 23:30:18 -0500 Received: from sus-ma1it00.rational.com ([10.64.1.25]) by 10.64.1.33 with InterScan Messaging Security Suite; Thu, 20 Mar 2003 23:13:32 -0500 Received: by sus-ma1it00.rational.com with Internet Mail Service (5.5.2656.59) id ; Thu, 20 Mar 2003 23:30:12 -0500 Message-ID: From: "Clemm, Geoff" To: WebDAV Date: Thu, 20 Mar 2003 23:30:10 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain Subject: RE: Raw meeting notes from WebDAV WG meeting X-Archived-At: http://www.w3.org/mid/E4F2D33B98DF7E4880884B9F0E6FDEE2023C97B2@SUS-MA1IT01 Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7523 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: If current clients depend on the "can unlock with the URL of indirectly locked resources", then I believe we can address Julian's concern with an interoperability note that states "for interoperability with older clients, a server MAY automatically redirect an UNLOCK on an indirectly locked resource to the lock root URL of that lock. Note: We should also include in 2518bis the motivation for this restriction; namely, that it prevents a client from mistakenly unlocking an entire tree of resources when all it wanted to do (and all it thought it was doing) was unlocking one of the members of that tree of resources. Cheers, Geoff -----Original Message----- From: Julian Reschke [mailto:julian.reschke@gmx.de] Sent: Thursday, March 20, 2003 4:34 PM To: Jim Whitehead; WebDAV Subject: RE: Raw meeting notes from WebDAV WG meeting > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Jim Whitehead > Sent: Thursday, March 20, 2003 10:09 PM > To: WebDAV > Subject: RE: Raw meeting notes from WebDAV WG meeting > > > > > Jason Crawford writes: > > << > > * Discussion of "First problem" slide. What should be the behavior on > > a LOCK on an indirectly locked resource? Should the lock remove the > > entire depth lock, or should it be redirected, or should it fail? > > Rough consensus for failure, error code to be determined later. > > >> > > Jim, could you publicly clarify this one. I'm not sure what > it's refering > > to. > > Sure. For example, say you have the following set of resources: > > C1 > / | \ > a C2 b > / \ > d e > > C1, C2 are collections > a, b, d, e are non-collection resources > C1 contains a, C2, b > C2 contains d, e > > If a Depth infinity lock is taken out on C1, using the > terminology from the > meeting (really from Geoff Clemm's GULP proposal), resource C1 is directly > locked, and resources a, C2, b, d, e are indirectly locked (that is, they > were not the target of the LOCK request). > > Given this terminological background, the question is, what is > the behavior > of "UNLOCK" (the raw meeting notes are in error -- they say LOCK, > and should > say UNLOCK) if applied to any of a, C2, b, d, or e? The three choices > discussed were: > > 1) remove the entire depth lock (i.e., is equivalent to an UNLOCK on C1) > 2) be redirected to C1 using HTTP redirection (3xx) > 3) fail (4xx) > > The rough consensus in the meeting was that the response should > fail (choice > #3). In theory, this makes a lot of sense (UNLOCK should be applied to the URL to which the original LOCK request was sent). In practice, old clients that want to break a lock (after finding it using lock discovery) may get into trouble by that change (if it is a change), because in RFC2518, there was no cheap way to find the root of a lock. Note that issue "UNLOCK_WHAT_URL" (on the issues list) says that you can use any of the URLs protected by the lock. Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Fri Mar 21 11:50:19 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18591 for ; Fri, 21 Mar 2003 11:50:19 -0500 (EST) Received: from frink.w3.org (localhost [127.0.0.1]) by frink.w3.org (8.12.8/8.12.8) with ESMTP id h2LGhh4g007835; Fri, 21 Mar 2003 11:43:43 -0500 (EST) Received: (from lists@localhost) by frink.w3.org (8.12.8/8.12.8/Submit) id h2LGgw0e007754; Fri, 21 Mar 2003 11:42:58 -0500 (EST) Resent-Date: Fri, 21 Mar 2003 11:42:58 -0500 (EST) Resent-Message-Id: <200303211642.h2LGgw0e007754@frink.w3.org> Received: from tux.w3.org (IDENT:root@tux [18.29.0.27]) by frink.w3.org (8.12.8/8.12.8) with ESMTP id h2LGgu4g007720 for ; Fri, 21 Mar 2003 11:42:56 -0500 (EST) Received: from mail.gmx.net (mail.gmx.net [213.165.65.60]) by tux.w3.org (8.12.8/8.12.8) with SMTP id h2LGgtrB021896 for ; Fri, 21 Mar 2003 11:42:55 -0500 Received: (qmail 8344 invoked by uid 0); 21 Mar 2003 16:42:49 -0000 Received: from mail.greenbytes.de (HELO lisa) (217.5.201.10) by mail.gmx.net (mp007-rz3) with SMTP; 21 Mar 2003 16:42:49 -0000 From: "Julian Reschke" To: "Clemm, Geoff" , Date: Fri, 21 Mar 2003 17:42:48 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Subject: RE: DAV properties / PROPFIND vs GET/HEAD X-Archived-At: http://www.w3.org/mid/JIEGINCHMLABHJBIGKBCMEGNGNAA.julian.reschke@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7525 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Clemm, Geoff > Sent: Friday, March 21, 2003 5:30 AM > To: w3c-dist-auth@w3.org > Subject: RE: DAV properties / PROPFIND vs GET/HEAD > > > > I agree that we should clarify what is meant by "accept headers". > But I'd be concerned about dropping this language, because it could > introduce incompatibility between new clients (that would then > expect accept headers to be respected) and old servers (that would > ignore them). Possibly. I think the first step should be to find out what this restriction is for, and to exactly which headers it's supposed to apply. Can anyone remember why the original authors came up with this description? Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Fri Mar 21 12:04:21 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18962 for ; Fri, 21 Mar 2003 12:04:20 -0500 (EST) Received: from frink.w3.org (localhost [127.0.0.1]) by frink.w3.org (8.12.8/8.12.8) with ESMTP id h2LGwX4g009742; Fri, 21 Mar 2003 11:58:33 -0500 (EST) Received: (from lists@localhost) by frink.w3.org (8.12.8/8.12.8/Submit) id h2LGwWJw009717; Fri, 21 Mar 2003 11:58:32 -0500 (EST) Resent-Date: Fri, 21 Mar 2003 11:58:32 -0500 (EST) Resent-Message-Id: <200303211658.h2LGwWJw009717@frink.w3.org> Received: from tux.w3.org (IDENT:root@tux [18.29.0.27]) by frink.w3.org (8.12.8/8.12.8) with ESMTP id h2LGwV4g009684 for ; Fri, 21 Mar 2003 11:58:31 -0500 (EST) Received: from mail.gmx.net (mail.gmx.net [213.165.65.60]) by tux.w3.org (8.12.8/8.12.8) with SMTP id h2LGwUrB025677 for ; Fri, 21 Mar 2003 11:58:30 -0500 Received: (qmail 32140 invoked by uid 0); 21 Mar 2003 16:58:24 -0000 Received: from mail.greenbytes.de (HELO lisa) (217.5.201.10) by mail.gmx.net (mp009-rz3) with SMTP; 21 Mar 2003 16:58:24 -0000 From: "Julian Reschke" To: "Clemm, Geoff" , Date: Fri, 21 Mar 2003 17:58:23 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Subject: RE: I-D ACTION:draft-ietf-webdav-rfc2518bis-03.txt X-Archived-At: http://www.w3.org/mid/JIEGINCHMLABHJBIGKBCAEGPGNAA.julian.reschke@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7526 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Clemm, Geoff > Sent: Friday, March 21, 2003 5:30 AM > To: w3c-dist-auth@w3.org > Subject: RE: I-D ACTION:draft-ietf-webdav-rfc2518bis-03.txt > > > > I'd like to thank Julian for this excellent and careful review! > > I agree with all of his points. The only one I was tempted to > question was "Section 13: XML element definitions", where he > suggested going back to the old syntax for DTD's. But upon > further reflection, although I believe the new more flexible > notation should be used when defining all new elements, > for compatibility with old servers, we should probably maintain > the element order defined by 2518, so I actually agree with that > point as well (:-). Well. The issue here is that all of our specs are using DTDs to describe protocol elements. But for many reasons, DTDs can not accurately describe the content models we use in WebDAV (namespaces, ordering, special extensibility rules...). One way to fix this would be to use a different schema language (XML Schema won't help a lot, RelaxNG may), or to get rid of the formal notation and fully describe the structure in prose. I think the latter doesn't fly, as it makes both reading and writing the specs much harder. Changing the schema language doesn't seem to solve it as well, unless we can decide to use one that actually *can* express the constraints in WebDAV (I *think* RelaxNG could, but I'd be surprised if we'd get consensus to make that change). That leaves us with DTDs. Right now, RFC2518, RFC3253, and some other specs which are nearing completion (ACL, Bind, Ordering) all use the same approach, which is: Use DTDs with the following additional guidelines: - elements are in the DAV: namespace - ordering doesn't matter (I *think* that's what most people assume) - extensibility rules from RFC2518 appendix apply This has worked fairly well. In particular, it allows me to write down things like: without adding a lot of prose. Again, that's better both to read *and* to author. In addition, making a change now will make RFC2518bis inconsistent with the other specs that already are published or close to submission. I think this would be a mistake, because it's guaranteed to confuse implementors. So my proposal is to keep the old syntax, and add crystal-clear rules how to read the DTDs (see for instance [1]). In addition, we'll have to fix the edge cases in RFC2518 (for instance state that extension elements in DAV:prop MUST NOT be ignored). > So I vote that all of the changes suggested by Julian be made > to the next draft of 2518bis. Note: I have no good idea about > how to deal with the 5 author limit question (:-). > > Cheers, > Geoff Regards, Julian [1] -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Fri Mar 21 20:16:22 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA04515 for ; Fri, 21 Mar 2003 20:16:22 -0500 (EST) Received: from frink.w3.org (localhost [127.0.0.1]) by frink.w3.org (8.12.8/8.12.8) with ESMTP id h2M1Ab4g023480; Fri, 21 Mar 2003 20:10:37 -0500 (EST) Received: (from lists@localhost) by frink.w3.org (8.12.8/8.12.8/Submit) id h2M1AT4X023420; Fri, 21 Mar 2003 20:10:29 -0500 (EST) Resent-Date: Fri, 21 Mar 2003 20:10:29 -0500 (EST) Resent-Message-Id: <200303220110.h2M1AT4X023420@frink.w3.org> Received: from tux.w3.org (IDENT:root@tux [18.29.0.27]) by frink.w3.org (8.12.8/8.12.8) with ESMTP id h2M1AR4g023388 for ; Fri, 21 Mar 2003 20:10:27 -0500 (EST) Received: from mail.xythos.com ([206.14.210.116]) by tux.w3.org (8.12.8/8.12.8) with ESMTP id h2M1AQrB011658 for ; Fri, 21 Mar 2003 20:10:27 -0500 Received: from ravms by mail.xythos.com with mail-ok (Exim 3.36 #3) id 18wXbn-0008Oc-00; Sat, 22 Mar 2003 01:15:39 +0000 Received: from ip-216-36-77-241.dsl.sjc.megapath.net ([216.36.77.241] helo=xythos.com) by mail.xythos.com with asmtp (Exim 3.36 #3) id 18wXbn-0008OE-00; Sat, 22 Mar 2003 01:15:39 +0000 Date: Fri, 21 Mar 2003 17:10:18 -0800 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: "WebDAV" To: "Julian Reschke" From: Brian Korver In-Reply-To: Message-Id: <0C1E5E0E-5C03-11D7-894D-000393751598@xythos.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) Old-X-Envelope-To: w3c-dist-auth@w3.org, julian.reschke@gmx.de Subject: Re: I-D ACTION:draft-ietf-webdav-quota-01.txt X-Archived-At: http://www.w3.org/mid/0C1E5E0E-5C03-11D7-894D-000393751598@xythos.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7527 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit On Thursday, March 20, 2003, at 12:38 AM, Julian Reschke wrote: > Right, RFC3010 doesn't define the term, but it uses the concept. I just > think that it makes sense to give the concept a name: > > The value in bytes which represent the amount of disc space > used by this file or directory and possibly a number of other > similar files or directories, where the set of "similar" meets > at least the criterion that allocating space to any file or > directory in the set will reduce the "quota_avail_hard" of > every other file or directory in the set. > > Note that there may be a number of distinct but overlapping > sets of files or directories for which a quota_used value is > maintained. E.g. "all files with a given owner", "all files > with a given group owner". etc. > > The server is at liberty to choose any of those sets but > should > do so in a repeatable way. The rule may be configured per- > filesystem or may be "choose the set with the smallest quota". > > So basically, a "quota space" is the set of resources that share the > same > quota. I'm not sure how important I think defining "quota space" is, but I'd I'll add it since you think it would be helpful. > > For the record, i'm absolutely in favor to stick with the definitions > from > RFC3010. Why don't we just steal them verbatim, or just refer to 3010? They require minor tweaking, so I think it would be easier to steal them. > > IMHO, > > The value in bytes which represents the amount of additional > disk space that can be allocated to this file or directory > before the user may reasonably be warned. It is understood > that this space may be consumed by allocations to other files > or directories though there is a rule as to which other files > or directories. > > is very clear (we may have to map some terms though). If we stick with > this > language it's also much clearer why the distinction between plain > resources > and collections (and other types) really doesn't make sense at all -- > I'd > prfer the spec not to say anything about that. I agree that it's clear. The problem is that we defined things a little differently from NFS: DAV:quota-limit-bytes is different from NFS's quota_avail_hard, in that DAV:quota-limit-bytes - DAV:quota-used-bytes = quota_avail_hard We talked about doing this because we wanted the "amount free" that is displayed to the user to be what the user expects rather than a value computed by the client, which might not end up as a round number. I think the definition of DAV:quota-limit-bytes (and DAV:quota-assigned-bytes) could be clearer, so any wordsmithing suggestions would be appreciated. > > That didn't come through. Now it reads: > > The value of this property will usually be protected, although a > user with sufficient privileges may be permitted to change the > value. The property is useful even if it is protected. A 403 > Forbidden response is RECOMMENDED for attempts to write a protected > property. > > That sounds as if *usually* the property is read-only. That makes sense. For instance, most users shouldn't be able to change my quota, as I shouldn't be able to change theirs. > > BTW: why do we need an additional property for that? There are several instances where there are 2 numbers for quota. For instance, the quota system given in the example. In the example, the assigned quota for B is 10,000,000 bytes, while the limit is 1,000,000. I'll try to make that clearer in the example. -brian briank@xythos.com From w3c-dist-auth-request@w3.org Mon Mar 24 03:26:49 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA07373 for ; Mon, 24 Mar 2003 03:26:48 -0500 (EST) Received: from frink.w3.org (localhost [127.0.0.1]) by frink.w3.org (8.12.8/8.12.8) with ESMTP id h2O8SL4g006232; Mon, 24 Mar 2003 03:28:21 -0500 (EST) Received: (from lists@localhost) by frink.w3.org (8.12.8/8.12.8/Submit) id h2O8S3gn006225; Mon, 24 Mar 2003 03:28:03 -0500 (EST) Resent-Date: Mon, 24 Mar 2003 03:28:03 -0500 (EST) Resent-Message-Id: <200303240828.h2O8S3gn006225@frink.w3.org> Received: from tux.w3.org (IDENT:root@tux [18.29.0.27]) by frink.w3.org (8.12.8/8.12.8) with ESMTP id h2O8Rt4g006169 for ; Mon, 24 Mar 2003 03:27:55 -0500 (EST) Received: from greenbytes.de (mail.greenbytes.de [217.5.201.10] (may be forged)) by tux.w3.org (8.12.8/8.12.8) with SMTP id h2O8RsrB025480 for ; Mon, 24 Mar 2003 03:27:55 -0500 Received: from greenbytes.de ([192.168.1.23]) by greenbytes.de ([217.5.201.11]) with SMTP (MDaemon.PRO.v6.7.0.R) for ; Mon, 24 Mar 2003 09:27:50 +0100 Date: Mon, 24 Mar 2003 09:27:51 +0100 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: "Julian Reschke" , "WebDAV" To: Brian Korver From: Stefan Eissing In-Reply-To: <0C1E5E0E-5C03-11D7-894D-000393751598@xythos.com> Message-Id: <80EC6FF2-5DD2-11D7-835C-00039384827E@greenbytes.de> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) X-MDRemoteIP: 192.168.1.23 X-Return-Path: stefan.eissing@greenbytes.de X-MDaemon-Deliver-To: w3c-dist-auth@w3.org Subject: Re: I-D ACTION:draft-ietf-webdav-quota-01.txt X-Archived-At: http://www.w3.org/mid/80EC6FF2-5DD2-11D7-835C-00039384827E@greenbytes.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7528 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit Am Samstag, 22.03.03, um 02:10 Uhr (Europe/Berlin) schrieb Brian Korver: > > I agree that it's clear. The problem is that we defined things a > little > differently from NFS: DAV:quota-limit-bytes is different from > NFS's quota_avail_hard, in that > > DAV:quota-limit-bytes - DAV:quota-used-bytes = quota_avail_hard > > We talked about doing this because we wanted the "amount free" that > is displayed to the user to be what the user expects rather than > a value computed by the client, which might not end up as a round > number. I wonder if this equation holds true when "disk space" gets low. Say you have 10 GB of space on the server, you have 10 users and each user has a quota of 1GB. You add an 11th user also with 1GB quota (or an administrator puts a 1GB sized resource). Now, when the free space on the server goes below 1GB, the above equation will not tell you how large a file you can PUT. That problem seems to be avoided in 3010 with "quota_avail_*". //Stefan From w3c-dist-auth-request@w3.org Mon Mar 24 08:05:07 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA15358 for ; Mon, 24 Mar 2003 08:05:06 -0500 (EST) Received: from frink.w3.org (localhost [127.0.0.1]) by frink.w3.org (8.12.8/8.12.8) with ESMTP id h2OD6m4g026463; Mon, 24 Mar 2003 08:06:48 -0500 (EST) Received: (from lists@localhost) by frink.w3.org (8.12.8/8.12.8/Submit) id h2OD6SRB026308; Mon, 24 Mar 2003 08:06:28 -0500 (EST) Resent-Date: Mon, 24 Mar 2003 08:06:28 -0500 (EST) Resent-Message-Id: <200303241306.h2OD6SRB026308@frink.w3.org> Received: from tux.w3.org (IDENT:root@tux [18.29.0.27]) by frink.w3.org (8.12.8/8.12.8) with ESMTP id h2OD6Q4g026243 for ; Mon, 24 Mar 2003 08:06:26 -0500 (EST) Received: from mail.gmx.net (mail.gmx.net [213.165.65.60]) by tux.w3.org (8.12.8/8.12.8) with SMTP id h2OD6PrB026024 for ; Mon, 24 Mar 2003 08:06:25 -0500 Received: (qmail 3385 invoked by uid 0); 24 Mar 2003 13:06:15 -0000 Received: from mail.greenbytes.de (HELO lisa) (217.5.201.10) by mail.gmx.net (mp003-rz3) with SMTP; 24 Mar 2003 13:06:15 -0000 From: "Julian Reschke" To: "Brian Korver" , "WebDAV" Date: Mon, 24 Mar 2003 14:06:14 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal In-Reply-To: <0C1E5E0E-5C03-11D7-894D-000393751598@xythos.com> Subject: RE: I-D ACTION:draft-ietf-webdav-quota-01.txt X-Archived-At: http://www.w3.org/mid/JIEGINCHMLABHJBIGKBCEEKPGNAA.julian.reschke@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7529 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Brian Korver > Sent: Saturday, March 22, 2003 2:10 AM > To: Julian Reschke > Cc: WebDAV > Subject: Re: I-D ACTION:draft-ietf-webdav-quota-01.txt > > ... > > I'm not sure how important I think defining "quota space" is, but > I'd I'll add it since you think it would be helpful. I think it's useful if and only if we use it consistently to define the quota properties (see below). > .. > > > IMHO, > > > > The value in bytes which represents the amount of additional > > disk space that can be allocated to this file or directory > > before the user may reasonably be warned. It is understood > > that this space may be consumed by allocations to other files > > or directories though there is a rule as to which other files > > or directories. > > > > is very clear (we may have to map some terms though). If we stick with this > > language it's also much clearer why the distinction between plain resources > > and collections (and other types) really doesn't make sense at all -- I'd > > prfer the spec not to say anything about that. > > I agree that it's clear. The problem is that we defined things a little > differently from NFS: DAV:quota-limit-bytes is different from > NFS's quota_avail_hard, in that > > DAV:quota-limit-bytes - DAV:quota-used-bytes = quota_avail_hard > > We talked about doing this because we wanted the "amount free" that > is displayed to the user to be what the user expects rather than > a value computed by the client, which might not end up as a round > number. I think now we're confusing marshalling and implementations. I agree that it would be confusing when the "available" value keeps changing due to rounding issues. However, that's an effect of the underlying implementation, not how the numbers are sent to the client. If a server really decides to *compute* the total (I really can't imagine why it would), changing the marshalling format will not change anything. > ... > > > That didn't come through. Now it reads: > > > > The value of this property will usually be protected, although a > > user with sufficient privileges may be permitted to change the > > value. The property is useful even if it is protected. A 403 > > Forbidden response is RECOMMENDED for attempts to write a protected > > property. > > > > That sounds as if *usually* the property is read-only. > > That makes sense. For instance, most users shouldn't be able to > change my quota, as I shouldn't be able to change theirs. Why would a server allow a user to change his own quota??? That really seems to be an adminstrator-only feature. > > BTW: why do we need an additional property for that? > > There are several instances where there are 2 numbers for > quota. For instance, the quota system given in the example. > In the example, the assigned quota for B is 10,000,000 bytes, > while the limit is 1,000,000. I'll try to make that clearer > in the example. If this is the case, there's still a major problem with the quota system you describe. Before we continue this thread, let's talk about whether the spec should actually describe server behaviour at all. As far as I remember the discussion in January, all that client implementors want is the ability to describe a ratio of used / available, and possibly the ability to discover the amount of storage a single resource takes. If we only need this, the spec can be much shorter. On the other hand, if the spec is going to define what quotas are and how they behave, it needs to be compatible with more than a single implementation, and you'll have to define why and how these two different value may vary. Right now, I honestly don't understand it. Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Mon Mar 24 08:13:48 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA15569 for ; Mon, 24 Mar 2003 08:13:48 -0500 (EST) Received: from frink.w3.org (localhost [127.0.0.1]) by frink.w3.org (8.12.8/8.12.8) with ESMTP id h2ODFa4g000459; Mon, 24 Mar 2003 08:15:36 -0500 (EST) Received: (from lists@localhost) by frink.w3.org (8.12.8/8.12.8/Submit) id h2ODFZlG000448; Mon, 24 Mar 2003 08:15:35 -0500 (EST) Resent-Date: Mon, 24 Mar 2003 08:15:35 -0500 (EST) Resent-Message-Id: <200303241315.h2ODFZlG000448@frink.w3.org> Received: from tux.w3.org (IDENT:root@tux [18.29.0.27]) by frink.w3.org (8.12.8/8.12.8) with ESMTP id h2ODFW4g000413 for ; Mon, 24 Mar 2003 08:15:32 -0500 (EST) Received: from mail.gmx.net (mail.gmx.net [213.165.65.60]) by tux.w3.org (8.12.8/8.12.8) with SMTP id h2ODFWrB028964 for ; Mon, 24 Mar 2003 08:15:32 -0500 Received: (qmail 14510 invoked by uid 0); 24 Mar 2003 13:15:26 -0000 Received: from mail.greenbytes.de (HELO lisa) (217.5.201.10) by mail.gmx.net (mp007-rz3) with SMTP; 24 Mar 2003 13:15:26 -0000 From: "Julian Reschke" To: "WebDAV" Date: Mon, 24 Mar 2003 14:15:25 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal In-Reply-To: <0C1E5E0E-5C03-11D7-894D-000393751598@xythos.com> Subject: RE: I-D ACTION:draft-ietf-webdav-quota-01.txt X-Archived-At: http://www.w3.org/mid/JIEGINCHMLABHJBIGKBCEELAGNAA.julian.reschke@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7530 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit Brian, here are two more issues I have: 1) During the discussion, I've seen soft limits (quotas) and hard limits (disk space) used in the same context. I'm really not sure that it is a good idea to use the same mechanism for both. 2) Related to that: I'm not sure that using 507 for failures due to quota restrictions is a good idea. 5xx indicates a server error. In this case, the problem is not causes by the server, but by the client (trying to take up more space than allowed), so a 4xx with a new precondition code seems to be more appropriate. Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Mon Mar 24 22:13:56 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA15749 for ; Mon, 24 Mar 2003 22:13:55 -0500 (EST) Received: from frink.w3.org (localhost [127.0.0.1]) by frink.w3.org (8.12.8/8.12.8) with ESMTP id h2P3Fj4g027578; Mon, 24 Mar 2003 22:15:45 -0500 (EST) Received: (from lists@localhost) by frink.w3.org (8.12.8/8.12.8/Submit) id h2P3FU7Q027484; Mon, 24 Mar 2003 22:15:30 -0500 (EST) Resent-Date: Mon, 24 Mar 2003 22:15:30 -0500 (EST) Resent-Message-Id: <200303250315.h2P3FU7Q027484@frink.w3.org> Received: from tux.w3.org (IDENT:root@tux [18.29.0.27]) by frink.w3.org (8.12.8/8.12.8) with ESMTP id h2P3FR4g027452 for ; Mon, 24 Mar 2003 22:15:27 -0500 (EST) Received: from matrixmail.matrixone.net (mail.matrix-one.com [4.17.165.4]) by tux.w3.org (8.12.8/8.12.8) with ESMTP id h2P3FRrB032249 for ; Mon, 24 Mar 2003 22:15:27 -0500 Received: from msx2am.matrixone.net (msx2am.matrixone.net [10.1.3.26]) by matrixmail.matrixone.net (8.12.8/8.12.8) with ESMTP id h2P3FJk2018331; Mon, 24 Mar 2003 22:15:20 -0500 (EST) Received: by msx2am.matrixone.net with Internet Mail Service (5.5.2653.19) id ; Mon, 24 Mar 2003 22:15:19 -0500 Message-ID: <9150DCE0CCB4D411A7DB00508BB0DBF20520856D@msx1am.matrixone.net> From: "Dyer, Kevin" To: "'Julian Reschke'" , WebDAV Date: Mon, 24 Mar 2003 22:15:19 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2F27C.C3E90510" Subject: RE: I-D ACTION:draft-ietf-webdav-quota-01.txt X-Archived-At: http://www.w3.org/mid/9150DCE0CCB4D411A7DB00508BB0DBF20520856D@msx1am.matrixone.net Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7531 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C2F27C.C3E90510 Content-Type: text/plain; charset="iso-8859-1" Julian, I agree with 1) on 2) are you talking about quotas? If so you are correct but disk space is still 507, IMHO. Kevin >-----Original Message----- >From: Julian Reschke [mailto:julian.reschke@gmx.de] >Sent: Monday, March 24, 2003 8:15 AM >To: WebDAV >Subject: RE: I-D ACTION:draft-ietf-webdav-quota-01.txt > > > >Brian, > >here are two more issues I have: > >1) During the discussion, I've seen soft limits (quotas) and >hard limits >(disk space) used in the same context. I'm really not sure >that it is a good >idea to use the same mechanism for both. > >2) Related to that: I'm not sure that using 507 for failures >due to quota >restrictions is a good idea. 5xx indicates a server error. >In this case, the >problem is not causes by the server, but by the client >(trying to take up >more space than allowed), so a 4xx with a new precondition >code seems to be >more appropriate. > >Julian > >-- >bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 > ------_=_NextPart_001_01C2F27C.C3E90510 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: I-D ACTION:draft-ietf-webdav-quota-01.txt

Julian,

I agree with 1) on 2) are you talking about quotas? = If so you are correct but disk space is still 507, IMHO.

        Kevin

  >-----Original Message-----
  >From: Julian Reschke [mailto:julian.reschke@gmx.de]<= /FONT>
  >Sent: Monday, March 24, 2003 8:15 = AM
  >To: WebDAV
  >Subject: RE: I-D = ACTION:draft-ietf-webdav-quota-01.txt
  >
  >
  >
  >Brian,
  >
  >here are two more issues I have:
  >
  >1) During the discussion, I've seen soft = limits (quotas) and
  >hard limits
  >(disk space) used in the same context. = I'm really not sure
  >that it is a good
  >idea to use the same mechanism for = both.
  >
  >2) Related to that: I'm not sure that = using 507 for failures
  >due to quota
  >restrictions is a good idea. 5xx = indicates a server error.
  >In this case, the
  >problem is not causes by the server, but = by the client
  >(trying to take up
  >more space than allowed), so a 4xx with a = new precondition
  >code seems to be
  >more appropriate.
  >
  >Julian
  >
  >--
  ><green/>bytes GmbH -- http://www.greenbytes.de -- = tel:+492512807760
  >

------_=_NextPart_001_01C2F27C.C3E90510-- From w3c-dist-auth-request@w3.org Mon Mar 24 22:52:06 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA16679 for ; Mon, 24 Mar 2003 22:52:06 -0500 (EST) Received: from frink.w3.org (localhost [127.0.0.1]) by frink.w3.org (8.12.8/8.12.8) with ESMTP id h2P3s04g001715; Mon, 24 Mar 2003 22:54:00 -0500 (EST) Received: (from lists@localhost) by frink.w3.org (8.12.8/8.12.8/Submit) id h2P3rwX7001697; Mon, 24 Mar 2003 22:53:58 -0500 (EST) Resent-Date: Mon, 24 Mar 2003 22:53:58 -0500 (EST) Resent-Message-Id: <200303250353.h2P3rwX7001697@frink.w3.org> Received: from tux.w3.org (IDENT:root@tux [18.29.0.27]) by frink.w3.org (8.12.8/8.12.8) with ESMTP id h2P3ru4g001661 for ; Mon, 24 Mar 2003 22:53:56 -0500 (EST) Received: from sus-ma1it31.rational.com (sus-ma1it31.rational.com [130.213.73.33]) by tux.w3.org (8.12.8/8.12.8) with ESMTP id h2P3rtrB005606 for ; Mon, 24 Mar 2003 22:53:55 -0500 Received: from sus-ma1it00.rational.com ([10.64.1.25]) by 10.64.1.33 with InterScan Messaging Security Suite; Mon, 24 Mar 2003 22:37:01 -0500 Received: by sus-ma1it00.rational.com with Internet Mail Service (5.5.2656.59) id ; Mon, 24 Mar 2003 22:53:49 -0500 Message-ID: From: "Clemm, Geoff" To: WebDAV Date: Mon, 24 Mar 2003 22:53:42 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain; charset="iso-8859-1" Subject: RE: I-D ACTION:draft-ietf-webdav-quota-01.txt X-Archived-At: http://www.w3.org/mid/E4F2D33B98DF7E4880884B9F0E6FDEE2023C9B80@SUS-MA1IT01 Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7532 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Just for interests sake, is there any client that acts significantly differently if it were to receive a 4xx response instead of a 5xx response? If not, this question is merely an aesthetic quibble (:-). But the advantage of an aesthetic quibble is that everyone can join in without risk of being proven wrong (:-), so my 2 cents say that 4xx is more consistent with the currently defined 4xx and 5xx messages. In particular, 413 (Request Entity Too Large) seems quite close to this condition, while there is no 5xx condition that is nearly as close. Cheers, Geoff -----Original Message----- From: Dyer, Kevin [mailto:kevin.dyer@matrixone.com] Julian, I agree with 1) on 2) are you talking about quotas? If so you are correct but disk space is still 507, IMHO. Kevin >-----Original Message----- >From: Julian Reschke [mailto:julian.reschke@gmx.de] >Sent: Monday, March 24, 2003 8:15 AM >To: WebDAV >Subject: RE: I-D ACTION:draft-ietf-webdav-quota-01.txt > > > >Brian, > >here are two more issues I have: > >1) During the discussion, I've seen soft limits (quotas) and >hard limits >(disk space) used in the same context. I'm really not sure >that it is a good >idea to use the same mechanism for both. > >2) Related to that: I'm not sure that using 507 for failures >due to quota >restrictions is a good idea. 5xx indicates a server error. >In this case, the >problem is not causes by the server, but by the client >(trying to take up >more space than allowed), so a 4xx with a new precondition >code seems to be >more appropriate. > >Julian > >-- >bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 > From w3c-dist-auth-request@w3.org Tue Mar 25 08:14:20 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA08839 for ; Tue, 25 Mar 2003 08:14:20 -0500 (EST) Received: from frink.w3.org (localhost [127.0.0.1]) by frink.w3.org (8.12.8/8.12.8) with ESMTP id h2PDG44g024958; Tue, 25 Mar 2003 08:16:04 -0500 (EST) Received: (from lists@localhost) by frink.w3.org (8.12.8/8.12.8/Submit) id h2PDFrlY024940; Tue, 25 Mar 2003 08:15:53 -0500 (EST) Resent-Date: Tue, 25 Mar 2003 08:15:53 -0500 (EST) Resent-Message-Id: <200303251315.h2PDFrlY024940@frink.w3.org> Received: from tux.w3.org (IDENT:root@tux [18.29.0.27]) by frink.w3.org (8.12.8/8.12.8) with ESMTP id h2PDFk4g024908 for ; Tue, 25 Mar 2003 08:15:46 -0500 (EST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by tux.w3.org (8.12.8/8.12.8) with ESMTP id h2PDFerB021559 for ; Tue, 25 Mar 2003 08:15:41 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA08726; Tue, 25 Mar 2003 08:13:17 -0500 (EST) Message-Id: <200303251313.IAA08726@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: w3c-dist-auth@w3.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Tue, 25 Mar 2003 08:13:17 -0500 Subject: I-D ACTION:draft-ietf-webdav-ordering-protocol-07.txt X-Archived-At: http://www.w3.org/mid/200303251313.IAA08726@ietf.org Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7533 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the WWW Distributed Authoring and Versioning Working Group of the IETF. Title : WebDAV Ordered Collections Protocol Author(s) : J. Slein, E. Whitehead et al. Filename : draft-ietf-webdav-ordering-protocol-07.txt Pages : 43 Date : 2003-3-24 This specification extends the WebDAV Distributed Authoring Protocol to support server-side ordering of collection members. Of particular interest are orderings that are not based on property values, and so cannot be achieved using a search protocol's ordering option and cannot be maintained automatically by the server. Protocol elements are defined to let clients specify the position in the ordering of each collection member, as well as the semantics governing the ordering. Distribution of this document is unlimited. Please send comments to the Distributed Authoring and Versioning (WebDAV) working group at w3c-dist-auth@w3.org, which may be joined by sending a message with subject 'subscribe' to w3c-dist-auth-request@w3.org. Discussions of the WEBDAV working group are archived at URL: http://lists.w3.org/Archives/Public/w3c-dist-auth/. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-webdav-ordering-protocol-07.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-ietf-webdav-ordering-protocol-07.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-ietf-webdav-ordering-protocol-07.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: <2003-3-24141510.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-webdav-ordering-protocol-07.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-webdav-ordering-protocol-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-3-24141510.I-D@ietf.org> --OtherAccess-- --NextPart-- From w3c-dist-auth-request@w3.org Tue Mar 25 10:45:26 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18892 for ; Tue, 25 Mar 2003 10:45:26 -0500 (EST) Received: from frink.w3.org (localhost [127.0.0.1]) by frink.w3.org (8.12.8/8.12.8) with ESMTP id h2PFku4g016171; Tue, 25 Mar 2003 10:46:56 -0500 (EST) Received: (from lists@localhost) by frink.w3.org (8.12.8/8.12.8/Submit) id h2PFkNQo016127; Tue, 25 Mar 2003 10:46:23 -0500 (EST) Resent-Date: Tue, 25 Mar 2003 10:46:23 -0500 (EST) Resent-Message-Id: <200303251546.h2PFkNQo016127@frink.w3.org> Received: from tux.w3.org (IDENT:root@tux [18.29.0.27]) by frink.w3.org (8.12.8/8.12.8) with ESMTP id h2PFkK4g016079 for ; Tue, 25 Mar 2003 10:46:20 -0500 (EST) Received: from mail-out2.apple.com (mail-out2.apple.com [17.254.0.51]) by tux.w3.org (8.12.8/8.12.8) with ESMTP id h2PFkJrB023657 for ; Tue, 25 Mar 2003 10:46:20 -0500 Received: from mailgate2.apple.com (A17-129-100-225.apple.com [17.129.100.225]) by mail-out2.apple.com (8.12.8/8.12.8) with ESMTP id h2PFkIsJ027849 for ; Tue, 25 Mar 2003 07:46:18 -0800 (PST) Received: from scv2.apple.com (scv2.apple.com) by mailgate2.apple.com (Content Technologies SMTPRS 4.2.1) with ESMTP id for ; Tue, 25 Mar 2003 07:46:18 -0800 Received: from apple.com (luthji.apple.com [17.202.43.76]) by scv2.apple.com (8.11.3/8.11.3) with ESMTP id h2PFkIH17065 for ; Tue, 25 Mar 2003 07:46:18 -0800 (PST) Date: Tue, 25 Mar 2003 07:46:05 -0800 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) From: Jim Luther To: WebDAV Content-Transfer-Encoding: 7bit In-Reply-To: Message-Id: X-Mailer: Apple Mail (2.551) Subject: Re: I-D ACTION:draft-ietf-webdav-quota-01.txt X-Archived-At: http://www.w3.org/mid/E3D14619-5ED8-11D7-96DF-0003934B6A22@apple.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7534 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit On Monday, March 24, 2003, at 07:53 PM, Clemm, Geoff wrote: > Just for interests sake, is there any client that acts significantly > differently if it were to receive a 4xx response instead of a 5xx > response? If not, this question is merely an aesthetic quibble (:-). Yes there is a client that handles those responses quite differently. The Mac OS X WebDAV file system client translates 507 to ENOSPC (No space left on device) which is interpreted by most Macintosh applications to mean the device is full; the WebDAV file system translates 413 as a generic 4xx response to EINVAL (Invalid argument) which is interpreted by most Macintosh applications to mean "something wasn't right - who knows what?" The Mac OS X WebDAV file system client is one of the few clients actually using quotas today and has been for over 1-1/2 years now. Jim Luther Apple Computer, Inc. From w3c-dist-auth-request@w3.org Tue Mar 25 11:08:34 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19599 for ; Tue, 25 Mar 2003 11:08:33 -0500 (EST) Received: from frink.w3.org (localhost [127.0.0.1]) by frink.w3.org (8.12.8/8.12.8) with ESMTP id h2PG5K4g021901; Tue, 25 Mar 2003 11:05:20 -0500 (EST) Received: (from lists@localhost) by frink.w3.org (8.12.8/8.12.8/Submit) id h2PG5J4B021883; Tue, 25 Mar 2003 11:05:19 -0500 (EST) Resent-Date: Tue, 25 Mar 2003 11:05:19 -0500 (EST) Resent-Message-Id: <200303251605.h2PG5J4B021883@frink.w3.org> Received: from tux.w3.org (IDENT:root@tux [18.29.0.27]) by frink.w3.org (8.12.8/8.12.8) with ESMTP id h2PG5G4g021846 for ; Tue, 25 Mar 2003 11:05:16 -0500 (EST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by tux.w3.org (8.12.8/8.12.8) with SMTP id h2PG5FrB001156 for ; Tue, 25 Mar 2003 11:05:16 -0500 Received: (qmail 18836 invoked by uid 65534); 25 Mar 2003 16:05:06 -0000 Received: from unknown (HELO lisa) (217.5.201.10) by mail.gmx.net (mp021-rz3) with SMTP; 25 Mar 2003 17:05:06 +0100 From: "Julian Reschke" To: "Jim Luther" , "WebDAV" Date: Tue, 25 Mar 2003 17:05:06 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 In-Reply-To: Importance: Normal Subject: RE: I-D ACTION:draft-ietf-webdav-quota-01.txt X-Archived-At: http://www.w3.org/mid/JIEGINCHMLABHJBIGKBCCENPGNAA.julian.reschke@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7535 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Jim Luther > Sent: Tuesday, March 25, 2003 4:46 PM > To: WebDAV > Subject: Re: I-D ACTION:draft-ietf-webdav-quota-01.txt > > > > On Monday, March 24, 2003, at 07:53 PM, Clemm, Geoff wrote: > > > Just for interests sake, is there any client that acts significantly > > differently if it were to receive a 4xx response instead of a 5xx > > response? If not, this question is merely an aesthetic quibble (:-). > > Yes there is a client that handles those responses quite differently. > > The Mac OS X WebDAV file system client translates 507 to ENOSPC (No > space left on device) which is interpreted by most Macintosh > applications to mean the device is full; the WebDAV file system > translates 413 as a generic 4xx response to EINVAL (Invalid argument) > which is interpreted by most Macintosh applications to mean "something > wasn't right - who knows what?" > > The Mac OS X WebDAV file system client is one of the few clients > actually using quotas today and has been for over 1-1/2 years now. Well. Quota exceeded isn't the same thing as disk space exceeded. Wouldn't it be more useful if the protocol would allow you to distinguish between ENOSPC and EDQUOT? Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Tue Mar 25 11:13:20 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19793 for ; Tue, 25 Mar 2003 11:13:20 -0500 (EST) Received: from frink.w3.org (localhost [127.0.0.1]) by frink.w3.org (8.12.8/8.12.8) with ESMTP id h2PGFC4g024589; Tue, 25 Mar 2003 11:15:12 -0500 (EST) Received: (from lists@localhost) by frink.w3.org (8.12.8/8.12.8/Submit) id h2PGFBkR024554; Tue, 25 Mar 2003 11:15:11 -0500 (EST) Resent-Date: Tue, 25 Mar 2003 11:15:11 -0500 (EST) Resent-Message-Id: <200303251615.h2PGFBkR024554@frink.w3.org> Received: from tux.w3.org (IDENT:root@tux [18.29.0.27]) by frink.w3.org (8.12.8/8.12.8) with ESMTP id h2PGF94g024519 for ; Tue, 25 Mar 2003 11:15:09 -0500 (EST) Received: from mail-out1.apple.com (mail-out1.apple.com [17.254.0.52]) by tux.w3.org (8.12.8/8.12.8) with ESMTP id h2PGF8rB006557 for ; Tue, 25 Mar 2003 11:15:08 -0500 Received: from mailgate2.apple.com (A17-129-100-225.apple.com [17.129.100.225]) by mail-out1.apple.com (8.12.8/8.12.8) with ESMTP id h2PGF8Or028024 for ; Tue, 25 Mar 2003 08:15:08 -0800 (PST) Received: from scv2.apple.com (scv2.apple.com) by mailgate2.apple.com (Content Technologies SMTPRS 4.2.1) with ESMTP id for ; Tue, 25 Mar 2003 08:15:08 -0800 Received: from apple.com (luthji.apple.com [17.202.43.76]) by scv2.apple.com (8.11.3/8.11.3) with ESMTP id h2PGF7H29102 for ; Tue, 25 Mar 2003 08:15:07 -0800 (PST) Date: Tue, 25 Mar 2003 08:14:55 -0800 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) From: Jim Luther To: WebDAV Content-Transfer-Encoding: 7bit In-Reply-To: Message-Id: X-Mailer: Apple Mail (2.551) Subject: Re: I-D ACTION:draft-ietf-webdav-quota-01.txt X-Archived-At: http://www.w3.org/mid/EAB93322-5EDC-11D7-96DF-0003934B6A22@apple.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7536 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit On Tuesday, March 25, 2003, at 08:05 AM, Julian Reschke wrote: >> From: w3c-dist-auth-request@w3.org >> [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Jim Luther >> Sent: Tuesday, March 25, 2003 4:46 PM >> To: WebDAV >> Subject: Re: I-D ACTION:draft-ietf-webdav-quota-01.txt >> >> >> On Monday, March 24, 2003, at 07:53 PM, Clemm, Geoff wrote: >> >>> Just for interests sake, is there any client that acts significantly >>> differently if it were to receive a 4xx response instead of a 5xx >>> response? If not, this question is merely an aesthetic quibble (:-). >> >> Yes there is a client that handles those responses quite differently. >> >> The Mac OS X WebDAV file system client translates 507 to ENOSPC (No >> space left on device) which is interpreted by most Macintosh >> applications to mean the device is full; the WebDAV file system >> translates 413 as a generic 4xx response to EINVAL (Invalid argument) >> which is interpreted by most Macintosh applications to mean "something >> wasn't right - who knows what?" >> >> The Mac OS X WebDAV file system client is one of the few clients >> actually using quotas today and has been for over 1-1/2 years now. > > Well. > > Quota exceeded isn't the same thing as disk space exceeded. Wouldn't > it be > more useful if the protocol would allow you to distinguish between > ENOSPC > and EDQUOT? > > Julian I was just answering the question "is there any client that acts significantly differently if it were to receive a 4xx response instead of a 5xx response?" The short answer is "yes." However, the quota properties our client uses today have different property names than the properties in draft-ietf-webdav-quota-01.txt, so when things are nailed down, I'll have to change our code to use the new property names. When I do that, I can change the way status codes are handled if needed. - Jim From w3c-dist-auth-request@w3.org Tue Mar 25 11:34:22 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20691 for ; Tue, 25 Mar 2003 11:34:22 -0500 (EST) Received: from frink.w3.org (localhost [127.0.0.1]) by frink.w3.org (8.12.8/8.12.8) with ESMTP id h2PGaG4g029879; Tue, 25 Mar 2003 11:36:16 -0500 (EST) Received: (from lists@localhost) by frink.w3.org (8.12.8/8.12.8/Submit) id h2PGaBQE029866; Tue, 25 Mar 2003 11:36:11 -0500 (EST) Resent-Date: Tue, 25 Mar 2003 11:36:11 -0500 (EST) Resent-Message-Id: <200303251636.h2PGaBQE029866@frink.w3.org> Received: from tux.w3.org (IDENT:root@tux [18.29.0.27]) by frink.w3.org (8.12.8/8.12.8) with ESMTP id h2PGa84g029830 for ; Tue, 25 Mar 2003 11:36:08 -0500 (EST) Received: from sus-ma1it31.rational.com (sus-ma1it31.rational.com [130.213.73.33]) by tux.w3.org (8.12.8/8.12.8) with ESMTP id h2PGa8rB016605 for ; Tue, 25 Mar 2003 11:36:08 -0500 Received: from sus-ma1it00.rational.com ([10.64.1.25]) by 10.64.1.33 with InterScan Messaging Security Suite; Tue, 25 Mar 2003 11:19:12 -0500 Received: by sus-ma1it00.rational.com with Internet Mail Service (5.5.2656.59) id ; Tue, 25 Mar 2003 11:36:02 -0500 Message-ID: From: "Clemm, Geoff" To: WebDAV Date: Tue, 25 Mar 2003 11:35:46 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain Subject: RE: I-D ACTION:draft-ietf-webdav-quota-01.txt X-Archived-At: http://www.w3.org/mid/E4F2D33B98DF7E4880884B9F0E6FDEE20260D976@SUS-MA1IT01 Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7537 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: That wasn't the question I meant to ask. Clearly there are clients that handle a specific code (such as 507) differently from another specific code (such as 413). But in those cases it doesn't matter whether the standard defined that specific code to be in the 4xx or 5xx range. What I was asking was whether there was a client that generically handled 4xx codes (i.e. a 4xx code that it had no special handling for) in a significantly different way than it handles a 5xx code (i.e. a 5xx code that it had no special handling for). I.e., when we are deciding whether to put a specific code in the 4xx or 5xx range, does it matter which one we pick? Cheers, Geoff -----Original Message----- From: Jim Luther [mailto:luther.j@apple.com] Sent: Tuesday, March 25, 2003 10:46 AM To: WebDAV Subject: Re: I-D ACTION:draft-ietf-webdav-quota-01.txt On Monday, March 24, 2003, at 07:53 PM, Clemm, Geoff wrote: > Just for interests sake, is there any client that acts significantly > differently if it were to receive a 4xx response instead of a 5xx > response? If not, this question is merely an aesthetic quibble (:-). Yes there is a client that handles those responses quite differently. The Mac OS X WebDAV file system client translates 507 to ENOSPC (No space left on device) which is interpreted by most Macintosh applications to mean the device is full; the WebDAV file system translates 413 as a generic 4xx response to EINVAL (Invalid argument) which is interpreted by most Macintosh applications to mean "something wasn't right - who knows what?" The Mac OS X WebDAV file system client is one of the few clients actually using quotas today and has been for over 1-1/2 years now. Jim Luther Apple Computer, Inc. From w3c-dist-auth-request@w3.org Tue Mar 25 12:18:28 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22025 for ; Tue, 25 Mar 2003 12:18:28 -0500 (EST) Received: from frink.w3.org (localhost [127.0.0.1]) by frink.w3.org (8.12.8/8.12.8) with ESMTP id h2PHKN4g008067; Tue, 25 Mar 2003 12:20:23 -0500 (EST) Received: (from lists@localhost) by frink.w3.org (8.12.8/8.12.8/Submit) id h2PHKKsB008055; Tue, 25 Mar 2003 12:20:20 -0500 (EST) Resent-Date: Tue, 25 Mar 2003 12:20:20 -0500 (EST) Resent-Message-Id: <200303251720.h2PHKKsB008055@frink.w3.org> Received: from tux.w3.org (IDENT:root@tux [18.29.0.27]) by frink.w3.org (8.12.8/8.12.8) with ESMTP id h2PHKG4g008018 for ; Tue, 25 Mar 2003 12:20:16 -0500 (EST) Received: from mail-out2.apple.com (mail-out2.apple.com [17.254.0.51]) by tux.w3.org (8.12.8/8.12.8) with ESMTP id h2PHKGrB032459 for ; Tue, 25 Mar 2003 12:20:16 -0500 Received: from mailgate2.apple.com (A17-129-100-225.apple.com [17.129.100.225]) by mail-out2.apple.com (8.12.8/8.12.8) with ESMTP id h2PHKFsJ026906 for ; Tue, 25 Mar 2003 09:20:15 -0800 (PST) Received: from scv2.apple.com (scv2.apple.com) by mailgate2.apple.com (Content Technologies SMTPRS 4.2.1) with ESMTP id for ; Tue, 25 Mar 2003 09:20:14 -0800 Received: from apple.com (luthji.apple.com [17.202.43.76]) by scv2.apple.com (8.11.3/8.11.3) with ESMTP id h2PHKDH01251 for ; Tue, 25 Mar 2003 09:20:13 -0800 (PST) Date: Tue, 25 Mar 2003 09:20:01 -0800 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) From: Jim Luther To: WebDAV Content-Transfer-Encoding: 7bit In-Reply-To: Message-Id: <03024B5B-5EE6-11D7-96DF-0003934B6A22@apple.com> X-Mailer: Apple Mail (2.551) Subject: Re: I-D ACTION:draft-ietf-webdav-quota-01.txt X-Archived-At: http://www.w3.org/mid/03024B5B-5EE6-11D7-96DF-0003934B6A22@apple.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7538 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit I'd refer back to rfc2616's language in sections 10.4 "Client Error 4xx" and 10.5 "Server Error 5xx". 4xx is for errors the server thinks can be resolved by changes in the client's request, and 5xx is for errors the server thinks are caused by something server-side. - Jim On Tuesday, March 25, 2003, at 08:35 AM, Clemm, Geoff wrote: > > That wasn't the question I meant to ask. > > Clearly there are clients that handle a specific code > (such as 507) differently from another specific code (such as 413). > But in those cases it doesn't matter whether the standard > defined that specific code to be in the 4xx or 5xx range. > > What I was asking was whether there was a client that > generically handled 4xx codes (i.e. a 4xx code that it had no > special handling for) in a significantly different way than > it handles a 5xx code (i.e. a 5xx code that it had no special > handling for). I.e., when we are deciding whether to put a > specific code in the 4xx or 5xx range, does it matter which > one we pick? > > Cheers, > Geoff > > -----Original Message----- > From: Jim Luther [mailto:luther.j@apple.com] > Sent: Tuesday, March 25, 2003 10:46 AM > To: WebDAV > Subject: Re: I-D ACTION:draft-ietf-webdav-quota-01.txt > > > > On Monday, March 24, 2003, at 07:53 PM, Clemm, Geoff wrote: > >> Just for interests sake, is there any client that acts significantly >> differently if it were to receive a 4xx response instead of a 5xx >> response? If not, this question is merely an aesthetic quibble (:-). > > Yes there is a client that handles those responses quite differently. > > The Mac OS X WebDAV file system client translates 507 to ENOSPC (No > space left on device) which is interpreted by most Macintosh > applications to mean the device is full; the WebDAV file system > translates 413 as a generic 4xx response to EINVAL (Invalid argument) > which is interpreted by most Macintosh applications to mean "something > wasn't right - who knows what?" > > The Mac OS X WebDAV file system client is one of the few clients > actually using quotas today and has been for over 1-1/2 years now. > > Jim Luther > Apple Computer, Inc. > From w3c-dist-auth-request@w3.org Tue Mar 25 15:49:54 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02866 for ; Tue, 25 Mar 2003 15:49:54 -0500 (EST) Received: from frink.w3.org (localhost [127.0.0.1]) by frink.w3.org (8.12.8/8.12.8) with ESMTP id h2PKpX4g004750; Tue, 25 Mar 2003 15:51:33 -0500 (EST) Received: (from lists@localhost) by frink.w3.org (8.12.8/8.12.8/Submit) id h2PKpBlQ004726; Tue, 25 Mar 2003 15:51:11 -0500 (EST) Resent-Date: Tue, 25 Mar 2003 15:51:11 -0500 (EST) Resent-Message-Id: <200303252051.h2PKpBlQ004726@frink.w3.org> Received: from tux.w3.org (IDENT:root@tux [18.29.0.27]) by frink.w3.org (8.12.8/8.12.8) with ESMTP id h2PKp94g004694 for ; Tue, 25 Mar 2003 15:51:09 -0500 (EST) Received: from sus-ma1it31.rational.com (sus-ma1it31.rational.com [130.213.73.33]) by tux.w3.org (8.12.8/8.12.8) with ESMTP id h2PKp8rB016876 for ; Tue, 25 Mar 2003 15:51:08 -0500 Received: from sus-ma1it00.rational.com ([10.64.1.25]) by 10.64.1.33 with InterScan Messaging Security Suite; Tue, 25 Mar 2003 15:34:12 -0500 Received: by sus-ma1it00.rational.com with Internet Mail Service (5.5.2656.59) id ; Tue, 25 Mar 2003 15:51:02 -0500 Message-ID: From: "Clemm, Geoff" To: WebDAV Date: Tue, 25 Mar 2003 15:50:55 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain Subject: RE: I-D ACTION:draft-ietf-webdav-quota-01.txt X-Archived-At: http://www.w3.org/mid/E4F2D33B98DF7E4880884B9F0E6FDEE25ED73C@SUS-MA1IT01 Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7539 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Any error can be "resolved" by changing the request to something else that doesn't fail, so that can't be the criterion used to distinguish a 4xx from a 5xx. All that sections 10.4 and 10.5 say are: "The 4xx class of status code is intended for cases in which the client seems to have erred." "Response status codes beginning with the digit "5" indicate cases in which the server is aware that it has erred or is incapable of performing the request." So requests that are malformed are clearly 4xx errors, but most other error cases are ambiguous, because looking at the error one way, the client erred in asking the server to do something it couldn't do (e.g. create a larger file than is permitted), but looking at them another way, the server erred by not (or by being incapable of) performing the specified request (e.g. create the large file). Cheers, Geoff -----Original Message----- From: Jim Luther [mailto:luther.j@apple.com] Sent: Tuesday, March 25, 2003 12:20 PM To: WebDAV Subject: Re: I-D ACTION:draft-ietf-webdav-quota-01.txt I'd refer back to rfc2616's language in sections 10.4 "Client Error 4xx" and 10.5 "Server Error 5xx". 4xx is for errors the server thinks can be resolved by changes in the client's request, and 5xx is for errors the server thinks are caused by something server-side. - Jim On Tuesday, March 25, 2003, at 08:35 AM, Clemm, Geoff wrote: > > That wasn't the question I meant to ask. > > Clearly there are clients that handle a specific code > (such as 507) differently from another specific code (such as 413). > But in those cases it doesn't matter whether the standard > defined that specific code to be in the 4xx or 5xx range. > > What I was asking was whether there was a client that > generically handled 4xx codes (i.e. a 4xx code that it had no > special handling for) in a significantly different way than > it handles a 5xx code (i.e. a 5xx code that it had no special > handling for). I.e., when we are deciding whether to put a > specific code in the 4xx or 5xx range, does it matter which > one we pick? > > Cheers, > Geoff > > -----Original Message----- > From: Jim Luther [mailto:luther.j@apple.com] > Sent: Tuesday, March 25, 2003 10:46 AM > To: WebDAV > Subject: Re: I-D ACTION:draft-ietf-webdav-quota-01.txt > > > > On Monday, March 24, 2003, at 07:53 PM, Clemm, Geoff wrote: > >> Just for interests sake, is there any client that acts significantly >> differently if it were to receive a 4xx response instead of a 5xx >> response? If not, this question is merely an aesthetic quibble (:-). > > Yes there is a client that handles those responses quite differently. > > The Mac OS X WebDAV file system client translates 507 to ENOSPC (No > space left on device) which is interpreted by most Macintosh > applications to mean the device is full; the WebDAV file system > translates 413 as a generic 4xx response to EINVAL (Invalid argument) > which is interpreted by most Macintosh applications to mean "something > wasn't right - who knows what?" > > The Mac OS X WebDAV file system client is one of the few clients > actually using quotas today and has been for over 1-1/2 years now. > > Jim Luther > Apple Computer, Inc. > From w3c-dist-auth-request@w3.org Tue Mar 25 15:59:01 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03277 for ; Tue, 25 Mar 2003 15:59:00 -0500 (EST) Received: from frink.w3.org (localhost [127.0.0.1]) by frink.w3.org (8.12.8/8.12.8) with ESMTP id h2PL0h4g008260; Tue, 25 Mar 2003 16:00:43 -0500 (EST) Received: (from lists@localhost) by frink.w3.org (8.12.8/8.12.8/Submit) id h2PL0gTt008236; Tue, 25 Mar 2003 16:00:42 -0500 (EST) Resent-Date: Tue, 25 Mar 2003 16:00:42 -0500 (EST) Resent-Message-Id: <200303252100.h2PL0gTt008236@frink.w3.org> Received: from tux.w3.org (IDENT:root@tux [18.29.0.27]) by frink.w3.org (8.12.8/8.12.8) with ESMTP id h2PL0f4g008201 for ; Tue, 25 Mar 2003 16:00:41 -0500 (EST) Received: from mail.gmx.net (mail.gmx.net [213.165.65.60]) by tux.w3.org (8.12.8/8.12.8) with SMTP id h2PL0erB021053 for ; Tue, 25 Mar 2003 16:00:40 -0500 Received: (qmail 2673 invoked by uid 65534); 25 Mar 2003 21:00:33 -0000 Received: from p3EE2481B.dip.t-dialin.net (HELO lisa) (62.226.72.27) by mail.gmx.net (mp011-rz3) with SMTP; 25 Mar 2003 22:00:33 +0100 From: "Julian Reschke" To: "Clemm, Geoff" , "WebDAV" Date: Tue, 25 Mar 2003 22:00:31 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal Subject: RE: I-D ACTION:draft-ietf-webdav-quota-01.txt X-Archived-At: http://www.w3.org/mid/JIEGINCHMLABHJBIGKBCAEONGNAA.julian.reschke@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7540 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit The reason I raised this is because I feel that a "disk full" indeed is an error condition on the server (thus 5xx), but a failed request due to exceeded quota limits happens *on purpose* -- the server theoretically *could* perform the request, but it doesn't want to. But as Geoff already stated, this is really not an important issue -- even more so if we have well-defined condition names that we can send in error response bodies. I'd prefer to focus the discussion on the other issues I mentioned (such as what is the quota model the spec describes, and do we really need to describe a specific model at all; or: are physical disk limits a special case of quotas? -- RFC3010 distinguishes both). Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 > -----Original Message----- > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Clemm, Geoff > Sent: Tuesday, March 25, 2003 9:51 PM > To: WebDAV > Subject: RE: I-D ACTION:draft-ietf-webdav-quota-01.txt > > > > Any error can be "resolved" by changing the request to something > else that doesn't fail, so that can't be the criterion used to > distinguish a 4xx from a 5xx. All that sections 10.4 and 10.5 say > are: > > "The 4xx class of status code is intended for cases in which the > client seems to have erred." > > "Response status codes beginning with the digit "5" indicate cases in > which the server is aware that it has erred or is incapable of > performing the request." > > So requests that are malformed are clearly 4xx errors, but > most other error cases are ambiguous, because looking at the > error one way, the client erred in asking the server to do something > it couldn't do (e.g. create a larger file than is permitted), but > looking at them another way, the server erred by not (or by being > incapable of) performing the specified request (e.g. create the large > file). > > Cheers, > Geoff > > > -----Original Message----- > From: Jim Luther [mailto:luther.j@apple.com] > Sent: Tuesday, March 25, 2003 12:20 PM > To: WebDAV > Subject: Re: I-D ACTION:draft-ietf-webdav-quota-01.txt > > > > I'd refer back to rfc2616's language in sections 10.4 "Client Error > 4xx" and 10.5 "Server Error 5xx". 4xx is for errors the server thinks > can be resolved by changes in the client's request, and 5xx is for > errors the server thinks are caused by something server-side. > > - Jim > > On Tuesday, March 25, 2003, at 08:35 AM, Clemm, Geoff wrote: > > > > > That wasn't the question I meant to ask. > > > > Clearly there are clients that handle a specific code > > (such as 507) differently from another specific code (such as 413). > > But in those cases it doesn't matter whether the standard > > defined that specific code to be in the 4xx or 5xx range. > > > > What I was asking was whether there was a client that > > generically handled 4xx codes (i.e. a 4xx code that it had no > > special handling for) in a significantly different way than > > it handles a 5xx code (i.e. a 5xx code that it had no special > > handling for). I.e., when we are deciding whether to put a > > specific code in the 4xx or 5xx range, does it matter which > > one we pick? > > > > Cheers, > > Geoff > > > > -----Original Message----- > > From: Jim Luther [mailto:luther.j@apple.com] > > Sent: Tuesday, March 25, 2003 10:46 AM > > To: WebDAV > > Subject: Re: I-D ACTION:draft-ietf-webdav-quota-01.txt > > > > > > > > On Monday, March 24, 2003, at 07:53 PM, Clemm, Geoff wrote: > > > >> Just for interests sake, is there any client that acts significantly > >> differently if it were to receive a 4xx response instead of a 5xx > >> response? If not, this question is merely an aesthetic quibble (:-). > > > > Yes there is a client that handles those responses quite differently. > > > > The Mac OS X WebDAV file system client translates 507 to ENOSPC (No > > space left on device) which is interpreted by most Macintosh > > applications to mean the device is full; the WebDAV file system > > translates 413 as a generic 4xx response to EINVAL (Invalid argument) > > which is interpreted by most Macintosh applications to mean "something > > wasn't right - who knows what?" > > > > The Mac OS X WebDAV file system client is one of the few clients > > actually using quotas today and has been for over 1-1/2 years now. > > > > Jim Luther > > Apple Computer, Inc. > > > From w3c-dist-auth-request@w3.org Tue Mar 25 16:50:44 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05532 for ; Tue, 25 Mar 2003 16:50:43 -0500 (EST) Received: from frink.w3.org (localhost [127.0.0.1]) by frink.w3.org (8.12.8/8.12.8) with ESMTP id h2PLqM4g028863; Tue, 25 Mar 2003 16:52:22 -0500 (EST) Received: (from lists@localhost) by frink.w3.org (8.12.8/8.12.8/Submit) id h2PLqFYE028838; Tue, 25 Mar 2003 16:52:15 -0500 (EST) Resent-Date: Tue, 25 Mar 2003 16:52:15 -0500 (EST) Resent-Message-Id: <200303252152.h2PLqFYE028838@frink.w3.org> Received: from tux.w3.org (IDENT:root@tux [18.29.0.27]) by frink.w3.org (8.12.8/8.12.8) with ESMTP id h2PLqC4g028806 for ; Tue, 25 Mar 2003 16:52:12 -0500 (EST) Received: from mac.wakasoft.com (64-60-92-50.cust.telepacific.net [64.60.92.50]) by tux.w3.org (8.12.8/8.12.8) with ESMTP id h2PLqBrB010629 for ; Tue, 25 Mar 2003 16:52:12 -0500 Received: from apache.org (localhost [127.0.0.1]) by mac.wakasoft.com (8.12.8/8.12.8) with ESMTP id h2PLhE0V004081; Tue, 25 Mar 2003 13:43:14 -0800 (PST) Date: Tue, 25 Mar 2003 13:43:13 -0800 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: WebDAV To: "Clemm, Geoff" From: "Roy T. Fielding" In-Reply-To: Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) Subject: Re: I-D ACTION:draft-ietf-webdav-quota-01.txt X-Archived-At: http://www.w3.org/mid/C7C9BCA3-5F0A-11D7-89F1-000393753936@apache.org Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7541 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit > What I was asking was whether there was a client that > generically handled 4xx codes (i.e. a 4xx code that it had no > special handling for) in a significantly different way than > it handles a 5xx code (i.e. a 5xx code that it had no special > handling for). Yes, web spiders that perform maintenance. > I.e., when we are deciding whether to put a > specific code in the 4xx or 5xx range, does it matter which > one we pick? Yes. One way is HTTP compliant; the other is not. ....Roy From w3c-dist-auth-request@w3.org Tue Mar 25 18:06:26 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA09181 for ; Tue, 25 Mar 2003 18:06:26 -0500 (EST) Received: from frink.w3.org (localhost [127.0.0.1]) by frink.w3.org (8.12.8/8.12.8) with ESMTP id h2PN8M4g010867; Tue, 25 Mar 2003 18:08:22 -0500 (EST) Received: (from lists@localhost) by frink.w3.org (8.12.8/8.12.8/Submit) id h2PN8234010837; Tue, 25 Mar 2003 18:08:02 -0500 (EST) Resent-Date: Tue, 25 Mar 2003 18:08:02 -0500 (EST) Resent-Message-Id: <200303252308.h2PN8234010837@frink.w3.org> Received: from tux.w3.org (IDENT:root@tux [18.29.0.27]) by frink.w3.org (8.12.8/8.12.8) with ESMTP id h2PN7v4g010801 for ; Tue, 25 Mar 2003 18:07:57 -0500 (EST) Received: from sus-ma1it31.rational.com (sus-ma1it31.rational.com [130.213.73.33]) by tux.w3.org (8.12.8/8.12.8) with ESMTP id h2PN7vrB032051 for ; Tue, 25 Mar 2003 18:07:57 -0500 Received: from sus-ma1it00.rational.com ([10.64.1.25]) by 10.64.1.33 with InterScan Messaging Security Suite; Tue, 25 Mar 2003 17:51:01 -0500 Received: by sus-ma1it00.rational.com with Internet Mail Service (5.5.2656.59) id ; Tue, 25 Mar 2003 18:07:51 -0500 Message-ID: From: "Clemm, Geoff" To: WebDAV Date: Tue, 25 Mar 2003 18:07:50 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain Subject: RE: I-D ACTION:draft-ietf-webdav-quota-01.txt X-Archived-At: http://www.w3.org/mid/E4F2D33B98DF7E4880884B9F0E6FDEE25ED73D@SUS-MA1IT01 Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7542 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: To help us in our categorization of errors, could you describe how does a web spider responds differently to a 4xx or a 5xx? Also, although it is good to know that one way is compliant and the other is not (:-), it would be helpful to have some criteria to to actually make that determination. In particular, how do you distinguish a client error category (making a bad request) from a server error category (not satisfying a valid client request). There are some obvious cases (a syntactically ill-formed request), but many of the others could fall in either category (the quota errors, in particular). Cheers, Geoff -----Original Message----- From: Roy T. Fielding [mailto:fielding@apache.org] Sent: Tuesday, March 25, 2003 4:43 PM To: Clemm, Geoff Cc: WebDAV Subject: Re: I-D ACTION:draft-ietf-webdav-quota-01.txt > What I was asking was whether there was a client that > generically handled 4xx codes (i.e. a 4xx code that it had no > special handling for) in a significantly different way than > it handles a 5xx code (i.e. a 5xx code that it had no special > handling for). Yes, web spiders that perform maintenance. > I.e., when we are deciding whether to put a > specific code in the 4xx or 5xx range, does it matter which > one we pick? Yes. One way is HTTP compliant; the other is not. ....Roy From w3c-dist-auth-request@w3.org Tue Mar 25 19:05:31 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA12327 for ; Tue, 25 Mar 2003 19:05:30 -0500 (EST) Received: from frink.w3.org (localhost [127.0.0.1]) by frink.w3.org (8.12.8/8.12.8) with ESMTP id h2Q07Q4g024725; Tue, 25 Mar 2003 19:07:26 -0500 (EST) Received: (from lists@localhost) by frink.w3.org (8.12.8/8.12.8/Submit) id h2Q07Lmw024659; Tue, 25 Mar 2003 19:07:21 -0500 (EST) Resent-Date: Tue, 25 Mar 2003 19:07:21 -0500 (EST) Resent-Message-Id: <200303260007.h2Q07Lmw024659@frink.w3.org> Received: from tux.w3.org (IDENT:root@tux [18.29.0.27]) by frink.w3.org (8.12.8/8.12.8) with ESMTP id h2Q07I4g024627 for ; Tue, 25 Mar 2003 19:07:18 -0500 (EST) Received: from mac.wakasoft.com (64-60-92-50.cust.telepacific.net [64.60.92.50]) by tux.w3.org (8.12.8/8.12.8) with ESMTP id h2Q07HrB012705 for ; Tue, 25 Mar 2003 19:07:18 -0500 Received: from apache.org (localhost [127.0.0.1]) by mac.wakasoft.com (8.12.8/8.12.8) with ESMTP id h2Q08Pt0000591; Tue, 25 Mar 2003 16:08:25 -0800 (PST) Date: Tue, 25 Mar 2003 16:08:24 -0800 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: WebDAV To: "Clemm, Geoff" From: "Roy T. Fielding" In-Reply-To: Message-Id: <1020644B-5F1F-11D7-BFAA-000393753936@apache.org> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) Subject: Re: I-D ACTION:draft-ietf-webdav-quota-01.txt X-Archived-At: http://www.w3.org/mid/1020644B-5F1F-11D7-BFAA-000393753936@apache.org Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7543 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit > To help us in our categorization of errors, could you describe > how does a web spider responds differently to a 4xx or a 5xx? They have different correction procedures. If you get a 5xx error, header fields like retry-after become effective and further errors are directed to the server administrator. A 4xx error, OTOH, is directed to the page owner of the referencing page or mechanism that generated the request. A 5xx is never seen as a failure of the author of a reference. > Also, although it is good to know that one way is compliant and the > other is not (:-), it would be helpful to have some criteria to > to actually make that determination. In particular, how do you > distinguish a client error category (making a bad request) from a > server error category (not satisfying a valid client request). If the same identical request might succeed were it not for a limitation on the server handling the request, then it is a 5xx. Basically, there is nothing wrong with the request. > There are some obvious > cases (a syntactically ill-formed request), but many of the others > could fall in either category (the quota errors, in particular). Not really. If the request would have succeeded but did not due to an addition of bytes exceeding quota, then it is a 5xx. If the request alone is sending a body greater than the quota max (disregarding other content on the server), then the correct response is not quota-exceeded but rather 413 (Request Entity Too Large). I haven't encountered a case that wasn't obvious. I have encountered many cases where extensions have tried to say too many different things with one status code when two would be clearer. ....Roy From w3c-dist-auth-request@w3.org Tue Mar 25 20:00:13 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA13346 for ; Tue, 25 Mar 2003 20:00:12 -0500 (EST) Received: from frink.w3.org (localhost [127.0.0.1]) by frink.w3.org (8.12.8/8.12.8) with ESMTP id h2Q0xD4g007817; Tue, 25 Mar 2003 19:59:13 -0500 (EST) Received: (from lists@localhost) by frink.w3.org (8.12.8/8.12.8/Submit) id h2Q0vqYP007735; Tue, 25 Mar 2003 19:57:52 -0500 (EST) Resent-Date: Tue, 25 Mar 2003 19:57:52 -0500 (EST) Resent-Message-Id: <200303260057.h2Q0vqYP007735@frink.w3.org> Received: from tux.w3.org (IDENT:root@tux [18.29.0.27]) by frink.w3.org (8.12.8/8.12.8) with ESMTP id h2Q0vn4g007699 for ; Tue, 25 Mar 2003 19:57:49 -0500 (EST) Received: from ucsc.edu (cats-mx2.ucsc.edu [128.114.129.35]) by tux.w3.org (8.12.8/8.12.8) with ESMTP id h2Q0vmrB024989 for ; Tue, 25 Mar 2003 19:57:48 -0500 Received: from Tycho (dhcp-55-196.cse.ucsc.edu [128.114.55.196]) by ucsc.edu (8.10.1/8.10.1) with SMTP id h2Q0vdG16089 for ; Tue, 25 Mar 2003 16:57:40 -0800 (PST) From: "Jim Whitehead" To: "WebDAV" Date: Tue, 25 Mar 2003 16:54:24 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 X-UCSC-CATS-MailScanner: Found to be clean Subject: WG Last Call: Ordered Collections Protocol X-Archived-At: http://www.w3.org/mid/AMEPKEBLDJJCCDEJHAMIAEJJGMAA.ejw@cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7544 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit ** WORKING GROUP LAST CALL FOR COMMENTS *** This is a final call for comments from the WebDAV Working Group on the WebDAV Ordered Collections Protocol, draft-ietf-webdav-ordering-protocol-07. Please review this specification, and make comments to the WebDAV WG mailing list, w3c-dist-auth@w3.org. From the abstract of the -07 specification This specification extends the WebDAV Distributed Authoring Protocol to support server-side ordering of collection members. Of particular interest are orderings that are not based on property values, and so cannot be achieved using a search protocol's ordering option and cannot be maintained automatically by the server. Protocol elements are defined to let clients specify the position in the ordering of each collection member, as well as the semantics governing the ordering. This last call for comments period begins immediately, and ends Sunday, April 27, 2003, at midnight, US Pacific time. This allows over four weeks for review of the specification. The specification can be accessed at: Text (this is the normative version) http://www.ietf.org/internet-drafts/draft-ietf-webdav-ordering-protocol-07.t xt HTML: http://www.greenbytes.de/tech/webdav/draft-ietf-webdav-ordering-protocol-07. html XML: http://www.greenbytes.de/tech/webdav/draft-ietf-webdav-ordering-protocol-07. xml At the end of the last call review period, a new draft may be issued. Depending on the scope of changes introduced between the -07 and -08 versions, there will either be an immediate call for rough consensus (very few changes), or a second last call review period (significant changes). Once the document represents the rough consensus of the working group, Lisa and I will submit this document to the Internet Engineering Steering Group (IESG) for their approval. IESG review involves a (minimum) two week public last call for comments period. This IESG-initiated last call period is in addition to the working group last call period. This document is intended to be a "Proposed Standard". Quoting from RFC 2026, "The Internet Standards Process -- Revision 3": The entry-level maturity for the standards track is "Proposed Standard". A specific action by the IESG is required to move a specification onto the standards track at the "Proposed Standard" level. A Proposed Standard specification is generally stable, has resolved known design choices, is believed to be well-understood, has received significant community review, and appears to enjoy enough community interest to be considered valuable. However, further experience might result in a change or even retraction of the specification before it advances. Usually, neither implementation nor operational experience is required for the designation of a specification as a Proposed Standard. However, such experience is highly desirable, and will usually represent a strong argument in favor of a Proposed Standard designation. Many details on the procedures used to develop an IETF standard can be found in RFC 2026, available at: http://www.ietf.org/rfc/rfc2026.txt If there are any procedural questions or concerns, please do not hesitate to contact me, or raise an issue on the list. Notes: 1) Issues raised during the last call period will be resolved individually, rather than lumped together and dealt with as a whole. 2) If you've been waiting for a "stable" version of the specification before performing a review, wait no longer. This is it. Please review the specification NOW in order to ensure your input gets included. - Jim Whitehead Co-Chair, IETF WebDAV Working Group From w3c-dist-auth-request@w3.org Wed Mar 26 19:04:27 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA23797 for ; Wed, 26 Mar 2003 19:04:27 -0500 (EST) Received: from frink.w3.org (localhost [127.0.0.1]) by frink.w3.org (8.12.8/8.12.8) with ESMTP id h2R05g4g021831; Wed, 26 Mar 2003 19:05:42 -0500 (EST) Received: (from lists@localhost) by frink.w3.org (8.12.8/8.12.8/Submit) id h2R05Tec021817; Wed, 26 Mar 2003 19:05:29 -0500 (EST) Resent-Date: Wed, 26 Mar 2003 19:05:29 -0500 (EST) Resent-Message-Id: <200303270005.h2R05Tec021817@frink.w3.org> Received: from tux.w3.org (IDENT:root@tux [18.29.0.27]) by frink.w3.org (8.12.8/8.12.8) with ESMTP id h2R05Q4g021776 for ; Wed, 26 Mar 2003 19:05:26 -0500 (EST) Received: from mail.xythos.com ([206.14.210.116]) by tux.w3.org (8.12.8/8.12.8) with ESMTP id h2R05QrB027580 for ; Wed, 26 Mar 2003 19:05:26 -0500 Received: from ravms by mail.xythos.com with mail-ok (Exim 3.36 #3) id 18yKzj-0004dK-00; Thu, 27 Mar 2003 00:11:47 +0000 Received: from ip-216-36-77-241.dsl.sjc.megapath.net ([216.36.77.241] helo=xythos.com) by mail.xythos.com with asmtp (Exim 3.36 #3) id 18yKzj-0004d8-00; Thu, 27 Mar 2003 00:11:47 +0000 Date: Wed, 26 Mar 2003 16:05:17 -0800 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: "WebDAV" To: "Julian Reschke" From: Brian Korver In-Reply-To: Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) Old-X-Envelope-To: w3c-dist-auth@w3.org, julian.reschke@gmx.de Subject: Re: I-D ACTION:draft-ietf-webdav-quota-01.txt X-Archived-At: http://www.w3.org/mid/CAA7668A-5FE7-11D7-894D-000393751598@xythos.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7545 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit On Tuesday, March 25, 2003, at 01:00 PM, Julian Reschke wrote: > > The reason I raised this is because I feel that a "disk full" indeed > is an > error condition on the server (thus 5xx), but a failed request due to > exceeded quota limits happens *on purpose* -- the server theoretically > *could* perform the request, but it doesn't want to. > > But as Geoff already stated, this is really not an important issue -- > even > more so if we have well-defined condition names that we can send in > error > response bodies. > > I'd prefer to focus the discussion on the other issues I mentioned > (such as > what is the quota model the spec describes, and do we really need to > describe a specific model at all; or: are physical disk limits a > special > case of quotas? -- RFC3010 distinguishes both). > > Julian Julian, I was thinking that physical disk limits are just another class of "quotas". That probably isn't clear enough from the spec, and should probably be stated. The alternative is to report two numbers, quota-limit and something like "space-limit", but I think we basically agreed that reporting back one number would be better than multiple numbers (given that the server should know which of the numbers is the "best" one to represent the space constraints on that server). -brian briank@xythos.com From w3c-dist-auth-request@w3.org Wed Mar 26 19:08:59 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA23853 for ; Wed, 26 Mar 2003 19:08:58 -0500 (EST) Received: from frink.w3.org (localhost [127.0.0.1]) by frink.w3.org (8.12.8/8.12.8) with ESMTP id h2R0AY4g023011; Wed, 26 Mar 2003 19:10:34 -0500 (EST) Received: (from lists@localhost) by frink.w3.org (8.12.8/8.12.8/Submit) id h2R0AYVc022999; Wed, 26 Mar 2003 19:10:34 -0500 (EST) Resent-Date: Wed, 26 Mar 2003 19:10:34 -0500 (EST) Resent-Message-Id: <200303270010.h2R0AYVc022999@frink.w3.org> Received: from tux.w3.org (IDENT:root@tux [18.29.0.27]) by frink.w3.org (8.12.8/8.12.8) with ESMTP id h2R0AW4g022967 for ; Wed, 26 Mar 2003 19:10:32 -0500 (EST) Received: from mail.xythos.com ([206.14.210.116]) by tux.w3.org (8.12.8/8.12.8) with ESMTP id h2R0AWrB029006 for ; Wed, 26 Mar 2003 19:10:32 -0500 Received: from ravms by mail.xythos.com with mail-ok (Exim 3.36 #3) id 18yL4k-0004lx-00; Thu, 27 Mar 2003 00:16:58 +0000 Received: from ip-216-36-77-241.dsl.sjc.megapath.net ([216.36.77.241] helo=xythos.com) by mail.xythos.com with asmtp (Exim 3.36 #3) id 18yL4k-0004lm-00; Thu, 27 Mar 2003 00:16:58 +0000 Date: Wed, 26 Mar 2003 16:10:28 -0800 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: "WebDAV" To: Stefan Eissing From: Brian Korver In-Reply-To: <80EC6FF2-5DD2-11D7-835C-00039384827E@greenbytes.de> Message-Id: <8409D5C5-5FE8-11D7-894D-000393751598@xythos.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) Old-X-Envelope-To: w3c-dist-auth@w3.org, stefan.eissing@greenbytes.de Subject: Re: I-D ACTION:draft-ietf-webdav-quota-01.txt X-Archived-At: http://www.w3.org/mid/8409D5C5-5FE8-11D7-894D-000393751598@xythos.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7546 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit On Monday, March 24, 2003, at 12:27 AM, Stefan Eissing wrote: > I wonder if this equation holds true when "disk space" gets low. Say > you > have 10 GB of space on the server, you have 10 users and each user > has a quota of 1GB. You add an 11th user also with 1GB quota (or an > administrator puts a 1GB sized resource). > > Now, when the free space on the server goes below 1GB, the above > equation will not tell you how large a file you can PUT. That problem > seems to be avoided in 3010 with "quota_avail_*". > > //Stefan If the free spec on the server goes below 1GB, then the quota-used will compensate. I agree that isn't as intuitive as the "avail" way of doing it, and this should probably be explained better in the spec. -brian briank@xythos.com From w3c-dist-auth-request@w3.org Thu Mar 27 06:18:11 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA23324 for ; Thu, 27 Mar 2003 06:18:11 -0500 (EST) Received: from frink.w3.org (localhost [127.0.0.1]) by frink.w3.org (8.12.8/8.12.8) with ESMTP id h2RBJw4g021574; Thu, 27 Mar 2003 06:19:58 -0500 (EST) Received: (from lists@localhost) by frink.w3.org (8.12.8/8.12.8/Submit) id h2RBJoab021280; Thu, 27 Mar 2003 06:19:50 -0500 (EST) Resent-Date: Thu, 27 Mar 2003 06:19:50 -0500 (EST) Resent-Message-Id: <200303271119.h2RBJoab021280@frink.w3.org> Received: from tux.w3.org (IDENT:root@tux [18.29.0.27]) by frink.w3.org (8.12.8/8.12.8) with ESMTP id h2RBJl4g021184 for ; Thu, 27 Mar 2003 06:19:47 -0500 (EST) Received: from greenbytes.de (mail.greenbytes.de [217.5.201.10] (may be forged)) by tux.w3.org (8.12.8/8.12.8) with SMTP id h2RBJkrB017353 for ; Thu, 27 Mar 2003 06:19:47 -0500 Received: from greenbytes.de ([192.168.1.23]) by greenbytes.de ([217.5.201.11]) with SMTP (MDaemon.PRO.v6.7.0.R) for ; Thu, 27 Mar 2003 12:19:19 +0100 Date: Thu, 27 Mar 2003 12:19:18 +0100 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: "WebDAV" To: Brian Korver From: Stefan Eissing In-Reply-To: <8409D5C5-5FE8-11D7-894D-000393751598@xythos.com> Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) X-MDRemoteIP: 192.168.1.23 X-Return-Path: stefan.eissing@greenbytes.de X-MDaemon-Deliver-To: w3c-dist-auth@w3.org Subject: Re: I-D ACTION:draft-ietf-webdav-quota-01.txt X-Archived-At: http://www.w3.org/mid/F378ED18-6045-11D7-8F8B-00039384827E@greenbytes.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7547 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit Am Donnerstag, 27.03.03, um 01:10 Uhr (Europe/Berlin) schrieb Brian Korver: > On Monday, March 24, 2003, at 12:27 AM, Stefan Eissing wrote: >> I wonder if this equation holds true when "disk space" gets low. Say >> you >> have 10 GB of space on the server, you have 10 users and each user >> has a quota of 1GB. You add an 11th user also with 1GB quota (or an >> administrator puts a 1GB sized resource). >> >> Now, when the free space on the server goes below 1GB, the above >> equation will not tell you how large a file you can PUT. That problem >> seems to be avoided in 3010 with "quota_avail_*". >> >> //Stefan > > If the free spec on the server goes below 1GB, then the quota-used > will compensate. I agree that isn't as intuitive as the "avail" > way of doing it, and this should probably be explained better > in the spec. If I understand you correctly the server will on low "disk space" tweak the quota-used value so that the difference between quota-size and quota-used matches the available space? So a user with 5GB quota on a server with 4GB space left, will be told that he already uses 1GB although he has no resources allocated? //Stefan From w3c-dist-auth-request@w3.org Thu Mar 27 12:11:51 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08285 for ; Thu, 27 Mar 2003 12:11:51 -0500 (EST) Received: from frink.w3.org (localhost [127.0.0.1]) by frink.w3.org (8.12.8/8.12.8) with ESMTP id h2RHDj4g022718; Thu, 27 Mar 2003 12:13:45 -0500 (EST) Received: (from lists@localhost) by frink.w3.org (8.12.8/8.12.8/Submit) id h2RHD93D022531; Thu, 27 Mar 2003 12:13:09 -0500 (EST) Resent-Date: Thu, 27 Mar 2003 12:13:09 -0500 (EST) Resent-Message-Id: <200303271713.h2RHD93D022531@frink.w3.org> Received: from tux.w3.org (IDENT:root@tux [18.29.0.27]) by frink.w3.org (8.12.8/8.12.8) with ESMTP id h2RHD64g022495 for ; Thu, 27 Mar 2003 12:13:06 -0500 (EST) Received: from ucsc.edu (cats-mx2.ucsc.edu [128.114.129.35]) by tux.w3.org (8.12.8/8.12.8) with ESMTP id h2RHD5rB009442 for ; Thu, 27 Mar 2003 12:13:05 -0500 Received: from Tycho (dhcp-55-196.cse.ucsc.edu [128.114.55.196]) by ucsc.edu (8.10.1/8.10.1) with SMTP id h2RHCnG07848 for ; Thu, 27 Mar 2003 09:12:50 -0800 (PST) From: "Jim Whitehead" To: "WebDAV" Date: Thu, 27 Mar 2003 09:09:34 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 X-UCSC-CATS-MailScanner: Found to be clean Subject: FW: Squid 2.5 and Webdav X-Archived-At: http://www.w3.org/mid/AMEPKEBLDJJCCDEJHAMIGEOFGMAA.ejw@cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7548 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 8bit Accidentally caught by the spam filter. - Jim -----Original Message----- From: Peter Smith [mailto:peter.smith@utsouthwestern.edu] Sent: Thursday, March 27, 2003 9:03 AM To: w3c-dist-auth@w3.org Subject: [Moderator Action] Squid 2.5 and Webdav I notice on the website, http://www.webdav.org, and specifically the page which mentions the Squid proxy, http://www.webdav.org/other/proxy.html, that Squids v2.2, v2.3, and v2.4 are listed. I'd like to know if anyone has verified the status of Squid v2.5's interoperability with Webdav? According to Henrik Nordström Squid v2.5 supports most Webdav methods out-of-the-box. The document I'm referring to is http://www.squid-cache.org/mail-archive/squid-users/200111/0637.html . Is this, in fact, the case? Please,someone, let me know as I have some users who are still having difficulties accessing Webdav content via Squid v2.5 . Are there still some methods which are missing in Squid v2.5's support? Thank you! Peter Smith From w3c-dist-auth-request@w3.org Thu Mar 27 14:33:16 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14514 for ; Thu, 27 Mar 2003 14:33:16 -0500 (EST) Received: from frink.w3.org (localhost [127.0.0.1]) by frink.w3.org (8.12.8/8.12.8) with ESMTP id h2RJZ24g006830; Thu, 27 Mar 2003 14:35:02 -0500 (EST) Received: (from lists@localhost) by frink.w3.org (8.12.8/8.12.8/Submit) id h2RJYwU8006766; Thu, 27 Mar 2003 14:34:58 -0500 (EST) Resent-Date: Thu, 27 Mar 2003 14:34:58 -0500 (EST) Resent-Message-Id: <200303271934.h2RJYwU8006766@frink.w3.org> Received: from tux.w3.org (IDENT:root@tux [18.29.0.27]) by frink.w3.org (8.12.8/8.12.8) with ESMTP id h2RJYu4g006734 for ; Thu, 27 Mar 2003 14:34:56 -0500 (EST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by tux.w3.org (8.12.8/8.12.8) with SMTP id h2RJYtrB025216 for ; Thu, 27 Mar 2003 14:34:55 -0500 Received: (qmail 10911 invoked by uid 65534); 27 Mar 2003 19:34:48 -0000 Received: from pD950C3A6.dip.t-dialin.net (HELO lisa) (217.80.195.166) by mail.gmx.net (mp014-rz3) with SMTP; 27 Mar 2003 20:34:48 +0100 From: "Julian Reschke" To: "WebDAV" Date: Thu, 27 Mar 2003 20:34:46 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal In-Reply-To: <1020644B-5F1F-11D7-BFAA-000393753936@apache.org> Subject: RE: I-D ACTION:draft-ietf-webdav-quota-01.txt X-Archived-At: http://www.w3.org/mid/JIEGINCHMLABHJBIGKBCCEDHGOAA.julian.reschke@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7549 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Roy T. Fielding > Sent: Wednesday, March 26, 2003 1:08 AM > To: Clemm, Geoff > Cc: WebDAV > Subject: Re: I-D ACTION:draft-ietf-webdav-quota-01.txt > > ... > > > There are some obvious > > cases (a syntactically ill-formed request), but many of the others > > could fall in either category (the quota errors, in particular). > > Not really. If the request would have succeeded but did not due > to an addition of bytes exceeding quota, then it is a 5xx. > If the request alone is sending a body greater than the quota max > (disregarding other content on the server), then the correct > response is not quota-exceeded but rather 413 (Request Entity Too > Large). > > ... For the record -- having read Roy's comment and looking again at RFC2616 -- "Response status codes beginning with the digit "5" indicate cases in which the server is aware that it has erred or is incapable of performing the request." I now agree that a 5xx code is the right one for "quota exceeded". However I still think it's valuable to be able to distinguish between the various reasons for 507 (Insufficient Storage), so I think we should have specific condition (for marshalling in DAV:error) for the various conditions. Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Thu Mar 27 14:34:26 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14607 for ; Thu, 27 Mar 2003 14:34:25 -0500 (EST) Received: from frink.w3.org (localhost [127.0.0.1]) by frink.w3.org (8.12.8/8.12.8) with ESMTP id h2RJaP4g007011; Thu, 27 Mar 2003 14:36:25 -0500 (EST) Received: (from lists@localhost) by frink.w3.org (8.12.8/8.12.8/Submit) id h2RJaOKm007005; Thu, 27 Mar 2003 14:36:24 -0500 (EST) Resent-Date: Thu, 27 Mar 2003 14:36:24 -0500 (EST) Resent-Message-Id: <200303271936.h2RJaOKm007005@frink.w3.org> Received: from tux.w3.org (IDENT:root@tux [18.29.0.27]) by frink.w3.org (8.12.8/8.12.8) with ESMTP id h2RJaN4g006973 for ; Thu, 27 Mar 2003 14:36:23 -0500 (EST) Received: from mail.xythos.com ([206.14.210.116]) by tux.w3.org (8.12.8/8.12.8) with ESMTP id h2RJaNrB025478 for ; Thu, 27 Mar 2003 14:36:23 -0500 Received: from ravms by mail.xythos.com with mail-ok (Exim 3.36 #3) id 18ydHC-0006Ea-00; Thu, 27 Mar 2003 19:43:02 +0000 Received: from ip-216-36-77-241.dsl.sjc.megapath.net ([216.36.77.241] helo=xythos.com) by mail.xythos.com with asmtp (Exim 3.36 #3) id 18ydHB-0006EO-00; Thu, 27 Mar 2003 19:43:01 +0000 Date: Thu, 27 Mar 2003 11:36:15 -0800 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: "WebDAV" To: Stefan Eissing From: Brian Korver In-Reply-To: Message-Id: <5FF823BB-608B-11D7-894D-000393751598@xythos.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) Old-X-Envelope-To: w3c-dist-auth@w3.org, stefan.eissing@greenbytes.de Subject: Re: I-D ACTION:draft-ietf-webdav-quota-01.txt X-Archived-At: http://www.w3.org/mid/5FF823BB-608B-11D7-894D-000393751598@xythos.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7550 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit On Thursday, March 27, 2003, at 03:19 AM, Stefan Eissing wrote: > If I understand you correctly the server will on low "disk space" tweak > the quota-used value so that the difference between quota-size > and quota-used matches the available space? > > So a user with 5GB quota on a server with 4GB space left, will be told > that he already uses 1GB although he has no resources allocated? > > //Stefan The server is free to do whatever it wants, but that is the idea. We didn't think of this when we discussed deviating from the NFS model. I'm tempted to go back to the NFS model. Does anyone else have an opinion? -brian briank@xythos.com From w3c-dist-auth-request@w3.org Thu Mar 27 14:47:42 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15167 for ; Thu, 27 Mar 2003 14:47:41 -0500 (EST) Received: from frink.w3.org (localhost [127.0.0.1]) by frink.w3.org (8.12.8/8.12.8) with ESMTP id h2RJnZ4g010830; Thu, 27 Mar 2003 14:49:35 -0500 (EST) Received: (from lists@localhost) by frink.w3.org (8.12.8/8.12.8/Submit) id h2RJnXs8010806; Thu, 27 Mar 2003 14:49:33 -0500 (EST) Resent-Date: Thu, 27 Mar 2003 14:49:33 -0500 (EST) Resent-Message-Id: <200303271949.h2RJnXs8010806@frink.w3.org> Received: from tux.w3.org (IDENT:root@tux [18.29.0.27]) by frink.w3.org (8.12.8/8.12.8) with ESMTP id h2RJnV4g010757 for ; Thu, 27 Mar 2003 14:49:31 -0500 (EST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by tux.w3.org (8.12.8/8.12.8) with SMTP id h2RJnUrB029559 for ; Thu, 27 Mar 2003 14:49:30 -0500 Received: (qmail 21501 invoked by uid 65534); 27 Mar 2003 19:49:24 -0000 Received: from pD950C3A6.dip.t-dialin.net (HELO lisa) (217.80.195.166) by mail.gmx.net (mp019-rz3) with SMTP; 27 Mar 2003 20:49:24 +0100 From: "Julian Reschke" To: "WebDAV" Date: Thu, 27 Mar 2003 20:49:22 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal In-Reply-To: Subject: RE: I-D ACTION:draft-ietf-webdav-quota-01.txt X-Archived-At: http://www.w3.org/mid/JIEGINCHMLABHJBIGKBCOEDHGOAA.julian.reschke@gmx.de Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7551 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Brian Korver > Sent: Thursday, March 27, 2003 1:05 AM > To: Julian Reschke > Cc: WebDAV > Subject: Re: I-D ACTION:draft-ietf-webdav-quota-01.txt > > > > On Tuesday, March 25, 2003, at 01:00 PM, Julian Reschke wrote: > > > > The reason I raised this is because I feel that a "disk full" indeed > > is an > > error condition on the server (thus 5xx), but a failed request due to > > exceeded quota limits happens *on purpose* -- the server theoretically > > *could* perform the request, but it doesn't want to. > > > > But as Geoff already stated, this is really not an important issue -- > > even > > more so if we have well-defined condition names that we can send in > > error > > response bodies. > > > > I'd prefer to focus the discussion on the other issues I mentioned > > (such as > > what is the quota model the spec describes, and do we really need to > > describe a specific model at all; or: are physical disk limits a > > special > > case of quotas? -- RFC3010 distinguishes both). > > > > Julian > > Julian, > > I was thinking that physical disk limits are just another class of "quotas". > That probably isn't clear enough from the spec, and should probably be > stated. Yes and no. It depends on who is asking. Note that RFC3010 (which I think we all like :-) distinguishes between both. Earlier today, Stefan E. showed that lumping disk limits and quota into the same property can lead to very surprising effects. Do we really want that? > The alternative is to report two numbers, quota-limit and something like > "space-limit", but I think we basically agreed that reporting back one number > would be better than multiple numbers (given that the server should know > which of the numbers is the "best" one to represent the space constraints > on that server). The issue here is that disk limits *behave* differently than quotas. For instance, a "quota error" usually can be resolved by the user, by deleting some of his own files, while a "disk full" condition may possibly not (other user may take up the disk space, so there's no way for the affected user to recover/continue). Also, recovery from both conditions may be different -- the person you need to contact to get a higher quota might be somebody else than the person that's able to free up physical disk space (or add new disks). Here's another proposal how we *could* inherit RFC3010 properties without much effort in WebDAV -- just use their welldefined names from RFC3010, and put them into the IETF namespace reserved for individual RFCs, for instance: 12345678 1234567890 123456 1234567 (we'd just have to state how RFC3010 terminology maps to WebDAV resources) Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Mon Mar 31 20:32:21 2003 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA06137 for ; Mon, 31 Mar 2003 20:32:21 -0500 (EST) Received: from frink.w3.org (localhost [127.0.0.1]) by frink.w3.org (8.12.8/8.12.8) with ESMTP id h311Xv4g016844; Mon, 31 Mar 2003 20:33:57 -0500 (EST) Received: (from lists@localhost) by frink.w3.org (8.12.8/8.12.8/Submit) id h311XGft016496; Mon, 31 Mar 2003 20:33:16 -0500 (EST) Resent-Date: Mon, 31 Mar 2003 20:33:16 -0500 (EST) Resent-Message-Id: <200304010133.h311XGft016496@frink.w3.org> Received: from tux.w3.org (IDENT:root@tux [18.29.0.27]) by frink.w3.org (8.12.8/8.12.8) with ESMTP id h311XD4g016457 for ; Mon, 31 Mar 2003 20:33:13 -0500 (EST) Received: from ucsc.edu (cats-mx2.ucsc.edu [128.114.129.35]) by tux.w3.org (8.12.8/8.12.8) with ESMTP id h311XCrB029041 for ; Mon, 31 Mar 2003 20:33:12 -0500 Received: from Tycho (dhcp-55-196.cse.ucsc.edu [128.114.55.196]) by ucsc.edu (8.10.1/8.10.1) with SMTP id h311WNi03550 for ; Mon, 31 Mar 2003 17:32:24 -0800 (PST) From: "Jim Whitehead" To: "WebDAV" Date: Mon, 31 Mar 2003 17:29:41 -0800 Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0029_01C2F7AB.1D026640" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal X-UCSC-CATS-MailScanner: Found to be clean Subject: FW: [Moderator Action] WEBDAV and Message Properties; Specifically "Changed By" Value X-Archived-At: http://www.w3.org/mid/AMEPKEBLDJJCCDEJHAMIAEIJGNAA.ejw@cse.ucsc.edu Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7552 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: This is a multi-part message in MIME format. ------=_NextPart_000_0029_01C2F7AB.1D026640 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Accidentally caught by the spam filter. - Jim -----Original Message----- From: Scott.Coltrane [mailto:Scott.Coltrane@target.com] Sent: Monday, March 31, 2003 3:03 PM To: 'w3c-dist-auth@w3.org' Subject: [Moderator Action] WEBDAV and Message Properties; Specifically "Changed By" Value I have written VB code to extract messages from an Exchange public folder using WEBDAV. I can get all the standard header stuff, like TO and FROM and TEXTDESCRIPTION and DATERECEIVED. However, one thing eludes me, and I need some advice. There are users who respond to private messages in their own inbox by changing their FROM field to the name of a public folder, and then CC that folder. The result is a public folder containing messages that indicate the sender of each message is the folder itself. However, the recipient of the message can view the original sender's email ID by using the Field Chooser in Outlook and selecting the CHANGED BY option. This adds a column to the recipient's inbox that shows who originally sent the email, regardless of what the FROM value states. That's what I'm looking for -- the CHANGED BY value. Does anybody know how to extract that using WEBDAV? Would that information exist in the carbon copied message in the public folder? ------=_NextPart_000_0029_01C2F7AB.1D026640 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Accidentally caught by the spam=20 filter.
 
-=20 Jim
-----Original Message-----
From: Scott.Coltrane=20 [mailto:Scott.Coltrane@target.com]
Sent: Monday, March 31, = 2003 3:03=20 PM
To: 'w3c-dist-auth@w3.org'
Subject: [Moderator = Action]=20 WEBDAV and Message Properties; Specifically "Changed By"=20 Value

I = have written VB=20 code to extract messages from an Exchange public folder using = WEBDAV.  I=20 can get all the standard header stuff, like TO and FROM and = TEXTDESCRIPTION and=20 DATERECEIVED.  However, one thing eludes me, and I need some=20 advice.
 
There are users=20 who respond to private messages in their own inbox by changing their = FROM field=20 to the name of a public folder, and then CC that folder.  The = result=20 is a public folder containing messages that indicate the sender of = each=20 message is the folder itself.  However, the recipient of the = message can=20 view the original sender's email ID by using the Field Chooser in = Outlook and=20 selecting the CHANGED BY option.  This adds a column to the = recipient's=20 inbox that shows who originally sent the email, regardless of what the = FROM=20 value states.
 
That's what I'm=20 looking for -- the CHANGED BY value.
 
Does = anybody know=20 how to extract that using WEBDAV?  Would that information exist in = the=20 carbon copied message in the public folder? 
 
 
------=_NextPart_000_0029_01C2F7AB.1D026640--