From w3c-dist-auth-request@w3.org Tue Aug 3 19:29:55 1999 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA16472 for ; Tue, 3 Aug 1999 19:29:54 -0400 (EDT) From: w3c-dist-auth-request@w3.org Received: by www19.w3.org (8.9.0/8.9.0) id TAA16902 for webdav-archive@lists.ietf.org; Tue, 3 Aug 1999 19:29:56 -0400 (EDT) Date: Tue, 3 Aug 1999 19:29:56 -0400 (EDT) Message-Id: <199908032329.TAA16902@www19.w3.org> To: webdav-archive@ietf.org Subject: Re: subscribe webdav-archive@lists.ietf.org X-Loop: w3c-dist-auth@w3.org ******* Note from the listmaster: (listmaster@w3.org) ******* You have been added to the subscriber list of: w3c-dist-auth@w3.org with the following mail address: webdav-archive@lists.ietf.org This mailing list is now being governed by SmartLists. All administrative requests should be sent to the request address: w3c-dist-auth-request@w3.org Commands to the request address are processed automatically. The desired command should be sent in the Subject of a mail message to 'w3c-dist-auth-request@w3.org'. ******* About the W3C Mailing Lists ******* There are many mailing lists provided by the W3C for discussion and development on the World Wide Web. A full list of them is available at: http://www.w3.org/Mail/Lists.html NOTE that this list is not the place for any of the following: How do I configure [insert-favorite-software-here]? I'm new to the web -- what is it? I tried to ask [insert-company-here] customer support, but [I didn't get any response / they told me to RTFM] What does RTFM mean? Answers to the above are often found in the WWW FAQ maintained by Thomas Boutell. The FAQ is available from several sites. Use the mirror closest to you: Sunsite, eastern United States (North America): http://sunsite.unc.edu/boutell/faq/ Internex Online, Montreal, eastern Canada (North America): http://www.io.org/faq/www/index.html New Software Technologies Service, Austria (Europe): http://nswt.tuwien.ac.at:8000/htdocs/boutell/ Glocom, Japan (Asia): http://www1.glocom.ac.jp/mirror/www.boutell.com/faq/index.htm The FAQ also lists the names of all the USENET newsgroups that are available regarding the WWW (most under the comp.infosystems.www.* hierarchy). ******* Administrative Requests ******* The -request mail address should be used for all list administrative requests. It accepts the following commands (in the Subject of an e-mail message): subscribe -- Subscribe to the list. If you want to subscribe under a different address, use a Reply-To: address header in the message. unsubscribe -- Unsubscribe from the list. help -- Get information about the mailing list. archive help -- Get information about the list archive(s). In the event of an address change, it would probably be wisest to first send an unsubscribe for the old address (this can be done from the new address), and then a new subscribe from the new address (the order is important). Most (un)subscription requests are processed automatically without human intervention. Do not send multiple (un)subscription or info requests in one mail. Only one will be processed per mail. NOTE: The -request server usually does quite a good job in discriminating between (un)subscribe requests and messages intended for the maintainer. If you'd like to make sure a human reads your message, make it look like a reply (i.e. the first word in the Subject: field should be "Re:", without the quotes of course); the -request server does not react to replies. ******* Archive Server ******* Every submission sent to this list is archived. Archives of public lists are available at URL: http://lists.w3.org/Archives/Public/ If you want to access this archive by e-mail, you have to send mail to the -request address with the word "archive" as the first word of your Subject:. To get you started, try sending a mail to the -request address with the following: Subject: archive help Rev. 18/Jul/97 -JK ================================================================= Welcome to the Internet Engineering Task Force (IETF) Working Group on World Wide Web Distributed Authoring and Versioning (WEBDAV). The purpose of this working group is to develop the HTTP extensions necessary to enable distributed web authoring tools to be broadly interoperable, while supporting user needs. If you are new to this working group, please examine the working group's home page, and read the group's charter. WEBDAV Working Group Home Page: WEBDAV Charter: If you are new to the IETF , please also read "Overview of the IETF," available at: Mailing list archives are available at: This mailing list is graciously provided by the World Wide Web Consortium . For your reference, your original subscription request is included below. > From webdav-archive@lists.ietf.org > From: request (w3c-dist-auth-request@w3.org) > Reply-To: webdav-archive@lists.ietf.org > To: w3c-dist-auth-request@w3.org > Subject: subscribe webdav-archive@lists.ietf.org > Comments: Action requested by ejw@ics.uci.edu From w3c-dist-auth-request@w3.org Wed Aug 4 12:23:51 1999 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16121 for ; Wed, 4 Aug 1999 12:23:51 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id MAA04830; Wed, 4 Aug 1999 12:15:00 -0400 (EDT) Resent-Date: Wed, 4 Aug 1999 12:15:00 -0400 (EDT) Resent-Message-Id: <199908041615.MAA04830@www19.w3.org> Message-ID: <37A866D4.9689D0A9@raleigh.ibm.com> Date: Wed, 04 Aug 1999 12:14:12 -0400 From: Keith Wannamaker Reply-To: krw@raleigh.ibm.com Organization: IBM Corp. X-Mailer: Mozilla 4.61 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: w3c-dist-auth@w3.org Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: PUT question Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3115 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list Content-Transfer-Encoding: 7bit The question, up front, is should a PUT request to a lock-null resource also validate the lock-null resource's parent collection against the If header? The background to the question- The PUT request involves writing to the uri's parent collection, so, in mod_dav, it always validates both the uri and the uri's parent for null resources. Thus, if /foo is a locked or lock-null resource, while / is not locked, should the following request fail? PUT /foo HTTP/1.1 If: () . The If header doesn't specify any uri's, so both /foo and / are validated against the lock token. If /foo is a lock-null resource, and / has not been locked, I assume this request generates a 412 Precondition failed. A successfully request specifies a uri- PUT /foo HTTP/1.1 If: () . This seems consistent with the spec, but a little unintuitive. I don't know of any locknull-aware mainstream clients, so I suppose this is new ground. Is this indeed the spirit of 2518? Thanks for any input, Keith -- Keith Wannamaker IBM HTTP Server Development RTP NC, USA From w3c-dist-auth-request@w3.org Wed Aug 4 12:37:44 1999 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16354 for ; Wed, 4 Aug 1999 12:37:43 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id MAA05206; Wed, 4 Aug 1999 12:29:12 -0400 (EDT) Resent-Date: Wed, 4 Aug 1999 12:29:12 -0400 (EDT) Resent-Message-Id: <199908041629.MAA05206@www19.w3.org> From: "Kevin Wiggen" To: , Date: Wed, 4 Aug 1999 09:23:57 -0700 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.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3155.0 In-Reply-To: <37A866D4.9689D0A9@raleigh.ibm.com> Subject: RE: PUT question Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3116 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list Content-Transfer-Encoding: 7bit I would argue that the lock-null resource IS a resource... When overwriting any other resource, you do not need to check the parent for its locks through IF headers (as its name consistency will not change). Therefore I think you don't need to check the parent as you are overwriting a known resource. This is at least how Xythos handles this situation... Kevin From w3c-dist-auth-request@w3.org Wed Aug 4 13:15:06 1999 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16943 for ; Wed, 4 Aug 1999 13:15:05 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id NAA06974; Wed, 4 Aug 1999 13:05:42 -0400 (EDT) Resent-Date: Wed, 4 Aug 1999 13:05:42 -0400 (EDT) Resent-Message-Id: <199908041705.NAA06974@www19.w3.org> Message-Id: <4.1.19990804100435.00aa3030@192.168.254.128> X-Sender: contact@pop.lmi.net X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Wed, 04 Aug 1999 10:05:31 -0700 To: "Kevin Wiggen" , , From: Jim Davis In-Reply-To: References: <37A866D4.9689D0A9@raleigh.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: PUT question Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3117 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list At 09:23 AM 8/4/99 -0700, Kevin Wiggen wrote: > >I would argue that the lock-null resource IS a resource... When overwriting >any other resource, you do not need to check the parent for its locks >through IF headers (as its name consistency will not change). Therefore I >think you don't need to check the parent as you are overwriting a known >resource. > >This is at least how Xythos handles this situation... > >Kevin > that's how I understand it also, and it's how PyDav does it. From w3c-dist-auth-request@w3.org Thu Aug 5 15:04:36 1999 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01957 for ; Thu, 5 Aug 1999 15:04:35 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id OAA18275; Thu, 5 Aug 1999 14:55:31 -0400 (EDT) Resent-Date: Thu, 5 Aug 1999 14:55:31 -0400 (EDT) Resent-Message-Id: <199908051855.OAA18275@www19.w3.org> From: Jim Whitehead To: WebDAV WG Date: Thu, 5 Aug 1999 11:49:07 -0700 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.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Importance: Normal Subject: Volunteers to work on locking issues Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3118 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list Content-Transfer-Encoding: 7bit Hi, Jason Crawford has pointed out to me that there has been sufficient disucssion on issues pertaining to locks in RFC 2518 that there are likely to be some (hopefully minor) tweaks to locking semantics as we more from proposed to draft standard. Jason has volunteered to work on preparing an Internet-Draft listing the proposed changes to RFC 2518 for lock-related modifications, but he'd appreciate some help with this. So, if you have some time to help Jason work on fine-tuning the WebDAV lock semantics, please send him a brief email saying you're willing to work on this with him. Thanks! - Jim From w3c-dist-auth-request@w3.org Thu Aug 5 17:03:44 1999 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05096 for ; Thu, 5 Aug 1999 17:03:43 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id QAA22415; Thu, 5 Aug 1999 16:55:09 -0400 (EDT) Resent-Date: Thu, 5 Aug 1999 16:55:09 -0400 (EDT) Resent-Message-Id: <199908052055.QAA22415@www19.w3.org> Message-ID: <8E3CFBC709A8D21191A400805F15E0DBD243D9@crte147.wc.eso.mc.xerox.com> From: "Slein, Judith A" To: "'WebDAV'" Date: Thu, 5 Aug 1999 16:54:57 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Subject: LOCK Scenarios Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3119 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list We've been concerned about interactions between MOVE and locks. Logically speaking, I think we have to consider the following cases. (They are not all equally realistic, but they all are possible.) The question to answer about each one is whether it seems right for the resource to be locked after the MOVE, and if so, which lock should apply to it after the MOVE. Considering these cases *may* help us decide whether the design principles applied in RFC 2518 were the right ones. Speaking for myself, I find that I don't have clear and consistent reactions to these cases, so I find myself relying on other considerations like what our underlying models imply, and implementation considerations. Anyhow, here are the cases: In all cases, we assume that the agent requesting the MOVE owns all the locks in question. A resource is being MOVEd. The locks are on that resource and / or its destination, not the collections that contain them. 1. The source resource is locked, but the destination is not. MOVE /a/b to /x/y, where /a/b is locked but /a/ is not and /x/y is not. 2. The source resource is not locked, but the destination is. MOVE /a/b to /x/y, where /a/b is not locked and /x/ is not locked, but /x/y is locked 3. Both are locked, but with separate locks. MOVE /a/b to /x/y, where /a/b has lock L1 and /x/y has lock L2, but neither /a/ nor /x/ is locked. A resource is being MOVEd. The locks are Depth: infinity locks on the collections that contain either the source or the destination location. 4. The source collection is locked, but the destination collection is not MOVE /a/b to /x/y, where /a/ is locked, but /x/ is not and /x/y is not. 5. The source collection is not locked, but the destination collection is. MOVE /a/b to /x/y, where /a/ is not locked and /a/b is not locked, but /x/ is locked. 6. Both are locked, but with separate locks. MOVE /a/b to /x/y, where /a/ has lock L1 and /b/ has lock L2. One lock is at the collection level, the other at the resource level. 7. The source resource is locked, and the destination collection is locked with a different token MOVE /a/b to /x/y, where /a/b has lock L1, /a/ is not locked, and /x/ has lock L2. 8. The source collection is locked, the destination resource (not its collection) is locked with a different token MOVE /a/b ro /x/y, where /a/ has lock L1, /x/ is not locked, and /x/y has lock L2. For the following cases, should the MOVE succeed or fail? If it succeeds, what should the lock state be afterwards? 9. The source resource was locked through one mapping, and a MOVE is attempted through a different mapping. 9a. /a/b and /c/d map to R. /a/ is locked. MOVE /c/d to /x/y. 9b. /a/b and /c/d map to R. /a/ is not locked, but /a/b is. MOVE /c/d to /x/y. 10. The destination resource was locked through one mapping, and a MOVE is attempted through a different mapping. 10a. /w/x and /y/z map to R. /w/ is locked. MOVE /a/b to /y/z. 10b. /w/x and /y/z map to R. /w/ is not locked, but /w/x is. MOVE /a/b to /y/z. --Judy Judith A. Slein Xerox Corporation jslein@crt.xerox.com (716)422-5169 800 Phillips Road 105/50C Webster, NY 14580 From w3c-dist-auth-request@w3.org Thu Aug 5 17:22:49 1999 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06588 for ; Thu, 5 Aug 1999 17:22:48 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id RAA22771; Thu, 5 Aug 1999 17:14:07 -0400 (EDT) Resent-Date: Thu, 5 Aug 1999 17:14:07 -0400 (EDT) Resent-Message-Id: <199908052114.RAA22771@www19.w3.org> Message-ID: <8E3CFBC709A8D21191A400805F15E0DBD243DA@crte147.wc.eso.mc.xerox.com> From: "Slein, Judith A" To: "'WebDAV'" Date: Thu, 5 Aug 1999 17:13:56 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Subject: Locking: Implementation Considerations Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3120 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list One of the issues we've been talking about is what should happen if you MOVE a resource into a locked collection. What lock should be on the resource after the MOVE? I think the question is whether collection locks with Depth: infinity should be inherited statically or dynamically. Should a collection lock with Depth: infinity affect just those resources that are in the collection at the time the lock is created (static inheritance), or should the lock affect whatever resources come into the collection while it is in force (and stop applying to any resources that are removed from the collection) (dynamic inheritance)? Static inheritance suggests that the lock would be maintained on the collection and also maintained on each resource in the collection to depth infinity. It would be painful to create this lock, and painful to remove it, and while it is in force it would be necessary to keep track of the MOVEs out of the collection in order to be able to remove the lock correctly in the end. However, if every lock is maintained on each resource it affects, it is easy to tell whether a given resource is locked. Dynamic inheritance suggests that the lock would be maintained only on the collection. It is easy to create and remove such a lock. But it is difficult to tell whether any given resource is locked when someone attempts a PUT, MOVE, etc. Especially once the BIND method is available, you would have to trace from the resource in question upward through all the bindings on all the collections in the hierarchy to find out whether the resource is locked. Currently, section 7.7 of RFC 2518 requires dynamic inheritance of locks. -- Judy Judith A. Slein Xerox Corporation jslein@crt.xerox.com (716)422-5169 800 Phillips Road 105/50C Webster, NY 14580 From w3c-dist-auth-request@w3.org Thu Aug 5 17:53:58 1999 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA08805 for ; Thu, 5 Aug 1999 17:53:57 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id RAA23262; Thu, 5 Aug 1999 17:42:21 -0400 (EDT) Resent-Date: Thu, 5 Aug 1999 17:42:21 -0400 (EDT) Resent-Message-Id: <199908052142.RAA23262@www19.w3.org> From: "Kevin Wiggen" To: "Slein, Judith A" , "'WebDAV'" Date: Thu, 5 Aug 1999 14:37:26 -0700 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.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3155.0 In-reply-to: <8E3CFBC709A8D21191A400805F15E0DBD243DA@crte147.wc.eso.mc.xerox.com> Subject: RE: Locking: Implementation Considerations Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3121 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list Content-Transfer-Encoding: 7bit My notes in tags... One of the issues we've been talking about is what should happen if you MOVE a resource into a locked collection. What lock should be on the resource after the MOVE? As you mention below section 7.7 of the spec says the new resource is now locked by the lock on the collection IF the depth = infinity I think the question is whether collection locks with Depth: infinity should be inherited statically or dynamically. Should a collection lock with Depth: infinity affect just those resources that are in the collection at the time the lock is created (static inheritance), or should the lock affect whatever resources come into the collection while it is in force (and stop applying to any resources that are removed from the collection) (dynamic inheritance)? I think its a mixture. The lock should be statically placed on the resources when the lock is made. The lock on the file should be removed if a lock is MOVED out of the locked collection, but the rest of the resources should remain locked. If a new resource is MOVED into the locked collection, it then needs to take on the lock. Whether you keep track of the lock on each file, or walk the tree every time, is an implementation issue. I think that it should work like above.. Static inheritance suggests that the lock would be maintained on the collection and also maintained on each resource in the collection to depth infinity. It would be painful to create this lock, and painful to remove it, and while it is in force it would be necessary to keep track of the MOVEs out of the collection in order to be able to remove the lock correctly in the end. However, if every lock is maintained on each resource it affects, it is easy to tell whether a given resource is locked. Painful to create, yes, necessary, yes. You already need to look at each resource in the collection to determine if it is already locked. It is possible for some resource 10 collections deep to be locked and thus the lock request should fail. I will send my thoughts on your examples (thanks for writing them up) soon. Kevin From w3c-dist-auth-request@w3.org Thu Aug 5 18:48:24 1999 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12518 for ; Thu, 5 Aug 1999 18:48:24 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id SAA24438; Thu, 5 Aug 1999 18:38:35 -0400 (EDT) Resent-Date: Thu, 5 Aug 1999 18:38:35 -0400 (EDT) Resent-Message-Id: <199908052238.SAA24438@www19.w3.org> Message-ID: From: "Babich, Alan" To: w3c-dist-auth@w3.org Date: Thu, 5 Aug 1999 15:38:42 -0700 X-Mailer: Internet Mail Service (5.5.2448.0) Subject: RE: Questions on Webdav Servers, MOVE and dest LOCK Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3122 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list Why don't we do this: When you lock a collection: depth 0: shared lock placed on the collection resource: no one can add or delete members exclusive lock placed on the collection resource: only you can add or delete members. depth 1: shared lock on coll.: no one can add or delete members. First level members that exist at that time have a shared lock placed on them. exclusive lock on coll.: only you can add or delete members. First level members that exist at that time have an exclusive lock placed on them. depth infinity: shared lock on coll.: no one can add or delete members. Members at any level(including subcollections) that exist at that time have a shared lock placed on them. exclusive lock on coll.: only you can add or delete members. Members at any level (including subcollections) that exist at that time have a shared lock placed on them. When a resource is moved out of or into a collection, the lock(s) of the resource don't change (assume the move is allowed). No locks are ever created or deleted as a result of an ordinary resource or collection resource being moved (assume the move is allowed). When you unlock a collection, depth n, you do the inverse of the operation described above on the members that exist at the time the unlock of the collection is executed. Remember that a resource can be in multiple collections at the same time. In fact, in some systems, that is the normal case. If a resource X is in two collections C1 and C2, locking C1 does not prevent the resource X from being removed from collection C2. Nor does it prevent the resource X from being inserted into collection C3. There are no locks placed or removed as side effects of MOVE. Only LOCK, UNLOCK, and DELETE mess with locks. Alan Babich -----Original Message----- From: Slein, Judith A [mailto:JSlein@crt.xerox.com] Sent: Tuesday, August 03, 1999 1:17 PM To: w3c-dist-auth@w3.org Subject: RE: Questions on Webdav Servers, MOVE and dest LOCK [caught in spam filter -Ralph] From: "Slein, Judith A" To: "'ccjason@us.ibm.com'" , w3c-dist-auth@w3.org Date: Tue, 3 Aug 1999 14:23:36 -0400 I think it was our intention that the advanced collection spec be consistent with the lock semantics described in rfc 2518. In fact, we explicitly say this is the case in 4.2.11 LOCK and UNLOCK. However, it's also true that we didn't consider interactions with locks when we were defining MOVE semantics. If you just read 4.2.10 MOVE and Bindings, you would probably expect that if a resource was locked before a MOVE, it would still be locked after the MOVE; and if it was not locked before a MOVE, it would not be locked after the MOVE. So I think we say or imply conflicting things in the advanced collections spec, and we need to figure out what we really want our story to be. I agree that we need to address these cases explicitly. My own feeling is that when you MOVE a resource, the result is the same resource, with all the same properties, at a different location. So it should have the same lock that it had at the source location. On the other hand, when we are thinking about simple resources inheriting locks from their parent collections, and moving a bunch of these resources around, it is certainly simpler to manage the locks if the simple resources inherit locks dynamically from their parent collections -- so that when you unlock a collection, you unlock all the resources that are in it at the time of the unlock rather than the ones that were in it when the lock was applied (which may reside anywhere by the time the lock is removed). The earlier rationale for having MOVE destroy the lock on a resource is at http://lists.w3.org/Archives/Public/w3c-dist-auth/1997JulSep/0177.html. > -----Original Message----- > From: ccjason@us.ibm.com [mailto:ccjason@us.ibm.com] > Sent: Monday, July 26, 1999 9:48 PM > To: w3c-dist-auth@w3.org > Subject: RE: [Moderator Action] Questions on Webdav Servers, MOVE and > dest LOCK > > > > > > 3) MOVE/COPY to a destination that is locked. 8.10.5 states "... a > > successful DELETE of a resource MUST cause all of its locks to be > > removed." > > and 8.8.4 states that overwrite set to T will do a DELETE.... > > Then will the > > LOCK on the destination be lost?? This seems wrong to me. If the > > destination is LOCKED, then after a MOVE/COPY which might delete the > > resource, I would assume the resource is still locked. > > If the destination of a COPY/MOVE is locked, and you submit > the lock token > of the destination lock in the If header, then the intent of > RFC 2518 is > that the destination resource should be locked. This is stated in the > second paragraph of section 7.7. > > > Note: Although I don't think we deal directly on the topic of > locks at the destination in the Adv Coll spec, 7.7 does seem to > be in disagreement > with the MOVE semantics of the Adv. Coll. proposal. If anyone > feels strongly that section 7.7 should remain > as is, I suggest that they do a read of the Adv Coll > document and then express their opposition. I just don't > want our Adv Coll work in this area to surprise anyone. > > We also should make sure that the Adv Coll document is *clear* > on what should happen in this situation. My opinion is that > the destination lock should go away as should the locks of > any decendent nodes in the URI tree at the destination. I > could be persuaded otherwise for a lock on the destination > URI/resource specifically though. > > J. > > From w3c-dist-auth-request@w3.org Thu Aug 5 19:06:18 1999 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA13115 for ; Thu, 5 Aug 1999 19:06:18 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id SAA24729; Thu, 5 Aug 1999 18:56:52 -0400 (EDT) Resent-Date: Thu, 5 Aug 1999 18:56:52 -0400 (EDT) Resent-Message-Id: <199908052256.SAA24729@www19.w3.org> From: "Kevin Wiggen" To: "Slein, Judith A" , "'WebDAV'" Date: Thu, 5 Aug 1999 15:51:56 -0700 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.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3155.0 In-reply-to: <8E3CFBC709A8D21191A400805F15E0DBD243D9@crte147.wc.eso.mc.xerox.com> Subject: RE: LOCK Scenarios Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3123 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list Content-Transfer-Encoding: 7bit Responses in I have tried to give thoughts to what the user would think should happen. I hope they are understandable, and I hope I don't contradict myself too much.... Kevin In all cases, we assume that the agent requesting the MOVE owns all the locks in question. A resource is being MOVEd. The locks are on that resource and / or its destination, not the collections that contain them. 1. The source resource is locked, but the destination is not. MOVE /a/b to /x/y, where /a/b is locked but /a/ is not and /x/y is not. The way I interpreted the spec is that /x/y is still not locked when this is done. The lock is lost during the move. I am OK with this. So this means there are no locks at all when the MOVE is done. Also note this means a TAGED IF header must be sent in order for this to happen 2. The source resource is not locked, but the destination is. MOVE /a/b to /x/y, where /a/b is not locked and /x/ is not locked, but /x/y is locked The spec says that /x/y gets deleted. The literal interpretation of this (see my earlier posts) means that the lock is removed and /a/b replaces /x/y. I think this is wrong for two reasons. 1) I would expect that /a/b is REPLACING /x/y and thus keeping the lock. I hate the fact that the spec says to do deletes (to depth infinity no less), but that is on the open issues list. 2) It might be possible in some implementations (I think) for someone else to create /x/y once I removed my lock via the DELETE, but before I placed the new file there... 2 is an implementation issue, but as a user, I would most likely expect the lock to still be there. 3. Both are locked, but with separate locks. MOVE /a/b to /x/y, where /a/b has lock L1 and /x/y has lock L2, but neither /a/ nor /x/ is locked. From my reading of the spec I would expect NO locks to exist when this was done. Again I believe this is wrong, and the lock L2 should still exist afterward, but be locking the newly MOVED resource. However if someone argues that in case 1 above the lock should FOLLOW the file across then I would expect this to overrule my problems with case 2 above and /a/b would still be locked by L1 A resource is being MOVEd. The locks are Depth: infinity locks on the collections that contain either the source or the destination location. 4. The source collection is locked, but the destination collection is not MOVE /a/b to /x/y, where /a/ is locked, but /x/ is not and /x/y is not. I agree with the spec here. The lock on /a simply looses /a/b as one of its members, the lock on /a and all the rest of its resources remains. Since /x/y is not locked. It is not locked after the MOVE 5. The source collection is not locked, but the destination collection is. MOVE /a/b to /x/y, where /a/ is not locked and /a/b is not locked, but /x/ is locked. Again I think I agree with the spec on this one. /x/y will be DELETED and removed from the lock. Then /a/b will be MOVED there and thus be added to the LOCK infinity. So the lock will contain the new resource /x/y at the end. 6. Both are locked, but with separate locks. MOVE /a/b to /x/y, where /a/ has lock L1 and /b/ has lock L2. /a/b is removed from the /a lock, but the /a lock L1 remains locking the rest of /a's members. L2 also has locks on the new /x/y as noted in the above example. One lock is at the collection level, the other at the resource level. 7. The source resource is locked, and the destination collection is locked with a different token MOVE /a/b to /x/y, where /a/b has lock L1, /a/ is not locked, and /x/ has lock L2. L1 gets deleted from the system, and the new /x/y is locked under L2. This also makes my way of handling number 1 more correct. Because if the lock is moving with the resource what happens here??? The spec says one owner cannot have 2 locks on the same object (I like this rule). So If 1 is written the other way, then is this a failure? This backs up my idea for how number 1 should work. 8. The source collection is locked, the destination resource (not its collection) is locked with a different token MOVE /a/b ro /x/y, where /a/ has lock L1, /x/ is not locked, and /x/y has lock L2. Again I think the spec says that at the end /a is still locking /a and its other resources than /a/b, and L2 gets removed during the MOVE, leaving you with a unlocked resource at /x/y. Again I disagree. I would expect that /x/y would still be locked with L2. For the following cases, should the MOVE succeed or fail? If it succeeds, what should the lock state be afterwards? In case 9 and 10 I had arguments that the resource R, and not the namespace should be locked. This contradicts infinity locks a little, as they lose and gain members on movement in the namespace. So I guess I am saying locks should LOCK the resource, but should be namespace aware :) 9. The source resource was locked through one mapping, and a MOVE is attempted through a different mapping. 9a. /a/b and /c/d map to R. /a/ is locked. MOVE /c/d to /x/y. Since the resource R is locked, if the correct lock token for /c/d is given (the lock token for the lock holding R), then the move occurs. Since /a/b still points to R, /x/y is still locked via /a's lock. 9b. /a/b and /c/d map to R. /a/ is not locked, but /a/b is. MOVE /c/d to /x/y. Again the MOVE succeeds if the token for R is given, the resource is still locked by /a/b 10. The destination resource was locked through one mapping, and a MOVE is attempted through a different mapping. 10a. /w/x and /y/z map to R. /w/ is locked. MOVE /a/b to /y/z. If correct lock token for R is given (If header with a tagged list of /y/z and the correct token) the move completes. Since /w is locking the resource R, it continues to do so 10b. /w/x and /y/z map to R. /w/ is not locked, but /w/x is. MOVE /a/b to /y/z. Given the correct lock tokens (See above), the move succeeds. The lock is then lost according to number 2 above. Again I would argue that the lock on /w/x would still be there with the same logic as in number 2 above From w3c-dist-auth-request@w3.org Fri Aug 6 13:22:27 1999 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20590 for ; Fri, 6 Aug 1999 13:22:26 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id NAA12117; Fri, 6 Aug 1999 13:13:29 -0400 (EDT) Resent-Date: Fri, 6 Aug 1999 13:13:29 -0400 (EDT) Resent-Message-Id: <199908061713.NAA12117@www19.w3.org> Message-ID: <078292D50C98D2118D090008C7E9C6A6019473CF@STAY.platinum.corp.microsoft.com> From: "Yaron Goland (Exchange)" To: "'ccjason@us.ibm.com'" , w3c-dist-auth@w3.org Date: Fri, 6 Aug 1999 10:11:20 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: text/plain; charset="windows-1252" Subject: RE: FW: [Moderator Action] Questions on Webdav Servers, locking Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3124 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list http://lists.w3.org/Archives/Public/w3c-dist-auth/1997JulSep/0177.html is the actual letter that caused the WG to decide that locks were lost on moves. Yaron > -----Original Message----- > From: ccjason@us.ibm.com [mailto:ccjason@us.ibm.com] > Sent: Sun, July 25, 1999 7:58 AM > To: w3c-dist-auth@w3.org > Subject: Re: FW: [Moderator Action] Questions on Webdav > Servers, locking > > > > Geoff wrote... > > But a resource state lock acts very differently. If you delete a > > resource, the resource state lock should be deleted as well > (no state > > left to lock). This is what WebDAV says. But if you MOVE > a resource, > > you'd expect the resource state lock to remain in effect. But here > > WebDAV goes with the URL lock semantics and says that a MOVE deletes > > the lock. > > I sent a note a few months ago that brought up this and a few other > locking problems. I guess everyone was busy, because we didn't > address that note. Perhaps we should. > > http://lists.w3.org/Archives/Public/w3c-dist-auth/1999AprJun/0246.html > > From w3c-dist-auth-request@w3.org Fri Aug 6 13:25:52 1999 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20663 for ; Fri, 6 Aug 1999 13:25:51 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id NAA12201; Fri, 6 Aug 1999 13:17:13 -0400 (EDT) Resent-Date: Fri, 6 Aug 1999 13:17:13 -0400 (EDT) Resent-Message-Id: <199908061717.NAA12201@www19.w3.org> Message-ID: <078292D50C98D2118D090008C7E9C6A6019473D0@STAY.platinum.corp.microsoft.com> From: "Yaron Goland (Exchange)" To: "'Geoffrey M. Clemm'" , ejw@ics.uci.edu Cc: w3c-dist-auth@w3.org Date: Fri, 6 Aug 1999 10:15:09 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.14) Content-Type: text/plain; charset="iso-8859-1" Subject: RE: FW: [Moderator Action] Questions on Webdav Servers Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3125 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list Section 7 of the WBOW vAlpha2 (http://lists.w3.org/Archives/Public/w3c-dist-auth/1999JanMar/0129.html) point to http://lists.w3.org/Archives/Public/w3c-dist-auth/1997JulSep/0177.html which explains the reasoning. Yaron > -----Original Message----- > From: Geoffrey M. Clemm [mailto:gclemm@tantalum.atria.com] > Sent: Sat, July 24, 1999 8:39 PM > To: ejw@ics.uci.edu > Cc: w3c-dist-auth@w3.org > Subject: Re: FW: [Moderator Action] Questions on Webdav Servers > > > > From: Kevin Wiggen [mailto:wiggs@xythos.com] > > The following are a few more questions I have. > > ... > > 3) MOVE/COPY to a destination that is locked. 8.10.5 > states "... a > successful DELETE of a resource MUST cause all of its > locks to be removed." > and 8.8.4 states that overwrite set to T will do a > DELETE.... Then will the > LOCK on the destination be lost?? This seems wrong to me. If the > destination is LOCKED, then after a MOVE/COPY which might > delete the > resource, I would assume the resource is still locked. > > I believe that the complexity here is due to the decision to have a > WebDAV lock be *both* a resource state lock (which means the state of > the resource is locked no matter what URL you use to access it) > *and* a URL lock (which means that you have a lock on whatever might > appear at that URL). > > This was done for some very good reasons, since you need both kinds > of locks to ensure that "when you have the lock, only you can change > what is at that URL". > > Unfortunately, the expected behavior of those two kinds of locks is > different under MOVE and DELETE, and the current WebDAV semantics ends > up with (is forced into) a compromise semantics that produces > counterintuitive behavior from either perspective. > > In particular, one would expect a URL lock to be unaffected by a MOVE > or a DELETE. If you've got a URL locked, you should be able to move > anything to it or from it (or even delete it, resulting in a locked > null resource). This I think is the perspective Kevin was taking. > > But a resource state lock acts very differently. If you delete a > resource, the resource state lock should be deleted as well (no state > left to lock). This is what WebDAV says. But if you MOVE a resource, > you'd expect the resource state lock to remain in effect. But here > WebDAV goes with the URL lock semantics and says that a MOVE deletes > the lock. > > Personally, I can live with most of this except for the losing of the > lock on the move. Can someone point me at something in the archives > that explains this decision? I didn't find it in Yaron's WBOW. > > 4) I assume that a null resource can be created via a URL > with a trailing > slash and one without. If I create one with a trailing > slash, can I only do > a MKCOL later? If no trailing slash is sent, the server > probably needs to > assume that the client might have just not sent the slash > and allow a MKCOL > or a PUT. I think the spec should state that a NULL > RESOURCE can be created > with a trailing slash or not, AND any NULL RESOURCE can > take a MKCOL or PUT. > (You already messed up some of the beauty of my server > with Null Resources, > I would hate to put even more if statements in to handle > the above....) > > I agree with Kevin. > > Note: These kinds of questions would not arise if > WebDAV would just state that /foo/x/ and /foo/x always map to > the same resource (JimW and I periodically go round on this > one :-). Even Windows and Unix agree that this is > the sensible approach. > > Cheers, > Geoff > From w3c-dist-auth-request@w3.org Fri Aug 6 14:53:04 1999 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22015 for ; Fri, 6 Aug 1999 14:53:04 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id OAA13887; Fri, 6 Aug 1999 14:44:41 -0400 (EDT) Resent-Date: Fri, 6 Aug 1999 14:44:41 -0400 (EDT) Resent-Message-Id: <199908061844.OAA13887@www19.w3.org> Message-ID: <078292D50C98D2118D090008C7E9C6A6019473D7@STAY.platinum.corp.microsoft.com> From: "Yaron Goland (Exchange)" To: "W3c-Dist-Auth (E-mail)" Date: Fri, 6 Aug 1999 11:42:36 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.14) Content-Type: text/plain; charset="iso-8859-1" Subject: Advanced Collections Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3126 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list In http://lists.w3.org/Archives/Public/w3c-dist-auth/1999JulSep/0019.html I raised the issue that the advanced collection specification should be split into three drafts. At the WebDAV meeting in OSLO the consensus of those present (or was that just Jeff and I? =) was that the draft should be split. While that consensus is not binding on the group I do think that it calls for some discussion of the topic on the mailing list. As such I would like to hear from the authors of the advanced collection specification. Do they intend to split the draft? Also, I haven't seen the meeting notes from Oslo posted but one thing that was decided by Keith is that WebDAV is being shut down in 3 months. If the advanced collection drafts aren't done by then they will have to continue as individual submissions. For those wondering about http://lists.w3.org/Archives/Public/w3c-dist-auth/1999JulSep/0020.html, I found myself very frustrated in reading the advanced collection specification. I decided that the source of my frustration was that the WebDAV WG had failed to provide a clearly defined object model and so advanced collections was forced to try and come up with definitions of the part of the WebDAV object model that it was attempting to expand. In the absence of a general model with clear language the AC draft ended up like the blind men with the elephant. The definitions fit the part of the elephant AC was standing in front of but was extremely difficult to understand because it lacked the context of the whole beast. The object model draft is a first attempt to address this problem. I look forward, when the object model draft is more mature, to seeing AC re-written to use its terminology and to see Delta-V and DASL using it as well. Having a single well defined set based object model will go a long way to ensure that WebDAV can continue to grow but still be coherent. Yaron From w3c-dist-auth-request@w3.org Fri Aug 6 15:10:51 1999 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22328 for ; Fri, 6 Aug 1999 15:10:50 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id PAA14440; Fri, 6 Aug 1999 15:02:19 -0400 (EDT) Resent-Date: Fri, 6 Aug 1999 15:02:19 -0400 (EDT) Resent-Message-Id: <199908061902.PAA14440@www19.w3.org> Message-ID: <8E3CFBC709A8D21191A400805F15E0DBD243DC@crte147.wc.eso.mc.xerox.com> From: "Slein, Judith A" To: "'WebDAV'" Date: Fri, 6 Aug 1999 15:02:07 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Subject: Circular Bindings Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3127 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list Looking over the minutes from the Oslo, it appears that the main technical issue on the advanced collection specification was circular bindings. We need to try to settle what we want the specification to say about circular bindings. Currently, the specification requires servers to detect cycles when processing requests with Depth: infinity, and to respond with 506 (Loop Detected). Questions raised at Oslo were: 1. Whether it would be better to prevent circular bindings from being created in the first place. There was discussion of the relative costs of preventing cycles for any method that creates a new binding vs. detecting them during Depth: infinity processing. Do people have opinions about whether it would be prohibitively expensive to prevent a cycle from being created by BIND or MOVE on a collection? There was discussion of possible legitimate uses for cycles. Can people offer examples of real scenarios requiring collections to contain themselves (directly or indirectly)? 2. Whether we should allow Depth: infinity requests to succeed even when loops are encountered. (Possibly a parameter was being suggested, allowing clients to direct the server whether to ignore cycles.) Jason also suggested in earlier e-mail that there is really no reason why a request should fail when it encounters a cycle during Depth: infinity. For DELETE, MOVE, COPY, and LOCK if the server can detect the cycle (which is presumed to be easy), it can do the right thing with it and report success. For PROPFIND, we could just have the server report 506 for a single response element whenever it encounters a collection for the second time, and not go into that collection. Similarly for SEARCH, it seems that the server could simply not search the collection a second time when it encounters a loop, and report success. If we decide to let cycles be created, should we change the spec to have Depth: infinity operations succeed? Or add a header to let clients specify whether to succeed or fail when a cycle is encountered? 3. General uneasiness about the impact of cycles on all methods that can have Depth: infinity, including new ones being introduced in versioning and perhaps in future extensions. Can anyone point out specific cases in versioning / configuration management where the existence of cycles might be a problem? Or in any other functional area that we might tackle in the future? --Judy Judith A. Slein Xerox Corporation jslein@crt.xerox.com (716)422-5169 800 Phillips Road 105/50C Webster, NY 14580 From w3c-dist-auth-request@w3.org Fri Aug 6 15:16:10 1999 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22381 for ; Fri, 6 Aug 1999 15:16:10 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id PAA14601; Fri, 6 Aug 1999 15:07:34 -0400 (EDT) Resent-Date: Fri, 6 Aug 1999 15:07:34 -0400 (EDT) Resent-Message-Id: <199908061907.PAA14601@www19.w3.org> Message-ID: <8E3CFBC709A8D21191A400805F15E0DBD243DD@crte147.wc.eso.mc.xerox.com> From: "Slein, Judith A" To: "'Yaron Goland (Exchange)'" , "W3c-Dist-Auth (E-mail)" Date: Fri, 6 Aug 1999 15:07:25 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Advanced Collections Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3128 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list Yes, we do intend to split the advanced collections spec into 3 parts. I'm currently working on that task and hope to have it completed within the next couple of weeks. Speaking just for myself, I agree that having an agreed object model would make life immensely easier for everyone. --Judy > -----Original Message----- > From: Yaron Goland (Exchange) [mailto:yarong@exchange.microsoft.com] > Sent: Friday, August 06, 1999 2:43 PM > To: W3c-Dist-Auth (E-mail) > Subject: Advanced Collections > > > In > http://lists.w3.org/Archives/Public/w3c-dist-auth/1999JulSep/0 > 019.html I > raised the issue that the advanced collection specification > should be split > into three drafts. At the WebDAV meeting in OSLO the > consensus of those > present (or was that just Jeff and I? =) was that the draft > should be split. > While that consensus is not binding on the group I do think > that it calls > for some discussion of the topic on the mailing list. As such > I would like > to hear from the authors of the advanced collection > specification. Do they > intend to split the draft? > > Also, I haven't seen the meeting notes from Oslo posted but > one thing that > was decided by Keith is that WebDAV is being shut down in 3 > months. If the > advanced collection drafts aren't done by then they will have > to continue as > individual submissions. > > For those wondering about > http://lists.w3.org/Archives/Public/w3c-dist-auth/1999JulSep/0 020.html, I found myself very frustrated in reading the advanced collection specification. I decided that the source of my frustration was that the WebDAV WG had failed to provide a clearly defined object model and so advanced collections was forced to try and come up with definitions of the part of the WebDAV object model that it was attempting to expand. In the absence of a general model with clear language the AC draft ended up like the blind men with the elephant. The definitions fit the part of the elephant AC was standing in front of but was extremely difficult to understand because it lacked the context of the whole beast. The object model draft is a first attempt to address this problem. I look forward, when the object model draft is more mature, to seeing AC re-written to use its terminology and to see Delta-V and DASL using it as well. Having a single well defined set based object model will go a long way to ensure that WebDAV can continue to grow but still be coherent. Yaron From w3c-dist-auth-request@w3.org Fri Aug 6 16:39:24 1999 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23667 for ; Fri, 6 Aug 1999 16:39:24 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id QAA16967; Fri, 6 Aug 1999 16:30:38 -0400 (EDT) Resent-Date: Fri, 6 Aug 1999 16:30:38 -0400 (EDT) Resent-Message-Id: <199908062030.QAA16967@www19.w3.org> From: ccjason@us.ibm.com X-Lotus-FromDomain: IBMUS To: "Slein, Judith A" cc: "'WebDAV'" Message-ID: <852567C5.0070A4F5.00@D51MTA07.pok.ibm.com> Date: Fri, 6 Aug 1999 16:30:27 -0400 Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Subject: Re: LOCK Scenarios Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3129 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list Judy, I've collected your scenarios and inserted them into a draft doc. I'll read through them more carefully later. ------------------------------------------ Phone: 914-784-7569, ccjason@us.ibm.com From w3c-dist-auth-request@w3.org Mon Aug 9 09:22:13 1999 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04826 for ; Mon, 9 Aug 1999 09:22:13 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id JAA05520; Mon, 9 Aug 1999 09:08:30 -0400 (EDT) Resent-Date: Mon, 9 Aug 1999 09:08:30 -0400 (EDT) Resent-Message-Id: <199908091308.JAA05520@www19.w3.org> Message-ID: <8E3CFBC709A8D21191A400805F15E0DBD243E0@crte147.wc.eso.mc.xerox.com> From: "Slein, Judith A" To: "'WebDAV'" Date: Mon, 9 Aug 1999 09:08:19 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Subject: FW: Circular Bindings Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3130 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list A useful note from Jason. -----Original Message----- From: ccjason@us.ibm.com [mailto:ccjason@us.ibm.com] Sent: Friday, August 06, 1999 6:51 PM To: Slein, Judith A Subject: Re: Circular Bindings Jason also suggested in earlier e-mail that there is really no reason why a request should fail when it encounters a cycle during Depth: infinity. For DELETE, MOVE, COPY, and LOCK if the server can detect the cycle (which is presumed to be easy), it can do the right thing with it and report success. For PROPFIND, we could just have the server report 506 for a single response element whenever it encounters a collection for the second time, and not go into that collection. One other thing that I said was that there are two cases to consider... 1) if the loop includes the request URI... and 2) if the loop only includes elements that are pure descendents of the request URI. The same thing goes for the destination URI in a copy. If the destination URI (or more precisely, the "parent" of the destination URI) is not included in the loop, the deletion phase of the COPY is pretty easy. But consider if if the destination (and it's parent) is in a loop.... /a/b/c/d/b/c/d/b/c/d/.... if /a/b/c/d is the destination, then a deletion is probably also going to remove various links and leave us with /a/b/ before we try to actually begin copying at /a/b/c/d.... but wait! we can't copy to /a/b/c/d unless /a/b/c exists. Now if /a/b/c is the destination, once again the deletion phase will leave us with /a/b/. And the COPY should work just fine. Now let's take the above situation and also say that there exists /e/c/d/b/c/d/b/c/d/... And let's say the destination is /e/c/d/. That's the same destination resource as in the troublesome first situation, but we are using a different URI to specify it. The deletion phase leaves us with /a/b/ and /e/c/ and the subsequent COPY phase can be pulled off. with much of the same result that we would have expected in that first scenario. Now let's us consider this previous siutation, where there is an /e/c, but let's make the destination URI the same as the first situation: /a/b/c/d/. Once again, we are left with /a/b and /e/c/ after the deletion phase. Are we allowed to go through with the COPY phase? The parent resource still exists... but the URI that was used to specify it doesn't.... Hmmmm. :-) Anyway, my point is that if the request URI (or the destination URI) is included in a loop, that can pose real problems that aren't as easily resolved as loops that reside entirely decendants of request URI. We should be aware of these distinctive classes of loops. Another observations that's not related to loops but that my example reminds me of. In the rfc2518 we say that a COPY performs a implicit delete at the destination. That has the possibly unfortunate side effect that if a portion of the destination subtree is shared via bindings with another portion of the URI space, that sharing is lost. For that reason down the road I think we should have an operation that is much like DOS's XCOPY /s. I don't want to delay the spec now for that. It can be added later. BTW, this also reminds me that with AdvColl, it is possible that a portion of the source tree and the destination might be common. And that initial deletion phase of the COPY might actually essentially delete a portion of the source tree. It's probably a red herring, but it's probably also something we should mention in the spec. From w3c-dist-auth-request@w3.org Mon Aug 9 16:51:08 1999 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13709 for ; Mon, 9 Aug 1999 16:51:08 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id QAA15517; Mon, 9 Aug 1999 16:40:22 -0400 (EDT) Resent-Date: Mon, 9 Aug 1999 16:40:22 -0400 (EDT) Resent-Message-Id: <199908092040.QAA15517@www19.w3.org> Date: Mon, 9 Aug 1999 16:40:15 -0400 Message-Id: <9908092040.AA24075@tantalum> From: "Geoffrey M. Clemm" To: JSlein@crt.xerox.com Cc: w3c-dist-auth@w3.org In-Reply-To: <8E3CFBC709A8D21191A400805F15E0DBD243E0@crte147.wc.eso.mc.xerox.com> (JSlein@crt.xerox.com) Subject: Re: FW: Circular Bindings Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3131 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list From: ccjason@us.ibm.com [mailto:ccjason@us.ibm.com] ... this also reminds me that with AdvColl, it is possible that a portion of the source tree and the destination might be common. And that initial deletion phase of the COPY might actually essentially delete a portion of the source tree. It's probably a red herring, but it's probably also something we should mention in the spec. I agree that it is something that should be explicitly mentioned (and disagree that it is a red herring :-). In particular, I'd suggest some words to the effect that a COPY should be semantically equivalent to a COPY to a temporary URL (that identifies a null resource) followed by a MOVE from the temporary URL to the destination URL. Since this situation can arise even in the base WebDAV spec, it probably would be worth adding this wording there as well, but minimally it should appear in the Adv. Col. specification. Cheers, Geoff From w3c-dist-auth-request@w3.org Tue Aug 10 13:48:53 1999 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21395 for ; Tue, 10 Aug 1999 13:48:53 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id NAA06018; Tue, 10 Aug 1999 13:36:09 -0400 (EDT) Resent-Date: Tue, 10 Aug 1999 13:36:09 -0400 (EDT) Resent-Message-Id: <199908101736.NAA06018@www19.w3.org> Message-ID: <002601bee356$cfbdaf00$0d1b15ac@aftershock.atria.com> From: "Geoffrey Clemm" To: "Yaron Goland (Exchange)" , Date: Tue, 10 Aug 1999 13:35:59 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.3110.5 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Subject: Losing Locks on MOVE requests (Was: FW: [Moderator Action] Questions on Webdav Servers) Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3132 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list Content-Transfer-Encoding: 7bit The message in WBW gives 4 choices: - fail the move if locks cannot be retained - try to maintain the locks, but let the move succeed even if the cannot be retained - require that locks be retained on a move - disallow a move on a locked file You then voted for the last choice. I'm not sure how this then resulted in the current semantics of "allow the move but strip off the locks". Are there other messages that provide the intermediate reasoning? In particular, I'm looking for a counter argument to: #1 seems to be a preferable choice, since it is trivial for both lock-preserving and lock-losing servers to implement, and a client needs to deal with a variety of failure cases for a move anyway. Having "cannot move locked file" be one of them does not seem much of an additional burden, and it does not force servers that can move locked objects to gratuitously remove all locks, and then have the client add them all back again. Cheers, Geoff -----Original Message----- From: Yaron Goland (Exchange) To: 'Geoffrey M. Clemm' ; ejw@ics.uci.edu Cc: w3c-dist-auth@w3.org Date: Friday, August 06, 1999 1:15 PM Subject: RE: FW: [Moderator Action] Questions on Webdav Servers >Section 7 of the WBOW vAlpha2 >(http://lists.w3.org/Archives/Public/w3c-dist-auth/1999JanMar/0129.html) >point to >http://lists.w3.org/Archives/Public/w3c-dist-auth/1997JulSep/0177.html which >explains the reasoning. > > Yaron > >> -----Original Message----- >> From: Geoffrey M. Clemm [mailto:gclemm@tantalum.atria.com] >> Sent: Sat, July 24, 1999 8:39 PM >> To: ejw@ics.uci.edu >> Cc: w3c-dist-auth@w3.org >> Subject: Re: FW: [Moderator Action] Questions on Webdav Servers >> >> >> >> From: Kevin Wiggen [mailto:wiggs@xythos.com] >> >> The following are a few more questions I have. >> >> ... >> >> 3) MOVE/COPY to a destination that is locked. 8.10.5 >> states "... a >> successful DELETE of a resource MUST cause all of its >> locks to be removed." >> and 8.8.4 states that overwrite set to T will do a >> DELETE.... Then will the >> LOCK on the destination be lost?? This seems wrong to me. If the >> destination is LOCKED, then after a MOVE/COPY which might >> delete the >> resource, I would assume the resource is still locked. >> >> I believe that the complexity here is due to the decision to have a >> WebDAV lock be *both* a resource state lock (which means the state of >> the resource is locked no matter what URL you use to access it) >> *and* a URL lock (which means that you have a lock on whatever might >> appear at that URL). >> >> This was done for some very good reasons, since you need both kinds >> of locks to ensure that "when you have the lock, only you can change >> what is at that URL". >> >> Unfortunately, the expected behavior of those two kinds of locks is >> different under MOVE and DELETE, and the current WebDAV semantics ends >> up with (is forced into) a compromise semantics that produces >> counterintuitive behavior from either perspective. >> >> In particular, one would expect a URL lock to be unaffected by a MOVE >> or a DELETE. If you've got a URL locked, you should be able to move >> anything to it or from it (or even delete it, resulting in a locked >> null resource). This I think is the perspective Kevin was taking. >> >> But a resource state lock acts very differently. If you delete a >> resource, the resource state lock should be deleted as well (no state >> left to lock). This is what WebDAV says. But if you MOVE a resource, >> you'd expect the resource state lock to remain in effect. But here >> WebDAV goes with the URL lock semantics and says that a MOVE deletes >> the lock. >> >> Personally, I can live with most of this except for the losing of the >> lock on the move. Can someone point me at something in the archives >> that explains this decision? I didn't find it in Yaron's WBOW. >> >> 4) I assume that a null resource can be created via a URL >> with a trailing >> slash and one without. If I create one with a trailing >> slash, can I only do >> a MKCOL later? If no trailing slash is sent, the server >> probably needs to >> assume that the client might have just not sent the slash >> and allow a MKCOL >> or a PUT. I think the spec should state that a NULL >> RESOURCE can be created >> with a trailing slash or not, AND any NULL RESOURCE can >> take a MKCOL or PUT. >> (You already messed up some of the beauty of my server >> with Null Resources, >> I would hate to put even more if statements in to handle >> the above....) >> >> I agree with Kevin. >> >> Note: These kinds of questions would not arise if >> WebDAV would just state that /foo/x/ and /foo/x always map to >> the same resource (JimW and I periodically go round on this >> one :-). Even Windows and Unix agree that this is >> the sensible approach. >> >> Cheers, >> Geoff >> > > From w3c-dist-auth-request@w3.org Tue Aug 10 14:07:17 1999 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21651 for ; Tue, 10 Aug 1999 14:07:17 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id NAA06667; Tue, 10 Aug 1999 13:57:56 -0400 (EDT) Resent-Date: Tue, 10 Aug 1999 13:57:56 -0400 (EDT) Resent-Message-Id: <199908101757.NAA06667@www19.w3.org> Message-ID: <078292D50C98D2118D090008C7E9C6A6019473F3@STAY.platinum.corp.microsoft.com> From: "Yaron Goland (Exchange)" To: "'Geoffrey Clemm'" , w3c-dist-auth@w3.org Date: Tue, 10 Aug 1999 10:55:09 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.14) Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Losing Locks on MOVE requests (Was: FW: [Moderator Action] Qu estions on Webdav Servers) Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3133 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list Ick we did choose 4 didn't we? I think someone eventually came up with the compromise that you could move a locked resource but only if lost the lock. As for #1, a certain unbelievably large vendor, who shall remain nameless, became agitated at the possibility that the overwhelming majority of humanity would loose the ability, with their current systems, to move a file if it was locked. BTW, if this rule is such an annoyance why not just add a mandatory extension to require that the method fail if the lock can't be moved? The WebDAV spec only effects the default behavior. If you add the "movelocks" header to a request then the server is free to move the lock. You can then use mandatory in cases where you absolutely insist that the movelocks header be honored. So long as the server and client agree on a particular behavior they can do anything they damn well please. Yaron > -----Original Message----- > From: Geoffrey Clemm [mailto:geoffrey.clemm@Rational.Com] > Sent: Tue, August 10, 1999 10:36 AM > To: Yaron Goland (Exchange); w3c-dist-auth@w3.org > Subject: Losing Locks on MOVE requests (Was: FW: [Moderator Action] > Questions on Webdav Servers) > > > The message in WBW gives 4 choices: > - fail the move if locks cannot be retained > - try to maintain the locks, but let the move succeed even if > the cannot be > retained > - require that locks be retained on a move > - disallow a move on a locked file > > You then voted for the last choice. I'm not sure how this > then resulted in > the > current semantics of "allow the move but strip off the > locks". Are there > other > messages that provide the intermediate reasoning? In particular, I'm > looking > for a counter argument to: > > #1 seems to be a preferable choice, since it is trivial for > both lock-preserving and lock-losing servers to implement, > and a client > needs to > deal with a variety of failure cases for a move anyway. > Having "cannot move > locked file" be one of them does not seem much of an > additional burden, and > it does not force servers that can move locked objects to gratuitously > remove > all locks, and then have the client add them all back again. > > Cheers, > Geoff > > -----Original Message----- > From: Yaron Goland (Exchange) > To: 'Geoffrey M. Clemm' ; ejw@ics.uci.edu > > Cc: w3c-dist-auth@w3.org > Date: Friday, August 06, 1999 1:15 PM > Subject: RE: FW: [Moderator Action] Questions on Webdav Servers > > > >Section 7 of the WBOW vAlpha2 > >(http://lists.w3.org/Archives/Public/w3c-dist-auth/1999JanMar > /0129.html) > >point to > >http://lists.w3.org/Archives/Public/w3c-dist-auth/1997JulSep/ > 0177.html > which > >explains the reasoning. > > > > Yaron > > > >> -----Original Message----- > >> From: Geoffrey M. Clemm [mailto:gclemm@tantalum.atria.com] > >> Sent: Sat, July 24, 1999 8:39 PM > >> To: ejw@ics.uci.edu > >> Cc: w3c-dist-auth@w3.org > >> Subject: Re: FW: [Moderator Action] Questions on Webdav Servers > >> > >> > >> > >> From: Kevin Wiggen [mailto:wiggs@xythos.com] > >> > >> The following are a few more questions I have. > >> > >> ... > >> > >> 3) MOVE/COPY to a destination that is locked. 8.10.5 > >> states "... a > >> successful DELETE of a resource MUST cause all of its > >> locks to be removed." > >> and 8.8.4 states that overwrite set to T will do a > >> DELETE.... Then will the > >> LOCK on the destination be lost?? This seems wrong to > me. If the > >> destination is LOCKED, then after a MOVE/COPY which might > >> delete the > >> resource, I would assume the resource is still locked. > >> > >> I believe that the complexity here is due to the decision to have a > >> WebDAV lock be *both* a resource state lock (which means > the state of > >> the resource is locked no matter what URL you use to access it) > >> *and* a URL lock (which means that you have a lock on > whatever might > >> appear at that URL). > >> > >> This was done for some very good reasons, since you need both kinds > >> of locks to ensure that "when you have the lock, only you > can change > >> what is at that URL". > >> > >> Unfortunately, the expected behavior of those two kinds of locks is > >> different under MOVE and DELETE, and the current WebDAV > semantics ends > >> up with (is forced into) a compromise semantics that produces > >> counterintuitive behavior from either perspective. > >> > >> In particular, one would expect a URL lock to be > unaffected by a MOVE > >> or a DELETE. If you've got a URL locked, you should be > able to move > >> anything to it or from it (or even delete it, resulting in a locked > >> null resource). This I think is the perspective Kevin was taking. > >> > >> But a resource state lock acts very differently. If you delete a > >> resource, the resource state lock should be deleted as > well (no state > >> left to lock). This is what WebDAV says. But if you MOVE > a resource, > >> you'd expect the resource state lock to remain in effect. But here > >> WebDAV goes with the URL lock semantics and says that a > MOVE deletes > >> the lock. > >> > >> Personally, I can live with most of this except for the > losing of the > >> lock on the move. Can someone point me at something in > the archives > >> that explains this decision? I didn't find it in Yaron's WBOW. > >> > >> 4) I assume that a null resource can be created via a URL > >> with a trailing > >> slash and one without. If I create one with a trailing > >> slash, can I only do > >> a MKCOL later? If no trailing slash is sent, the server > >> probably needs to > >> assume that the client might have just not sent the slash > >> and allow a MKCOL > >> or a PUT. I think the spec should state that a NULL > >> RESOURCE can be created > >> with a trailing slash or not, AND any NULL RESOURCE can > >> take a MKCOL or PUT. > >> (You already messed up some of the beauty of my server > >> with Null Resources, > >> I would hate to put even more if statements in to handle > >> the above....) > >> > >> I agree with Kevin. > >> > >> Note: These kinds of questions would not arise if > >> WebDAV would just state that /foo/x/ and /foo/x always map to > >> the same resource (JimW and I periodically go round on this > >> one :-). Even Windows and Unix agree that this is > >> the sensible approach. > >> > >> Cheers, > >> Geoff > >> > > > > > From w3c-dist-auth-request@w3.org Tue Aug 10 23:30:41 1999 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA00473 for ; Tue, 10 Aug 1999 23:30:40 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id XAA17946; Tue, 10 Aug 1999 23:21:38 -0400 (EDT) Resent-Date: Tue, 10 Aug 1999 23:21:38 -0400 (EDT) Resent-Message-Id: <199908110321.XAA17946@www19.w3.org> From: Jim Whitehead To: WebDAV WG Date: Tue, 10 Aug 1999 20:15:55 -0700 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.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Importance: Normal Subject: Oslo IETF WG Minutes Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3134 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list Content-Transfer-Encoding: 7bit Just received a message in my inbox that reminded me that the minutes from the last IETF were never sent out to the mailing list. My apologies for the delay, I should have gotten them out sooner. Major, major thanks go out to Lisa Lippert for her excellent note taking during the meeting. - Jim ---------------------- WebDAV WG Minutes Oslo IETF 45 Thursday, July 15, 1999 A meeting of the WebDAV working group was held on Thursday, July 15, 1999, from 9:00AM to 11:30AM. Geoff Clemm was the acting chair for the duration of the meeting. Minutes were recorded by Lisa Lippert. BINDING SEMANTICS ----------------- There was not enough consensus on what a direct reference should be, how it should interact with locking/collections/versioning, so this was dropped and the redirect bindings were used. New method: BIND Larry Masinter: It seemed that the model for these representations did map into the underlying architecture, is that true? Is it widespread? Do BIND and ordered collections map to existing capabilities or is it new capability that people are comfortable adding? Geoff Clemm: People want this behaviour. The proposal already takes into account some subtleties of existing implementations. Yaron Goland: Essentially it started with Unix, 'ln' type functionality. How can we best represent it in the protocol as closely as possible to existing linking functionality? On the other hand, ordered collections have apparently been implemented in very advanced doc mgmt systems, nevertheless Judy Slein did a good job of specifying this functionality. Geoff: There are a couple of other people on the ML saying this is required functionality. Geoff returned to discussing bindings: bindings allow you to bind "/a/b/foo.html" to "/a/b/bar.html", so that a resource has two names, a PROPPATCH will affect both. It does cause interesting issues with LOCK -- if you lock one, can you MOVE the other? Explanation of how a binding to a collection works -- rather than have a shadow resource created for every resource within the collection, just the collection link is created. The purpose of the collection binding is, however, to have available all the collection resources under the new link. Jules? worried about whether this was specifying the implementation, and Geoff clarified that the implementation discussion was only to ensure that a compliant implementation was possible, and any other way of implementing consistent with the protocol is valid. Geoff explained how a collection binding requires that new resources in the source collection results in new resources available under the link collection. Jules asked whether the protocol violated the reversibility of the bindings, and Geoff does not think this has been violated. Geoff discussed circular bindings: BIND /x/ to /x/circle-x/ This results in /x/ /x/y/ /x/circle-x/ /x/circle-x/y /x/circle-x/circle-x/ ... We strongly distinguish bindings, which connect a name and a resource, and a mapping, which is a connection between some legal name and a resource. The creation of one new binding can induce an infinite number of mappings, i.e. names that are now linked to a resource. A delete of a binding can remove an infinite number of mappings. Because of this, a circularity check is required. PROPFIND depth infinity does include a circularity check that only needs to be done by servers that support bindings. There is a new response code to be returned rather than return a 500 server error. Yaron pointed out that servers may just ignore this requirement as roughly equivalent. Nick Shelness: I have a hunch this breaks the model where resources know what they belong to. You might have an infinite number of membership. Geoff thinks this is OK though. Nick will think more about this. Question: Why do we even allow circularity? Geoff: it was argued that it was tougher to prevent circularity than to deal with it, but the more important argument is that it should be possible to just classify a collection as part of a set which contains itself, that there were contains-itself relationships that people wanted to model. Example from "include" files: a collection which contained all the files included might include itself. These might be excluded by some kind of #ifdef behaviour... Everybody in the design team had their own favourite example of why circularity should be allowed (otherwise would be faked in some way more painful than asking the server to do the circularity check) Yaron: We've created a situation where any PROPFIND depth infinity request will generate an error if there is a circularity. Geoff: We thought of some custom stuff to tell the server to "ignore circularities", but figured it's most useful for clients to be able to deal with the circularity error by controling depth more carefully in requests. Yaron: These relationships have kind of poisoned effects. E.g. Depth infinity DASL requests will be the rule, and these will now result in errors because of a cycle somewhere, and that seems problematic. I would like to see some kind of discussion of what circularities would result in for other areas of DAV, like searching, versioning, etc. Geoff: Yes, we wanted to open this up for discussion. If anybody else requires this feature, add your vote. Question: Note that circular references might be much more complex, and involve many levels before the circularity is discoverable. This is a hard problem to find out when the binding is created: a complete tree traversal would be required every time a reference is created. It might make sense, when doing these traversals, to indicate to the server not to traverse links, just like in Unix. Geoff: This was one of the reasons for removing support for direct bindings. There is no difference between the original URL to a resource and the new bound URL, they are both bindings to the actual resource. The result is that instead of paying on deep traversals, you pay on every binding. To require the server to do this check on every creation of a binding was actually the more serious implementation check than to do this only on PROPFIND depth infinity. Lisa Lippert: The price for not checking when the binding is created could me more than we can know now, covering more than just PROPFIND depth infinity. Geoff: Yes. Yaron: MOVE and COPY are like this. Geoff: MOVE is very like BIND, it just creates a new link between a name and a resource. If anybody else can identify the methods which concern them... Yaron: That's why I'm pounding on the model. I think we just have to say we're running with scissors with this feature. John Stracke: But since a MOVE is a COPY followed by a DELETE... Yaron: NO. In the webDAV spec, MOVE is not defined as a copy followed by a delete. We said that a MOVE is logically equivalent to an atomically performed (with fixup) COPY then DELETE. It was an attempt to inherit certain behaviours that applied to COPY, without specifying implementation. We knew that certain servers would end up deleting a resource (i.e. in the case of a MOVE from one server to another). We needed a way to say that if a MOVE operation implementation did involve a DELETE, it would operate in a certain way to comply with requirements from the military. Geoff: I need to explain how MOVE works with respect to bindings. A MOVE is, in the case of a binding, like a BIND followed by a DELETE. The difference is in all the other bindings to the thing that is being moved: the other bindings (other than the ones being moved) are unchanged; they continue to have the same name and point to the same resource. This is important, because the result does not involve creating a brand new copy of the resource, which is what a COPY then DELETE would cause. Summary: the core of bindings is pretty simple, but it has some interesting implications. Modulo a few problems, the WebDAV base has been a good one to work on, it's a very effective base to work on for both the design teams I'm on. PROCESS QUESTIONS ----------------- Question: Do you feel the ordering sections of advanced collections are complete? Geoff: We (the authors, at least) only agree that clients should be able to tell the server that this should be after that. We don't know what server-maintained orderings are or mean. Client-defined orderings are less controversial. Question: It sounds like there are actually three independent specifications in advanced collections, at different levels of completion... Geoff: Yes, the status of ordering is that not many cared, and the few who did only agree on client-side ordering. It would be a shame to hold up the rest of the protocol while we're resolving that issue. There's less administrative need to separate the redirect references from the binding functionality; on the other hand their connection is gratuitous. Keith: Just put redirect references in a separate document. Larry: Historically, redirect references were a response to requirements for collection-based functionality. Geoff: I am happy to follow Keith's direction so if anybody else has a problem take it up in mail. Are there other issues with respect to these specifications -- is it OK for them to fall under the "finishing up WebDAV" WG? Keith: Is it close to being done? Geoff: Yes Yaron: No Keith: Take 3 months to finish, then decide what to do, but don't go under the assumption that the current WebDAV WG will continue to exist to do this. I bet you could get the bindings done in under 3 months. Do them in the order of how you think you can get them done. Larry: Just split up the document and last-call the pieces. Geoff: Whichever are done in 3 months fall under this WG... Larry: It's not that there is less consensus for ordering, there are just fewer people interested in seeing this functionality. That doesn't mean it will drag out any longer than bindings. Geoff: Any other issues? Larry: There are two elements of functionality which I think need to be worked out before we can say we've accomplished a protocol that can be used to do distributed authoring: - variants - compound documents This doesn't meet the charter until we've resolved those. Keith: A lot of people have been chewing over those for decades. I'm not sure you can do anything. Larry: I'm interested in pursuing protocol elements that would further this functionality, whether within this WG or elsewhere. This could be done in DMA. Yaron: I would much rather this happen in IETF. We would have to do a lot of work before the work could continue in DMA with the same kind of openness. Geoff: One could use the same gating function for a subset of the versioning work that is of sufficient maturity that it could be closed off in 3 months. Keith: No. *** Meeting Adjourned *** From w3c-dist-auth-request@w3.org Wed Aug 11 13:57:17 1999 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03439 for ; Wed, 11 Aug 1999 13:57:15 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id NAA04415; Wed, 11 Aug 1999 13:46:45 -0400 (EDT) Resent-Date: Wed, 11 Aug 1999 13:46:45 -0400 (EDT) Resent-Message-Id: <199908111746.NAA04415@www19.w3.org> Message-ID: <37B1B6EE.E6CCB844@ecal.com> Date: Wed, 11 Aug 1999 13:46:22 -0400 From: John Stracke X-Mailer: Mozilla 4.6 [en] (X11; I; Linux 2.0.36 i586) X-Accept-Language: en MIME-Version: 1.0 To: WebDAV WG Content-Type: multipart/mixed; boundary="------------1F06265F3863E764881FA48F" Subject: Proposal for narrowing PROPFINDs a bit Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3135 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list This is a multi-part message in MIME format. --------------1F06265F3863E764881FA48F Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit I'm working on a WebDAV-based app (it's not a normal content management scenario, but DAV functionality turned out to be useful), and I encountered a case where I needed to extend PROPFIND so that it could list all the properties in a given namespace or namespaces. It occurred to me that such a mechanism might be more generally applicable, so I've written up a Draft (attached; also available at ) proposing it. I'd appreciate any comments. (I'm afraid I can't talk about why I needed this just yet, but I did include a couple of other scenarios in the Draft.) -- /=============================================================\ |John Stracke | My opinions are my own | S/MIME & HTML OK | |francis@ecal.com|============================================| |Chief Scientist | NT's lack of reliability is only surpassed | |eCal Corp. | by its lack of scalability. -- John Kirch | \=============================================================/ --------------1F06265F3863E764881FA48F Content-Type: text/plain; charset=us-ascii; name="draft-stracke-webdav-propfind-space-00.txt" Content-Disposition: inline; filename="draft-stracke-webdav-propfind-space-00.txt" Content-Transfer-Encoding: 7bit Network Working Group J. Stracke, eCal Corp. INTERNET DRAFT Expires April, 2000 August 10, 1999 WebDAV PROPFIND Extension To List Specified Namespaces 1 Status of this Document This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as ``work in progress.'' The list of current Internet-Drafts can be accessed at The list of Internet-Draft Shadow Directories can be accessed at Distribution of this document is unlimited. Please send comments to francis@ecal.com or to the w3c-dist-auth@w3.org discussion list. 2 Abstract This document specifies an extension to the [WEBDAV] PROPFIND method to permit a WebDAV client to request all properties which belong to a specified namespace or namespaces. 3 Introduction This document specifies an extension to the [WEBDAV] PROPFIND method to permit a WebDAV client to request all properties which belong to a specified namespace or namespaces. A WebDAV application using a custom namespace for application-specific data may occasionally need to use PROPFIND to list all a resource's properties from that namespace. (Similarly, a WebDAV client might need to know all DAV: properties, but not care about non-standard properties.) In such a case, the client must choose between the element, which will retrieve all properties on the resource, and the element, which will retrieve specified properties only. The problem with is that the resource may have many properties from other namespaces, in which the application is not interested. The problem with is that the client may not know all the property names which may be present (for example, if the client is too general-purpose to permit it to be configured with the list of property names, or if property name munging is being used). A third choice would be to use Stracke [Page 1] INTERNET-DRAFT WebDAV PROPFIND Namespace List August 10, 1999 to list all the resource's properties without their contents, then use with just the properties in the desired namespace; the problem with this approach is that it requires an extra HTTP request. This document proposes a middle ground, an extension to which provides a list of namespaces to search. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALLNOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and"OPTIONAL" in this document are to be interpreted as described in [MUSTS] . 4 Extension definition Two new XML elements are proposed, and . In the idiom of [WEBDAV]: 4.1 namespaces XML Element Name: namespaces Namespace: DAV: Purpose: The namespaces XML element specifies that the enclosing allprop or propname element applies only to properties belonging to the namespaces listed in the enclosed namespace elements. 4.2 namespace XML Element Name: namespace Namespace: DAV: Purpose: The namespace XML element specifies a namespace in the namespaces list. appears inside , and has a single attribute, uri, the URI of the namespace. 5 Examples 5.1 Fetching all DAV: properties Request: PROPFIND /index.html HTTP/1.1 Host: www.example.com Content-Length: xxxx Content-Type: text/xml Stracke [Page 2] INTERNET-DRAFT WebDAV PROPFIND Namespace List August 10, 1999 Response: HTTP/1.1 200 OK Content-Type: text/xml Content-Length: xxxx 1999-08-11T12:12:12Z Example.com, The Fictious Site! 17 text/html xyzzy 1999-08-11T12:12:14Z 5.2 Listing names of properties in two namespaces Request: PROPFIND /index.html HTTP/1.1 Host: www.example.com Content-Length: xxxx Content-Type: text/xml Response: 6 Compatibility Considerations Section 14 of [WEBDAV] specifies: "All DAV compliant resources MUST ignore any unknown XML element and all its children encountered while processing a DAV method that uses XML as its command language." As a result, a client which uses on a server which does not support it will get the base-level DAV behavior (listing all properties), exactly as if it had issued a base-level DAV request. Therefore, a client which sends PROPFIND requests using MUST accept responses which include properties not in the listed namespace(s). Of course, it is always risky assuming that all implementations of a young standard adhere to all points of the standard. In this case, the risk is mitigated by the fact that section 23.3.2.2 of [WEBDAV] presents a (hypothetical) similar extension, , and states: "If the previous example were submitted to a server unfamiliar with leave-out, the only result would be that the leave-out element would be ignored and a propname would be executed." Nevertheless, since there may be some servers which, for whatever reason, violate this prescription (say, if they attempt to validate the XML request against the DTD in section 23.2 of [WEBDAV] ), a client which uses SHOULD be aware that it may receive a 400 Bad Request from such a server, and SHOULD be able to retry the request without using . 7 Internationalization Considerations This proposal builds on [WEBDAV], and inherits its internationalizability. 8 IANA Considerations This proposal does not introduce any new IANA considerations, since it does not specify any new namespaces (in the general sense), but merely uses existing ones. 9 Security Considerations For a server, this proposal does not introduce any new security considerations over those of [WEBDAV], since the information which is Stracke [Page 4] INTERNET-DRAFT WebDAV PROPFIND Namespace List August 10, 1999 exposed is already available. There might be privacy considerations for a client, since telling the server which namespaces one wishes to search does reveal some information. Implementors must balance this concern against the efficiency gains this proposal offers. 10 Copyright The following copyright notice is copied from RFC 2026 [Bradner, 1996], section 10.4, and describes the applicable copyright for this document. Copyright (C) The Internet Society April 5, 1998. All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assignees. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 11 Intellectual Property The following notice is copied from RFC 2026 [Bradner, 1996], section 10.4, and describes the position of the IETF concerning intellectual property claims made against this document. The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use other technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of Stracke [Page 5] INTERNET-DRAFT WebDAV PROPFIND Namespace List August 10, 1999 licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. 12 Acknowledgements Some of the PROPFIND syntax in the examples was copied from examples in [WEBDAV]. 13 References [WEBDAV] Y. Y. Goland, E. J. Whitehead, Jr., A. Faizi, S. R. Carter, D. Jensen, "Extensions for Distributed Authoring on the World Wide Web - WebDAV." RFC 2518. Microsoft, U.C. Irvine, Netscape, Novell. April, 1998. [MUSTS] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels," BCP 14, RFC 2119, Harvard University, March 1997. 14 Author's Address J. Stracke eCal Corp. 234 N. Columbus Blvd., 2nd Floor francis@ecal.com Stracke [Page 6] --------------1F06265F3863E764881FA48F-- From w3c-dist-auth-request@w3.org Wed Aug 11 14:24:19 1999 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03842 for ; Wed, 11 Aug 1999 14:24:18 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id OAA04928; Wed, 11 Aug 1999 14:15:57 -0400 (EDT) Resent-Date: Wed, 11 Aug 1999 14:15:57 -0400 (EDT) Resent-Message-Id: <199908111815.OAA04928@www19.w3.org> Message-ID: <37B1BDCE.8E2823A0@ecal.com> Date: Wed, 11 Aug 1999 14:15:42 -0400 From: John Stracke X-Mailer: Mozilla 4.6 [en] (X11; I; Linux 2.0.36 i586) X-Accept-Language: en MIME-Version: 1.0 To: WebDAV WG References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [Moderator Action] Questions on Webdav Servers Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3136 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list Content-Transfer-Encoding: 7bit (I'm replying to this rather late, so I'll do some excessive quoting so people can get the context.) Jim Whitehead wrote: > > 2) Section 9.6 "...If the Overwrite Header is not included in a COPY/MOVE > > request then the resource MUST treat the request as if it had an overwrite > > header of value 'T'". This seems backwards to me (in fact I had it coded > > the otherway until yesterday), since the overwrite will do a DELETE, is it > > not safer to assume a header of "F"??? > > Well, I'll note that you brought this up previously: > http://lists.w3.org/Archives/Public/w3c-dist-auth/1999AprJun/0053.html > > And it has been noted on the issues list (issue: > OVERWRITE_DELETE_TOO_STRONG): > http://www.ics.uci.edu/pub/ietf/webdav/protocol/issues.html > > I'm certainly willing to see this change as we move from Proposed to Draft > Standard. For now, I'd expect user agents to protect users from > unexpectedly large effects. The problem with changing it as the standard moves forward is that we run the risk that existing clients will probably omit the Overwrite header when they mean T, and people's COPY/MOVEs will start failing when the servers switch standards. I'd suggest it'd be best to leave this alone. -- /=============================================================\ |John Stracke | My opinions are my own | S/MIME & HTML OK | |francis@ecal.com|============================================| |Chief Scientist | NT's lack of reliability is only surpassed | |eCal Corp. | by its lack of scalability. -- John Kirch | \=============================================================/ From w3c-dist-auth-request@w3.org Wed Aug 11 14:29:35 1999 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03954 for ; Wed, 11 Aug 1999 14:29:34 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id OAA05151; Wed, 11 Aug 1999 14:21:06 -0400 (EDT) Resent-Date: Wed, 11 Aug 1999 14:21:06 -0400 (EDT) Resent-Message-Id: <199908111821.OAA05151@www19.w3.org> Message-ID: <37B1BF03.CC9D1B34@ecal.com> Date: Wed, 11 Aug 1999 14:20:51 -0400 From: John Stracke X-Mailer: Mozilla 4.6 [en] (X11; I; Linux 2.0.36 i586) X-Accept-Language: en MIME-Version: 1.0 To: WebDAV WG References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: WebDAV methods: safe and idempotent Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3137 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list Content-Transfer-Encoding: 7bit Jim Whitehead wrote: > Off-list, I was asked about the "idempotence" and "safety" of WebDAV > methods [...] (Basically, "safe" > = does not harm the state of the resource, "idempotent" = the effect of N > > 0 identical requests is the same as a single request) [...] > > PROPFIND: safe, idempotent > PROPPATCH: unsafe, idempotent ...*provided* you're not using any funky live properties. Live properties are behavior, not state, so they have safeness and idempotency, too. So, really, you have to assume that both PROPFIND and PROPPATCH are unsafe and non-idempotent unless you know the safeness and idempotency of all the properties in use. (This is the same issue as CGIs in base HTTP/1.1; a CGI script could be built that reacts unsafely to GET, but it wouldn't be HTTP/1.1-compliant; it's supposed to use POST if it's unsafe. But we don't have PROPFIND-GET and PROPFIND-POST.) -- /=============================================================\ |John Stracke | My opinions are my own | S/MIME & HTML OK | |francis@ecal.com|============================================| |Chief Scientist | NT's lack of reliability is only surpassed | |eCal Corp. | by its lack of scalability. -- John Kirch | \=============================================================/ From w3c-dist-auth-request@w3.org Wed Aug 11 16:42:52 1999 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA06599 for ; Wed, 11 Aug 1999 16:42:52 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id QAA09082; Wed, 11 Aug 1999 16:33:34 -0400 (EDT) Resent-Date: Wed, 11 Aug 1999 16:33:34 -0400 (EDT) Resent-Message-Id: <199908112033.QAA09082@www19.w3.org> Message-ID: <011201bee438$3d28fb30$0d1b15ac@aftershock.atria.com> From: "Geoffrey Clemm" To: "Jim Whitehead" , "WebDAV WG" Date: Wed, 11 Aug 1999 16:29:36 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.3110.5 X-Mimeole: Produced By Microsoft MimeOLE V4.72.3110.3 Subject: Re: [Moderator Action] Questions on Webdav Servers Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3138 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list Content-Transfer-Encoding: 7bit From: Jim Whitehead >Kevin Wiggen writes: > ... >> 3) MOVE/COPY to a destination that is locked. 8.10.5 states "... a >> successful DELETE of a resource MUST cause all of its locks to be >> removed." >> and 8.8.4 states that overwrite set to T will do a DELETE.... >> Then will the >> LOCK on the destination be lost?? This seems wrong to me. If the >> destination is LOCKED, then after a MOVE/COPY which might delete the >> resource, I would assume the resource is still locked. > >If the destination of a COPY/MOVE is locked, and you submit the lock token >of the destination lock in the If header, then the intent of RFC 2518 is >that the destination resource should be locked. This is stated in the >second paragraph of section 7.7. I agree that section 7.7 makes it clear that if you are *inheriting* a lock from a collection that *contains* the destination, then that inherited lock is valid following a COPY/MOVE. This makes sense since the locked collection still exists following the COPY/MOVE. But I do not see anything in 7.7 (or in 7.5) that either states or implies that a lock that was on the destination itself remains following the COPY/MOVE. So as currently written, I believe that the spec supports Kevin's interpretation. Cheers, Geoff From w3c-dist-auth-request@w3.org Fri Aug 13 15:40:01 1999 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09262 for ; Fri, 13 Aug 1999 15:40:01 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id PAA04024; Fri, 13 Aug 1999 15:27:29 -0400 (EDT) Resent-Date: Fri, 13 Aug 1999 15:27:29 -0400 (EDT) Resent-Message-Id: <199908131927.PAA04024@www19.w3.org> From: "Larry Masinter" To: "John Stracke" , "WebDAV WG" Date: Fri, 13 Aug 1999 12:26:47 PDT Message-ID: <002601bee5c1$c8b4e620$79d3000d@copper.parc.xerox.com> 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 8.5, Build 4.71.2173.0 In-Reply-To: <37B1BF03.CC9D1B34@ecal.com> X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Importance: Normal Subject: RE: WebDAV methods: safe and idempotent Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3139 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list Content-Transfer-Encoding: 7bit > > PROPFIND: safe, idempotent > > PROPPATCH: unsafe, idempotent > > ...*provided* you're not using any funky live properties. Live properties are > behavior, not state, so they have safeness and idempotency, too. So, really, > you have to assume that both PROPFIND and PROPPATCH are unsafe and > non-idempotent unless you know the safeness and idempotency of all the > properties in use. I think it's more appropriate to define 'live properties' such that they have the same relationship to safety and idempotency of PROPFIND and PROPPATCH as 'resources' have to GET and PUT. That is: even though the property is live, PROPFIND of any property SHOULD be safe and idempotent, and PROPPATCH should be idempotent. > (This is the same issue as CGIs in base HTTP/1.1; a CGI script could be built > that reacts unsafely to GET, but it wouldn't be HTTP/1.1-compliant; it's > supposed to use POST if it's unsafe. But we don't have PROPFIND-GET and > PROPFIND-POST.) We should make the correspondence of PROPFIND-GET and PROPPATCH-PUT (not POST). Not having done so is an flaw in the WebDAV spec that SHOULD be corrected, not celebrated. Larry From w3c-dist-auth-request@w3.org Fri Aug 13 17:22:17 1999 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10418 for ; Fri, 13 Aug 1999 17:22:17 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id RAA06380; Fri, 13 Aug 1999 17:13:04 -0400 (EDT) Resent-Date: Fri, 13 Aug 1999 17:13:04 -0400 (EDT) Resent-Message-Id: <199908132113.RAA06380@www19.w3.org> From: "Kevin Wiggen" To: , Date: Fri, 13 Aug 1999 14:07:49 -0700 Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00B0_01BEE595.3A08DDE0" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3155.0 Subject: Xythos announces Sharemation.com Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3140 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list This is a multi-part message in MIME format. ------=_NextPart_000_00B0_01BEE595.3A08DDE0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit I am sad to announce that the Xythos webdav server http://216.102.212.251/~webdav will be decommissioned in the next few weeks. But I am proud to announce Sharemation.com (www.sharemation.com) this is a fully featured Webdav Level 2 server powered by Xythos. All the same great functionality, plus even more. Go to Sharemation and sign up for your FREE account. As always, if you have any questions or problems with our server, please let me know.... Kevin Wiggen ------=_NextPart_000_00B0_01BEE595.3A08DDE0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
I am = sad to announce=20 that the Xythos webdav server http://216.102.212.251/~webdav will be=20 decommissioned in the next few weeks.
 
But I = am proud to=20 announce Sharemation.com (www.sharemation.com) this is a = fully=20 featured Webdav Level 2 server powered by Xythos.  All the same = great=20 functionality, plus even more.  Go to Sharemation and sign up for = your FREE=20 account.
 
As = always, if you=20 have any questions or problems with our server, please let me=20 know....
 
Kevin=20 Wiggen
------=_NextPart_000_00B0_01BEE595.3A08DDE0-- From w3c-dist-auth-request@w3.org Fri Aug 13 19:05:12 1999 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA11262 for ; Fri, 13 Aug 1999 19:05:12 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id SAA07702; Fri, 13 Aug 1999 18:56:15 -0400 (EDT) Resent-Date: Fri, 13 Aug 1999 18:56:15 -0400 (EDT) Resent-Message-Id: <199908132256.SAA07702@www19.w3.org> From: "Kevin Wiggen" To: , Date: Fri, 13 Aug 1999 15:50:59 -0700 Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00C7_01BEE5A3.A3546680" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3155.0 Subject: Note on accessing Sharemation via Webdav Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3141 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list This is a multi-part message in MIME format. ------=_NextPart_000_00C7_01BEE5A3.A3546680 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Unlike http://216.102.212.251/~webdav, where the access permissions were set to Public READ, WRITE, DELETE, your new accounts on Sharemation will not automatically have these permissions set. By default, the server sets the permissions to only accessible from the owner of the account. In order to run our security, we use a number of cookies to set user context. In order to run a Webdav client against our server, you need to take those cookies into account (like IE and Office2000). That being said, you can turn an area in your Sharemation account into a PUBLIC area. Simply create a folder, and set the permissions for Public to READ, WRITE, DELETE (this can be done on the Sharemation Web site). This will allow you to run webdav clients without the need for our security checks. Example: I could create a folder, webdav, under my home account. Using the Sharemation Web site, I can change the permissions on that folder to be PUBLIC READ, WRITE, and DELETE. I can then run my webdav client against http://www.sharemation.com/~kwiggen/webdav without having to worry about the security context. Opening up an area to PUBLIC might be dangerous, as someone might fill up your 20M of space with junk. In order to alleviate this, you might want to set the Quota on the webdav folder (also done on the Sharemation Web site), to something small (like 1 Meg). This will keep the area for that folder at 1M while the rest of your account (your non publicly writeable part) will run with the 20M quota. Hope this helps, Kevin ------=_NextPart_000_00C7_01BEE5A3.A3546680 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Unlike = http://216.102.212.251/~webdav, where=20 the access permissions were set to Public READ, WRITE, DELETE, your new = accounts=20 on Sharemation will not automatically have these permissions set.  = By=20 default, the server sets the permissions to only accessible from the = owner of=20 the account.
 
In = order to run our=20 security, we use a number of cookies to set user context.  In order = to run=20 a Webdav client against our server, you need to take those cookies into = account=20 (like IE and Office2000).
 
That = being said, you=20 can turn an area in your Sharemation account into a PUBLIC area.  = Simply=20 create a folder, and set the permissions for Public to READ, WRITE, = DELETE (this=20 can be done on the Sharemation Web site).  This will allow you to = run=20 webdav clients without the need for our security = checks.
 
Example:
 
I = could create a=20 folder, webdav, under my home account.  Using the Sharemation Web = site, I=20 can change the permissions on that folder to be PUBLIC READ, WRITE, and=20 DELETE.  I can then run my webdav client against http://www.sharematio= n.com/~kwiggen/webdav=20 without having to worry about the security context.
 
Opening up an area=20 to PUBLIC might be dangerous, as someone might fill up your 20M of space = with=20 junk.  In order to alleviate this, you might want to set the Quota = on the=20 webdav folder (also done on the Sharemation Web site), to something = small (like=20 1 Meg).  This will keep the area for that folder at 1M while the = rest of=20 your account (your non publicly writeable part) will run with the 20M=20 quota.
 
Hope = this=20 helps,
Kevin
------=_NextPart_000_00C7_01BEE5A3.A3546680-- From w3c-dist-auth-request@w3.org Fri Aug 13 20:33:13 1999 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA12111 for ; Fri, 13 Aug 1999 20:33:13 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id UAA12246; Fri, 13 Aug 1999 20:24:08 -0400 (EDT) Resent-Date: Fri, 13 Aug 1999 20:24:08 -0400 (EDT) Resent-Message-Id: <199908140024.UAA12246@www19.w3.org> From: ccjason@us.ibm.com X-Lotus-FromDomain: IBMUS To: "Geoffrey M. Clemm" cc: w3c-dist-auth@w3.org Message-ID: <852567CD.00022EA2.00@D51MTA07.pok.ibm.com> Date: Fri, 13 Aug 1999 20:23:04 -0400 Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Subject: Re: FW: Circular Bindings Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3142 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list ... this also reminds me that with AdvColl, it is possible that a portion of the source tree and the destination might be common. And that initial deletion phase of the COPY might actually essentially delete a portion of the source tree. It's probably a red herring, but it's probably also something we should mention in the spec. I agree that it is something that should be explicitly mentioned (and disagree that it is a red herring :-). In particular, I'd suggest some words to the effect that a COPY should be semantically equivalent to a COPY to a temporary URL (that identifies a null resource) followed by a MOVE from the temporary URL to the destination URL. Geoff, I don't understand your wording. Whoops. Yes, I do. The COPY would create a new instance of the resources that were in the source tree. The MOVE would UNBIND the destination and rebind the newly created copy to the destination URI. (Am I using our "bind" vocabulary/object-model correctly? :-)) Got it. Of course, that's the AdvColl. way of explaining it. And it still has this odd behavior with the the DELETE phase if we use your wording with RFC2518... so we still should flag it there. Hopefully we can move to AdvColl. and not worry too much about this. (It's only a problem for AdvColl if the UNBIND of the MOVE phase destroys a binding that happens to be in the source tree. Fortunately that one binding is the only thing that gets destroyed (at least explicitly) as a result of the COPY. I said explicitly because a bunch of resources might lose their only mapping(s) as a result of that unbind and thus become inaccessable in the absense of versioning.) The caveat is... even with AdvColl, I think we need to define what COPY/MOVE do across machines that don't cooperate on bindings. Your definition of COPY seems to work across machines as long as we say the COPY phase copies to a temporary location on the *destination* machine. MOVE across machines is another matter. We should say if we allow MOVE if the intended semantics can't be achieved. Or if best effort is acceptable. Or if the client can specify if best-effort is acceptable. From w3c-dist-auth-request@w3.org Fri Aug 13 22:32:53 1999 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA14645 for ; Fri, 13 Aug 1999 22:32:53 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id WAA20786; Fri, 13 Aug 1999 22:19:34 -0400 (EDT) Resent-Date: Fri, 13 Aug 1999 22:19:34 -0400 (EDT) Resent-Message-Id: <199908140219.WAA20786@www19.w3.org> From: ccjason@us.ibm.com X-Lotus-FromDomain: IBMUS To: w3c-dist-auth@w3.org Message-ID: <852567CD.000CC1E4.00@D51MTA07.pok.ibm.com> Date: Fri, 13 Aug 1999 22:18:36 -0400 Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Subject: Multiple exclusive locks on a resource Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3144 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list Just another LOCK issue that I'm about to add to the list... A resource can only have one exclusive lock on it right? Well, what about if a principle locks (with depth) two trees of resources... but those two trees have some resources in common? That means those common resources would have two exclusive locks on them. Illegal, right? But the same principle owns both locks mind you. It would sure be nice to allow this... at least from this perspective. If we did not, it would sure be tedious to lock both trees. I haven't thought of the ramifications yet. J. ------------------------------------------ Phone: 914-784-7569, ccjason@us.ibm.com From w3c-dist-auth-request@w3.org Fri Aug 13 22:33:15 1999 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA14677 for ; Fri, 13 Aug 1999 22:33:15 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id WAA20737; Fri, 13 Aug 1999 22:18:01 -0400 (EDT) Resent-Date: Fri, 13 Aug 1999 22:18:01 -0400 (EDT) Resent-Message-Id: <199908140218.WAA20737@www19.w3.org> From: ccjason@us.ibm.com X-Lotus-FromDomain: IBMUS To: "Kevin Wiggen" cc: "Slein, Judith A" , "'WebDAV'" Message-ID: <852567CD.000C9684.00@D51MTA07.pok.ibm.com> Date: Fri, 13 Aug 1999 22:16:42 -0400 Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Subject: RE: LOCK Scenarios Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3143 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list In case 9 and 10 I had arguments that the resource R, and not the namespace should be locked. This contradicts infinity locks a little, as they lose and gain members on movement in the namespace. So I guess I am saying locks should LOCK the resource, but should be namespace aware :) It took a while to read it all, but I think I agree with everything you said for scenarios 1 - 8. It's difficult to express succinctly. I think it is after we get some vocabulary. Lets call the URI at which the LOCK was placed the "lock URI". The LOCK URI has special properties. First of all, it is "protected". These scenarios don't cover that prroperty, but the Adv. Collection spec does. It means that among other things, that it's parent nodes (Is that what we call them?) can not go through name space manipulations that would cause the locked URI to disappear. That is... if /a/b/c is locked, then /a/'s 'b' binding is not allowed to change and to therefore take the URI "/a/b/c" out of existance. I'll leave that fuzzy for now. If we dig further, I'm sure we can find some complications in there. The idea behind protection is that we protect the URI so that someone that doesn't have a lock can't make the LOCK URI mapping go away. The thinking is that we are locking that URI because we're going to be using that URI to perform some operation on the resource. If some other principal can make that URI go away or map to something else, then we aren't happy. (A URI is our only way of address resources right now.) In addition, the lock binds most tightly to the LOCK URI. Then secondarily to the resource at the LOCK URI. That means if you change the resource at that URI, the new resource gets the lock that was set to the LOCK URI. (This what your scenarios seem to suggest and it sounds like it might be what users want.) Next... if the lock has depth... various descendent (vocab?) URI's are locked. (We need vocabulary to distinguish this "locked" from what we are talking about at the LOCK URI.) And the resources at those URI's are locked. The fact that these resources are locked also means that they are locked if accessed through other URI's too... but that those URI's aren't necessarily "protected". Yes, this is a totally fuzzy definition. I'll come up with a detailed boring one later if this one shows promise. Anyway, I think this is the definition that you used for scenarios 1-8. Now let me move on to 9 and 10.... Firstly, unless I misunderstand you, I think I disagree with what you've said above about 9 and 10. This seems to be in disagreement with 1-8. I believe that in the first scenarios, the LOCK URI is the primary location of the lock... not necessarily the resource at that URI. (Yes, this is in conflict with what we've been thinking with AdvCollections, but I want to run with your proposal which you demonstrated with scenarios 1 - 8...) The resource IS locked, but only by virtue of it's current relationship to the LOCK URI. The fact that the resource is locked does mean it (the resource itself) is locked at other mappings too. 9. The source resource was locked through one mapping, and a MOVE is attempted through a different mapping. 9a. /a/b and /c/d map to R. /a/ is locked. MOVE /c/d to /x/y. Since the resource R is locked, if the correct lock token for /c/d is given (the lock token for the lock holding R), then the move occurs. Since /a/b still points to R, /x/y is still locked via /a's lock. I agree. 9b. /a/b and /c/d map to R. /a/ is not locked, but /a/b is. MOVE /c/d to /x/y. Again the MOVE succeeds if the token for R is given, the resource is still locked by /a/b I don't see why a token is necessary.. Yes R is locked, but the move is an operation on the state of it's parent, not it. (I assume that /a/ and /c/ aren't the same resource.) That means the /c/d URI is not protected. The /a/b URI is, but the MOVE isn't threatening that mapping. -- Besides the token issue, I agree. 10. The destination resource was locked through one mapping, and a MOVE is attempted through a different mapping. 10a. /w/x and /y/z map to R. /w/ is locked. MOVE /a/b to /y/z. If correct lock token for R is given (If header with a tagged list of /y/z and the correct token) the move completes. Since /w is locking the resource R, it continues to do so I disagree about the lock token for the same reason as above... unless we're possibly talking about a depth lock token. Let's first assume we're not. Moving /a/b to /y/z is changing the state of the collections /a/ and /y/. (At least that's how we have been thinking about it in the AdvColl discussions.) Since neither of them is locked, the lock is irrelevant in the example. (BTW, I assume /w/ and /y/ are not two mappings for the same collection.) Now if it's a depth lock.... which I think you assumed... In that case, R is locked by virtue of being accessable via /w/x. But I assert that that lock remains irrelevant. When all the operations are through, resource R remains accessible via /w/x and R remains locked. Nothing attempted threatens to break the lock. It just becomes accessible through different mappings, but the mappings that were lost were not PROTECTED by that particular lock since the LOCK URI was not involved. I agree about everything else besides the token. 10b. /w/x and /y/z map to R. /w/ is not locked, but /w/x is. MOVE /a/b to /y/z. Given the correct lock tokens (See above), the move succeeds. The lock is then lost according to number 2 above. Again I would argue that the lock on /w/x would still be there with the same logic as in number 2 above Once again, I say the lock tokens aren't relevant here. Nor is the lock. R continues to exist. It's state hasn't changed. And the LOCK URI wasn't threatend by the move. 11) - One thing I want to point out is a combination of 9 and 10. Both the source and the destination are locked. By different locks. Exclusive locks. /a/b and /c/d map to R. /a/ is depth locked. /x/ is depth locked. move /c/d to /x/y In all the similar cases above, I believe we said it succeeded. But in this combination, I believe it fails. Why? Because if it succeeded, R would be accessable via /a/b and /x/y. but both /a/ and /x/ are depth locked. Exclusively. That means R somehow would have inherited two exclusive locks.. That sounds like something we have to disallow. :-) (Well, maybe. I'll make another post on a twist on this in a sec.) Anyway, Kevin, I think you have a viable proposal. I think most of us were expecting a resource to be the primary holder of a lock. That seems like something that would be easy to understand and would seem like what one would want on first blush. But I think you've suggested is that what clients might prefer is that the LOCK-URI own the lock... and whether a resource is locked is determined if the resource that has a mapping the is or descends from that URI. As resources are moved around they might be added or removed from the lock as their mappings change. And even the resource mapped to the LOCK-URI itself can change... and thus be added or removed from the lock. I think we should keep your proposal on the table. And probably define it more rigorously. J. From w3c-dist-auth-request@w3.org Sun Aug 15 19:27:34 1999 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA28176 for ; Sun, 15 Aug 1999 19:27:34 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id TAA14816; Sun, 15 Aug 1999 19:16:45 -0400 (EDT) Resent-Date: Sun, 15 Aug 1999 19:16:45 -0400 (EDT) Resent-Message-Id: <199908152316.TAA14816@www19.w3.org> From: Jim Whitehead To: ccjason@us.ibm.com, w3c-dist-auth@w3.org MMDF-Warning: Parse error in original version of preceding line at paris.ics.uci.edu Date: Sun, 15 Aug 1999 16:08:40 -0700 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.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 In-Reply-To: <852567CD.000CC1E4.00@D51MTA07.pok.ibm.com> Importance: Normal Subject: RE: Multiple exclusive locks on a resource Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3145 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list Content-Transfer-Encoding: 7bit My recollection is that this issue was discussed during one of the face to face meetings, and the resultion was that the second lock request would just fail. In my view, this is an extremely uncommon scenario, and it isn't worth adding complexity to either implementations or the standard to handle it well. The complexity of expanding the existing lock just doesn't seem to be worth it. - Jim > Just another LOCK issue that I'm about to add to the list... > > A resource can only have one exclusive lock on it right? > > Well, what about if a principle locks (with depth) two trees of > resources... but > those two trees have some resources in common? That means those common > resources would have two exclusive locks on them. Illegal, > right? But the same > principle owns both locks mind you. It would sure be nice to > allow this... at > least from this perspective. If we did not, it would sure be > tedious to lock > both trees. > > I haven't thought of the ramifications yet. > > J. > > ------------------------------------------ > Phone: 914-784-7569, ccjason@us.ibm.com > > From w3c-dist-auth-request@w3.org Sun Aug 15 19:27:36 1999 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA28187 for ; Sun, 15 Aug 1999 19:27:36 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id TAA14856; Sun, 15 Aug 1999 19:17:17 -0400 (EDT) Resent-Date: Sun, 15 Aug 1999 19:17:17 -0400 (EDT) Resent-Message-Id: <199908152317.TAA14856@www19.w3.org> From: Jim Whitehead To: WebDAV WG Date: Sun, 15 Aug 1999 16:08:44 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Importance: Normal Subject: FW: [Moderator Action] RE: WebDAV: UUID/GUID - Please check my math! Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3147 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list Content-Transfer-Encoding: 7bit Also caught by the spam filter. - Jim P.S. - Dennis -- email I send to infonuovo@email.com is bouncing... -----Original Message----- From: Dennis E. Hamilton [mailto:orcmid@email.msn.com]On Behalf Of infonuovo@email.com Sent: Friday, August 13, 1999 8:06 AM To: WebDAV Discussion List (E-mail) Cc: Alan Babich (E-mail); Chuck Fay (E-mail); Jim Green (E-mail); John F. Greene Jr. (E-mail); Katsumi Kanasaki (E-mail); Mitsuru Akizawa (E-mail); Richard Sauvain (E-mail); Steve Cousins (E-mail) Subject: [Moderator Action] RE: WebDAV: UUID/GUID - Please check my math! In the subject note, please ignore the brain-damaged comment at the end: >> Can someone please check this for me. >>And does anyone know where the 3400AD determination came from? >>(It's true that the timestamp can be smaller for different Variant fields. >>But the DCE variant field only takes away 2 bits from time-hi.) I was confusing the DCE variant field with the DCE version field. The version field is always 4 bits in a DCE UUID and the timestamp is always 60 bits. It is the clock-sequence number (a different beast altogether) that is narrowed as the variant field changes size. -- Dennis Dennis E. Hamilton - - - - - - - - - - - - - - - - mailto:infonuovo@email.com tel. +1(650)938.4584 fax. +1(650)567.9846 http://www.infonuovo.com From w3c-dist-auth-request@w3.org Sun Aug 15 19:27:37 1999 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA28189 for ; Sun, 15 Aug 1999 19:27:36 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id TAA14871; Sun, 15 Aug 1999 19:17:19 -0400 (EDT) Resent-Date: Sun, 15 Aug 1999 19:17:19 -0400 (EDT) Resent-Message-Id: <199908152317.TAA14871@www19.w3.org> From: Jim Whitehead To: Larry Masinter , John Stracke , WebDAV WG Date: Sun, 15 Aug 1999 16:12:52 -0700 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.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 In-Reply-To: <002601bee5c1$c8b4e620$79d3000d@copper.parc.xerox.com> Importance: Normal Subject: RE: WebDAV methods: safe and idempotent Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3148 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list Content-Transfer-Encoding: 7bit Since some systems allow GET to perform non-safe, non-idempotent operations via URL munging (e.g., http://www.docmgmtsys.com/doc-guid;action=CHECKOUT) it seems to me the best a spec. can do is state what the intended behavior is wrt safety and idempotence, and assume that people won't break it without a very good reason. - Jim > > > PROPFIND: safe, idempotent > > > PROPPATCH: unsafe, idempotent > > > > ...*provided* you're not using any funky live properties. Live > properties are > > behavior, not state, so they have safeness and idempotency, > too. So, really, > > you have to assume that both PROPFIND and PROPPATCH are unsafe and > > non-idempotent unless you know the safeness and idempotency of all the > > properties in use. > > I think it's more appropriate to define 'live properties' such that > they have the same relationship to safety and idempotency of PROPFIND > and PROPPATCH as 'resources' have to GET and PUT. That is: > > even though the property is live, PROPFIND of any property > SHOULD be safe and idempotent, and PROPPATCH should be idempotent. > > > > (This is the same issue as CGIs in base HTTP/1.1; a CGI script > could be built > > that reacts unsafely to GET, but it wouldn't be HTTP/1.1-compliant; it's > > supposed to use POST if it's unsafe. But we don't have PROPFIND-GET and > > PROPFIND-POST.) > > We should make the correspondence of PROPFIND-GET and PROPPATCH-PUT > (not POST). Not having done so is an flaw in the WebDAV spec that > SHOULD be corrected, not celebrated. > > Larry > From w3c-dist-auth-request@w3.org Sun Aug 15 19:27:39 1999 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA28209 for ; Sun, 15 Aug 1999 19:27:39 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id TAA14862; Sun, 15 Aug 1999 19:17:18 -0400 (EDT) Resent-Date: Sun, 15 Aug 1999 19:17:18 -0400 (EDT) Resent-Message-Id: <199908152317.TAA14862@www19.w3.org> From: Jim Whitehead To: WebDAV WG Date: Sun, 15 Aug 1999 16:08:41 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Importance: Normal Subject: FW: [Moderator Action] WebDAV: UUID/GUID - Please check my math! Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3146 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list Content-Transfer-Encoding: 7bit Caught by the spam filter... - Jim -----Original Message----- From: Dennis E. Hamilton [mailto:orcmid@email.msn.com]On Behalf Of infonuovo@email.com Sent: Tuesday, August 10, 1999 10:49 PM To: WebDAV Discussion List (E-mail) Cc: Alan Babich (E-mail); Chuck Fay (E-mail); Jim Green (E-mail); John F. Greene Jr. (E-mail); Katsumi Kanasaki (E-mail); Mitsuru Akizawa (E-mail); Richard Sauvain (E-mail); Steve Cousins (E-mail) Subject: [Moderator Action] WebDAV: UUID/GUID - Please check my math! %To: WebDAV Discussion List %Cc: DMA CSDocs Subcommittee %From: Dennis E. Hamilton %Re: UUID/GUID - Please check my math! In the DMA work on compound/structured documents, we are using UUID/GUID values for unambiguously identifying distinguished elements of persistent material. I followed the lead in RFC 2518 and did some research into UUID/GUID schemes. I wanted to make sure I could describe the conditions where someone could safely reserve a 32-bit block of Ids for suballocation as part of some specialized application (e.g., generating UUIDs for locally-unique elements of a legacy system). What I came up with is at http://www.infonuovo.com/dma/csdocs/sketch/instidid.htm#StandardDmaId MATH QUESTION According to my arithmetic, a timestamp employing a 60-bit 100ns interval counter will take over 3,653 years to repeat. Since DCE UUIDs are origined at 00:00 on October 15, 1582 A.D of the current calendar system, it looks like we will get FAR beyond 3400AD without a timestamp repetition. I have repeated this calculation several times and I get the same answer: 2^60 * 0.1 microsecond is over 3,653 years. (Or (1<<60) * 10E-7 seconds) I've included the relevant passage below (from http://www.infonuovo.com/dma/csdocs/sketch/instidid.htm#UUIDTimeStamp) although the formulas aren't as nice as in HTML. Can someone please check this for me. And does anyone know where the 3400AD determination came from? (It's true that the timestamp can be smaller for different Variant fields. But the DCE variant field only takes away 2 bits from time-hi.) -- Dennis Dennis E. Hamilton - - - - - - - - - - - - - - - - mailto:infonuovo@email.com tel. +1(650)938.4584 fax. +1(650)567.9846 http://www.infonuovo.com UUID TIME STAMP: TIME-LOW, TIME-MID, TIME-HI ------------------------------------------ The time stamp values correspond to the number of 100-nanosecond intervals that have occurred since the initiation of the current Gregorian calendar on October 15, 1582 A.D of that calendar. The 60 bits are expressed in three parts: time-low (32 bits), time-mid (16 bits), and time-hi (12 bits). The integer value of the time stamp is (time-hi $B!_(B 2^16 + time-mid) $B!_(B 2^32 + time-low It is not expected that time stamps be accurate to the nearest 100 nanoseconds. It is expected that time stamps generated with the same node and clock-seq values be monotonically increasing. There must be sufficient accuracy of time-keeping that duplication of identical time stamp and clock-seq combinations is statistically impossible for a given node identification. TIME-LOW The first group, consisting of 8 hexadecimal digits, specifies the value of a 32-bit unsigned binary integer, time-low. As a 100-nanosecond interval counter, time-low takes 429.4967296 seconds (about 7.16 minutes) before it repeats. TIME-MID The second group, consisting of 4 hexadecimal digits, specifies the value of a 16-bit unsigned binary integer, time-mid. The time-mid value advances each time time-low changes to 0. So time-mid changes every 429.4967296 seconds. It will take about 28,147,497.67 seconds, or about 7,818.75 hours, or about 325.78 days for time-mid to repeat. TIME-HI The third group, consisting of 4 hexadecimal digits, specifies the value of a 16-bit unsigned binary integer. The high-order nibble of 4 bits is used for a version field and the remaining 12 bits constitute the time-hi value. Since time-hi changes every 325.78 days, it will take 1,334,399.89 days, or over 3,653 years (4096 clicks of time-hi) for time-hi, and hence a value of the entire time stamp, to repeat. [end of extract] From w3c-dist-auth-request@w3.org Sun Aug 15 19:30:20 1999 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA28229 for ; Sun, 15 Aug 1999 19:30:20 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id TAA15077; Sun, 15 Aug 1999 19:22:02 -0400 (EDT) Resent-Date: Sun, 15 Aug 1999 19:22:02 -0400 (EDT) Resent-Message-Id: <199908152322.TAA15077@www19.w3.org> From: Jim Whitehead To: Geoffrey Clemm , WebDAV WG Date: Sun, 15 Aug 1999 16:16:17 -0700 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.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 In-Reply-To: <011201bee438$3d28fb30$0d1b15ac@aftershock.atria.com> Importance: Normal Subject: RE: [Moderator Action] Questions on Webdav Servers Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3149 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list Content-Transfer-Encoding: 7bit If this is the case, then RFC 2518 should be amended to make this so. Our intent was to ensure that locks at the destination stay active after copy/move (provided the destination lock is given in the If header), whether the lock is a singleton, or a hierarchy lock. - Jim > -----Original Message----- > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Geoffrey Clemm > Sent: Wednesday, August 11, 1999 1:30 PM > To: Jim Whitehead; WebDAV WG > Subject: Re: [Moderator Action] Questions on Webdav Servers > > > From: Jim Whitehead > > >Kevin Wiggen writes: > > ... > >> 3) MOVE/COPY to a destination that is locked. 8.10.5 states "... a > >> successful DELETE of a resource MUST cause all of its locks to be > >> removed." > >> and 8.8.4 states that overwrite set to T will do a DELETE.... > >> Then will the > >> LOCK on the destination be lost?? This seems wrong to me. If the > >> destination is LOCKED, then after a MOVE/COPY which might delete the > >> resource, I would assume the resource is still locked. > > > >If the destination of a COPY/MOVE is locked, and you submit the > lock token > >of the destination lock in the If header, then the intent of RFC 2518 is > >that the destination resource should be locked. This is stated in the > >second paragraph of section 7.7. > > > I agree that section 7.7 makes it clear that if you are > *inheriting* a lock > from > a collection that *contains* the destination, then that inherited lock is > valid following a COPY/MOVE. This makes sense since the locked collection > still exists following the COPY/MOVE. But I do not see anything > in 7.7 (or > in 7.5) that > either states or implies that a lock that was on the destination itself > remains > following the COPY/MOVE. So as currently written, I believe that the spec > supports > Kevin's interpretation. > > Cheers, > Geoff > > From w3c-dist-auth-request@w3.org Sun Aug 15 20:13:38 1999 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA28444 for ; Sun, 15 Aug 1999 20:13:36 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id UAA16174; Sun, 15 Aug 1999 20:05:06 -0400 (EDT) Resent-Date: Sun, 15 Aug 1999 20:05:06 -0400 (EDT) Resent-Message-Id: <199908160005.UAA16174@www19.w3.org> From: "Larry Masinter" To: "Jim Whitehead" , "John Stracke" , "WebDAV WG" Date: Sun, 15 Aug 1999 17:04:42 PDT Message-ID: <000001bee77a$f099f300$79d3000d@copper.parc.xerox.com> 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 8.5, Build 4.71.2173.0 In-reply-to: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Subject: RE: WebDAV methods: safe and idempotent Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3150 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list Content-Transfer-Encoding: 7bit > Since some systems allow GET to perform non-safe, non-idempotent operations > via URL munging (e.g., http://www.docmgmtsys.com/doc-guid;action=CHECKOUT) > it seems to me the best a spec. can do is state what the intended behavior > is wrt safety and idempotence, and assume that people won't break it without > a very good reason. Yes, PROPFIND SHOULD be safe and idempotent, and PROPPATCH SHOULD be idempotent, under the sense of SHOULD (from RFC 2119): 3. SHOULD This word, or the adjective "RECOMMENDED", mean that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course. in the same way that HTTP 1.1 identifies this for GET and HEAD in RFC 2616: In particular, the convention has been established that the GET and HEAD methods SHOULD NOT have the significance of taking an action other than retrieval. These methods ought to be considered "safe". This allows user agents to represent other methods, such as POST, PUT and DELETE, in a special way, so that the user is made aware of the fact that a possibly unsafe action is being requested. Naturally, it is not possible to ensure that the server does not generate side-effects as a result of performing a GET request; in fact, some dynamic resources consider that a feature. The important distinction here is that the user did not request the side-effects, so therefore cannot be held accountable for them. .... From w3c-dist-auth-request@w3.org Mon Aug 16 10:57:08 1999 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25206 for ; Mon, 16 Aug 1999 10:57:07 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id KAA05857; Mon, 16 Aug 1999 10:40:39 -0400 (EDT) Resent-Date: Mon, 16 Aug 1999 10:40:39 -0400 (EDT) Resent-Message-Id: <199908161440.KAA05857@www19.w3.org> From: jamsden@us.ibm.com X-Lotus-FromDomain: IBMUS To: w3c-dist-auth@w3.org Message-ID: <852567CF.00509744.00@d54mta03.raleigh.ibm.com> Date: Mon, 16 Aug 1999 10:37:30 -0400 Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Subject: RE: [Moderator Action] Questions on Webdav Servers, MOVE and dest LOCK Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3151 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list See comments in tags below on locks with COPY/MOVE ccjason@us.ibm.com on 07/26/99 09:47:36 PM To: w3c-dist-auth@w3.org cc: Subject: RE: [Moderator Action] Questions on Webdav Servers, MOVE and dest LOCK > 3) MOVE/COPY to a destination that is locked. 8.10.5 states "... a > successful DELETE of a resource MUST cause all of its locks to be > removed." > and 8.8.4 states that overwrite set to T will do a DELETE.... > Then will the > LOCK on the destination be lost?? This seems wrong to me. If the > destination is LOCKED, then after a MOVE/COPY which might delete the > resource, I would assume the resource is still locked. If the destination of a COPY/MOVE is locked, and you submit the lock token of the destination lock in the If header, then the intent of RFC 2518 is that the destination resource should be locked. This is stated in the second paragraph of section 7.7. I think this is an incorrect interpretation of section 7.7. The original lock on the destination of COPY/MOVE is always lost. Section 7.7 says what happens when the destination is within the scope of a depth lock, that is, the resource at the new location is a member of a collection locked with depth infinity. In this case, the lock is not retained, the destination resource gets a new lock. The purpose of the lock token in the If header for the COPY/MOVE destination is to allow the overwrite if necessary. It has no effect on the lock status of the destination resource after the COPY/MOVE method. Note: Although I don't think we deal directly on the topic of locks at the destination in the Adv Coll spec, 7.7 does seem to be in disagreement with the MOVE semantics of the Adv. Coll. proposal. If anyone feels strongly that section 7.7 should remain as is, I suggest that they do a read of the Adv Coll document and then express their opposition. I just don't want our Adv Coll work in this area to surprise anyone. We also should make sure that the Adv Coll document is *clear* on what should happen in this situation. My opinion is that the destination lock should go away as should the locks of any decendent nodes in the URI tree at the destination. I could be persuaded otherwise for a lock on the destination URI/resource specifically though. J. From w3c-dist-auth-request@w3.org Mon Aug 16 13:58:38 1999 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03099 for ; Mon, 16 Aug 1999 13:58:38 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id NAA15662; Mon, 16 Aug 1999 13:46:15 -0400 (EDT) Resent-Date: Mon, 16 Aug 1999 13:46:15 -0400 (EDT) Resent-Message-Id: <199908161746.NAA15662@www19.w3.org> From: jamsden@us.ibm.com X-Lotus-FromDomain: IBMUS To: w3c-dist-auth@w3.org Message-ID: <852567CF.00618F40.00@d54mta03.raleigh.ibm.com> Date: Mon, 16 Aug 1999 13:45:56 -0400 Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Subject: Re: LOCK Scenarios Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3152 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list See tags below... "Slein, Judith A" on 08/05/99 04:54:57 PM To: "'WebDAV'" cc: Subject: LOCK Scenarios We've been concerned about interactions between MOVE and locks. Logically speaking, I think we have to consider the following cases. (They are not all equally realistic, but they all are possible.) The question to answer about each one is whether it seems right for the resource to be locked after the MOVE, and if so, which lock should apply to it after the MOVE. Considering these cases *may* help us decide whether the design principles applied in RFC 2518 were the right ones. Speaking for myself, I find that I don't have clear and consistent reactions to these cases, so I find myself relying on other considerations like what our underlying models imply, and implementation considerations. Anyhow, here are the cases: In all cases, we assume that the agent requesting the MOVE owns all the locks in question. A resource is being MOVEd. The locks are on that resource and / or its destination, not the collections that contain them. 1. The source resource is locked, but the destination is not. MOVE /a/b to /x/y, where /a/b is locked but /a/ is not and /x/y is not. Lock token is required on source for MOVE, but not COPY. /x/y is not locked after the MOVE or COPY. 2. The source resource is not locked, but the destination is. MOVE /a/b to /x/y, where /a/b is not locked and /x/ is not locked, but /x/y is locked The lock token for the destination is required in the If header for both MOVE and COPY, and overwrite must be "T". The destination is not locked after the MOVE or COPY. Although at first, this seems to loose the lock, but the destination is a different resource, so it's not clear it should be locked after the MOVE or COPY. 3. Both are locked, but with separate locks. MOVE /a/b to /x/y, where /a/b has lock L1 and /x/y has lock L2, but neither /a/ nor /x/ is locked. Both lock tokens are required in the If header for MOVE, only the destination for COPY. The destination is not locked after the MOVE operation. A resource is being MOVEd. The locks are Depth: infinity locks on the collections that contain either the source or the destination location. 4. The source collection is locked, but the destination collection is not MOVE /a/b to /x/y, where /a/ is locked, but /x/ is not and /x/y is not. The source lock token is required in the If header. /x/y is not locked after the MOVE. 5. The source collection is not locked, but the destination collection is. MOVE /a/b to /x/y, where /a/ is not locked and /a/b is not locked, but /x/ is locked. No lock token is required. /x/y will be added to /a's write lock if it is a depth infinity lock. Otherwise, /x/y is not locked after the MOVE operation. 6. Both are locked, but with separate locks. MOVE /a/b to /x/y, where /a/ has lock L1 and /b/ has lock L2. The source lock token is required in the If header. /x/y will be added to /a's write lock if it is a depth infinity lock. Otherwise, /x/y is not locked after the MOVE operation. One lock is at the collection level, the other at the resource level. 7. The source resource is locked, and the destination collection is locked with a different token MOVE /a/b to /x/y, where /a/b has lock L1, /a/ is not locked, and /x/ has lock L2. L1 is required in the If header. /x/y will be locked with lock L2 if it is a depth infinity lock. 8. The source collection is locked, the destination resource (not its collection) is locked with a different token MOVE /a/b ro /x/y, where /a/ has lock L1, /x/ is not locked, and /x/y has lock L2. Both lock tokens L1 and L2 are required in the If header, and overwrite must be "T". For the following cases, should the MOVE succeed or fail? If it succeeds, what should the lock state be afterwards? 9. The source resource was locked through one mapping, and a MOVE is attempted through a different mapping. 9a. /a/b and /c/d map to R. /a/ is locked. MOVE /c/d to /x/y. The question here is, do we lock URLs or do we lock resources. If we lock resources, then we don't have enough information. We need to know what /a/ maps to. 9b. /a/b and /c/d map to R. /a/ is not locked, but /a/b is. MOVE /c/d to /x/y. 10. The destination resource was locked through one mapping, and a MOVE is attempted through a different mapping. 10a. /w/x and /y/z map to R. /w/ is locked. MOVE /a/b to /y/z. if the locks are on the resources, not the URLs that map to them, then it wouldn't matter which mapping was used to access the resource. 10b. /w/x and /y/z map to R. /w/ is not locked, but /w/x is. MOVE /a/b to /y/z. --Judy Judith A. Slein Xerox Corporation jslein@crt.xerox.com (716)422-5169 800 Phillips Road 105/50C Webster, NY 14580 From w3c-dist-auth-request@w3.org Mon Aug 16 14:03:08 1999 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03520 for ; Mon, 16 Aug 1999 14:03:07 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id NAA16153; Mon, 16 Aug 1999 13:54:07 -0400 (EDT) Resent-Date: Mon, 16 Aug 1999 13:54:07 -0400 (EDT) Resent-Message-Id: <199908161754.NAA16153@www19.w3.org> Date: Mon, 16 Aug 1999 13:53:54 -0400 Message-Id: <9908161753.AA27242@tantalum> From: "Geoffrey M. Clemm" To: w3c-dist-auth@w3.org, ietf-dav-versioning@w3.org Subject: Using PROPPATCH to create a resource with no body Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3153 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list The DeltaV versioning extensions to WebDAV propose four new types of resources: workspace, activity, configuration, and history. All these new resource types share the characteristic that their state is represented as a set of properties, rather than in a body. In this way, they are like the collection resource type from the core WebDAV protocol, and the redirect-reference resource type from the advanced collection WebDAV extensions. A common issue for each of these new resource types is how one creates an instance. The approach started by the core WebDAV spec is to introduce a new method for creating each new resource type (e.g. MKCOL). This becomes rather burdensome when the list starts growing (MKWORKSPACE, MKACTIVITY, MKCONFIGURATION, MKHISTORY, ...), and is rather redundant since they all take the form of initializing a set of properties of a new resource. An alternative approach is to just allow PROPPATCH to create a new resource when it is applied to a null resource. I would propose also adding a new value for the Overwrite header, e.g. Update, which would say that the destination of operation should be updated, rather than deleted (Overwrite=T) or have the operation fail (Overwrite=F). Then the Overwrite header could be used to control the effect of a PROPPATCH. This is very consistent with the functionality of PUT, which can be used either to update an existing resource or create a new resource. Another alternative is to introduce a MKRESOURCE method, which would be equivalent to a PROPATCH with Overwrite=F. I personally favor extending PROPPATCH since it is both more consistent with PUT, and a more powerful/flexible approach. As a note, MKCOL would then just become an alias for a PROPATCH, with the resourcetype property set to be Comments? Cheers, Geoff From w3c-dist-auth-request@w3.org Mon Aug 16 15:58:17 1999 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09078 for ; Mon, 16 Aug 1999 15:58:17 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id PAA19561; Mon, 16 Aug 1999 15:48:16 -0400 (EDT) Resent-Date: Mon, 16 Aug 1999 15:48:16 -0400 (EDT) Resent-Message-Id: <199908161948.PAA19561@www19.w3.org> From: "Kevin Wiggen" To: , Date: Mon, 16 Aug 1999 12:46:42 -0700 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.2910.0) In-Reply-To: <852567CF.00618F40.00@d54mta03.raleigh.ibm.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3155.0 Subject: RE: LOCK Scenarios Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3154 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list Content-Transfer-Encoding: 7bit tags.... Thanks for bringing up COPY, we should be making it a priority as well in all of this.. I am OK with 1-3. I might argue that locks on the destination should remain, but I could be convinced otherwise. A resource is being MOVEd. The locks are Depth: infinity locks on the collections that contain either the source or the destination location. 4. The source collection is locked, but the destination collection is not MOVE /a/b to /x/y, where /a/ is locked, but /x/ is not and /x/y is not. The source lock token is required in the If header. /x/y is not locked after the MOVE. agree 5. The source collection is not locked, but the destination collection is. MOVE /a/b to /x/y, where /a/ is not locked and /a/b is not locked, but /x/ is locked. No lock token is required. /x/y will be added to /a's write lock if it is a depth infinity lock. Otherwise, /x/y is not locked after the MOVE operation. Disagree with the part about No lock token required. Since you are changing /x's contents, you need /x's LOCK. /a/b is moved to /x and added to its LOCK 6. Both are locked, but with separate locks. MOVE /a/b to /x/y, where /a/ has lock L1 and /b/ has lock L2. The source lock token is required in the If header. /x/y will be added to /a's write lock if it is a depth infinity lock. Otherwise, /x/y is not locked after the MOVE operation. Same arguement as above. 2 Lock token's required, /a loses /a/b as a resource and loses it from its lock. /x/y now exists as a new resource (/a/b) but is still locked by L2. One lock is at the collection level, the other at the resource level. 7. The source resource is locked, and the destination collection is locked with a different token MOVE /a/b to /x/y, where /a/b has lock L1, /a/ is not locked, and /x/ has lock L2. L1 is required in the If header. /x/y will be locked with lock L2 if it is a depth infinity lock. Both locks are required in IF header for reasons above. L1 is removed from system (nothing left to lock?) while new /x/y is in L2 due to infinity lock I agree that some mention must be made of the Depth header on the collection locks. We need to add it and COPY to the use cases that are being argued.. Kevin From w3c-dist-auth-request@w3.org Mon Aug 16 16:54:44 1999 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10589 for ; Mon, 16 Aug 1999 16:54:44 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id QAA20931; Mon, 16 Aug 1999 16:45:51 -0400 (EDT) Resent-Date: Mon, 16 Aug 1999 16:45:51 -0400 (EDT) Resent-Message-Id: <199908162045.QAA20931@www19.w3.org> From: jamsden@us.ibm.com X-Lotus-FromDomain: IBMUS To: w3c-dist-auth@w3.org, ietf-dav-versioning@w3.org Message-ID: <852567CF.007205C4.00@d54mta03.raleigh.ibm.com> Date: Mon, 16 Aug 1999 16:45:47 -0400 Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Subject: Re: Using PROPPATCH to create a resource with no body Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3155 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list I am generally in favor of using PROPPATCH to create and initialize the properties of a resource. This would allow PROPPATCH to have the same semantics as PUT. I am a little less comfortable with the overwrite header semantics. It seems that overwrite is somewhat redundant with the propertyupdate element in the body of the PROPPATCH request. Perhaps the semantics being handled by the overwrite header could be included in the propertyupdate element. This would allow more flexibility by indicating for each property how it should be handled, and would not introduce a third state for overwrite which is currently a boolean header. There are a number of proposed extensions to PROPPATCH which I will summarize here. Jim Whitehead, what needs to be done to get these extensions considered by the WebDAV working group? 1. Allow PROPPATCH on a null resource to create a resource and initialize its properties. The spec is currently quiet about PROPPATCH on a null resource (a resource that does not exist). It does say that PROPPATCH on a lock null resource (a resource created by the LOCK method) will fail, but this is inconsistent with PUT which is allowed, and changes the state of the resource from lock null to resource. 2. Extend the DAV:set and DAV:remove elements to include information describing how the client wishes to handle errors. The DTD additions would be: If an updatebehavior is not included, it is equivalent to specifying * meaning that all the updates must be successful or none of them are performed. If a list of URIs is included as the value of mustsucceed, then the named properties must be updated successfully. The #PCDATA in element mustsucceed can only be "*" indicating all updates must be successful. If ignore is specified, then the server must use best effort to update the properties returning a multistatus indicating which properties were not updated. Currently, the spec says that all property updates must be successful, or none are applied. In many instances, this is too restrictive requiring clients to submit PROPPATCH requests, examine the multistatus returned to figure out which updates failed, and re-submit a new PROPPATCH with the failures removed. This situation arrises when different servers support different live properties. The above extension to PROPPATCH allows client applications to have more control on setting properties. 3. Add an add element to propertyupdate to distinguish between setting an existing property and adding a new property. Currently, propertyupdate includes set and remove. A client can either set the value of an existing property, or add a new property with the set element. There are some cases where the client does not want to set an element that already exists, but there is currently no way to distinguish these operations in the propertyupdate element. The extension provides an add element that would add a new property to the resource. The add update would fail if the property already has a value. This extension will be more important if we add extension 1 because there will be many cases where a property should not be updated after it has been set. For example, resourcetype, creationdate, etc. "Geoffrey M. Clemm" on 08/16/99 01:53:54 PM To: w3c-dist-auth@w3.org, ietf-dav-versioning@w3.org cc: Subject: Using PROPPATCH to create a resource with no body The DeltaV versioning extensions to WebDAV propose four new types of resources: workspace, activity, configuration, and history. All these new resource types share the characteristic that their state is represented as a set of properties, rather than in a body. In this way, they are like the collection resource type from the core WebDAV protocol, and the redirect-reference resource type from the advanced collection WebDAV extensions. A common issue for each of these new resource types is how one creates an instance. The approach started by the core WebDAV spec is to introduce a new method for creating each new resource type (e.g. MKCOL). This becomes rather burdensome when the list starts growing (MKWORKSPACE, MKACTIVITY, MKCONFIGURATION, MKHISTORY, ...), and is rather redundant since they all take the form of initializing a set of properties of a new resource. An alternative approach is to just allow PROPPATCH to create a new resource when it is applied to a null resource. I would propose also adding a new value for the Overwrite header, e.g. Update, which would say that the destination of operation should be updated, rather than deleted (Overwrite=T) or have the operation fail (Overwrite=F). Then the Overwrite header could be used to control the effect of a PROPPATCH. This is very consistent with the functionality of PUT, which can be used either to update an existing resource or create a new resource. Another alternative is to introduce a MKRESOURCE method, which would be equivalent to a PROPATCH with Overwrite=F. I personally favor extending PROPPATCH since it is both more consistent with PUT, and a more powerful/flexible approach. As a note, MKCOL would then just become an alias for a PROPATCH, with the resourcetype property set to be Comments? Cheers, Geoff From w3c-dist-auth-request@w3.org Mon Aug 16 17:04:14 1999 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10894 for ; Mon, 16 Aug 1999 17:04:13 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id QAA21093; Mon, 16 Aug 1999 16:53:52 -0400 (EDT) Resent-Date: Mon, 16 Aug 1999 16:53:52 -0400 (EDT) Resent-Message-Id: <199908162053.QAA21093@www19.w3.org> From: jamsden@us.ibm.com X-Lotus-FromDomain: IBMUS To: w3c-dist-auth@w3.org Message-ID: <852567CF.0072C630.00@d54mta03.raleigh.ibm.com> Date: Mon, 16 Aug 1999 16:51:07 -0400 Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Subject: RE: LOCK Scenarios Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3156 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list I agree with all of Kevin's observations below. In particular, if you MOVE a resource to a destination where the (new) parent collection is locked, you need the lock token for that parent collection in order to add the new member. Sorry, I wasn't careful enough in my response. It's easy to get all these rules mixed up or forget one - ample justification for keeping things simple and regular. "Kevin Wiggen" on 08/16/99 03:46:42 PM To: Jim Amsden/Raleigh/IBM@IBMUS, w3c-dist-auth@w3.org cc: Subject: RE: LOCK Scenarios tags.... Thanks for bringing up COPY, we should be making it a priority as well in all of this.. I am OK with 1-3. I might argue that locks on the destination should remain, but I could be convinced otherwise. A resource is being MOVEd. The locks are Depth: infinity locks on the collections that contain either the source or the destination location. 4. The source collection is locked, but the destination collection is not MOVE /a/b to /x/y, where /a/ is locked, but /x/ is not and /x/y is not. The source lock token is required in the If header. /x/y is not locked after the MOVE. agree 5. The source collection is not locked, but the destination collection is. MOVE /a/b to /x/y, where /a/ is not locked and /a/b is not locked, but /x/ is locked. No lock token is required. /x/y will be added to /a's write lock if it is a depth infinity lock. Otherwise, /x/y is not locked after the MOVE operation. Disagree with the part about No lock token required. Since you are changing /x's contents, you need /x's LOCK. /a/b is moved to /x and added to its LOCK 6. Both are locked, but with separate locks. MOVE /a/b to /x/y, where /a/ has lock L1 and /b/ has lock L2. The source lock token is required in the If header. /x/y will be added to /a's write lock if it is a depth infinity lock. Otherwise, /x/y is not locked after the MOVE operation. Same arguement as above. 2 Lock token's required, /a loses /a/b as a resource and loses it from its lock. /x/y now exists as a new resource (/a/b) but is still locked by L2. One lock is at the collection level, the other at the resource level. 7. The source resource is locked, and the destination collection is locked with a different token MOVE /a/b to /x/y, where /a/b has lock L1, /a/ is not locked, and /x/ has lock L2. L1 is required in the If header. /x/y will be locked with lock L2 if it is a depth infinity lock. Both locks are required in IF header for reasons above. L1 is removed from system (nothing left to lock?) while new /x/y is in L2 due to infinity lock I agree that some mention must be made of the Depth header on the collection locks. We need to add it and COPY to the use cases that are being argued.. Kevin From w3c-dist-auth-request@w3.org Mon Aug 16 18:33:27 1999 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12972 for ; Mon, 16 Aug 1999 18:33:26 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id SAA23037; Mon, 16 Aug 1999 18:25:01 -0400 (EDT) Resent-Date: Mon, 16 Aug 1999 18:25:01 -0400 (EDT) Resent-Message-Id: <199908162225.SAA23037@www19.w3.org> From: Jim Whitehead To: w3c-dist-auth@w3.org, ietf-dav-versioning@w3.org MMDF-Warning: Parse error in original version of preceding line at paris.ics.uci.edu Date: Mon, 16 Aug 1999 15:19:02 -0700 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.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 In-Reply-To: <9908161753.AA27242@tantalum> Subject: RE: Using PROPPATCH to create a resource with no body Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3157 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list Content-Transfer-Encoding: 7bit I think overloading PROPPATCH so it can also create resources is a sub-optimal design choice. > A common issue for each of these new resource types is how one creates > an instance. The approach started by the core WebDAV spec is > to introduce a new method for creating each new resource type > (e.g. MKCOL). This becomes rather burdensome when > the list starts growing (MKWORKSPACE, MKACTIVITY, MKCONFIGURATION, > MKHISTORY, ...), and is rather redundant since they all take the > form of initializing a set of properties of a new resource. On the plus side, if I'm looking to create a workspace, and I'm glancing through the table of contents of the Delta-V specification, I'll immediately guess that MKWORKSPACE does the job. In contrast, it would take some reading, and some head scratching to figure out that PROPPATCH did this as a side effect. > An alternative approach is to just allow PROPPATCH to create a new > resource when it is applied to a null resource. I would propose > also adding a new value for the Overwrite header, e.g. Update, > which would say that the destination of operation should be updated, > rather than deleted (Overwrite=T) or have the operation fail > (Overwrite=F). > Then the Overwrite header could be used to control the effect of a > PROPPATCH. > > This is very consistent with the functionality of PUT, which can be > used either to update an existing resource or create a new resource. Right, but PUT was explicitly designed to be a resource creation method, PROPPATCH was not. > Another alternative is to introduce a MKRESOURCE method, which would > be equivalent to a PROPATCH with Overwrite=F. I like this idea the best. In particular, the current defintion of MKRESOURCE uses the value of the resourcetype property to determine the kind of resource that is created (workspace, etc.). This is a different behavior than when the same property is operated on using PROPPATCH (normally, resourcetype is read-only). Since MKRESOURCE is affecting the semantics of the property set operation, it doesn't seem like a good separation of concerns to try and shoehorn this functionality back into PROPPATCH. Since MKRESOURCE does have different semantics than PROPPATCH, and since I have yet to see any critique giving reasons for why MKRERSOURCE is a bad design choice, simple separation of concerns leads me to favor MKRESOURCE over an overloaded PROPPATCH. - Jim From w3c-dist-auth-request@w3.org Mon Aug 16 18:34:11 1999 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13009 for ; Mon, 16 Aug 1999 18:34:11 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id SAA23075; Mon, 16 Aug 1999 18:25:25 -0400 (EDT) Resent-Date: Mon, 16 Aug 1999 18:25:25 -0400 (EDT) Resent-Message-Id: <199908162225.SAA23075@www19.w3.org> From: Jim Whitehead To: w3c-dist-auth@w3.org, ietf-dav-versioning@w3.org MMDF-Warning: Parse error in original version of preceding line at paris.ics.uci.edu Date: Mon, 16 Aug 1999 15:19:03 -0700 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.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 In-Reply-To: <852567CF.007205C4.00@d54mta03.raleigh.ibm.com> Subject: RE: Using PROPPATCH to create a resource with no body Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3158 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list Content-Transfer-Encoding: 7bit Jim Amsden writes: > There are a number of proposed extensions to PROPPATCH which I > will summarize here. Jim Whitehead, what needs to be done to get these > extensions considered by the WebDAV working group? Write them up in an Internet-Draft. This draft can then be used by the document editors when RFC 2518 goes to Draft Standard. > 1. Allow PROPPATCH on a null resource to create a resource and > initialize its properties. > > The spec is currently quiet about PROPPATCH on a null resource (a > resource that does not exist). It does say that PROPPATCH on a lock null > resource (a resource created by the LOCK method) will fail, but this is inconsistent > with PUT which is allowed, and changes the state of the resource from lock null > to resource. The intent of RFC 2518 was that PROPPATCH, like every other method that does not create a resource, would return a 404 (Not Found) error. The spec. does not explicitly mention this, since we intended for all standard HTTP/1.1 error cases to be applied to WebDAV. A PROPPATCH on a null resource is a standard 404 (Not Found) error case, and hence we didn't think it needed special mention. - Jim From w3c-dist-auth-request@w3.org Tue Aug 17 10:59:08 1999 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22828 for ; Tue, 17 Aug 1999 10:59:07 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id KAA07343; Tue, 17 Aug 1999 10:46:11 -0400 (EDT) Resent-Date: Tue, 17 Aug 1999 10:46:11 -0400 (EDT) Resent-Message-Id: <199908171446.KAA07343@www19.w3.org> Message-ID: <8E3CFBC709A8D21191A400805F15E0DBD243F9@crte147.wc.eso.mc.xerox.com> From: "Slein, Judith A" To: "'WebDAV'" Date: Tue, 17 Aug 1999 10:46:15 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Subject: Re: LOCK Scenarios Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3159 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list Two people have now taken a careful look at the lock / MOVE scenarios. Kevin's intuitions are consistent: It is always the lock at the destination that survives after a MOVE, whether that lock is inherited from a collection or is directly on the resource at the destination. Jim Whitehead confirmed that this was the intended behavior specified in section 7.7 of rfc 2518. As Kevin points out, the language in 8.8.4 and 8.10.5 together seems to contradict this, so the inconsistency in rfc 2518 needs to be straightened out. Section 8.10.5 says that if Overwrite is "T", the resource at the destination will be deleted, and section 8.8.4 says that if a resource is deleted, all its locks are removed. So the upshot seems to be that after the MOVE, any singleton lock at the destination will be gone. Jim Amsden's intuitions about the scenarios were different: No singleton lock ever survives a MOVE, but a resource that is moved into a locked collection does inherit the collection's lock. So Jim's intuitions agree with sections 8.8.4 and 8.10.5, and with interpreting section 7.7 to be only about inheriting collection locks, and not about singleton locks. ------- Cases 9 and 10 poke at the complexities added by multiple URI mappings to the same resource. Kevin's intuitions say that there is really no added difficulty about resolving these cases. It's the resource that gets locked, as rfc 2518 says, and it's still true that any lock, inherited or singleton, at the destination, survives the move. --Judy Judith A. Slein Xerox Corporation jslein@crt.xerox.com (716)422-5169 800 Phillips Road 105/50C Webster, NY 14580 From w3c-dist-auth-request@w3.org Tue Aug 17 11:44:10 1999 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24832 for ; Tue, 17 Aug 1999 11:44:09 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id LAA09668; Tue, 17 Aug 1999 11:35:28 -0400 (EDT) Resent-Date: Tue, 17 Aug 1999 11:35:28 -0400 (EDT) Resent-Message-Id: <199908171535.LAA09668@www19.w3.org> Date: Tue, 17 Aug 1999 11:35:18 -0400 Message-Id: <9908171535.AA27655@tantalum> From: "Geoffrey M. Clemm" To: JSlein@crt.xerox.com Cc: w3c-dist-auth@w3.org In-Reply-To: <8E3CFBC709A8D21191A400805F15E0DBD243F9@crte147.wc.eso.mc.xerox.com> (JSlein@crt.xerox.com) Subject: Re: LOCK Scenarios Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3160 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list It appears to me that Jim Amsden's intuition and the current wording of the spec is more consistent than the "intended behavior". In particular, suppose you had three locks, on: /x /x/y /x/y/z.html Now suppose you MOVE'd a new collection to /x/y. I think we all agree that the lock on /x is unaffected. But what about the locks on /x/y and /x/y/z.html? It is consistent to say that all locks on deleted resources at the destination are removed (i.e. consistent with the fact that deleting a resource deletes its locks). It is also consistent (although somewhat more complicated) to say that the "delete" performed as a side effect of a MOVE is a special kind of delete that does not remove locks. But then neither the lock on /x/y *nor* the lock on /x/y/z.html should be affected, which means that if /x/y/z.html is not mapped to any resource following the MOVE, then a lock-null resource must auto-magically be created at /x/y/z.html after the MOVE. In my opinion, the complexity of special casing delete for MOVE, and creating these lock-null resources as a side effect of the MOVE, significantly outweigh any benefits that might be achieved. Cheers, Geoff From: "Slein, Judith A" Date: Tue, 17 Aug 1999 10:46:15 -0400 Mime-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) charset="iso-8859-1" Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3159 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list X-Lines: 42 Content-Type: text/plain; charset="iso-8859-1" Content-Length: 1640 Two people have now taken a careful look at the lock / MOVE scenarios. Kevin's intuitions are consistent: It is always the lock at the destination that survives after a MOVE, whether that lock is inherited from a collection or is directly on the resource at the destination. Jim Whitehead confirmed that this was the intended behavior specified in section 7.7 of rfc 2518. As Kevin points out, the language in 8.8.4 and 8.10.5 together seems to contradict this, so the inconsistency in rfc 2518 needs to be straightened out. Section 8.10.5 says that if Overwrite is "T", the resource at the destination will be deleted, and section 8.8.4 says that if a resource is deleted, all its locks are removed. So the upshot seems to be that after the MOVE, any singleton lock at the destination will be gone. Jim Amsden's intuitions about the scenarios were different: No singleton lock ever survives a MOVE, but a resource that is moved into a locked collection does inherit the collection's lock. So Jim's intuitions agree with sections 8.8.4 and 8.10.5, and with interpreting section 7.7 to be only about inheriting collection locks, and not about singleton locks. ------- Cases 9 and 10 poke at the complexities added by multiple URI mappings to the same resource. Kevin's intuitions say that there is really no added difficulty about resolving these cases. It's the resource that gets locked, as rfc 2518 says, and it's still true that any lock, inherited or singleton, at the destination, survives the move. --Judy From w3c-dist-auth-request@w3.org Tue Aug 17 11:50:59 1999 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25349 for ; Tue, 17 Aug 1999 11:50:58 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id LAA09960; Tue, 17 Aug 1999 11:42:05 -0400 (EDT) Resent-Date: Tue, 17 Aug 1999 11:42:05 -0400 (EDT) Resent-Message-Id: <199908171542.LAA09960@www19.w3.org> From: ccjason@us.ibm.com X-Lotus-FromDomain: IBMUS To: "Slein, Judith A" cc: "'WebDAV'" Message-ID: <852567D0.0056282C.00@D51MTA07.pok.ibm.com> Date: Tue, 17 Aug 1999 11:39:50 -0400 Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Subject: Re: LOCK Scenarios Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3161 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list Judith, > Two people have now taken a careful look at the lock / MOVE scenarios. At least three people. You overlooked my note. Kevin's intuitions are consistent: It is always the lock at the destination that survives after a MOVE, whether that lock is inherited from a collection or is directly on the resource at the destination. Agreed. They seem consistant and your interpretation of what he's said sounds right. As my note pointed out, I think he had some trouble on whether lock tokens are required though in scenarios 9/10. It seemed to be based on his assumption that changing the membership of a collection isn't an operation on the collection. Just on the resource already at the URI. In subsequent notes in response to Jim, Kevin seemed to recognize the role of the parent though. Jim Amsden's intuitions about the scenarios were different: No singleton lock ever survives a MOVE, but a resource that is moved into a locked collection does inherit the collection's lock. Just for the sake of consistancy, I prefer the singleton and depth locks to be treated the same. Just as Kevin apparently does. Cases 9 and 10 poke at the complexities added by multiple URI mappings to the same resource. Kevin's intuitions say that there is really no added difficulty about resolving these cases. It's the resource that gets locked, as rfc 2518 says, and it's still true that any lock, inherited or singleton, at the destination, survives the move. I disagree somewhat with "it's the resource that gets locked" as sumarizing Kevin's interpretation. If the resouce moves and doesn't carry the lock with it at times, then I don't think it's correct to say it's the resource that is locked. At least not without further explanation. That's what my note pointed out. But yes, if a resource is locked at one mapping, it is locked at all. But only the original URI mapping is "protected"... using the AdvColl definition of "protected". At least that was my proposal... based on AdvColl discussions. J. From w3c-dist-auth-request@w3.org Tue Aug 17 13:30:48 1999 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29779 for ; Tue, 17 Aug 1999 13:30:48 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id NAA12313; Tue, 17 Aug 1999 13:21:14 -0400 (EDT) Resent-Date: Tue, 17 Aug 1999 13:21:14 -0400 (EDT) Resent-Message-Id: <199908171721.NAA12313@www19.w3.org> From: jamsden@us.ibm.com X-Lotus-FromDomain: IBMUS To: w3c-dist-auth@w3.org Message-ID: <852567D0.005F4236.00@d54mta03.raleigh.ibm.com> Date: Tue, 17 Aug 1999 13:13:15 -0400 Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Subject: Re: LOCK Scenarios Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3162 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list Section 7.7 makes no mention of locks on the destination, only depth infinity locks inherited from new parent collections. If the destination resource falls within the scope of a depth infinity lock, then it inherits the lock, just like PUT or MKCOL. I don't think the spec is inconsistent with regard to locks and MOVE and COPY. It may not be the semantics everyone would want, but it is not inconsistent. I'm not convinced that destination locks should be retained after MOVE and COPY anyway as the destination is a new resource with new properties. The lock was on the old resource which was deleted. However, I don't feel strongly about these semantics as long as whatever we come up with is simple, consistent, and predictable. "Slein, Judith A" on 08/17/99 10:46:15 AM To: "'WebDAV'" cc: Subject: Re: LOCK Scenarios Two people have now taken a careful look at the lock / MOVE scenarios. Kevin's intuitions are consistent: It is always the lock at the destination that survives after a MOVE, whether that lock is inherited from a collection or is directly on the resource at the destination. Jim Whitehead confirmed that this was the intended behavior specified in section 7.7 of rfc 2518. As Kevin points out, the language in 8.8.4 and 8.10.5 together seems to contradict this, so the inconsistency in rfc 2518 needs to be straightened out. Section 8.10.5 says that if Overwrite is "T", the resource at the destination will be deleted, and section 8.8.4 says that if a resource is deleted, all its locks are removed. So the upshot seems to be that after the MOVE, any singleton lock at the destination will be gone. Jim Amsden's intuitions about the scenarios were different: No singleton lock ever survives a MOVE, but a resource that is moved into a locked collection does inherit the collection's lock. So Jim's intuitions agree with sections 8.8.4 and 8.10.5, and with interpreting section 7.7 to be only about inheriting collection locks, and not about singleton locks. ------- Cases 9 and 10 poke at the complexities added by multiple URI mappings to the same resource. Kevin's intuitions say that there is really no added difficulty about resolving these cases. It's the resource that gets locked, as rfc 2518 says, and it's still true that any lock, inherited or singleton, at the destination, survives the move. --Judy Judith A. Slein Xerox Corporation jslein@crt.xerox.com (716)422-5169 800 Phillips Road 105/50C Webster, NY 14580 From w3c-dist-auth-request@w3.org Tue Aug 17 14:00:37 1999 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00948 for ; Tue, 17 Aug 1999 14:00:36 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id NAA13353; Tue, 17 Aug 1999 13:49:18 -0400 (EDT) Resent-Date: Tue, 17 Aug 1999 13:49:18 -0400 (EDT) Resent-Message-Id: <199908171749.NAA13353@www19.w3.org> From: jamsden@us.ibm.com X-Lotus-FromDomain: IBMUS To: w3c-dist-auth@w3.org Message-ID: <852567D0.0061DE78.00@d54mta03.raleigh.ibm.com> Date: Tue, 17 Aug 1999 13:46:09 -0400 Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Subject: LOCK Scenarios Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3163 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list Jason says: Just for the sake of consistancy, I prefer the singleton and depth locks to be treated the same. Just as Kevin apparently does. I'm not sure this treating these locks the same is consistent. They are different locks on different resources playing different roles in the methods. As Geoff pointed out, to have a (singleton) destination lock retained on COPY or MOVE requires a significant number of special cases. From w3c-dist-auth-request@w3.org Tue Aug 17 14:35:05 1999 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01980 for ; Tue, 17 Aug 1999 14:35:04 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id OAA13984; Tue, 17 Aug 1999 14:23:15 -0400 (EDT) Resent-Date: Tue, 17 Aug 1999 14:23:15 -0400 (EDT) Resent-Message-Id: <199908171823.OAA13984@www19.w3.org> From: ccjason@us.ibm.com X-Lotus-FromDomain: IBMUS To: jamsden@us.ibm.com cc: w3c-dist-auth@w3.org Message-ID: <852567D0.0064F805.00@D51MTA07.pok.ibm.com> Date: Tue, 17 Aug 1999 14:21:41 -0400 Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Subject: Re: LOCK Scenarios Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3164 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list >> As Geoff pointed out, to have a (singleton) destination lock retained on COPY or MOVE requires a significant number of special cases. >> Maybe I misinterpretted what it was that he Geoff felt was inconsistant. He didn't mention singleton, depth or even exclusive locks. For this reason, the inconsistancy that I thought he depicted applies to singleton and depth locks equally... and exclusive and shared... and that's what I addressed in my response to his note. From w3c-dist-auth-request@w3.org Tue Aug 17 15:17:10 1999 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03115 for ; Tue, 17 Aug 1999 15:17:09 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id PAA15131; Tue, 17 Aug 1999 15:08:25 -0400 (EDT) Resent-Date: Tue, 17 Aug 1999 15:08:25 -0400 (EDT) Resent-Message-Id: <199908171908.PAA15131@www19.w3.org> From: ccjason@us.ibm.com X-Lotus-FromDomain: IBMUS To: "Geoffrey M. Clemm" cc: w3c-dist-auth@w3.org Message-ID: <852567D0.00691803.00@D51MTA07.pok.ibm.com> Date: Tue, 17 Aug 1999 15:06:45 -0400 Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Subject: Re: LOCK Scenarios Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3165 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list I missed something in my previous response to Geoff's note... It appears to me that Jim Amsden's intuition and the current wording of the spec is more consistent than the "intended behavior". In particular, suppose you had three locks, on: /x /x/y /x/y/z.html Now suppose you MOVE'd a new collection to /x/y. I think we all agree that the lock on /x is unaffected. But what about the locks on /x/y and /x/y/z.html? It is consistent to say that all locks on deleted resources at the destination are removed (i.e. consistent with the fact that deleting a resource deletes its locks). It is also consistent (although somewhat more complicated) to say that the "delete" performed as a side effect of a MOVE is a special kind of delete that does not remove locks. But then neither the lock on /x/y *nor* the lock on /x/y/z.html should be affected, which means that if /x/y/z.html is not mapped to any resource following the MOVE, then a lock-null resource must auto-magically be created at /x/y/z.html after the MOVE. In my previous response I voted against retaining a lock for /x/y/z.html. One other thing I'd like to check... Is it possible to do a MOVE operation that replaces a binding to a collection with a binding to a non-collection? (This relates to your discussions with JimW over /x/y/ and /x/y being interchangeable.) If so... there might not even be a collection at /x/y after the move which makes keeping a null lock at /x/y/z.html even odder. To date, all null locks have had collection resources at their PARENT URI. I'd vote that for now we limit the things so that the only lock that we'd consider retaining is at the DELETE's request URI. Any ancestor lock will be retained. Any descendent lock will not. Note: all of our discussion retaining destination locks also applies to an overwrit'ing BIND. From w3c-dist-auth-request@w3.org Tue Aug 17 16:38:03 1999 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04975 for ; Tue, 17 Aug 1999 16:38:03 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id QAA17491; Tue, 17 Aug 1999 16:21:26 -0400 (EDT) Resent-Date: Tue, 17 Aug 1999 16:21:26 -0400 (EDT) Resent-Message-Id: <199908172021.QAA17491@www19.w3.org> From: jamsden@us.ibm.com X-Lotus-FromDomain: IBMUS To: w3c-dist-auth@w3.org Message-ID: <852567D0.006FC9E2.00@d54mta03.raleigh.ibm.com> Date: Tue, 17 Aug 1999 16:21:12 -0400 Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Subject: Re: LOCK Scenarios Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3166 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list In my previous response I voted against retaining a lock for /x/y/z.html. One other thing I'd like to check... Is it possible to do a MOVE operation that replaces a binding to a collection with a binding to a non-collection? (This relates to your discussions with JimW over /x/y/ and /x/y being interchangeable.) You can MOVE a resource over a collection or the other way around. The semantics are that the overwrite header must be "T", and if so the destination is deleted before the MOVE. If so... there might not even be a collection at /x/y after the move which makes keeping a null lock at /x/y/z.html even odder. To date, all null locks have had collection resources at their PARENT URI. All DAV resources have collection resources at the PARENT URI. I'd vote that for now we limit the things so that the only lock that we'd consider retaining is at the DELETE's request URI. Any ancestor lock will be retained. Any descendent lock will not. Yet another special case. The current spec has no such special cases. Inheriting a depth infinity lock from the destination parent collection is not a special case, its part of what it means to be a memeber of a collection. Note: all of our discussion retaining destination locks also applies to an overwrit'ing BIND. From w3c-dist-auth-request@w3.org Wed Aug 18 09:51:10 1999 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA09487 for ; Wed, 18 Aug 1999 09:51:10 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id JAA02288; Wed, 18 Aug 1999 09:31:02 -0400 (EDT) Resent-Date: Wed, 18 Aug 1999 09:31:02 -0400 (EDT) Resent-Message-Id: <199908181331.JAA02288@www19.w3.org> From: jamsden@us.ibm.com X-Lotus-FromDomain: IBMUS To: w3c-dist-auth@w3.org Message-ID: <852567D1.004A398E.00@d54mta03.raleigh.ibm.com> Date: Wed, 18 Aug 1999 09:29:24 -0400 Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Subject: Re: LOCK Scenarios Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3167 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list A couple misunderstandings here. 1) I think Judith suggested that you were suggesting that depth and singleton locks at the destination be treated differently. At least that was my initial reading. I've not found evidence of you saying this though. As it turns out it looks like she missed the point of the distinction between your expectations and Kevin's. I think the point is not singleton vs. depth... or singleton vs inherited. The point is whether a LOCK that is rooted (singleton or not) at the destination URI survives. depth only applies to the parent of the destination resource when determining if the new destination gets the lock or not. I do not even consider the resource type or what kind of lock it has with respect to the COPY or MOVE operation because it doesn't matter, this lock is not retained. However, if the new parent collection is depth infinity locked, the destination will inherit the lock (regardless of what lock the deleted resource might have had), and if the destination is also a collection, it will have a depth infinity lock too. Just like it would if you had created the collection with MKCOL or a resource with PUT. BTW, I propose we use the phrases, "rooted at the URI" vs "inherited at the URI/resource" when talking about these locks. As far as vocabulary goes, there are also a few other cases that need vocabulary. I'll save that for a seperate note. I don't know what either of these phrases mean. A resource is locked or unlocked. A resource inherites any depth infinity lock of its parent collection, no matter how it became a member of that collection. 2) It sounds like you also think that having support for retaining a lock rooted on URI below a deleted URI is too messy to support. If so, we agree. That's why I made the proposal above. It eliminates everything that I'd consider a "special case". It does still leave the issue of if the destination URI remains locked. And lets the client decide that. I think this is more of a feature than a special case to handle. The client simply declares if he wants to retain the lock or not when he issues the DELETE. Depending on the implementation, the server might even find it *easier* to support the keeping of the lock. (AKA no code at all.) But the proposal would be for the server to support both behaviors at the DELETE request URI. I don't think the destination URL retains the lock of the resource that used to be at that destination unless it just happens to have the same depth infinity locked parent collection. But this would be a new lock with the timeout reset. 3) 8.10.5 says a DELETE destroys a lock at the destination. I think this is not optimal. A scenario is... /a/b exists and is a resource... not a collection. We want to replace it with a new resource that is a collection. But the spec says that MKCOL can not replace am existing resource (or collection). It requires that a delete be performed first. Now if one wants to accomplish this atomically (with LOCKS), right now one has several choices. a) LOCK /a/. It would probably be a depth 0 lock since there would be no point in locking at depth except possibly to prevent someone from tossing in another lock immediately after in the /a/b/... tree. But if they did chose to use a depth lock, they'd also risk being unable to get the lock if someone for example has a conflicting lock somehwere in a /a/c/ tree. It's a trade off. Depth or not, the other disadvantage of it is that they are also locking out any operations on /a/. The point is that if they decide to lock /a/, they are locking more than they need to and may interfere with other principles... or be blocked themselves. b) LOCK /a/b. But unfortunately with the current spec, the initial DELETE will destroy the lock. So this isn't really a choice unless we want to reissue the lock... to create a null lock which is better, but still risks problems if another entity beats us to the punch. It's a race condition. Now if we altered 8.10.5 to allow support for not deleting the lock, we could act surgically to insure that we get exactly the safe atomic behavior we want. (Ignoring a tangential caveat.) We lock /a/b possibly at depth. Do the delete specifying that we want the lock retained. Then do the MKCOL /a/b/ and any other operations we require. When done, release the lock. Once again ignoring an unspecified caveat, we know that as soon as we get the lock that we're going to be able to acomplish what we set out to do without another principle interfering. If we don't want this, then I think we need to evaluate why we support lock-null resources. I'd think the arguments for each of these are the same. There are a large number of situations in authoring environments where transaction semantics are required. WebDAV doesn't (yet) support transactions, and I don't think we should attempt to come up with a lot of special cases (like lock-null resources) supported by the protocol to overcome this important missing function. Rather let's propose an extension that does support transactions. Might be pretty hard with a stateless server though. BTW, my final comment above has prompted me to check into the history of destination lock deletion and lock-null resources... http://lists.w3.org/Archives/Public/w3c-dist-auth/1998OctDec/0245.html Here Yaron's solution to atomicity in COPY. It's not to support locks on the destination. It's to simply change the spec to say COPY should be implemented atomically. No explanation. Just his recomendation. Sounds reasonable. http://lists.w3.org/Archives/Public/w3c-dist-auth/1996OctDec/0041.html There was a time where deleting a resource didn't necessarily delete its lock. Nov 96. http://lists.w3.org/Archives/Public/w3c-dist-auth/1997AprJun/0135.html But deleting the destination lock was in there April 97. I could find no explanation for the change. It looks like they/Yaron decided to start from scratch and this was the result. -- I believe this is also where lock-null resources came in. No earlier references to this. No documentated rationale behind it. Yaron? From w3c-dist-auth-request@w3.org Wed Aug 18 14:40:05 1999 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20158 for ; Wed, 18 Aug 1999 14:40:05 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id OAA10291; Wed, 18 Aug 1999 14:27:29 -0400 (EDT) Resent-Date: Wed, 18 Aug 1999 14:27:29 -0400 (EDT) Resent-Message-Id: <199908181827.OAA10291@www19.w3.org> From: ccjason@us.ibm.com X-Lotus-FromDomain: IBMUS To: jamsden@us.ibm.com, w3c-dist-auth@w3.org Message-ID: <852567D1.00655AC1.00@D51MTA07.pok.ibm.com> Date: Wed, 18 Aug 1999 14:25:49 -0400 Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Subject: Re: LOCK Scenarios Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3168 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list BTW, I propose we use the phrases, "rooted at the URI" vs "inherited at the URI/resource" when talking about these locks. As far as vocabulary goes, there are also a few other cases that need vocabulary. I'll save that for a seperate note. I don't know what either of these phrases mean. A resource is locked or unlocked. A resource inherites any depth infinity lock of its parent collection, no matter how it became a member of that collection. As I said, I'll save the full vocabulary and lock/resource/URI discussion for another note. I'll just say here that for discussing the differences between the two proposals, we need terminology that describes the situation where the two proposals differ. The "Rooted" phrase refers to that situation. The situation where the earlier LOCK request was originally (to simplify) at the same URI that is now the destination of the MOVE. I don't think the destination URL retains the lock of the resource that used to be at that destination unless it just happens to have the same depth infinity locked parent collection. Right. That's where there is a difference of opinion. ...But this would be a new lock with the timeout reset. New lock? Perhaps I didn't understand what you just said above about "same.... parent". Please run that by me again. From w3c-dist-auth-request@w3.org Wed Aug 18 14:56:06 1999 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20538 for ; Wed, 18 Aug 1999 14:56:05 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id OAA10678; Wed, 18 Aug 1999 14:46:24 -0400 (EDT) Resent-Date: Wed, 18 Aug 1999 14:46:24 -0400 (EDT) Resent-Message-Id: <199908181846.OAA10678@www19.w3.org> From: ccjason@us.ibm.com X-Lotus-FromDomain: IBMUS To: jamsden@us.ibm.com cc: w3c-dist-auth@w3.org Message-ID: <852567D1.00671A46.00@D51MTA07.pok.ibm.com> Date: Wed, 18 Aug 1999 14:44:55 -0400 Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Subject: Re: DELETE leaving a lock-null resource; was LOCK Scenarios Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3169 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list 3) 8.10.5 says a DELETE destroys a lock at the destination. I think this is not optimal. A scenario is... /a/b exists and is a resource... not a collection. We want to replace it with a new resource that is a collection. But the spec says that MKCOL can not replace am existing resource (or collection). It requires that a delete be performed first. Now if one wants to accomplish this atomically (with LOCKS), right now one has several choices. a) LOCK /a/. It would probably be a depth 0 lock since there would be no point in locking at depth except possibly to prevent someone from tossing in another lock immediately after in the /a/b/... tree. But if they did chose to use a depth lock, they'd also risk being unable to get the lock if someone for example has a conflicting lock somehwere in a /a/c/ tree. It's a trade off. Depth or not, the other disadvantage of it is that they are also locking out any operations on /a/. The point is that if they decide to lock /a/, they are locking more than they need to and may interfere with other principles... or be blocked themselves. b) LOCK /a/b. But unfortunately with the current spec, the initial DELETE will destroy the lock. So this isn't really a choice unless we want to reissue the lock... to create a null lock which is better, but still risks problems if another entity beats us to the punch. It's a race condition. Now if we altered 8.10.5 to allow support for not deleting the lock, we could act surgically to insure that we get exactly the safe atomic behavior we want. (Ignoring a tangential caveat.) We lock /a/b possibly at depth. Do the delete specifying that we want the lock retained. Then do the MKCOL /a/b/ and any other operations we require. When done, release the lock. Once again ignoring an unspecified caveat, we know that as soon as we get the lock that we're going to be able to acomplish what we set out to do without another principle interfering. If we don't want this, then I think we need to evaluate why we support lock-null resources. I'd think the arguments for each of these are the same. There are a large number of situations in authoring environments where transaction semantics are required. WebDAV doesn't (yet) support transactions, and I don't think we should attempt to come up with a lot of special cases (like lock-null resources) supported by the protocol to overcome this important missing function. Rather let's propose an extension that does support transactions. Might be pretty hard with a stateless server though. So you're not a fan of lock-null resources either at this stage. That seems consistent. JimA and I have been doing all the talking for the last day. Anyone else want to be heard? :-) From w3c-dist-auth-request@w3.org Wed Aug 18 15:04:10 1999 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20901 for ; Wed, 18 Aug 1999 15:04:09 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id OAA11452; Wed, 18 Aug 1999 14:55:21 -0400 (EDT) Resent-Date: Wed, 18 Aug 1999 14:55:21 -0400 (EDT) Resent-Message-Id: <199908181855.OAA11452@www19.w3.org> From: jamsden@us.ibm.com X-Lotus-FromDomain: IBMUS To: w3c-dist-auth@w3.org Message-ID: <852567D1.0067EA3B.00@d54mta03.raleigh.ibm.com> Date: Wed, 18 Aug 1999 14:45:46 -0400 Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Subject: Re: LOCK Scenarios Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3170 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list From: Jason Crawford on 08/18/99 02:18 PM To: jamsden@us.ibm.com cc: Subject: Re: LOCK Scenarios (Document link not converted) I don't think the destination URL retains the lock of the resource that used to be at that destination unless it just happens to have the same depth infinity locked parent collection. Right. That's where there is a difference of opinion. I hope I am expressing what is currently in the spec rather than an opinion. I'm not opposed to changing the spec to something else, but I havn't seen anything yet that would motivate me to retain destination locks. ...But this would be a new lock with the timeout reset. New lock? Perhaps I didn't understand what you just said above about "same.... parent". Please run that by me again. Its a new lock on the destination (the new member of the parent collection), not a new lock on the parent collection. Again, just like you would get if you did a PUT or MKCOL to create a new resource in that collection. The new resource would get a new (to it) lock inherited from its parent. From w3c-dist-auth-request@w3.org Wed Aug 18 16:35:42 1999 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22734 for ; Wed, 18 Aug 1999 16:35:42 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id QAA14569; Wed, 18 Aug 1999 16:26:42 -0400 (EDT) Resent-Date: Wed, 18 Aug 1999 16:26:42 -0400 (EDT) Resent-Message-Id: <199908182026.QAA14569@www19.w3.org> Date: Wed, 18 Aug 1999 16:26:35 -0400 Message-Id: <9908182026.AA28734@tantalum> From: "Geoffrey M. Clemm" To: w3c-dist-auth@w3.org In-Reply-To: <852567D1.004A398E.00@d54mta03.raleigh.ibm.com> (jamsden@us.ibm.com) Subject: Re: LOCK Scenarios Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3171 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list ... The point is whether a LOCK that is rooted (singleton or not) at the destination URI survives. I see at least two reasons in favor of deleting the lock: - A MOVE/COPY just does a regular delete (with deletion of all locks), rather than a "special delete" which deletes all locks except for the one rooted at the destination URI. - The MOVE/COPY protocol doesn't have to deal with the complexity of applying the old lock to the new resource. I can easily imagine the creation of certain types of locks that only apply to certain types of resources. The MOVE/COPY protocol would then have to deal with all the error conditions that LOCK has to deal with. One clearly can extend the protocol to answer these questions, but it makes for a significantly more complicated protocol. ... The client simply declares if he wants to retain the lock or not when he issues the DELETE. Depending on the implementation, the server might even find it *easier* to support the keeping of the lock. (AKA no code at all.) A server has to delete all of the LOCK's rooted at descendents of the destination URI, so I don't see how it could be easier for it to delete all descendent locks, but not the lock at the URI. 8.10.5 says a DELETE destroys a lock at the destination. I think this is not optimal. A scenario is... /a/b exists and is a resource... not a collection. We want to replace it with a new resource that is a collection. But the spec says that MKCOL can not replace am existing resource (or collection). It requires that a delete be performed first. Now if one wants to accomplish this atomically (with LOCKS), right now one has several choices. ... I think this is better handled by just saying (as suggested by Yaron) that a COPY/MOVE should be performed atomically, and not bother with trying to use locking to achieve atomicity of COPY/MOVE. Cheers, Geoff From w3c-dist-auth-request@w3.org Wed Aug 18 17:50:44 1999 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27443 for ; Wed, 18 Aug 1999 17:50:44 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id RAA15808; Wed, 18 Aug 1999 17:34:06 -0400 (EDT) Resent-Date: Wed, 18 Aug 1999 17:34:06 -0400 (EDT) Resent-Message-Id: <199908182134.RAA15808@www19.w3.org> Date: Wed, 18 Aug 1999 17:33:57 -0400 Message-Id: <9908182133.AA28803@tantalum> From: "Geoffrey M. Clemm" To: JSlein@crt.xerox.com Cc: w3c-dist-auth@w3.org In-Reply-To: <8E3CFBC709A8D21191A400805F15E0DBD243DA@crte147.wc.eso.mc.xerox.com> (JSlein@crt.xerox.com) Subject: Re: Locking: Implementation Considerations Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3172 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list I believe that in the context of advanced collections (multiple bindings to a single resource) and versioning (multiple workspaces providing different views of the same URL hierarchy), Depth:infinity locking will be undesireable both for clients (does the wrong thing) and for servers (too expensive to implement). From the server side, Judy has described the difficulty of implementing Depth:infinity locking in the context of multiple bindings. With the introduction of versioning, with rule-based selection of each versioned collection on the URL path to a versioned resource, the cost of maintaining Depth:infinity locking increases to an even more unacceptable level. From the client side, a Depth:infinity write lock on a collection will lock all properties of all resources in the workspace's view of that collection. This effectively prevents labeling and creating successors of those resources by another user in *any* workspace, effectively eliminating many critical aspects parallel development. In contrast, Depth:0 locks work just fine, since normally you would apply them only to the working resources you have checked out, and those are not visible in other workspaces anyway. So what conclusion can one draw from all this? One possibility is to say that locking is largely unneccessary in the presence of versioning (after all, everything is read-only unless you explicitly check it out into your workspace), so versioning servers just won't bother with locking at all. This would have an unfortunate interoperability result on Class-2 clients try to work with versioning servers. Another possibility is to downgrade Depth:infinity locking to a MAY, thereby warning clients that they are likely to find this not supported, and to turn the default lock into Depth:0, instead of Depth:infinity. The latter will cause an interoperability issue with existing class-2 servers, but since there aren't many of those yet, if we move fast, this would probably be OK. Cheers, Geoff From: "Slein, Judith A" Date: Thu, 5 Aug 1999 17:13:56 -0400 Mime-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) charset="iso-8859-1" Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3120 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list Content-Type: text/plain; charset="iso-8859-1" Content-Length: 1787 One of the issues we've been talking about is what should happen if you MOVE a resource into a locked collection. What lock should be on the resource after the MOVE? I think the question is whether collection locks with Depth: infinity should be inherited statically or dynamically. Should a collection lock with Depth: infinity affect just those resources that are in the collection at the time the lock is created (static inheritance), or should the lock affect whatever resources come into the collection while it is in force (and stop applying to any resources that are removed from the collection) (dynamic inheritance)? Static inheritance suggests that the lock would be maintained on the collection and also maintained on each resource in the collection to depth infinity. It would be painful to create this lock, and painful to remove it, and while it is in force it would be necessary to keep track of the MOVEs out of the collection in order to be able to remove the lock correctly in the end. However, if every lock is maintained on each resource it affects, it is easy to tell whether a given resource is locked. Dynamic inheritance suggests that the lock would be maintained only on the collection. It is easy to create and remove such a lock. But it is difficult to tell whether any given resource is locked when someone attempts a PUT, MOVE, etc. Especially once the BIND method is available, you would have to trace from the resource in question upward through all the bindings on all the collections in the hierarchy to find out whether the resource is locked. Currently, section 7.7 of RFC 2518 requires dynamic inheritance of locks. From w3c-dist-auth-request@w3.org Wed Aug 18 18:56:44 1999 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29561 for ; Wed, 18 Aug 1999 18:56:43 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id SAA16899; Wed, 18 Aug 1999 18:47:30 -0400 (EDT) Resent-Date: Wed, 18 Aug 1999 18:47:30 -0400 (EDT) Resent-Message-Id: <199908182247.SAA16899@www19.w3.org> Message-ID: <00a201bee9cb$54610570$f0ff1f64@v85064> From: "Greg Stein" To: "Geoffrey M. Clemm" , Cc: References: <9908182133.AA28803@tantalum> Date: Wed, 18 Aug 1999 15:45:08 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Subject: Re: Locking: Implementation Considerations Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3173 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list Content-Transfer-Encoding: 7bit I'd be quite happy to dump Depth:infinity locks from mod_dav. There is a lot of code in there to deal with those things. Keith Wannamaker did a good job writing it all and may be sad to see it go :-), but in the best interest of things... I'm game. Cheers, -g ----- Original Message ----- From: Geoffrey M. Clemm To: Cc: Sent: Wednesday, August 18, 1999 2:33 PM Subject: Re: Locking: Implementation Considerations > I believe that in the context of advanced collections (multiple > bindings to a single resource) and versioning (multiple workspaces > providing different views of the same URL hierarchy), Depth:infinity > locking will be undesireable both for clients (does the wrong thing) > and for servers (too expensive to implement). > > >From the server side, Judy has described the difficulty of > implementing Depth:infinity locking in the context of multiple > bindings. With the introduction of versioning, with rule-based > selection of each versioned collection on the URL path to a versioned > resource, the cost of maintaining Depth:infinity locking increases to > an even more unacceptable level. > > >From the client side, a Depth:infinity write lock on a collection will > lock all properties of all resources in the workspace's view of that > collection. This effectively prevents labeling and creating > successors of those resources by another user in *any* workspace, > effectively eliminating many critical aspects parallel development. > > In contrast, Depth:0 locks work just fine, since normally you would apply > them only to the working resources you have checked out, and those are > not visible in other workspaces anyway. > > So what conclusion can one draw from all this? > > One possibility is to say that locking is largely unneccessary in the > presence of versioning (after all, everything is read-only unless you > explicitly check it out into your workspace), so versioning servers > just won't bother with locking at all. This would have an unfortunate > interoperability result on Class-2 clients try to work with versioning > servers. > > Another possibility is to downgrade Depth:infinity locking to a MAY, > thereby warning clients that they are likely to find this not supported, > and to turn the default lock into Depth:0, instead of Depth:infinity. > The latter will cause an interoperability issue with existing class-2 > servers, but since there aren't many of those yet, if we move fast, this > would probably be OK. > > Cheers, > Geoff > > From: "Slein, Judith A" > Date: Thu, 5 Aug 1999 17:13:56 -0400 > Mime-Version: 1.0 > X-Mailer: Internet Mail Service (5.5.2448.0) > charset="iso-8859-1" > Resent-From: w3c-dist-auth@w3.org > X-Mailing-List: archive/latest/3120 > X-Loop: w3c-dist-auth@w3.org > Sender: w3c-dist-auth-request@w3.org > Resent-Sender: w3c-dist-auth-request@w3.org > Precedence: list > Content-Type: text/plain; > charset="iso-8859-1" > Content-Length: 1787 > > One of the issues we've been talking about is what should happen if you MOVE > a resource into a locked collection. What lock should be on the resource > after the MOVE? > > I think the question is whether collection locks with Depth: infinity should > be inherited statically or dynamically. Should a collection lock with > Depth: infinity affect just those resources that are in the collection at > the time the lock is created (static inheritance), or should the lock affect > whatever resources come into the collection while it is in force (and stop > applying to any resources that are removed from the collection) (dynamic > inheritance)? > > Static inheritance suggests that the lock would be maintained on the > collection and also maintained on each resource in the collection to depth > infinity. It would be painful to create this lock, and painful to remove > it, and while it is in force it would be necessary to keep track of the > MOVEs out of the collection in order to be able to remove the lock correctly > in the end. However, if every lock is maintained on each resource it > affects, it is easy to tell whether a given resource is locked. > > Dynamic inheritance suggests that the lock would be maintained only on the > collection. It is easy to create and remove such a lock. But it is > difficult to tell whether any given resource is locked when someone attempts > a PUT, MOVE, etc. Especially once the BIND method is available, you would > have to trace from the resource in question upward through all the bindings > on all the collections in the hierarchy to find out whether the resource is > locked. > > Currently, section 7.7 of RFC 2518 requires dynamic inheritance of locks. From w3c-dist-auth-request@w3.org Wed Aug 18 19:05:04 1999 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA29846 for ; Wed, 18 Aug 1999 19:05:04 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id SAA17101; Wed, 18 Aug 1999 18:56:13 -0400 (EDT) Resent-Date: Wed, 18 Aug 1999 18:56:13 -0400 (EDT) Resent-Message-Id: <199908182256.SAA17101@www19.w3.org> From: "Kevin Wiggen" To: , Date: Wed, 18 Aug 1999 15:55:48 -0700 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.2910.0) Importance: Normal In-Reply-To: <852567D1.004A398E.00@d54mta03.raleigh.ibm.com> X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3155.0 Subject: RE: LOCK Scenarios Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3174 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list Content-Transfer-Encoding: 7bit OK not to make this any harder than it is.... But I have an issue on the Webdav Issues list that a move/copy should not do the DELETE by itself, ever. This gives the client complete control and forces them to do the delete before placing the file there. This way my server is not making any judgments about the existing resource for the user. On a side note this has already been a complaint multiple times on Sharemation, and it has only been up for 2 days. People think that a move/copy should be merging files, not overriding them. Especially since IE is telling them its doing a merge!!! And I quote "This folder already contains a folder named 'pictures'. If the files in the existing folder have the same name as files in the folder you are moving, they will be replaced. Do you still want to move the folder?" Now I am not saying we should do something because Microsoft does it, but this is the behavior I would be expecting.... If you follow this train of thought, if I replace 1 file with another, I would expect things like creation date to be left alone. I would expect that only the bytes would change. From this I would expect that any lock I had would still be there.... Maybe I am complicating things too much, but I just felt I should mention it... Kevin From w3c-dist-auth-request@w3.org Wed Aug 18 19:43:27 1999 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA00618 for ; Wed, 18 Aug 1999 19:43:26 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id TAA18136; Wed, 18 Aug 1999 19:31:51 -0400 (EDT) Resent-Date: Wed, 18 Aug 1999 19:31:51 -0400 (EDT) Resent-Message-Id: <199908182331.TAA18136@www19.w3.org> From: "Kevin Wiggen" To: , "Geoffrey M. Clemm" Cc: Date: Wed, 18 Aug 1999 16:31:25 -0700 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.2910.0) Importance: Normal In-Reply-To: <852567D0.00691803.00@D51MTA07.pok.ibm.com> X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3155.0 Subject: RE: LOCK Scenarios Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3175 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list Content-Transfer-Encoding: 7bit It appears to me that Jim Amsden's intuition and the current wording of the spec is more consistent than the "intended behavior". In particular, suppose you had three locks, on: /x /x/y /x/y/z.html Now suppose you MOVE'd a new collection to /x/y. I think we all agree that the lock on /x is unaffected. But what about the locks on /x/y and /x/y/z.html? The resource /x/y/z.html has been deleted due to the move to /x/y, therefore the lock there was removed. This does lead to an interesting situation where moving to /x/y can fail if you don't give the correct lock-token to /x/y/z.html. But I think this is a good thing. Again I note that there is no good response to the move for failures during the delete. The argument on /x/y is open I believe Obviously /x and /x/y are depth 0 locks otherwise they wouldn't have been created due to the other locks in the system. You don't need to give the lock-token for /x as its namespace is remaining consistent. It is consistent to say that all locks on deleted resources at the destination are removed (i.e. consistent with the fact that deleting a resource deletes its locks). It is also consistent (although somewhat more complicated) to say that the "delete" performed as a side effect of a MOVE is a special kind of delete that does not remove locks. But then neither the lock on /x/y *nor* the lock on /x/y/z.html should be affected, which means that if /x/y/z.html is not mapped to any resource following the MOVE, then a lock-null resource must auto-magically be created at /x/y/z.html after the MOVE. Again /x/y/z.html is deleted so the lock MUST be removed If so... there might not even be a collection at /x/y after the move which makes keeping a null lock at /x/y/z.html even odder. To date, all null locks have had collection resources at their PARENT URI. I'd vote that for now we limit the things so that the only lock that we'd consider retaining is at the DELETE's request URI. Any ancestor lock will be retained. Any descendent lock will not. Again I believe this is consistent as descendents will be deleted and therefore so will there locks... I think we need to start again with the use cases from Judith. There are now a number more. ccjason said a doc was being created. If I don't see it soon, I will create one. I think all the use cases need to be looked at... Again I think the major argument comes down to: 1) A lock locks a resource VRS 2) A lock locks the URL namespace I'd like to vote we keep infinity locks, but my argument might start "It took me a whole weekend to get that to work" :) But there must have been reasons to put it in there in the first place. Unfortunately I was not there for those conversations. Kevin From w3c-dist-auth-request@w3.org Thu Aug 19 01:04:23 1999 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA07919 for ; Thu, 19 Aug 1999 01:04:23 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id AAA29129; Thu, 19 Aug 1999 00:54:14 -0400 (EDT) Resent-Date: Thu, 19 Aug 1999 00:54:14 -0400 (EDT) Resent-Message-Id: <199908190454.AAA29129@www19.w3.org> From: ccjason@us.ibm.com X-Lotus-FromDomain: IBMUS To: "Geoffrey M. Clemm" cc: w3c-dist-auth@w3.org Message-ID: <852567D2.001AE747.00@D51MTA07.pok.ibm.com> Date: Thu, 19 Aug 1999 00:52:27 -0400 Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Subject: Re: LOCK Scenarios Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3176 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list ... The point is whether a LOCK that is rooted (singleton or not) at the destination URI survives. I see at least two reasons in favor of deleting the lock: - A MOVE/COPY just does a regular delete (with deletion of all locks), rather than a "special delete" which deletes all locks except for the one rooted at the destination URI. - The MOVE/COPY protocol doesn't have to deal with the complexity of applying the old lock to the new resource. I can easily imagine the creation of certain types of locks that only apply to certain types of resources. The MOVE/COPY protocol would then have to deal with all the error conditions that LOCK has to deal with. One clearly can extend the protocol to answer these questions, but it makes for a significantly more complicated protocol. The first reason would not be significant if we added the optional capability into DELETE that I suggested. I pointed out why it would be useful to add this capability to DELETE. The second problem would also be possible if the parent of the destination had a depth lock that was in conflict with the new resource(s) at the destination. If such class of locks exist, then the checking needs to be there anyway. Just one more lock to check. (Similar argument to what you use below... except supporting the opposite position.) ... The client simply declares if he wants to retain the lock or not when he issues the DELETE. Depending on the implementation, the server might even find it *easier* to support the keeping of the lock. (AKA no code at all.) A server has to delete all of the LOCK's rooted at descendents of the destination URI, so I don't see how it could be easier for it to delete all descendent locks, but not the lock at the URI. Good point. It's the nearly the same effort either way if there are a lot of locks rooted below. I wouldn't expect that to be common, but who knows... And the server would have to search for them anyway. That in itself could be relatively expensive depending on implementation and size of tree. Point well taken. As I said, the proposal would be that it would have to be supported either way though... so it was more importantly my point that it's not much harder. It's just the matter of optionally one less deleted lock. 8.10.5 says a DELETE destroys a lock at the destination. I think this is not optimal. A scenario is... /a/b exists and is a resource... not a collection. We want to replace it with a new resource that is a collection. But the spec says that MKCOL can not replace am existing resource (or collection). It requires that a delete be performed first. Now if one wants to accomplish this atomically (with LOCKS), right now one has several choices. ... I think this is better handled by just saying (as suggested by Yaron) that a COPY/MOVE should be performed atomically, and not bother with trying to use locking to achieve atomicity of COPY/MOVE. This wouldn't be addressing the issue of atomicity of the COPY/MOVE... although it would achieve that. It would be addressing the atomicity of the COPY/MOVE followed by something else if the client wanted it. The same applies to DELETE. There's something there you want to remove and replace with something else. The same applies to BIND with overwrite... I think. (See next note.) This capability addresses the same need that lock-null resources do now. Without them, you'd have to create the resource and then lock them and then do whatever else you had in mind. That's why I suggest that if we don't want this capability, we have to wonder about lock-null resources. From w3c-dist-auth-request@w3.org Thu Aug 19 09:17:53 1999 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA28974 for ; Thu, 19 Aug 1999 09:17:52 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id JAA06547; Thu, 19 Aug 1999 09:06:33 -0400 (EDT) Resent-Date: Thu, 19 Aug 1999 09:06:33 -0400 (EDT) Resent-Message-Id: <199908191306.JAA06547@www19.w3.org> From: jamsden@us.ibm.com X-Lotus-FromDomain: IBMUS To: w3c-dist-auth@w3.org Message-ID: <852567D2.0047FC45.00@d54mta03.raleigh.ibm.com> Date: Thu, 19 Aug 1999 09:06:00 -0400 Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Subject: Re: Locking: Implementation Considerations Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3177 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list I too would be happy to see Depth: infinity locks go. As Geoff says, they should be substantially unnecessary with versioning systems. They were hard and expensive to implement, and have the effect of reducing resource availability. Perhaps users should be more proactive about their locking and use clients to do "depth" locks when necessary instead of having this facility implemented directly in the server. A client could support a user interface consisting of a "Lock Deep" menu item on a selected collection which iterated over the members of the collection (recursively or not depending on a user option) and lock the members. This would require a lot of round trips, and would result in best-effort locking, but this shouldn't be a significant performance or usability constraint for the few times this capability should be used. "Greg Stein" on 08/18/99 06:45:08 PM To: "Geoffrey M. Clemm" , JSlein@crt.xerox.com cc: w3c-dist-auth@w3.org Subject: Re: Locking: Implementation Considerations I'd be quite happy to dump Depth:infinity locks from mod_dav. There is a lot of code in there to deal with those things. Keith Wannamaker did a good job writing it all and may be sad to see it go :-), but in the best interest of things... I'm game. Cheers, -g ----- Original Message ----- From: Geoffrey M. Clemm To: Cc: Sent: Wednesday, August 18, 1999 2:33 PM Subject: Re: Locking: Implementation Considerations > I believe that in the context of advanced collections (multiple > bindings to a single resource) and versioning (multiple workspaces > providing different views of the same URL hierarchy), Depth:infinity > locking will be undesireable both for clients (does the wrong thing) > and for servers (too expensive to implement). > > >From the server side, Judy has described the difficulty of > implementing Depth:infinity locking in the context of multiple > bindings. With the introduction of versioning, with rule-based > selection of each versioned collection on the URL path to a versioned > resource, the cost of maintaining Depth:infinity locking increases to > an even more unacceptable level. > > >From the client side, a Depth:infinity write lock on a collection will > lock all properties of all resources in the workspace's view of that > collection. This effectively prevents labeling and creating > successors of those resources by another user in *any* workspace, > effectively eliminating many critical aspects parallel development. > > In contrast, Depth:0 locks work just fine, since normally you would apply > them only to the working resources you have checked out, and those are > not visible in other workspaces anyway. > > So what conclusion can one draw from all this? > > One possibility is to say that locking is largely unneccessary in the > presence of versioning (after all, everything is read-only unless you > explicitly check it out into your workspace), so versioning servers > just won't bother with locking at all. This would have an unfortunate > interoperability result on Class-2 clients try to work with versioning > servers. > > Another possibility is to downgrade Depth:infinity locking to a MAY, > thereby warning clients that they are likely to find this not supported, > and to turn the default lock into Depth:0, instead of Depth:infinity. > The latter will cause an interoperability issue with existing class-2 > servers, but since there aren't many of those yet, if we move fast, this > would probably be OK. > > Cheers, > Geoff > > From: "Slein, Judith A" > Date: Thu, 5 Aug 1999 17:13:56 -0400 > Mime-Version: 1.0 > X-Mailer: Internet Mail Service (5.5.2448.0) > charset="iso-8859-1" > Resent-From: w3c-dist-auth@w3.org > X-Mailing-List: archive/latest/3120 > X-Loop: w3c-dist-auth@w3.org > Sender: w3c-dist-auth-request@w3.org > Resent-Sender: w3c-dist-auth-request@w3.org > Precedence: list > Content-Type: text/plain; > charset="iso-8859-1" > Content-Length: 1787 > > One of the issues we've been talking about is what should happen if you MOVE > a resource into a locked collection. What lock should be on the resource > after the MOVE? > > I think the question is whether collection locks with Depth: infinity should > be inherited statically or dynamically. Should a collection lock with > Depth: infinity affect just those resources that are in the collection at > the time the lock is created (static inheritance), or should the lock affect > whatever resources come into the collection while it is in force (and stop > applying to any resources that are removed from the collection) (dynamic > inheritance)? > > Static inheritance suggests that the lock would be maintained on the > collection and also maintained on each resource in the collection to depth > infinity. It would be painful to create this lock, and painful to remove > it, and while it is in force it would be necessary to keep track of the > MOVEs out of the collection in order to be able to remove the lock correctly > in the end. However, if every lock is maintained on each resource it > affects, it is easy to tell whether a given resource is locked. > > Dynamic inheritance suggests that the lock would be maintained only on the > collection. It is easy to create and remove such a lock. But it is > difficult to tell whether any given resource is locked when someone attempts > a PUT, MOVE, etc. Especially once the BIND method is available, you would > have to trace from the resource in question upward through all the bindings > on all the collections in the hierarchy to find out whether the resource is > locked. > > Currently, section 7.7 of RFC 2518 requires dynamic inheritance of locks. From w3c-dist-auth-request@w3.org Thu Aug 19 10:13:31 1999 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04289 for ; Thu, 19 Aug 1999 10:13:30 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id KAA08057; Thu, 19 Aug 1999 10:03:48 -0400 (EDT) Resent-Date: Thu, 19 Aug 1999 10:03:48 -0400 (EDT) Resent-Message-Id: <199908191403.KAA08057@www19.w3.org> Date: Thu, 19 Aug 1999 10:03:39 -0400 Message-Id: <9908191403.AA29315@tantalum> From: "Geoffrey M. Clemm" To: ccjason@us.ibm.com Cc: w3c-dist-auth@w3.org In-Reply-To: <852567D2.001AE747.00@D51MTA07.pok.ibm.com> (ccjason@us.ibm.com) Subject: Re: LOCK Scenarios Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3178 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list From: ccjason@us.ibm.com ... The point is whether a LOCK that is rooted (singleton or not) at the destination URI survives. I see at least two reasons in favor of deleting the lock: - A MOVE/COPY just does a regular delete (with deletion of all locks), rather than a "special delete" which deletes all locks except for the one rooted at the destination URI. - The MOVE/COPY protocol doesn't have to deal with the complexity of applying the old lock to the new resource. I can easily imagine the creation of certain types of locks that only apply to certain types of resources. The MOVE/COPY protocol would then have to deal with all the error conditions that LOCK has to deal with. The first reason would not be significant if we added the optional capability into DELETE that I suggested. I pointed out why it would be useful to add this capability to DELETE. I agree that adding the capability to DELETE would be more uniform than special-casing it for MOVE, but I'd prefer not having it in either case (for simplicity). The second problem would also be possible if the parent of the destination had a depth lock that was in conflict with the new resource(s) at the destination. If such class of locks exist, then the checking needs to be there anyway. Just one more lock to check. (Similar argument to what you use below... except supporting the opposite position.) I advocate removing "depth" locking from the spec (in the "Locking: Implementation Considerations" thread) for other reasons. In general, I am against all bits of the protocol which cause a lock to be "inherited", since this forces all the "resource creation" methods to have to deal with all the "LOCK" failure cases. So I'm against: - depth locking - lock-null resources - keeping the lock on the destination of a MOVE/COPY ... A scenario is... /a/b exists and is a resource... not a collection. We want to replace it with a new resource that is a collection. Now if one wants to accomplish this atomically (with LOCKS), right now one has several choices. ... I think this is better handled by just saying (as suggested by Yaron) that a COPY/MOVE should be performed atomically, and not bother with trying to use locking to achieve atomicity of COPY/MOVE. This wouldn't be addressing the issue of atomicity of the COPY/MOVE... although it would achieve that. It would be addressing the atomicity of the COPY/MOVE followed by something else if the client wanted it. I don't believe that LOCK's are a good technique for achieving atomicity of an arbitrary set of operations following the COPY/MOVE. The main problem is that a LOCK is a very coarse form of control, i.e. none of the properties or bodies of any of the members of a depth infinity lock can be modified by anyone. In a distributed authoring context, I believe an optimistic "modify/merge" paradigm scales much better. As long as the MOVE/COPY operations are atomic, you can perform all your changes in a personal copy, and then MOVE/COPY the result to its final destination. This capability addresses the same need that lock-null resources do now. Without them, you'd have to create the resource and then lock them and then do whatever else you had in mind. That's why I suggest that if we don't want this capability, we have to wonder about lock-null resources. I agree, and am against lock-null resources. I believe the protocol could be simplified with very little loss of functionality by just saying that if you want to achieve the effect of a lock-null resource, you just create an empty resource (e.g. a resource with an empty body) and then lock that real resource. So to summarize, I'm in favor of: - deleting lock-null resources from the spec - deleting depth locking from the spec - otherwise leaving alone the current wording in the spec of the effect of delete/move on locks Cheers, Geoff From w3c-dist-auth-request@w3.org Thu Aug 19 13:01:27 1999 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA11495 for ; Thu, 19 Aug 1999 13:01:26 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id MAA11937; Thu, 19 Aug 1999 12:52:34 -0400 (EDT) Resent-Date: Thu, 19 Aug 1999 12:52:34 -0400 (EDT) Resent-Message-Id: <199908191652.MAA11937@www19.w3.org> Message-ID: <078292D50C98D2118D090008C7E9C6A60194746A@STAY.platinum.corp.microsoft.com> From: "Yaron Goland (Exchange)" To: "'Kevin Wiggen'" , jamsden@us.ibm.com, w3c-dist-auth@w3.org Date: Thu, 19 Aug 1999 09:52:21 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: text/plain; charset="iso-8859-1" Subject: RE: LOCK Scenarios Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3179 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list BTW when we originally discussed this in WebDAV the conclusion was that a system like IE could handle the "merge" behavior on its own, without needing any help from the server. That is, it could pipeline a bunch of copy's w/overwrites. This wouldn't even hurt latency since the requests could be pipelined. However the reality is that things would probably be faster if there was a way to say "Hey, merge." So why not just add a header which specifies merge functionality? If you want to make sure it is honored then mark up with the request with mandatory. As for IE, sigh... I have forwarded the bug to the right folks but in the meanwhile it might make sense to put in a detection for IE's user agent and "do the right thing." I realize this sucks but bugs happen, especially amongst early adopters. Yaron > -----Original Message----- > From: Kevin Wiggen [mailto:wiggs@wiggenout.com] > Sent: Wednesday, August 18, 1999 3:56 PM > To: jamsden@us.ibm.com; w3c-dist-auth@w3.org > Subject: RE: LOCK Scenarios > > > > OK not to make this any harder than it is.... But I have an > issue on the > Webdav Issues list that a move/copy should not do the DELETE > by itself, > ever. This gives the client complete control and forces them > to do the > delete before placing the file there. This way my server is > not making any > judgments about the existing resource for the user. > > On a side note this has already been a complaint multiple times on > Sharemation, and it has only been up for 2 days. People think that a > move/copy should be merging files, not overriding them. > Especially since IE > is telling them its doing a merge!!! And I quote "This folder already > contains a folder named 'pictures'. If the files in the > existing folder > have the same name as files in the folder you are moving, they will be > replaced. Do you still want to move the folder?" > > Now I am not saying we should do something because Microsoft > does it, but > this is the behavior I would be expecting.... > > If you follow this train of thought, if I replace 1 file with > another, I > would expect things like creation date to be left alone. I > would expect > that only the bytes would change. From this I would expect > that any lock I > had would still be there.... > > Maybe I am complicating things too much, but I just felt I > should mention > it... > > Kevin > From w3c-dist-auth-request@w3.org Thu Aug 19 13:28:07 1999 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12241 for ; Thu, 19 Aug 1999 13:28:06 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id NAA12494; Thu, 19 Aug 1999 13:17:36 -0400 (EDT) Resent-Date: Thu, 19 Aug 1999 13:17:36 -0400 (EDT) Resent-Message-Id: <199908191717.NAA12494@www19.w3.org> Message-ID: <078292D50C98D2118D090008C7E9C6A60194746B@STAY.platinum.corp.microsoft.com> From: "Yaron Goland (Exchange)" To: "'jamsden@us.ibm.com'" , w3c-dist-auth@w3.org Date: Thu, 19 Aug 1999 10:17:24 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: text/plain; charset="windows-1252" Subject: RE: Locking: Implementation Considerations Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3180 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list I am scared that the server folk are riding rough shod over the needs of the client folk. This has been the rule, rather than the exception, in the HTTP world. There are huge numbers of server makers but very few client makers. Just take a look at www.webdav.org. There are roughly 17 servers and 5 clients and most of those clients were written by server guys who only provide APIs rather than real apps. In practice this means that the group often thinks it has rough consensus because all the server guys have agreed amongst themselves that they would like to make their lives easier. So please pay special attention to the painfully few client folk who are actually hanging around. As for depth infinity locks, I agree that this is hard for a server to implement. But it is also critical for a reasonable client to operate. For example, if I am going to go change my web site I don't know which files, in particular, I am going to change. So I want to make sure that the whole site is locked so I don't have to worry about anything becoming inconsistent while I wander around the site making changes. It is unrealistic to expect clients to send, even pipelined, series of lock requests because the chance of getting all those locks at once is low and having to constantly retry is unrealistic, especially because of the latency involved. Therefore clients MUST have depth infinity locks or WebDAV can't meet their needs. This having been said, I fully appreciate that depth infinity locks are hard to implement and may be inappropriate for versioning scenarios. I wouldn't have a problem with us saying that versioned resources won't support depth infinity. Frankly I think it would be inappropriate (and here I disagree w/the versioning group) for a level 2 client to work directly with versioned resources. I expect a more realistic scenario is that versioned systems will expose a particular view in a defined namespace and level 2 clients will then manipulate that view. It is in that view that depth infinity locking will be implemented. Yaron > -----Original Message----- > From: jamsden@us.ibm.com [mailto:jamsden@us.ibm.com] > Sent: Thursday, August 19, 1999 6:06 AM > To: w3c-dist-auth@w3.org > Subject: Re: Locking: Implementation Considerations > > > > > I too would be happy to see Depth: infinity locks go. As > Geoff says, they should > be substantially unnecessary with versioning systems. They > were hard and > expensive to implement, and have the effect of reducing > resource availability. > Perhaps users should be more proactive about their locking > and use clients to do > "depth" locks when necessary instead of having this facility > implemented > directly in the server. A client could support a user > interface consisting of a > "Lock Deep" menu item on a selected collection which iterated > over the members > of the collection (recursively or not depending on a user > option) and lock the > members. This would require a lot of round trips, and would result in > best-effort locking, but this shouldn't be a significant > performance or > usability constraint for the few times this capability should be used. > > > > > > "Greg Stein" on 08/18/99 06:45:08 PM > > To: "Geoffrey M. Clemm" , > JSlein@crt.xerox.com > cc: w3c-dist-auth@w3.org > > Subject: Re: Locking: Implementation Considerations > > > > > I'd be quite happy to dump Depth:infinity locks from mod_dav. > There is a lot > of code in there to deal with those things. Keith Wannamaker > did a good job > writing it all and may be sad to see it go :-), but in the > best interest of > things... I'm game. > > Cheers, > -g > > ----- Original Message ----- > From: Geoffrey M. Clemm > To: > Cc: > Sent: Wednesday, August 18, 1999 2:33 PM > Subject: Re: Locking: Implementation Considerations > > > > I believe that in the context of advanced collections (multiple > > bindings to a single resource) and versioning (multiple workspaces > > providing different views of the same URL hierarchy), Depth:infinity > > locking will be undesireable both for clients (does the wrong thing) > > and for servers (too expensive to implement). > > > > >From the server side, Judy has described the difficulty of > > implementing Depth:infinity locking in the context of multiple > > bindings. With the introduction of versioning, with rule-based > > selection of each versioned collection on the URL path to a > versioned > > resource, the cost of maintaining Depth:infinity locking > increases to > > an even more unacceptable level. > > > > >From the client side, a Depth:infinity write lock on a > collection will > > lock all properties of all resources in the workspace's view of that > > collection. This effectively prevents labeling and creating > > successors of those resources by another user in *any* workspace, > > effectively eliminating many critical aspects parallel development. > > > > In contrast, Depth:0 locks work just fine, since normally > you would apply > > them only to the working resources you have checked out, > and those are > > not visible in other workspaces anyway. > > > > So what conclusion can one draw from all this? > > > > One possibility is to say that locking is largely > unneccessary in the > > presence of versioning (after all, everything is read-only > unless you > > explicitly check it out into your workspace), so versioning servers > > just won't bother with locking at all. This would have an > unfortunate > > interoperability result on Class-2 clients try to work with > versioning > > servers. > > > > Another possibility is to downgrade Depth:infinity locking to a MAY, > > thereby warning clients that they are likely to find this > not supported, > > and to turn the default lock into Depth:0, instead of > Depth:infinity. > > The latter will cause an interoperability issue with > existing class-2 > > servers, but since there aren't many of those yet, if we > move fast, this > > would probably be OK. > > > > Cheers, > > Geoff > > > > From: "Slein, Judith A" > > Date: Thu, 5 Aug 1999 17:13:56 -0400 > > Mime-Version: 1.0 > > X-Mailer: Internet Mail Service (5.5.2448.0) > > charset="iso-8859-1" > > Resent-From: w3c-dist-auth@w3.org > > X-Mailing-List: archive/latest/3120 > > X-Loop: w3c-dist-auth@w3.org > > Sender: w3c-dist-auth-request@w3.org > > Resent-Sender: w3c-dist-auth-request@w3.org > > Precedence: list > > Content-Type: text/plain; > > charset="iso-8859-1" > > Content-Length: 1787 > > > > One of the issues we've been talking about is what > should happen if you > MOVE > > a resource into a locked collection. What lock should be on the > resource > > after the MOVE? > > > > I think the question is whether collection locks with > Depth: infinity > should > > be inherited statically or dynamically. Should a > collection lock with > > Depth: infinity affect just those resources that are in > the collection > at > > the time the lock is created (static inheritance), or > should the lock > affect > > whatever resources come into the collection while it is > in force (and > stop > > applying to any resources that are removed from the collection) > (dynamic > > inheritance)? > > > > Static inheritance suggests that the lock would be > maintained on the > > collection and also maintained on each resource in the > collection to > depth > > infinity. It would be painful to create this lock, and > painful to > remove > > it, and while it is in force it would be necessary to > keep track of the > > MOVEs out of the collection in order to be able to > remove the lock > correctly > > in the end. However, if every lock is maintained on > each resource it > > affects, it is easy to tell whether a given resource is locked. > > > > Dynamic inheritance suggests that the lock would be > maintained only on > the > > collection. It is easy to create and remove such a > lock. But it is > > difficult to tell whether any given resource is locked > when someone > attempts > > a PUT, MOVE, etc. Especially once the BIND method is > available, you > would > > have to trace from the resource in question upward > through all the > bindings > > on all the collections in the hierarchy to find out whether the > resource is > > locked. > > > > Currently, section 7.7 of RFC 2518 requires dynamic > inheritance of > locks. > > > > From w3c-dist-auth-request@w3.org Thu Aug 19 14:25:22 1999 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13672 for ; Thu, 19 Aug 1999 14:25:22 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id OAA14190; Thu, 19 Aug 1999 14:16:01 -0400 (EDT) Resent-Date: Thu, 19 Aug 1999 14:16:01 -0400 (EDT) Resent-Message-Id: <199908191816.OAA14190@www19.w3.org> From: ccjason@us.ibm.com X-Lotus-FromDomain: IBMUS To: w3c-dist-auth@w3.org Message-ID: <852567D2.00644C77.00@D51MTA07.pok.ibm.com> Date: Thu, 19 Aug 1999 14:14:09 -0400 Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Subject: LOCK NULL reserves what? Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3181 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list Whoops, I sent this to the wrong address last night.... My comments in my previous note remind me of something else. If I have a lock-null resource, and if someone places a lock on the parent collection, am I blocked from doing a BIND or MOVE on my lock-null URI? I believe the intent of the lock-null is to insure that we can do operations like PUT/MKCOL there... but I'd think that BIND and MOVE also apply... at least in intent... but that seems to conflict with what we've been saying about BIND/MOVE being an operation on the state of the parent collection... and thereby blocked if someone else locks the parent. Any thoughts? Yaron? :-) ------------------------------------------ Phone: 914-784-7569, ccjason@us.ibm.com From w3c-dist-auth-request@w3.org Thu Aug 19 14:57:29 1999 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14425 for ; Thu, 19 Aug 1999 14:57:28 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id OAA15257; Thu, 19 Aug 1999 14:48:45 -0400 (EDT) Resent-Date: Thu, 19 Aug 1999 14:48:45 -0400 (EDT) Resent-Message-Id: <199908191848.OAA15257@www19.w3.org> From: "Kevin Wiggen" To: , Date: Thu, 19 Aug 1999 11:42:42 -0700 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.2910.0) In-Reply-To: <852567D2.00644C77.00@D51MTA07.pok.ibm.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3155.0 Subject: RE: LOCK NULL reserves what? Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3182 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list Content-Transfer-Encoding: 7bit It is my understanding that locking a collection simply locks the namespace of the collection. If /a is locked by L1 and /a/b is locked by L2 Then to change /a/b I only need to give L2, since /a's namespace will not change. Thus if /a/b is a null-resource, and you have the lock, then you can change it at will through a PUT. MOVE/COPY are interesting in the fact that if the whole operation is not automic, then the Delete will fail due to the changing namespace.. I would assume that the MOVE/COPY would work without L1 if I were a client program. Is this not how it is supposed to work?? Kevin -----Original Message----- From: w3c-dist-auth-request@w3.org [mailto:w3c-dist-auth-request@w3.org]On Behalf Of ccjason@us.ibm.com Sent: Thursday, August 19, 1999 11:14 AM To: w3c-dist-auth@w3.org Subject: LOCK NULL reserves what? Whoops, I sent this to the wrong address last night.... My comments in my previous note remind me of something else. If I have a lock-null resource, and if someone places a lock on the parent collection, am I blocked from doing a BIND or MOVE on my lock-null URI? I believe the intent of the lock-null is to insure that we can do operations like PUT/MKCOL there... but I'd think that BIND and MOVE also apply... at least in intent... but that seems to conflict with what we've been saying about BIND/MOVE being an operation on the state of the parent collection... and thereby blocked if someone else locks the parent. Any thoughts? Yaron? :-) ------------------------------------------ Phone: 914-784-7569, ccjason@us.ibm.com From w3c-dist-auth-request@w3.org Thu Aug 19 17:39:18 1999 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA18281 for ; Thu, 19 Aug 1999 17:39:17 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id RAA18763; Thu, 19 Aug 1999 17:28:47 -0400 (EDT) Resent-Date: Thu, 19 Aug 1999 17:28:47 -0400 (EDT) Resent-Message-Id: <199908192128.RAA18763@www19.w3.org> Message-ID: <078292D50C98D2118D090008C7E9C6A601947480@STAY.platinum.corp.microsoft.com> From: "Yaron Goland (Exchange)" To: "'ccjason@us.ibm.com'" , w3c-dist-auth@w3.org Date: Thu, 19 Aug 1999 14:28:32 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: text/plain; charset="windows-1252" Subject: RE: LOCK NULL reserves what? Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3183 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list Step 1 - User A successfully take out an exclusive write lock on a/b, which is a lock null resource. Step 2 - User B tries to take out an exclusive write lock, depth = infinity on a/. The write lock will fail because a/b is already locked. Yaron > -----Original Message----- > From: ccjason@us.ibm.com [mailto:ccjason@us.ibm.com] > Sent: Thursday, August 19, 1999 11:14 AM > To: w3c-dist-auth@w3.org > Subject: LOCK NULL reserves what? > > > > Whoops, I sent this to the wrong address last night.... > > My comments in my previous note remind me of something else. > > If I have > a lock-null resource, and if someone places a lock on the > parent collection, am I blocked from doing a BIND or MOVE on my > lock-null URI? I believe the intent of the lock-null is to insure > that we can do operations like PUT/MKCOL there... but I'd think > that BIND and MOVE also apply... at least in intent... but that > seems to conflict with what we've been saying about BIND/MOVE > being an operation on the state of the parent collection... > and thereby blocked if someone else locks the parent. > Any thoughts? > > Yaron? :-) > > > ------------------------------------------ > Phone: 914-784-7569, ccjason@us.ibm.com > From w3c-dist-auth-request@w3.org Thu Aug 19 18:12:58 1999 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA19013 for ; Thu, 19 Aug 1999 18:12:58 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id SAA19765; Thu, 19 Aug 1999 18:04:34 -0400 (EDT) Resent-Date: Thu, 19 Aug 1999 18:04:34 -0400 (EDT) Resent-Message-Id: <199908192204.SAA19765@www19.w3.org> From: jamsden@us.ibm.com X-Lotus-FromDomain: IBMUS To: w3c-dist-auth@w3.org Message-ID: <852567D2.00793E5F.00@d54mta03.raleigh.ibm.com> Date: Thu, 19 Aug 1999 17:55:49 -0400 Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Subject: Re: LOCK NULL reserves what? Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3184 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list The intent is that a lock on the parent collection preserves that namespace by preventing the addition or removal of members. So any method that effects a DELETE would fail as it changes the namespace even though it might be temporary. The owner of the lock on the parent collection can change the collection members, and the owner of the lock on the lock-null resource can set the resource contents with PUT. But the owner of the lock-null resource cannot UNLOCK or DELETE the lock-null resource, or MOVE it to a different parent. ccjason@us.ibm.com on 08/19/99 02:14:09 PM To: w3c-dist-auth@w3.org cc: Subject: LOCK NULL reserves what? Whoops, I sent this to the wrong address last night.... My comments in my previous note remind me of something else. If I have a lock-null resource, and if someone places a lock on the parent collection, am I blocked from doing a BIND or MOVE on my lock-null URI? I believe the intent of the lock-null is to insure that we can do operations like PUT/MKCOL there... but I'd think that BIND and MOVE also apply... at least in intent... but that seems to conflict with what we've been saying about BIND/MOVE being an operation on the state of the parent collection... and thereby blocked if someone else locks the parent. Any thoughts? Yaron? :-) ------------------------------------------ Phone: 914-784-7569, ccjason@us.ibm.com From w3c-dist-auth-request@w3.org Thu Aug 19 19:58:14 1999 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA21110 for ; Thu, 19 Aug 1999 19:58:13 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id TAA21294; Thu, 19 Aug 1999 19:49:04 -0400 (EDT) Resent-Date: Thu, 19 Aug 1999 19:49:04 -0400 (EDT) Resent-Message-Id: <199908192349.TAA21294@www19.w3.org> From: ccjason@us.ibm.com X-Lotus-FromDomain: IBMUS To: "Yaron Goland (Exchange)" cc: w3c-dist-auth@w3.org Message-ID: <852567D2.0082CD2A.00@D51MTA07.pok.ibm.com> Date: Thu, 19 Aug 1999 19:47:24 -0400 Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Subject: RE: LOCK NULL reserves what? Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3185 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list >> Step 1 - User A successfully take out an exclusive write lock on a/b, which is a lock null resource. Step 2 - User B tries to take out an exclusive write lock, depth = infinity on a/. The write lock will fail because a/b is already locked. >> Perhaps I should have been clearer. What if step two is a singleton, not a depth lock request. Can User A do a BIND/MOVE/and other operations that we usually think of as modifying the state of /a/? I'm asking for the original design philosophy and the what we'd actually like to see now. Two questions. It does beg a second question. Reverse the order of the steps. Can the lock null resource be created if the parent is locked? I think the answer to this is easier. :-) From w3c-dist-auth-request@w3.org Thu Aug 19 20:38:26 1999 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA21740 for ; Thu, 19 Aug 1999 20:38:26 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id UAA22667; Thu, 19 Aug 1999 20:29:50 -0400 (EDT) Resent-Date: Thu, 19 Aug 1999 20:29:50 -0400 (EDT) Resent-Message-Id: <199908200029.UAA22667@www19.w3.org> From: ccjason@us.ibm.com X-Lotus-FromDomain: IBMUS To: "Geoffrey M. Clemm" cc: JSlein@crt.xerox.com, w3c-dist-auth@w3.org Message-ID: <852567D3.0002B3B6.00@D51MTA07.pok.ibm.com> Date: Thu, 19 Aug 1999 20:28:15 -0400 Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Subject: Re: Locking: Implementation Considerations Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3186 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list GEoff, before you go on vacation, it would probably be valuable if you were your own devil's advocate here.... So what conclusion can one draw from all this? One possibility is to say that locking is largely unneccessary in the presence of versioning (after all, everything is read-only unless you explicitly check it out into your workspace), so versioning servers just won't bother with locking at all. This would have an unfortunate interoperability result on Class-2 clients try to work with versioning servers. So why *NOT* let versioning replace locking? Is there a form of locking that provides value add over versioning? How mature is the versioning work? Be your own devil's advocate... Another possibility is to downgrade Depth:infinity locking to a MAY, thereby warning clients that they are likely to find this not supported, and to turn the default lock into Depth:0, instead of Depth:infinity. The latter will cause an interoperability issue with existing class-2 servers, but since there aren't many of those yet, if we move fast, this would probably be OK. There must be issues with your first proposal or you wouldn't have offered this one. Let's hear them. :-) I just want to get your thoughts here before you go. I'm sure we'll all be discussing this while you're gone. Cheers, Jason. From w3c-dist-auth-request@w3.org Fri Aug 20 09:46:20 1999 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19917 for ; Fri, 20 Aug 1999 09:46:19 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id JAA02237; Fri, 20 Aug 1999 09:35:58 -0400 (EDT) Resent-Date: Fri, 20 Aug 1999 09:35:58 -0400 (EDT) Resent-Message-Id: <199908201335.JAA02237@www19.w3.org> Date: Fri, 20 Aug 1999 09:35:14 -0400 Message-Id: <9908201335.AA29957@tantalum> From: "Geoffrey M. Clemm" To: ccjason@us.ibm.com Cc: JSlein@crt.xerox.com, w3c-dist-auth@w3.org In-Reply-To: <852567D3.0002B3B6.00@D51MTA07.pok.ibm.com> (ccjason@us.ibm.com) Subject: Re: Locking: Implementation Considerations Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3187 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list From: ccjason@us.ibm.com Geoff, before you go on vacation, it would probably be valuable if you were your own devil's advocate here.... I always like a good debate, even with myself (:-). So what conclusion can one draw from all this? One possibility is to say that locking is largely unneccessary in the presence of versioning (after all, everything is read-only unless you explicitly check it out into your workspace), so versioning servers just won't bother with locking at all. This would have an unfortunate interoperability result on Class-2 clients try to work with versioning servers. So why *NOT* let versioning replace locking? Is there a form of locking that provides value add over versioning? Versioning is harder to provide than "simple single resource at a time" locking (ssraat locking :-). But ssraat locking is very useful for various simple use cases (I'm working on these two resources ... I lock them while I'm doing so). So I see a variety of clients getting significant benefit out of ssraat locking, and it's nice and lightweight for servers to implement (well, not so lightweight in the presence of bindings, but still doable). But if you extend locking to depth:infinity locking of collections, the utility to clients drops dramatically. It appears to work just fine while there is just a single client (but then you didn't need to lock in the first place). But as soon as you get a few clients trying to get work done, the simplicity of just "locking the whole collection" when you want to work on some of the members inevitably leads to gratuitous lockout. Most of the resources locked by a depth:infinity lock are commonly *not* ones you are going to change, and even the usually harmless operation of adding a new member to a collection is locked out. Even worse, all the properties of those members are locked as well. In contrast sraat locking encourages the client to just lock the resources they really expect to modify, so when another client collides with the lock, you really are preventing an overwrite situation. Of course, a client could just walk the whole collection and place depth:0 locks on every member, but at least we aren't encouraging them to do so. This argument so far is based solely on the dis-utility of depth:infinity locking from a clients perspective. Let's go devil's advocate for a moment: "Then clients can simply just not use depth:infinity locks if they have these bad effects." But now lets look at it from a servers point of view (clearly the devil needs a much better advocate than me :-). To handle clients that *do* chose to use depth:infinity locks (because they haven't yet figured out how bad they are :-), you still have to pay the price of implementing them. The added complexity of lock-null and depth:infinity is likely to significantly *decrease* the interoperability of clients and servers, both because some servers will consciously cut various corners and because the of the high likelihood of servers handling edge cases differently. Now lets add in the presence of versioning (note that all the preceding arguments apply irrespective of the existence of versioning support). You now have workspaces that share common revisions but that have their own "working resource" for resources that are being modified in that workspace. Ssraat locking works just fine, since the lock is being applied to the resources being modified (i.e. the checked-out working resources). On the other hand, depth:infinity locks apply to all the *shared* revisions, effectively locking out key versioning operations (such as labeling) on all the shared resources. So in summary, the argument is that depth:infinity provides marginal utility for locking-only clients, provides significant cost/complexity for locking-only servers, decreases interoperability due to this cost/complexity, and is incompatible with versioning. How mature is the versioning work? Be your own devil's advocate... Even if we had no plans of ever producing a versioning protocol, I'd still be against depth:infinity locking and lock-null resources. (And thus he adroitly dodges the request to denigrate the versioning work :-). Another possibility is to downgrade Depth:infinity locking to a MAY, thereby warning clients that they are likely to find this not supported, and to turn the default lock into Depth:0, instead of Depth:infinity. The latter will cause an interoperability issue with existing class-2 servers, but since there aren't many of those yet, if we move fast, this would probably be OK. There must be issues with your first proposal or you wouldn't have offered this one. Let's hear them. :-) Actually, that was just a pre-emptive strike in case someone came up with some convincing reasons why they just had to have depth:infinity locking. I don't have any, and I'd rather just simplify the spec (i.e. the first proposal), so the second proposal is (in my view) just an inferior alternative proposal. Cheers, Geoff From w3c-dist-auth-request@w3.org Fri Aug 20 10:41:31 1999 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23750 for ; Fri, 20 Aug 1999 10:41:31 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id KAA03486; Fri, 20 Aug 1999 10:32:18 -0400 (EDT) Resent-Date: Fri, 20 Aug 1999 10:32:18 -0400 (EDT) Resent-Message-Id: <199908201432.KAA03486@www19.w3.org> From: ccjason@us.ibm.com X-Lotus-FromDomain: IBMUS To: "Geoffrey M. Clemm" cc: w3c-dist-auth@w3.org, JSlein@crt.xerox.com Message-ID: <852567D3.004FCD04.00@D51MTA07.pok.ibm.com> Date: Fri, 20 Aug 1999 10:30:06 -0400 Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Subject: Re: Locking: Implementation Considerations Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3188 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list So in summary... It is your opinion that the versioning work provides all of the (current) benefits of locking (presumably with a merge phase), but it is hard to implement so you offer the option of adding ssraat. Did I get that right? You mention a scenario where ssraat is used in combination with versioning. That suggests that you feel locking provides something that versioning doesn't.... is that the case? (And thus he adroitly dodges the request to denigrate the versioning work :-). Cheater! :-) I think you or someone will have to answer this if we're to consider versioning to be a partial or true alternative to locking. Otherwise, we'll just have to evaluate your proposals to remove depthlock and null lock on each of their own merits. J. From w3c-dist-auth-request@w3.org Fri Aug 20 16:11:56 1999 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10925 for ; Fri, 20 Aug 1999 16:11:56 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id QAA10221; Fri, 20 Aug 1999 16:02:39 -0400 (EDT) Resent-Date: Fri, 20 Aug 1999 16:02:39 -0400 (EDT) Resent-Message-Id: <199908202002.QAA10221@www19.w3.org> Date: Fri, 20 Aug 1999 16:02:26 -0400 Message-Id: <9908202002.AA00246@tantalum> From: "Geoffrey M. Clemm" To: ccjason@us.ibm.com Cc: w3c-dist-auth@w3.org, JSlein@crt.xerox.com In-Reply-To: <852567D3.004FCD04.00@D51MTA07.pok.ibm.com> (ccjason@us.ibm.com) Subject: Re: Locking: Implementation Considerations Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3189 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list From: ccjason@us.ibm.com So in summary... It is your opinion that the versioning work provides all of the (current) benefits of locking (presumably with a merge phase), but it is hard to implement so you offer the option of adding depth:0 locking. Did I get that right? Yup. I'd only modify that slightly to say it is *harder* to implement versioning than depth:0 locking, but I wouldn't say it is *hard* to implement versioning. You mention a scenario where depth:0 locking is used in combination with versioning. That suggests that you feel locking provides something that versioning doesn't.... is that the case? Not quite. In my opinion, locking is unneccessary if you have versioning support, but I do care that locking clients interoperate with versioning servers, so that is why I care about the combination of locking and versioning. (And thus he adroitly dodges the request to denigrate the versioning work :-). Cheater! :-) I think you or someone will have to answer this if we're to consider versioning to be a partial or true alternative to locking. Otherwise, we'll just have to evaluate your proposals to remove depthlock and null lock on each of their own merits. Initially, lets just do the latter (i.e. evaluate the removal of depthlock and null lock on their own merits). I believe that Depth:0 locking is a good thing and stands on its own as worthwhile functionality. I believe Depth:infinity locking is a bad thing, both for it's effect on clients trying to cooperate, and on servers trying to implement the protocol in an interoperable way. If we end up agreeing on those points, then we don't have to spend the time/effort in discussing the incompatibility of Depth:infinity with versioning, and the ways in which versioning might provide a superior alternative to Depth:infinity locking. Cheers, Geoff From w3c-dist-auth-request@w3.org Fri Aug 20 21:04:56 1999 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA16931 for ; Fri, 20 Aug 1999 21:04:56 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id UAA18942; Fri, 20 Aug 1999 20:56:19 -0400 (EDT) Resent-Date: Fri, 20 Aug 1999 20:56:19 -0400 (EDT) Resent-Message-Id: <199908210056.UAA18942@www19.w3.org> From: "Kevin Wiggen" To: Date: Fri, 20 Aug 1999 17:55:54 -0700 Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0000_01BEEB35.3FCDD280" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3155.0 Subject: Fun w/ Proxies-Firewalls Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3190 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list This is a multi-part message in MIME format. ------=_NextPart_000_0000_01BEEB35.3FCDD280 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Just thought I would report to everyone what I found today on Firewalls and Proxies. If anyone has any data in this area, please tell me... Web Folders. 1) Run with no proxies set at a non-SSL port. - Works fine 2) Run with a proxy server at a non-SSL port - FAILS 3) Run with no proxies set at a SSL port - Works fine 4) Run with a proxy server at a SSL port - Works fine It seems that the code line which does proxies without SSL is missing the Webdav code. IE or Office will simply send the GET and POST with the /_vti stuff. It never even tries to do an options. This all occurs when the Tools -> Internet Options -> Connections -> LAN settings -> Use a proxy server checkbox is clicked. Does anyone have a workaround for this without forcing the use of SSL? Is this consistent with what other people are finding? Thanks, Kevin ------=_NextPart_000_0000_01BEEB35.3FCDD280 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Just = thought I would=20 report to everyone what I found today on Firewalls and Proxies.  If = anyone=20 has any data in this area, please tell me...
 
Web=20 Folders.
 
1)  Run with no=20 proxies set at a non-SSL port.  - Works fine
2)  Run with a=20 proxy server at a non-SSL port - FAILS
3)  Run with no=20 proxies set at a SSL port - Works fine
4)  Run with a=20 proxy server at a SSL port - Works fine
 
It = seems that the=20 code line which does proxies without SSL is missing the=20 Webdav code.
 
IE or=20 Office will simply send the GET and POST with the /_vti = stuff. =20 It never even tries to do an options.  This all occurs = when the=20 Tools -> Internet Options -> Connections -> LAN settings -> = Use a=20 proxy server checkbox is clicked.
 
Does = anyone have a=20 workaround for this without forcing the use of SSL?  Is this=20 consistent with what other people are finding?  =
 
Thanks,
Kevin 
------=_NextPart_000_0000_01BEEB35.3FCDD280-- From w3c-dist-auth-request@w3.org Sat Aug 21 05:12:47 1999 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA04783 for ; Sat, 21 Aug 1999 05:12:43 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id FAA27914; Sat, 21 Aug 1999 05:03:11 -0400 (EDT) Resent-Date: Sat, 21 Aug 1999 05:03:11 -0400 (EDT) Resent-Message-Id: <199908210903.FAA27914@www19.w3.org> Date: Sat, 21 Aug 1999 10:02:40 +0100 (BST) From: Joe Orton X-Sender: joe@ankh.orton.local To: Kevin Wiggen cc: w3c-dist-auth@w3.org In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: Re: Fun w/ Proxies-Firewalls Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3191 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list > IE or Office will simply send the GET and POST with the /_vti stuff. It > never even tries to do an options. This all occurs when the Tools -> > Internet Options -> Connections -> LAN settings -> Use a proxy server > checkbox is clicked. We found some (HTTP/1.0) proxies don't let through 'extension' methods like OPTIONS, let alone MKCOL, DELETE etc. Maybe IE is trying an OPTIONS and the proxy blocks it from getting to the server, so it falls back on GET/POST? joe -- Joe Orton joe@orton.demon.co.uk ... jeo101@york.ac.uk http://www.orton.demon.co.uk/ From w3c-dist-auth-request@w3.org Sat Aug 21 12:43:42 1999 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08770 for ; Sat, 21 Aug 1999 12:43:42 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id MAA01516; Sat, 21 Aug 1999 12:33:29 -0400 (EDT) Resent-Date: Sat, 21 Aug 1999 12:33:29 -0400 (EDT) Resent-Message-Id: <199908211633.MAA01516@www19.w3.org> From: "Kevin Wiggen" To: "Joe Orton" Cc: Date: Sat, 21 Aug 1999 09:32:46 -0700 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.2910.0) In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3155.0 Subject: RE: Fun w/ Proxies-Firewalls Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3192 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list Content-Transfer-Encoding: 7bit This is a good point. I was working with Raptor v5 & v6 for HTTP proxy services, a Squid?? (that one is a friend of mine) proxy, and the JavaWebserver Proxy. We were looking at the Logs of the Proxies as we went. When the checkbox for "use proxy" is set in IE, it simply never sends the OPTIONS request.... On that same note, if your client mistakenly sends an OPTIONS with a HTTP/1.0 Header, most Firewalls I looked at will block it. So be careful. (I noticed that the GET /_vti stuff still sends HTTP/1.0 headers. I thought this might be the problem, but by viewing the logs it was not) In viewing the Sharemation logs, there are some OPTIONS requests with the 1.0 Header. The following is out of the Raptor FAQ: 219 Can't parse URL: (OPTIONS * HTTP/1.0 ...... The browser requested the use of the OPTIONS methods, but OPTIONS is not part of the HTTP/1.0 standard. It is part of HTTP/1.1. The browser may be allowed to ask for it, but it should specify HTTP/1.1 in the request header. The Raptor Firewall acts correctly in refusing to support it. Kevin From w3c-dist-auth-request@w3.org Sat Aug 21 18:55:24 1999 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13492 for ; Sat, 21 Aug 1999 18:55:24 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id SAA04257; Sat, 21 Aug 1999 18:40:56 -0400 (EDT) Resent-Date: Sat, 21 Aug 1999 18:40:56 -0400 (EDT) Resent-Message-Id: <199908212240.SAA04257@www19.w3.org> Message-ID: <078292D50C98D2118D090008C7E9C6A603C964EE@STAY.platinum.corp.microsoft.com> From: "Yaron Goland (Exchange)" To: "'Kevin Wiggen'" , Joe Orton Cc: w3c-dist-auth@w3.org Date: Sat, 21 Aug 1999 15:40:36 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.14) Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Fun w/ Proxies-Firewalls Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3193 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list 1. The Raptor text is nonsense. Anyone can send any method they damn well please over 1.0 or 1.1. Saying OPTIONS is not part of HTTP/1.0 is like saying you can't use any functions in C that aren't defined in K&R. Now, their complaint about the use of "*" is more reasonable but since they apparently support the host header they really have nothing to complain about. They should just act dumb and blindly pass it on. 2. Any windows system running WebDAV must be using at least IE 5.0 and IE 5.0 defaults to HTTP/1.0 whenever it talks to a proxy. This behavior can be overridden if you can reach deep enough into tools - internet options - advanced - HTTP/1.1 settings. The reason for this behavior is that we found a number of 1.0 proxies which do not change the version number on requests/responses to 1.0. I send a 1.1 request to the proxy and get back a 1.1 response, so I figure I'm on a 1.1 clean connection, then things go bad because I'm not. Now the via header would be a real good tip off here but what happens if the first proxy really is 1.1 but the next one isn't? All these problems have work arounds but in practice nobody implemented them, so we decided to stay on the safe side. This shouldn't, however, have stopped Web Folders from working through a proxy. 3. I just connected to http://msdav.lyra.org/dav/ and http://sandbox.xerox.com:8080/ through a MS proxy using web folders w/out any problem. The entire communication was over HTTP/1.0. Yaron > -----Original Message----- > From: Kevin Wiggen [mailto:wiggs@wiggenout.com] > Sent: Saturday, August 21, 1999 9:33 AM > To: Joe Orton > Cc: w3c-dist-auth@w3.org > Subject: RE: Fun w/ Proxies-Firewalls > > > > This is a good point. I was working with Raptor v5 & v6 for > HTTP proxy > services, a Squid?? (that one is a friend of mine) proxy, and the > JavaWebserver Proxy. > > We were looking at the Logs of the Proxies as we went. When > the checkbox > for "use proxy" is set in IE, it simply never sends the > OPTIONS request.... > > On that same note, if your client mistakenly sends an OPTIONS with a > HTTP/1.0 Header, most Firewalls I looked at will block it. > So be careful. > (I noticed that the GET /_vti stuff still sends HTTP/1.0 > headers. I thought > this might be the problem, but by viewing the logs it was > not) In viewing > the Sharemation logs, there are some OPTIONS requests with > the 1.0 Header. > The following is out of the Raptor FAQ: > > > 219 Can't parse URL: (OPTIONS * HTTP/1.0 ...... > The browser requested the use of the OPTIONS methods, but > OPTIONS is not > part of the HTTP/1.0 standard. It is part of HTTP/1.1. The > browser may be > allowed to ask for it, but it should specify HTTP/1.1 in the > request header. > The Raptor Firewall acts correctly in refusing to support it. > > > Kevin > From w3c-dist-auth-request@w3.org Mon Aug 23 13:35:35 1999 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24747 for ; Mon, 23 Aug 1999 13:35:34 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id NAA07579; Mon, 23 Aug 1999 13:19:04 -0400 (EDT) Resent-Date: Mon, 23 Aug 1999 13:19:04 -0400 (EDT) Resent-Message-Id: <199908231719.NAA07579@www19.w3.org> From: Jim Whitehead To: WebDAV WG Date: Mon, 23 Aug 1999 10:13:29 -0700 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.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Subject: Mozilla editor and DAV Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3194 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list Content-Transfer-Encoding: 7bit Just wanted to pass along some Mozilla information I heard last week. Turns out that, at present, no one on the Mozilla team is working on integrating WebDAV functionality, a definite bummer. But, it appears that now would be a very good time for volunteers to join the Mozilla team and implement DAV, since the Mozilla editor is currently being re-built, and it would presumably be fairly easy to add WebDAV support in during this rebuild process. http://www.mozilla.org/editor/ is the site for work on the Mozilla editor (I've been having trouble accessing it this morning, though). - Jim From w3c-dist-auth-request@w3.org Mon Aug 23 15:45:16 1999 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27035 for ; Mon, 23 Aug 1999 15:45:14 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id PAA11736; Mon, 23 Aug 1999 15:34:26 -0400 (EDT) Resent-Date: Mon, 23 Aug 1999 15:34:26 -0400 (EDT) Resent-Message-Id: <199908231934.PAA11736@www19.w3.org> From: jamsden@us.ibm.com X-Lotus-FromDomain: IBMUS To: w3c-dist-auth@w3.org Message-ID: <852567D6.006B7708.00@d54mta03.raleigh.ibm.com> Date: Mon, 23 Aug 1999 15:32:29 -0400 Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Subject: Advanced Collections-04 Review Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3195 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list Here's my review of the advanced collections spec 04. I tried to keep my comments based on the order of the spec to uncover anything a new reader might have trouble with. This is a nice piece of work. In particular, the BIND method seems to be just what we need. However, redirect references still seem pretty complex and full of special cases. It would require doing an implementation to root out all the detailed issues, but the specification as it stands is pretty close to what we need in order to start implementing. Thanks to the authors for all the hard work they put into this. Last paragraph, section 3 Introduction: Might be helpful to say this specification defines client specified, server maintained orderings. Its not clear that the server is not supporting the ordering, only maintaining an ordering given by a client. 4.1, second bullet: HTTP servers provide URI mappings, but no protocol for specifying them. Must be done in server-dependent configuration and often requires server restart. Last bullet: making support for cross-server bindings optional does not eliminate the referential integrity problem caused by disconnected servers. So a server could support cross-server bindings sometimes, but not at other times if the server is disconnected. Unfortunately, this is stateful and depends on connectivity, not anything to with the bindings themselves. So referential integrity could never be guaranteed, and either must be optional or cross-server bindings must be prohibited. 4.2, 1st paragraph: aren't bindings a many-to-1 relationship between URI mappings to resources? Can't a collection have more than one binding to the same internal member? Note that the definition of internal member given in this specification implies that a resource can be an internal member of more than one collection. Cross-server bindings: would it be acceptable to 1) refuse to delete a resource that would create dangling references? 2) only delete the binding, and employ some garbage collection algorithm (including leaving the garbage)? and/or 3) delete the resource and all references if it can be known (through say reference counts) that there are no other references? Should these suggestions be added to the spec to indicate possible ways referential integrity could be maintained across servers? 4.2.1 says that a Request-URI ending in a "/" must bind to a collection, but does not indicate a Request-URI NOT ending in a "/" CAN bind to a collection too. 4.2.2 506 (Loop Detected) is a server error status code, but this is likely a successful operation that clients mostly don't care about. Should be a 2xx status code? I had trouble making sense of section 4.2.3. What's a non-WebDAV collection or non-WebDAV advanced collection? Where is domain name variant defined? What is the authority part of a URL? Should step 4 be left to right? How is S bound to R in step 4? Does this algorithm only apply to bindings whose destination is a collection? The example in 4.2.4 uses the destination URL not the request URL as specified in 4.2.3. Are users expected to understand and use this algorithm in order to know what is bound to what? Section 4.2.5, 409 (Conflict): so the binding is only created for the right-most path segment. All other collections in the path segment must already exist? BIND doesn't create bindings for these path segments in their parent directory too? In example 4.2.6, collection /~whitehead/dav/ must already exist? The bind operation wouldn't create a binding for dav if it didn't already exist? Example 4.2.7: the existence of / should not be required. The binding should have been created although it is probably not what the user intended. In all other cases, WebDAV behaves as if the / were present, and returns any URI's with the / added. BIND should be consistent with this convention. In any case, this error condition is not described in section 4.2.5. Should section 8.6.1 of [WebDAV] be corrected so the last paragraph of 4.2.8 isn't necessary? 4.2.9, 2nd paragraph: if depth is specified for the COPY method, it must be Depth: infinity. Depth: 0 or 1 is not allowed. Section 4.2.10: The semantics of MOVE are fine, but they are different than [WebDAV]. In this case, the resource is not moved at all, only bindings to the resource are manipulated. The implication is that the resource is unchanged. Its the same resource in the same physical storage location on the same server, etc. This is not the case with [WebDAV], and may not be what was desired. Perhaps there are two MOVE operations that need to be distinguished. Note that COPY created R' while MOVE didn't. Another possible outcome for the example is that a new resource is created R' which is a copy of R, and URI 1, URI 2, and URIX are all bound to R'. All bindings to R are deleted. This interpretation is consistent with [WebDAV]. Second to the last sentence in the last paragraph: ... request-URI cannot be moved. Section 4.2.10.1: OK, we're in agreement. However, it is not clear what server writers are required to do with implementation notes. It also seems the protocol should not be specifying anything about implementation. Perhaps these two sections can be replaced by one that specifies a logical move where either implementation would be valid. Or, these are not equivalent logical operations and clients may wish to distinguish them. (I don't think so though as the client probably couldn't tell the difference). Section 4.2.12: Seems to assume that all bindings have the same behavior if they are bindings to the same resource. However, servers do special things with non-WebDAV collection names (acting as functors) such as cgi-bin, servlet, etc. In this case, different bindings to the same resource will behave very differently. The 4th paragraph on PUT may not be possible due to the effect of these functors. Should we introduce a new DAV property that provides a GUID for each resource that can act as an identifier for that resource? Then we can determine if two bindings are to the same resource by examining a property. Note that just because the contents and properties are the same for a pair of resources, this does not mean they are the same resource. 4.2.13: If the optional DAV:bindings property exists for a resource, does it have to contain ALL the bindings? Even those from other servers? Is this optional on a server or resource basis? 4.3, last paragraph: the semantics of the Passthrough header seem to be described in reverse. The last sentence of the last paragraph sounds like a NoPassthrough header, not Passthrough. The default should be to return the properties of the reference or return a 302. Why not return a 302 of the Passthrough header is not present, and if it is present, it must be a referencing-aware client and just do what the header says. "T" means Passthrough to the target and don't return a 302. "F" means operate on the reference. Second paragraph of 4.3.2 indicates the problem. The response to a PROPFIND Depth:infinity on a collection containing redirect references returns 302 for the redirect references, but also returns the DAV:resourcetype and DAV:location properties (described as DAV:reftarget in section 4.3?) for the redirect reference but no other properties. Seems like a lot of special cases. Could using a three-state Passthrough header eliminate the special cases? 4.3.1 MKREF should use the Destination header like BIND. Operations involving redirect references use a Location header. BIND uses Destination. MKREF uses Ref-Target while the redirect reference has a DAV:reftarget property. These should be normalized. 4.3.1.1, 409: Examples that MAY produce a conflict include reference to a target that does not exist on a server that does not support dangling references. This, and similar server behavior needs to be part of the specification in order to ensure interoperability. 4.3.3. Seems like COPY should just copy the redirect reference resource, just like any other resource, and there should be no special cases. This looks like its attempting to mix binding and redirect reference semantics on a case-by-case basis. It will be too hard to explain and remember these semantics. So I don't agree with "For a COPY request to a redirect reference, the expectation would be a 203 response that the client could use to copy the target resource." The client is made aware on a GET on the redirect reference that it is a redirect reference. So on COPY, the client would expect to copy the redirect reference to a new location, but have it redirect to the same target. The behavior of the newly copied redirect reference is exactly the same as the old one. We shouldn't special case methods based on resource type. I don't think the client would expect a new, independent copy of the target resource because that's not what was copied. An alternative would be to go ahead and copy the reference but still return a 302 unless the Passthrough header was specified. If Passthrough is "T", copy the target. If Passthrough is "F", copy the reference, same target, and no 302. 4.3.4 Passthrough for DELETE isn't consistent with its use on other methods. Passthrough : T should not generate a 302, it should delete the target resource and the reference. Third paragraph: this is one interpretation of COPY and MOVE. Another is given by GET, PUT, DELETE semantics. COPY is a GET followed by PUT to the new destination. MOVE is a COPY followed by a DELETE of the source. In this interpretation, these methods require no special cases. The semantics of references should be independent of these implied implementation details. 4.3.6. This is too complicated and has too many special cases. If redirect references are exposed as resources, then they should be treated like resources. LOCK on a redirect reference should lock the reference. It should have no effect on the target unless Passthrough is specified to "T". Then the target resource, not the reference is locked. A locked reference can't have its properties changed. In particular, one can't change its target. Or consider removing redirect references from the spec. 5.2.1, last paragraph: DAV:orderingtype should be optional. Missing DAV:orderingtype is equivalent to DAV:unordered. This would be more compatible with existing servers, and simpler. 5.4. What happens to requests that occur between changing the DAV:orderingtype and the ORDERPATCH method? Won't the ordering be incorrect? 6.4 Passthrough "T" should not return a 302, but instead should operate directly on the target resource. The client is already referencing aware (or wouldn't have used the header), and has expressed his intent to operate on the target not the reference. The server should do the operation without requiring another round trip. Also, Passthrough: T and no Passthrough header do the same thing. 6.6: perhaps it should be an error to adding a binding to a collection with a client-maintained ordering and the Position header is not specified. Putting the resource at the end seems a bit arbitrary. See section 8.4: If the collection has a custom ordering type, how do we know any given client will add resources in the desired order? Requiring the Position header at least makes the client think about ordering. But the result looks pretty useless as there is no way to ensure the client ordering semantics are followed. 7.1 loop detected should be a 2xx status code, not an 506 which indicates an internal server error. Loops aren't errors. 11.1 indicates a resource that provides resource sharing MUST support both bindings and redirect references while the next sentence indicates an OPTIONS request MUST indicate which of these capabilities the resource supports. Aren't bindings and redirect references independent? Couldn't a server support either one or both? From w3c-dist-auth-request@w3.org Tue Aug 24 07:16:52 1999 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA20382 for ; Tue, 24 Aug 1999 07:16:51 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id HAA25790; Tue, 24 Aug 1999 07:02:40 -0400 (EDT) Resent-Date: Tue, 24 Aug 1999 07:02:40 -0400 (EDT) Resent-Message-Id: <199908241102.HAA25790@www19.w3.org> Message-Id: <199908241102.HAA19948@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, 24 Aug 1999 07:02:33 -0400 Subject: I-D ACTION:draft-ietf-webdav-ordering-protocol-00.txt Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3197 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list --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, J. Davis, G. Clemm, C. Fay, J. Crawford, C. Chihaya Filename : draft-ietf-webdav-ordering-protocol-00.txt Pages : 21 Date : 23-Aug-99 The WebDAV Distributed Authoring Protocol provides basic support for collections, offering the ability to create and list unordered collections. This specification is one of a group of three specifications that supplement the WebDAV Distributed Authoring Protocol to increase the power of WebDAV collections. This specification defines a protocol supporting server-side ordering of collection members. The companion specifications [B] and [RR] define two mechanisms for allowing a single resource to appear in more than one collection. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-webdav-ordering-protocol-00.txt 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-00.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-00.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: <19990823112810.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-webdav-ordering-protocol-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-webdav-ordering-protocol-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19990823112810.I-D@ietf.org> --OtherAccess-- --NextPart-- From w3c-dist-auth-request@w3.org Tue Aug 24 07:16:52 1999 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA20386 for ; Tue, 24 Aug 1999 07:16:52 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id HAA25824; Tue, 24 Aug 1999 07:02:48 -0400 (EDT) Resent-Date: Tue, 24 Aug 1999 07:02:48 -0400 (EDT) Resent-Message-Id: <199908241102.HAA25824@www19.w3.org> Message-Id: <199908241102.HAA19963@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, 24 Aug 1999 07:02:39 -0400 Subject: I-D ACTION:draft-ietf-webdav-redirectref-protocol-00.txt Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3198 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list --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 Redirect Reference Resources Author(s) : J. Slein, E. Whitehead, J. Davis, G. Clemm, C. Fay, J. Crawford, T. Chihaya Filename : draft-ietf-webdav-redirectref-protocol-00.txt Pages : 28 Date : 23-Aug-99 The WebDAV Distributed Authoring Protocol provides basic support for collections, offering the ability to create and list unordered collections. This specification is one of a group of three specifications that supplement the WebDAV Distributed Authoring Protocol to increase the power of WebDAV collections. This specification defines redirect reference resources, one mechanism for allowing a single resource to appear in more than one collection. A redirect reference resource is a resource in one collection that responds to most requests by redirecting the request (using an HTTP 1.1 302 Moved Temporarily response) to a different resource, possibly in a different collection. [B] defines bindings, another approach to allowing a single resource to be accessed from multiple collections. [OC] provides ordered collections. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-webdav-redirectref-protocol-00.txt 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-redirectref-protocol-00.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-redirectref-protocol-00.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: <19990823112821.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-webdav-redirectref-protocol-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-webdav-redirectref-protocol-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19990823112821.I-D@ietf.org> --OtherAccess-- --NextPart-- From w3c-dist-auth-request@w3.org Tue Aug 24 07:30:41 1999 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA20385 for ; Tue, 24 Aug 1999 07:16:52 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id HAA25770; Tue, 24 Aug 1999 07:02:37 -0400 (EDT) Resent-Date: Tue, 24 Aug 1999 07:02:37 -0400 (EDT) Resent-Message-Id: <199908241102.HAA25770@www19.w3.org> Message-Id: <199908241102.HAA19933@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, 24 Aug 1999 07:02:25 -0400 Subject: I-D ACTION:draft-ietf-webdav-binding-protocol-00.txt Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3196 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list --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 Bindings Author(s) : J. Slein, E. Whitehead, J. Davis, G. Clemm, C. Fay, J. Crawford, T. Chihaya Filename : draft-ietf-webdav-binding-protocol-00.txt Pages : 22 Date : 23-Aug-99 The WebDAV Distributed Authoring Protocol provides basic support for collections, offering the ability to create and list unordered collections. This specification is one of a group of three specifications that supplement the WebDAV Distributed Authoring Protocol to increase the power of WebDAV collections. This specification defines bindings, one mechanism for allowing a single resource to appear in more than one collection. Bindings make this possible by creating mappings of URIs to resources. The BIND method defined here gives clients the ability to create new bindings to existing resources. [RR] defines redirect references, another approach to allowing a single resource to be accessed from multiple collections. [OC] provides ordered collections. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-webdav-binding-protocol-00.txt 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-binding-protocol-00.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-binding-protocol-00.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: <19990823112758.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-webdav-binding-protocol-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-webdav-binding-protocol-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19990823112758.I-D@ietf.org> --OtherAccess-- --NextPart-- From w3c-dist-auth-request@w3.org Tue Aug 24 09:29:53 1999 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA00364 for ; Tue, 24 Aug 1999 09:29:52 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id JAA00145; Tue, 24 Aug 1999 09:19:59 -0400 (EDT) Resent-Date: Tue, 24 Aug 1999 09:19:59 -0400 (EDT) Resent-Message-Id: <199908241319.JAA00145@www19.w3.org> Date: Tue, 24 Aug 1999 15:19:23 +0200 (MESZ) From: Edgar Schwarz X-Sender: Edgar.Schwarz@hpmx15.bk.bosch.de To: w3c-dist-auth@w3.org In-Reply-To: <9908191403.AA29315@tantalum> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: Geoffries simplification proposal (Was: LOCK Scenarios) Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3199 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list On Thu, 19 Aug 1999, Geoffrey M. Clemm wrote: > In general, I am against all bits of the > protocol which cause a lock to be "inherited", since this forces > all the "resource creation" methods to have to deal with all > the "LOCK" failure cases. So I'm against: > - depth locking > - lock-null resources > - keeping the lock on the destination of a MOVE/COPY After coming back from my holidays and reading a lot of WebDAV articles I don't want to repeat all arguments. I just want to say: I agree with you :-) Regards, Edgar -- Edgar.Schwarz@de.bosch.com ON/EMS1, 07191/13-3382 Niklaus Wirth: Privat kann jeder soviel C programmieren oder Videos ansehen wie er mag. Albert Einstein: Mach es so einfach wie moeglich, aber nicht einfacher. From w3c-dist-auth-request@w3.org Tue Aug 24 11:22:03 1999 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09454 for ; Tue, 24 Aug 1999 11:22:02 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id LAA04829; Tue, 24 Aug 1999 11:10:41 -0400 (EDT) Resent-Date: Tue, 24 Aug 1999 11:10:41 -0400 (EDT) Resent-Message-Id: <199908241510.LAA04829@www19.w3.org> Message-ID: <8E3CFBC709A8D21191A400805F15E0DBD2440C@crte147.wc.eso.mc.xerox.com> From: "Slein, Judith A" To: "'jamsden@us.ibm.com'" , w3c-dist-auth@w3.org Date: Tue, 24 Aug 1999 11:10:00 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Advanced Collections-04 Review Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3200 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list Jim, Thanks very much for giving the 04 spec such a thorough review. I've been working at splitting the collections spec into 3 parts -- one on bindings, one on redirect references, and one on ordered collections. The 3 new specs were announced this morning, as you may have noticed. In addition to the mechanics of splitting the spec, I've been focusing on giving better context in the introductions and on clarifying the definitions. This all should help with some of your more basic questions. Most of your issues are still relevant to the new specs, however. We'll address them in the next revision. Explanations below . . . > -----Original Message----- > From: jamsden@us.ibm.com [mailto:jamsden@us.ibm.com] > Sent: Monday, August 23, 1999 3:32 PM > To: w3c-dist-auth@w3.org > Subject: Advanced Collections-04 Review > > > > > Here's my review of the advanced collections spec 04. I tried > to keep my > comments based on the order of the spec to uncover anything a > new reader might > have trouble with. This is a nice piece of work. In > particular, the BIND method > seems to be just what we need. However, redirect references > still seem pretty > complex and full of special cases. It would require doing an > implementation to > root out all the detailed issues, but the specification as it > stands is pretty > close to what we need in order to start implementing. Thanks > to the authors for > all the hard work they put into this. > > Last paragraph, section 3 Introduction: Might be helpful to say this > specification defines client specified, server maintained > orderings. Its not > clear that the server is not supporting the ordering, only > maintaining an > ordering given by a client. Yes, it needs to be made more clear what we are defining. All the orderings we specify are on the server side, and we are most interested in orderings that are maintained based on client requests to insert a child at a certain position in the collection's ordering. (We call these client-maintained orderings.) But we do have some minimal support for server-maintained orderings (ones where it's the server's responsibility to insert children at the right position in the ordering just based on the ordering identifier). All we do for this last sort of ordering is provide a way for clients to discover what orderings the server can support in this way, and to pick from the list of available server-maintained orderings. > > 4.1, second bullet: HTTP servers provide URI mappings, but no > protocol for > specifying them. Must be done in server-dependent > configuration and often > requires server restart. This bullet is gone now. > > Last bullet: making support for cross-server bindings > optional does not > eliminate the referential integrity problem caused by > disconnected servers. So a > server could support cross-server bindings sometimes, but not > at other times if > the server is disconnected. Unfortunately, this is stateful > and depends on > connectivity, not anything to with the bindings themselves. > So referential > integrity could never be guaranteed, and either must be > optional or cross-server > bindings must be prohibited. > > 4.2, 1st paragraph: aren't bindings a many-to-1 relationship > between URI > mappings to resources? Can't a collection have more than one > binding to the same > internal member? Note that the definition of internal member > given in this > specification implies that a resource can be an internal > member of more than one > collection. No. No. No. (if I take you literally, but the spirit of what you say is correct. Here's what I mean:) A binding is a relation between the final segment of a URI relative to a collection and a resource. So think of the binding as the triple (Segment, Collection, Resource). An internal member URI is not a resource, but an absolute URI. Any given binding induces one or more internal member URIs. But bindings are to resources, not to internal member URIs. A collection can have more than one binding to the same resource. What is really strictly speaking contained in a collection are bindings. A resource can be (loosely speaking) contained in more than one collection because there can be bindings to it in more than one collection. > > Cross-server bindings: would it be acceptable to 1) refuse to > delete a resource > that would create dangling references? 2) only delete the > binding, and employ > some garbage collection algorithm (including leaving the > garbage)? and/or 3) > delete the resource and all references if it can be known > (through say reference > counts) that there are no other references? Should these > suggestions be added to > the spec to indicate possible ways referential integrity > could be maintained > across servers? 1 - yes. 2 - yes, this is what we say DELETE means. 3 - I think not, though perhaps I don't understand. You're only allowed to delete the binding identified by the request-URL, unless the All-Bindings header is used. But 1 and 2 assume that the server knows what bindings there are to the resource. The trouble is that we don't define any server-to-server protocol elements, which is what would be required for the server where the resource lives to keep an accurate reference count or list of bindings. > > 4.2.1 says that a Request-URI ending in a "/" must bind to a > collection, but > does not indicate a Request-URI NOT ending in a "/" CAN bind > to a collection > too. > We do need to straighten out what we say about Request-URI that do / do not end in a "/". > 4.2.2 506 (Loop Detected) is a server error status code, but > this is likely a > successful operation that clients mostly don't care about. > Should be a 2xx > status code? > We need to make some decisions about whether to allow loops to be created in the first place, and if so what to do when they are encountered. This was a topic of discussion at Oslo. There are also some related threads on the list, but we need more discussion. > I had trouble making sense of section 4.2.3. What's a > non-WebDAV collection or > non-WebDAV advanced collection? Where is domain name variant > defined? What is > the authority part of a URL? Should step 4 be left to right? > How is S bound to R > in step 4? Does this algorithm only apply to bindings whose > destination is a > collection? > > The example in 4.2.4 uses the destination URL not the request > URL as specified > in 4.2.3. Are users expected to understand and use this > algorithm in order to > know what is bound to what? We know that sections 4.2.3 - 4.2.4 need a lot of work. I haven't tried to touch this in the new drafts coming out, but we will fix it. > > Section 4.2.5, 409 (Conflict): so the binding is only created > for the right-most > path segment. All other collections in the path segment must > already exist? BIND > doesn't create bindings for these path segments in their > parent directory too? > In example 4.2.6, collection /~whitehead/dav/ must already > exist? The bind > operation wouldn't create a binding for dav if it didn't > already exist? Correct on all counts. > > Example 4.2.7: the existence of / should not be required. The > binding should > have been created although it is probably not what the user > intended. In all > other cases, WebDAV behaves as if the / were present, and > returns any URI's with > the / added. BIND should be consistent with this convention. > In any case, this > error condition is not described in section 4.2.5. We need to look at this. It's part of the general problem of straightening out what we say about the presence or absence of "/" and making sure we are consistent with the rest of WebDAV. > > Should section 8.6.1 of [WebDAV] be corrected so the last > paragraph of 4.2.8 > isn't necessary? Yes. It is our intention to try to get this changed as part of the process of preparing [WebDAV] for draft status. Jim Whitehead, is this on the issues list? > > 4.2.9, 2nd paragraph: if depth is specified for the COPY > method, it must be > Depth: infinity. Depth: 0 or 1 is not allowed. I think Depth 0 is allowed according to [WebDAV] Section 8.8.3. > > Section 4.2.10: The semantics of MOVE are fine, but they are > different than > [WebDAV]. In this case, the resource is not moved at all, > only bindings to the > resource are manipulated. The implication is that the > resource is unchanged. Its > the same resource in the same physical storage location on > the same server, etc. > This is not the case with [WebDAV], and may not be what was > desired. Perhaps > there are two MOVE operations that need to be distinguished. > Note that COPY > created R' while MOVE didn't. Another possible outcome for > the example is that a > new resource is created R' which is a copy of R, and URI 1, > URI 2, and URIX are > all bound to R'. All bindings to R are deleted. This interpretation is > consistent with [WebDAV]. Second to the last sentence in the > last paragraph: ... > request-URI cannot be moved. A lot of work went into trying to insure that the definition of MOVE in advanced collections is logically equivalent to the definition in [WebDAV]. The authors of [WebDAV] were consulted. I suppose we should claim only equivalence from the point of view of the client, who doesn't know about storage locations, but only about what URIs can be used to access the resource before and after the MOVE operations. > > Section 4.2.10.1: OK, we're in agreement. However, it is not > clear what server > writers are required to do with implementation notes. It also > seems the protocol > should not be specifying anything about implementation. > Perhaps these two > sections can be replaced by one that specifies a logical move > where either > implementation would be valid. Or, these are not equivalent > logical operations > and clients may wish to distinguish them. (I don't think so > though as the client > probably couldn't tell the difference). We can change the name of this section and revise the wording if that seems better. But we want to keep the basic information of this section, as this is where we were trying to explain the equivalence of our MOVE semantics to the semantics in [WebDAV]. > > Section 4.2.12: Seems to assume that all bindings have the > same behavior if they > are bindings to the same resource. However, servers do > special things with > non-WebDAV collection names (acting as functors) such as > cgi-bin, servlet, etc. > In this case, different bindings to the same resource will behave very > differently. The 4th paragraph on PUT may not be possible due > to the effect of > these functors. > I'll add this to the issues list. > Should we introduce a new DAV property that provides a GUID > for each resource > that can act as an identifier for that resource? Then we can > determine if two > bindings are to the same resource by examining a property. > Note that just > because the contents and properties are the same for a pair > of resources, this > does not mean they are the same resource. An interesting suggestion. I'll add it to our issues list. > > 4.2.13: If the optional DAV:bindings property exists for a > resource, does it > have to contain ALL the bindings? Even those from other > servers? Is this > optional on a server or resource basis? Well, we've said that servers are required to guarantee the integrity of bindings. So they have to fail BIND requests unless they can guarantee that the server where the resource lives knows about the binding and will honor it (won't let the resource be destroyed while the binding still exists, etc.). Which pretty much means that no one will support cross-server bindings, as far as I can see. But in any case it means that the server maintaining DAV:bindings would have the information needed to include all bindings, and I think it should be required to do so. The property is optional on a resource basis, like all capabilities in WebDAV. > > 4.3, last paragraph: the semantics of the Passthrough header > seem to be > described in reverse. The last sentence of the last paragraph > sounds like a > NoPassthrough header, not Passthrough. The default should be > to return the > properties of the reference or return a 302. We probably need to talk about the values of Passthrough (T and F) to make it clearer what is meant here. The default in the case of a PROPFIND is to return a 302. So using Passthrough: F would get the reference's own properties. >Why not return a > 302 of the > Passthrough header is not present, and if it is present, it must be a > referencing-aware client and just do what the header says. > "T" means Passthrough > to the target and don't return a 302. "F" means operate on > the reference. We don't want to end up with a hybrid direct / redirect reference. One of the essential characteristics of a redirect reference is that the server never has to resolve it. The server never operates on the target, but only responds with a 302 and gives the client the information it needs to send a request to the target. This was to insure that server implementations would be easy and that there would be no complexity about using redirect references to resources on a different server. >Second > paragraph of 4.3.2 indicates the problem. The response to a PROPFIND > Depth:infinity on a collection containing redirect references > returns 302 for > the redirect references, but also returns the > DAV:resourcetype and DAV:location > properties (described as DAV:reftarget in section 4.3?) for > the redirect > reference but no other properties. Seems like a lot of > special cases. Could > using a three-state Passthrough header eliminate the special cases? There is only 1 special case: a redirect reference is encountered when doing a PROPFIND with Depth > 0. The special processing for that case is to return a 302 with DAV:resourcetype and DAV:location, and no other properties. We could have said that the server must resolve the reference and return its target's properties, but that would be to turn the redirect reference into a direct reference, which we were not willing to do. > > 4.3.1 MKREF should use the Destination header like BIND. > Operations involving > redirect references use a Location header. BIND uses > Destination. MKREF uses > Ref-Target while the redirect reference has a DAV:reftarget > property. These > should be normalized. We should definitely take another look at this, but there were reasons. Ref-Target and DAV:reftarget differ from Destination in allowing relative URIs as values. People felt that in some situations it would be desirable to use relative URIs. The Location header and DAV:location pseudo-property are used in situations where [HTTP] requires the Location header. You have to use Location with a 302, and we introduced DAV:location for use inside a Multi-Status response to convey the same information. > > 4.3.1.1, 409: Examples that MAY produce a conflict include > reference to a target > that does not exist on a server that does not support > dangling references. This, > and similar server behavior needs to be part of the > specification in order to > ensure interoperability. > ok > 4.3.3. Seems like COPY should just copy the redirect > reference resource, just > like any other resource, and there should be no special > cases. This looks like > its attempting to mix binding and redirect reference > semantics on a case-by-case > basis. It will be too hard to explain and remember these > semantics. So I don't > agree with "For a COPY request to a redirect reference, the > expectation would be > a 203 response that the client could use to copy the target > resource." The > client is made aware on a GET on the redirect reference that > it is a redirect > reference. So on COPY, the client would expect to copy the > redirect reference to > a new location, but have it redirect to the same target. The > behavior of the > newly copied redirect reference is exactly the same as the > old one. We shouldn't > special case methods based on resource type. I don't think > the client would > expect a new, independent copy of the target resource because > that's not what > was copied. An alternative would be to go ahead and copy the > reference but still > return a 302 unless the Passthrough header was specified. If > Passthrough is "T", > copy the target. If Passthrough is "F", copy the reference, > same target, and no > 302. > We can revisit this, but we've been through it so many times I don't promise a different decision. It's a balancing act between conflicting considerations, and no answer seems right from all points of view. > 4.3.4 Passthrough for DELETE isn't consistent with its use on > other methods. > Passthrough : T should not generate a 302, it should delete > the target resource > and the reference. You'll be tired of hearing this by now, but one thing a redirect reference will never do is operate on the target resource. Passthrough: T for a redirect reference always results in a 302, which allows the client to submit a request to the target resource. Passthrough: F for a redirect reference means operate on the reference. If we ever re-introduce direct references, Passthrough: T for them will mean operate on the target. >Third paragraph: this is one > interpretation of COPY and MOVE. > Another is given by GET, PUT, DELETE semantics. COPY is a GET > followed by PUT to > the new destination. MOVE is a COPY followed by a DELETE of > the source. In this > interpretation, these methods require no special cases. The > semantics of > references should be independent of these implied > implementation details. I don't think the paragraph implies anything about implementation. It certainly wasn't meant to. But I'll have to agree that this rationale has always seemed pretty shaky to me. What I really think people have in mind is the behavior of Unix symbolic links (where removing the link doesn't remove the target) and the desire to do the least-potentially-damaging thing. > > 4.3.6. This is too complicated and has too many special > cases. If redirect > references are exposed as resources, then they should be > treated like resources. > LOCK on a redirect reference should lock the reference. It > should have no effect > on the target unless Passthrough is specified to "T". Then > the target resource, > not the reference is locked. A locked reference can't have > its properties > changed. In particular, one can't change its target. Or > consider removing > redirect references from the spec. Again, redirect references are not direct references and so never operate on the target resource. We start from the position that the default behavior for any method for a redirect reference is to respond with a 302, and that there has to be a good reason to deviate from that behavior for any method. LOCK and COPY have been the difficult cases, where we've made exceptions for one reason or another. In the case of LOCK the decisive consideration was that LOCK on a collection with Depth: infinity would always fail for collections that contained redirect references if we stayed with the 302 behavior. So we have the LOCK apply to the reference instead. > > 5.2.1, last paragraph: DAV:orderingtype should be optional. Missing > DAV:orderingtype is equivalent to DAV:unordered. This would > be more compatible > with existing servers, and simpler. Sounds ok. > > 5.4. What happens to requests that occur between changing the > DAV:orderingtype > and the ORDERPATCH method? Won't the ordering be incorrect? Yes. Maybe we should use ORDERPATCH both for changing the ordering semantics and for manipulating the order of the members. > > 6.4 Passthrough "T" should not return a 302, but instead > should operate directly > on the target resource. The client is already referencing > aware (or wouldn't > have used the header), and has expressed his intent to > operate on the target not > the reference. The server should do the operation without > requiring another > round trip. Also, Passthrough: T and no Passthrough header do > the same thing. For redirect references, Passthrough: T returns a 302. If we ever re-introduce direct references, Passthrough: T for them will operate on the target resource. Whether Passthrough: T and no Passthrough header do the same thing depends upon the method in question. For DELETE and MOVE the default behavior is to operate on the reference. So the absence of a Passthrough header for those methods is equivalent to Passthrough: F. > > 6.6: perhaps it should be an error to adding a binding to a > collection with a > client-maintained ordering and the Position header is not > specified. Putting the > resource at the end seems a bit arbitrary. See section 8.4: > If the collection > has a custom ordering type, how do we know any given client > will add resources > in the desired order? Requiring the Position header at least > makes the client > think about ordering. But the result looks pretty useless as > there is no way to > ensure the client ordering semantics are followed. In any case, yes, it's entirely up to the clients that add bindings to the collection to see that the ordering semantics are followed. I do like the idea of requiring the Position header when adding a binding to a collection with a client-maintained ordering. The only hesitation I have is that someone other than the person who specified the ordering might be trying to add a binding. If we assume that the owner cares more about maintaining the ordering than about allowing others to add to the collection, we can add this constraint. Otherwise, maybe better not. > > 7.1 loop detected should be a 2xx status code, not an 506 > which indicates an > internal server error. Loops aren't errors. We'll be taking another look at this. > > 11.1 indicates a resource that provides resource sharing MUST > support both > bindings and redirect references while the next sentence > indicates an OPTIONS > request MUST indicate which of these capabilities the > resource supports. Aren't > bindings and redirect references independent? Couldn't a > server support either > one or both? > In the split specs, we define separate compliance classes for bindings and redirect references, so servers will be free to implement either one or both or neither. From w3c-dist-auth-request@w3.org Tue Aug 24 16:49:44 1999 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24006 for ; Tue, 24 Aug 1999 16:49:44 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id QAA16223; Tue, 24 Aug 1999 16:35:04 -0400 (EDT) Resent-Date: Tue, 24 Aug 1999 16:35:04 -0400 (EDT) Resent-Message-Id: <199908242035.QAA16223@www19.w3.org> Message-ID: <8E3CFBC709A8D21191A400805F15E0DBD24410@crte147.wc.eso.mc.xerox.com> From: "Slein, Judith A" To: "'WebDAV'" Date: Tue, 24 Aug 1999 16:34:47 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Subject: New Internet Drafts: Advanced Collections spec has been split Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3201 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list The new internet drafts that were announced this morning are the result of splitting the Advanced Collections spec into 3 parts: Bindings, Redirect References, and Ordered Collections. In addition to splitting the specs, a lot of editorial changes were made, and an attempt was made to provide better context in the Introductions to the new specs, as well as clearer definitions in the Terminology sections. Please review these new drafts as soon as possible and provide comments to the mailing list. Just to remind you of where they are: http://www.ietf.org/internet-drafts/draft-ietf-webdav-binding-protocol-00.tx t http://www.ietf.org/internet-drafts/draft-ietf-webdav-redirectref-protocol-0 0.txt http://www.ietf.org/internet-drafts/draft-ietf-webdav-ordering-protocol-00.t xt Thanks again to Jim Amsden for his comments of yesterday. We also have some comments from Yaron and from Jason Crawford that were communicated privately. I'll try to summarize the substantive ones on the mailing list over the next few days so that they can be discussed. --Judy Judith A. Slein Xerox Corporation jslein@crt.xerox.com (716)422-5169 800 Phillips Road 105/50C Webster, NY 14580 From w3c-dist-auth-request@w3.org Wed Aug 25 11:16:33 1999 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00907 for ; Wed, 25 Aug 1999 11:16:32 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id LAA06840; Wed, 25 Aug 1999 11:06:36 -0400 (EDT) Resent-Date: Wed, 25 Aug 1999 11:06:36 -0400 (EDT) Resent-Message-Id: <199908251506.LAA06840@www19.w3.org> In-Reply-To: from Jim Whitehead at "Aug 23, 1999 10:13:29 am" To: ejw@ics.uci.edu (Jim Whitehead) Date: Wed, 25 Aug 1999 17:04:37 +0200 (CEST) Cc: w3c-dist-auth@w3.org X-Mailer: ELM [version 2.4ME+ PL47 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Message-Id: <19990825150437.7C68761046@aachen.heimat.de> From: ruebe@aachen.heimat.de (Christian Scholz) Subject: Re: Mozilla editor and DAV Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3202 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list Content-Transfer-Encoding: 7bit Hi! > Just wanted to pass along some Mozilla information I heard last week. Turns > out that, at present, no one on the Mozilla team is working on integrating > WebDAV functionality, a definite bummer. Wouldn't it make more sense if WebDAV functionality would be implemented in the underlying OS as then every application automatically would have access to it. But I see that maybe more advanced features like properties etc. one would not be able to handle that way (if it's only some sort of filesystem structure). I once also asked on the Linux Kernel Mailing list and it looks as if also there nobody is working on it.. There have been some interesting ideas floating around though like implementing filesystems in Perl which might make the implementation of a DAV prototype quite easy. (But as I am mostly into Python and my time is quite limited I cannot do that. But maybe one day I will port it to Python and write the DAV FS with this.. But we will see :) > But, it appears that now would be a very good time for volunteers to join > the Mozilla team and implement DAV, since the Mozilla editor is currently > being re-built, and it would presumably be fairly easy to add WebDAV support > in during this rebuild process. At least it would make sense to have a look at it and tell them where some hooks should be added to do it later, etc. Usually they're quite open (as far as I experienced..) regards, Christian From w3c-dist-auth-request@w3.org Wed Aug 25 11:27:56 1999 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01387 for ; Wed, 25 Aug 1999 11:27:55 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id LAA07105; Wed, 25 Aug 1999 11:19:44 -0400 (EDT) Resent-Date: Wed, 25 Aug 1999 11:19:44 -0400 (EDT) Resent-Message-Id: <199908251519.LAA07105@www19.w3.org> Message-ID: <8E3CFBC709A8D21191A400805F15E0DBD24412@crte147.wc.eso.mc.xerox.com> From: "Slein, Judith A" To: "'WebDAV'" Date: Wed, 25 Aug 1999 11:19:20 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Subject: Redirect References Spec: "Passthrough" Header Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3203 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list Yaron argues that we should get rid of the Passthrough header, and instead have a property analogous to the DAV:source property. This issue was discussed by the design team last January (see minutes of 1/14/99), but it will be good to get their discussions into the mailing list archives now: Some Background What is the Passthrough header? For redirect references, the default behavior (in the absence of a Passthrough header) is to respond with a 302 and the location of the target resource. Then the client can resubmit the request to the target resource. In a few cases, the default behavior is to apply the method to the redirect reference. The Passthrough header allows a reference-aware client to control whether the response will be a 302 or the method will be applied to the reference. Passthrough: T means respond with a 302, Passthrough: F means apply the method to the reference. (The name "Passthrough" made more sense in the days when we had direct references. In the case of direct references, Passthrough: T meant apply the method to the target resource, while Passthrough: F meant apply it to the reference.) Arguments for Using a Property: 1. Using a header to determine what resource the method will be applied to is a bad thing. A server should be able to tell just from looking at the Request-URI what resource to apply the method to. The server would have to examine the Passthrough header to determine what access control to apply, and whether caching is appropriate. (Note: For redirect references, Passthrough doesn't actually change the resource the method gets applied to, but it would if used with direct references someday.) 2. The Passthrough header is just like URL-munging, and that's bad. It's bad for 2 reasons: When it is used to append an operation to a URL (;op=checkout), it is unclear what order to perform operations if request method is anything other than GET. In addition, there is the possibility of collisions in the url-munging space. (Rebuttal: Neither of these considerations applies in the case of Passthrough. No-passthrough has consistent semantics no matter what method it gets applied to, and there's no problem like the order-of-operations problem. And there is no possibility of collections here because we are defining Passthrough as part of a spec.) 3. Keep a consistent style through all the WebDAV specs. We used DAV:source, so let's use the same approach here. (Rebuttal: The cases aren't actually analogous. In the case of DAV:source there really were 2 separate resources we needed to be able to address. The test for this is whether you might want different access control on the 2 resources. But here if you ask, might we want different access control on the reference-as-mediator vs. on the reference-as-itself, the answer is "No". So we have only one resource.) Arguments against Using a Property 1. Two URLs would mean that 2 entries in the namespace would be used up for every reference created. So at the time, the decision was made to stick with the Passthrough header. --Judy Judith A. Slein Xerox Corporation jslein@crt.xerox.com (716)422-5169 800 Phillips Road 105/50C Webster, NY 14580 From w3c-dist-auth-request@w3.org Wed Aug 25 11:30:21 1999 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01539 for ; Wed, 25 Aug 1999 11:30:20 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id LAA07236; Wed, 25 Aug 1999 11:22:05 -0400 (EDT) Resent-Date: Wed, 25 Aug 1999 11:22:05 -0400 (EDT) Resent-Message-Id: <199908251522.LAA07236@www19.w3.org> From: jamsden@us.ibm.com X-Lotus-FromDomain: IBMUS To: ruebe@aachen.heimat.de (Christian Scholz) cc: w3c-dist-auth@w3.org Message-ID: <852567D8.00545BED.00@d54mta03.raleigh.ibm.com> Date: Wed, 25 Aug 1999 11:20:43 -0400 Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Subject: Re: Mozilla editor and DAV Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3204 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list Take a look at DAV4J on http://www.alphaworks.ibm.com. It presents a client API for accessing WebDAV resources that would make building clients much easier. ruebe@aachen.heimat.de (Christian Scholz) on 08/25/99 11:04:37 AM To: ejw@ics.uci.edu (Jim Whitehead) cc: w3c-dist-auth@w3.org Subject: Re: Mozilla editor and DAV Hi! > Just wanted to pass along some Mozilla information I heard last week. Turns > out that, at present, no one on the Mozilla team is working on integrating > WebDAV functionality, a definite bummer. Wouldn't it make more sense if WebDAV functionality would be implemented in the underlying OS as then every application automatically would have access to it. But I see that maybe more advanced features like properties etc. one would not be able to handle that way (if it's only some sort of filesystem structure). I once also asked on the Linux Kernel Mailing list and it looks as if also there nobody is working on it.. There have been some interesting ideas floating around though like implementing filesystems in Perl which might make the implementation of a DAV prototype quite easy. (But as I am mostly into Python and my time is quite limited I cannot do that. But maybe one day I will port it to Python and write the DAV FS with this.. But we will see :) > But, it appears that now would be a very good time for volunteers to join > the Mozilla team and implement DAV, since the Mozilla editor is currently > being re-built, and it would presumably be fairly easy to add WebDAV support > in during this rebuild process. At least it would make sense to have a look at it and tell them where some hooks should be added to do it later, etc. Usually they're quite open (as far as I experienced..) regards, Christian From w3c-dist-auth-request@w3.org Wed Aug 25 12:08:23 1999 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02594 for ; Wed, 25 Aug 1999 12:08:21 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id MAA08575; Wed, 25 Aug 1999 12:00:34 -0400 (EDT) Resent-Date: Wed, 25 Aug 1999 12:00:34 -0400 (EDT) Resent-Message-Id: <199908251600.MAA08575@www19.w3.org> Message-ID: <8E3CFBC709A8D21191A400805F15E0DBD24413@crte147.wc.eso.mc.xerox.com> From: "Slein, Judith A" To: "'WebDAV'" Date: Wed, 25 Aug 1999 12:00:17 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Subject: Redirect References Spec: Structured information in DAV:resourcet ype Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3205 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list Yaron believes that we are not taking full advantage of the structuring potential of DAV:resourcetype, and are limiting ourselves similarly by choosing to use a Resource-Type header rather than an XML body in messages. This is an issues that was discussed earlier by the design team (see minutes of 3/30/99), but it will be good to get the considerations into the mailing list archive now: Background The specification at that time included several separate properties related to referencing: DAV:reftype, DAV:refintegrity, DAV:reftarget. Yaron's suggestion was that these should instead be structured elements of the DAV:resourcetype property. Considerations Structured properties are not currently searchable using DASL, so we should keep separate any properties we really care about searching. In particular, reftarget. Values of resourcetype should determine different method behaviors. If method behaviors for property values are the same, the property doesn't belong in resourcetype. By this test, reftype and refintegrity might belong in resourcetype. Eventually servers may have to branch on refintegrity to determine behavior. But reftarget does not belong in resourcetype. Changing the target of a reference does not change the type of resource it is, so reftarget certainly does not belong in resourcetype. The names ref* are an indication that we're dealing with different types of references, so it may make sense to include reftype in resourcetype and structure the values of reftype. Nevertheless, there was no strong sentiment for incorporating reftype and refintegrity into resourcetype, so the decision was made to leave them separate properties. What Has Changed We no longer have direct references, so the only new resource type being introduced is redirect references. The reftype property is gone. There are no longer any protocol elements related to referential integrity. We no longer have a refintegrity property. So the only element we currently have that could go into DAV:resourcetype is DAV:redirectref. It might still pay to plan for the future by anticipating that direct references will come back someday, and that there will protocol elements supporting referential integrity someday. In that case we might still want to structure our values of DAV:resourcetype: The Resource-Type header is new. Yaron pointed out that using a header in responses to represent the contents of a structured property is needlessly limiting. Although no one is currently exploiting the structuring capabilities of DAV:resourcetype, they may someday (and of course he thinks we should be today), so we should provide for this by using an XML body with the DAV:resourcetype property instead. The only thing we are using this header for now is in 302 responses, to let reference-aware clients know tha the 302 is from a redirect reference, so we could use a header with a different name (say, Redirect-Ref) for this purpose. Or we could replace the header with an XML body containing the DAV:resourcetype property. I don't have a strong opinion about this. --Judy Judith A. Slein Xerox Corporation jslein@crt.xerox.com (716)422-5169 800 Phillips Road 105/50C Webster, NY 14580 From w3c-dist-auth-request@w3.org Wed Aug 25 12:17:07 1999 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02819 for ; Wed, 25 Aug 1999 12:17:06 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id MAA08926; Wed, 25 Aug 1999 12:08:27 -0400 (EDT) Resent-Date: Wed, 25 Aug 1999 12:08:27 -0400 (EDT) Resent-Message-Id: <199908251608.MAA08926@www19.w3.org> Message-ID: <37C4149D.48196159@ecal.com> Date: Wed, 25 Aug 1999 12:06:54 -0400 From: John Stracke X-Mailer: Mozilla 4.6 [en] (X11; I; Linux 2.0.36 i586) X-Accept-Language: en MIME-Version: 1.0 To: w3c-dist-auth@w3.org References: <19990825150437.7C68761046@aachen.heimat.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: Mozilla editor and DAV Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3206 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list Content-Transfer-Encoding: 7bit Christian Scholz wrote: > Wouldn't it make more sense if WebDAV functionality would be implemented > in the underlying OS as then every application automatically would > have access to it. No. Why would you want to bloat the OS with something that most processes don't need? Now, a common library that apps can use easily, that'd be different; but it certainly doesn't belong in the kernel. -- /=============================================================\ |John Stracke | My opinions are my own | S/MIME & HTML OK | |francis@ecal.com|============================================| |Chief Scientist | NT's lack of reliability is only surpassed | |eCal Corp. | by its lack of scalability. -- John Kirch | \=============================================================/ From w3c-dist-auth-request@w3.org Wed Aug 25 12:24:56 1999 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02953 for ; Wed, 25 Aug 1999 12:24:55 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id MAA09360; Wed, 25 Aug 1999 12:16:45 -0400 (EDT) Resent-Date: Wed, 25 Aug 1999 12:16:45 -0400 (EDT) Resent-Message-Id: <199908251616.MAA09360@www19.w3.org> Message-ID: <37C41698.5A137799@ecal.com> Date: Wed, 25 Aug 1999 12:15:20 -0400 From: John Stracke X-Mailer: Mozilla 4.6 [en] (X11; I; Linux 2.0.36 i586) X-Accept-Language: en MIME-Version: 1.0 To: "'WebDAV'" References: <8E3CFBC709A8D21191A400805F15E0DBD24412@crte147.wc.eso.mc.xerox.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: Redirect References Spec: "Passthrough" Header Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3207 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list Content-Transfer-Encoding: 7bit "Slein, Judith A" wrote: > Arguments against Using a Property > > 1. Two URLs would mean that 2 entries in the namespace would be used up for > every reference created. 2. Without Passthrough:, how do you find the property? PROPFIND would get 302d; you'd have no way to apply it to the reference itself. -- /=============================================================\ |John Stracke | My opinions are my own | S/MIME & HTML OK | |francis@ecal.com|============================================| |Chief Scientist | NT's lack of reliability is only surpassed | |eCal Corp. | by its lack of scalability. -- John Kirch | \=============================================================/ From w3c-dist-auth-request@w3.org Wed Aug 25 12:56:38 1999 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04217 for ; Wed, 25 Aug 1999 12:56:37 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id MAA10687; Wed, 25 Aug 1999 12:48:23 -0400 (EDT) Resent-Date: Wed, 25 Aug 1999 12:48:23 -0400 (EDT) Resent-Message-Id: <199908251648.MAA10687@www19.w3.org> Message-ID: <37C41DFE.45623909@ecal.com> Date: Wed, 25 Aug 1999 12:46:54 -0400 From: John Stracke X-Mailer: Mozilla 4.6 [en] (X11; I; Linux 2.0.36 i586) X-Accept-Language: en MIME-Version: 1.0 To: w3c-dist-auth@w3.org References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: Mozilla editor and DAV Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3208 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list Content-Transfer-Encoding: 7bit Stig Bakken wrote: > IMHO, WebDAV definitely has its place in a filesystem implementation. It'd be convenient, but think about the security problems: given existing HTTP authentication protocols, the filesystem code would have to have the cleartext password of each user. -- /=============================================================\ |John Stracke | My opinions are my own | S/MIME & HTML OK | |francis@ecal.com|============================================| |Chief Scientist | NT's lack of reliability is only surpassed | |eCal Corp. | by its lack of scalability. -- John Kirch | \=============================================================/ From w3c-dist-auth-request@w3.org Wed Aug 25 13:11:34 1999 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04787 for ; Wed, 25 Aug 1999 13:11:33 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id NAA11182; Wed, 25 Aug 1999 13:00:30 -0400 (EDT) Resent-Date: Wed, 25 Aug 1999 13:00:30 -0400 (EDT) Resent-Message-Id: <199908251700.NAA11182@www19.w3.org> Date: Wed, 25 Aug 1999 09:40:46 -0700 Message-ID: <4290-Wed25Aug1999095307-0700-bill@carpenter.ORG> X-Mailer: 20.4 "Emerald" XEmacs Lucid (via feedmail 9-beta-8 Q); VM 6.71 under 20.4 "Emerald" XEmacs Lucid MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: bill@carpenter.ORG (WJCarpenter) To: w3c-dist-auth@w3.org In-Reply-To: <19990825150437.7C68761046@aachen.heimat.de> References: <19990825150437.7C68761046@aachen.heimat.de> Subject: Re: Mozilla editor and DAV Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3209 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list Content-Transfer-Encoding: 7bit ruebe> Wouldn't it make more sense if WebDAV functionality would be ruebe> implemented in the underlying OS as then every application ruebe> automatically would have access to it. But I see that maybe Oh, you must be talking about emacs now. :-) -- bill@carpenter.ORG (WJCarpenter) PGP bill@bubblegum.net 0x91865119 38 95 1B 69 C9 C6 3D 25 73 46 32 04 69 D6 ED F3 From w3c-dist-auth-request@w3.org Wed Aug 25 13:17:48 1999 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04941 for ; Wed, 25 Aug 1999 13:17:48 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id NAA11665; Wed, 25 Aug 1999 13:09:23 -0400 (EDT) Resent-Date: Wed, 25 Aug 1999 13:09:23 -0400 (EDT) Resent-Message-Id: <199908251709.NAA11665@www19.w3.org> From: Jim Whitehead To: WebDAV WG Date: Wed, 25 Aug 1999 10:02:54 -0700 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.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Importance: Normal Subject: FW: [Moderator Action] Re: Mozilla editor and DAV Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3211 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list Content-Transfer-Encoding: 7bit Also caught by the spam filter. - Jim -----Original Message----- From: Stig Bakken [mailto:ssb@fast.no] Sent: Wednesday, August 25, 1999 10:04 AM To: John Stracke Cc: w3c-dist-auth@w3.org Subject: [Moderator Action] Re: Mozilla editor and DAV On Wed, 25 Aug 1999, John Stracke wrote: > Stig Bakken wrote: > > > IMHO, WebDAV definitely has its place in a filesystem implementation. > > It'd be convenient, but think about the security problems: given > existing HTTP authentication protocols, the filesystem code would have > to have the cleartext password of each user. I was just trying to make a point out of that adding WebDAV support to the OS didn't have to bloat it. As for the secure authentication, that is an issue that has to be dealt with for WebDAV (and HTTP in general) anyway. - Stig From w3c-dist-auth-request@w3.org Wed Aug 25 13:18:28 1999 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04955 for ; Wed, 25 Aug 1999 13:18:28 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id NAA11695; Wed, 25 Aug 1999 13:09:44 -0400 (EDT) Resent-Date: Wed, 25 Aug 1999 13:09:44 -0400 (EDT) Resent-Message-Id: <199908251709.NAA11695@www19.w3.org> From: Jim Whitehead To: WebDAV WG Date: Wed, 25 Aug 1999 10:02:00 -0700 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.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Importance: Normal Subject: FW: [Moderator Action] Re: Mozilla editor and DAV Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3210 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list Content-Transfer-Encoding: 7bit Caught by the spam filter. - Jim -----Original Message----- From: Stig Bakken [mailto:ssb@fast.no] Sent: Wednesday, August 25, 1999 9:38 AM To: John Stracke Cc: w3c-dist-auth@w3.org Subject: [Moderator Action] Re: Mozilla editor and DAV On Wed, 25 Aug 1999, John Stracke wrote: > Christian Scholz wrote: > > > Wouldn't it make more sense if WebDAV functionality would be implemented > > in the underlying OS as then every application automatically would > > have access to it. > > No. Why would you want to bloat the OS with something that most > processes don't need? Now, a common library that apps can use easily, > that'd be different; but it certainly doesn't belong in the kernel. IMHO, WebDAV definitely has its place in a filesystem implementation. This won't bloat the OS (not modern ones, at least), and it provides a useful abstraction that requires little or no no extra work for application developers. - Stig From w3c-dist-auth-request@w3.org Wed Aug 25 13:23:53 1999 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05111 for ; Wed, 25 Aug 1999 13:23:51 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id NAA11867; Wed, 25 Aug 1999 13:15:55 -0400 (EDT) Resent-Date: Wed, 25 Aug 1999 13:15:55 -0400 (EDT) Resent-Message-Id: <199908251715.NAA11867@www19.w3.org> From: jamsden@us.ibm.com X-Lotus-FromDomain: IBMUS To: "Slein, Judith A" cc: w3c-dist-auth@w3.org Message-ID: <852567D8.005ECF77.00@d54mta03.raleigh.ibm.com> Date: Wed, 25 Aug 1999 13:15:17 -0400 Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Subject: Re: Redirect References Spec: "Passthrough" Header Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3212 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list I think the Passthrough header is fine. Referencing aware clients can use the passthrough header without having to access the properties of a resource first. However, I don't understand why Passthrough: T wouldn't apply to the target resource and not return a 302. Seems like the client knows what it wants to do and is aware the request-URI is a reference. Why require the extra round trip in this case? Second, I don't think we should special case method behavior based on resource type. That is, Passthrough isn't specified, return 302, if it is specified, do what it says for all methods. We shouldn't make cases like if this is an XXX method whose request URI is reference to a collection do one thing, otherwise do something else. This makes the protocol too complicated and brittle. It will inhibit server creation and interoperability, and will result in client behavior that will be difficult for users to understand and predict. The protocol should provide basic core capabilities that clients can exploit for various purposes in an interoperable way. For example, MOVE vs. collection merge, exposing vs. hiding redirect references, shallow or deep locking, etc. "Slein, Judith A" on 08/25/99 11:19:20 AM To: "'WebDAV'" cc: Subject: Redirect References Spec: "Passthrough" Header Yaron argues that we should get rid of the Passthrough header, and instead have a property analogous to the DAV:source property. This issue was discussed by the design team last January (see minutes of 1/14/99), but it will be good to get their discussions into the mailing list archives now: Some Background What is the Passthrough header? For redirect references, the default behavior (in the absence of a Passthrough header) is to respond with a 302 and the location of the target resource. Then the client can resubmit the request to the target resource. In a few cases, the default behavior is to apply the method to the redirect reference. The Passthrough header allows a reference-aware client to control whether the response will be a 302 or the method will be applied to the reference. Passthrough: T means respond with a 302, Passthrough: F means apply the method to the reference. (The name "Passthrough" made more sense in the days when we had direct references. In the case of direct references, Passthrough: T meant apply the method to the target resource, while Passthrough: F meant apply it to the reference.) Arguments for Using a Property: 1. Using a header to determine what resource the method will be applied to is a bad thing. A server should be able to tell just from looking at the Request-URI what resource to apply the method to. The server would have to examine the Passthrough header to determine what access control to apply, and whether caching is appropriate. (Note: For redirect references, Passthrough doesn't actually change the resource the method gets applied to, but it would if used with direct references someday.) 2. The Passthrough header is just like URL-munging, and that's bad. It's bad for 2 reasons: When it is used to append an operation to a URL (;op=checkout), it is unclear what order to perform operations if request method is anything other than GET. In addition, there is the possibility of collisions in the url-munging space. (Rebuttal: Neither of these considerations applies in the case of Passthrough. No-passthrough has consistent semantics no matter what method it gets applied to, and there's no problem like the order-of-operations problem. And there is no possibility of collections here because we are defining Passthrough as part of a spec.) 3. Keep a consistent style through all the WebDAV specs. We used DAV:source, so let's use the same approach here. (Rebuttal: The cases aren't actually analogous. In the case of DAV:source there really were 2 separate resources we needed to be able to address. The test for this is whether you might want different access control on the 2 resources. But here if you ask, might we want different access control on the reference-as-mediator vs. on the reference-as-itself, the answer is "No". So we have only one resource.) Arguments against Using a Property 1. Two URLs would mean that 2 entries in the namespace would be used up for every reference created. So at the time, the decision was made to stick with the Passthrough header. --Judy Judith A. Slein Xerox Corporation jslein@crt.xerox.com (716)422-5169 800 Phillips Road 105/50C Webster, NY 14580 From w3c-dist-auth-request@w3.org Wed Aug 25 13:30:40 1999 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05322 for ; Wed, 25 Aug 1999 13:30:39 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id NAA11976; Wed, 25 Aug 1999 13:18:43 -0400 (EDT) Resent-Date: Wed, 25 Aug 1999 13:18:43 -0400 (EDT) Resent-Message-Id: <199908251718.NAA11976@www19.w3.org> Message-ID: <37C4251E.C24ADD1E@ecal.com> Date: Wed, 25 Aug 1999 13:17:18 -0400 From: John Stracke X-Mailer: Mozilla 4.6 [en] (X11; I; Linux 2.0.36 i586) X-Accept-Language: en MIME-Version: 1.0 To: w3c-dist-auth@w3.org References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: Mozilla editor and DAV Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3213 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list Content-Transfer-Encoding: 7bit Stig Bakken wrote: > As for the secure authentication, that is an issue that has to be dealt > with for WebDAV (and HTTP in general) anyway. Yes, but the point is that any acceptably strong authentication system is going to involve credentials that can't be reused. (E.g., if I'm running through a proxy, then the proxy can steal my credentials if I use Basic authentication, but not if I use Digest.) This is more or less OK if only your browser has the credentials; but, if you want to do a filesystem, it's going to need access to all the credentials of all the users who want to use it. (For example, with Samba, if I want a filesystem to be mounted at startup, I have to put the password into the appropriate /etc/rc.d script.) -- /=============================================================\ |John Stracke | My opinions are my own | S/MIME & HTML OK | |francis@ecal.com|============================================| |Chief Scientist | NT's lack of reliability is only surpassed | |eCal Corp. | by its lack of scalability. -- John Kirch | \=============================================================/ From w3c-dist-auth-request@w3.org Thu Aug 26 10:02:05 1999 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19117 for ; Thu, 26 Aug 1999 10:02:04 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id JAA15713; Thu, 26 Aug 1999 09:51:24 -0400 (EDT) Resent-Date: Thu, 26 Aug 1999 09:51:24 -0400 (EDT) Resent-Message-Id: <199908261351.JAA15713@www19.w3.org> Message-ID: <8E3CFBC709A8D21191A400805F15E0DBD24414@crte147.wc.eso.mc.xerox.com> From: "Slein, Judith A" To: "'WebDAV'" Date: Thu, 26 Aug 1999 09:51:02 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Subject: Binding Spec: Why DELETE removes a binding, not a resource Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3214 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list Yaron: HTTP was crystal clear that DELETE deletes resources. If you want to just remove a name and not a resource then introduce a new method with that functionality. There has been a lotof discussion of this issue on the mailing list in the past. I think the best statements of the rationale for defining DELETE to be removing the binding identified by the request-URI are in these messages: http://lists.w3.org/Archives/Public/w3c-dist-auth/1999AprJun/0018.html http://lists.w3.org/Archives/Public/w3c-dist-auth/1999AprJun/0020.html --Judy Judith A. Slein Xerox Corporation jslein@crt.xerox.com (716)422-5169 800 Phillips Road 105/50C Webster, NY 14580 From w3c-dist-auth-request@w3.org Thu Aug 26 10:14:34 1999 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19610 for ; Thu, 26 Aug 1999 10:14:33 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id KAA15951; Thu, 26 Aug 1999 10:06:22 -0400 (EDT) Resent-Date: Thu, 26 Aug 1999 10:06:22 -0400 (EDT) Resent-Message-Id: <199908261406.KAA15951@www19.w3.org> Message-ID: <8E3CFBC709A8D21191A400805F15E0DBD24415@crte147.wc.eso.mc.xerox.com> From: "Slein, Judith A" To: "'John Stracke'" , "'WebDAV'" Date: Thu, 26 Aug 1999 10:05:45 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Redirect References Spec: "Passthrough" Header Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3215 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list Good point. --Judy Judith A. Slein Xerox Corporation jslein@crt.xerox.com (716)422-5169 800 Phillips Road 105/50C Webster, NY 14580 > -----Original Message----- > From: John Stracke [mailto:francis@ecal.com] > Sent: Wednesday, August 25, 1999 12:15 PM > To: 'WebDAV' > Subject: Re: Redirect References Spec: "Passthrough" Header > > > "Slein, Judith A" wrote: > > > Arguments against Using a Property > > > > 1. Two URLs would mean that 2 entries in the namespace > would be used up for > > every reference created. > > 2. Without Passthrough:, how do you find the property? > PROPFIND would get > 302d; you'd have no way to apply it to the reference itself. > > -- > /=============================================================\ > |John Stracke | My opinions are my own | S/MIME & HTML OK | > |francis@ecal.com|============================================| > |Chief Scientist | NT's lack of reliability is only surpassed | > |eCal Corp. | by its lack of scalability. -- John Kirch | > \=============================================================/ > > > From w3c-dist-auth-request@w3.org Thu Aug 26 11:03:25 1999 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21543 for ; Thu, 26 Aug 1999 11:03:24 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id KAA16902; Thu, 26 Aug 1999 10:52:57 -0400 (EDT) Resent-Date: Thu, 26 Aug 1999 10:52:57 -0400 (EDT) Resent-Message-Id: <199908261452.KAA16902@www19.w3.org> Message-ID: <8E3CFBC709A8D21191A400805F15E0DBD24416@crte147.wc.eso.mc.xerox.com> From: "Slein, Judith A" To: "'jamsden@us.ibm.com'" , "Slein, Judith A" Cc: w3c-dist-auth@w3.org Date: Thu, 26 Aug 1999 10:52:00 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Redirect References Spec: "Passthrough" Header Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3216 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list Comments in tags below. > -----Original Message----- > From: jamsden@us.ibm.com [mailto:jamsden@us.ibm.com] > Sent: Wednesday, August 25, 1999 1:15 PM > To: Slein, Judith A > Cc: w3c-dist-auth@w3.org > Subject: Re: Redirect References Spec: "Passthrough" Header > > > > > I think the Passthrough header is fine. Referencing aware > clients can use the > passthrough header without having to access the properties of > a resource first. > However, I don't understand why Passthrough: T wouldn't apply > to the target > resource and not return a 302. Seems like the client knows > what it wants to do > and is aware the request-URI is a reference. Why require the > extra round trip in > this case? You can *never* use redirect references to operate directly on target resources. That's what direct references were, but they have been removed from the spec. There are only 2 behaviors you can get out of redirect references: 302 or operate on the reference itself. For most methods the default behavior is 302, and you have to use Passthrough: F to have the method apply to the reference. For a few methods, the default behavior is apply to the reference, and you have to use Passthrough: T to get a 302. So what are the reasons for insisting that methods sent to redirect references never get applied directly to the target resource? 1. Even though direct references have been removed from the spec, we want to keep a clean distinction between direct and redirect references. We may decide to restore direct references some day. 2. It's a design goal that redirect references be simple to implement. They should require little more than the 302 mechanism already implemented. In particular, servers never have to resolve the reference. 2a. Servers never have to act as proxies in order to implement redirect references. We want to be sure that redirect references can be used for cross-server access to the target resource. This is especially important because it is unlikely that cross-server bindings will be implemented. So we need some sort of referencing that is sure to be usable across servers, and redirect references fill that gap -- provided that we never require the server to apply a method to the target resource. > Second, I don't think we should special case > method behavior based on > resource type. That is, Passthrough isn't specified, return > 302, if it is > specified, do what it says for all methods. We shouldn't make > cases like if this > is an XXX method whose request URI is reference to a > collection do one thing, > otherwise do something else. I think things are less complicated than you fear. I think what you really are asking is separate from the Passthrough: issue. It's about whether we should ever say that behavior is different depending upon whether (1) the Request-URI identifies a redirect reference, or whether (2) the Request-URI identifies a collection that turns out to contain a redirect reference. There is only one case where we do that: COPY. I agree with you that this is bad. I think we should say either (1) that the default behavior of COPY is to apply to the reference, whether the Request-URI identifies the reference or the reference is a member of the collection identified by the Request-URI, or (2) that the default behavior of COPY is to respond with a 302, whether the Request-URI identifies the reference or the reference is a member of the collection identified by the Request-URI. Here's a table of all the default behaviors for the different methods. That is, in the absence of a Passthrough: header, this is what happens. Request-URI is redirect ref Redirect Ref encountered while processing a collection PROPFIND 302 302 COPY 302 Apply to reference DELETE Apply to reference Apply to reference MOVE Apply to reference Apply to reference LOCK Apply to reference Apply to reference GET 302 N/A HEAD 302 N/A PUT 302 N/A POST 302 N/A OPTIONS 302 N/A PROPPATCH 302 N/A MKCOL 302 N/A MKREF 302 N/A BIND 302 N/A ORDERPATCH 302 N/A > This makes the protocol too > complicated and > brittle. It will inhibit server creation and > interoperability, and will result > in client behavior that will be difficult for users to > understand and predict. > The protocol should provide basic core capabilities that > clients can exploit for > various purposes in an interoperable way. For example, MOVE > vs. collection > merge, exposing vs. hiding redirect references, shallow or > deep locking, etc. > > > > > > From w3c-dist-auth-request@w3.org Thu Aug 26 11:07:16 1999 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21680 for ; Thu, 26 Aug 1999 11:07:15 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id KAA17059; Thu, 26 Aug 1999 10:58:59 -0400 (EDT) Resent-Date: Thu, 26 Aug 1999 10:58:59 -0400 (EDT) Resent-Message-Id: <199908261458.KAA17059@www19.w3.org> To: w3c-dist-auth@w3.org References: <19990825150437.7C68761046@aachen.heimat.de> From: Steinar Bang Date: 26 Aug 1999 15:57:41 +0200 In-Reply-To: ruebe@aachen.heimat.de's message of "Wed, 25 Aug 1999 17:04:37 +0200 (CEST)" Message-ID: Lines: 15 User-Agent: Gnus/5.070084 (Pterodactyl Gnus v0.84) XEmacs/20.4 (Emerald) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Re: Mozilla editor and DAV Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3217 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list >>>>> ruebe@aachen.heimat.de (Christian Scholz): > Wouldn't it make more sense if WebDAV functionality would be > implemented in the underlying OS as then every application > automatically would have access to it. But I see that maybe more > advanced features like properties etc. one would not be able to > handle that way (if it's only some sort of filesystem structure). > I once also asked on the Linux Kernel Mailing list and it looks as > if also there nobody is working on it.. Here's one idea at least http://rufus.w3.org/linux/httpfs/ But I don't think he's been looking at this for quite a while. From w3c-dist-auth-request@w3.org Thu Aug 26 13:23:11 1999 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25510 for ; Thu, 26 Aug 1999 13:23:09 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id NAA21278; Thu, 26 Aug 1999 13:13:57 -0400 (EDT) Resent-Date: Thu, 26 Aug 1999 13:13:57 -0400 (EDT) Resent-Message-Id: <199908261713.NAA21278@www19.w3.org> X-Authentication-Warning: sophia.inria.fr: Host ah-img-rel-1.compuserve.com [149.174.217.152] claimed to be hpamraaa.compuserve.com From: "Jean-Francois Tougard" To: "'Slein, Judith A'" , Cc: Date: Thu, 26 Aug 1999 17:15:48 +0200 Message-ID: <001701beefdf$f78fe260$64646464@vectra> 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 8.5, Build 4.71.2173.0 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Importance: Normal In-Reply-To: <8E3CFBC709A8D21191A400805F15E0DBD24416@crte147.wc.eso.mc.xerox.com> Subject: RE: Redirect References Spec: "Passthrough" Header - DUPLICATED MESSAGES Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3218 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list Content-Transfer-Encoding: 7bit I received from last days all messages duplicated.. Who knows what happens? Jean-Francois Tougard - Strategy Partners International 8, Sente des Favrils F-78570 ANDRESY Ph: +33-(0)1.39.75.00.10 Fax: +33-(0)1.39.70.53.27 Mobile GSM : +33-(0)6.09.24.27.24 http://www.strategy-partners.com http://www.ovum.com/reports/document_management.htm http://www.strategypartners.com/r3nt-toc.pdf http://www.strategy-partners.com/pdf/sum98.pdf -----Original Message----- From: w3c-dist-auth-request@w3.org [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Slein, Judith A Sent: Thursday, August 26, 1999 4:52 PM To: 'jamsden@us.ibm.com'; Slein, Judith A Cc: w3c-dist-auth@w3.org Subject: RE: Redirect References Spec: "Passthrough" Header Comments in tags below. > -----Original Message----- > From: jamsden@us.ibm.com [mailto:jamsden@us.ibm.com] > Sent: Wednesday, August 25, 1999 1:15 PM > To: Slein, Judith A > Cc: w3c-dist-auth@w3.org > Subject: Re: Redirect References Spec: "Passthrough" Header > > > > > I think the Passthrough header is fine. Referencing aware > clients can use the > passthrough header without having to access the properties of > a resource first. > However, I don't understand why Passthrough: T wouldn't apply > to the target > resource and not return a 302. Seems like the client knows > what it wants to do > and is aware the request-URI is a reference. Why require the > extra round trip in > this case? You can *never* use redirect references to operate directly on target resources. That's what direct references were, but they have been removed from the spec. There are only 2 behaviors you can get out of redirect references: 302 or operate on the reference itself. For most methods the default behavior is 302, and you have to use Passthrough: F to have the method apply to the reference. For a few methods, the default behavior is apply to the reference, and you have to use Passthrough: T to get a 302. So what are the reasons for insisting that methods sent to redirect references never get applied directly to the target resource? 1. Even though direct references have been removed from the spec, we want to keep a clean distinction between direct and redirect references. We may decide to restore direct references some day. 2. It's a design goal that redirect references be simple to implement. They should require little more than the 302 mechanism already implemented. In particular, servers never have to resolve the reference. 2a. Servers never have to act as proxies in order to implement redirect references. We want to be sure that redirect references can be used for cross-server access to the target resource. This is especially important because it is unlikely that cross-server bindings will be implemented. So we need some sort of referencing that is sure to be usable across servers, and redirect references fill that gap -- provided that we never require the server to apply a method to the target resource. > Second, I don't think we should special case > method behavior based on > resource type. That is, Passthrough isn't specified, return > 302, if it is > specified, do what it says for all methods. We shouldn't make > cases like if this > is an XXX method whose request URI is reference to a > collection do one thing, > otherwise do something else. I think things are less complicated than you fear. I think what you really are asking is separate from the Passthrough: issue. It's about whether we should ever say that behavior is different depending upon whether (1) the Request-URI identifies a redirect reference, or whether (2) the Request-URI identifies a collection that turns out to contain a redirect reference. There is only one case where we do that: COPY. I agree with you that this is bad. I think we should say either (1) that the default behavior of COPY is to apply to the reference, whether the Request-URI identifies the reference or the reference is a member of the collection identified by the Request-URI, or (2) that the default behavior of COPY is to respond with a 302, whether the Request-URI identifies the reference or the reference is a member of the collection identified by the Request-URI. Here's a table of all the default behaviors for the different methods. That is, in the absence of a Passthrough: header, this is what happens. Request-URI is redirect ref Redirect Ref encountered while processing a collection PROPFIND 302 302 COPY 302 Apply to reference DELETE Apply to reference Apply to reference MOVE Apply to reference Apply to reference LOCK Apply to reference Apply to reference GET 302 N/A HEAD 302 N/A PUT 302 N/A POST 302 N/A OPTIONS 302 N/A PROPPATCH 302 N/A MKCOL 302 N/A MKREF 302 N/A BIND 302 N/A ORDERPATCH 302 N/A > This makes the protocol too > complicated and > brittle. It will inhibit server creation and > interoperability, and will result > in client behavior that will be difficult for users to > understand and predict. > The protocol should provide basic core capabilities that > clients can exploit for > various purposes in an interoperable way. For example, MOVE > vs. collection > merge, exposing vs. hiding redirect references, shallow or > deep locking, etc. > > > > > > From w3c-dist-auth-request@w3.org Thu Aug 26 13:56:59 1999 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26209 for ; Thu, 26 Aug 1999 13:56:57 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id NAA22273; Thu, 26 Aug 1999 13:48:39 -0400 (EDT) Resent-Date: Thu, 26 Aug 1999 13:48:39 -0400 (EDT) Resent-Message-Id: <199908261748.NAA22273@www19.w3.org> From: Jim Whitehead To: Steinar Bang , w3c-dist-auth@w3.org MMDF-Warning: Parse error in original version of preceding line at gremlin-relay.ics.uci.edu Date: Thu, 26 Aug 1999 10:41:45 -0700 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.2910.0) In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Importance: Normal Subject: RE: Mozilla editor and DAV Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3219 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list Content-Transfer-Encoding: 7bit This approach seems to have occurred to several people. There was a paper in the 1997 Usenix Annual Technical Conference titled: "Extending the Operating System at the User level: the Ufo Global File System" Albert D. Alexandrov, Maximilian Ibel, Klaus E. Schauser, Chris J. Scheiman pages 77-90 http://www.cs.ucsb.edu/research/ufo/ "Ufo is a global file system. It allows users to treat remote files exactly as if they were local. Currently, Ufo supports file access through the FTP and HTTP protocols and allows new protocols to be plugged in. Ufo is implemented entirely at the user level using the Catcher. The Catcher is our tool for extending the functionality of standard UNIX operating systems completely at the user level. It works by intercepting selected system calls at the user level, using the existing /proc interface." I contacted them about a year ago, and told them about DAV. They mentioned that the project was no longer active, but that source code was available if someone was interested in picking it up and extending it. Their approach may be Solaris-specific. I did download their binary executable and ran it on a Solaris machine, and it worked pretty well. It was kinda neat being able to do an "ls" of the Internet-Drafts directory (and very useful to be able to use the ls wildcards to only find specific I-Ds). Of course, this approach highlighted for me why you want to have both tool integration and OS support. For example, if using Ufo (i.e., using only an OS integration) I wanted to do a grep of the I-D directory, it would be a really long operation, where every I-D would be locally downloaded, then searched. If, however, grep knew about DASL, it could then turn its request into a DASL query, which would execute much faster. It seems to me the advantage of OS integration is compatibility will all existing file-based tools, at the cost of some operations taking longer than the same operation performed by a tool that was tightly integrated with DAV, and hence could take advantage of DAV features to perform the operation in the most efficient way. So, I see advantages to both approaches, with the tight integration into every tool being the best possible choice. But, since this is going to take a while to occur, OS-level integration gives a good level of compatibility for the interim as tools add DAV support. - Jim > -----Original Message----- > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Steinar Bang > Sent: Thursday, August 26, 1999 6:58 AM > To: w3c-dist-auth@w3.org > Subject: Re: Mozilla editor and DAV > > > >>>>> ruebe@aachen.heimat.de (Christian Scholz): > > > Wouldn't it make more sense if WebDAV functionality would be > > implemented in the underlying OS as then every application > > automatically would have access to it. But I see that maybe more > > advanced features like properties etc. one would not be able to > > handle that way (if it's only some sort of filesystem structure). > > > I once also asked on the Linux Kernel Mailing list and it looks as > > if also there nobody is working on it.. > > Here's one idea at least > http://rufus.w3.org/linux/httpfs/ > > But I don't think he's been looking at this for quite a while. > From w3c-dist-auth-request@w3.org Mon Aug 30 16:58:17 1999 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15227 for ; Mon, 30 Aug 1999 16:58:15 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id QAA00236; Mon, 30 Aug 1999 16:37:26 -0400 (EDT) Resent-Date: Mon, 30 Aug 1999 16:37:26 -0400 (EDT) Resent-Message-Id: <199908302037.QAA00236@www19.w3.org> Date: Mon, 30 Aug 1999 16:36:22 -0400 Message-Id: <9908302036.AA01395@tantalum> From: "Geoffrey M. Clemm" To: yarong@Exchange.Microsoft.com Cc: w3c-dist-auth@w3.org In-Reply-To: <078292D50C98D2118D090008C7E9C6A601947374@STAY.platinum.corp.microsoft.com> (yarong@Exchange.Microsoft.com) Subject: Re: Advanced Collections & the WebDAV Object Model Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3220 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list I enthusiastically support the production of a "WebDAV object model", and apologize for the delay in responding to Yaron's original message. I'll make a few general comments in this message, and then break up my responses into separate threads to avoid confusion. From: "Yaron Goland (Exchange)" When I do return from vacation I will follow up this paper with one looking at the details of advanced collections as modeled by this paper and I will finish out the paper. If Yaron has time to do this (and do his real job and get any sleep :-), I will be both impressed and grateful! Note that bind becomes more about replication then NR(N1) = NR(N2) mapping That would suprise me, since the intent for BIND was explicitly to give clients control over the NR mapping, in particular, allowing the client to request that NR(N1) = NR(N2). and yes, the model for collections will work (I think) for versioning. That is of course something that I care a great deal about. I'll just copy the rest of Yaron's message here verbatim, for anyone whose mail threading system only keeps recent messages. Cheers, Geoff The WebDAV Object Model by Yaron Y. Goland July 15, 1999 Disclaimer Weasel words are always annoying but the following weasel words are important so please read them. There is no standardized formalization of the HTTP or WebDAV object models. Neither RFC 2616 nor RFC 2518 explicitly define their object models. Both, in fact, seem to spend quite a bit of time trying to not talk about their object models and rather to focus on presenting themselves as request/response protocols. This is unfortunate as it has lead to a lot of confusion regarding how these protocols should be extended. The author of this paper had some very definite ideas about how the HTTP and WebDAV object models worked as he helped to author RFC 2518. His ideas changed over time and the content of this paper is more rigorously defined than anything the author had actually thought of when helping to write RFC 2518. That is also unfortunate as RFC 2518 probably would have been clearer had the author written this paper several years earlier. Therefore the contents of this paper represent the opinions of the author and the author alone. Anyone who references this paper as being in anyway authoritative will be making a fool of themselves. However it is the author's hope that this paper will lead to the creation of a normative document which formally and rigorously defines both the HTTP and WebDAV object models. The author of this paper assumes that the reader has read and understood RFC 2616, RFC 2617 and RFC 2518, in that order. The Larry Masinter Disclaimer - The following document is not complete. I apologize for wasting your time with its meaningless prattle. Introduction The goal of this paper is to provide an object model that will completely describe the behavior of the URI namespace and HTTP resources as seen by HTTP clients. This model is completely unrelated to how one would actually implement an HTTP server. Rather it provides a robust model against which extensions to RFC 2616 and RFC 2518 can be judged so as to ensure that such extensions are consistent with the functionality already present in those two specifications. It is the expectation of the author of this paper that as future extensions are approved this paper will be extended to include them. [Will add a short summary of each major section.] 1 Namespace/Resource Space 1.1 In the beginning... There exists the namespace. The namespace is the set of all possible URIs. There exists the resource space. The resource space is the set of all currently existing resources. There exists a function NR() which maps from the namespace to the resource space. There exists another function RN() which maps from the resource space to the namespace. NR() is read as "Namespace to Resource space mapping function". The input to NR() is N, which represents a single member of the namespace. The output of NR() is R, which represents a single member of the resource space. RN() is read as "Resource space to namespace mapping function". The input to RN() is R, which represents a single member of the resource space. The output of RN() is the set n which contains zero or more members of the namespace. NR() is a one-to-one function. For each value in the namespace there exists one and only one value that it can map to in the resource space. RN() is a one-to-many function. For each value in the resource space there are zero to an infinite number of values it can map to in the namespace. For every N in the namespace there must be a value R as the output of NR(N). By default all NR(N) map to the NULL resource. For every R, RN(R) will output a set n but n may be empty. Thus while every N has an R not all Rs have Ns. 1.2 Form without... A resource is defined as an object able to accept requests and send responses. How a resource is actually implemented, how a namespace communicates with it and all other issues pertaining to the underlying nature of a resource are, by default, left completely undefined. Thus all we know about a resource is what we are able to learn by sending it requests via a member of the namespace and getting a response. 1.3 Call me Ishmael... RFC 2616 introduces the http URL subset of the URI namespace set. The basic form of the http URL is http://dest/segment/segment/...:port. Dest is either a domain name or an IP address. To send a message to a http name one first discovers the IP address for a domain name in dest or if an IP address is already provided then the message is sent directly to that IP address. A TCP port can also be specified, port 80 is the default. The message form provided by RFC 2616 places the segment information inside of the message. So RFC 2616 processing can be thought of as a multiple level multiplexer. The first level of demultiplexing is based on the IP address and port. The second level of demultiplexing occurs when the message is sent to the specified IP address/port and the segment information is provided. 1.4 Sprechen Sie... As a bit of a side note, the request-URI of a RFC 2616 message can accept any arbitrary URI. Therefore it is possible to use HTTP to speak with any member of the namespace. That is the theory. The reality is that trying to put non-HTTP URLs in an RFC 2616 message is a dangerous business. For example, if one makes a RFC 2616 request with the request URI foo:bar and get back a 404, does that mean that NR(foo:bar) == NULL? The answer is both yes and no, which is the problem. The answer is yes that for the specified IP address and port the processing system present there thinks that foo:bar is NULL but that doesn't mean that there isn't some other system someplace which could actually translate foo:bar. An example may help explain things better. Imagine one makes an HTTP request for ftp://foo/bar. Some HTTP systems can proxy this request properly and do something "intelligent." The rest will just reject it. So the value of NR(ftp://foo/bar) depends on who you ask. This problem doesn't exist with http URLs because there is a well defined master location. If you go to the specified IP address and port whatever you get in response is the definitive response from NR(http://whatever...). In the case of non-http URLs there does not, by default, exist a RFC 2616 based mechanism for determining if one is talking to the definitive processor for a particular non-http name. 1.5 Send in the methods... RFC 2616 defines a protocol called HTTP. HTTP provides a mechanism for sending requests, called methods, to a member of the namespace and receiving a response. The exact mechanism defined by HTTP is specified as: 1) A client sends a method formatted as specified by RFC 2616 to the member of the namespace specified by the request-URI. 2) The namespace member N performs the function NR(N) and passes the method to the resulting R through an unspecified mechanism. 3) R will return a result to N through an unspecified mechanism. 4) N will then pass that response in the format defined in RFC 2616 to the requestor. The key concept is that only resources can perform computations. The namespace only exists to forward requests to and send replies from resources. The format of a RFC 2616 request consists of a method name, a set of name/value pairs called headers and a byte stream called the body. In general RFC 2616 requests are called methods. The format of a RFC 2616 response consists of a response code, a response comment, headers and a body. It is possible for a resource to know the name of the namespace member who sends it a request. The resource may change its response based on the value of the namespace member who sent the request. So, for example, the foo method sent to N1 and N2, both of which map to R1, may end up with two different responses even though they were sent to the exact same resource. RFC 2616 also defines a set of standard methods - OPTIONS, GET, HEAD, POST, PUT, DELETE, TRACE and CONNECT. The following summaries of the method's functionality are meant to concentrate on the effect and interaction of the method with the namespace and resource space. Thus many details are left out. Note that the "code" listed below is executed inside of the resource. Also note that if the resource doesn't support the particular method then an error will be returned. The following are not really namespace related methods - OPTIONS(N) - Will return descriptive information about the functionality of R. Note that R may be aware of the value of N and therefore could return different information based the value of N. GET(N) - Will return a body whose value may or may not be chosen based on the value of submitted headers. HEAD(N) - Returns the headers, without the body, that would have been returned had the request been a GET(N). POST(N) - A well defined way to blow holes in firewalls. TRACE(N) - Ping for HTTP. CONNECT(N) - Just weird, don't worry about it. The following alter the value of NR() - PUT(N,G): R = NR(N); If (R != NULL) { R.GET = G; // Future responses to GET will be G return; } R' = R.CreateNewResource(); NR(N) = R'; R'.GET = G; return; The previous doesn't probably describe content negotiation, which will be discussed later in the paper. DELETE(N): If NR(N) = R is the NULL resource then the method will fail. If R is not the NULL resource then R is to be deleted from the resource space and all n in the output set to RN(R) are to have their NR(N) set to the NULL resource. 1.6 31 Flavors... Resources, as has already been implied, come in a number of different flavors. The first flavor of resource is the NULL resource. The NULL resource will reject all methods and their namespace representative will return a 404 for them. NULL should be thought of as a base type upon which many different resources inherit from. For example, a very common inheritor of NULL adds support for the PUT method. The PUT supporting NULL resource will accept PUT methods, will create a new resource and will set the GET output properly. RFC 2616 doesn't require that the NULL resource support OPTIONS so it isn't always possible to determine what sort of NULL resource one is talking to. 1.7 Moving on up... RFC 2616 does not provide for very much control over the output of NR(). PUT can be used to create a new R as a side effect and DELETE can be used to destroy a R, but that is it. For many applications more control is needed. Specifically, support for copy and move functionality. Copy and move allow one to change the NR() output in a manner that doesn't require clients to understand the fundamental nature of the underlying resources. The COPY and MOVE methods are defined by RFC 2518. COPY(Ns,Nd) - Rtemp = NR(Nd); If ((Rtemp != NULL) && (Overwrite == FALSE)) return(FAIL); Create(Rd); Rs = NR(Ns); Rd.State = Rs.State; // Just copying state information from Rs to Rd, the resources are independent of each other. NR(Nd) = Rs; If ((Rtemp != NULL) && (RN(Rtemp) == Empty Set)) // THIS IS OPTIONAL Destroy(Rtemp); MOVE(Ns, Nd) - Rtemp = NR(Nd); If ((Rtemp != NULL) && (Overwrite == FALSE)) return(FAIL); NR(Nd) = NR(Ns); NR(Ns) = NULL; If ((Rtemp != NULL) && (RN(Rtemp) == Empty Set)) // THIS IS OPTIONAL Destroy(Rtemp); 1.8 Good Fences Make Good Neighbors... RFC 2518 also provides for locking support that has some interesting effects on the relationship of the namespace to the resource space. LOCK(N,LockType) - R = NR(N); LockToken = R.Lock(LockType); return(LockToken); UNLOCK(N, LockToken) - R = NR(N); return(R.UnLock(LockToken)); The key point about locking to understand is that resources are locked, not namespace entries. The type of the lock then effects how the resource handles other types of requests. For example, if NR(N1) = NR(N2) and a write lock is executed on N1 then it will be impossible for a non-lock owner to delete N2 because N2 points to the same resource and write locks prevent deletion of the resource by non-lock owners. [Add an example of processing methods on locked resources in order to drive home the point that locks effect both the resource and the name under which the lock was sent in. So you could move N2 but not N1 if you had a write lock on N1. Actually, this should be a section on write locks in particular.] 2 Hierarchy 2.1 What We Have Here is a Failure to Communicate... The http URL namespace, as previously defined, consists of a series of segments that are separated by the "/" delimiter. This means that the http URL namespace is hierarchical. Thus hierarchical terminology applies. For example, http://foo/ is the parent of http://foo/bar. http://foo/bar/blah/ is the child of http://foo/bar/. An important subtlety of the http URL is that http://foo/bar and http://foo/bar/ are not necessarily the same resource. Therefore http://foo/bar/ and not http://foo/bar is the parent of http://foo/bar/blah and http://foo/bar/blah/. Also note that http://foo is not a legal http URL. 2.2 From Little Acorns... By default two resources related to each other through the namespace hierarchy do not necessarily have any semantic relationship. So just because R1 = NR(http://foo/) is the parent of R2 = NR(http://foo/bar) in the foo part of the http URL namespace this does not necessarily mean that R1 and R2 have any other relationship. Nevertheless, in many circumstances the fact that R2 was made the child of R1 in the foo subset of the http URL namespace does have semantic meanings. A common example is the use of WebDAV to implement a file hierarchy. As such, a mechanism is needed to enumerate a resource's children in a particular namespace in order to have a complete list of all the resources which have some relationship implied by their membership in some namespace. The trivial solution to this problem would be to introduce the SillyChild() function which takes a member N of the namespace as an argument and returns a set c of children. However SillyChild(N) would have an output that consists of every possible legal combination of characters since every possible URI in the universe is contained in the namespace. What is needed is the following Child() function: Child(N) - Set c = NULL; //c is a variable of type set that is initially empty for every child C of N if (NR(C) != NULL) add C to c; Return(c); In other words, one needs a way to list all children that map to a resource that does not inherit from NULL. RFC 2518 tackles this problem by introducing a new type of resource called a collection resource. Collection resources implement the Child function through the PROPFIND method. The actual functionality of the PROPFIND function is a bit more complex and will be discussed in detail later in this paper. Note that for a resource R for which NR(N1) == NR(N2) == R the answer R will give for PROPFIND when addressed through N1 will be different than the answer given for N2 assuming N1 != N2. This is because the child relationship is a function of the namespace and not of the resource space. This is a very subtle but important point so I will repeat it again - The child relationship is based on the naming relationships that exist within the namespace. That is why the same function can give totally unrelated answers for the PROPFIND method depending upon the name used to address the resource. Once one can list the children of a collection resource it is very temping to allow one to manipulate entire hierarchies of the namespace based on their child relations. RFC 2518 introduces the Depth header to provide this functionality. The Depth header, when used on a collection resource, allows one to specify that a method should apply to the resource and to its children for the number of levels specified by the Depth header. The Depth header current supports 0, 1 and infinite levels. Note that the Depth header is to be ignored if it is not used on a collection resource. RFC 2518 provides Depth support for the COPY, MOVE and DELETE methods. The following is an example of the COPY method enhanced to support Depth. Note that everything before the comment "Here is where we add depth support" is unchanged. COPY(Ns,Nd) - Rtemp = NR(Nd); If ((Rtemp != NULL) && (Overwrite == FALSE)) return(FAIL); Create(Rd); Rs = NR(Ns); Rd.State = Rs.State; // Just copying state information from Rs to Rd, the resources are independent of each other. NR(Nd) = Rs; If ((Rtemp != NULL) && (RN(Rtemp) == Empty Set)) // THIS IS OPTIONAL Destroy(Rtemp); // Here is where we add depth support if (Rs == Collection Resource) switch (depth) { case 0: return; case 1: depth = 0; //We assume all further COPY calls get this new value case infinity: break; default: //We ignore illegal depth values return; } for every child C of Ns if (NR(C) != NULL) COPY(C,Nd+Last_Segment(C)); Nd+Last_Segment(C) is used to build up the destination of the new destination argument. Nd is the base and the Last_Segment function takes the last function of the URI name of C and concatenates it with Nd. The point of providing this code is to drive home the point that depth based functions such as COPY, MOVE and DELETE are based on relationships established in the namespace and not on any relationships established in resource space. [Add in code for MOVE and DELETE.] Having introduced a new resource called a collection RFC 2518 also introduced a means to create such a resource through the MKCOL method. MKCOL(N) - R = NR(N); If (R != NULL) return(error); If (R != MKCOL supporting NULL resource) return(error); Create Resource R' as a collection; NR(N) = R'; 2.3 A little taxonomy... To understand the following conversation one needs to understand that RFC 2518 divides the world into two types of resources, DAV compliant and non-DAV compliant. The DAV compliant world is divided into two parts, level 1 and level 2. A level 1 DAV compliant resource support all the RFC 2616 methods plus COPY, MOVE, PROPFIND and PROPPATCH. A level 2 DAV compliant resource support everything a level 1 DAV compliant resource supports plus LOCK and UNLOCK. Level 1 and Level 2 DAV compliant resources also come in two flavors, collection and non-collection resources. A collection resource enforces the namespace consistency requirements defined below and support the Depth header. DAV Compliant Resources Level 1 Level 2 Non-Collection Resource RFC 2616 + COPY + MOVE + PROPFIND + PROPPATCH Non-Collection Level 1 Resource + LOCK + UNLOCK Collection Resource Non-Collection Level 1 Resource + Consistency Requirements + Depth Collection Level 1 Resource + LOCK + UNLOCK The purpose of the previous was to drive home the point that in the world of RFC 2518 there are two classes of resource, DAV and non-DAV compliant. 2.4 A foolish consistency is the hobgoblin of little minds... [For completeness I should talk about namespace consistency. I'm not going to, but I really should.] 3 Inheritance [We need to talk generally about the idea that a resource can inherit from multiple types of resources such as a DASL/Level 2/Bind enabled/Versionable resources.] Neither RFC 2616 nor RFC 2518 provide generic mechanisms to create arbitrary types of resources. There is no way, for example, to specify that one wants a DAV compliant level 1 non-collection resource. In the same way there is no way to specify what sort of NULL resource one wants. For example, a user may want to specify that N and all its children will point to a type of NULL resource that will only produce DAV Level 2 compliant resources. The only method current specified which sort of provide for the previous functionality is MKCOL. However even MKCOL doesn't allow the user to specify if the resulting collection should be Level 1 or Level 2. 4 WebDAV Properties PROPFIND PROPPATCH 5 Content Negotiation [Talk about the "client proposes - server disposes" model. Also talk about the difference between content-location and location. Focus on the ambiguity Henrik pointed out in content-location and content negotiation. You have the news paper problem and the language problem and the way you use content-location in each case is inconsistent with the other.] From w3c-dist-auth-request@w3.org Mon Aug 30 17:40:32 1999 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16257 for ; Mon, 30 Aug 1999 17:40:31 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id RAA13644; Mon, 30 Aug 1999 17:31:44 -0400 (EDT) Resent-Date: Mon, 30 Aug 1999 17:31:44 -0400 (EDT) Resent-Message-Id: <199908302131.RAA13644@www19.w3.org> Date: Mon, 30 Aug 1999 17:31:36 -0400 Message-Id: <9908302131.AA01419@tantalum> From: "Geoffrey M. Clemm" To: yarong@Exchange.Microsoft.com Cc: w3c-dist-auth@w3.org In-Reply-To: <078292D50C98D2118D090008C7E9C6A601947374@STAY.platinum.corp.microsoft.com> (yarong@Exchange.Microsoft.com) Subject: DELETE (was: Advanced Collections & the WebDAV Object Model) Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3221 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list From: "Yaron Goland (Exchange)" DELETE(N): If NR(N) = R is the NULL resource then the method will fail. If R is not the NULL resource then R is to be deleted from the resource space and all n in the output set to RN(R) are to have their NR(N) set to the NULL resource. An alternative definition of DELETE is: DELETE(N): If NR(N) = R is the NULL resource then the method will fail. If R is not the NULL resource, then NR(N) is set to NULL. A few observations: - These definitions are equivalent in the simple case where a resource has only a single name, and in many cases the latter definition is easier to implement (does not require a server to be able to compute RN(R)). - The former (i.e. "DESTROY") form of DELETE can be implemented by a client if it can discover the various names of a resource (see the advanced collection "all-bindings" property), whereas DESTROY cannot be used to implement the milder form of DELETE. - This is clearly a value judgement, but I believe it is better for downlevel clients to perform the weaker form of DELETE, since they may not be aware of all the other clients that are still using that resource under different names. If we introduce a DESTROY method, that should be only applied when specifically requested. This is especially true when versioning is introduced, since DESTROY is hardly ever the right thing to do, and certainly not by default by downlevel clients. Cheers, Geoff