From w3c-dist-auth-request@w3.org Thu Sep 2 10:33: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 KAA14458 for ; Thu, 2 Sep 1999 10:33:32 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id KAA21891; Thu, 2 Sep 1999 10:23:41 -0400 (EDT) Resent-Date: Thu, 2 Sep 1999 10:23:41 -0400 (EDT) Resent-Message-Id: <199909021423.KAA21891@www19.w3.org> Message-ID: <8E3CFBC709A8D21191A400805F15E0DBD24426@crte147.wc.eso.mc.xerox.com> From: "Slein, Judith A" To: "'WebDAV'" Date: Thu, 2 Sep 1999 10:23:22 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Subject: Bindings, Locks, and MOVE Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3222 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 authoring team for the bindings spec had a discussion of locks and MOVE in the context of bindings, and wants to test its conclusions with the mailing list members. (For a complete record of the discussion, see the minutes of 8/31/99, accessible from http://www.ics.uci.edu/pub/ietf/webdav/.) AGREED: For MOVE, if the source resource is locked (the lock is not inherited from a parent collection), the lock moves with it to the destination. If the destination resource is locked (the lock is not inherited from a parent collection), its lock is lost. For MOVE, if it's the parent collections that are locked, the resource being moved inherits the lock of the destination collection. If a collection is MOVEd, and there are some locked resources in that collection, the locks on those resources get moved. We don't require support for cross-server MOVEs where the source resource is locked, but we will define an optional lock header for use in responses, so that the destination server can change the lock token and return the new token with its response. If the server allows a cross- server MOVE but elects not to return a lock token value, the client can do lock discovery to find it out. If a cross-server MOVE is allowed in a case where there are multiple bindings to the source resource, and the source resource is locked, the result will be that the resource is locked on both servers with the same lock token in both places. (If the same lock token cannot be used, the MOVE must fail.) For COPY, any locks at the destination are deleted, and no new locks are created at the destination. After the COPY, there will be no locks at the destination except what is inherited from above. This is a reversal of the position taken in RFC 2518. Most people's intuition is that a MOVEd resource is the same resource, with the same state (including its lock state). The only rationale that has been presented for having locks be lost after a MOVE is the case of cross-server MOVEs. The source server and destination server may use different URI schemes for lock tokens, so that the destination server may be unwilling to keep the same lock token for the MOVEd resource. We can make support for cross-server MOVEs of locked resources optional, and allow the destination server to replace the lock token with a different lock token. We'll provide a response header for it to use to report the new lock token. AGREED: We'll change the language related to protecting the Request-URI to SHOULD. We intend this to protect the entire path, including the final segment. This does impact the definition of write locks in RFC 2518, which will have to change. It's no longer that a write lock MUST prevent MOVE and DELETE, but that it SHOULD prevent them. This discussion began with Yaron's comment that saying that "it MUST NOT be possible for a principal other than the lock owner to make a locked resource inaccessible via the URI mapping used to lock the resource" is too strong. It may make sense for write locks as defined in RFC 2518, but may not make sense for other sorts of locks that don't restrict MOVE and DELETE. The user expectation would be that the Request-URI used to lock the resource would continue to work for the duration of the lock, so we should go as far as is practical toward protecting the Request-URI. Locks can disappear anyhow due to administrator actions, and it is quite unlikely that anyone will interfere with the Request-URI while a lock is in force, so it's ok to weaken the normative language from "MUST NOT" to "SHOULD NOT". But we want to be consistent for the whole Request-URI. That would mean weakening the definition of write lock in RFC 2518, so that a write lock only SHOULD prevent other principals from MOVE or DELETE on the locked resource, not MUST. --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 Sep 2 14:55: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 OAA27945 for ; Thu, 2 Sep 1999 14:55:40 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id OAA01225; Thu, 2 Sep 1999 14:42:58 -0400 (EDT) Resent-Date: Thu, 2 Sep 1999 14:42:58 -0400 (EDT) Resent-Message-Id: <199909021842.OAA01225@www19.w3.org> From: Jim Whitehead To: WebDAV WG Date: Thu, 2 Sep 1999 11:39:49 -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: Minutes of Aug. 31 Adv. Col. teleconference Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3223 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 minutes of the August 31, 1999 Advanced Collections teleconference are available on the Web at: http://www.ics.uci.edu/pub/ietf/webdav/collection/dt/Minutes990831.txt - Jim From w3c-dist-auth-request@w3.org Thu Sep 2 17:55: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 RAA04480 for ; Thu, 2 Sep 1999 17:55:34 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id RAA05515; Thu, 2 Sep 1999 17:42:51 -0400 (EDT) Resent-Date: Thu, 2 Sep 1999 17:42:51 -0400 (EDT) Resent-Message-Id: <199909022142.RAA05515@www19.w3.org> From: ccjason@us.ibm.com X-Lotus-FromDomain: IBMUS Message-ID: <852567E0.00773FF3.00@D51MTA07.pok.ibm.com> Date: Thu, 2 Sep 1999 17:50:41 -0400 Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline To: undisclosed-recipients:; Subject: Re: Bindings, Locks, and MOVE Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3224 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 discussion began with Yaron's comment that saying that "it MUST NOT be possible for a principal other than the lock owner to make a locked resource inaccessible via the URI mapping used to lock the resource" is too strong. It may make sense for write locks as defined in RFC 2518, but may not make sense for other sorts of locks that don't restrict MOVE and DELETE. I believe that this is not specific to any particular type of locks. All clients need to insure that they have at the very least a way to unlock the the locks they have created. I assume that to unlock (a resource), we have to provide a URI of a (the?) resource locked by that lock... so if someone else changes the URI, it's very likely that we're not going to be able to figure out what the new URI is... and will have to leave the lock around until it times out. From w3c-dist-auth-request@w3.org Thu Sep 2 21:53: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 VAA08325 for ; Thu, 2 Sep 1999 21:53:28 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id VAA09161; Thu, 2 Sep 1999 21:44:32 -0400 (EDT) Resent-Date: Thu, 2 Sep 1999 21:44:32 -0400 (EDT) Resent-Message-Id: <199909030144.VAA09161@www19.w3.org> Date: Thu, 2 Sep 1999 21:44:23 -0400 Message-Id: <9909030144.AA02884@tantalum> From: "Geoffrey M. Clemm" To: w3c-dist-auth@w3.org In-Reply-To: <852567E0.00773FF3.00@D51MTA07.pok.ibm.com> (ccjason@us.ibm.com) Subject: Re: Bindings, Locks, and MOVE Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3225 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 This discussion began with Yaron's comment that saying that "it MUST NOT be possible for a principal other than the lock owner to make a locked resource inaccessible via the URI mapping used to lock the resource" is too strong. It may make sense for write locks as defined in RFC 2518, but may not make sense for other sorts of locks that don't restrict MOVE and DELETE. I believe that this is not specific to any particular type of locks. All clients need to insure that they have at the very least a way to unlock the the locks they have created. I assume that to unlock (a resource), we have to provide a URI of a (the?) resource locked by that lock... so if someone else changes the URI, it's very likely that we're not going to be able to figure out what the new URI is... and will have to leave the lock around until it times out. Since the server needs to deal with this in case the client just neglects to remove the lock, and if having another client MOVE your locked resource is a rare occurrence (which I believe it is), then this does not seem to be especially problematical. Cheers, Geoff From w3c-dist-auth-request@w3.org Fri Sep 3 02:40: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 CAA22721 for ; Fri, 3 Sep 1999 02:40:31 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id CAA12890; Fri, 3 Sep 1999 02:31:12 -0400 (EDT) Resent-Date: Fri, 3 Sep 1999 02:31:12 -0400 (EDT) Resent-Message-Id: <199909030631.CAA12890@www19.w3.org> Date: Fri, 3 Sep 1999 08:29:55 +0200 (MESZ) From: Edgar Schwarz X-Sender: Edgar.Schwarz@hpmx15.bk.bosch.de To: w3c-dist-auth@w3.org In-Reply-To: <9909030144.AA02884@tantalum> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: Re: Bindings, Locks, and MOVE Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3226 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, 2 Sep 1999, Geoffrey M. Clemm wrote: > From: ccjason@us.ibm.com > > > This discussion began with Yaron's comment that saying that "it MUST NOT be > possible for a principal other than the lock owner to make a locked resource > inaccessible via the URI mapping used to lock the resource" is too strong. > It may make sense for write locks as defined in RFC 2518, but may not make > sense for other sorts of locks that don't restrict MOVE and DELETE. > > > I believe that this is not specific to any particular type of locks. All > clients need to insure that they have at the very least a way to unlock > the the locks they have created. I assume that to unlock (a resource), we > have to provide a URI of a (the?) resource locked by that lock... so if > someone else changes the URI, it's > very likely that we're not going to be able to figure out what the new > URI is... and will have to leave the lock around until it times out. > > Since the server needs to deal with this in case the client just > neglects to remove the lock, and if having another client MOVE your > locked resource is a rare occurrence (which I believe it is), then > this does not seem to be especially problematical. Would it be possible to say: If a locked resource is moved the server SHOULD create a indirect reference resource which should exist for some sensible time. Yes I know, it's complicating the server :-) I imagine the above happening perhaps when somebody is reorganizing a directory structure and deep in the collections there are some locked resources. So the lock owner at least has a decent chance to find out where his resource has gone to. 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 Fri Sep 3 03:40: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 DAA23057 for ; Fri, 3 Sep 1999 03:40:55 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id DAA13758; Fri, 3 Sep 1999 03:31:29 -0400 (EDT) Resent-Date: Fri, 3 Sep 1999 03:31:29 -0400 (EDT) Resent-Message-Id: <199909030731.DAA13758@www19.w3.org> Message-ID: <37CF7775.334145A1@lyra.org> Date: Fri, 03 Sep 1999 00:23:33 -0700 From: Greg Stein X-Mailer: Mozilla 3.01 (X11; I; Linux 2.0.28 i586) MIME-Version: 1.0 To: w3c-dist-auth@w3.org References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: Bindings, Locks, and MOVE Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3227 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 whole thread (post-Judy's message) seems to be picking out a very minor detail of her post. Personally, I find this nit-picking of detail counter to the goal of her original post: "test its conclusions with the mailing list members." For myself (and mod_dav), the first "AGREED" portion makes complete sense, and I do agree with it. [btw, is *anybody* going to be implementing cross-server MOVE/COPY? is it necessary to have that feature in the spec at all? of the umpteen DAV servers out there now, I don't know any that do this or plan to do this. It would be nice to cut the thing and not worry about it.] The second "AGREED" portion does not make a whole lot of sense. The commentary states that the position is too strong [because it might not make sense with other types of locks]. Are there other locks out there? Do people have concrete, useful examples? I haven't heard of anything besides a write-lock yet. Regardless, I think it should be enforced in the spec that a write-lock MUST have guaranteed protection of the Request-URI. Put in some language that says other locks can define the MUST/SHOULD nature of protection. Otherwise, leave it in the intuitive state: a write lock says that others cannot monkey with your URI. Cheers, -g Edgar Schwarz wrote: > > On Thu, 2 Sep 1999, Geoffrey M. Clemm wrote: > > > From: ccjason@us.ibm.com > > > > > > This discussion began with Yaron's comment that saying that "it MUST NOT be > > possible for a principal other than the lock owner to make a locked resource > > inaccessible via the URI mapping used to lock the resource" is too strong. > > It may make sense for write locks as defined in RFC 2518, but may not make > > sense for other sorts of locks that don't restrict MOVE and DELETE. > > > > > > I believe that this is not specific to any particular type of locks. All > > clients need to insure that they have at the very least a way to unlock > > the the locks they have created. I assume that to unlock (a resource), we > > have to provide a URI of a (the?) resource locked by that lock... so if > > someone else changes the URI, it's > > very likely that we're not going to be able to figure out what the new > > URI is... and will have to leave the lock around until it times out. > > > > Since the server needs to deal with this in case the client just > > neglects to remove the lock, and if having another client MOVE your > > locked resource is a rare occurrence (which I believe it is), then > > this does not seem to be especially problematical. > Would it be possible to say: > If a locked resource is moved the server SHOULD create a indirect > reference resource which should exist for some sensible time. > > Yes I know, it's complicating the server :-) > I imagine the above happening perhaps when somebody is reorganizing > a directory structure and deep in the collections there are some > locked resources. > So the lock owner at least has a decent chance to find out where his > resource has gone to. > > 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. -- Greg Stein, http://www.lyra.org/ From w3c-dist-auth-request@w3.org Fri Sep 3 09:13: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 JAA29492 for ; Fri, 3 Sep 1999 09:13:35 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id JAA20501; Fri, 3 Sep 1999 09:04:26 -0400 (EDT) Resent-Date: Fri, 3 Sep 1999 09:04:26 -0400 (EDT) Resent-Message-Id: <199909031304.JAA20501@www19.w3.org> Message-ID: <37CFC733.86595E93@ecal.com> Date: Fri, 03 Sep 1999 09:03:48 -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: <37CF7775.334145A1@lyra.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Cross-server (was: Re: Bindings, Locks, and MOVE) Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3228 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 Greg Stein wrote: > [btw, is *anybody* going to be implementing cross-server MOVE/COPY? is > it necessary to have that feature in the spec at all? of the umpteen DAV > servers out there now, I don't know any that do this or plan to do this. It's still early, though. > It would be nice to cut the thing and not worry about it.] I dunno. I certainly appreciate not wanting to implement it; it's going to be a marginal case, especially since you can't expect that the request's WWW-Authenticate: will work for both servers. But it has the potential to be a really *useful* marginal case. :-) As long as the protocol designers are willing to expend the thought to make it work, and as long as the results don't overcomplicate the base case, I'd say leave it in. It occurs to me that one possible way to implement it would be in a proxy, which, in response to a cross-server COPY, would do what sitecopy does. Such a proxy could live out on a fast backbone site, providing services that would take too long if the client did them itself over a slow link; and it could store the user's credentials for various servers, so that it could provide the right credentials to each server it talks to. -- /============================================================\ |John Stracke |http://www.ecal.com|My opinions are my own.| |Chief Scientist |===========================================| |eCal Corp. |Speak softly and carry an Illudium Q-32 | |francis@ecal.com|Explosive Space Disintegrator. | \============================================================/ From w3c-dist-auth-request@w3.org Fri Sep 3 10:04: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 KAA02085 for ; Fri, 3 Sep 1999 10:04:51 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id JAA22237; Fri, 3 Sep 1999 09:53:51 -0400 (EDT) Resent-Date: Fri, 3 Sep 1999 09:53:51 -0400 (EDT) Resent-Message-Id: <199909031353.JAA22237@www19.w3.org> From: jamsden@us.ibm.com X-Lotus-FromDomain: IBMUS To: w3c-dist-auth@w3.org Message-ID: <852567E1.004C4EEF.00@d54mta03.raleigh.ibm.com> Date: Fri, 3 Sep 1999 09:50:44 -0400 Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Subject: Re: Bindings, Locks, and MOVE Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3229 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list DAV4J does do cross server COPY and MOVE. This is an important function required to support publishing web applications. DAV4J does it by reusing GET/PROPFIND and PUT/PROPPATCH (followed by DELETE if MOVE). The handling of live properties is a little tricky as PROPPATCH doesn't have anything like a propertybehavior element to specify what to do with the live properties like COPY and MOVE (I have proposed and extension to PROPPATCH that allows the client to specify how to handle errors on individual properties, see below). DAV4J does it for now by attempting the PROPPATCH, looking at the properties that failed, removes them from the PROPPATCH, and tries again. I know this isn't ideal, is an instance of server-to-server communication, and it makes COPY and MOVE very sloooooow, but its the best we could do for now. Proposed extensions to PROPPATCH: 1. 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. 2. 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. From w3c-dist-auth-request@w3.org Fri Sep 3 11:09: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 LAA04638 for ; Fri, 3 Sep 1999 11:09:41 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id LAA25196; Fri, 3 Sep 1999 11:00:13 -0400 (EDT) Resent-Date: Fri, 3 Sep 1999 11:00:13 -0400 (EDT) Resent-Message-Id: <199909031500.LAA25196@www19.w3.org> Message-ID: <37CFE257.2A33B290@ecal.com> Date: Fri, 03 Sep 1999 10:59:36 -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: <852567E1.004C4EEF.00@d54mta03.raleigh.ibm.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: Bindings, Locks, and MOVE Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3230 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 jamsden@us.ibm.com wrote: > Proposed extensions to PROPPATCH: > > 1. Extend the DAV:set and DAV:remove elements to include information describing > how the client wishes to handle errors. The DTD additions would be: I like this idea; I just have a syntactic quibble: > > > If an updatebehavior is not included, it is equivalent to specifying > * It might be better if, rather than using "*", you defined an element meaning the same thing. For now, "*" is simple enough; but, if we add more wildcards eventually, then it gets messier; we'd have to add more possible values, which starts getting into defining a separate syntax, with a separate parser. Simpler to use XML tags and let the existing parser handle it. -- /============================================================\ |John Stracke |http://www.ecal.com|My opinions are my own.| |Chief Scientist |===========================================| |eCal Corp. |Campbell's has it wrong--it's "Never | |francis@ecal.com|underestimate the power of *chocolate*". | \============================================================/ From w3c-dist-auth-request@w3.org Fri Sep 3 13:58: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 NAA09103 for ; Fri, 3 Sep 1999 13:58:36 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id NAA28978; Fri, 3 Sep 1999 13:49:54 -0400 (EDT) Resent-Date: Fri, 3 Sep 1999 13:49:54 -0400 (EDT) Resent-Message-Id: <199909031749.NAA28978@www19.w3.org> From: jamsden@us.ibm.com X-Lotus-FromDomain: IBMUS To: w3c-dist-auth@w3.org Message-ID: <852567E1.0061EC24.00@d54mta03.raleigh.ibm.com> Date: Fri, 3 Sep 1999 13:32:07 -0400 Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Subject: Re: Bindings, Locks, and MOVE Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3231 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list * was used to be consistent with the current DAV:keepalive element used by COPY and MOVE. John Stracke on 09/03/99 10:59:36 AM To: w3c-dist-auth@w3.org cc: Subject: Re: Bindings, Locks, and MOVE jamsden@us.ibm.com wrote: > Proposed extensions to PROPPATCH: > > 1. Extend the DAV:set and DAV:remove elements to include information describing > how the client wishes to handle errors. The DTD additions would be: I like this idea; I just have a syntactic quibble: > > > If an updatebehavior is not included, it is equivalent to specifying > * It might be better if, rather than using "*", you defined an element meaning the same thing. For now, "*" is simple enough; but, if we add more wildcards eventually, then it gets messier; we'd have to add more possible values, which starts getting into defining a separate syntax, with a separate parser. Simpler to use XML tags and let the existing parser handle it. -- /============================================================\ |John Stracke |http://www.ecal.com|My opinions are my own.| |Chief Scientist |===========================================| |eCal Corp. |Campbell's has it wrong--it's "Never | |francis@ecal.com|underestimate the power of *chocolate*". | \============================================================/ From w3c-dist-auth-request@w3.org Fri Sep 3 14:03: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 OAA09277 for ; Fri, 3 Sep 1999 14:03:11 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id NAA29130; Fri, 3 Sep 1999 13:54:38 -0400 (EDT) Resent-Date: Fri, 3 Sep 1999 13:54:38 -0400 (EDT) Resent-Message-Id: <199909031754.NAA29130@www19.w3.org> Message-ID: <37D00B39.9F1C14E6@ecal.com> Date: Fri, 03 Sep 1999 13:54:02 -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: <852567E1.0061EC24.00@d54mta03.raleigh.ibm.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: Bindings, Locks, and MOVE Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3232 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 jamsden@us.ibm.com wrote: > * was used to be consistent with the current DAV:keepalive element used by COPY > and MOVE. Ah--I'd forgotten about that. OK, never mind, then; better to be consistent. -- /============================================================\ |John Stracke |http://www.ecal.com|My opinions are my own.| |Chief Scientist |===========================================| |eCal Corp. |Earth: love it or leave it. | |francis@ecal.com| | \============================================================/ From w3c-dist-auth-request@w3.org Sat Sep 4 21:45: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 VAA07145 for ; Sat, 4 Sep 1999 21:45:49 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id UAA28567; Sat, 4 Sep 1999 20:57:04 -0400 (EDT) Resent-Date: Sat, 4 Sep 1999 20:57:04 -0400 (EDT) Resent-Message-Id: <199909050057.UAA28567@www19.w3.org> Date: Sat, 4 Sep 1999 20:56:55 -0400 Message-Id: <9909050056.AA03594@tantalum> From: "Geoffrey M. Clemm" To: jamsden@us.ibm.com Cc: w3c-dist-auth@w3.org In-Reply-To: <852567E1.004C4EEF.00@d54mta03.raleigh.ibm.com> (jamsden@us.ibm.com) Subject: Re: Bindings, Locks, and MOVE Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3233 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: jamsden@us.ibm.com DAV4J does do cross server COPY and MOVE. This is an important function required to support publishing web applications. DAV4J does it by reusing GET/PROPFIND and PUT/PROPPATCH (followed by DELETE if MOVE). Let me modify Greg's question just a bit: Is anybody going to be implementing cross-server MOVE as anything more than a cross-server COPY followed by a DELETE? The reason I ask is that it is a MOVE that has all the tricky interactions with multiple bindings and locks, while a COPY is relatively straightforward (new resources are created, so bindings and locks are not affected). In particular, I'd advocate making cross-server COPY's a MUST (or at least a SHOULD), while a cross-server MOVE's a MAY (or at most a SHOULD). My main argument against MOVE is that unless the "fixup" step that comes between the logical "COPY and the MOVE" is well defined (as it is in the advanced collection spec), the MOVE semantics is so vague as to be useless. Then a client that wants the COPY/DELETE form of "MOVE" can just issue a COPY followed by a DELETE. Cheers, Geoff From w3c-dist-auth-request@w3.org Sun Sep 5 14:44: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 OAA24251 for ; Sun, 5 Sep 1999 14:44:28 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id NAA05641; Sun, 5 Sep 1999 13:55:33 -0400 (EDT) Resent-Date: Sun, 5 Sep 1999 13:55:33 -0400 (EDT) Resent-Message-Id: <199909051755.NAA05641@www19.w3.org> From: jamsden@us.ibm.com X-Lotus-FromDomain: IBMUS To: w3c-dist-auth@w3.org cc: moore@cs.utk.edu, paf@swip.net Message-ID: <852567E3.00624A4F.00@d54mta03.raleigh.ibm.com> Date: Sun, 5 Sep 1999 13:52:24 -0400 Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Subject: WebDAV Working Group Meeting Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3234 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list WebDAV Working Group Members, We are considering a WebDAV working group meeting sometime before the November IETF meeting to help move the spec to Draft Standard. There are a lot of items to cover, perhaps too much to handle effectively in the 1-2 hour meetings available at IETF. Hopefully this meeting would provide action items, issue resolutions, and conclusions that we could use to hit the ground running at the November IETF. The proposed agenda is: 1. Discuss creating a WebDAV support organization ("webdav.org") 2. Discuss the future of the WebDAV effort With the WG closing soon, we should determine if is a need to create a new WG (DAVEXT, say) for known extensions (access control, schemas, etc.). What work items should be addressed by this new WG? 3. Organizing an interoperability event 4. Moving RFC 2518 to Draft Standard 5. Final review on the Advanced Collections specifications 6. Discuss/review/work on the Access Control specification 7. Review/work on DASL (DAV Searching and Locating) 8. Discussion/review/work on the Delta-V protocol IBM is considering hosting this meeting at our Research Triangle Park facility in RTP NC during the week of October 25. We would like some feedback to see if there is sufficient interest, additional agenda items, and an indication of how may working group members would be interested in attending. If there is sufficient interest and attendance, we will petition the area directors for permission to schedule the meeting. Thank you for you continued interest in WebDAV. Sent by Jim Amsden and Jim Whitehead From w3c-dist-auth-request@w3.org Tue Sep 7 10:34: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 KAA09751 for ; Tue, 7 Sep 1999 10:34:18 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id KAA17940; Tue, 7 Sep 1999 10:24:00 -0400 (EDT) Resent-Date: Tue, 7 Sep 1999 10:24:00 -0400 (EDT) Resent-Message-Id: <199909071424.KAA17940@www19.w3.org> Message-ID: <8E3CFBC709A8D21191A400805F15E0DBD24430@crte147.wc.eso.mc.xerox.com> From: "Slein, Judith A" To: "'Greg Stein'" , w3c-dist-auth@w3.org Date: Tue, 7 Sep 1999 10:19:04 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Bindings, Locks, and MOVE Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3235 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list Thanks for bringing the discussion back to earth. I agree with you that the compromise of saying that servers SHOULD protect the path of the Request-URI used in locking a resource is a poor one. It doesn't respond to the issue that was raised, and it needlessly muddies the waters for clients, which now don't know whether the path will be protected or not. I like your suggestion that we keep the MUST language, but state that it applies only to write locks. --Judy > -----Original Message----- > From: Greg Stein [mailto:gstein@lyra.org] > Sent: Friday, September 03, 1999 3:24 AM > To: w3c-dist-auth@w3.org > Subject: Re: Bindings, Locks, and MOVE > > > This whole thread (post-Judy's message) seems to be picking out a very > minor detail of her post. Personally, I find this nit-picking > of detail > counter to the goal of her original post: "test its > conclusions with the > mailing list members." > > For myself (and mod_dav), the first "AGREED" portion makes complete > sense, and I do agree with it. > [btw, is *anybody* going to be implementing cross-server MOVE/COPY? is > it necessary to have that feature in the spec at all? of the > umpteen DAV > servers out there now, I don't know any that do this or plan > to do this. > It would be nice to cut the thing and not worry about it.] > > The second "AGREED" portion does not make a whole lot of sense. The > commentary states that the position is too strong [because it > might not > make sense with other types of locks]. Are there other locks > out there? > Do people have concrete, useful examples? I haven't heard of anything > besides a write-lock yet. Regardless, I think it should be enforced in > the spec that a write-lock MUST have guaranteed protection of the > Request-URI. Put in some language that says other locks can define the > MUST/SHOULD nature of protection. Otherwise, leave it in the intuitive > state: a write lock says that others cannot monkey with your URI. > > Cheers, > -g > > Edgar Schwarz wrote: > > > > On Thu, 2 Sep 1999, Geoffrey M. Clemm wrote: > > > > > From: ccjason@us.ibm.com > > > > > > > > > This discussion began with Yaron's comment that saying > that "it MUST NOT be > > > possible for a principal other than the lock owner to > make a locked resource > > > inaccessible via the URI mapping used to lock the > resource" is too strong. > > > It may make sense for write locks as defined in RFC > 2518, but may not make > > > sense for other sorts of locks that don't restrict > MOVE and DELETE. > > > > > > > > > I believe that this is not specific to any particular > type of locks. All > > > clients need to insure that they have at the very > least a way to unlock > > > the the locks they have created. I assume that to > unlock (a resource), we > > > have to provide a URI of a (the?) resource locked by > that lock... so if > > > someone else changes the URI, it's > > > very likely that we're not going to be able to figure > out what the new > > > URI is... and will have to leave the lock around until > it times out. > > > > > > Since the server needs to deal with this in case > the client just > > > neglects to remove the lock, and if having another client > MOVE your > > > locked resource is a rare occurrence (which I believe it is), then > > > this does not seem to be especially problematical. > > Would it be possible to say: > > If a locked resource is moved the server SHOULD create a indirect > > reference resource which should exist for some sensible time. > > > > Yes I know, it's complicating the server :-) > > I imagine the above happening perhaps when somebody is reorganizing > > a directory structure and deep in the collections there are some > > locked resources. > > So the lock owner at least has a decent chance to find out where his > > resource has gone to. > > > > 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. > > -- > Greg Stein, http://www.lyra.org/ > From w3c-dist-auth-request@w3.org Tue Sep 7 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 NAA13837 for ; Tue, 7 Sep 1999 13:30:47 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id NAA22442; Tue, 7 Sep 1999 13:19:58 -0400 (EDT) Resent-Date: Tue, 7 Sep 1999 13:19:58 -0400 (EDT) Resent-Message-Id: <199909071719.NAA22442@www19.w3.org> From: Daniel LaLiberte Message-ID: <14293.18732.859667.961124@alceste.w3.org> Date: Tue, 7 Sep 1999 13:19:40 -0400 (EDT) To: "Geoffrey M. Clemm" Cc: w3c-dist-auth@w3.org In-Reply-To: <9909050056.AA03594@tantalum> References: <852567E1.004C4EEF.00@d54mta03.raleigh.ibm.com> <9909050056.AA03594@tantalum> X-Mailer: VM 6.67 under 20.4 "Emerald" XEmacs Lucid Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Subject: Replication vs Cloning (was: Bindings, Locks, and MOVE) Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3236 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list Geoffrey M. Clemm writes: > Is anybody going to be implementing cross-server MOVE as anything > more than a cross-server COPY followed by a DELETE? A cross-server MOVE has to be more than just a cross-server COPY followed by a DELETE, unless the COPY is a full replication rather than mere cloning, or the MOVE is a mere cloning rather than a full replication. Are you suggesting that such a cross-server MOVE would always result in a new resource rather than the same resource at a different location? To clarify, what I mean by a replica is a true copy, like a clone but with the additional property that any change to one replica should be reflected in all other replicas. Perhaps replicas could be or should be built on top of WebDAV at a higher level, but the D in WebDAV is already about managing copies of resources to support remote authoring in such a way that all the copies appear to be consistent replicas. That is why we have locks in the first place, although there are other techniques for managing consistency. > The reason > I ask is that it is a MOVE that has all the tricky interactions > with multiple bindings and locks, while a COPY is relatively > straightforward (new resources are created, so bindings and locks > are not affected). > > In particular, I'd advocate making cross-server COPY's a MUST > (or at least a SHOULD), while a cross-server MOVE's a MAY > (or at most a SHOULD). My main argument against MOVE is that > unless the "fixup" step that comes between the logical > "COPY and the MOVE" is well defined (as it is in the > advanced collection spec), the MOVE semantics is so vague > as to be useless. I agree that it would be bad to have MOVE mean "same resource" in one case (same-server) and "different resource" in another case (cross-server). Whether a resource ends up on the same server or not should be irrelevant. Even within the same server, the resource might move across file system boundaries which requires the equivalent of a copy. > Then a client that wants the COPY/DELETE form of "MOVE" can just > issue a COPY followed by a DELETE. We should distinguish these two cases. I'll call the first replica-MOVE and the second clone-MOVE. Similarly, we can distinguish two forms of COPY: replica-COPY and clone-COPY. A replica-MOVE can be implemented as a replica-COPY followed by a DELETE. A clone-MOVE can be implemented as a clone-COPY followed by a DELETE. Another important difference between the one MOVE operation and the two operations COPY followed by DELETE is whether the combined operations are atomic. For a clone-MOVE, this atomic property is (probably) not an issue unless someone needs to know that a new resource has been created before the old resource is deleted. For a replica-MOVE, the atomic property is important if someone is given write access to the old replica after the replica-COPY but before the DELETE since the new replica may not expect any changes to occur via the old replica. I don't know why the replication operations are that difficult to implement, although I can see that they are more difficult than cloning. I know there is much more work involved in maintaining replicas than initially making replicas. But I suggest that since WebDAV is intended to support some form of replication (i.e. distributed authoring) the specifications should do one of two things: 1. Add support for replication, both replica-COPY and replica-MOVE in addition to clone-COPY and clone-MOVE, both same-server and cross-server. 2. Include enough support to allow applications to build all those operations on top of WebDAV. In any case, we should be clear about the level of support WebDAV has for replication, whether it is only same-server replica-MOVE, or build-your-own replication via atomic LOCKs. -- Daniel LaLiberte liberte@w3.org From w3c-dist-auth-request@w3.org Tue Sep 7 20:58: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 UAA19713 for ; Tue, 7 Sep 1999 20:58:40 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id UAA28941; Tue, 7 Sep 1999 20:49:22 -0400 (EDT) Resent-Date: Tue, 7 Sep 1999 20:49:22 -0400 (EDT) Resent-Message-Id: <199909080049.UAA28941@www19.w3.org> Message-ID: <078292D50C98D2118D090008C7E9C6A603C9659B@STAY.platinum.corp.microsoft.com> From: "Yaron Goland (Exchange)" To: "'Slein, Judith A'" , "'Greg Stein'" , w3c-dist-auth@w3.org Date: Tue, 7 Sep 1999 17:49:07 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Bindings, Locks, and MOVE Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3237 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list Phew!!! I couldn't believe what I was reading regarding write locks. What use is a write lock that only sometimes is a write lock? Yikes. I'm glad that is dead. However there is still a point in the original post that concerns me. Let's see if I understand the proposal: When copying a resource into a tree that is currently locked then the lock on that tree is lost? Is that the proposal for how to handle locks at the destination of a copied resource? That is my reading of the paragraph Judy provided. Yaron > -----Original Message----- > From: Slein, Judith A [mailto:JSlein@crt.xerox.com] > Sent: Tue, September 07, 1999 7:19 AM > To: 'Greg Stein'; w3c-dist-auth@w3.org > Subject: RE: Bindings, Locks, and MOVE > > > Thanks for bringing the discussion back to earth. > > I agree with you that the compromise of saying that servers > SHOULD protect > the path of the Request-URI used in locking a resource is a > poor one. It > doesn't respond to the issue that was raised, and it > needlessly muddies the > waters for clients, which now don't know whether the path > will be protected > or not. > > I like your suggestion that we keep the MUST language, but > state that it > applies only to write locks. > > --Judy > > > > -----Original Message----- > > From: Greg Stein [mailto:gstein@lyra.org] > > Sent: Friday, September 03, 1999 3:24 AM > > To: w3c-dist-auth@w3.org > > Subject: Re: Bindings, Locks, and MOVE > > > > > > This whole thread (post-Judy's message) seems to be picking > out a very > > minor detail of her post. Personally, I find this nit-picking > > of detail > > counter to the goal of her original post: "test its > > conclusions with the > > mailing list members." > > > > For myself (and mod_dav), the first "AGREED" portion makes complete > > sense, and I do agree with it. > > [btw, is *anybody* going to be implementing cross-server > MOVE/COPY? is > > it necessary to have that feature in the spec at all? of the > > umpteen DAV > > servers out there now, I don't know any that do this or plan > > to do this. > > It would be nice to cut the thing and not worry about it.] > > > > The second "AGREED" portion does not make a whole lot of sense. The > > commentary states that the position is too strong [because it > > might not > > make sense with other types of locks]. Are there other locks > > out there? > > Do people have concrete, useful examples? I haven't heard > of anything > > besides a write-lock yet. Regardless, I think it should be > enforced in > > the spec that a write-lock MUST have guaranteed protection of the > > Request-URI. Put in some language that says other locks can > define the > > MUST/SHOULD nature of protection. Otherwise, leave it in > the intuitive > > state: a write lock says that others cannot monkey with your URI. > > > > Cheers, > > -g > > > > Edgar Schwarz wrote: > > > > > > On Thu, 2 Sep 1999, Geoffrey M. Clemm wrote: > > > > > > > From: ccjason@us.ibm.com > > > > > > > > > > > > This discussion began with Yaron's comment that saying > > that "it MUST NOT be > > > > possible for a principal other than the lock owner to > > make a locked resource > > > > inaccessible via the URI mapping used to lock the > > resource" is too strong. > > > > It may make sense for write locks as defined in RFC > > 2518, but may not make > > > > sense for other sorts of locks that don't restrict > > MOVE and DELETE. > > > > > > > > > > > > I believe that this is not specific to any particular > > type of locks. All > > > > clients need to insure that they have at the very > > least a way to unlock > > > > the the locks they have created. I assume that to > > unlock (a resource), we > > > > have to provide a URI of a (the?) resource locked by > > that lock... so if > > > > someone else changes the URI, it's > > > > very likely that we're not going to be able to figure > > out what the new > > > > URI is... and will have to leave the lock around until > > it times out. > > > > > > > > Since the server needs to deal with this in case > > the client just > > > > neglects to remove the lock, and if having another client > > MOVE your > > > > locked resource is a rare occurrence (which I believe > it is), then > > > > this does not seem to be especially problematical. > > > Would it be possible to say: > > > If a locked resource is moved the server SHOULD create > a indirect > > > reference resource which should exist for some sensible time. > > > > > > Yes I know, it's complicating the server :-) > > > I imagine the above happening perhaps when somebody is > reorganizing > > > a directory structure and deep in the collections there are some > > > locked resources. > > > So the lock owner at least has a decent chance to find > out where his > > > resource has gone to. > > > > > > 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. > > > > -- > > Greg Stein, http://www.lyra.org/ > > > From w3c-dist-auth-request@w3.org Tue Sep 7 20:58: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 UAA19724 for ; Tue, 7 Sep 1999 20:58:44 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id UAA28989; Tue, 7 Sep 1999 20:50:17 -0400 (EDT) Resent-Date: Tue, 7 Sep 1999 20:50:17 -0400 (EDT) Resent-Message-Id: <199909080050.UAA28989@www19.w3.org> Message-ID: <078292D50C98D2118D090008C7E9C6A603C9659C@STAY.platinum.corp.microsoft.com> From: "Yaron Goland (Exchange)" To: "'Geoffrey M. Clemm'" , jamsden@us.ibm.com Cc: w3c-dist-auth@w3.org Date: Tue, 7 Sep 1999 17:50:03 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Bindings, Locks, and MOVE Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3238 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list That the spec needs to address the issue of cross-server anything indicates that the specification is fundamentally broken and needs to be re-written. The spec should not need to address these issues at all. Rather it should provide a well defined start and end state. It is up to the server to figure out what that means in application. I suspect y'all have taken a serious wrong term somewhere. Yaron > -----Original Message----- > From: Geoffrey M. Clemm [mailto:gclemm@tantalum.atria.com] > Sent: Sat, September 04, 1999 5:57 PM > To: jamsden@us.ibm.com > Cc: w3c-dist-auth@w3.org > Subject: Re: Bindings, Locks, and MOVE > > > From: jamsden@us.ibm.com > > DAV4J does do cross server COPY and MOVE. This is an important > function required to support publishing web applications. > DAV4J does > it by reusing GET/PROPFIND and PUT/PROPPATCH (followed by DELETE if > MOVE). > > Let me modify Greg's question just a bit: > > Is anybody going to be implementing cross-server MOVE as anything > more than a cross-server COPY followed by a DELETE? The reason > I ask is that it is a MOVE that has all the tricky interactions > with multiple bindings and locks, while a COPY is relatively > straightforward (new resources are created, so bindings and locks > are not affected). > > In particular, I'd advocate making cross-server COPY's a MUST > (or at least a SHOULD), while a cross-server MOVE's a MAY > (or at most a SHOULD). My main argument against MOVE is that > unless the "fixup" step that comes between the logical > "COPY and the MOVE" is well defined (as it is in the > advanced collection spec), the MOVE semantics is so vague > as to be useless. > > Then a client that wants the COPY/DELETE form of "MOVE" can just > issue a COPY followed by a DELETE. > > Cheers, > Geoff > From w3c-dist-auth-request@w3.org Tue Sep 7 21:21: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 VAA19891 for ; Tue, 7 Sep 1999 21:21:04 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id VAA29401; Tue, 7 Sep 1999 21:11:56 -0400 (EDT) Resent-Date: Tue, 7 Sep 1999 21:11:56 -0400 (EDT) Resent-Message-Id: <199909080111.VAA29401@www19.w3.org> Message-ID: <078292D50C98D2118D090008C7E9C6A603C965A0@STAY.platinum.corp.microsoft.com> From: "Yaron Goland (Exchange)" To: "'jamsden@us.ibm.com'" , w3c-dist-auth@w3.org Cc: moore@cs.utk.edu, paf@swip.net Date: Tue, 7 Sep 1999 18:11:15 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Subject: RE: WebDAV Working Group Meeting Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3239 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list General comment: Why do we need a meeting for this? This sounds like great material for an e-mail list and it will have the extra added benefit of allowing everyone to participate. I don't know about you folks but NC is REALLY far away from where I am. > 1. Discuss creating a WebDAV support organization ("webdav.org") But, it already exists. http://webdav.org > 2. Discuss the future of the WebDAV effort > > With the WG closing soon, we should determine if is a need to > create a new WG > (DAVEXT, say) for known extensions (access control, schemas, > etc.). What work > items should be addressed by this new WG? Individual submissions sound fine to me. No need to clutter up the IETF with a whole bunch of WGs for every effort under the sun. If an effort gets big enough then it can go for WG status. > 3. Organizing an interoperability event Why? I know bake offs are popular but WebDAV seems to have been having a continual back off for months now just by having folks put their implementations on the net. Unless I have seriously missed something it seems to work damn well. > 4. Moving RFC 2518 to Draft Standard Personally, I would like to see this held off for at least a year. I think it was a huge mistake for HTTP/1.1 to push to draft status long before there was any real experience with the protocol. Except for a few propeller head implementations there wasn't a single full featured commercial HTTP/1.1 client or proxy implementation available when HTTP/1.1 started going to draft status. The end result is that RFC 2616 added very little value and a lot of confusion. I think we should take this as a model of what not to do. Instead we should wait until a number of implementations, both on the client and server side, are widely deployed and we get some real world experience. That has not happened yet, not even close. > 5. Final review on the Advanced Collections specifications The only relevant review of the AC draft is, of course, on the e-mail list but I can certainly appreciate why you would want to do this at a meeting. However I think we have enough time at the IETF for this. > 6. Discuss/review/work on the Access Control specification Indeed, this has been a real problem. I am going to get out a new version of the ACL draft which I think basically has it right, it just needs some clean up. Comments are always welcome. If anyone has the meeting notes for the Florida ACL chat please put up a link, I think the discussion was extremely informative as to why there hasn't been a lot of progress on ACLs. > 7. Review/work on DASL (DAV Searching and Locating) Huh? Isn't that why we have a DASL WG? > 8. Discussion/review/work on the Delta-V protocol How about we first get a charter. But, that having been said, a meeting on Delta-V would obviously be very useful. > > IBM is considering hosting this meeting at our Research > Triangle Park facility > in RTP NC during the week of October 25. Sigh... I wish we could do this after the IETF. The week of Oct 20th is pretty bad for me. But of course, that is just me. > We would like some > feedback to see if > there is sufficient interest, additional agenda items, and an > indication of how > may working group members would be interested in attending. > If there is > sufficient interest and attendance, we will petition the area > directors for > permission to schedule the meeting. Thank you for you > continued interest in > WebDAV. ADs do not give permission to schedule meetings outside the IETF. Why would they? The only place you can do anything "on the record" is on the e-mail list. The IETF meetings are just a convenience to help the mailing lists better function and meetings outside of the IETF meetings are completely outside the purview of the IETF. The only time the IETF gets involved with meetings held completely outside the IETF process is if those meetings start being where real work is done to the detriment of the mailing list. In that case the ADs will step in. A classic example of what not to do would be the IPP effort. Either way, unless Keith has changed his mind, as of the end of this month WebDAV is closed. There is no more WebDAV, there are no more meetings. That doesn't mean you shouldn't have meetings on ACLs and on Delta-V. In fact, by the next IETF Delta-V should be a WG (Keith?). I know we have had ACL meetings but I don't know if we ever had a BOF. > > Sent by Jim Amsden and Jim Whitehead > Send by Yaron From w3c-dist-auth-request@w3.org Tue Sep 7 21:37: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 VAA20040 for ; Tue, 7 Sep 1999 21:37:21 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id VAA29556; Tue, 7 Sep 1999 21:29:01 -0400 (EDT) Resent-Date: Tue, 7 Sep 1999 21:29:01 -0400 (EDT) Resent-Message-Id: <199909080129.VAA29556@www19.w3.org> Message-Id: <199909080123.VAA23508@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: "Yaron Goland (Exchange)" cc: "'jamsden@us.ibm.com'" , w3c-dist-auth@w3.org, moore@cs.utk.edu, paf@swip.net In-reply-to: Your message of "Tue, 07 Sep 1999 18:11:15 PDT." <078292D50C98D2118D090008C7E9C6A603C965A0@STAY.platinum.corp.microsoft.com> Date: Tue, 07 Sep 1999 21:23:50 -0400 Subject: Re: WebDAV Working Group Meeting Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3240 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 fact, by > the next IETF Delta-V should be a WG (Keith?). chances are good. the charter is currently being discussed by iesg and iab. Keith From w3c-dist-auth-request@w3.org Wed Sep 8 09:19: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 JAA12446 for ; Wed, 8 Sep 1999 09:19:16 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id IAA08061; Wed, 8 Sep 1999 08:53:46 -0400 (EDT) Resent-Date: Wed, 8 Sep 1999 08:53:46 -0400 (EDT) Resent-Message-Id: <199909081253.IAA08061@www19.w3.org> From: jamsden@us.ibm.com X-Lotus-FromDomain: IBMUS To: w3c-dist-auth@w3.org Message-ID: <852567E6.0046C3BD.00@d54mta03.raleigh.ibm.com> Date: Wed, 8 Sep 1999 08:53:11 -0400 Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Subject: RE: Bindings, Locks, and MOVE Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3241 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list Copying a resource into a destination collection that is locked requires the principal to own the lock, and provide its lock token in an If header. The resouce inherites the lock of its new parent collection, the lock is not removed from the parent. However, if the resource was locked, then the lock is not copied. The lock state of the new destination resource is determined by its new parent collection, not any lock the source resource might have had. "Yaron Goland (Exchange)" on 09/07/99 08:49:07 PM To: "'Slein, Judith A'" , "'Greg Stein'" , w3c-dist-auth@w3.org cc: Subject: RE: Bindings, Locks, and MOVE Phew!!! I couldn't believe what I was reading regarding write locks. What use is a write lock that only sometimes is a write lock? Yikes. I'm glad that is dead. However there is still a point in the original post that concerns me. Let's see if I understand the proposal: When copying a resource into a tree that is currently locked then the lock on that tree is lost? Is that the proposal for how to handle locks at the destination of a copied resource? That is my reading of the paragraph Judy provided. Yaron > -----Original Message----- > From: Slein, Judith A [mailto:JSlein@crt.xerox.com] > Sent: Tue, September 07, 1999 7:19 AM > To: 'Greg Stein'; w3c-dist-auth@w3.org > Subject: RE: Bindings, Locks, and MOVE > > > Thanks for bringing the discussion back to earth. > > I agree with you that the compromise of saying that servers > SHOULD protect > the path of the Request-URI used in locking a resource is a > poor one. It > doesn't respond to the issue that was raised, and it > needlessly muddies the > waters for clients, which now don't know whether the path > will be protected > or not. > > I like your suggestion that we keep the MUST language, but > state that it > applies only to write locks. > > --Judy > > > > -----Original Message----- > > From: Greg Stein [mailto:gstein@lyra.org] > > Sent: Friday, September 03, 1999 3:24 AM > > To: w3c-dist-auth@w3.org > > Subject: Re: Bindings, Locks, and MOVE > > > > > > This whole thread (post-Judy's message) seems to be picking > out a very > > minor detail of her post. Personally, I find this nit-picking > > of detail > > counter to the goal of her original post: "test its > > conclusions with the > > mailing list members." > > > > For myself (and mod_dav), the first "AGREED" portion makes complete > > sense, and I do agree with it. > > [btw, is *anybody* going to be implementing cross-server > MOVE/COPY? is > > it necessary to have that feature in the spec at all? of the > > umpteen DAV > > servers out there now, I don't know any that do this or plan > > to do this. > > It would be nice to cut the thing and not worry about it.] > > > > The second "AGREED" portion does not make a whole lot of sense. The > > commentary states that the position is too strong [because it > > might not > > make sense with other types of locks]. Are there other locks > > out there? > > Do people have concrete, useful examples? I haven't heard > of anything > > besides a write-lock yet. Regardless, I think it should be > enforced in > > the spec that a write-lock MUST have guaranteed protection of the > > Request-URI. Put in some language that says other locks can > define the > > MUST/SHOULD nature of protection. Otherwise, leave it in > the intuitive > > state: a write lock says that others cannot monkey with your URI. > > > > Cheers, > > -g > > > > Edgar Schwarz wrote: > > > > > > On Thu, 2 Sep 1999, Geoffrey M. Clemm wrote: > > > > > > > From: ccjason@us.ibm.com > > > > > > > > > > > > This discussion began with Yaron's comment that saying > > that "it MUST NOT be > > > > possible for a principal other than the lock owner to > > make a locked resource > > > > inaccessible via the URI mapping used to lock the > > resource" is too strong. > > > > It may make sense for write locks as defined in RFC > > 2518, but may not make > > > > sense for other sorts of locks that don't restrict > > MOVE and DELETE. > > > > > > > > > > > > I believe that this is not specific to any particular > > type of locks. All > > > > clients need to insure that they have at the very > > least a way to unlock > > > > the the locks they have created. I assume that to > > unlock (a resource), we > > > > have to provide a URI of a (the?) resource locked by > > that lock... so if > > > > someone else changes the URI, it's > > > > very likely that we're not going to be able to figure > > out what the new > > > > URI is... and will have to leave the lock around until > > it times out. > > > > > > > > Since the server needs to deal with this in case > > the client just > > > > neglects to remove the lock, and if having another client > > MOVE your > > > > locked resource is a rare occurrence (which I believe > it is), then > > > > this does not seem to be especially problematical. > > > Would it be possible to say: > > > If a locked resource is moved the server SHOULD create > a indirect > > > reference resource which should exist for some sensible time. > > > > > > Yes I know, it's complicating the server :-) > > > I imagine the above happening perhaps when somebody is > reorganizing > > > a directory structure and deep in the collections there are some > > > locked resources. > > > So the lock owner at least has a decent chance to find > out where his > > > resource has gone to. > > > > > > 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. > > > > -- > > Greg Stein, http://www.lyra.org/ > > > From w3c-dist-auth-request@w3.org Wed Sep 8 09:48: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 JAA14122 for ; Wed, 8 Sep 1999 09:48:00 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id JAA08904; Wed, 8 Sep 1999 09:34:25 -0400 (EDT) Resent-Date: Wed, 8 Sep 1999 09:34:25 -0400 (EDT) Resent-Message-Id: <199909081334.JAA08904@www19.w3.org> Message-ID: <8E3CFBC709A8D21191A400805F15E0DBD24433@crte147.wc.eso.mc.xerox.com> From: "Slein, Judith A" To: "'Yaron Goland (Exchange)'" , w3c-dist-auth@w3.org Date: Wed, 8 Sep 1999 09:34:03 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Bindings, Locks, and MOVE Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3242 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 intention is that if a resource is copied or moved into a tree that is locked, the lock on the tree remains in force. We didn't discuss the case where you are doing a MOVE, and the resource being moved is locked, and it is being moved into a collection that is locked. The lock on the collection will certainly stay in force, but we need to decide whether the lock on the resource being MOVEd will be lost or whether the MOVE will fail. I guess my own opinion is that the MOVE should fail, since that maintains a consistent position that the state of a MOVEd resource should be unaffected by the move; if its lock state would have to be changed, the move should fail. Judith A. Slein XR&T/Xerox Architecture Center jslein@crt.xerox.com 8*222-5169 > -----Original Message----- > From: Yaron Goland (Exchange) [mailto:yarong@Exchange.Microsoft.com] > Sent: Tuesday, September 07, 1999 8:49 PM > To: 'Slein, Judith A'; 'Greg Stein'; w3c-dist-auth@w3.org > Subject: RE: Bindings, Locks, and MOVE > > > Phew!!! I couldn't believe what I was reading regarding write > locks. What > use is a write lock that only sometimes is a write lock? > Yikes. I'm glad > that is dead. > > However there is still a point in the original post that > concerns me. Let's > see if I understand the proposal: > > When copying a resource into a tree that is currently locked > then the lock > on that tree is lost? > > Is that the proposal for how to handle locks at the > destination of a copied > resource? That is my reading of the paragraph Judy provided. > > Yaron > > > -----Original Message----- > > From: Slein, Judith A [mailto:JSlein@crt.xerox.com] > > Sent: Tue, September 07, 1999 7:19 AM > > To: 'Greg Stein'; w3c-dist-auth@w3.org > > Subject: RE: Bindings, Locks, and MOVE > > > > > > Thanks for bringing the discussion back to earth. > > > > I agree with you that the compromise of saying that servers > > SHOULD protect > > the path of the Request-URI used in locking a resource is a > > poor one. It > > doesn't respond to the issue that was raised, and it > > needlessly muddies the > > waters for clients, which now don't know whether the path > > will be protected > > or not. > > > > I like your suggestion that we keep the MUST language, but > > state that it > > applies only to write locks. > > > > --Judy > > > > > > > -----Original Message----- > > > From: Greg Stein [mailto:gstein@lyra.org] > > > Sent: Friday, September 03, 1999 3:24 AM > > > To: w3c-dist-auth@w3.org > > > Subject: Re: Bindings, Locks, and MOVE > > > > > > > > > This whole thread (post-Judy's message) seems to be picking > > out a very > > > minor detail of her post. Personally, I find this nit-picking > > > of detail > > > counter to the goal of her original post: "test its > > > conclusions with the > > > mailing list members." > > > > > > For myself (and mod_dav), the first "AGREED" portion > makes complete > > > sense, and I do agree with it. > > > [btw, is *anybody* going to be implementing cross-server > > MOVE/COPY? is > > > it necessary to have that feature in the spec at all? of the > > > umpteen DAV > > > servers out there now, I don't know any that do this or plan > > > to do this. > > > It would be nice to cut the thing and not worry about it.] > > > > > > The second "AGREED" portion does not make a whole lot of > sense. The > > > commentary states that the position is too strong [because it > > > might not > > > make sense with other types of locks]. Are there other locks > > > out there? > > > Do people have concrete, useful examples? I haven't heard > > of anything > > > besides a write-lock yet. Regardless, I think it should be > > enforced in > > > the spec that a write-lock MUST have guaranteed protection of the > > > Request-URI. Put in some language that says other locks can > > define the > > > MUST/SHOULD nature of protection. Otherwise, leave it in > > the intuitive > > > state: a write lock says that others cannot monkey with your URI. > > > > > > Cheers, > > > -g > > > > > > Edgar Schwarz wrote: > > > > > > > > On Thu, 2 Sep 1999, Geoffrey M. Clemm wrote: > > > > > > > > > From: ccjason@us.ibm.com > > > > > > > > > > > > > > > This discussion began with Yaron's comment that saying > > > that "it MUST NOT be > > > > > possible for a principal other than the lock owner to > > > make a locked resource > > > > > inaccessible via the URI mapping used to lock the > > > resource" is too strong. > > > > > It may make sense for write locks as defined in RFC > > > 2518, but may not make > > > > > sense for other sorts of locks that don't restrict > > > MOVE and DELETE. > > > > > > > > > > > > > > > I believe that this is not specific to any particular > > > type of locks. All > > > > > clients need to insure that they have at the very > > > least a way to unlock > > > > > the the locks they have created. I assume that to > > > unlock (a resource), we > > > > > have to provide a URI of a (the?) resource locked by > > > that lock... so if > > > > > someone else changes the URI, it's > > > > > very likely that we're not going to be able to figure > > > out what the new > > > > > URI is... and will have to leave the lock around until > > > it times out. > > > > > > > > > > Since the server needs to deal with this in case > > > the client just > > > > > neglects to remove the lock, and if having another client > > > MOVE your > > > > > locked resource is a rare occurrence (which I believe > > it is), then > > > > > this does not seem to be especially problematical. > > > > Would it be possible to say: > > > > If a locked resource is moved the server SHOULD create > > a indirect > > > > reference resource which should exist for some sensible time. > > > > > > > > Yes I know, it's complicating the server :-) > > > > I imagine the above happening perhaps when somebody is > > reorganizing > > > > a directory structure and deep in the collections there are some > > > > locked resources. > > > > So the lock owner at least has a decent chance to find > > out where his > > > > resource has gone to. > > > > > > > > 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. > > > > > > -- > > > Greg Stein, http://www.lyra.org/ > > > > > > From w3c-dist-auth-request@w3.org Wed Sep 8 09:54: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 JAA14442 for ; Wed, 8 Sep 1999 09:54:05 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id JAA09126; Wed, 8 Sep 1999 09:43:57 -0400 (EDT) Resent-Date: Wed, 8 Sep 1999 09:43:57 -0400 (EDT) Resent-Message-Id: <199909081343.JAA09126@www19.w3.org> Message-ID: <8E3CFBC709A8D21191A400805F15E0DBD24435@crte147.wc.eso.mc.xerox.com> From: "Slein, Judith A" To: "'Yaron Goland (Exchange)'" , "'jamsden@us.ibm.com'" , w3c-dist-auth@w3.org Cc: moore@cs.utk.edu, paf@swip.net Date: Wed, 8 Sep 1999 09:43:35 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Subject: RE: WebDAV Working Group Meeting Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3243 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list > -----Original Message----- > From: Yaron Goland (Exchange) [mailto:yarong@exchange.microsoft.com] > Sent: Tuesday, September 07, 1999 9:11 PM > To: 'jamsden@us.ibm.com'; w3c-dist-auth@w3.org > Cc: moore@cs.utk.edu; paf@swip.net > Subject: RE: WebDAV Working Group Meeting > > > > Either way, unless Keith has changed his mind, as of the end > of this month > WebDAV is closed. There is no more WebDAV, there are no more > meetings. > Keith, what is the status of the WebDAV working group? Will there be a WebDAV meeting at the November IETF? --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 Sep 8 10:10: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 KAA15619 for ; Wed, 8 Sep 1999 10:10:05 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id JAA09638; Wed, 8 Sep 1999 09:59:31 -0400 (EDT) Resent-Date: Wed, 8 Sep 1999 09:59:31 -0400 (EDT) Resent-Message-Id: <199909081359.JAA09638@www19.w3.org> Message-Id: <199909081341.JAA09897@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: "Slein, Judith A" cc: "'Yaron Goland (Exchange)'" , "'jamsden@us.ibm.com'" , w3c-dist-auth@w3.org, moore@cs.utk.edu, paf@swip.net In-reply-to: Your message of "Wed, 08 Sep 1999 09:43:35 EDT." <8E3CFBC709A8D21191A400805F15E0DBD24435@crte147.wc.eso.mc.xerox.com> Date: Wed, 08 Sep 1999 09:41:17 -0400 Subject: Re: WebDAV Working Group Meeting Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3244 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list > Keith, what is the status of the WebDAV working group? currently, it's still active, but I expect it to be winding down. The group can request a meeting if it wants, but it shouldn't take on any new work. Keith From w3c-dist-auth-request@w3.org Wed Sep 8 11:22:54 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 LAA19170 for ; Wed, 8 Sep 1999 11:22:54 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id LAA11884; Wed, 8 Sep 1999 11:12:12 -0400 (EDT) Resent-Date: Wed, 8 Sep 1999 11:12:12 -0400 (EDT) Resent-Message-Id: <199909081512.LAA11884@www19.w3.org> From: jamsden@us.ibm.com X-Lotus-FromDomain: IBMUS To: w3c-dist-auth@w3.org Message-ID: <852567E6.00537D70.00@d54mta03.raleigh.ibm.com> Date: Wed, 8 Sep 1999 11:11:50 -0400 Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Subject: RE: Bindings, Locks, and MOVE Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3245 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 WebDAV spec says that locks are lost on MOVE. So if the source resource is locked, then the MOVE request must include the lock token, and the lock must be owned by the requesting principal. Otherwise the delete portion of the move will fail. Since MOVE is a best effort method, the copy to the destination will work, even if the source can't be deleted. As is the case with COPY, the lock on the destination resource is determined by its new parent collection, not by any lock state it may have had. This could be taken to mean that the new resource is not the same resource moved to a new location, but a different resource. "Slein, Judith A" on 09/08/99 09:34:03 AM To: "'Yaron Goland (Exchange)'" , w3c-dist-auth@w3.org cc: Subject: RE: Bindings, Locks, and MOVE The intention is that if a resource is copied or moved into a tree that is locked, the lock on the tree remains in force. We didn't discuss the case where you are doing a MOVE, and the resource being moved is locked, and it is being moved into a collection that is locked. The lock on the collection will certainly stay in force, but we need to decide whether the lock on the resource being MOVEd will be lost or whether the MOVE will fail. I guess my own opinion is that the MOVE should fail, since that maintains a consistent position that the state of a MOVEd resource should be unaffected by the move; if its lock state would have to be changed, the move should fail. Judith A. Slein XR&T/Xerox Architecture Center jslein@crt.xerox.com 8*222-5169 > -----Original Message----- > From: Yaron Goland (Exchange) [mailto:yarong@Exchange.Microsoft.com] > Sent: Tuesday, September 07, 1999 8:49 PM > To: 'Slein, Judith A'; 'Greg Stein'; w3c-dist-auth@w3.org > Subject: RE: Bindings, Locks, and MOVE > > > Phew!!! I couldn't believe what I was reading regarding write > locks. What > use is a write lock that only sometimes is a write lock? > Yikes. I'm glad > that is dead. > > However there is still a point in the original post that > concerns me. Let's > see if I understand the proposal: > > When copying a resource into a tree that is currently locked > then the lock > on that tree is lost? > > Is that the proposal for how to handle locks at the > destination of a copied > resource? That is my reading of the paragraph Judy provided. > > Yaron > > > -----Original Message----- > > From: Slein, Judith A [mailto:JSlein@crt.xerox.com] > > Sent: Tue, September 07, 1999 7:19 AM > > To: 'Greg Stein'; w3c-dist-auth@w3.org > > Subject: RE: Bindings, Locks, and MOVE > > > > > > Thanks for bringing the discussion back to earth. > > > > I agree with you that the compromise of saying that servers > > SHOULD protect > > the path of the Request-URI used in locking a resource is a > > poor one. It > > doesn't respond to the issue that was raised, and it > > needlessly muddies the > > waters for clients, which now don't know whether the path > > will be protected > > or not. > > > > I like your suggestion that we keep the MUST language, but > > state that it > > applies only to write locks. > > > > --Judy > > > > > > > -----Original Message----- > > > From: Greg Stein [mailto:gstein@lyra.org] > > > Sent: Friday, September 03, 1999 3:24 AM > > > To: w3c-dist-auth@w3.org > > > Subject: Re: Bindings, Locks, and MOVE > > > > > > > > > This whole thread (post-Judy's message) seems to be picking > > out a very > > > minor detail of her post. Personally, I find this nit-picking > > > of detail > > > counter to the goal of her original post: "test its > > > conclusions with the > > > mailing list members." > > > > > > For myself (and mod_dav), the first "AGREED" portion > makes complete > > > sense, and I do agree with it. > > > [btw, is *anybody* going to be implementing cross-server > > MOVE/COPY? is > > > it necessary to have that feature in the spec at all? of the > > > umpteen DAV > > > servers out there now, I don't know any that do this or plan > > > to do this. > > > It would be nice to cut the thing and not worry about it.] > > > > > > The second "AGREED" portion does not make a whole lot of > sense. The > > > commentary states that the position is too strong [because it > > > might not > > > make sense with other types of locks]. Are there other locks > > > out there? > > > Do people have concrete, useful examples? I haven't heard > > of anything > > > besides a write-lock yet. Regardless, I think it should be > > enforced in > > > the spec that a write-lock MUST have guaranteed protection of the > > > Request-URI. Put in some language that says other locks can > > define the > > > MUST/SHOULD nature of protection. Otherwise, leave it in > > the intuitive > > > state: a write lock says that others cannot monkey with your URI. > > > > > > Cheers, > > > -g > > > > > > Edgar Schwarz wrote: > > > > > > > > On Thu, 2 Sep 1999, Geoffrey M. Clemm wrote: > > > > > > > > > From: ccjason@us.ibm.com > > > > > > > > > > > > > > > This discussion began with Yaron's comment that saying > > > that "it MUST NOT be > > > > > possible for a principal other than the lock owner to > > > make a locked resource > > > > > inaccessible via the URI mapping used to lock the > > > resource" is too strong. > > > > > It may make sense for write locks as defined in RFC > > > 2518, but may not make > > > > > sense for other sorts of locks that don't restrict > > > MOVE and DELETE. > > > > > > > > > > > > > > > I believe that this is not specific to any particular > > > type of locks. All > > > > > clients need to insure that they have at the very > > > least a way to unlock > > > > > the the locks they have created. I assume that to > > > unlock (a resource), we > > > > > have to provide a URI of a (the?) resource locked by > > > that lock... so if > > > > > someone else changes the URI, it's > > > > > very likely that we're not going to be able to figure > > > out what the new > > > > > URI is... and will have to leave the lock around until > > > it times out. > > > > > > > > > > Since the server needs to deal with this in case > > > the client just > > > > > neglects to remove the lock, and if having another client > > > MOVE your > > > > > locked resource is a rare occurrence (which I believe > > it is), then > > > > > this does not seem to be especially problematical. > > > > Would it be possible to say: > > > > If a locked resource is moved the server SHOULD create > > a indirect > > > > reference resource which should exist for some sensible time. > > > > > > > > Yes I know, it's complicating the server :-) > > > > I imagine the above happening perhaps when somebody is > > reorganizing > > > > a directory structure and deep in the collections there are some > > > > locked resources. > > > > So the lock owner at least has a decent chance to find > > out where his > > > > resource has gone to. > > > > > > > > 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. > > > > > > -- > > > Greg Stein, http://www.lyra.org/ > > > > > > From w3c-dist-auth-request@w3.org Wed Sep 8 11:38:57 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 LAA19847 for ; Wed, 8 Sep 1999 11:38:56 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id LAA12777; Wed, 8 Sep 1999 11:27:50 -0400 (EDT) Resent-Date: Wed, 8 Sep 1999 11:27:50 -0400 (EDT) Resent-Message-Id: <199909081527.LAA12777@www19.w3.org> X-Authentication-Warning: pentaventures.com: Host nap-pm3-01-13.gulfaccess.net [209.26.59.28] claimed to be brain Message-ID: <002701befa0d$4b132fa0$1711a8c0@brain.pentaventures.com> From: "David Motes" To: Date: Wed, 8 Sep 1999 11:17:39 -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: Need proppatch example Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3246 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, Are there any DAV clients that do a proppatch? I have been looking for an example of a proppatch in action. Thanks, -David From w3c-dist-auth-request@w3.org Wed Sep 8 11:49: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 LAA20245 for ; Wed, 8 Sep 1999 11:49:51 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id LAA13198; Wed, 8 Sep 1999 11:39:09 -0400 (EDT) Resent-Date: Wed, 8 Sep 1999 11:39:09 -0400 (EDT) Resent-Message-Id: <199909081539.LAA13198@www19.w3.org> Message-ID: <37D682EF.F7DBBF30@ecal.com> Date: Wed, 08 Sep 1999 11:38:23 -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: <002701befa0d$4b132fa0$1711a8c0@brain.pentaventures.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: Need proppatch example Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3247 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 David Motes wrote: > I have been looking for an example of a proppatch > in action. Sanity check: have you seen the PROPPATCH example in the RFC? -- /============================================================\ |John Stracke |http://www.ecal.com|My opinions are my own.| |Chief Scientist |===========================================| |eCal Corp. |Stock up and save! Limit one. | |francis@ecal.com| | \============================================================/ From w3c-dist-auth-request@w3.org Wed Sep 8 11:58: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 LAA20575 for ; Wed, 8 Sep 1999 11:58:07 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id LAA13398; Wed, 8 Sep 1999 11:47:06 -0400 (EDT) Resent-Date: Wed, 8 Sep 1999 11:47:06 -0400 (EDT) Resent-Message-Id: <199909081547.LAA13398@www19.w3.org> Message-ID: <8E3CFBC709A8D21191A400805F15E0DBD24436@crte147.wc.eso.mc.xerox.com> From: "Slein, Judith A" To: "'jamsden@us.ibm.com'" , w3c-dist-auth@w3.org Date: Wed, 8 Sep 1999 11:46:48 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Bindings, Locks, and MOVE Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3248 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 I noted in the message that started this thread, our proposal contradicts what RFC 2518 says about preserving locks on a MOVE. We would like to see the WebDAV spec changed when it goes to draft status to say that locks are *not* lost on a MOVE. Judith A. Slein XR&T/Xerox Architecture Center jslein@crt.xerox.com 8*222-5169 > -----Original Message----- > From: jamsden@us.ibm.com [mailto:jamsden@us.ibm.com] > Sent: Wednesday, September 08, 1999 11:12 AM > To: w3c-dist-auth@w3.org > Subject: RE: Bindings, Locks, and MOVE > > > > > The WebDAV spec says that locks are lost on MOVE. So if the > source resource is > locked, then the MOVE request must include the lock token, > and the lock must be > owned by the requesting principal. Otherwise the delete > portion of the move will > fail. Since MOVE is a best effort method, the copy to the > destination will work, > even if the source can't be deleted. As is the case with > COPY, the lock on the > destination resource is determined by its new parent > collection, not by any lock > state it may have had. This could be taken to mean that the > new resource is not > the same resource moved to a new location, but a different resource. > > > > > > "Slein, Judith A" on 09/08/99 09:34:03 AM > > To: "'Yaron Goland (Exchange)'" , > w3c-dist-auth@w3.org > cc: > > Subject: RE: Bindings, Locks, and MOVE > > > > > The intention is that if a resource is copied or moved into a > tree that is > locked, the lock on the tree remains in force. > > We didn't discuss the case where you are doing a MOVE, and > the resource > being moved is locked, and it is being moved into a collection that is > locked. The lock on the collection will certainly stay in > force, but we > need to decide whether the lock on the resource being MOVEd > will be lost or > whether the MOVE will fail. I guess my own opinion is that > the MOVE should > fail, since that maintains a consistent position that the > state of a MOVEd > resource should be unaffected by the move; if its lock state > would have to > be changed, the move should fail. > > Judith A. Slein > XR&T/Xerox Architecture Center > jslein@crt.xerox.com > 8*222-5169 > > > > -----Original Message----- > > From: Yaron Goland (Exchange) [mailto:yarong@Exchange.Microsoft.com] > > Sent: Tuesday, September 07, 1999 8:49 PM > > To: 'Slein, Judith A'; 'Greg Stein'; w3c-dist-auth@w3.org > > Subject: RE: Bindings, Locks, and MOVE > > > > > > Phew!!! I couldn't believe what I was reading regarding write > > locks. What > > use is a write lock that only sometimes is a write lock? > > Yikes. I'm glad > > that is dead. > > > > However there is still a point in the original post that > > concerns me. Let's > > see if I understand the proposal: > > > > When copying a resource into a tree that is currently locked > > then the lock > > on that tree is lost? > > > > Is that the proposal for how to handle locks at the > > destination of a copied > > resource? That is my reading of the paragraph Judy provided. > > > > Yaron > > > > > -----Original Message----- > > > From: Slein, Judith A [mailto:JSlein@crt.xerox.com] > > > Sent: Tue, September 07, 1999 7:19 AM > > > To: 'Greg Stein'; w3c-dist-auth@w3.org > > > Subject: RE: Bindings, Locks, and MOVE > > > > > > > > > Thanks for bringing the discussion back to earth. > > > > > > I agree with you that the compromise of saying that servers > > > SHOULD protect > > > the path of the Request-URI used in locking a resource is a > > > poor one. It > > > doesn't respond to the issue that was raised, and it > > > needlessly muddies the > > > waters for clients, which now don't know whether the path > > > will be protected > > > or not. > > > > > > I like your suggestion that we keep the MUST language, but > > > state that it > > > applies only to write locks. > > > > > > --Judy > > > > > > > > > > -----Original Message----- > > > > From: Greg Stein [mailto:gstein@lyra.org] > > > > Sent: Friday, September 03, 1999 3:24 AM > > > > To: w3c-dist-auth@w3.org > > > > Subject: Re: Bindings, Locks, and MOVE > > > > > > > > > > > > This whole thread (post-Judy's message) seems to be picking > > > out a very > > > > minor detail of her post. Personally, I find this nit-picking > > > > of detail > > > > counter to the goal of her original post: "test its > > > > conclusions with the > > > > mailing list members." > > > > > > > > For myself (and mod_dav), the first "AGREED" portion > > makes complete > > > > sense, and I do agree with it. > > > > [btw, is *anybody* going to be implementing cross-server > > > MOVE/COPY? is > > > > it necessary to have that feature in the spec at all? of the > > > > umpteen DAV > > > > servers out there now, I don't know any that do this or plan > > > > to do this. > > > > It would be nice to cut the thing and not worry about it.] > > > > > > > > The second "AGREED" portion does not make a whole lot of > > sense. The > > > > commentary states that the position is too strong [because it > > > > might not > > > > make sense with other types of locks]. Are there other locks > > > > out there? > > > > Do people have concrete, useful examples? I haven't heard > > > of anything > > > > besides a write-lock yet. Regardless, I think it should be > > > enforced in > > > > the spec that a write-lock MUST have guaranteed > protection of the > > > > Request-URI. Put in some language that says other locks can > > > define the > > > > MUST/SHOULD nature of protection. Otherwise, leave it in > > > the intuitive > > > > state: a write lock says that others cannot monkey with > your URI. > > > > > > > > Cheers, > > > > -g > > > > > > > > Edgar Schwarz wrote: > > > > > > > > > > On Thu, 2 Sep 1999, Geoffrey M. Clemm wrote: > > > > > > > > > > > From: ccjason@us.ibm.com > > > > > > > > > > > > > > > > > > This discussion began with Yaron's comment that saying > > > > that "it MUST NOT be > > > > > > possible for a principal other than the lock owner to > > > > make a locked resource > > > > > > inaccessible via the URI mapping used to lock the > > > > resource" is too strong. > > > > > > It may make sense for write locks as defined in RFC > > > > 2518, but may not make > > > > > > sense for other sorts of locks that don't restrict > > > > MOVE and DELETE. > > > > > > > > > > > > > > > > > > I believe that this is not specific to any particular > > > > type of locks. All > > > > > > clients need to insure that they have at the very > > > > least a way to unlock > > > > > > the the locks they have created. I assume that to > > > > unlock (a resource), we > > > > > > have to provide a URI of a (the?) resource locked by > > > > that lock... so if > > > > > > someone else changes the URI, it's > > > > > > very likely that we're not going to be able to figure > > > > out what the new > > > > > > URI is... and will have to leave the lock around until > > > > it times out. > > > > > > > > > > > > Since the server needs to deal with this in case > > > > the client just > > > > > > neglects to remove the lock, and if having another client > > > > MOVE your > > > > > > locked resource is a rare occurrence (which I believe > > > it is), then > > > > > > this does not seem to be especially problematical. > > > > > Would it be possible to say: > > > > > If a locked resource is moved the server SHOULD create > > > a indirect > > > > > reference resource which should exist for some > sensible time. > > > > > > > > > > Yes I know, it's complicating the server :-) > > > > > I imagine the above happening perhaps when somebody is > > > reorganizing > > > > > a directory structure and deep in the collections > there are some > > > > > locked resources. > > > > > So the lock owner at least has a decent chance to find > > > out where his > > > > > resource has gone to. > > > > > > > > > > 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. > > > > > > > > -- > > > > Greg Stein, http://www.lyra.org/ > > > > > > > > > > > > > > From w3c-dist-auth-request@w3.org Wed Sep 8 13:27: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 NAA23444 for ; Wed, 8 Sep 1999 13:27:27 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id NAA15333; Wed, 8 Sep 1999 13:17:11 -0400 (EDT) Resent-Date: Wed, 8 Sep 1999 13:17:11 -0400 (EDT) Resent-Message-Id: <199909081717.NAA15333@www19.w3.org> Message-ID: From: Ray Patch To: w3c-dist-auth@w3.org Date: Wed, 8 Sep 1999 10:15:57 -0700 X-Mailer: Internet Mail Service (5.5.2448.0) Subject: RE: Bindings, Locks, and MOVE Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3249 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list How do I get removed from this DL? Thanks, Ray Patch Raypa@microsoft.com -----Original Message----- From: John Stracke [mailto:francis@ecal.com] Sent: Friday, September 03, 1999 8:00 AM To: w3c-dist-auth@w3.org Subject: Re: Bindings, Locks, and MOVE jamsden@us.ibm.com wrote: > Proposed extensions to PROPPATCH: > > 1. Extend the DAV:set and DAV:remove elements to include information describing > how the client wishes to handle errors. The DTD additions would be: I like this idea; I just have a syntactic quibble: > > > If an updatebehavior is not included, it is equivalent to specifying > * It might be better if, rather than using "*", you defined an element meaning the same thing. For now, "*" is simple enough; but, if we add more wildcards eventually, then it gets messier; we'd have to add more possible values, which starts getting into defining a separate syntax, with a separate parser. Simpler to use XML tags and let the existing parser handle it. -- /============================================================\ |John Stracke |http://www.ecal.com|My opinions are my own.| |Chief Scientist |===========================================| |eCal Corp. |Campbell's has it wrong--it's "Never | |francis@ecal.com|underestimate the power of *chocolate*". | \============================================================/ From w3c-dist-auth-request@w3.org Wed Sep 8 15:40: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 PAA28157 for ; Wed, 8 Sep 1999 15:40:18 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id PAA17628; Wed, 8 Sep 1999 15:28:37 -0400 (EDT) Resent-Date: Wed, 8 Sep 1999 15:28:37 -0400 (EDT) Resent-Message-Id: <199909081928.PAA17628@www19.w3.org> Message-ID: <37D6B67F.B5C7024@lyra.org> Date: Wed, 08 Sep 1999 12:18:23 -0700 From: Greg Stein X-Mailer: Mozilla 3.01 (X11; I; Linux 2.0.28 i586) MIME-Version: 1.0 To: David Motes CC: w3c-dist-auth@w3.org References: <002701befa0d$4b132fa0$1711a8c0@brain.pentaventures.com> <37D682EF.F7DBBF30@ecal.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: Need proppatch example Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3250 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 John Stracke wrote: > > David Motes wrote: > > > I have been looking for an example of a proppatch > > in action. > > Sanity check: have you seen the PROPPATCH example in the RFC? If you know Python, then you can also grab my davlib.py and httplib.py (via links at www.webdav.org/mod_dav/). Using that, you can generate a PROPPATCH to your server. Cheers, -g -- Greg Stein, http://www.lyra.org/ From w3c-dist-auth-request@w3.org Wed Sep 8 16:17: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 QAA29582 for ; Wed, 8 Sep 1999 16:17:18 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id QAA18413; Wed, 8 Sep 1999 16:05:43 -0400 (EDT) Resent-Date: Wed, 8 Sep 1999 16:05:43 -0400 (EDT) Resent-Message-Id: <199909082005.QAA18413@www19.w3.org> Message-ID: <078292D50C98D2118D090008C7E9C6A603C965A7@STAY.platinum.corp.microsoft.com> From: "Yaron Goland (Exchange)" To: "'Slein, Judith A'" , "'jamsden@us.ibm.com'" , w3c-dist-auth@w3.org Date: Wed, 8 Sep 1999 13:05:11 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Bindings, Locks, and MOVE Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3251 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 reason that locks are lost on MOVEs is that the overwhelming majority of existing systems can not handle moving locks on MOVEs. We could, of course, have said locks SHOULD NOT be lost on moves. But this sort of language is exactly the type of language the destroys interoperability. When I write a client I am going to write it to either demand that locks move properly on moves in the average case (with exceptions handled as force 10 failures) or I'm going to write it to assume that locks never work on MOVE and set up my UI and APIs appropriately. their UI and internal code in order to compensate. We will be consistent. We will be uniform. We will use "MUST." If you want to change the language to say that locks MUST move then we can discuss this, although I think preventing the majority of existing systems in the world from supporting WebDAV is probably a bad idea. If you want to use the Mandatory mechanism, I think that would be a great idea. But the requirement absolutely will not be a SHOULD. Yaron P.S. Phew... I haven't had a good rant in a while. Feels good. =) > -----Original Message----- > From: Slein, Judith A [mailto:JSlein@crt.xerox.com] > Sent: Wednesday, September 08, 1999 8:47 AM > To: 'jamsden@us.ibm.com'; w3c-dist-auth@w3.org > Subject: RE: Bindings, Locks, and MOVE > > > As I noted in the message that started this thread, our > proposal contradicts > what RFC 2518 says about preserving locks on a MOVE. We > would like to see > the WebDAV spec changed when it goes to draft status to say > that locks are > *not* lost on a MOVE. > > Judith A. Slein > XR&T/Xerox Architecture Center > jslein@crt.xerox.com > 8*222-5169 > > > > -----Original Message----- > > From: jamsden@us.ibm.com [mailto:jamsden@us.ibm.com] > > Sent: Wednesday, September 08, 1999 11:12 AM > > To: w3c-dist-auth@w3.org > > Subject: RE: Bindings, Locks, and MOVE > > > > > > > > > > The WebDAV spec says that locks are lost on MOVE. So if the > > source resource is > > locked, then the MOVE request must include the lock token, > > and the lock must be > > owned by the requesting principal. Otherwise the delete > > portion of the move will > > fail. Since MOVE is a best effort method, the copy to the > > destination will work, > > even if the source can't be deleted. As is the case with > > COPY, the lock on the > > destination resource is determined by its new parent > > collection, not by any lock > > state it may have had. This could be taken to mean that the > > new resource is not > > the same resource moved to a new location, but a different resource. > > > > > > > > > > > > "Slein, Judith A" on 09/08/99 09:34:03 AM > > > > To: "'Yaron Goland (Exchange)'" , > > w3c-dist-auth@w3.org > > cc: > > > > Subject: RE: Bindings, Locks, and MOVE > > > > > > > > > > The intention is that if a resource is copied or moved into a > > tree that is > > locked, the lock on the tree remains in force. > > > > We didn't discuss the case where you are doing a MOVE, and > > the resource > > being moved is locked, and it is being moved into a > collection that is > > locked. The lock on the collection will certainly stay in > > force, but we > > need to decide whether the lock on the resource being MOVEd > > will be lost or > > whether the MOVE will fail. I guess my own opinion is that > > the MOVE should > > fail, since that maintains a consistent position that the > > state of a MOVEd > > resource should be unaffected by the move; if its lock state > > would have to > > be changed, the move should fail. > > > > Judith A. Slein > > XR&T/Xerox Architecture Center > > jslein@crt.xerox.com > > 8*222-5169 > > > > > > > -----Original Message----- > > > From: Yaron Goland (Exchange) > [mailto:yarong@Exchange.Microsoft.com] > > > Sent: Tuesday, September 07, 1999 8:49 PM > > > To: 'Slein, Judith A'; 'Greg Stein'; w3c-dist-auth@w3.org > > > Subject: RE: Bindings, Locks, and MOVE > > > > > > > > > Phew!!! I couldn't believe what I was reading regarding write > > > locks. What > > > use is a write lock that only sometimes is a write lock? > > > Yikes. I'm glad > > > that is dead. > > > > > > However there is still a point in the original post that > > > concerns me. Let's > > > see if I understand the proposal: > > > > > > When copying a resource into a tree that is currently locked > > > then the lock > > > on that tree is lost? > > > > > > Is that the proposal for how to handle locks at the > > > destination of a copied > > > resource? That is my reading of the paragraph Judy provided. > > > > > > Yaron > > > > > > > -----Original Message----- > > > > From: Slein, Judith A [mailto:JSlein@crt.xerox.com] > > > > Sent: Tue, September 07, 1999 7:19 AM > > > > To: 'Greg Stein'; w3c-dist-auth@w3.org > > > > Subject: RE: Bindings, Locks, and MOVE > > > > > > > > > > > > Thanks for bringing the discussion back to earth. > > > > > > > > I agree with you that the compromise of saying that servers > > > > SHOULD protect > > > > the path of the Request-URI used in locking a resource is a > > > > poor one. It > > > > doesn't respond to the issue that was raised, and it > > > > needlessly muddies the > > > > waters for clients, which now don't know whether the path > > > > will be protected > > > > or not. > > > > > > > > I like your suggestion that we keep the MUST language, but > > > > state that it > > > > applies only to write locks. > > > > > > > > --Judy > > > > > > > > > > > > > -----Original Message----- > > > > > From: Greg Stein [mailto:gstein@lyra.org] > > > > > Sent: Friday, September 03, 1999 3:24 AM > > > > > To: w3c-dist-auth@w3.org > > > > > Subject: Re: Bindings, Locks, and MOVE > > > > > > > > > > > > > > > This whole thread (post-Judy's message) seems to be picking > > > > out a very > > > > > minor detail of her post. Personally, I find this nit-picking > > > > > of detail > > > > > counter to the goal of her original post: "test its > > > > > conclusions with the > > > > > mailing list members." > > > > > > > > > > For myself (and mod_dav), the first "AGREED" portion > > > makes complete > > > > > sense, and I do agree with it. > > > > > [btw, is *anybody* going to be implementing cross-server > > > > MOVE/COPY? is > > > > > it necessary to have that feature in the spec at all? of the > > > > > umpteen DAV > > > > > servers out there now, I don't know any that do this or plan > > > > > to do this. > > > > > It would be nice to cut the thing and not worry about it.] > > > > > > > > > > The second "AGREED" portion does not make a whole lot of > > > sense. The > > > > > commentary states that the position is too strong [because it > > > > > might not > > > > > make sense with other types of locks]. Are there other locks > > > > > out there? > > > > > Do people have concrete, useful examples? I haven't heard > > > > of anything > > > > > besides a write-lock yet. Regardless, I think it should be > > > > enforced in > > > > > the spec that a write-lock MUST have guaranteed > > protection of the > > > > > Request-URI. Put in some language that says other locks can > > > > define the > > > > > MUST/SHOULD nature of protection. Otherwise, leave it in > > > > the intuitive > > > > > state: a write lock says that others cannot monkey with > > your URI. > > > > > > > > > > Cheers, > > > > > -g > > > > > > > > > > Edgar Schwarz wrote: > > > > > > > > > > > > On Thu, 2 Sep 1999, Geoffrey M. Clemm wrote: > > > > > > > > > > > > > From: ccjason@us.ibm.com > > > > > > > > > > > > > > > > > > > > > This discussion began with Yaron's comment that saying > > > > > that "it MUST NOT be > > > > > > > possible for a principal other than the lock owner to > > > > > make a locked resource > > > > > > > inaccessible via the URI mapping used to lock the > > > > > resource" is too strong. > > > > > > > It may make sense for write locks as defined in RFC > > > > > 2518, but may not make > > > > > > > sense for other sorts of locks that don't restrict > > > > > MOVE and DELETE. > > > > > > > > > > > > > > > > > > > > > I believe that this is not specific to any particular > > > > > type of locks. All > > > > > > > clients need to insure that they have at the very > > > > > least a way to unlock > > > > > > > the the locks they have created. I assume that to > > > > > unlock (a resource), we > > > > > > > have to provide a URI of a (the?) resource locked by > > > > > that lock... so if > > > > > > > someone else changes the URI, it's > > > > > > > very likely that we're not going to be able to figure > > > > > out what the new > > > > > > > URI is... and will have to leave the lock around until > > > > > it times out. > > > > > > > > > > > > > > Since the server needs to deal with this in case > > > > > the client just > > > > > > > neglects to remove the lock, and if having another client > > > > > MOVE your > > > > > > > locked resource is a rare occurrence (which I believe > > > > it is), then > > > > > > > this does not seem to be especially problematical. > > > > > > Would it be possible to say: > > > > > > If a locked resource is moved the server SHOULD create > > > > a indirect > > > > > > reference resource which should exist for some > > sensible time. > > > > > > > > > > > > Yes I know, it's complicating the server :-) > > > > > > I imagine the above happening perhaps when somebody is > > > > reorganizing > > > > > > a directory structure and deep in the collections > > there are some > > > > > > locked resources. > > > > > > So the lock owner at least has a decent chance to find > > > > out where his > > > > > > resource has gone to. > > > > > > > > > > > > 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. > > > > > > > > > > -- > > > > > Greg Stein, http://www.lyra.org/ > > > > > > > > > > > > > > > > > > > > > > > From w3c-dist-auth-request@w3.org Wed Sep 8 16:17: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 QAA29593 for ; Wed, 8 Sep 1999 16:17:32 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id QAA18461; Wed, 8 Sep 1999 16:06:00 -0400 (EDT) Resent-Date: Wed, 8 Sep 1999 16:06:00 -0400 (EDT) Resent-Message-Id: <199909082006.QAA18461@www19.w3.org> Message-ID: <078292D50C98D2118D090008C7E9C6A603C965A8@STAY.platinum.corp.microsoft.com> From: "Yaron Goland (Exchange)" To: "'jamsden@us.ibm.com'" , w3c-dist-auth@w3.org Date: Wed, 8 Sep 1999 13:05:25 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Bindings, Locks, and MOVE Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3252 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list Music to my ears. > -----Original Message----- > From: jamsden@us.ibm.com [mailto:jamsden@us.ibm.com] > Sent: Wednesday, September 08, 1999 5:53 AM > To: w3c-dist-auth@w3.org > Subject: RE: Bindings, Locks, and MOVE > > > > > Copying a resource into a destination collection that is > locked requires the > principal to own the lock, and provide its lock token in an > If header. The > resouce inherites the lock of its new parent collection, the > lock is not removed > from the parent. However, if the resource was locked, then > the lock is not > copied. The lock state of the new destination resource is > determined by its new > parent collection, not any lock the source resource might have had. > > > > > > "Yaron Goland (Exchange)" on > 09/07/99 08:49:07 > PM > > To: "'Slein, Judith A'" , "'Greg Stein'" > , w3c-dist-auth@w3.org > cc: > > Subject: RE: Bindings, Locks, and MOVE > > > > > Phew!!! I couldn't believe what I was reading regarding write > locks. What > use is a write lock that only sometimes is a write lock? > Yikes. I'm glad > that is dead. > > However there is still a point in the original post that > concerns me. Let's > see if I understand the proposal: > > When copying a resource into a tree that is currently locked > then the lock > on that tree is lost? > > Is that the proposal for how to handle locks at the > destination of a copied > resource? That is my reading of the paragraph Judy provided. > > Yaron > > > -----Original Message----- > > From: Slein, Judith A [mailto:JSlein@crt.xerox.com] > > Sent: Tue, September 07, 1999 7:19 AM > > To: 'Greg Stein'; w3c-dist-auth@w3.org > > Subject: RE: Bindings, Locks, and MOVE > > > > > > Thanks for bringing the discussion back to earth. > > > > I agree with you that the compromise of saying that servers > > SHOULD protect > > the path of the Request-URI used in locking a resource is a > > poor one. It > > doesn't respond to the issue that was raised, and it > > needlessly muddies the > > waters for clients, which now don't know whether the path > > will be protected > > or not. > > > > I like your suggestion that we keep the MUST language, but > > state that it > > applies only to write locks. > > > > --Judy > > > > > > > -----Original Message----- > > > From: Greg Stein [mailto:gstein@lyra.org] > > > Sent: Friday, September 03, 1999 3:24 AM > > > To: w3c-dist-auth@w3.org > > > Subject: Re: Bindings, Locks, and MOVE > > > > > > > > > This whole thread (post-Judy's message) seems to be picking > > out a very > > > minor detail of her post. Personally, I find this nit-picking > > > of detail > > > counter to the goal of her original post: "test its > > > conclusions with the > > > mailing list members." > > > > > > For myself (and mod_dav), the first "AGREED" portion > makes complete > > > sense, and I do agree with it. > > > [btw, is *anybody* going to be implementing cross-server > > MOVE/COPY? is > > > it necessary to have that feature in the spec at all? of the > > > umpteen DAV > > > servers out there now, I don't know any that do this or plan > > > to do this. > > > It would be nice to cut the thing and not worry about it.] > > > > > > The second "AGREED" portion does not make a whole lot of > sense. The > > > commentary states that the position is too strong [because it > > > might not > > > make sense with other types of locks]. Are there other locks > > > out there? > > > Do people have concrete, useful examples? I haven't heard > > of anything > > > besides a write-lock yet. Regardless, I think it should be > > enforced in > > > the spec that a write-lock MUST have guaranteed protection of the > > > Request-URI. Put in some language that says other locks can > > define the > > > MUST/SHOULD nature of protection. Otherwise, leave it in > > the intuitive > > > state: a write lock says that others cannot monkey with your URI. > > > > > > Cheers, > > > -g > > > > > > Edgar Schwarz wrote: > > > > > > > > On Thu, 2 Sep 1999, Geoffrey M. Clemm wrote: > > > > > > > > > From: ccjason@us.ibm.com > > > > > > > > > > > > > > > This discussion began with Yaron's comment that saying > > > that "it MUST NOT be > > > > > possible for a principal other than the lock owner to > > > make a locked resource > > > > > inaccessible via the URI mapping used to lock the > > > resource" is too strong. > > > > > It may make sense for write locks as defined in RFC > > > 2518, but may not make > > > > > sense for other sorts of locks that don't restrict > > > MOVE and DELETE. > > > > > > > > > > > > > > > I believe that this is not specific to any particular > > > type of locks. All > > > > > clients need to insure that they have at the very > > > least a way to unlock > > > > > the the locks they have created. I assume that to > > > unlock (a resource), we > > > > > have to provide a URI of a (the?) resource locked by > > > that lock... so if > > > > > someone else changes the URI, it's > > > > > very likely that we're not going to be able to figure > > > out what the new > > > > > URI is... and will have to leave the lock around until > > > it times out. > > > > > > > > > > Since the server needs to deal with this in case > > > the client just > > > > > neglects to remove the lock, and if having another client > > > MOVE your > > > > > locked resource is a rare occurrence (which I believe > > it is), then > > > > > this does not seem to be especially problematical. > > > > Would it be possible to say: > > > > If a locked resource is moved the server SHOULD create > > a indirect > > > > reference resource which should exist for some sensible time. > > > > > > > > Yes I know, it's complicating the server :-) > > > > I imagine the above happening perhaps when somebody is > > reorganizing > > > > a directory structure and deep in the collections there are some > > > > locked resources. > > > > So the lock owner at least has a decent chance to find > > out where his > > > > resource has gone to. > > > > > > > > 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. > > > > > > -- > > > Greg Stein, http://www.lyra.org/ > > > > > > > > > From w3c-dist-auth-request@w3.org Wed Sep 8 16:28: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 QAA00009 for ; Wed, 8 Sep 1999 16:28:02 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id QAA18920; Wed, 8 Sep 1999 16:17:41 -0400 (EDT) Resent-Date: Wed, 8 Sep 1999 16:17:41 -0400 (EDT) Resent-Message-Id: <199909082017.QAA18920@www19.w3.org> Message-ID: <37D6C223.1FDAB5F1@lyra.org> Date: Wed, 08 Sep 1999 13:08:03 -0700 From: Greg Stein X-Mailer: Mozilla 3.01 (X11; I; Linux 2.0.28 i586) MIME-Version: 1.0 To: "Slein, Judith A" CC: w3c-dist-auth@w3.org References: <8E3CFBC709A8D21191A400805F15E0DBD24433@crte147.wc.eso.mc.xerox.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: Bindings, Locks, and MOVE Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3253 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: > > The intention is that if a resource is copied or moved into a tree that is > locked, the lock on the tree remains in force. > > We didn't discuss the case where you are doing a MOVE, and the resource > being moved is locked, and it is being moved into a collection that is > locked. The lock on the collection will certainly stay in force, but we > need to decide whether the lock on the resource being MOVEd will be lost or > whether the MOVE will fail. I guess my own opinion is that the MOVE should > fail, since that maintains a consistent position that the state of a MOVEd > resource should be unaffected by the move; if its lock state would have to > be changed, the move should fail. There is a third case: allow the move. How about this: allow the MOVE, the resource then falls under the Destination lock, the source is now in a lock-null state. Therefore, the user does *not* lose any locks, the MOVE is completed, and this scenario actually provides a way to do a "safe" MOVE. If the user could not lock both ends, then you have a race condition. Further, making the user lock the source "one level up" so that the lock wouldn't move with the resource just feels like a hack. If you are MOVEing a collection and there is a lock on one of the collection members, then the move should fail if there is an incompatible lock (e.g. exclusive and not the same lock) at the destination. Cheers, -g -- Greg Stein, http://www.lyra.org/ From w3c-dist-auth-request@w3.org Wed Sep 8 16:31: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 QAA00259 for ; Wed, 8 Sep 1999 16:31:24 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id QAA19029; Wed, 8 Sep 1999 16:20:25 -0400 (EDT) Resent-Date: Wed, 8 Sep 1999 16:20:25 -0400 (EDT) Resent-Message-Id: <199909082020.QAA19029@www19.w3.org> Message-ID: <37D6C2D6.25989FEF@lyra.org> Date: Wed, 08 Sep 1999 13:11:02 -0700 From: Greg Stein X-Mailer: Mozilla 3.01 (X11; I; Linux 2.0.28 i586) MIME-Version: 1.0 To: Keith Moore CC: w3c-dist-auth@w3.org, paf@swip.net References: <199909081341.JAA09897@astro.cs.utk.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: WebDAV Working Group Meeting Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3254 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 Keith Moore wrote: > > > Keith, what is the status of the WebDAV working group? > > currently, it's still active, but I expect it to be winding down. > The group can request a meeting if it wants, but it shouldn't > take on any new work. Actually, I'm somewhat amazed as the desire to blow away this working group. It is still performing a lot of work with the WebDAV extensions. If this list goes away, then what? Where does all this discussion go then? I find it silly to shut something down simply because some rule somewhere says it needs to be shut down. Leave it open until the work is done. If you must shut it down, then we must have a "DAV Extensions WG" to take its place. [this is the heart of the silliness -- renaming something just to satisfy some rules] Cheers, -g -- Greg Stein, http://www.lyra.org/ From w3c-dist-auth-request@w3.org Wed Sep 8 17:12: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 RAA01618 for ; Wed, 8 Sep 1999 17:12:35 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id RAA20184; Wed, 8 Sep 1999 17:00:26 -0400 (EDT) Resent-Date: Wed, 8 Sep 1999 17:00:26 -0400 (EDT) Resent-Message-Id: <199909082100.RAA20184@www19.w3.org> Message-Id: <199909082055.QAA11150@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Greg Stein cc: Keith Moore , w3c-dist-auth@w3.org, paf@swip.net In-reply-to: Your message of "Wed, 08 Sep 1999 13:11:02 PDT." <37D6C2D6.25989FEF@lyra.org> Date: Wed, 08 Sep 1999 16:55:01 -0400 Subject: Re: WebDAV Working Group Meeting Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3255 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list > Actually, I'm somewhat amazed as the desire to blow away this working > group. It is still performing a lot of work with the WebDAV extensions. > If this list goes away, then what? Where does all this discussion go > then? Many years of experience with IETF working groups indicates that, in general, they start to become ineffective after 18 months or so. There are a variety of reasons for this, but in general we have found that such groups are likely to either bog down, or go off into the weeds doing things which are very different from their charters, and often, at cross-purposes with other groups. Furthermore many members of the group will be burned out by this time (e.g. they are tired of revisiting the same issues over and over, or their employer is no longer as supportive of the work), which means that any purported consensus of the group has to be viewed with suspicion. So after about 18 months we start looking for a way to gracefully close down the group. Often it takes much longer than that, because we don't want to be more disruptive than necessary. If more work remains to be done, we can always create a new group. This gives us a chance both to refocus on the new work at hand and also to recruit new participants. Working group mailing lists are rarely shut down even after the group is closed; a WG mailing list typically remains active for as long as someone is willing to maintain it. Such lists are often consulted by IESG, e.g. when their expertise is needed to review a draft document. Keith p.s. This isn't a hard-and-fast rule - we made an exception for HTTP - it's an administrative decision which has been made by the area director. From w3c-dist-auth-request@w3.org Wed Sep 8 17:14: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 RAA01633 for ; Wed, 8 Sep 1999 17:14:36 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id RAA20339; Wed, 8 Sep 1999 17:03:58 -0400 (EDT) Resent-Date: Wed, 8 Sep 1999 17:03:58 -0400 (EDT) Resent-Message-Id: <199909082103.RAA20339@www19.w3.org> From: "Jeffrey A. Stuart" To: Date: Wed, 8 Sep 1999 16:53:06 -0400 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: <199909080123.VAA23508@astro.cs.utk.edu> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Subject: Delta-V WG/Mailing List Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3256 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 As the WG for WebDAV is going to be closed soon, will this list still exist to discuss the Delta-V work and other extensions of DAV? While I am only a lurker right now, I do have an interest in WebDAV, Delta-V work and other extensions of WebDAV. I hope to soon be implementing a package based on WebDAV and am very interested in following the protocol as it moves closer to a standard. If not, are there any plans to create a new mailing list for Delta-V and the other extensions of WebDAV? -- Jeff Stuart DevilCat@bigfoot.com PGP Key ID: 0xE8A76C8A Get it from certserver.pgp.com. PGP Fingerprint: FBB0 CE1F D159 116A 34CA 77FB 6CCB 04A4 E8A7 6C8A -----Original Message----- From: w3c-dist-auth-request@w3.org [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Keith Moore Sent: Tuesday, September 07, 1999 9:24 PM To: Yaron Goland (Exchange) Cc: 'jamsden@us.ibm.com'; w3c-dist-auth@w3.org; moore@cs.utk.edu; paf@swip.net Subject: Re: WebDAV Working Group Meeting > In fact, by > the next IETF Delta-V should be a WG (Keith?). chances are good. the charter is currently being discussed by iesg and iab. Keith From w3c-dist-auth-request@w3.org Wed Sep 8 20:42: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 UAA04318 for ; Wed, 8 Sep 1999 20:42:41 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id UAA25184; Wed, 8 Sep 1999 20:23:02 -0400 (EDT) Resent-Date: Wed, 8 Sep 1999 20:23:02 -0400 (EDT) Resent-Message-Id: <199909090023.UAA25184@www19.w3.org> Message-ID: <078292D50C98D2118D090008C7E9C6A603C965AD@STAY.platinum.corp.microsoft.com> From: "Yaron Goland (Exchange)" To: "'Jeffrey A. Stuart'" , w3c-dist-auth@w3.org Date: Wed, 8 Sep 1999 17:22:32 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Delta-V WG/Mailing List Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3257 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list My understanding is that the W3C will continue to operate this list for as long as anyone is interested in it. If that proves not to be the case I can assure you that the number of other groups who will be willing to sponsor the list is mind blowing. Just in case anyone doubts this I will obligate Microsoft right now, we will run this list if the W3C stops running it. However, having worked with the W3C for many years, I can assure you that they will continue to run the list long after the WG is gone. That is standard operating procedure in the IETF. Yaron > -----Original Message----- > From: Jeffrey A. Stuart [mailto:DevilCat@bigfoot.com] > Sent: Wednesday, September 08, 1999 1:53 PM > To: w3c-dist-auth@w3.org > Subject: Delta-V WG/Mailing List > > > As the WG for WebDAV is going to be closed soon, will this > list still exist to > discuss the Delta-V work and other extensions of DAV? While > I am only a > lurker right now, I do have an interest in WebDAV, Delta-V > work and other > extensions of WebDAV. I hope to soon be implementing a > package based on > WebDAV and am very interested in following the protocol as it > moves closer to > a standard. > If not, are there any plans to create a new mailing list for > Delta-V and the > other extensions of WebDAV? > > -- > Jeff Stuart > DevilCat@bigfoot.com > PGP Key ID: 0xE8A76C8A Get it from certserver.pgp.com. > PGP Fingerprint: FBB0 CE1F D159 116A 34CA 77FB 6CCB 04A4 E8A7 6C8A > > -----Original Message----- > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On > Behalf Of Keith Moore > Sent: Tuesday, September 07, 1999 9:24 PM > To: Yaron Goland (Exchange) > Cc: 'jamsden@us.ibm.com'; w3c-dist-auth@w3.org; > moore@cs.utk.edu; paf@swip.net > Subject: Re: WebDAV Working Group Meeting > > > In fact, by > > the next IETF Delta-V should be a WG (Keith?). > > chances are good. the charter is currently being discussed > by iesg and iab. > > Keith > From w3c-dist-auth-request@w3.org Wed Sep 8 21:06: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 VAA04638 for ; Wed, 8 Sep 1999 21:06:04 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id UAA26412; Wed, 8 Sep 1999 20:37:38 -0400 (EDT) Resent-Date: Wed, 8 Sep 1999 20:37:38 -0400 (EDT) Resent-Message-Id: <199909090037.UAA26412@www19.w3.org> Message-ID: <078292D50C98D2118D090008C7E9C6A603C965AE@STAY.platinum.corp.microsoft.com> From: "Yaron Goland (Exchange)" To: "'Greg Stein'" , Keith Moore Cc: w3c-dist-auth@w3.org, paf@swip.net Date: Wed, 8 Sep 1999 17:35:07 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Subject: RE: WebDAV Working Group Meeting Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3258 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list WGs that live too long have a really nasty habit of taking on lives of their own and perpetuating themselves simply to perpetuate themselves. Forcing working groups to go through regular replenishments is a critical activity. It allows new leadership to step up and for the WG to renew itself. Just look at the people who are driving WebDAV today. Most of them are fairly new to the effort and even those who have been around for a while did not take on the leadership roles that they now occupy until recently. This is a natural and healthy process. Forcing WGs to disband and reform under new charters with new leadership encourages this process and keeps the IETF functioning smoothly. One of the reasons the IETF has formed this process is to avoid the types of problems the ITU experiences where WGs live forever and people start to make careers out of a particular WG. This leads to an end to progress and sucks up valuable organizational resources that could be better applied elsewhere. A WG is not a self contained entity. It requires constant care and supervision from the IETF in the form of the ADs. ADs are a very limited resource and need to be applied sparingly. In the case of WebDAV we have no less than three vibrant efforts underway. The first, DASL, already has its own WG. The second, Delta-V, is well on its way to getting a WG. The third, Advanced Collections, is moving along with its specifications. In addition to these efforts we have other efforts underway, such as the renewed interest in ACLs and the potential (although in my opinion misguided ;) interest in live properties. I would strongly council against a DAVEX WG. This type of WG has been tried before and it inevitable fails. The reason being that it turns into a grab bag of technologies with a meandering charter that never stops growing. Standing WGs are almost always a bad idea. Many of the drafts that people are interested in are targeted to very well defined and fairly small communities. These sorts of drafts can be easily explored as individuals submissions. A WG is only necessary when you have a fairly complex draft which requires a significant portion of the community to participate. I don't believe these requirements apply to Advanced Collections or ACLs but I do believe they apply to DASL and Delta-V. As such I hope we shut down the WebDAV WG as soon as possible and let the other efforts bloom. Yaron > -----Original Message----- > From: Greg Stein [mailto:gstein@lyra.org] > Sent: Wednesday, September 08, 1999 1:11 PM > To: Keith Moore > Cc: w3c-dist-auth@w3.org; paf@swip.net > Subject: Re: WebDAV Working Group Meeting > > > Keith Moore wrote: > > > > > Keith, what is the status of the WebDAV working group? > > > > currently, it's still active, but I expect it to be winding down. > > The group can request a meeting if it wants, but it shouldn't > > take on any new work. > > Actually, I'm somewhat amazed as the desire to blow away this working > group. It is still performing a lot of work with the WebDAV > extensions. > If this list goes away, then what? Where does all this discussion go > then? > > I find it silly to shut something down simply because some rule > somewhere says it needs to be shut down. Leave it open until > the work is > done. > > If you must shut it down, then we must have a "DAV Extensions WG" to > take its place. > [this is the heart of the silliness -- renaming something just to > satisfy some rules] > > Cheers, > -g > > -- > Greg Stein, http://www.lyra.org/ > From w3c-dist-auth-request@w3.org Wed Sep 8 21:07: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 VAA04672 for ; Wed, 8 Sep 1999 21:07:57 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id UAA26867; Wed, 8 Sep 1999 20:43:44 -0400 (EDT) Resent-Date: Wed, 8 Sep 1999 20:43:44 -0400 (EDT) Resent-Message-Id: <199909090043.UAA26867@www19.w3.org> Message-ID: <078292D50C98D2118D090008C7E9C6A603C965AF@STAY.platinum.corp.microsoft.com> From: "Yaron Goland (Exchange)" To: "'jamsden@us.ibm.com'" , w3c-dist-auth@w3.org Date: Wed, 8 Sep 1999 17:41:47 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Bindings, Locks, and MOVE Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3259 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list Sigh... every day, in every way, I wish like hell I had never written that damn "COPY followed by a DELETE" language. A server CAN NOT implement a cross server MOVE as a WebDAV COPY method followed by a WebDAV DELETE method. The reason that this isn't possible is that the MOVE requires atomic behavior and it requires that the resource at the destination be the exact same resource (within reason) as at the source. Therefore, for a cross server MOVE to be possible between two unrelated servers a new protocol would have to be invented which could guarantee the WebDAV semantics. In the WebDAV charter you will find the following entry in the list of things not in scope for WebDAV: *HTTP server to server communication protocols The reason this line was put in the charter was that in the beginning a lot of folks wanted to enable server to server communication so it would be possible to do things like cross-server MOVEs. WebDAV decided to focus solely on the issue of client/server communication and thus ruled server/server communication out of scope. If you wish to do cross-server MOVEs you will need a new protocol because WebDAV can't do it. Yaron P.S. Stop laughing Jeff! =) > -----Original Message----- > From: jamsden@us.ibm.com [mailto:jamsden@us.ibm.com] > Sent: Wednesday, September 08, 1999 8:12 AM > To: w3c-dist-auth@w3.org > Subject: RE: Bindings, Locks, and MOVE > > > > > The WebDAV spec says that locks are lost on MOVE. So if the > source resource is > locked, then the MOVE request must include the lock token, > and the lock must be > owned by the requesting principal. Otherwise the delete > portion of the move will > fail. Since MOVE is a best effort method, the copy to the > destination will work, > even if the source can't be deleted. As is the case with > COPY, the lock on the > destination resource is determined by its new parent > collection, not by any lock > state it may have had. This could be taken to mean that the > new resource is not > the same resource moved to a new location, but a different resource. > > > > > > "Slein, Judith A" on 09/08/99 09:34:03 AM > > To: "'Yaron Goland (Exchange)'" , > w3c-dist-auth@w3.org > cc: > > Subject: RE: Bindings, Locks, and MOVE > > > > > The intention is that if a resource is copied or moved into a > tree that is > locked, the lock on the tree remains in force. > > We didn't discuss the case where you are doing a MOVE, and > the resource > being moved is locked, and it is being moved into a collection that is > locked. The lock on the collection will certainly stay in > force, but we > need to decide whether the lock on the resource being MOVEd > will be lost or > whether the MOVE will fail. I guess my own opinion is that > the MOVE should > fail, since that maintains a consistent position that the > state of a MOVEd > resource should be unaffected by the move; if its lock state > would have to > be changed, the move should fail. > > Judith A. Slein > XR&T/Xerox Architecture Center > jslein@crt.xerox.com > 8*222-5169 > > > > -----Original Message----- > > From: Yaron Goland (Exchange) [mailto:yarong@Exchange.Microsoft.com] > > Sent: Tuesday, September 07, 1999 8:49 PM > > To: 'Slein, Judith A'; 'Greg Stein'; w3c-dist-auth@w3.org > > Subject: RE: Bindings, Locks, and MOVE > > > > > > Phew!!! I couldn't believe what I was reading regarding write > > locks. What > > use is a write lock that only sometimes is a write lock? > > Yikes. I'm glad > > that is dead. > > > > However there is still a point in the original post that > > concerns me. Let's > > see if I understand the proposal: > > > > When copying a resource into a tree that is currently locked > > then the lock > > on that tree is lost? > > > > Is that the proposal for how to handle locks at the > > destination of a copied > > resource? That is my reading of the paragraph Judy provided. > > > > Yaron > > > > > -----Original Message----- > > > From: Slein, Judith A [mailto:JSlein@crt.xerox.com] > > > Sent: Tue, September 07, 1999 7:19 AM > > > To: 'Greg Stein'; w3c-dist-auth@w3.org > > > Subject: RE: Bindings, Locks, and MOVE > > > > > > > > > Thanks for bringing the discussion back to earth. > > > > > > I agree with you that the compromise of saying that servers > > > SHOULD protect > > > the path of the Request-URI used in locking a resource is a > > > poor one. It > > > doesn't respond to the issue that was raised, and it > > > needlessly muddies the > > > waters for clients, which now don't know whether the path > > > will be protected > > > or not. > > > > > > I like your suggestion that we keep the MUST language, but > > > state that it > > > applies only to write locks. > > > > > > --Judy > > > > > > > > > > -----Original Message----- > > > > From: Greg Stein [mailto:gstein@lyra.org] > > > > Sent: Friday, September 03, 1999 3:24 AM > > > > To: w3c-dist-auth@w3.org > > > > Subject: Re: Bindings, Locks, and MOVE > > > > > > > > > > > > This whole thread (post-Judy's message) seems to be picking > > > out a very > > > > minor detail of her post. Personally, I find this nit-picking > > > > of detail > > > > counter to the goal of her original post: "test its > > > > conclusions with the > > > > mailing list members." > > > > > > > > For myself (and mod_dav), the first "AGREED" portion > > makes complete > > > > sense, and I do agree with it. > > > > [btw, is *anybody* going to be implementing cross-server > > > MOVE/COPY? is > > > > it necessary to have that feature in the spec at all? of the > > > > umpteen DAV > > > > servers out there now, I don't know any that do this or plan > > > > to do this. > > > > It would be nice to cut the thing and not worry about it.] > > > > > > > > The second "AGREED" portion does not make a whole lot of > > sense. The > > > > commentary states that the position is too strong [because it > > > > might not > > > > make sense with other types of locks]. Are there other locks > > > > out there? > > > > Do people have concrete, useful examples? I haven't heard > > > of anything > > > > besides a write-lock yet. Regardless, I think it should be > > > enforced in > > > > the spec that a write-lock MUST have guaranteed > protection of the > > > > Request-URI. Put in some language that says other locks can > > > define the > > > > MUST/SHOULD nature of protection. Otherwise, leave it in > > > the intuitive > > > > state: a write lock says that others cannot monkey with > your URI. > > > > > > > > Cheers, > > > > -g > > > > > > > > Edgar Schwarz wrote: > > > > > > > > > > On Thu, 2 Sep 1999, Geoffrey M. Clemm wrote: > > > > > > > > > > > From: ccjason@us.ibm.com > > > > > > > > > > > > > > > > > > This discussion began with Yaron's comment that saying > > > > that "it MUST NOT be > > > > > > possible for a principal other than the lock owner to > > > > make a locked resource > > > > > > inaccessible via the URI mapping used to lock the > > > > resource" is too strong. > > > > > > It may make sense for write locks as defined in RFC > > > > 2518, but may not make > > > > > > sense for other sorts of locks that don't restrict > > > > MOVE and DELETE. > > > > > > > > > > > > > > > > > > I believe that this is not specific to any particular > > > > type of locks. All > > > > > > clients need to insure that they have at the very > > > > least a way to unlock > > > > > > the the locks they have created. I assume that to > > > > unlock (a resource), we > > > > > > have to provide a URI of a (the?) resource locked by > > > > that lock... so if > > > > > > someone else changes the URI, it's > > > > > > very likely that we're not going to be able to figure > > > > out what the new > > > > > > URI is... and will have to leave the lock around until > > > > it times out. > > > > > > > > > > > > Since the server needs to deal with this in case > > > > the client just > > > > > > neglects to remove the lock, and if having another client > > > > MOVE your > > > > > > locked resource is a rare occurrence (which I believe > > > it is), then > > > > > > this does not seem to be especially problematical. > > > > > Would it be possible to say: > > > > > If a locked resource is moved the server SHOULD create > > > a indirect > > > > > reference resource which should exist for some > sensible time. > > > > > > > > > > Yes I know, it's complicating the server :-) > > > > > I imagine the above happening perhaps when somebody is > > > reorganizing > > > > > a directory structure and deep in the collections > there are some > > > > > locked resources. > > > > > So the lock owner at least has a decent chance to find > > > out where his > > > > > resource has gone to. > > > > > > > > > > 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. > > > > > > > > -- > > > > Greg Stein, http://www.lyra.org/ > > > > > > > > > > > > > From w3c-dist-auth-request@w3.org Wed Sep 8 22:02: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 WAA06004 for ; Wed, 8 Sep 1999 22:02:33 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id VAA29187; Wed, 8 Sep 1999 21:39:42 -0400 (EDT) Resent-Date: Wed, 8 Sep 1999 21:39:42 -0400 (EDT) Resent-Message-Id: <199909090139.VAA29187@www19.w3.org> Message-ID: <37D70D60.4CF55FD4@lyra.org> Date: Wed, 08 Sep 1999 18:29:04 -0700 From: Greg Stein X-Mailer: Mozilla 3.01 (X11; I; Linux 2.0.28 i586) MIME-Version: 1.0 To: w3c-dist-auth@w3.org References: <078292D50C98D2118D090008C7E9C6A603C965AD@STAY.platinum.corp.microsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: Delta-V WG/Mailing List Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3260 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 Not to mention that webdav.org can sponsor any and all mailing lists. Whether official WG lists, project-related, or even semi-private lists. As long as it is webdav-related, or there are DAV features in the project. Cheers, -g Yaron Goland (Exchange) wrote: > > My understanding is that the W3C will continue to operate this list for as > long as anyone is interested in it. If that proves not to be the case I can > assure you that the number of other groups who will be willing to sponsor > the list is mind blowing. Just in case anyone doubts this I will obligate > Microsoft right now, we will run this list if the W3C stops running it. > > However, having worked with the W3C for many years, I can assure you that > they will continue to run the list long after the WG is gone. That is > standard operating procedure in the IETF. > > Yaron > > > -----Original Message----- > > From: Jeffrey A. Stuart [mailto:DevilCat@bigfoot.com] > > Sent: Wednesday, September 08, 1999 1:53 PM > > To: w3c-dist-auth@w3.org > > Subject: Delta-V WG/Mailing List > > > > > > As the WG for WebDAV is going to be closed soon, will this > > list still exist to > > discuss the Delta-V work and other extensions of DAV? While > > I am only a > > lurker right now, I do have an interest in WebDAV, Delta-V > > work and other > > extensions of WebDAV. I hope to soon be implementing a > > package based on > > WebDAV and am very interested in following the protocol as it > > moves closer to > > a standard. > > If not, are there any plans to create a new mailing list for > > Delta-V and the > > other extensions of WebDAV? > > > > -- > > Jeff Stuart > > DevilCat@bigfoot.com > > PGP Key ID: 0xE8A76C8A Get it from certserver.pgp.com. > > PGP Fingerprint: FBB0 CE1F D159 116A 34CA 77FB 6CCB 04A4 E8A7 6C8A > > > > -----Original Message----- > > From: w3c-dist-auth-request@w3.org > > [mailto:w3c-dist-auth-request@w3.org]On > > Behalf Of Keith Moore > > Sent: Tuesday, September 07, 1999 9:24 PM > > To: Yaron Goland (Exchange) > > Cc: 'jamsden@us.ibm.com'; w3c-dist-auth@w3.org; > > moore@cs.utk.edu; paf@swip.net > > Subject: Re: WebDAV Working Group Meeting > > > > > In fact, by > > > the next IETF Delta-V should be a WG (Keith?). > > > > chances are good. the charter is currently being discussed > > by iesg and iab. > > > > Keith > > -- Greg Stein, http://www.lyra.org/ From w3c-dist-auth-request@w3.org Thu Sep 9 09:37: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 JAA28815 for ; Thu, 9 Sep 1999 09:37:55 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id JAA13544; Thu, 9 Sep 1999 09:26:04 -0400 (EDT) Resent-Date: Thu, 9 Sep 1999 09:26:04 -0400 (EDT) Resent-Message-Id: <199909091326.JAA13544@www19.w3.org> From: jamsden@us.ibm.com X-Lotus-FromDomain: IBMUS To: "Yaron Goland (Exchange)" cc: w3c-dist-auth@w3.org Message-ID: <852567E7.0049C65C.00@d54mta03.raleigh.ibm.com> Date: Thu, 9 Sep 1999 09:25:54 -0400 Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Subject: RE: Bindings, Locks, and MOVE Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3261 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, I guess I don't see the issue. See comments below. "Yaron Goland (Exchange)" on 09/08/99 08:41:47 PM To: Jim Amsden/Raleigh/IBM@IBMUS, w3c-dist-auth@w3.org cc: Subject: RE: Bindings, Locks, and MOVE Sigh... every day, in every way, I wish like hell I had never written that damn "COPY followed by a DELETE" language. A server CAN NOT implement a cross server MOVE as a WebDAV COPY method followed by a WebDAV DELETE method. The reason that this isn't possible is that the MOVE requires atomic behavior and it requires that the resource at the destination be the exact same resource (within reason) as at the source. Therefore, for a cross server MOVE to be possible between two unrelated servers a new protocol would have to be invented which could guarantee the WebDAV semantics. A WebDAV MOVE is a best effort operation, so it would seem that this is consistent with non-atomic operation (which might miss resources that were added or changed after the move began). DAV4J does the MOVE as an atomic operation whether its from a client of another server acting as a client, so it wouldn't have this problem anyway. As far as having the destination be exactly the same as the source, I don't know what "within reason" means. If it means has the same GUID, or is effectively a new reference to the same resource in some server-dependent way, then no, I can't probably do that. DAV4J makes a new resource at the destination that has the same contents as the source, but not necessarily the same character encoding, and the same properties if possible. The only issue is conversion between live and dead properties when the servers involved support different sets (a potential interoperability problem). It seems this is at least a useful interpretation of the spec. In the WebDAV charter you will find the following entry in the list of things not in scope for WebDAV: *HTTP server to server communication protocols The reason this line was put in the charter was that in the beginning a lot of folks wanted to enable server to server communication so it would be possible to do things like cross-server MOVEs. WebDAV decided to focus solely on the issue of client/server communication and thus ruled server/server communication out of scope. If you wish to do cross-server MOVEs you will need a new protocol because WebDAV can't do it. Yaron P.S. Stop laughing Jeff! =) > -----Original Message----- > From: jamsden@us.ibm.com [mailto:jamsden@us.ibm.com] > Sent: Wednesday, September 08, 1999 8:12 AM > To: w3c-dist-auth@w3.org > Subject: RE: Bindings, Locks, and MOVE > > > > > The WebDAV spec says that locks are lost on MOVE. So if the > source resource is > locked, then the MOVE request must include the lock token, > and the lock must be > owned by the requesting principal. Otherwise the delete > portion of the move will > fail. Since MOVE is a best effort method, the copy to the > destination will work, > even if the source can't be deleted. As is the case with > COPY, the lock on the > destination resource is determined by its new parent > collection, not by any lock > state it may have had. This could be taken to mean that the > new resource is not > the same resource moved to a new location, but a different resource. > > > > > > "Slein, Judith A" on 09/08/99 09:34:03 AM > > To: "'Yaron Goland (Exchange)'" , > w3c-dist-auth@w3.org > cc: > > Subject: RE: Bindings, Locks, and MOVE > > > > > The intention is that if a resource is copied or moved into a > tree that is > locked, the lock on the tree remains in force. > > We didn't discuss the case where you are doing a MOVE, and > the resource > being moved is locked, and it is being moved into a collection that is > locked. The lock on the collection will certainly stay in > force, but we > need to decide whether the lock on the resource being MOVEd > will be lost or > whether the MOVE will fail. I guess my own opinion is that > the MOVE should > fail, since that maintains a consistent position that the > state of a MOVEd > resource should be unaffected by the move; if its lock state > would have to > be changed, the move should fail. > > Judith A. Slein > XR&T/Xerox Architecture Center > jslein@crt.xerox.com > 8*222-5169 > > > > -----Original Message----- > > From: Yaron Goland (Exchange) [mailto:yarong@Exchange.Microsoft.com] > > Sent: Tuesday, September 07, 1999 8:49 PM > > To: 'Slein, Judith A'; 'Greg Stein'; w3c-dist-auth@w3.org > > Subject: RE: Bindings, Locks, and MOVE > > > > > > Phew!!! I couldn't believe what I was reading regarding write > > locks. What > > use is a write lock that only sometimes is a write lock? > > Yikes. I'm glad > > that is dead. > > > > However there is still a point in the original post that > > concerns me. Let's > > see if I understand the proposal: > > > > When copying a resource into a tree that is currently locked > > then the lock > > on that tree is lost? > > > > Is that the proposal for how to handle locks at the > > destination of a copied > > resource? That is my reading of the paragraph Judy provided. > > > > Yaron > > > > > -----Original Message----- > > > From: Slein, Judith A [mailto:JSlein@crt.xerox.com] > > > Sent: Tue, September 07, 1999 7:19 AM > > > To: 'Greg Stein'; w3c-dist-auth@w3.org > > > Subject: RE: Bindings, Locks, and MOVE > > > > > > > > > Thanks for bringing the discussion back to earth. > > > > > > I agree with you that the compromise of saying that servers > > > SHOULD protect > > > the path of the Request-URI used in locking a resource is a > > > poor one. It > > > doesn't respond to the issue that was raised, and it > > > needlessly muddies the > > > waters for clients, which now don't know whether the path > > > will be protected > > > or not. > > > > > > I like your suggestion that we keep the MUST language, but > > > state that it > > > applies only to write locks. > > > > > > --Judy > > > > > > > > > > -----Original Message----- > > > > From: Greg Stein [mailto:gstein@lyra.org] > > > > Sent: Friday, September 03, 1999 3:24 AM > > > > To: w3c-dist-auth@w3.org > > > > Subject: Re: Bindings, Locks, and MOVE > > > > > > > > > > > > This whole thread (post-Judy's message) seems to be picking > > > out a very > > > > minor detail of her post. Personally, I find this nit-picking > > > > of detail > > > > counter to the goal of her original post: "test its > > > > conclusions with the > > > > mailing list members." > > > > > > > > For myself (and mod_dav), the first "AGREED" portion > > makes complete > > > > sense, and I do agree with it. > > > > [btw, is *anybody* going to be implementing cross-server > > > MOVE/COPY? is > > > > it necessary to have that feature in the spec at all? of the > > > > umpteen DAV > > > > servers out there now, I don't know any that do this or plan > > > > to do this. > > > > It would be nice to cut the thing and not worry about it.] > > > > > > > > The second "AGREED" portion does not make a whole lot of > > sense. The > > > > commentary states that the position is too strong [because it > > > > might not > > > > make sense with other types of locks]. Are there other locks > > > > out there? > > > > Do people have concrete, useful examples? I haven't heard > > > of anything > > > > besides a write-lock yet. Regardless, I think it should be > > > enforced in > > > > the spec that a write-lock MUST have guaranteed > protection of the > > > > Request-URI. Put in some language that says other locks can > > > define the > > > > MUST/SHOULD nature of protection. Otherwise, leave it in > > > the intuitive > > > > state: a write lock says that others cannot monkey with > your URI. > > > > > > > > Cheers, > > > > -g > > > > > > > > Edgar Schwarz wrote: > > > > > > > > > > On Thu, 2 Sep 1999, Geoffrey M. Clemm wrote: > > > > > > > > > > > From: ccjason@us.ibm.com > > > > > > > > > > > > > > > > > > This discussion began with Yaron's comment that saying > > > > that "it MUST NOT be > > > > > > possible for a principal other than the lock owner to > > > > make a locked resource > > > > > > inaccessible via the URI mapping used to lock the > > > > resource" is too strong. > > > > > > It may make sense for write locks as defined in RFC > > > > 2518, but may not make > > > > > > sense for other sorts of locks that don't restrict > > > > MOVE and DELETE. > > > > > > > > > > > > > > > > > > I believe that this is not specific to any particular > > > > type of locks. All > > > > > > clients need to insure that they have at the very > > > > least a way to unlock > > > > > > the the locks they have created. I assume that to > > > > unlock (a resource), we > > > > > > have to provide a URI of a (the?) resource locked by > > > > that lock... so if > > > > > > someone else changes the URI, it's > > > > > > very likely that we're not going to be able to figure > > > > out what the new > > > > > > URI is... and will have to leave the lock around until > > > > it times out. > > > > > > > > > > > > Since the server needs to deal with this in case > > > > the client just > > > > > > neglects to remove the lock, and if having another client > > > > MOVE your > > > > > > locked resource is a rare occurrence (which I believe > > > it is), then > > > > > > this does not seem to be especially problematical. > > > > > Would it be possible to say: > > > > > If a locked resource is moved the server SHOULD create > > > a indirect > > > > > reference resource which should exist for some > sensible time. > > > > > > > > > > Yes I know, it's complicating the server :-) > > > > > I imagine the above happening perhaps when somebody is > > > reorganizing > > > > > a directory structure and deep in the collections > there are some > > > > > locked resources. > > > > > So the lock owner at least has a decent chance to find > > > out where his > > > > > resource has gone to. > > > > > > > > > > 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. > > > > > > > > -- > > > > Greg Stein, http://www.lyra.org/ > > > > > > > > > > > > > From w3c-dist-auth-request@w3.org Thu Sep 9 11:02: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 LAA02803 for ; Thu, 9 Sep 1999 11:02:38 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id KAA16009; Thu, 9 Sep 1999 10:51:56 -0400 (EDT) Resent-Date: Thu, 9 Sep 1999 10:51:56 -0400 (EDT) Resent-Message-Id: <199909091451.KAA16009@www19.w3.org> Message-ID: <8E3CFBC709A8D21191A400805F15E0DBD2443B@crte147.wc.eso.mc.xerox.com> From: "Slein, Judith A" To: "'Yaron Goland (Exchange)'" , "'Greg Stein'" , Keith Moore Cc: w3c-dist-auth@w3.org, paf@swip.net Date: Thu, 9 Sep 1999 10:50:07 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Subject: RE: WebDAV Working Group Meeting Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3262 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list > -----Original Message----- > From: Yaron Goland (Exchange) [mailto:yarong@exchange.microsoft.com] > Sent: Wednesday, September 08, 1999 8:35 PM > To: 'Greg Stein'; Keith Moore > Cc: w3c-dist-auth@w3.org; paf@swip.net > Subject: RE: WebDAV Working Group Meeting > > > A WG is only necessary when you have a fairly > complex draft > which requires a significant portion of the community to > participate. I > don't believe these requirements apply to Advanced > Collections or ACLs but I > do believe they apply to DASL and Delta-V. > > As such I hope we shut down the WebDAV WG as soon as possible > and let the > other efforts bloom. > > Yaron I do think the work on Advanced Collections benefits from the support of a working group, and would like to see the WebDAV working group continue until the 3 advanced collections specs are through IETF-wide last call. I also think deadlines are good, that limiting the life of working groups is a good thing, and that we should try to wrap up the advanced collections work as soon as possible. --Judy From w3c-dist-auth-request@w3.org Thu Sep 9 11:18: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 LAA03130 for ; Thu, 9 Sep 1999 11:18:01 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id LAA17227; Thu, 9 Sep 1999 11:08:43 -0400 (EDT) Resent-Date: Thu, 9 Sep 1999 11:08:43 -0400 (EDT) Resent-Message-Id: <199909091508.LAA17227@www19.w3.org> Message-ID: <37D7B978.CF9D7537@ecal.com> Date: Thu, 09 Sep 1999 09:43:21 -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: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: MUST a PROPPATCH return 207? Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3263 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 RFC-2518 seems to be silent on when PROPPATCH returns 207 Multistatus. Other methods specify (e.g., DELETE says 207 is for when a failure occurs with a resource other than the one identified by the Request-URI), but PROPPACH is silent. Of course, it has to return 207 if it's applying to multiple resources (or multiple properties on a single resource); but what about if it's modifying a single property on a single resource? -- /================================================================\ |John Stracke |http://www.ecal.com|My opinions are my own. | |Chief Scientist |===============================================| |eCal Corp. |Yes, sir, we've graphed the data. It's a smiley| |francis@ecal.com|face, sir. | \================================================================/ From w3c-dist-auth-request@w3.org Thu Sep 9 11:21: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 LAA03221 for ; Thu, 9 Sep 1999 11:21:15 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id LAA17300; Thu, 9 Sep 1999 11:11:59 -0400 (EDT) Resent-Date: Thu, 9 Sep 1999 11:11:59 -0400 (EDT) Resent-Message-Id: <199909091511.LAA17300@www19.w3.org> Message-ID: <8E3CFBC709A8D21191A400805F15E0DBD2443C@crte147.wc.eso.mc.xerox.com> From: "Slein, Judith A" To: "'Yaron Goland (Exchange)'" , "Slein, Judith A" , "'jamsden@us.ibm.com'" , w3c-dist-auth@w3.org Date: Thu, 9 Sep 1999 11:11:26 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Bindings, Locks, and MOVE Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3264 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list Wait, I think we need to go back to the original proposals from the design team. There are a lot of separate points there, and SHOULD only applied to one of them (not the one about whether locks survive a MOVE). Here they are again, just for reference: AGREED: For MOVE, if the source resource is locked (the lock is not inherited from a parent collection), the lock moves with it to the destination. (This is a reversal of the position taken in RFC 2518.) If the destination resource is locked (the lock is not inherited from a parent collection), its lock is lost. For MOVE, if it's the parent collections that are locked, the resource being moved inherits the lock of the destination collection. If a collection is MOVEd, and there are some locked resources in that collection, the locks on those resources get moved. We don't require support for cross-server MOVEs where the source resource is locked, but we will define an optional lock header for use in responses, so that the destination server can change the lock token and return the new token with its response. If the server allows a cross- server MOVE but elects not to return a lock token value, the client can do lock discovery to find it out. If a cross-server MOVE is allowed in a case where there are multiple bindings to the source resource, and the source resource is locked, the result will be that the resource is locked on both servers with the same lock token in both places. (If the same lock token cannot be used, the MOVE must fail.) For COPY, any locks at the destination are deleted, and no new locks are created at the destination. After the COPY, there will be no locks at the destination except what is inherited from above. AGREED: We'll change the language related to protecting the Request-URI to SHOULD. We intend this to protect the entire path, including the final segment. This does impact the definition of write locks in RFC 2518, which will have to change. It's no longer that a write lock MUST prevent MOVE and DELETE, but that it SHOULD prevent them. I agree with Yaron's rant about SHOULD. I think that changing the language to SHOULD on this last point is a bad thing. Back to the issue of having locks move when a resource is MOVEd: The one case that has been cited of a system that cannot move locks with a resource is Windows 95. I assume that it's really all the Microsoft file systems, including future plans, that won't be able to comply if we say that locks MUST move with their resources. So that's a pretty serious pragmatic consideration. It still would be interesting to hear about other systems that do locking, and whether they would be able to comply with the position stated above. Setting aside for a minute the pragmatic considerations and looking for technical ones: The only technical reason we have heard for not having locks move with the resource is the case of cross-server moves. Since we didn't standardize an algorithm for constructing lock tokens, it might not be possible for the destination server to preserve the lock token created by the source server in a cross-server move. We think we can solve this problem by letting the destination server replace the lock token with one of its own, and inform the client of the new lock token. --Judy > -----Original Message----- > From: Yaron Goland (Exchange) [mailto:yarong@Exchange.Microsoft.com] > Sent: Wednesday, September 08, 1999 4:05 PM > To: 'Slein, Judith A'; 'jamsden@us.ibm.com'; w3c-dist-auth@w3.org > Subject: RE: Bindings, Locks, and MOVE > > > The reason that locks are lost on MOVEs is that the > overwhelming majority of > existing systems can not handle moving locks on MOVEs. We > could, of course, > have said locks SHOULD NOT be lost on moves. But this sort of > language is > exactly the type of language the destroys interoperability. > When I write a > client I am going to write it to either demand that locks > move properly on > moves in the average case (with exceptions handled as force > 10 failures) or > I'm going to write it to assume that locks never work on MOVE > and set up my > UI and APIs appropriately. > their UI and internal code in order to compensate. > > We will be consistent. > > We will be uniform. > > We will use "MUST." > > If you want to change the language to say that locks MUST > move then we can > discuss this, although I think preventing the majority of > existing systems > in the world from supporting WebDAV is probably a bad idea. > If you want to > use the Mandatory mechanism, I think that would be a great > idea. But the > requirement absolutely will not be a SHOULD. > > Yaron > > P.S. Phew... I haven't had a good rant in a while. Feels good. =) > From w3c-dist-auth-request@w3.org Thu Sep 9 13:50: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 NAA06240 for ; Thu, 9 Sep 1999 13:50:24 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id NAA21582; Thu, 9 Sep 1999 13:40:08 -0400 (EDT) Resent-Date: Thu, 9 Sep 1999 13:40:08 -0400 (EDT) Resent-Message-Id: <199909091740.NAA21582@www19.w3.org> Message-ID: <078292D50C98D2118D090008C7E9C6A603C965BF@STAY.platinum.corp.microsoft.com> From: "Yaron Goland (Exchange)" To: "'Slein, Judith A'" , "'Greg Stein'" , Keith Moore Cc: w3c-dist-auth@w3.org, paf@swip.net Date: Thu, 9 Sep 1999 10:39:33 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Subject: RE: WebDAV Working Group Meeting Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3265 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 there are a lot of problems with AC that aren't going to be solved any time soon. I appreciate the desire to close down the specs quickly but every single time any point is brought up about AC it ends up bringing up 10 other points. The specs are leaking and most likely require a complete re-think. A good place to start would be an object model document. In almost every case the AC spec's problems can be traced back to the fact that it is trying to enable very complicated namespace/resource manipulations without having a good model of how the namespace/resource space actually works. Therefore if WebDAV is kept open until AC is done then WebDAV will go into Zombie state for at least another year. I realize that a lot of people disagree with me. I would recommend looking at the e-mail log on AC over the last few years and judging for yourself. As such I suggest we close down WebDAV and either bring up a new WG for AC or let them go on their own. Yaron > -----Original Message----- > From: Slein, Judith A [mailto:JSlein@crt.xerox.com] > Sent: Thursday, September 09, 1999 7:50 AM > To: 'Yaron Goland (Exchange)'; 'Greg Stein'; Keith Moore > Cc: w3c-dist-auth@w3.org; paf@swip.net > Subject: RE: WebDAV Working Group Meeting > > > > -----Original Message----- > > From: Yaron Goland (Exchange) [mailto:yarong@exchange.microsoft.com] > > Sent: Wednesday, September 08, 1999 8:35 PM > > To: 'Greg Stein'; Keith Moore > > Cc: w3c-dist-auth@w3.org; paf@swip.net > > Subject: RE: WebDAV Working Group Meeting > > > > > > A WG is only necessary when you have a fairly > > complex draft > > which requires a significant portion of the community to > > participate. I > > don't believe these requirements apply to Advanced > > Collections or ACLs but I > > do believe they apply to DASL and Delta-V. > > > > As such I hope we shut down the WebDAV WG as soon as possible > > and let the > > other efforts bloom. > > > > Yaron > > I do think the work on Advanced Collections benefits from the > support of a > working group, and would like to see the WebDAV working group > continue until > the 3 advanced collections specs are through IETF-wide last call. > > I also think deadlines are good, that limiting the life of > working groups is > a good thing, and that we should try to wrap up the advanced > collections > work as soon as possible. > > --Judy > From w3c-dist-auth-request@w3.org Thu Sep 9 22:07: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 WAA11527 for ; Thu, 9 Sep 1999 22:07:39 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id VAA01025; Thu, 9 Sep 1999 21:57:00 -0400 (EDT) Resent-Date: Thu, 9 Sep 1999 21:57:00 -0400 (EDT) Resent-Message-Id: <199909100157.VAA01025@www19.w3.org> From: ccjason@us.ibm.com X-Lotus-FromDomain: IBMUS To: Greg Stein cc: w3c-dist-auth@w3.org Message-ID: <852567E8.000AABDD.00@D51MTA07.pok.ibm.com> Date: Thu, 9 Sep 1999 22:04:04 -0400 Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Subject: UNLOCKING, was Bindings, Locks and MOVE's Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3266 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 whole thread (post-Judy's message) seems to be picking out a very minor detail of her post. Personally, I find this nit-picking of detail counter to the goal of her original post: "test its conclusions with the mailing list members." Sorry Greg. I'm basically in agreement with testing the conclusions, I was just pointing out one place where I as a member of the list feel that it's off the mark. I'm on the fence on most of the other stuff and want to hear more opinions there without comment from me. My "nit-picking" is not meant to be an indictment of the whole proposal. The second "AGREED" portion does not make a whole lot of sense. The commentary states that the position is too strong [because it might not make sense with other types of locks]. Are there other locks out there? Not in the spec, but the issues list does hint at suggested approaches which include other lock types. Do people have concrete, useful examples? With write locks, shared or exclusive, there is no way to protect a resource without preventing others from protecting it. If there were a "write-block" lock which people usually would use in shared mode, that would be another type of lock. (I guess most people call these "read locks".) I don't think the example itself matters though and I don't want anyone to get hung up on it. The point is the spec provides for other lock types and my statement expresses the opinion that the need to protect a URI goes beyond write locks and applies to all locks. At least as long as we use the lock URI as the sole means of identifying a locked resource or unlocking it. (The use of URI's need not be necessary but other options haven't seriously been discussed.) I haven't heard of anything besides a write-lock yet. Regardless, I think it should be enforced in the spec that a write-lock MUST have guaranteed protection of the Request-URI. Put in some language that says other locks can define the MUST/SHOULD nature of protection. Otherwise, leave it in the intuitive state: a write lock says that others cannot monkey with your URI. Sounds paletable. We can speak of this on a case by case basis. We just need to not forget to specify it for each type of lock we devise. I'd feel better if we'd either solve the unlocking problem or just say upfront that all lock URI's are protected. If we solved that problem, I'd feel very comfortable saying that we can define URI protection on a case by case (lcck-type by lock-type) basis. How can we solve it? I can think of several options... 1) One way would be to say that the URI of the unlock method is not relavent. Only the provided lock token is relavent to the request. The complication is that the only way that we have to provide lock tokens right now is via the "Lock-Token" header. And it is my understanding that that header always implicitly or explicitly causes a check that the provided lock token applies to the request URI or some explicitly specified URI. Therefore, in a neat implementation, the lock-token check might tend to be done before the server's method specific code ever gets a chance to execute. 1b) We could specify a different request header for specifying the locktoken to be unlocked. That new header would not involve checking if the lock token applies to a known URI. 2) We could say that a LOCK response provides a pseudo URI that we can use for the UNLOCK request that remains in effect until LOCK goes away. And of course we'd try not to recycle those URI's too rapidly. 2b) We could have the lock request provide a pseudo URI like (2), but this URI would be a URI that essentially specifies the GUID for the resource that was locked. The approach of course is dependent on us not defining any semantics where the root of a lock can drift to another resource. (No null lock reources for example.) 3) We could say that the lock token itself can be specified as the URI of the unlock request. This sounds weird and also seems to preclude the possibility of unlocking multiple locks at once. (The current spec is unclear on this capability.) My preference is (1b). Once we do this, I think we'll have more flexibility to say if a given lock will protect a URI. Then I'd feel very comfortable with your recommendation of just saying that *write* locks protect the lock URI. Cheers, J. From w3c-dist-auth-request@w3.org Thu Sep 9 22:39:45 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 WAA12596 for ; Thu, 9 Sep 1999 22:39:45 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id WAA01446; Thu, 9 Sep 1999 22:30:32 -0400 (EDT) Resent-Date: Thu, 9 Sep 1999 22:30:32 -0400 (EDT) Resent-Message-Id: <199909100230.WAA01446@www19.w3.org> From: ccjason@us.ibm.com X-Lotus-FromDomain: IBMUS To: Edgar Schwarz , w3c-dist-auth@w3.org Message-ID: <852567E8.000DC2DC.00@D51MTA07.pok.ibm.com> Date: Thu, 9 Sep 1999 22:37:51 -0400 Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Subject: Protected URI's wes: Bindings, Locks, and MOVE Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3267 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list Edgar, Since the server needs to deal with this in case the client just neglects to remove the lock, and if having another client MOVE your locked resource is a rare occurrence (which I believe it is), then this does not seem to be especially problematical. Would it be possible to say: If a locked resource is moved the server SHOULD create a indirect reference resource which should exist for some sensible time. Yes I know, it's complicating the server :-) I imagine the above happening perhaps when somebody is reorganizing a directory structure and deep in the collections there are some locked resources. So the lock owner at least has a decent chance to find out where his resource has gone to. I believe you're proposing an alternative to protecting a lock URI... I don't think the server can create the indirect reference *during* the MOVE since (1) The now null resource URI may not have a parent after the move if the moved resource was a grandfather collection above. I think we require that even indirect resource have a parent. (2) The client that requested the MOVE might not be the owner of the lock. So telling the mover, doesn't really help the owner of the lock. I assume the owner of the lock is the entity most interested in knowing it moved. A similar approach to what you've suggested might be to provide a URI at the time the lock is created. I know that Geoff has one argument against it lined up already. :-) I still think it's worth discussing though. From w3c-dist-auth-request@w3.org Thu Sep 9 23:00: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 XAA12798 for ; Thu, 9 Sep 1999 23:00:05 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id WAA01744; Thu, 9 Sep 1999 22:50:19 -0400 (EDT) Resent-Date: Thu, 9 Sep 1999 22:50:19 -0400 (EDT) Resent-Message-Id: <199909100250.WAA01744@www19.w3.org> From: ccjason@us.ibm.com X-Lotus-FromDomain: IBMUS To: "Yaron Goland (Exchange)" cc: w3c-dist-auth@w3.org, jamsden@us.ibm.com, "'Slein, Judith A'" Message-ID: <852567E8.000F8D5F.00@D51MTA07.pok.ibm.com> Date: Thu, 9 Sep 1999 22:57:25 -0400 Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Subject: RE: Bindings, Locks, and MOVE Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3268 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'm not sure if it was even an doubted, but I agree with Yaron that we must say that locks either MUST move as a result of the MOVE or that they MUST NOT move as a result of a MOVE operation. ------------------------------------------ Phone: 914-784-7569, ccjason@us.ibm.com From w3c-dist-auth-request@w3.org Fri Sep 10 00:52: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 AAA14328 for ; Fri, 10 Sep 1999 00:52:59 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id AAA02517; Fri, 10 Sep 1999 00:43:03 -0400 (EDT) Resent-Date: Fri, 10 Sep 1999 00:43:03 -0400 (EDT) Resent-Message-Id: <199909100443.AAA02517@www19.w3.org> Date: Fri, 10 Sep 1999 00:42:47 -0400 Message-Id: <9909100442.AA01057@tantalum> From: "Geoffrey M. Clemm" To: yarong@Exchange.Microsoft.com Cc: w3c-dist-auth@w3.org In-Reply-To: <078292D50C98D2118D090008C7E9C6A603C9659C@STAY.platinum.corp.microsoft.com> (yarong@Exchange.Microsoft.com) Subject: Re: Bindings, Locks, and MOVE Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3269 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)" That the spec needs to address the issue of cross-server anything indicates that the specification is fundamentally broken and needs to be re-written. Or it means that the section that talks about the cross-server as a special case is irrelevant and should be deleted. The spec should not need to address these issues at all. Rather it should provide a well defined start and end state. It is up to the server to figure out what that means in application. Yes, I heartily agree! That reference to cross server moves in the spec always bothered me, but it took this note from Yaron to clarify why it was so bothersome. I suspect y'all have taken a serious wrong term somewhere. Actually "a wrong term" in this context is quite a good pun, albeit somewhat recursive and probably unintentional (;-). I believe that it is sufficient to just delete the sentence that talks about cross server moves. If a server can implement it, then fine. If it can't, it needs nothing in the protocol to indicate that it can fail the request -- it simply must do so. So please ignore all my burbling about SHOULD's and MAY's in this regard (which I've quoted below as a form of self flagellation). Also, I fully agree with Yaron's point in a different thread that a MOVE is not a COPY followed by a DELETE (and yes, Yaron, I admit it, I was laughing while reading that thread :-). My point below was intended to be that a COPY followed by a DELETE is *not* a MOVE, it is a COPY followed by a DELETE. Cheers, Geoff > From: Geoffrey M. Clemm [mailto:gclemm@tantalum.atria.com] > > From: jamsden@us.ibm.com > > DAV4J does do cross server COPY and MOVE. This is an important > function required to support publishing web applications. > DAV4J does > it by reusing GET/PROPFIND and PUT/PROPPATCH (followed by DELETE if > MOVE). > > Let me modify Greg's question just a bit: > > Is anybody going to be implementing cross-server MOVE as anything > more than a cross-server COPY followed by a DELETE? The reason > I ask is that it is a MOVE that has all the tricky interactions > with multiple bindings and locks, while a COPY is relatively > straightforward (new resources are created, so bindings and locks > are not affected). > > In particular, I'd advocate making cross-server COPY's a MUST > (or at least a SHOULD), while a cross-server MOVE's a MAY > (or at most a SHOULD). My main argument against MOVE is that > unless the "fixup" step that comes between the logical > "COPY and the MOVE" is well defined (as it is in the > advanced collection spec), the MOVE semantics is so vague > as to be useless. > > Then a client that wants the COPY/DELETE form of "MOVE" can just > issue a COPY followed by a DELETE. > > Cheers, > Geoff > From w3c-dist-auth-request@w3.org Fri Sep 10 01:13:45 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 BAA15341 for ; Fri, 10 Sep 1999 01:13:45 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id BAA02720; Fri, 10 Sep 1999 01:04:52 -0400 (EDT) Resent-Date: Fri, 10 Sep 1999 01:04:52 -0400 (EDT) Resent-Message-Id: <199909100504.BAA02720@www19.w3.org> From: ccjason@us.ibm.com X-Lotus-FromDomain: IBMUS To: w3c-dist-auth@w3.org Message-ID: <852567E8.001BDAE0.00@D51MTA07.pok.ibm.com> Date: Fri, 10 Sep 1999 00:46:28 -0400 Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Subject: Protected URI's wes: Bindings, Locks, and MOVE Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3270 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list Okay, a bunch of people have spoken up to say that the lock URI of a write lock MUST be protected. The emphasis here is on "MUST". I tend to agree, but I'll be a devils advocate... 1) In the recent proposal by the AdvColl folks (including myself) that Judith posted, we also proposed that locks at the source move to the destination when a MOVE occurs? Are we prepared to say that the protected URI also moves? 2) Okay, this proposal has also tried to promote the model that it is the resource that holds the lock... not the URI or something else. OTOH, you all have probably heard me speak of a protecte *URI*. It does seem odd that we say that it's a resource that is locked, but that it's a URI that is protected. Here's thinking of why it's a URI. Now let's consider the case where the lock is rooted at a resource that has two bindings to it. /a/b and /x/y both refer to the same resource, but /a/ and /x/ are different resources. (We have two bindings to the resource at /a/b.) Now let's lock /a/b. /a/b is protected, but is /x/y? Most of us would say no since unbinding /x/ or /x/y wouldn't interfere with what resource is at /a/b. That might strike us as odd because we've said that the lock is rooted at a *resource*... but only some mappings to the resource are protected. We might even be tempted to say that the protection is rooted at the *binding* since breaking the binding /a/b nor matter what mapping is used, will change what resource is at /a/b. Well... Let's have /a/b and /m/n/b Where /a/ and /n/ are the same resource. And let's lock /a/b. Now /a/b should be protected. But is /c/d/b protected? It's the same resource... and they share the same binding? On the otherhand, I think everyone would agree that despite the lock, anyone would be allowed to UNBIND (DELETE in our current vocab) /m/ and /m/n/. Therefore /m/n/b is not protected despite that resource only having one binding. This suggests that the protection is rooted a URI, not a resource (and not a binding). Admittedly that's just saying that it is the URI -> resource mapping that is protected... which seems much more benign. Now we've said it's a URI mapping that is protected. Here's a contrived santity check... /a/b/c/d is locked. /m/c/d also exists. /a/, /a/b/ /a/b/c/, /m/, /m/c/ are all distinct resources. The only resource here with mutliple bindings is the resource at /a/b/c/d and /m/c/d.. Now an outside entity that doesn't have the lock does a BIND /m/ to dest /a/b/. Do we allow the BIND? Note: the parentage of the protected resource has changed... but it's final mapping has not. Can a server allow it? Should it allow it? MUST it allow it? Note: if we say MUST, that means a server has a bit more work to do. It has to create a model of the final state and determine if any mappings change. Perhaps not *much* more work... but definitely *more*. So is it okay with everyone to say that although it's a resource that's locked, it's its lockURI mapping that is protected? Or is this difference disturbing? 3) I have another set of rhetorical questions regarding reasigning a protected URI to a lock on a MOVE, but first I'd like to hear comments about what I've said above. (It's also past my bed time. :-)) ------------------------------------------ Phone: 914-784-7569, ccjason@us.ibm.com From w3c-dist-auth-request@w3.org Fri Sep 10 11:29: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 LAA10972 for ; Fri, 10 Sep 1999 11:29:04 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id LAA14103; Fri, 10 Sep 1999 11:17:25 -0400 (EDT) Resent-Date: Fri, 10 Sep 1999 11:17:25 -0400 (EDT) Resent-Message-Id: <199909101517.LAA14103@www19.w3.org> Message-ID: <37D920D6.97091D9D@ecal.com> Date: Fri, 10 Sep 1999 11:16:38 -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: <078292D50C98D2118D090008C7E9C6A603C965AF@STAY.platinum.corp.microsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: Bindings, Locks, and MOVE Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3271 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 "Yaron Goland (Exchange)" wrote: > If you wish to do cross-server > MOVEs you will need a new protocol because WebDAV can't do it. Disturbing thought from the peanut gallery: cross-host MOVE (i.e., between two URLs with different hostnames) is not necessarily cross-server, because they could be hosted on the same machine. So, sometimes, something that looks like a cross-server MOVE may work. But usually it won't. And, in some cases, a user may find it works for a while and then stops, when his admin splits the server up. Or vice versa. Fun, no? :-) -- /============================================================\ |John Stracke |http://www.ecal.com|My opinions are my own.| |Chief Scientist |===========================================| |eCal Corp. |I'm a .sig virus...and, boy, am I tired! | |francis@ecal.com| | \============================================================/ From w3c-dist-auth-request@w3.org Fri Sep 10 12:07: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 MAA13228 for ; Fri, 10 Sep 1999 12:07:24 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id LAA14644; Fri, 10 Sep 1999 11:52:18 -0400 (EDT) Resent-Date: Fri, 10 Sep 1999 11:52:18 -0400 (EDT) Resent-Message-Id: <199909101552.LAA14644@www19.w3.org> From: Daniel LaLiberte Message-ID: <14297.10533.600688.467026@alceste.w3.org> Date: Fri, 10 Sep 1999 11:52:05 -0400 (EDT) To: John Stracke Cc: w3c-dist-auth@w3.org In-Reply-To: <37D920D6.97091D9D@ecal.com> References: <078292D50C98D2118D090008C7E9C6A603C965AF@STAY.platinum.corp.microsoft.com> <37D920D6.97091D9D@ecal.com> X-Mailer: VM 6.67 under 20.4 "Emerald" XEmacs Lucid Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Subject: Re: Bindings, Locks, and MOVE Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3272 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list John Stracke writes: > Disturbing thought from the peanut gallery: cross-host MOVE (i.e., > between two URLs with different hostnames) is not necessarily > cross-server, because they could be hosted on the same machine. So, > sometimes, something that looks like a cross-server MOVE may work. > But usually it won't. And, in some cases, a user may find it works > for a while and then stops, when his admin splits the server up. Or > vice versa. Fun, no? :-) Conversely, something that looks like a same-server MOVE may work (if it works at all) in a way that is functionally indistinguishable from a cross-server MOVE. This can happen if the move is across internal boundaries that require a copy, such as across file system boundaries, or from a database to a file system. No public protocol is needed to support this internal move, however. -- Daniel LaLiberte liberte@w3.org From w3c-dist-auth-request@w3.org Fri Sep 10 12:52: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 MAA15389 for ; Fri, 10 Sep 1999 12:52:10 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id MAA15726; Fri, 10 Sep 1999 12:41:02 -0400 (EDT) Resent-Date: Fri, 10 Sep 1999 12:41:02 -0400 (EDT) Resent-Message-Id: <199909101641.MAA15726@www19.w3.org> From: jamsden@us.ibm.com X-Lotus-FromDomain: IBMUS To: w3c-dist-auth@w3.org Message-ID: <852567E8.005B9DCB.00@d54mta03.raleigh.ibm.com> Date: Fri, 10 Sep 1999 12:36:50 -0400 Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Subject: Re: Bindings, Locks, and MOVE Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3273 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list Do we think clients should be able to effect a cross server "move" with GET, PROPFIND/PUT, PROPPATCH/DELETE? Seems like a minimal requirement for authoring and publishing. If so, then wouldn't we like the server's MOVE to just something similar in a single method to reduce network traffic and client complexity? Are we making MOVE way too complicated, full of special cases, etc. I continue to believe that any method whose semantics require a list of if-then-else's is missing some underlying fundamental principal, will be difficult to implement, difficult to test, introduce interoperability problems, and will be hard for clients to use. Move with locks and references seems to have crossed the line. John Stracke on 09/10/99 11:16:38 AM To: w3c-dist-auth@w3.org cc: Subject: Re: Bindings, Locks, and MOVE "Yaron Goland (Exchange)" wrote: > If you wish to do cross-server > MOVEs you will need a new protocol because WebDAV can't do it. Disturbing thought from the peanut gallery: cross-host MOVE (i.e., between two URLs with different hostnames) is not necessarily cross-server, because they could be hosted on the same machine. So, sometimes, something that looks like a cross-server MOVE may work. But usually it won't. And, in some cases, a user may find it works for a while and then stops, when his admin splits the server up. Or vice versa. Fun, no? :-) -- /============================================================\ |John Stracke |http://www.ecal.com|My opinions are my own.| |Chief Scientist |===========================================| |eCal Corp. |I'm a .sig virus...and, boy, am I tired! | |francis@ecal.com| | \============================================================/ From w3c-dist-auth-request@w3.org Fri Sep 10 14:02:54 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 OAA18636 for ; Fri, 10 Sep 1999 14:02:54 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id NAA17158; Fri, 10 Sep 1999 13:47:53 -0400 (EDT) Resent-Date: Fri, 10 Sep 1999 13:47:53 -0400 (EDT) Resent-Message-Id: <199909101747.NAA17158@www19.w3.org> From: ccjason@us.ibm.com X-Lotus-FromDomain: IBMUS To: "Geoffrey M. Clemm" cc: yarong@Exchange.Microsoft.com, w3c-dist-auth@w3.org Message-ID: <852567E8.0061BA87.00@D51MTA07.pok.ibm.com> Date: Fri, 10 Sep 1999 13:54:57 -0400 Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Subject: Crossserver ops and lock token swapping. Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3274 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, I'm tending to agree with you (and Yaron) that cross server moves shouldn't be a special case in the protocol. No lock token swapping for example. Here's a bit of verbage the issue of lock token swapping.... BTW, before I get to the verbage, I just want to say that even if we agree that cross server isn't a special case, I'd kind of like the spec to mention cross server operations... Just to say that various URI's *CAN* include the host name for example would be an example of what we can say to remind the reader of the cross server compatibility. I just want to bring attention to the fact that WebDAV should be cross server compatible and to remind us that we shouldn't really add anything that prevents this. Now the verbage... I'd like to propose that moving a lock across servers not change the lock token for a lock on that moved resource.. The reason I say this is because we are claiming in the proposal that locks are on resources... not bindings or URI's. Well, a MOVE operation is basically just a rebinding and in that sense, the resource itself has not moved. MOVE just changes some of the URI's at which resources are accessable. In this case the resource(s) is now accessable via a URI on another server. (Note: It may still be accessable at the source server via another URI.) In order to achieve this, we implicitly require (except for special cases) that server pairs cooperate on bindings... and therefore locks since a locked resource can be accessed via a URI on either machine. An argument against what I've just said is... what if someone wants to move a resource (or tree) between servers. And neither server really supports bindings. (Is server support for multiple bindings to a resource a MUST?) These are really simple servers with simple mappings. One mapping per resource. But one wants to move resources between these servers. Nothing fancy. Just move them. Can we actually expect unsophisticated servers to actually support locks generated by other servers? So this suggests... 1) MOVE does not move locks from source to destination in any sense. (But this breaks model of resource is what is locked.) or 2) We let the destination reassign lock tokens. (Is this situation important enough to take this approach and complicate the spec? And wouldn't they still face authentication issues?) or 3) MOVE wouldn't be allowed between these these servers. The client would have to use DELETE/COPY/DELETE. (Keeps protocol simple. Probably is good enough for those with cheap servers.) Thoughts? Further thoughts on cross server. As some have pointed out, right now the spec is nowhere near close enough to actually enable two independently developed servers to do cross server operations besides possibly COPY. Things like cooperative authentication and lock and binding protocols are are needed. And we need to specify that lock tokens be standardized. (We might want to address this now rather than retrofit this later.) (Judith pointed this out.) So are we agree'ing that WebDAV is to be cross server friendly/compatible... but not enabling? (Is that what Yaron was trying to say? :-)) J. ------------------------------------------ Phone: 914-784-7569, ccjason@us.ibm.com From w3c-dist-auth-request@w3.org Fri Sep 10 14:06: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 OAA18829 for ; Fri, 10 Sep 1999 14:06:05 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id NAA17408; Fri, 10 Sep 1999 13:52:21 -0400 (EDT) Resent-Date: Fri, 10 Sep 1999 13:52:21 -0400 (EDT) Resent-Message-Id: <199909101752.NAA17408@www19.w3.org> Message-ID: <078292D50C98D2118D090008C7E9C6A603C965CE@STAY.platinum.corp.microsoft.com> From: "Yaron Goland (Exchange)" To: "'jamsden@us.ibm.com'" Cc: w3c-dist-auth@w3.org Date: Fri, 10 Sep 1999 10:51:46 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Subject: RE: Bindings, Locks, and MOVE Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3275 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list To quote from section 8.9 of RFC 2518: The MOVE operation on a non-collection resource is the logical equivalent of a copy (COPY), followed by consistency maintenance processing, followed by a delete of the source, where all three actions are performed atomically. MOVE is not a best effort operation. It is an atomic operation which can conceptually be broken into several steps. However the user is guaranteed that all the steps occur or none of them occur. An example may help here: T0 - User sends in a MOVE from server a to server b T1 - Server a issues a PUT onto server b T2 - Server a issues a PROPPATCH onto server b T3 - Network connection between a & b goes down T4 - User accesses server a and b and finds both servers contain a copy of the resource! There are also a lot of implicit state in a resource that a PUT/PROPPATCH won't necessarily copy over. For example, I would expect the creation date at the destination to be the same as at the source. If you use a PUT/PROPPATCH/DELETE to implement MOVE then you are almost certainly not compliant with WebDAV. In practice this may not matter. I can imagine any number of systems where this hack may be useful. But it has no place in a standard. Yaron > -----Original Message----- > From: jamsden@us.ibm.com [mailto:jamsden@us.ibm.com] > Sent: Thursday, September 09, 1999 6:26 AM > To: Yaron Goland (Exchange) > Cc: w3c-dist-auth@w3.org > Subject: RE: Bindings, Locks, and MOVE > > > > > Yaron, > I guess I don't see the issue. See comments below. > > > > > > "Yaron Goland (Exchange)" on > 09/08/99 08:41:47 > PM > > To: Jim Amsden/Raleigh/IBM@IBMUS, w3c-dist-auth@w3.org > cc: > > Subject: RE: Bindings, Locks, and MOVE > > > > > Sigh... every day, in every way, I wish like hell I had never > written that > damn "COPY followed by a DELETE" language. > > A server CAN NOT implement a cross server MOVE as a WebDAV COPY method > followed by a WebDAV DELETE method. The reason that this > isn't possible is > that the MOVE requires atomic behavior and it requires that > the resource at > the destination be the exact same resource (within reason) as > at the source. > Therefore, for a cross server MOVE to be possible between two > unrelated > servers a new protocol would have to be invented which could > guarantee the > WebDAV semantics. > > A WebDAV MOVE is a best effort operation, so it would seem > that this is > consistent with non-atomic operation (which might miss > resources that were added > or changed after the move began). DAV4J does the MOVE as an > atomic operation > whether its from a client of another server acting as a > client, so it wouldn't > have this problem anyway. As far as having the destination be > exactly the same > as the source, I don't know what "within reason" means. If it > means has the same > GUID, or is effectively a new reference to the same resource in some > server-dependent way, then no, I can't probably do that. > DAV4J makes a new > resource at the destination that has the same contents as the > source, but not > necessarily the same character encoding, and the same > properties if possible. > The only issue is conversion between live and dead properties > when the servers > involved support different sets (a potential interoperability > problem). > > It seems this is at least a useful interpretation of the spec. > > In the WebDAV charter you will find the following entry in the list of > things not in scope for WebDAV: > > *HTTP server to server communication protocols > > The reason this line was put in the charter was that in the > beginning a lot > of folks wanted to enable server to server communication so > it would be > possible to do things like cross-server MOVEs. WebDAV decided to focus > solely on the issue of client/server communication and thus ruled > server/server communication out of scope. If you wish to do > cross-server > MOVEs you will need a new protocol because WebDAV can't do it. > > Yaron > > P.S. Stop laughing Jeff! =) > > > -----Original Message----- > > From: jamsden@us.ibm.com [mailto:jamsden@us.ibm.com] > > Sent: Wednesday, September 08, 1999 8:12 AM > > To: w3c-dist-auth@w3.org > > Subject: RE: Bindings, Locks, and MOVE > > > > > > > > > > The WebDAV spec says that locks are lost on MOVE. So if the > > source resource is > > locked, then the MOVE request must include the lock token, > > and the lock must be > > owned by the requesting principal. Otherwise the delete > > portion of the move will > > fail. Since MOVE is a best effort method, the copy to the > > destination will work, > > even if the source can't be deleted. As is the case with > > COPY, the lock on the > > destination resource is determined by its new parent > > collection, not by any lock > > state it may have had. This could be taken to mean that the > > new resource is not > > the same resource moved to a new location, but a different resource. > > > > > > > > > > > > "Slein, Judith A" on 09/08/99 09:34:03 AM > > > > To: "'Yaron Goland (Exchange)'" , > > w3c-dist-auth@w3.org > > cc: > > > > Subject: RE: Bindings, Locks, and MOVE > > > > > > > > > > The intention is that if a resource is copied or moved into a > > tree that is > > locked, the lock on the tree remains in force. > > > > We didn't discuss the case where you are doing a MOVE, and > > the resource > > being moved is locked, and it is being moved into a > collection that is > > locked. The lock on the collection will certainly stay in > > force, but we > > need to decide whether the lock on the resource being MOVEd > > will be lost or > > whether the MOVE will fail. I guess my own opinion is that > > the MOVE should > > fail, since that maintains a consistent position that the > > state of a MOVEd > > resource should be unaffected by the move; if its lock state > > would have to > > be changed, the move should fail. > > > > Judith A. Slein > > XR&T/Xerox Architecture Center > > jslein@crt.xerox.com > > 8*222-5169 > > > > > > > -----Original Message----- > > > From: Yaron Goland (Exchange) > [mailto:yarong@Exchange.Microsoft.com] > > > Sent: Tuesday, September 07, 1999 8:49 PM > > > To: 'Slein, Judith A'; 'Greg Stein'; w3c-dist-auth@w3.org > > > Subject: RE: Bindings, Locks, and MOVE > > > > > > > > > Phew!!! I couldn't believe what I was reading regarding write > > > locks. What > > > use is a write lock that only sometimes is a write lock? > > > Yikes. I'm glad > > > that is dead. > > > > > > However there is still a point in the original post that > > > concerns me. Let's > > > see if I understand the proposal: > > > > > > When copying a resource into a tree that is currently locked > > > then the lock > > > on that tree is lost? > > > > > > Is that the proposal for how to handle locks at the > > > destination of a copied > > > resource? That is my reading of the paragraph Judy provided. > > > > > > Yaron > > > > > > > -----Original Message----- > > > > From: Slein, Judith A [mailto:JSlein@crt.xerox.com] > > > > Sent: Tue, September 07, 1999 7:19 AM > > > > To: 'Greg Stein'; w3c-dist-auth@w3.org > > > > Subject: RE: Bindings, Locks, and MOVE > > > > > > > > > > > > Thanks for bringing the discussion back to earth. > > > > > > > > I agree with you that the compromise of saying that servers > > > > SHOULD protect > > > > the path of the Request-URI used in locking a resource is a > > > > poor one. It > > > > doesn't respond to the issue that was raised, and it > > > > needlessly muddies the > > > > waters for clients, which now don't know whether the path > > > > will be protected > > > > or not. > > > > > > > > I like your suggestion that we keep the MUST language, but > > > > state that it > > > > applies only to write locks. > > > > > > > > --Judy > > > > > > > > > > > > > -----Original Message----- > > > > > From: Greg Stein [mailto:gstein@lyra.org] > > > > > Sent: Friday, September 03, 1999 3:24 AM > > > > > To: w3c-dist-auth@w3.org > > > > > Subject: Re: Bindings, Locks, and MOVE > > > > > > > > > > > > > > > This whole thread (post-Judy's message) seems to be picking > > > > out a very > > > > > minor detail of her post. Personally, I find this nit-picking > > > > > of detail > > > > > counter to the goal of her original post: "test its > > > > > conclusions with the > > > > > mailing list members." > > > > > > > > > > For myself (and mod_dav), the first "AGREED" portion > > > makes complete > > > > > sense, and I do agree with it. > > > > > [btw, is *anybody* going to be implementing cross-server > > > > MOVE/COPY? is > > > > > it necessary to have that feature in the spec at all? of the > > > > > umpteen DAV > > > > > servers out there now, I don't know any that do this or plan > > > > > to do this. > > > > > It would be nice to cut the thing and not worry about it.] > > > > > > > > > > The second "AGREED" portion does not make a whole lot of > > > sense. The > > > > > commentary states that the position is too strong [because it > > > > > might not > > > > > make sense with other types of locks]. Are there other locks > > > > > out there? > > > > > Do people have concrete, useful examples? I haven't heard > > > > of anything > > > > > besides a write-lock yet. Regardless, I think it should be > > > > enforced in > > > > > the spec that a write-lock MUST have guaranteed > > protection of the > > > > > Request-URI. Put in some language that says other locks can > > > > define the > > > > > MUST/SHOULD nature of protection. Otherwise, leave it in > > > > the intuitive > > > > > state: a write lock says that others cannot monkey with > > your URI. > > > > > > > > > > Cheers, > > > > > -g > > > > > > > > > > Edgar Schwarz wrote: > > > > > > > > > > > > On Thu, 2 Sep 1999, Geoffrey M. Clemm wrote: > > > > > > > > > > > > > From: ccjason@us.ibm.com > > > > > > > > > > > > > > > > > > > > > This discussion began with Yaron's comment that saying > > > > > that "it MUST NOT be > > > > > > > possible for a principal other than the lock owner to > > > > > make a locked resource > > > > > > > inaccessible via the URI mapping used to lock the > > > > > resource" is too strong. > > > > > > > It may make sense for write locks as defined in RFC > > > > > 2518, but may not make > > > > > > > sense for other sorts of locks that don't restrict > > > > > MOVE and DELETE. > > > > > > > > > > > > > > > > > > > > > I believe that this is not specific to any particular > > > > > type of locks. All > > > > > > > clients need to insure that they have at the very > > > > > least a way to unlock > > > > > > > the the locks they have created. I assume that to > > > > > unlock (a resource), we > > > > > > > have to provide a URI of a (the?) resource locked by > > > > > that lock... so if > > > > > > > someone else changes the URI, it's > > > > > > > very likely that we're not going to be able to figure > > > > > out what the new > > > > > > > URI is... and will have to leave the lock around until > > > > > it times out. > > > > > > > > > > > > > > Since the server needs to deal with this in case > > > > > the client just > > > > > > > neglects to remove the lock, and if having another client > > > > > MOVE your > > > > > > > locked resource is a rare occurrence (which I believe > > > > it is), then > > > > > > > this does not seem to be especially problematical. > > > > > > Would it be possible to say: > > > > > > If a locked resource is moved the server SHOULD create > > > > a indirect > > > > > > reference resource which should exist for some > > sensible time. > > > > > > > > > > > > Yes I know, it's complicating the server :-) > > > > > > I imagine the above happening perhaps when somebody is > > > > reorganizing > > > > > > a directory structure and deep in the collections > > there are some > > > > > > locked resources. > > > > > > So the lock owner at least has a decent chance to find > > > > out where his > > > > > > resource has gone to. > > > > > > > > > > > > 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. > > > > > > > > > > -- > > > > > Greg Stein, http://www.lyra.org/ > > > > > > > > > > > > > > > > > > > > > > > From w3c-dist-auth-request@w3.org Fri Sep 10 14:09: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 OAA18955 for ; Fri, 10 Sep 1999 14:09:07 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id NAA17496; Fri, 10 Sep 1999 13:55:55 -0400 (EDT) Resent-Date: Fri, 10 Sep 1999 13:55:55 -0400 (EDT) Resent-Message-Id: <199909101755.NAA17496@www19.w3.org> Message-ID: <078292D50C98D2118D090008C7E9C6A603C965CF@STAY.platinum.corp.microsoft.com> From: "Yaron Goland (Exchange)" To: "'Slein, Judith A'" , "'jamsden@us.ibm.com'" , w3c-dist-auth@w3.org Date: Fri, 10 Sep 1999 10:55:42 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Bindings, Locks, and MOVE Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3276 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list Lock tokens are universally unique therefore unless a server has made the really silly mistake of encoding useful information in the lock token it should be able to use the existing token. In general, any time you feel the need to specify cross-server behavior you can be absolutely sure that the base standard has a design mistake. Yaron > -----Original Message----- > From: Slein, Judith A [mailto:JSlein@crt.xerox.com] > Sent: Thursday, September 09, 1999 8:11 AM > To: Yaron Goland (Exchange); Slein, Judith A; 'jamsden@us.ibm.com'; > w3c-dist-auth@w3.org > Subject: RE: Bindings, Locks, and MOVE > > > Wait, I think we need to go back to the original proposals > from the design > team. There are a lot of separate points there, and SHOULD > only applied to > one of them (not the one about whether locks survive a MOVE). > > Here they are again, just for reference: > > AGREED: > For MOVE, if the source resource is locked (the lock is not > inherited from > a parent collection), the lock moves with it to the > destination. (This is a > reversal of the position taken in RFC 2518.) If the > destination resource > is locked (the lock is not inherited from a parent > collection), its lock is > lost. > For MOVE, if it's the parent collections that are locked, the resource > being moved inherits the lock of the destination collection. > If a collection is MOVEd, and there are some locked resources in that > collection, the locks on those resources get moved. > We don't require support for cross-server MOVEs where the > source resource > is locked, but we will define an optional lock header for use in > responses, so that the destination server can change the lock > token and > return the new token with its response. If the server allows a cross- > server MOVE but elects not to return a lock token value, the client > can do lock discovery to find it out. > If a cross-server MOVE is allowed in a case where there are multiple > bindings to the source resource, and the source resource is > locked, the > result will be that the resource is locked on both servers > with the same > lock token in both places. (If the same lock token cannot be > used, the > MOVE must fail.) > For COPY, any locks at the destination are deleted, and no > new locks are > created at the destination. After the COPY, there will be no locks at > the destination except what is inherited from above. > > AGREED: We'll change the language related to protecting the > Request-URI to SHOULD. We intend this to protect the entire path, > including the final segment. This does impact the definition of write > locks in RFC 2518, which will have to change. It's no longer that a > write lock MUST prevent MOVE and DELETE, but that it SHOULD prevent > them. > > I agree with Yaron's rant about SHOULD. I think that > changing the language > to SHOULD on this last point is a bad thing. > > Back to the issue of having locks move when a resource is > MOVEd: The one > case that has been cited of a system that cannot move locks > with a resource > is Windows 95. I assume that it's really all the Microsoft > file systems, > including future plans, that won't be able to comply if we > say that locks > MUST move with their resources. So that's a pretty serious pragmatic > consideration. > > It still would be interesting to hear about other systems > that do locking, > and whether they would be able to comply with the position > stated above. > > Setting aside for a minute the pragmatic considerations and > looking for > technical ones: The only technical reason we have heard for > not having locks > move with the resource is the case of cross-server moves. > Since we didn't > standardize an algorithm for constructing lock tokens, it might not be > possible for the destination server to preserve the lock > token created by > the source server in a cross-server move. We think we can solve this > problem by letting the destination server replace the lock > token with one of > its own, and inform the client of the new lock token. > > --Judy > > > -----Original Message----- > > From: Yaron Goland (Exchange) [mailto:yarong@Exchange.Microsoft.com] > > Sent: Wednesday, September 08, 1999 4:05 PM > > To: 'Slein, Judith A'; 'jamsden@us.ibm.com'; w3c-dist-auth@w3.org > > Subject: RE: Bindings, Locks, and MOVE > > > > > > The reason that locks are lost on MOVEs is that the > > overwhelming majority of > > existing systems can not handle moving locks on MOVEs. We > > could, of course, > > have said locks SHOULD NOT be lost on moves. But this sort of > > language is > > exactly the type of language the destroys interoperability. > > When I write a > > client I am going to write it to either demand that locks > > move properly on > > moves in the average case (with exceptions handled as force > > 10 failures) or > > I'm going to write it to assume that locks never work on MOVE > > and set up my > > UI and APIs appropriately. > > their UI and internal code in order to compensate. > > > > We will be consistent. > > > > We will be uniform. > > > > We will use "MUST." > > > > If you want to change the language to say that locks MUST > > move then we can > > discuss this, although I think preventing the majority of > > existing systems > > in the world from supporting WebDAV is probably a bad idea. > > If you want to > > use the Mandatory mechanism, I think that would be a great > > idea. But the > > requirement absolutely will not be a SHOULD. > > > > Yaron > > > > P.S. Phew... I haven't had a good rant in a while. Feels good. =) > > > From w3c-dist-auth-request@w3.org Fri Sep 10 16: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 QAA21994 for ; Fri, 10 Sep 1999 16:00:32 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id PAA20328; Fri, 10 Sep 1999 15:48:49 -0400 (EDT) Resent-Date: Fri, 10 Sep 1999 15:48:49 -0400 (EDT) Resent-Message-Id: <199909101948.PAA20328@www19.w3.org> Message-ID: <078292D50C98D2118D090008C7E9C6A603C965D9@STAY.platinum.corp.microsoft.com> From: "Yaron Goland (Exchange)" To: "'jamsden@us.ibm.com'" , w3c-dist-auth@w3.org Date: Fri, 10 Sep 1999 12:48:15 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Subject: RE: Bindings, Locks, and MOVE Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3277 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list To guarantee that a MOVE will work using a GET/PROPFIND/PUT/PROPPATCH/DELETE or any other sequence of client commands would be to rob servers of their ability to add value, which is clearly a step too far. This is especially the case in circumstances where the resource in question is not a file in disguise but a generic program. That having been said, in many cases the previous sequence would work just fine. Unfortunately it is also slow as all hell but in some cases there is nothing better available. Yaron > -----Original Message----- > From: jamsden@us.ibm.com [mailto:jamsden@us.ibm.com] > Sent: Friday, September 10, 1999 9:37 AM > To: w3c-dist-auth@w3.org > Subject: Re: Bindings, Locks, and MOVE > > > > > Do we think clients should be able to effect a cross server > "move" with GET, > PROPFIND/PUT, PROPPATCH/DELETE? Seems like a minimal > requirement for authoring > and publishing. If so, then wouldn't we like the server's > MOVE to just something > similar in a single method to reduce network traffic and > client complexity? Are > we making MOVE way too complicated, full of special cases, > etc. I continue to > believe that any method whose semantics require a list of > if-then-else's is > missing some underlying fundamental principal, will be > difficult to implement, > difficult to test, introduce interoperability problems, and > will be hard for > clients to use. Move with locks and references seems to have > crossed the line. > > > > > > John Stracke on 09/10/99 11:16:38 AM > > To: w3c-dist-auth@w3.org > cc: > > Subject: Re: Bindings, Locks, and MOVE > > > > > "Yaron Goland (Exchange)" wrote: > > > If you wish to do cross-server > > MOVEs you will need a new protocol because WebDAV can't do it. > > Disturbing thought from the peanut gallery: cross-host MOVE > (i.e., between two > URLs with different hostnames) is not necessarily > cross-server, because they > could be hosted on the same machine. So, sometimes, > something that looks like > a cross-server MOVE may work. But usually it won't. And, in > some cases, a > user may find it works for a while and then stops, when his > admin splits the > server up. Or vice versa. Fun, no? :-) > > -- > /============================================================\ > |John Stracke |http://www.ecal.com|My opinions are my own.| > |Chief Scientist |===========================================| > |eCal Corp. |I'm a .sig virus...and, boy, am I tired! | > |francis@ecal.com| | > \============================================================/ > > > > > > From w3c-dist-auth-request@w3.org Fri Sep 10 16:35: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 QAA22469 for ; Fri, 10 Sep 1999 16:35:31 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id QAA21103; Fri, 10 Sep 1999 16:23:57 -0400 (EDT) Resent-Date: Fri, 10 Sep 1999 16:23:57 -0400 (EDT) Resent-Message-Id: <199909102023.QAA21103@www19.w3.org> From: jamsden@us.ibm.com X-Lotus-FromDomain: IBMUS To: w3c-dist-auth@w3.org Message-ID: <852567E8.0070009E.00@d54mta03.raleigh.ibm.com> Date: Fri, 10 Sep 1999 16:21:25 -0400 Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Subject: RE: Bindings, Locks, and MOVE Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3278 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list By best effort, I was refering to section 8.8.3 which states that "... the server SHOULD try to finish as much of the original copy operation as posible." In this spirit, failure of the delete and the results in step T4 seem to be consistent. "Yaron Goland (Exchange)" on 09/10/99 01:51:46 PM To: Jim Amsden/Raleigh/IBM@IBMUS cc: w3c-dist-auth@w3.org Subject: RE: Bindings, Locks, and MOVE To quote from section 8.9 of RFC 2518: The MOVE operation on a non-collection resource is the logical equivalent of a copy (COPY), followed by consistency maintenance processing, followed by a delete of the source, where all three actions are performed atomically. MOVE is not a best effort operation. It is an atomic operation which can conceptually be broken into several steps. However the user is guaranteed that all the steps occur or none of them occur. An example may help here: T0 - User sends in a MOVE from server a to server b T1 - Server a issues a PUT onto server b T2 - Server a issues a PROPPATCH onto server b T3 - Network connection between a & b goes down T4 - User accesses server a and b and finds both servers contain a copy of the resource! There are also a lot of implicit state in a resource that a PUT/PROPPATCH won't necessarily copy over. For example, I would expect the creation date at the destination to be the same as at the source. If you use a PUT/PROPPATCH/DELETE to implement MOVE then you are almost certainly not compliant with WebDAV. In practice this may not matter. I can imagine any number of systems where this hack may be useful. But it has no place in a standard. Yaron > -----Original Message----- > From: jamsden@us.ibm.com [mailto:jamsden@us.ibm.com] > Sent: Thursday, September 09, 1999 6:26 AM > To: Yaron Goland (Exchange) > Cc: w3c-dist-auth@w3.org > Subject: RE: Bindings, Locks, and MOVE > > > > > Yaron, > I guess I don't see the issue. See comments below. > > > > > > "Yaron Goland (Exchange)" on > 09/08/99 08:41:47 > PM > > To: Jim Amsden/Raleigh/IBM@IBMUS, w3c-dist-auth@w3.org > cc: > > Subject: RE: Bindings, Locks, and MOVE > > > > > Sigh... every day, in every way, I wish like hell I had never > written that > damn "COPY followed by a DELETE" language. > > A server CAN NOT implement a cross server MOVE as a WebDAV COPY method > followed by a WebDAV DELETE method. The reason that this > isn't possible is > that the MOVE requires atomic behavior and it requires that > the resource at > the destination be the exact same resource (within reason) as > at the source. > Therefore, for a cross server MOVE to be possible between two > unrelated > servers a new protocol would have to be invented which could > guarantee the > WebDAV semantics. > > A WebDAV MOVE is a best effort operation, so it would seem > that this is > consistent with non-atomic operation (which might miss > resources that were added > or changed after the move began). DAV4J does the MOVE as an > atomic operation > whether its from a client of another server acting as a > client, so it wouldn't > have this problem anyway. As far as having the destination be > exactly the same > as the source, I don't know what "within reason" means. If it > means has the same > GUID, or is effectively a new reference to the same resource in some > server-dependent way, then no, I can't probably do that. > DAV4J makes a new > resource at the destination that has the same contents as the > source, but not > necessarily the same character encoding, and the same > properties if possible. > The only issue is conversion between live and dead properties > when the servers > involved support different sets (a potential interoperability > problem). > > It seems this is at least a useful interpretation of the spec. > > In the WebDAV charter you will find the following entry in the list of > things not in scope for WebDAV: > > *HTTP server to server communication protocols > > The reason this line was put in the charter was that in the > beginning a lot > of folks wanted to enable server to server communication so > it would be > possible to do things like cross-server MOVEs. WebDAV decided to focus > solely on the issue of client/server communication and thus ruled > server/server communication out of scope. If you wish to do > cross-server > MOVEs you will need a new protocol because WebDAV can't do it. > > Yaron > > P.S. Stop laughing Jeff! =) > > > -----Original Message----- > > From: jamsden@us.ibm.com [mailto:jamsden@us.ibm.com] > > Sent: Wednesday, September 08, 1999 8:12 AM > > To: w3c-dist-auth@w3.org > > Subject: RE: Bindings, Locks, and MOVE > > > > > > > > > > The WebDAV spec says that locks are lost on MOVE. So if the > > source resource is > > locked, then the MOVE request must include the lock token, > > and the lock must be > > owned by the requesting principal. Otherwise the delete > > portion of the move will > > fail. Since MOVE is a best effort method, the copy to the > > destination will work, > > even if the source can't be deleted. As is the case with > > COPY, the lock on the > > destination resource is determined by its new parent > > collection, not by any lock > > state it may have had. This could be taken to mean that the > > new resource is not > > the same resource moved to a new location, but a different resource. > > > > > > > > > > > > "Slein, Judith A" on 09/08/99 09:34:03 AM > > > > To: "'Yaron Goland (Exchange)'" , > > w3c-dist-auth@w3.org > > cc: > > > > Subject: RE: Bindings, Locks, and MOVE > > > > > > > > > > The intention is that if a resource is copied or moved into a > > tree that is > > locked, the lock on the tree remains in force. > > > > We didn't discuss the case where you are doing a MOVE, and > > the resource > > being moved is locked, and it is being moved into a > collection that is > > locked. The lock on the collection will certainly stay in > > force, but we > > need to decide whether the lock on the resource being MOVEd > > will be lost or > > whether the MOVE will fail. I guess my own opinion is that > > the MOVE should > > fail, since that maintains a consistent position that the > > state of a MOVEd > > resource should be unaffected by the move; if its lock state > > would have to > > be changed, the move should fail. > > > > Judith A. Slein > > XR&T/Xerox Architecture Center > > jslein@crt.xerox.com > > 8*222-5169 > > > > > > > -----Original Message----- > > > From: Yaron Goland (Exchange) > [mailto:yarong@Exchange.Microsoft.com] > > > Sent: Tuesday, September 07, 1999 8:49 PM > > > To: 'Slein, Judith A'; 'Greg Stein'; w3c-dist-auth@w3.org > > > Subject: RE: Bindings, Locks, and MOVE > > > > > > > > > Phew!!! I couldn't believe what I was reading regarding write > > > locks. What > > > use is a write lock that only sometimes is a write lock? > > > Yikes. I'm glad > > > that is dead. > > > > > > However there is still a point in the original post that > > > concerns me. Let's > > > see if I understand the proposal: > > > > > > When copying a resource into a tree that is currently locked > > > then the lock > > > on that tree is lost? > > > > > > Is that the proposal for how to handle locks at the > > > destination of a copied > > > resource? That is my reading of the paragraph Judy provided. > > > > > > Yaron > > > > > > > -----Original Message----- > > > > From: Slein, Judith A [mailto:JSlein@crt.xerox.com] > > > > Sent: Tue, September 07, 1999 7:19 AM > > > > To: 'Greg Stein'; w3c-dist-auth@w3.org > > > > Subject: RE: Bindings, Locks, and MOVE > > > > > > > > > > > > Thanks for bringing the discussion back to earth. > > > > > > > > I agree with you that the compromise of saying that servers > > > > SHOULD protect > > > > the path of the Request-URI used in locking a resource is a > > > > poor one. It > > > > doesn't respond to the issue that was raised, and it > > > > needlessly muddies the > > > > waters for clients, which now don't know whether the path > > > > will be protected > > > > or not. > > > > > > > > I like your suggestion that we keep the MUST language, but > > > > state that it > > > > applies only to write locks. > > > > > > > > --Judy > > > > > > > > > > > > > -----Original Message----- > > > > > From: Greg Stein [mailto:gstein@lyra.org] > > > > > Sent: Friday, September 03, 1999 3:24 AM > > > > > To: w3c-dist-auth@w3.org > > > > > Subject: Re: Bindings, Locks, and MOVE > > > > > > > > > > > > > > > This whole thread (post-Judy's message) seems to be picking > > > > out a very > > > > > minor detail of her post. Personally, I find this nit-picking > > > > > of detail > > > > > counter to the goal of her original post: "test its > > > > > conclusions with the > > > > > mailing list members." > > > > > > > > > > For myself (and mod_dav), the first "AGREED" portion > > > makes complete > > > > > sense, and I do agree with it. > > > > > [btw, is *anybody* going to be implementing cross-server > > > > MOVE/COPY? is > > > > > it necessary to have that feature in the spec at all? of the > > > > > umpteen DAV > > > > > servers out there now, I don't know any that do this or plan > > > > > to do this. > > > > > It would be nice to cut the thing and not worry about it.] > > > > > > > > > > The second "AGREED" portion does not make a whole lot of > > > sense. The > > > > > commentary states that the position is too strong [because it > > > > > might not > > > > > make sense with other types of locks]. Are there other locks > > > > > out there? > > > > > Do people have concrete, useful examples? I haven't heard > > > > of anything > > > > > besides a write-lock yet. Regardless, I think it should be > > > > enforced in > > > > > the spec that a write-lock MUST have guaranteed > > protection of the > > > > > Request-URI. Put in some language that says other locks can > > > > define the > > > > > MUST/SHOULD nature of protection. Otherwise, leave it in > > > > the intuitive > > > > > state: a write lock says that others cannot monkey with > > your URI. > > > > > > > > > > Cheers, > > > > > -g > > > > > > > > > > Edgar Schwarz wrote: > > > > > > > > > > > > On Thu, 2 Sep 1999, Geoffrey M. Clemm wrote: > > > > > > > > > > > > > From: ccjason@us.ibm.com > > > > > > > > > > > > > > > > > > > > > This discussion began with Yaron's comment that saying > > > > > that "it MUST NOT be > > > > > > > possible for a principal other than the lock owner to > > > > > make a locked resource > > > > > > > inaccessible via the URI mapping used to lock the > > > > > resource" is too strong. > > > > > > > It may make sense for write locks as defined in RFC > > > > > 2518, but may not make > > > > > > > sense for other sorts of locks that don't restrict > > > > > MOVE and DELETE. > > > > > > > > > > > > > > > > > > > > > I believe that this is not specific to any particular > > > > > type of locks. All > > > > > > > clients need to insure that they have at the very > > > > > least a way to unlock > > > > > > > the the locks they have created. I assume that to > > > > > unlock (a resource), we > > > > > > > have to provide a URI of a (the?) resource locked by > > > > > that lock... so if > > > > > > > someone else changes the URI, it's > > > > > > > very likely that we're not going to be able to figure > > > > > out what the new > > > > > > > URI is... and will have to leave the lock around until > > > > > it times out. > > > > > > > > > > > > > > Since the server needs to deal with this in case > > > > > the client just > > > > > > > neglects to remove the lock, and if having another client > > > > > MOVE your > > > > > > > locked resource is a rare occurrence (which I believe > > > > it is), then > > > > > > > this does not seem to be especially problematical. > > > > > > Would it be possible to say: > > > > > > If a locked resource is moved the server SHOULD create > > > > a indirect > > > > > > reference resource which should exist for some > > sensible time. > > > > > > > > > > > > Yes I know, it's complicating the server :-) > > > > > > I imagine the above happening perhaps when somebody is > > > > reorganizing > > > > > > a directory structure and deep in the collections > > there are some > > > > > > locked resources. > > > > > > So the lock owner at least has a decent chance to find > > > > out where his > > > > > > resource has gone to. > > > > > > > > > > > > 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. > > > > > > > > > > -- > > > > > Greg Stein, http://www.lyra.org/ > > > > > > > > > > > > > > > > > > > > > > > From w3c-dist-auth-request@w3.org Fri Sep 10 17:02: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 RAA23037 for ; Fri, 10 Sep 1999 17:02:12 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id QAA21780; Fri, 10 Sep 1999 16:48:40 -0400 (EDT) Resent-Date: Fri, 10 Sep 1999 16:48:40 -0400 (EDT) Resent-Message-Id: <199909102048.QAA21780@www19.w3.org> Message-ID: <37D96C8C.79C278B1@lyra.org> Date: Fri, 10 Sep 1999 13:39:40 -0700 From: Greg Stein X-Mailer: Mozilla 3.01 (X11; I; Linux 2.0.28 i586) MIME-Version: 1.0 To: dav References: <078292D50C98D2118D090008C7E9C6A603C965D9@STAY.platinum.corp.microsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: Bindings, Locks, and MOVE Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3279 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 Yaron Goland (Exchange) wrote: > > To guarantee that a MOVE will work using a GET/PROPFIND/PUT/PROPPATCH/DELETE > or any other sequence of client commands would be to rob servers of their > ability to add value, which is clearly a step too far. This is especially > the case in circumstances where the resource in question is not a file in > disguise but a generic program. > > That having been said, in many cases the previous sequence would work just > fine. Unfortunately it is also slow as all hell but in some cases there is > nothing better available. I certainly won't be building any client-side HTTP code into mod_dav. If the MOVE can't be done within the server, then it will fail. Period. I fully agree with the part of the charter than Yaron pointed out: server-server communication is NOT in scope. There are enough things to do without worrying about this. Jim's server happens to be able to do cross-server moves because it is a blended client/server package. I would still like to know if *any* other server-side only packages are actually *intending* to support any kind of cross-server functionality. If not, then take Geoff's stance: allow a MOVE to fail with a "Bad Gateway" at any time. There. Enough said in the spec. Let's move on. Cheers, -g -- Greg Stein, http://www.lyra.org/ From w3c-dist-auth-request@w3.org Fri Sep 10 17:12: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 RAA23271 for ; Fri, 10 Sep 1999 17:12:03 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id RAA22312; Fri, 10 Sep 1999 17:02:00 -0400 (EDT) Resent-Date: Fri, 10 Sep 1999 17:02:00 -0400 (EDT) Resent-Message-Id: <199909102102.RAA22312@www19.w3.org> Message-ID: <37D96D48.2B5B6455@lyra.org> Date: Fri, 10 Sep 1999 13:42:48 -0700 From: Greg Stein X-Mailer: Mozilla 3.01 (X11; I; Linux 2.0.28 i586) MIME-Version: 1.0 To: "Yaron Goland (Exchange)" CC: w3c-dist-auth@w3.org References: <078292D50C98D2118D090008C7E9C6A603C965CF@STAY.platinum.corp.microsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: Bindings, Locks, and MOVE Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3280 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 Yaron Goland (Exchange) wrote: > > Lock tokens are universally unique therefore unless a server has made the > really silly mistake of encoding useful information in the lock token it > should be able to use the existing token. Why is this a silly mistake? I haven't done this, but would certainly like to. I don't see a problem with this at all. -g -- Greg Stein, http://www.lyra.org/ From w3c-dist-auth-request@w3.org Fri Sep 10 18:02: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 SAA23925 for ; Fri, 10 Sep 1999 18:02:57 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id RAA23371; Fri, 10 Sep 1999 17:53:20 -0400 (EDT) Resent-Date: Fri, 10 Sep 1999 17:53:20 -0400 (EDT) Resent-Message-Id: <199909102153.RAA23371@www19.w3.org> Message-ID: <37D97BC8.46384D89@lyra.org> Date: Fri, 10 Sep 1999 14:44:40 -0700 From: Greg Stein X-Mailer: Mozilla 3.01 (X11; I; Linux 2.0.28 i586) MIME-Version: 1.0 To: ccjason@us.ibm.com CC: w3c-dist-auth@w3.org References: <852567E8.0061BA87.00@D51MTA07.pok.ibm.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: Crossserver ops and lock token swapping. Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3281 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 ccjason@us.ibm.com wrote: >... > I'd like to propose that moving a lock across servers not change the lock token > for a lock on that moved resource.. The reason I say this is because we are > claiming in the proposal that locks are on resources... not bindings or URI's. This is rather neat philosophically/academically, but from a pragmatic standpoint, I don't think it really holds water. Let's just take a simple example of a resource being moved from a filesystem into a database. The filesystem prefers scheme X to represent the locks. The database prefers Y. Sure, they could both use opaquelocktokens, but they aren't -- they're each using a scheme to optimize their behavior. Now what are you going to do? I say the MOVE allows the lock token to change, or it just isn't going to happen. > Well, a MOVE operation is basically just a rebinding and in that sense, the > resource itself has not moved. MOVE just changes some of the URI's at which > resources are accessable. In this case the resource(s) is now accessable via a Again: neat philosophy. Go implement this and I'll buy it. >... > move them. Can we actually expect unsophisticated servers to actually support > locks generated by other servers? So this suggests... Nope. But that was probably a rhetorical question :-) > 1) MOVE does not move locks from source to destination in any sense. (But > this breaks model of resource is what is locked.) Works for me. [although, as I stated in reply to Judy's initial proposal: I'm also fine with moving the lock. I think it isn't making as much sense (to me) to move it, though. more below] > or > 2) We let the destination reassign lock tokens. (Is this situation important > enough to take this approach and complicate the spec? And wouldn't they still > face authentication issues?) I prefer this option. Why not just allow the MOVE to return a Lock-Token header? The Lock-Token header would specify the lock that the (moved) resources now fall under at the destination. There is an issue, though: what of the old locktoken? Did it get moved (and changed) or did it remain? Hrm. This isn't an issue, though, if we state that it always remains (yes, this is different than Judy's latest proposal; it also follows my suggestion about it remaining and establishing a locknull resource). If the lock remains, then client can always know what happens -- the source lock remains, the resource now falls under the lock specified by the returned Lock-Token. > or > 3) MOVE wouldn't be allowed between these these servers. The client would > have to use > DELETE/COPY/DELETE. (Keeps protocol simple. Probably is good enough for those > with cheap servers.) This is *always* an option. A server can always return Bad Gateway if it chooses not to do a move. > > Thoughts? > > Further thoughts on cross server. As some have pointed out, right now the spec > is nowhere near close enough to actually enable two independently developed > servers to do cross server operations besides possibly COPY. Things like > cooperative authentication and lock and binding protocols are are needed. And > we need to specify that lock tokens be standardized. (We might want to address > this now rather than retrofit this later.) (Judith pointed this out.) So are > we agree'ing that WebDAV is to be cross server friendly/compatible... but not > enabling? (Is that what Yaron was trying to say? :-)) I believe Yaron was trying to say that we should not be considering server-to-server communication. The WebDAV charter explicitly states that this is not in scope. As a result, any portion of the specification that are necessary *only* for server-server communication should be axed. If you can argue a DAV client would use it, then it can stay :-) Cheers, -g -- Greg Stein, http://www.lyra.org/ From w3c-dist-auth-request@w3.org Fri Sep 10 18:06: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 SAA23952 for ; Fri, 10 Sep 1999 18:06:06 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id RAA23476; Fri, 10 Sep 1999 17:56:08 -0400 (EDT) Resent-Date: Fri, 10 Sep 1999 17:56:08 -0400 (EDT) Resent-Message-Id: <199909102156.RAA23476@www19.w3.org> Date: Fri, 10 Sep 1999 14:56:20 -0700 Message-Id: <3887-Fri10Sep1999145620-0700-bstiles@starbase.com> X-Mailer: emacs 20.3.1 (via feedmail 8 I) From: "Brian Stiles" To: w3c-dist-auth@w3.org Subject: Clarification on MKCOL needed Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3282 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list How can a WebDAV server support MKCOL if the repository the server is built upon assigns names to newly created collections (as opposed to allowing clients to specify the name)? Put another way, how can a client create a collection on a WebDAV server using MKCOL if the collection that gets created must be assigned a URI by the server? For example, suppose that each collection is assigned an ID that is unique to the database that underlies the WebDAV server and this ID is used to identify the collection in a URI (e.g., http://foo.com/121/13/4/). If a client wants to create a new collection, it must issue a MKCOL request to http://foo.com/121/13/4// but because of the fact that the server essentially controls the namespace, not the client, the client can't know what to send for NEW_NAME. Am I missing some important piece of information here? I assume that document management systems might be likely to encounter this kind of problem. If so, has anyone dealt with it? Although it doesn't seem to be explicitly forbidden, I am assuming that it is inappropriate for the server to ignore the name in the request-URI and respond with a Location header that identifies the name assigned by the server. Though this seems like a possible solution, it seems contrary to the intent expressed in the spec. Or am I wrong in this assumption? -- Brian Stiles From w3c-dist-auth-request@w3.org Fri Sep 10 18:08: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 SAA23968 for ; Fri, 10 Sep 1999 18:08:58 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id RAA23635; Fri, 10 Sep 1999 17:59:09 -0400 (EDT) Resent-Date: Fri, 10 Sep 1999 17:59:09 -0400 (EDT) Resent-Message-Id: <199909102159.RAA23635@www19.w3.org> Message-ID: <078292D50C98D2118D090008C7E9C6A603C965DA@STAY.platinum.corp.microsoft.com> From: "Yaron Goland (Exchange)" To: "'jamsden@us.ibm.com'" , w3c-dist-auth@w3.org Date: Fri, 10 Sep 1999 14:58:39 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Subject: RE: Bindings, Locks, and MOVE Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3283 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list You have taken a statement completely out of context. RFC 2518 is not the bible and was most certainly not divinely inspired. As such one must read each statement within the context of the sentence in which it is written, the paragraph in which it is included and the section in which it is stated. The section you are quoting from is 8.8.3 which is titled "COPY for collections" and only applies to the behavior of copy across multiple resources in a collection. However the original point you made was regarding the behavior of a single MOVE method on a single resource. Thus any language in 8.8.3 clearly does not apply. In the case of a single MOVE/COPY method on a single resource the result must be atomic and must be complete success or complete failure where success/failure is defined by the headers included in the request. There is no "best effort" about it. Nothing, anywhere in the spec, abrogates this requirement in the least. "best effort", as defined in 8.8.3, only applies in the singular case when one is copying multiple resources in a single copy command as the result of issuing the copy against a collection. In that singular case it is permissible for some of the copies to succeed and for others to failure. However each individual copy must completely succeed or completely fail. Therefore the language in 8.8.3 explicitly prevents the scenario described in T4 and hence explains why it is impossible to fully replicate the COPY/MOVE behavior using the client originated method sequences previously discussed. Yaron > -----Original Message----- > From: jamsden@us.ibm.com [mailto:jamsden@us.ibm.com] > Sent: Friday, September 10, 1999 1:21 PM > To: w3c-dist-auth@w3.org > Subject: RE: Bindings, Locks, and MOVE > > > > > By best effort, I was refering to section 8.8.3 which states > that "... the > server SHOULD try to finish as much of the original copy > operation as posible." > In this spirit, failure of the delete and the results in step > T4 seem to be > consistent. > > > > > > "Yaron Goland (Exchange)" on > 09/10/99 01:51:46 > PM > > To: Jim Amsden/Raleigh/IBM@IBMUS > cc: w3c-dist-auth@w3.org > > Subject: RE: Bindings, Locks, and MOVE > > > > > To quote from section 8.9 of RFC 2518: > > The MOVE operation on a non-collection resource is the logical > equivalent of a copy (COPY), followed by consistency maintenance > processing, followed by a delete of the source, where all three > actions are performed atomically. > > > MOVE is not a best effort operation. It is an atomic > operation which can > conceptually be broken into several steps. However the user > is guaranteed > that all the steps occur or none of them occur. An example > may help here: > > T0 - User sends in a MOVE from server a to server b > T1 - Server a issues a PUT onto server b > T2 - Server a issues a PROPPATCH onto server b > T3 - Network connection between a & b goes down > T4 - User accesses server a and b and finds both servers > contain a copy of > the resource! > > There are also a lot of implicit state in a resource that a > PUT/PROPPATCH > won't necessarily copy over. For example, I would expect the > creation date > at the destination to be the same as at the source. > > If you use a PUT/PROPPATCH/DELETE to implement MOVE then you > are almost > certainly not compliant with WebDAV. In practice this may not > matter. I can > imagine any number of systems where this hack may be useful. > But it has no > place in a standard. > > Yaron > > > -----Original Message----- > > From: jamsden@us.ibm.com [mailto:jamsden@us.ibm.com] > > Sent: Thursday, September 09, 1999 6:26 AM > > To: Yaron Goland (Exchange) > > Cc: w3c-dist-auth@w3.org > > Subject: RE: Bindings, Locks, and MOVE > > > > > > > > > > Yaron, > > I guess I don't see the issue. See comments below. > > > > > > > > > > > > "Yaron Goland (Exchange)" on > > 09/08/99 08:41:47 > > PM > > > > To: Jim Amsden/Raleigh/IBM@IBMUS, w3c-dist-auth@w3.org > > cc: > > > > Subject: RE: Bindings, Locks, and MOVE > > > > > > > > > > Sigh... every day, in every way, I wish like hell I had never > > written that > > damn "COPY followed by a DELETE" language. > > > > A server CAN NOT implement a cross server MOVE as a WebDAV > COPY method > > followed by a WebDAV DELETE method. The reason that this > > isn't possible is > > that the MOVE requires atomic behavior and it requires that > > the resource at > > the destination be the exact same resource (within reason) as > > at the source. > > Therefore, for a cross server MOVE to be possible between two > > unrelated > > servers a new protocol would have to be invented which could > > guarantee the > > WebDAV semantics. > > > > A WebDAV MOVE is a best effort operation, so it would seem > > that this is > > consistent with non-atomic operation (which might miss > > resources that were added > > or changed after the move began). DAV4J does the MOVE as an > > atomic operation > > whether its from a client of another server acting as a > > client, so it wouldn't > > have this problem anyway. As far as having the destination be > > exactly the same > > as the source, I don't know what "within reason" means. If it > > means has the same > > GUID, or is effectively a new reference to the same resource in some > > server-dependent way, then no, I can't probably do that. > > DAV4J makes a new > > resource at the destination that has the same contents as the > > source, but not > > necessarily the same character encoding, and the same > > properties if possible. > > The only issue is conversion between live and dead properties > > when the servers > > involved support different sets (a potential interoperability > > problem). > > > > It seems this is at least a useful interpretation of the spec. > > > > In the WebDAV charter you will find the following entry in > the list of > > things not in scope for WebDAV: > > > > *HTTP server to server communication protocols > > > > The reason this line was put in the charter was that in the > > beginning a lot > > of folks wanted to enable server to server communication so > > it would be > > possible to do things like cross-server MOVEs. WebDAV > decided to focus > > solely on the issue of client/server communication and thus ruled > > server/server communication out of scope. If you wish to do > > cross-server > > MOVEs you will need a new protocol because WebDAV can't do it. > > > > Yaron > > > > P.S. Stop laughing Jeff! =) > > > > > -----Original Message----- > > > From: jamsden@us.ibm.com [mailto:jamsden@us.ibm.com] > > > Sent: Wednesday, September 08, 1999 8:12 AM > > > To: w3c-dist-auth@w3.org > > > Subject: RE: Bindings, Locks, and MOVE > > > > > > > > > > > > > > > The WebDAV spec says that locks are lost on MOVE. So if the > > > source resource is > > > locked, then the MOVE request must include the lock token, > > > and the lock must be > > > owned by the requesting principal. Otherwise the delete > > > portion of the move will > > > fail. Since MOVE is a best effort method, the copy to the > > > destination will work, > > > even if the source can't be deleted. As is the case with > > > COPY, the lock on the > > > destination resource is determined by its new parent > > > collection, not by any lock > > > state it may have had. This could be taken to mean that the > > > new resource is not > > > the same resource moved to a new location, but a > different resource. > > > > > > > > > > > > > > > > > > "Slein, Judith A" on 09/08/99 09:34:03 AM > > > > > > To: "'Yaron Goland (Exchange)'" , > > > w3c-dist-auth@w3.org > > > cc: > > > > > > Subject: RE: Bindings, Locks, and MOVE > > > > > > > > > > > > > > > The intention is that if a resource is copied or moved into a > > > tree that is > > > locked, the lock on the tree remains in force. > > > > > > We didn't discuss the case where you are doing a MOVE, and > > > the resource > > > being moved is locked, and it is being moved into a > > collection that is > > > locked. The lock on the collection will certainly stay in > > > force, but we > > > need to decide whether the lock on the resource being MOVEd > > > will be lost or > > > whether the MOVE will fail. I guess my own opinion is that > > > the MOVE should > > > fail, since that maintains a consistent position that the > > > state of a MOVEd > > > resource should be unaffected by the move; if its lock state > > > would have to > > > be changed, the move should fail. > > > > > > Judith A. Slein > > > XR&T/Xerox Architecture Center > > > jslein@crt.xerox.com > > > 8*222-5169 > > > > > > > > > > -----Original Message----- > > > > From: Yaron Goland (Exchange) > > [mailto:yarong@Exchange.Microsoft.com] > > > > Sent: Tuesday, September 07, 1999 8:49 PM > > > > To: 'Slein, Judith A'; 'Greg Stein'; w3c-dist-auth@w3.org > > > > Subject: RE: Bindings, Locks, and MOVE > > > > > > > > > > > > Phew!!! I couldn't believe what I was reading regarding write > > > > locks. What > > > > use is a write lock that only sometimes is a write lock? > > > > Yikes. I'm glad > > > > that is dead. > > > > > > > > However there is still a point in the original post that > > > > concerns me. Let's > > > > see if I understand the proposal: > > > > > > > > When copying a resource into a tree that is currently locked > > > > then the lock > > > > on that tree is lost? > > > > > > > > Is that the proposal for how to handle locks at the > > > > destination of a copied > > > > resource? That is my reading of the paragraph Judy provided. > > > > > > > > Yaron > > > > > > > > > -----Original Message----- > > > > > From: Slein, Judith A [mailto:JSlein@crt.xerox.com] > > > > > Sent: Tue, September 07, 1999 7:19 AM > > > > > To: 'Greg Stein'; w3c-dist-auth@w3.org > > > > > Subject: RE: Bindings, Locks, and MOVE > > > > > > > > > > > > > > > Thanks for bringing the discussion back to earth. > > > > > > > > > > I agree with you that the compromise of saying that servers > > > > > SHOULD protect > > > > > the path of the Request-URI used in locking a resource is a > > > > > poor one. It > > > > > doesn't respond to the issue that was raised, and it > > > > > needlessly muddies the > > > > > waters for clients, which now don't know whether the path > > > > > will be protected > > > > > or not. > > > > > > > > > > I like your suggestion that we keep the MUST language, but > > > > > state that it > > > > > applies only to write locks. > > > > > > > > > > --Judy > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > From: Greg Stein [mailto:gstein@lyra.org] > > > > > > Sent: Friday, September 03, 1999 3:24 AM > > > > > > To: w3c-dist-auth@w3.org > > > > > > Subject: Re: Bindings, Locks, and MOVE > > > > > > > > > > > > > > > > > > This whole thread (post-Judy's message) seems to be picking > > > > > out a very > > > > > > minor detail of her post. Personally, I find this > nit-picking > > > > > > of detail > > > > > > counter to the goal of her original post: "test its > > > > > > conclusions with the > > > > > > mailing list members." > > > > > > > > > > > > For myself (and mod_dav), the first "AGREED" portion > > > > makes complete > > > > > > sense, and I do agree with it. > > > > > > [btw, is *anybody* going to be implementing cross-server > > > > > MOVE/COPY? is > > > > > > it necessary to have that feature in the spec at all? of the > > > > > > umpteen DAV > > > > > > servers out there now, I don't know any that do this or plan > > > > > > to do this. > > > > > > It would be nice to cut the thing and not worry about it.] > > > > > > > > > > > > The second "AGREED" portion does not make a whole lot of > > > > sense. The > > > > > > commentary states that the position is too strong > [because it > > > > > > might not > > > > > > make sense with other types of locks]. Are there other locks > > > > > > out there? > > > > > > Do people have concrete, useful examples? I haven't heard > > > > > of anything > > > > > > besides a write-lock yet. Regardless, I think it should be > > > > > enforced in > > > > > > the spec that a write-lock MUST have guaranteed > > > protection of the > > > > > > Request-URI. Put in some language that says other locks can > > > > > define the > > > > > > MUST/SHOULD nature of protection. Otherwise, leave it in > > > > > the intuitive > > > > > > state: a write lock says that others cannot monkey with > > > your URI. > > > > > > > > > > > > Cheers, > > > > > > -g > > > > > > > > > > > > Edgar Schwarz wrote: > > > > > > > > > > > > > > On Thu, 2 Sep 1999, Geoffrey M. Clemm wrote: > > > > > > > > > > > > > > > From: ccjason@us.ibm.com > > > > > > > > > > > > > > > > > > > > > > > > This discussion began with Yaron's comment > that saying > > > > > > that "it MUST NOT be > > > > > > > > possible for a principal other than the lock owner to > > > > > > make a locked resource > > > > > > > > inaccessible via the URI mapping used to lock the > > > > > > resource" is too strong. > > > > > > > > It may make sense for write locks as defined in RFC > > > > > > 2518, but may not make > > > > > > > > sense for other sorts of locks that don't restrict > > > > > > MOVE and DELETE. > > > > > > > > > > > > > > > > > > > > > > > > I believe that this is not specific to any particular > > > > > > type of locks. All > > > > > > > > clients need to insure that they have at the very > > > > > > least a way to unlock > > > > > > > > the the locks they have created. I assume that to > > > > > > unlock (a resource), we > > > > > > > > have to provide a URI of a (the?) resource locked by > > > > > > that lock... so if > > > > > > > > someone else changes the URI, it's > > > > > > > > very likely that we're not going to be able to figure > > > > > > out what the new > > > > > > > > URI is... and will have to leave the lock > around until > > > > > > it times out. > > > > > > > > > > > > > > > > Since the server needs to deal with this in case > > > > > > the client just > > > > > > > > neglects to remove the lock, and if having > another client > > > > > > MOVE your > > > > > > > > locked resource is a rare occurrence (which I believe > > > > > it is), then > > > > > > > > this does not seem to be especially problematical. > > > > > > > Would it be possible to say: > > > > > > > If a locked resource is moved the server SHOULD create > > > > > a indirect > > > > > > > reference resource which should exist for some > > > sensible time. > > > > > > > > > > > > > > Yes I know, it's complicating the server :-) > > > > > > > I imagine the above happening perhaps when somebody is > > > > > reorganizing > > > > > > > a directory structure and deep in the collections > > > there are some > > > > > > > locked resources. > > > > > > > So the lock owner at least has a decent chance to find > > > > > out where his > > > > > > > resource has gone to. > > > > > > > > > > > > > > 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. > > > > > > > > > > > > -- > > > > > > Greg Stein, http://www.lyra.org/ > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > From w3c-dist-auth-request@w3.org Fri Sep 10 19:19:50 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 TAA24360 for ; Fri, 10 Sep 1999 19:19:50 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id TAA25466; Fri, 10 Sep 1999 19:06:48 -0400 (EDT) Resent-Date: Fri, 10 Sep 1999 19:06:48 -0400 (EDT) Resent-Message-Id: <199909102306.TAA25466@www19.w3.org> Message-ID: <37D98CF0.3CC4AD1E@lyra.org> Date: Fri, 10 Sep 1999 15:57:52 -0700 From: Greg Stein X-Mailer: Mozilla 3.01 (X11; I; Linux 2.0.28 i586) MIME-Version: 1.0 To: Brian Stiles CC: w3c-dist-auth@w3.org References: <3887-Fri10Sep1999145620-0700-bstiles@starbase.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: Clarification on MKCOL needed Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3284 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 Brian Stiles wrote: > > How can a WebDAV server support MKCOL if the repository the server is > built upon assigns names to newly created collections (as opposed to > allowing clients to specify the name)? Put another way, how can a It can't. MKCOL is defined as creating the collection specified by the Request-URI. If your server doesn't do that, it it isn't MKCOL :-) Is it possible for you to create (internally) the server-specified collection and then somehow link/alias the Request-URI to point to the new collection? If you have a custom client, then you can define a method such as "STARBASE-MKCOL" which is modelled after MKCOL, but returns a Location header with the true URI. Another alternative is to return the "next-collection-name" as a property of the parent collection; this has transactional problems, though (e.g. what happens if two clients request the property and then use it in MKCOL?) Cheers, -g -- Greg Stein, http://www.lyra.org/ From w3c-dist-auth-request@w3.org Fri Sep 10 19:52: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 TAA24566 for ; Fri, 10 Sep 1999 19:52:18 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id TAA26005; Fri, 10 Sep 1999 19:33:53 -0400 (EDT) Resent-Date: Fri, 10 Sep 1999 19:33:53 -0400 (EDT) Resent-Message-Id: <199909102333.TAA26005@www19.w3.org> Message-ID: <078292D50C98D2118D090008C7E9C6A603C965DD@STAY.platinum.corp.microsoft.com> From: "Yaron Goland (Exchange)" To: "'Greg Stein'" , ccjason@us.ibm.com Cc: w3c-dist-auth@w3.org Date: Fri, 10 Sep 1999 16:33:21 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Subject: RE: Crossserver ops and lock token swapping. Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3285 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 first lessons learned years ago in the database world is to absolutely never put any useful information into an identifier. It always bites you. As such servers that put useful information into their lock tokens are basically guaranteed to be badly written. In this case the first manifestation of this "brokenness" will be when they try to coordinate with other servers. While it is true that we can hack up the protocol to make it support allowing the lock token to be changed on a request by request basis this is an abysmally bad idea. For example, imagine that after the response with the new lock token is sent the connection is lost and the client never actually receives the response. The client can, of course, perform lock discovery on the destination (after checking that the source is gone) and get the new lock token. The only problem is that the client now doesn't know if the resource has been locked the whole time. For example, did another program also under the user's control happen to ask for a lock on the resource, thus explaining why the program can access the lock? Because the lock token isn't the same there is no way for the program to know if the lock it took out was outstanding the whole time so any consistency guarantees provided by the continuing existence of the lock are abrogated and the client is S.O.L. Of course we could try to work around this problem by either providing some sort of lock equivalence statement or using timers but those lead to their own complications. Given that the whole reason to jump into this pit is to enable servers to do something they manifestly should never do I would recommend that the lock tokens be required to remain the same. Yaron > -----Original Message----- > From: Greg Stein [mailto:gstein@lyra.org] > Sent: Friday, September 10, 1999 2:45 PM > To: ccjason@us.ibm.com > Cc: w3c-dist-auth@w3.org > Subject: Re: Crossserver ops and lock token swapping. > > > ccjason@us.ibm.com wrote: > >... > > I'd like to propose that moving a lock across servers not > change the lock token > > for a lock on that moved resource.. The reason I say this > is because we are > > claiming in the proposal that locks are on resources... not > bindings or URI's. > > This is rather neat philosophically/academically, but from a pragmatic > standpoint, I don't think it really holds water. > > Let's just take a simple example of a resource being moved from a > filesystem into a database. The filesystem prefers scheme X > to represent > the locks. The database prefers Y. Sure, they could both use > opaquelocktokens, but they aren't -- they're each using a scheme to > optimize their behavior. > > Now what are you going to do? > > I say the MOVE allows the lock token to change, or it just isn't going > to happen. > > > Well, a MOVE operation is basically just a rebinding and in > that sense, the > > resource itself has not moved. MOVE just changes some of > the URI's at which > > resources are accessable. In this case the resource(s) is > now accessable via a > > Again: neat philosophy. Go implement this and I'll buy it. > > >... > > move them. Can we actually expect unsophisticated servers > to actually support > > locks generated by other servers? So this suggests... > > Nope. But that was probably a rhetorical question :-) > > > 1) MOVE does not move locks from source to destination > in any sense. (But > > this breaks model of resource is what is locked.) > > Works for me. > > [although, as I stated in reply to Judy's initial proposal: I'm also > fine with moving the lock. I think it isn't making as much > sense (to me) > to move it, though. more below] > > > or > > 2) We let the destination reassign lock tokens. (Is > this situation important > > enough to take this approach and complicate the spec? And > wouldn't they still > > face authentication issues?) > > I prefer this option. > > Why not just allow the MOVE to return a Lock-Token header? The > Lock-Token header would specify the lock that the (moved) > resources now > fall under at the destination. > > There is an issue, though: what of the old locktoken? Did it get moved > (and changed) or did it remain? Hrm. This isn't an issue, > though, if we > state that it always remains (yes, this is different than > Judy's latest > proposal; it also follows my suggestion about it remaining and > establishing a locknull resource). If the lock remains, then > client can > always know what happens -- the source lock remains, the resource now > falls under the lock specified by the returned Lock-Token. > > > or > > 3) MOVE wouldn't be allowed between these these servers. > The client would > > have to use > > DELETE/COPY/DELETE. (Keeps protocol simple. Probably is > good enough for those > > with cheap servers.) > > This is *always* an option. A server can always return Bad > Gateway if it > chooses not to do a move. > > > > > Thoughts? > > > > Further thoughts on cross server. As some have pointed > out, right now the spec > > is nowhere near close enough to actually enable two > independently developed > > servers to do cross server operations besides possibly > COPY. Things like > > cooperative authentication and lock and binding protocols > are are needed. And > > we need to specify that lock tokens be standardized. (We > might want to address > > this now rather than retrofit this later.) (Judith pointed > this out.) So are > > we agree'ing that WebDAV is to be cross server > friendly/compatible... but not > > enabling? (Is that what Yaron was trying to say? :-)) > > I believe Yaron was trying to say that we should not be considering > server-to-server communication. The WebDAV charter explicitly states > that this is not in scope. As a result, any portion of the > specification > that are necessary *only* for server-server communication should be > axed. If you can argue a DAV client would use it, then it can stay :-) > > Cheers, > -g > > -- > Greg Stein, http://www.lyra.org/ > From w3c-dist-auth-request@w3.org Fri Sep 10 19:56: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 TAA24591 for ; Fri, 10 Sep 1999 19:56:12 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id TAA26245; Fri, 10 Sep 1999 19:47:35 -0400 (EDT) Resent-Date: Fri, 10 Sep 1999 19:47:35 -0400 (EDT) Resent-Message-Id: <199909102347.TAA26245@www19.w3.org> Message-ID: <37D998A9.A4338037@starbase.com> Date: Fri, 10 Sep 1999 16:47:53 -0700 From: Brian Stiles X-Mailer: Mozilla 4.61 [en] (X11; I; Linux 2.2.5-15 i686) X-Accept-Language: en MIME-Version: 1.0 To: Greg Stein CC: w3c-dist-auth@w3.org References: <3887-Fri10Sep1999145620-0700-bstiles@starbase.com> <37D98CF0.3CC4AD1E@lyra.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: Clarification on MKCOL needed Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3286 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 Thanks for the quick response. Greg Stein wrote: > > Is it possible for you to create (internally) the server-specified > collection and then somehow link/alias the Request-URI to point to the > new collection? It's problematic because we are trying to make use of a legacy repository that has some inconsistencies with the WebDAV model and we are trying not to modify the repository code. In particular, if you use the repository-assigned ID's of the objects in the repository for the URI, then you can have proper URI's for each object, but you can't create new collections with MKCOL for the aforementioned reason. If you use the user-assigned name of each object in the repository, you can't have proper URI's for each object in the repository because there can be multiple objects in one collection that have the same name. After thinking about your suggestion, it appears we have two choices. We could use the user-assigned names of collections in the MKCOL request-URI and also assign the new collection a URI based on the repository-assigned ID's. Or, perhaps a better approach would be to consider it a flaw in the repository that two objects in the same collection can have the same name and just disallow access via WebDAV to all but one of the objects with the same name. > If you have a custom client, then you can define a method such as > "STARBASE-MKCOL" which is modelled after MKCOL, but returns a Location > header with the true URI. Another alternative is to return the > "next-collection-name" as a property of the parent collection; this has > transactional problems, though (e.g. what happens if two clients request > the property and then use it in MKCOL?) That is problematic indeed in our case. I think I'd rather bend my product to work with the protocol than extend the protocol to work with my product. Thanks again. -- Brian Stiles From w3c-dist-auth-request@w3.org Fri Sep 10 20:27:57 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 UAA24713 for ; Fri, 10 Sep 1999 20:27:56 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id UAA27251; Fri, 10 Sep 1999 20:18:46 -0400 (EDT) Resent-Date: Fri, 10 Sep 1999 20:18:46 -0400 (EDT) Resent-Message-Id: <199909110018.UAA27251@www19.w3.org> Message-ID: <37D99DDF.55C31FF5@lyra.org> Date: Fri, 10 Sep 1999 17:10:07 -0700 From: Greg Stein X-Mailer: Mozilla 3.01 (X11; I; Linux 2.0.28 i586) MIME-Version: 1.0 To: "Yaron Goland (Exchange)" CC: w3c-dist-auth@w3.org References: <078292D50C98D2118D090008C7E9C6A603C965DD@STAY.platinum.corp.microsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: Crossserver ops and lock token swapping. Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3287 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 Yaron Goland (Exchange) wrote: > > One of the first lessons learned years ago in the database world is to > absolutely never put any useful information into an identifier. It always > bites you. Forgive me if my jaw hits the floor. Database tables use column values all the time for primary keys. You do *not* have to always create an "id" column. Yes, you usually do when you have various foreign-key relationships (as part of the process of normalizing your database design), but there is *nothing* in database relational theory that requires the addition of an extra column simply to refer to rows in a database. A URI is a unique value which contains useful information. If I have no foreign key relationships or I don't want to normalize my tables, then why do I have to munge that into something else? That's bunk. Useful info can definitely be part of an identifier. I can cite examples :-) > As such servers that put useful information into their lock > tokens are basically guaranteed to be badly written. In this case the first > manifestation of this "brokenness" will be when they try to coordinate with > other servers. I disagree with your assertion. Let's say that I have a repository (table) with two columns: a database-assigned unique serial number ("id"), and a binary blob. I use this table to store the resources on my server. When I generate a locktoken, I want that token to specify the resource's "id" for efficiency purposes. If the WebDAV spec does not allow that, then it is broken. As it is currently written, it *does*, but it seems like you're trying to say that all locktokens should be uniform, regardless of repository. NFW. I don't see how you can assert that my server would be "badly written" because of this feature. What makes you believe that? I see no support for your position. Coordinating with other servers is beyond the scope of WebDAV. Further, when/if this server-server communication begins to be designed, then you're going to need to deal with different locktoken designs simply because servers are going to want to have opaque/private locktokens. I know that I want custom locktokens. > While it is true that we can hack up the protocol to make it support > allowing the lock token to be changed on a request by request basis this is > an abysmally bad idea. > [snip: discussion of why changing tokens is bad] Excellent point! I agree with you here. That leads me to believe that locks MUST NOT move with the resource since the Destination may not support the transfer of the locktoken (heck, what happens if the Destination doesn't support locking!). However, I still disagree on your notion that locktokens cannot be defined by the server (to include useful info). And I *really* disagree with your (unsupported) view that this implies the server is badly written. Cheers, -g -- Greg Stein, http://www.lyra.org/ From w3c-dist-auth-request@w3.org Fri Sep 10 21:13:54 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 VAA24943 for ; Fri, 10 Sep 1999 21:13:54 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id VAA00021; Fri, 10 Sep 1999 21:05:00 -0400 (EDT) Resent-Date: Fri, 10 Sep 1999 21:05:00 -0400 (EDT) Resent-Message-Id: <199909110105.VAA00021@www19.w3.org> Message-ID: <37D9AA90.B8FD9ACA@ecal.com> Date: Fri, 10 Sep 1999 21:04:16 -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: <078292D50C98D2118D090008C7E9C6A603C965DD@STAY.platinum.corp.microsoft.com> <37D99DDF.55C31FF5@lyra.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: Crossserver ops and lock token swapping. Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3288 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 Greg Stein wrote: > Useful > info can definitely be part of an identifier. I can cite examples :-) Eric the Red. -- /==============================================================\ |John Stracke | http://www.ecal.com |My opinions are my own.| |Chief Scientist |=============================================| |eCal Corp. |"We can't duplicate the bug." "Have you tried| |francis@ecal.com|the Xerox machine?" | \==============================================================/ From w3c-dist-auth-request@w3.org Fri Sep 10 21:21: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 VAA24963 for ; Fri, 10 Sep 1999 21:21:13 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id VAA00241; Fri, 10 Sep 1999 21:11:52 -0400 (EDT) Resent-Date: Fri, 10 Sep 1999 21:11:52 -0400 (EDT) Resent-Message-Id: <199909110111.VAA00241@www19.w3.org> Message-ID: <37D9AC35.BF787EFD@ecal.com> Date: Fri, 10 Sep 1999 21:11:17 -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: <078292D50C98D2118D090008C7E9C6A603C965DD@STAY.platinum.corp.microsoft.com> <37D99DDF.55C31FF5@lyra.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: Crossserver ops and lock token swapping. Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3289 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 Greg Stein wrote: > That leads me to believe that > locks MUST NOT move with the resource It occurs to me that the biggest reason you'd want to MOVE the lock is because you want to keep control over the resource in the new location. Couldn't you do that by locking the destination and then MOVEing the resource? -- /==============================================================\ |John Stracke | http://www.ecal.com |My opinions are my own.| |Chief Scientist |=============================================| |eCal Corp. |NT's lack of reliability is only surpassed by| |francis@ecal.com|its lack of scalability. --John Kirch | \==============================================================/ From w3c-dist-auth-request@w3.org Fri Sep 10 21:29: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 VAA25009 for ; Fri, 10 Sep 1999 21:29:23 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id VAA00496; Fri, 10 Sep 1999 21:20:39 -0400 (EDT) Resent-Date: Fri, 10 Sep 1999 21:20:39 -0400 (EDT) Resent-Message-Id: <199909110120.VAA00496@www19.w3.org> From: ccjason@us.ibm.com X-Lotus-FromDomain: IBMUS To: Greg Stein cc: w3c-dist-auth@w3.org Message-ID: <852567E9.00075917.00@D51MTA07.pok.ibm.com> Date: Fri, 10 Sep 1999 21:27:53 -0400 Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Subject: Re: Crossserver ops and lock token swapping. Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3290 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'd like to propose that moving a lock across servers not change the lock token > for a lock on that moved resource.. The reason I say this is because we are > claiming in the proposal that locks are on resources... not bindings or URI's. This is rather neat philosophically/academically, but from a pragmatic standpoint, I don't think it really holds water. Let's just take a simple example of a resource being moved from a filesystem into a database. The filesystem prefers scheme X to represent the locks. The database prefers Y. Sure, they could both use opaquelocktokens, but they aren't -- they're each using a scheme to optimize their behavior. Now what are you going to do? They have to support tokens generated by the other server anyway if they support locking and cross server bindings. So what would they do? They'd do whatever they'd do for x-server locks. And what might that be? Depending on the operation it might delegate... or the servers would use out of band communication to cooperate on locking issues. As for the out of band-communication, we haven't defined that. That's not in the scope of the current WebDAV protocol. Now of course, I think you're thinking about how a server would support this if that server doesn't support x-server bindings. Such a server is very unlikely to implement support of lock tokens generated on other servers. So... Yes, the ability to reissue lock tokens upon MOVE would enable a case that wouldn't normally be available to this server. (Note: this problem is specific to Judy's/ proposal to move locks with moved resources.) In addition, if we're serious about this situation, we'd probably want to enhance WebDAV to provide a way to specify authentication information for the destination server. This is probably a good idea anyway. (Anyone want to start a thread?) Also note: another approach such a server might take is to not allow the MOVE if any of the source resources are locked. Remember... we're talking about a server that is already limited in its cross server capabilities. Note regardless of reissuing lock tokens, no resource with two binding (caveat omitted) can be moved between this type of servers. Not supporting cross server movement of resources that have locks rooted on them would be just another limitation of these servers. So what is user of such a server to do? Well I suppose they could unlock the source and then MOVE. Another option is to do a COPY/DELETE. I don't think that *requires* any sophistication or cooperation between servers. I say the MOVE allows the lock token to change, or it just isn't going to happen. I don't like it, but I'm willing to give that a shot if we don't make it specific to x-server moves. No special cases here for x-server. We'd have to allow lock token changing on what appears to be a local operation also. To take your example... if the same server had both a SQL and file system implementation running in tandem, it could then change the token. Of if for some reason it decided to encode the LOCK URI in the lock token, it could reissue it if the protected URI changed due to MOVE's or whatever within the same server. BTW, this example is admittedly poor. A good implementation is unlikely to encode this stuff in the lock-token. And the code that enforces the lock token probably is implemented earlier/higher in the server than the part that care about the difference between SQL or filesystem. This doesn't undermine your position though. Just mine. But I still philosophically don't want to special case the x-server case within the protocol. So, I'd prefer not to support reissuing of lock tokens, but if WebDAV is to support it, let's not make it a special cross-server case. > 1) MOVE does not move locks from source to destination in any sense. (But > this breaks model of resource is what is locked.) Works for me. Works for me too. But I'm still trying to fully exercise the proposal that Judy posted. :-) > or > 2) We let the destination reassign lock tokens. (Is this situation important > enough to take this approach and complicate the spec? And wouldn't they still > face authentication issues?) I prefer this option. Why not just allow the MOVE to return a Lock-Token header? The Lock-Token header would specify the lock that the (moved) resources now fall under at the destination. I forget if Judith mentioned it in her posting, but as discussed off line, in her proposal the response could return a new locktoken of the source resource in the header of the response. If any other resource changed its locktoken, then the new lock token could be obtained through lock discovery. Of course it would be efficient if the server's response warned the client that some lock tokens had been reassigned so that the client code would only do lock discovery when necessary. Argh... I'm just thinking about that poor client harvesting all the reissued lock tokens. I suppose we could enhance the MOVE response to make that more efficient. Anyway, my preference is not to reassign lock tokens during MOVE's. This is all, "what if". From w3c-dist-auth-request@w3.org Fri Sep 10 22:30: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 WAA26294 for ; Fri, 10 Sep 1999 22:30:25 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id WAA02876; Fri, 10 Sep 1999 22:20:23 -0400 (EDT) Resent-Date: Fri, 10 Sep 1999 22:20:23 -0400 (EDT) Resent-Message-Id: <199909110220.WAA02876@www19.w3.org> From: ccjason@us.ibm.com X-Lotus-FromDomain: IBMUS To: John Stracke , w3c-dist-auth@w3.org Message-ID: <852567E9.000CD2AF.00@D51MTA07.pok.ibm.com> Date: Fri, 10 Sep 1999 22:27:41 -0400 Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Subject: Re: Crossserver ops and lock token swapping. Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3291 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list > > That leads me to believe that > > locks MUST NOT move with the resource > It occurs to me that the biggest reason you'd want to MOVE the lock is because > you want to keep control over the resource in the new location. Couldn't you do > that by locking the destination and then MOVEing the resource? Yup I think that's the biggest. And you can do it fairly precisely with null locks... at the destination and in some sense reserve the destination before you actually move something to it. ...but, and I don't know if it's important,... but if you move locks during a MOVE, locks within a moved tree are retained. But if we don't support moving of locks, some locks might be totally destroyed by the MOVE operation. I think that's what the previous proposal said. It's hard to recall. My brain has been warped by the new proposal. :-) ...I think it was/is also the hope that tying locks to resources (Judy's proposal) provides a simpler model and that that will pay off in other ways. I think the jury's still out on that. Anything else?... From w3c-dist-auth-request@w3.org Sat Sep 11 15:37: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 PAA13042 for ; Sat, 11 Sep 1999 15:37:34 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id PAA13961; Sat, 11 Sep 1999 15:26:32 -0400 (EDT) Resent-Date: Sat, 11 Sep 1999 15:26:32 -0400 (EDT) Resent-Message-Id: <199909111926.PAA13961@www19.w3.org> Date: Sat, 11 Sep 1999 15:26:16 -0400 Message-Id: <9909111926.AA01848@tantalum> From: "Geoffrey M. Clemm" To: w3c-dist-auth@w3.org In-Reply-To: <852567E8.0061BA87.00@D51MTA07.pok.ibm.com> (ccjason@us.ibm.com) Subject: Re: Crossserver ops and lock token swapping. Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3292 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 I'm tending to agree with you (and Yaron) that cross server moves shouldn't be a special case in the protocol. No lock token swapping for example.... BTW, before I get to the verbage, I just want to say that even if we agree that cross server isn't a special case, I'd kind of like the spec to mention cross server operations... Just to say that various URI's *CAN* include the host name for example would be an example of what we can say to remind the reader of the cross server compatibility. I just want to bring attention to the fact that WebDAV should be cross server compatible and to remind us that we shouldn't really add anything that prevents this. I agree. I think one of the problems has been that we (and certainly, *I*) have sometimes failed to distinguish between: - using cross-server issues to influence the protocol design (*good*) - defining different protocol behavior for intra-server and cross-server operations (*bad*) Motivating a particular protocol design choice by appealing to cross-server issues is perfectly reasonable, but addressing cross-server issues by defining *different* protocol behavior in this case produces an unacceptable complexity in the protocol and therefore in clients that try to use it. I'd like to propose that moving a lock across servers not change the lock token for a lock on that moved resource. I agree. Greg and others gave various reasons why a cross-server MOVE might not be able to preserve locks. That's fine. The server is then just responsible for failing the MOVE request. The client can then do an UNLOCK/MOVE/LOCK or a COPY/LOCK. Trying to hardwire certain variants of UNLOCK/MOVE/LOCK or COPY/fixup/LOCK into the MOVE semantics is virtually guaranteed to produce non-interoperable behavior. (Heck, look at how the simple MOVE request was implemented by some as a "merge" request ... just imagine how many ways the lock renewal semantics could be misinterpreted). The reason I say this is because we are claiming in the proposal that locks are on resources... not bindings or URI's. Well, a MOVE operation is basically just a rebinding and in that sense, the resource itself has not moved. MOVE just changes some of the URI's at which resources are accessable. In this case the resource(s) is now accessable via a URI on another server. (Note: It may still be accessable at the source server via another URI.) In order to achieve this, we implicitly require (except for special cases) that server pairs cooperate on bindings... and therefore locks since a locked resource can be accessed via a URI on either machine. I agree with all this, except for the "except for special cases". What did you have in mind here? Either the server pairs cooperate on bindings so that bindings semantics is maintained, or they must fail the BIND or MOVE request that would have created the cross server binding. An argument against what I've just said is... what if someone wants to move a resource (or tree) between servers. Then they either UNLOCK the tree before the move (if the server cannot move the locks), or they do a COPY/DELETE (if the move would have resulted in cross server bindings and the server cannot support them). And neither server really supports bindings. (Is server support for multiple bindings to a resource a MUST?) It is a MUST if they support the advanced collection protocol. These are really simple servers with simple mappings. One mapping per resource. But one wants to move resources between these servers. Nothing fancy. Just move them. Can we actually expect unsophisticated servers to actually support locks generated by other servers? So this suggests... 1) MOVE does not move locks from source to destination in any sense. (But this breaks model of resource is what is locked.) or I agree. Unless we want to define two different MOVE protocols, the protocol has to make sense not only for simple servers, but also servers that do support multiple bindings to a resource. And deleting the locks from the source of the copy does not work if there are multiple bindings to a resource that still expect it to be locked. 2) We let the destination reassign lock tokens. (Is this situation important enough to take this approach and complicate the spec? And wouldn't they still face authentication issues?), or I agree. I do not believe that this situation is important enough to warrant the complexity it would introduce in both the protocol and in clients using the protocol. 3) MOVE wouldn't be allowed between these these servers. The client would have to use COPY/DELETE. (Keeps protocol simple. Probably is good enough for those with cheap servers.) I agree. Simple and sufficient for the key use cases. I'd defer enhancements until the need for them has been clearly demonstrated. From: Greg Stein There is an issue, though: what of the old locktoken? Did it get moved (and changed) or did it remain? Hrm. This isn't an issue, though, if we state that it always remains (yes, this is different than Judy's latest proposal; it also follows my suggestion about it remaining and establishing a locknull resource). If the lock remains, then client can always know what happens -- the source lock remains, the resource now falls under the lock specified by the returned Lock-Token. Having the lock continue to apply to the source (null) resource would be problematical in the presence of multiple bindings to the same resource. The lock would apply to both the null resource, and to the resource as it is known by other mappings. Now you create a new resource at the null resource location. This inherits the lock, which means that the same lock applies to both the old and the new resources. This leads to a large number of anomalies. From: "Yaron Goland (Exchange)" For example, imagine that after the response with the new lock token is sent the connection is lost and the client never actually receives the response. The client can, of course, perform lock discovery on the destination (after checking that the source is gone) and get the new lock token. The only problem is that the client now doesn't know if the resource has been locked the whole time. For example, did another program also under the user's control happen to ask for a lock on the resource, thus explaining why the program can access the lock? Because the lock token isn't the same there is no way for the program to know if the lock it took out was outstanding the whole time so any consistency guarantees provided by the continuing existence of the lock are abrogated and the client is S.O.L. Of course we could try to work around this problem by either providing some sort of lock equivalence statement or using timers but those lead to their own complications. This is such a good example of what can happen when a lock token is effectively "re-identified" that I thought I'd just quote it verbatim (:-). One of the first lessons learned years ago in the database world is to absolutely never put any useful information into an identifier. It always bites you. Forgive me if my jaw hits the floor. [good examples of why info is encoded in URI's deleted] It's important to distinguish an identifier (in the sense that I believe Yaron intended, namely a GUID or a UUID) from a URL or name. A URL or name will commonly encode some semantic information. An identifier (or URN) is there to determine identity. If you depend on non-identity information appearing in the identifier, then things break badly when that non-identity information is no longer true about that resource. While it is true that we can hack up the protocol to make it support allowing the lock token to be changed on a request by request basis this is an abysmally bad idea. Excellent point! I agree with you here. That leads me to believe that locks MUST NOT move with the resource since the Destination may not support the transfer of the locktoken (heck, what happens if the Destination doesn't support locking!). The alternative conclusion is that unless the server can maintain the lock token, it must fail the MOVE request. I think this is a more scalable/extensible approach than defining special behavior for the MOVE with respect to various resource behavior (such as locks and bindings). However, I still disagree on your notion that locktokens cannot be defined by the server (to include useful info). And I *really* disagree with your (unsupported) view that this implies the server is badly written. If you encode anything in the token, you must then constrain the resource to always satisfy whatever information is stored in that encoding (or else anything that counts on this encoded information will be misled). That means that operations will fail in various server defined ways depending on what they decided to encode in those tokens. So I'm with Yaron on this one. From: John Stracke It occurs to me that the biggest reason you'd want to MOVE the lock is because you want to keep control over the resource in the new location. Couldn't you do that by locking the destination and then MOVEing the resource? Good point. I may have to withdraw my objection to the null-resource lock, since only the null-resource lock survives a MOVE. Cheers, Geoff From w3c-dist-auth-request@w3.org Sat Sep 11 17:21: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 RAA13526 for ; Sat, 11 Sep 1999 17:21:19 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id RAA14746; Sat, 11 Sep 1999 17:07:42 -0400 (EDT) Resent-Date: Sat, 11 Sep 1999 17:07:42 -0400 (EDT) Resent-Message-Id: <199909112107.RAA14746@www19.w3.org> From: ccjason@us.ibm.com X-Lotus-FromDomain: IBMUS To: "Geoffrey M. Clemm" cc: w3c-dist-auth@w3.org Message-ID: <852567E9.00740616.00@D51MTA07.pok.ibm.com> Date: Sat, 11 Sep 1999 17:14:31 -0400 Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Subject: Re: Crossserver ops and lock token swapping. Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3293 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 reason I say this is because we are claiming in the proposal that locks are on resources... not bindings or URI's. Well, a MOVE operation is basically just a rebinding and in that sense, the resource itself has not moved. MOVE just changes some of the URI's at which resources are accessable. In this case the resource(s) is now accessable via a URI on another server. (Note: It may still be accessable at the source server via another URI.) In order to achieve this, we implicitly require (except for special cases) that server pairs cooperate on bindings... and therefore locks since a locked resource can be accessed via a URI on either machine. I agree with all this, except for the "except for special cases". What did you have in mind here? Either the server pairs cooperate on bindings so that bindings semantics is maintained, or they must fail the BIND or MOVE request that would have created the cross server binding. I don't remember what I meant before. I'm guessing that I was thinking of the limited situation that I outlined in my note to Greg. The situation where there are no locks on the source and only single bindings. I think we couldn't protest very vigorously if in special cases like this, servers (that might not even support bindings) tried to carry out the move using PUT/PROPPATCH/DELETE. These are really simple servers with simple mappings. One mapping per resource. But one wants to move resources between these servers. Nothing fancy. Just move them. Can we actually expect unsophisticated servers to actually support locks generated by other servers? So this suggests... 1) MOVE does not move locks from source to destination in any sense. (But this breaks model of resource is what is locked.) or I agree. Unless we want to define two different MOVE protocols, the protocol has to make sense not only for simple servers, but also servers that do support multiple bindings to a resource. And deleting the locks from the source of the copy does not work if there are multiple bindings to a resource that still expect it to be locked. I'm glad you agree, but I'm not sure with what you are agreeing. Let me guess that you are agreeing with the, "but this breaks...", so you are disagreeing with a special case that says in some cases locks don't move with the resource. -- Or perhaps you're agreeing that locks shouldn't move with the resource at all? (IOW, rejecting "Judith's" proposal that MOVE's move locks.) -- Sorry, I should have phrased these options more concisely and omitted my own commentary from them. While it is true that we can hack up the protocol to make it support allowing the lock token to be changed on a request by request basis this is an abysmally bad idea. Excellent point! I agree with you here. That leads me to believe that locks MUST NOT move with the resource since the Destination may not support the transfer of the locktoken (heck, what happens if the Destination doesn't support locking!). The alternative conclusion is that unless the server can maintain the lock token, it must fail the MOVE request. I think this is a more scalable/extensible approach than defining special behavior for the MOVE with respect to various resource behavior (such as locks and bindings). We've already explored the world without lock movements on MOVE, so let's continue exploring based on the variant of Judith's proposal that Geoff just suggested. That is, locks remain tied to resources, lock tokens never are reassigned, if a server can't support this semantic for a given request, it must reject the request. It occurs to me that the biggest reason you'd want to MOVE the lock is because you want to keep control over the resource in the new location. Couldn't you do that by locking the destination and then MOVEing the resource? Good point. I may have to withdraw my objection to the null-resource lock, since only the null-resource lock survives a MOVE. Geoff, what is it that you are withdrawing? Please clarify. From w3c-dist-auth-request@w3.org Sat Sep 11 17:43: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 RAA13624 for ; Sat, 11 Sep 1999 17:43:53 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id RAA15071; Sat, 11 Sep 1999 17:30:40 -0400 (EDT) Resent-Date: Sat, 11 Sep 1999 17:30:40 -0400 (EDT) Resent-Message-Id: <199909112130.RAA15071@www19.w3.org> From: ccjason@us.ibm.com X-Lotus-FromDomain: IBMUS To: ccjason@us.ibm.com cc: w3c-dist-auth@w3.org Message-ID: <852567E9.007623FC.00@D51MTA07.pok.ibm.com> Date: Sat, 11 Sep 1999 17:37:39 -0400 Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Subject: Re: Protected URI's wes: Bindings, Locks, and MOVE Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3294 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list No comments on my previous note with this Title? Anyway, that note suggested that when we say a lock protects a URI, we truly mean a URI to resource mapping, not a binding and not a resource. (BTW: An interesting situation is listed near the bottom of that note that you might want to agree or disagree with.) It also hinted at odd situations where we'd presumably have to reassign a protected URI to a lock if MOVE and BINDs and DELETEs occur. ------------------------------------------ Phone: 914-784-7569, ccjason@us.ibm.com From w3c-dist-auth-request@w3.org Sat Sep 11 23:35: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 XAA17008 for ; Sat, 11 Sep 1999 23:35:39 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id XAA17909; Sat, 11 Sep 1999 23:22:16 -0400 (EDT) Resent-Date: Sat, 11 Sep 1999 23:22:16 -0400 (EDT) Resent-Message-Id: <199909120322.XAA17909@www19.w3.org> Date: Sat, 11 Sep 1999 23:22:04 -0400 Message-Id: <9909120322.AA01906@tantalum> From: "Geoffrey M. Clemm" To: w3c-dist-auth@w3.org In-Reply-To: <852567E9.00740616.00@D51MTA07.pok.ibm.com> (ccjason@us.ibm.com) Subject: Re: Crossserver ops and lock token swapping. Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3295 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 ... MOVE just changes some of the URI's at which resources are accessable. In this case the resource(s) is now accessable via a URI on another server. ... In order to achieve this, we implicitly require (except for special cases) that server pairs cooperate on bindings... and therefore locks since a locked resource can be accessed via a URI on either machine. I agree with all this, except for the "except for special cases". What did you have in mind here? Either the server pairs cooperate on bindings so that bindings semantics is maintained, or they must fail the BIND or MOVE request that would have created the cross server binding. I don't remember what I meant before. I'm guessing that I was thinking of the limited situation that I outlined in my note to Greg. The situation where there are no locks on the source and only single bindings. I think we couldn't protest very vigorously if in special cases like this, servers (that might not even support bindings) tried to carry out the move using PUT/PROPPATCH/DELETE. I wouldn't call that a special case. It's just a case where it's very easy for the two servers to cooperate on the bindings because as a result of the MOVE, all bindings (i.e. the single binding) live on just one server. These are really simple servers with simple mappings. One mapping per resource. But one wants to move resources between these servers. Nothing fancy. Just move them. Can we actually expect unsophisticated servers to actually support locks generated by other servers? So this suggests... 1) MOVE does not move locks from source to destination in any sense. (But this breaks model of resource is what is locked.) I agree. Unless we want to define two different MOVE protocols, the protocol has to make sense not only for simple servers, but also servers that do support multiple bindings to a resource. And deleting the locks from the source of the copy does not work if there are multiple bindings to a resource that still expect it to be locked. I'm glad you agree, but I'm not sure with what you are agreeing. Let me guess that you are agreeing with the, "but this breaks...", so you are disagreeing with a special case that says in some cases locks don't move with the resource. Yup. (I was agreeing with your "But..." statement). -- Or perhaps you're agreeing that locks shouldn't move with the resource at all? Nope. (I believe locks should move with the MOVE). It occurs to me that the biggest reason you'd want to MOVE the lock is because you want to keep control over the resource in the new location. Couldn't you do that by locking the destination and then MOVEing the resource? Good point. I may have to withdraw my objection to the null-resource lock, since only the null-resource lock survives a MOVE. Geoff, what is it that you are withdrawing? Please clarify. I was contemplating withdrawing my objection to a null-resource lock (in an earlier thread, I proposed that we get rid of null resource locking). I had asked what you can do with a null-resource lock that you can't do with a lock on a dummy resource created by the client. John's suggestion was an example of something that should work with a null-resource lock but that shouldn't work with a lock on a regular resource (the lock on a regular resource at the destination of a MOVE should be deleted by MOVE). Cheers, Geoff From w3c-dist-auth-request@w3.org Sun Sep 12 00:49:50 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 AAA17375 for ; Sun, 12 Sep 1999 00:49:49 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id AAA18541; Sun, 12 Sep 1999 00:37:36 -0400 (EDT) Resent-Date: Sun, 12 Sep 1999 00:37:36 -0400 (EDT) Resent-Message-Id: <199909120437.AAA18541@www19.w3.org> Date: Sun, 12 Sep 1999 00:37:30 -0400 Message-Id: <9909120437.AA02041@tantalum> From: "Geoffrey M. Clemm" To: w3c-dist-auth@w3.org In-Reply-To: <852567CD.00022EA2.00@D51MTA07.pok.ibm.com> (ccjason@us.ibm.com) Subject: COPY onto itself (was: Circular Bindings) Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3296 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: Would you add this topic to the "action item" list for the adv. col. spec? Thanks! From: 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. 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. ... 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. Since COPY produces a new set of resources (which won't be locked or have existing bindings to them), I don't think any of the cross-server problems should apply here. Cheers, Geoff From w3c-dist-auth-request@w3.org Mon Sep 13 12:12:46 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 MAA02712 for ; Mon, 13 Sep 1999 12:12:45 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id LAA23689; Mon, 13 Sep 1999 11:57:40 -0400 (EDT) Resent-Date: Mon, 13 Sep 1999 11:57:40 -0400 (EDT) Resent-Message-Id: <199909131557.LAA23689@www19.w3.org> Message-ID: <8E3CFBC709A8D21191A400805F15E0DBD24444@crte147.wc.eso.mc.xerox.com> From: "Slein, Judith A" To: "'Brian Stiles'" , w3c-dist-auth@w3.org Date: Mon, 13 Sep 1999 11:57:05 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Clarification on MKCOL needed Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3297 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 you that this is a problem for all document management systems. I believe it is the most fundamental mismatch between the WebDAV operational model and the way document management systems work. It affects not only MKCOL, but all methods that result in the creation of new resources (COPY, MKREF, PUT, MKRESOURCE). It's also wound up with the requirement that WebDAV resource names reflect the collection hierarchy, which the server-generated names in document management systems generally do not do. Document Management Systems will probably be forced to do aliasing between client names and server names, no matter how costly and annoying that turns out to be. --Judy Judith A. Slein Xerox Corporation jslein@crt.xerox.com (716)422-5169 800 Phillips Road 105/50C Webster, NY 14580 > -----Original Message----- > From: Brian Stiles [mailto:bstiles@starbase.com] > Sent: Friday, September 10, 1999 5:56 PM > To: w3c-dist-auth@w3.org > Subject: Clarification on MKCOL needed > > > How can a WebDAV server support MKCOL if the repository the server is > built upon assigns names to newly created collections (as opposed to > allowing clients to specify the name)? Put another way, how can a > client create a collection on a WebDAV server using MKCOL if the > collection that gets created must be assigned a URI by the server? > For example, suppose that each collection is assigned an ID that is > unique to the database that underlies the WebDAV server and this ID is > used to identify the collection in a URI (e.g., > http://foo.com/121/13/4/). If a client wants to create a new > collection, it must issue a MKCOL request to > http://foo.com/121/13/4// but because of the fact that the > server essentially controls the namespace, not the client, the client > can't know what to send for NEW_NAME. > > Am I missing some important piece of information here? I assume that > document management systems might be likely to encounter this kind of > problem. If so, has anyone dealt with it? > > Although it doesn't seem to be explicitly forbidden, I am assuming > that it is inappropriate for the server to ignore the name in the > request-URI and respond with a Location header that identifies the > name assigned by the server. Though this seems like a possible > solution, it seems contrary to the intent expressed in the spec. Or > am I wrong in this assumption? > > -- > Brian Stiles > From w3c-dist-auth-request@w3.org Mon Sep 13 12:41:54 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 MAA03702 for ; Mon, 13 Sep 1999 12:41:54 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id MAA24973; Mon, 13 Sep 1999 12:28:33 -0400 (EDT) Resent-Date: Mon, 13 Sep 1999 12:28:33 -0400 (EDT) Resent-Message-Id: <199909131628.MAA24973@www19.w3.org> Message-ID: <37DD25FD.6D3847FC@ecal.com> Date: Mon, 13 Sep 1999 12:27:41 -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: <9909120437.AA02041@tantalum> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: COPY onto itself (was: Circular Bindings) Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3298 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 "Geoffrey M. Clemm" wrote: > 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. Recursion alert: MOVE is defined in terms of COPY. -- /================================================================\ |John Stracke | http://www.ecal.com |My opinions are my own. | |Chief Scientist |===============================================| |eCal Corp. |I am destined to build a bridge to China out of| |francis@ecal.com|live sheep. | \================================================================/ From w3c-dist-auth-request@w3.org Mon Sep 13 19:02: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 TAA10580 for ; Mon, 13 Sep 1999 19:02:06 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id SAA06037; Mon, 13 Sep 1999 18:51:48 -0400 (EDT) Resent-Date: Mon, 13 Sep 1999 18:51:48 -0400 (EDT) Resent-Message-Id: <199909132251.SAA06037@www19.w3.org> Message-ID: <078292D50C98D2118D090008C7E9C6A603C965EE@STAY.platinum.corp.microsoft.com> From: "Yaron Goland (Exchange)" To: "'Greg Stein'" , w3c-dist-auth@w3.org Cc: "Jim Whitehead (E-mail)" , Henrik Frystyk Nielsen Date: Mon, 13 Sep 1999 15:50:20 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Subject: Why IDs need to be Opaque Tokens - Long Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3299 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list [Ed. Note: This one is long but I think it provides a good description of why putting useful information into IDs is almost always a bad idea.] ">" comments by Greg Stein: > Database tables use column values all the time for primary > keys. You do > *not* have to always create an "id" column. Yes, you usually > do when you > have various foreign-key relationships (as part of the process of > normalizing your database design), but there is *nothing* in database > relational theory that requires the addition of an extra column simply > to refer to rows in a database. You are correct in that one can successfully perform relational manipulation on systems without a dedicated row ID. In fact, one can do relational manipulation without even having to have unique IDs. In my experience there are two general ways in which database parsing code is written: Required Structure - In this type of code the code assumes that it knows exactly what the structure of the database is, what all of its columns are, etc. For example, imagine one has a car database. The database has only three columns, car color, engine type and model year. The code is written to assume this structure. Therefore the code assumes that a car can be uniquely identified by car color, engine type and model year. To this end it generates an ID made up of these three values. It then puts this ID on the car's ID plates on various parts of the car so that if the car is stolen the parts can be potentially identified. Minimal Structure - In this type of code the code only assumes that a certain set of columns will be present but makes no assumptions about what columns may be added later. Given the same database as before this code doesn't know what columns may be added in the future or what sorts of new ways in which cars may be identified. As such this code requires that an additional column be added to the data, an ID column which contains a unique opaque ID. Each car is then identified by that ID rather than by some combination of values. Thus the code does not necessarily assume that car color/engine type/model year is sufficient to identify the car. The only assumptions it makes are: 1) A car is uniquely identified by the opaque ID 2) The database, at minimum, will contain car color, engine type and model year Therefore the IDs generated by this system are just opaque tokens, they have no inherent meaning and will be stuck all over the car for the same reasons as stated before. Now lets look at what happens when the world changes. For example, it turns out that the car company, for the first time, will be producing cars which have the same color, engine type and model year but different body types. So the database needs to have a new column added to it for body type. The "required structure" code will be completely broken. It has assumptions all over the place that a car can be uniquely identified by the three original values. It will no longer be able to generate useful IDs (since they won't be unique in the new system) and the entire database system and all systems which depend on that database system will have to be completely retooled. The "minimal structure" code won't have any problems at all. It never assumed anything about what it takes to uniquely identify a car other than some opaque ID. So one can add in a new column without problem. All the existing code will continue to function and the supporting systems will continue to work just fine. This isn't to say that changes won't have to be made. Obviously the database screens will all have to be updated to include the new data. However even if you didn't do this, for example in a search screen, the result will just be that you will get a lot more results than you were expecting. This is why one should always keep one's row identifiers opaque. One can argue that the real problem with the required structure is that its original database was badly designed. What car could possibly be uniquely identified by just car color, engine type and model year? The problem is that we absolutely never get it right. No matter how smart we are, no matter how hard we work, time always makes fools of us. That is the power of systems like HTTP. It included versioning from day one (o.k., day two, but close enough =). It assumed that it would get it wrong and left itself a way out. Opaque IDs are the moral equivalent of versioning for database systems. One writes one's code to only assume that a minimal set of values will be present and make no assumptions regarding what may be added in the future. For the minimal assumption to work one needs to have a unique ID. That way if the combination of values which uniquely identify an entry should change in the future one's code will continue to work. Unique IDs aren't about getting V1 to work. They are about making sure that V2, V3, etc. will work as well. > > A URI is a unique value which contains useful information. If > I have no > foreign key relationships or I don't want to normalize my tables, then > why do I have to munge that into something else? That's bunk. Useful > info can definitely be part of an identifier. I can cite examples :-) It is very common to put useful information into URIs. The design principal in HTTP has been that only servers are allowed to generate URIs. Clients may ask in a PUT or similar request for a particular URI but it is up to the server to decide if it wants to give out that URI. As we used to say in WebDAV, the client proposes and the server disposes. Since the server generated the URI and only the server could actually consume the URI it seemed reasonable to allow the server to put useful state information into the URI so as to simplify the implementation. I think there are many scenarios where this is true. The reason this works is that while the server may make assumptions about what the values in the URI mean the clients do not. The client treats the URI as being completely opaque. This means that if the server has to later change its policy about the format or data inside the URI no one cares but the server. This strategy isn't perfect of course. For example, if two servers decide to coordinate in a farm to handle resources then they will need to be running the exact same code so they can understand the information that has been put into the URI. Another problem is that if the server does want to change its policy in formatting the URIs then generally any existing URIs will be broken. In practice neither of these problems have been a big enough issue to overcome the processing simplicity offered by encoding data in the URI. This is the old simplicity v. extensibility tradeoff. One almost always has to trade one for the other. In general dynamically generated URIs are not stored by the clients and if multiple servers are cooperating they are all running the same software, so the versioning issues don't really matter. The cross-server lock case is a good counter example. In this case two servers running different software need to communicate and the clients are most certainly recording the identifiers. That is one reason why it is such a bad idea to put useful information into lock tokens. It is also a bad idea for the reasons discussed in the previous section. The assumptions the code will make about what is in the lock tokens will tend to "spill out" into the rest of the server code and make the entire code base more fragile. By just using an opaque token you don't have to worry about this fragility. > I disagree with your assertion. Let's say that I have a repository > (table) with two columns: a database-assigned unique serial number > ("id"), and a binary blob. I use this table to store the > resources on my > server. When I generate a locktoken, I want that token to specify the > resource's "id" for efficiency purposes. The problem is that if a server wants to move its lock over to a server which encodes IDs into its lock tokens then the transfer will fail because the first server's lock token format won't have the same information as the second server's format. This is a great example of why it is a bad idea to encode information. Just keep your identifiers opaque. > If the WebDAV spec does not allow that, then it is broken. As it is > currently written, it *does*, but it seems like you're trying to say > that all locktokens should be uniform, regardless of repository. NFW. WebDAV does allow you to do anything you want with a lock token. Additionally I am not suggesting we have a uniform lock token format. I am suggesting that we always treat lock tokens as opaque tokens with no meaningful data other than a globally unique identifier. That way we can share lock tokens. > I don't see how you can assert that my server would be "badly written" > because of this feature. What makes you believe that? I see no support > for your position. Hopefully the previous answers your question. > Coordinating with other servers is beyond the scope of > WebDAV. Further, > when/if this server-server communication begins to be designed, then > you're going to need to deal with different locktoken designs simply > because servers are going to want to have opaque/private locktokens. I > know that I want custom locktokens. I think it would be a real shame if Mod_DAV, which has shown great promise as one of the key WebDAV platforms, would make a design decision whose ramifications were to weaken its ability to be extended in the future and effectively prevent it from being able to implement server-to-server communication protocols. I hope, in light of the reasons I have listed above, that you reconsider your decision and stick with an opaque model. > Excellent point! I agree with you here. That leads me to believe that > locks MUST NOT move with the resource since the Destination may not > support the transfer of the locktoken (heck, what happens if the > Destination doesn't support locking!). In the short and probably medium term I agree with you that locks can not be moved, although for very different reasons. Long term, however, if we are to create a robust object manipulation system we must provide for the movement of locks. We can't have a situation where resources are bound based on their physical presence on a particular server. We need to make the place where the bits reside irrelevant. People who are writing WebDAV servers today who wish to be able to support this bright new future of inter-server communication can prepare for that day by not making the mistake of encoding useful information into their lock tokens. People who make the decision to use opaque tokens can take comfort that their design choice will most likely have also made their code more robust and easier to extend in the future. > > However, I still disagree on your notion that locktokens cannot be > defined by the server (to include useful info). And I > *really* disagree > with your (unsupported) view that this implies the server is badly > written. The server can include whatever it wants in a lock token, I am simply suggesting it shouldn't include anything but an opaque ID. Either way, I hope the previous provides support for my view that a server that uses non-opaque tokens will almost certainly not be able to interoperate with other servers in the future and most likely has a very fragile code base that will not be easily extensible. > > Cheers, > -g > > -- > Greg Stein, http://www.lyra.org/ > Yaron From w3c-dist-auth-request@w3.org Tue Sep 14 14: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 OAA03629 for ; Tue, 14 Sep 1999 14:24:55 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id OAA26160; Tue, 14 Sep 1999 14:13:51 -0400 (EDT) Resent-Date: Tue, 14 Sep 1999 14:13:51 -0400 (EDT) Resent-Message-Id: <199909141813.OAA26160@www19.w3.org> From: "Kevin Wiggen" To: "Slein, Judith A" , "'Yaron Goland (Exchange)'" , , Date: Tue, 14 Sep 1999 11:11: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: <8E3CFBC709A8D21191A400805F15E0DBD2443C@crte147.wc.eso.mc.xerox.com> X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3155.0 Subject: RE: Bindings, Locks, and MOVE Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3300 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 thoughts on the following subject, and some random thoughts... 1) Xythos does have cross-server communication planned. We have a hook for it, some code written, but need to build a version that works with proxy-servers etc. This being said, I agree that cross-server MOVE is hard. For all the reasons stated earlier plus other things such as keeping permissions on a file constant across servers (especially if they are across corporate barriers and users/groups do not exist on both servers. I will agree with the statements that cross-server MOVE should be out-of-scope for Webdav, and should just return an error. Clients can still issue a COPY, then DELETE if they want. Xythos will implement cross-server COPY. 2) I am fine with the lock-token being MOVED with a resource. If we can get away with saying cross-server MOVE is not supported, then the individual servers simply need to make a way of keeping locks on their own server. I believe this is how we should proceed. It sounds like we are cutting out a bunch of functionality, but I think it will take a whole set of working groups to get cross-server MOVE to work correctly in all cases anyway, so we might as well punt now. 3) I believe (with I think most other people), that the language surrounding the use of write-lock, should remain a MUST. 4) I would then like to take Judith's original note on locks and work though the scenarios to make sure we are all not missing anything... I now assume that locks are locking the resource not the URI. 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. /a/b moves to /x/y and remains locked with the same lock-token it had before. The only Lock Token mentioned still exists and remains on the resource it was locking. 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 This one gets a little weird. I assume that we can delete /x/y since we have the lock on it. This delete removes the lock from the system. When /a/b is moved to /x/y, it still is not locked. As a user, I might expect that /a/b (which is now /x/y) has the /x/y lock, but I have always thought (from a user's perspective) that a merge would happen and not a delete followed by a write. But the fact that the lock is removed from the system, does make the rest of the scenarios work nicely 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. This will remove L2 from the system, and the new /x/y is still 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. Since the lock on /a/b comes from /a, the lock is not kept on its move. /a remains locked, but the new resource /x/y loses the lock it had on it. 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. The original /x/y is removed, and the lock on that resource is removed. /a/b is then moved there, and picks up the lock from its new parent /x/ 6. Both are locked, but with separate locks. MOVE /a/b to /x/y, where /a/ has lock L1 and /b/ has lock L2. /x/y is removed and its resource is no longer locked by L2. /a/b is removed from /a's lock, and the resource is added to the L2 lock space. 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. I believe this must FAIL. A user cannot have 2 locks on the same resource, and therefore needs to remove one of them before the MOVE can happen. 8. The source collection is locked, the destination resource (not its collection) is locked with a different token MOVE /a/b to /x/y, where /a/ has lock L1, /x/ is not locked, and /x/y has lock L2. Strangely enough (to the user), this succeeds. The lock L2 is removed from the system during the DELETE phase of the move, /a/b is then moved. It is removed from /a's L1 and no lock now exists on the new /x/y 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. Since locks are on resources, if the correct lock-token is passed, I say this succeeds. The new /x/y is still locked via /a's lock because the binding for /a/b still exists. In order to do something to the new /x/y you need to pass the correct lock-token. 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 and bound to /a/b and the new /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 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, but /y/z no longer maps to R so it is not locked anymore 10b. /w/x and /y/z map to R. /w/ is not locked, but /w/x is. MOVE /a/b to /y/z. If the correct lock-token for R is passed (through the correct IF header and tagged list), the MOVE succeeds. When it is done, /w/x is still locking R, and the new /y/z is no longer locked as it now points to a new resource R2. Kevin From w3c-dist-auth-request@w3.org Tue Sep 14 19:34: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 TAA15530 for ; Tue, 14 Sep 1999 19:34:34 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id TAA04905; Tue, 14 Sep 1999 19:20:23 -0400 (EDT) Resent-Date: Tue, 14 Sep 1999 19:20:23 -0400 (EDT) Resent-Message-Id: <199909142320.TAA04905@www19.w3.org> From: ccjason@us.ibm.com X-Lotus-FromDomain: IBMUS To: w3c-dist-auth@w3.org Message-ID: <852567EC.00802B81.00@D51MTA07.pok.ibm.com> Date: Tue, 14 Sep 1999 19:26:51 -0400 Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Subject: RE: Bindings, Locks, and MOVE Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3301 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list 2) I am fine with the lock-token being MOVED with a resource. If we can get away with saying cross-server MOVE is not supported, then the individual servers simply need to make a way of keeping locks on their own server. I believe this is how we should proceed. It sounds like we are cutting out a bunch of functionality, but I think it will take a whole set of working groups to get cross-server MOVE to work correctly in all cases anyway, so we might as well punt now. Just to be clear. It is the *implementations* that can chose not to support x-server MOVE's. In the spec this would presumably be a "CAN". I just want to distinguish between implementations and the spec. -- So... it would be the server writers that would be (understandably) "cutting out a bunch of functionality"... not the spec writers. Also to clarify, I think we (as spec writers) are free to specify x-server behavior in WebDAV and to keep x-server issues in mind as we design WebDAV... but I think the philosophy is that we won't try to define the protocol that the two servers use to cooperate. I think this final thing is our only agreed restriction. As far as how far we go on the former... I think that's up to us to decide. A case in point might be... for servers to move locks across servers, they almost certainly would have to do proxy authentication. That is, both servers would need to agree on the authenticity credentials for a given principal (AKA client). We could enhance webdav operations that are potentially cross server to specify the credentials to use when interacting with the second server. Whether we chose to do that in WebDAV right now is up to us. 3) I believe (with I think most other people), that the language surrounding the use of write-lock, should remain a MUST. I take it you are refering to "protection of the URI". That's where the MUST vs. SHOULD debate was. I now assume that locks are locking the resource not the URI. Yes... with one exception: the issue of URI protection. Right now... protection is based on a hybrid of URI and resource. It's essentially a mapping that is protected... but that can be (in Judith's proposal) caused to migrate if we hold the appropriate locks. We haven't actually clearly delineated when it moves and when it does not. A resource is being MOVEd. The locks are on that resource and / or its destination, not the collections that contain them. Yes if I understand you. It is kind of an anti-null-lock view. That's why I thought it was odd that GC is starting to waver in his resistance to null locks, when he was strong in his resistance to them in the former proposal where null-locks actually filled a larger void and worked a bit better. 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. /a/b moves to /x/y and remains locked with the same lock-token it had before. The only Lock Token mentioned still exists and remains on the resource it was locking. And since you liked it when we mentioned lock tokens last time, I'll mention here again... The lock token must be provided to pass the protected URI test. (I assume that the /a/b mapping is protected... rather than some unmentioned mapping.) 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 This one gets a little weird. I assume that we can delete /x/y since we have the lock on it. This delete removes the lock from the system. When /a/b is moved to /x/y, it still is not locked. As a user, I might expect that /a/b (which is now /x/y) has the /x/y lock, but I have always thought (from a user's perspective) that a merge would happen and not a delete followed by a write. But the fact that the lock is removed from the system, does make the rest of the scenarios work nicely Sounds reasonable. Except for one caveat. What if the resource that was at the destination also has other bindings to it. Does the lock go away... or does it drift to the other URI on that resource? Is this dependent on which URI was used when it was locked? We need to discuss this. -- BTW, there's also the academic case of the lock not being *rooted* at the destination... but inherited through another binding. I think we all agree what happens then, so it's academic. Lock token must be provided to destroy a lock. And probably to cause the lock to drift. 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. This will remove L2 from the system, and the new /x/y is still locked by L1. Sounds good. Both tokens provided. if URI's are protected. 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. Since the lock on /a/b comes from /a, the lock is not kept on its move. /a remains locked, but the new resource /x/y loses the lock it had on it. lock token needed for the *write* lock because the state of the locked collection is changing. I just wanted to note that only one URI is "protected", but because the parent collection of all the other resources in the tree are also *write locked*, all of the URI's in that tree here are essentially "protected" despite only one being officially protected. This is specific to write locks I believe. If anyone doesn't think so, we should discuss it. 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. The original /x/y is removed, and the lock on that resource is removed. /a/b is then moved there, and picks up the lock from its new parent /x/ Lock must be provided because the destination collection is write locked and is changing state. 6. Both are locked, but with separate locks. MOVE /a/b to /x/y, where /a/ has lock L1 and /b/ has lock L2. /x/y is removed and its resource is no longer locked by L2. /a/b is removed from /a's lock, and the resource is added to the L2 lock space. both tokens provided as per above. 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. I believe this must FAIL. A user cannot have 2 locks on the same resource, and therefore needs to remove one of them before the MOVE can happen. Can't have two *exclusive* locks of the same type on the same resource. Otherwise I agree. Both tokens needed. Source, if protected URI; Dest, because changing state. 8. The source collection is locked, the destination resource (not its collection) is locked with a different token MOVE /a/b to /x/y, where /a/ has lock L1, /x/ is not locked, and /x/y has lock L2. Strangely enough (to the user), this succeeds. The lock L2 is removed from the system during the DELETE phase of the move, /a/b is then moved. It is removed from /a's L1 and no lock now exists on the new /x/y Which part of this do you think is surprising to the user? Both tokens provided. Source, because state changes; dest, because presumed protected URI. Once again we can talk about drifting locks on DELETE/UNBIND's. 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. Since locks are on resources, if the correct lock-token is passed, I say this succeeds. The new /x/y is still locked via /a's lock because the binding for /a/b still exists. In order to do something to the new /x/y you need to pass the correct lock-token. If the lock is not a depth lock, then I don't think a lock token is needed because the state of /a/ is not at risk. BTW, I think when we said locks are on resources, what we really meant was that locks are *rooted* on resources. Of course we're free to evaluate any proposal. So... if it's a depth lock... I'd say that a lock token still isn't needed to carry out the MOVE. The state of no locked resource isn't at risk of changing. And I don't think the only URI that is protected is /a/, so that isn't an issue either. 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 and bound to /a/b and the new /x/y I think we disagree about providing a lock token. The state of R is not changed here, so the *write* lock on R isn't relevent. The protection on /a/b isn't relevent because the mapping from /a/b to R isn't at risk. I suggest that no token is needed. 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, but /y/z no longer maps to R so it is not locked anymore Once again, I don't think a lock token is needed. Depth lock or singleton. The only resources whose state changes are /a/ and /y/. Neither is locked. The only protected URI/mapping is /w/. It's not at risk. 10b. /w/x and /y/z map to R. /w/ is not locked, but /w/x is. MOVE /a/b to /y/z. If the correct lock-token for R is passed (through the correct IF header and tagged list), the MOVE succeeds. When it is done, /w/x is still locking R, and the new /y/z is no longer locked as it now points to a new resource R2. We probably need to work out exactly what is protected. A previous note by my indicates that it's a single URI to resource mapping that is protected. Even in today's advanced collection meeting, folks spoke of a chain of bindings being protected... rather than a mapping. (This is admittedly usually equivalent.) I say here that no token is necessary. The only resources changing states are /a/ and /y/. Neither is locked. The only URI protected is /w/x and it's mapping remains unchanged after the move. So no lock tokens are needed to pull this off. BTW, I should add... Disclaimer: What I'm suggesting in all my comments above is what I think we're proposing. It doesn't mean I've actually thought about whether what I've suggested above provides what a client would want in all of these situations. I'm only commenting on what behavior we'd expect based on our object model. Oh... Good note Kevin. From w3c-dist-auth-request@w3.org Wed Sep 15 01:17: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 BAA22829 for ; Wed, 15 Sep 1999 01:17:30 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id BAA10274; Wed, 15 Sep 1999 01:03:48 -0400 (EDT) Resent-Date: Wed, 15 Sep 1999 01:03:48 -0400 (EDT) Resent-Message-Id: <199909150503.BAA10274@www19.w3.org> From: "Kevin Wiggen" To: , Date: Tue, 14 Sep 1999 22:00:58 -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: <852567EC.00802B81.00@D51MTA07.pok.ibm.com> X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3155.0 Subject: RE: Bindings, Locks, and MOVE Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3302 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 Ahhh OK so I take back some of my last post. I am beginning to see clearer now. Correct me if I am wrong. /a/b.html and /x/y.html both point to resource R via BINDS. 1) I take out an "Exclusive Write" lock L1 on /a/b.html. Once this is done, user2 - can READ /a/b.html and /x/y.html (GET) - cannot DELETE /a/b.html (LOCKED) - can DELETE /x/y.html (will simply remove the binding) - cannot PROPPATCH /a/b.html OR /x/y.html (Resource is LOCKED) - cannot PUT /a/b.html OR /x/y.html (Resource is LOCKED) - can COPY /a/b.html and /x/y.html - cannot MOVE /a/b.html (LOCKED) - can MOVE /x/y.html (will simply move the binding URI, resource not changed) - cannot LOCK /x/y.html OR /a/b.html (LOCKED) - can PROPFIND /x/y.html and /a/b.html (its a write lock) - cannot MOVE or COPY TO /x/y.html or /a/b.html (Destination resource is LOCKED) Actually MOVE/COPY TO /x/y.html makes an interesting point of do you A) Do the delete first which UNBinds the resource and then complete the MOVE/COPY, or B) fail with resource LOCKED. I think you have to do B otherwise you end up with 2 resources where you used to have 1. 2) I take out a "Depth-Infinity Exclusive Write" lock L2 on /a. Once this is done, user2 - can READ /a/b.html and /x/y.html (GET) - cannot DELETE /a/b.html (LOCKED) - can DELETE /x/y.html (will simply remove the binding) - cannot PROPPATCH /a/b.html OR /x/y.html (Resource is LOCKED) - cannot PUT /a/b.html OR /x/y.html (Resource is LOCKED) - can COPY /a/b.html and /x/y.html - cannot MOVE /a/b.html (LOCKED) - can MOVE /x/y.html (will simply move the binding URI, resource not changed) - cannot LOCK /x/y.html or /a/b.html (LOCKED) - can PROPFIND /x/y.html and /a/b.html (its a write lock) - cannot MOVE or COPY TO /x/y.html or /a/b.html (Destination resource is LOCKED) 3) I take out a "Depth-Zero Exclusive Write" lock L3 on /a. Once this is done, user2 - can READ /a/b.html and /x/y.html (GET) - cannot DELETE /a/b.html (/a's namespace is LOCKED) - can DELETE /x/y.html (will simply remove the binding) - can PROPPATCH /a/b.html and /x/y.html (the resource is NOT Locked) - can PUT /a/b.html and /x/y.html (the resource is NOT Locked) - can COPY /a/b.html and /x/y.html - cannot MOVE /a/b.html (/a's namespace is LOCKED) - can move /x/y.html (will simply move the binding URI, resource not changed) - can LOCK /x/y.html and /a/b.html (they are not Locked) - can PROPFIND /x/y.html and /a/b.html (its a write lock) - can MOVE and COPY TO /x/y.html and /a/b.html (resource not locked) Is this correct?? Kevin From w3c-dist-auth-request@w3.org Wed Sep 15 11:47: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 LAA14724 for ; Wed, 15 Sep 1999 11:47:26 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id LAA25107; Wed, 15 Sep 1999 11:33:37 -0400 (EDT) Resent-Date: Wed, 15 Sep 1999 11:33:37 -0400 (EDT) Resent-Message-Id: <199909151533.LAA25107@www19.w3.org> Message-ID: <8E3CFBC709A8D21191A400805F15E0DBD24449@crte147.wc.eso.mc.xerox.com> From: "Slein, Judith A" To: "'Kevin Wiggen'" , ccjason@us.ibm.com, w3c-dist-auth@w3.org Date: Wed, 15 Sep 1999 11:32:53 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Bindings, Locks, and MOVE Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3303 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 like everything that you say here, but the MOVE / COPY TO cases raise a red flag for me. We claim in the bindings spec that the MOVE semantics we present is equivalent to the COPY + fixup + DELETE semantics defined in RFC 2518. But I doubt it when I look at this case. Leave aside for a minute intuitions about what should really happen, and just see what would follow from the underlying semantic model: Suppose we define MOVE as "remove the binding identified by the Request-URI and add the binding identified by the Destination header". Now consider your case: /a/b.html and /x/y.html both point to resource R, and I have an exclusive write lock on /a/b.html. User2 tries to MOVE /c/d.html (which points to some other resource S) to /x/y.html. It seems this should be possible, because all that is happening is that the binding y.html in collection /x/ is being replaced with one that binds to a different resource. Nothing happens to resource R. But if we use the COPY + fixup + DELETE semantics for MOVE, resource S would have to be duplicated, overwriting R. And this would not be allowed, because R is locked. Of course, we can legislate this problem away by, for example, accepting your proposal that a MOVE or COPY like this one fail no matter which semantics you use. But I'm afraid other cases will turn up that reveal inconsistencies between the 2 models of MOVE. --Judy > -----Original Message----- > From: Kevin Wiggen [mailto:wiggs@wiggenout.com] > Sent: Wednesday, September 15, 1999 1:01 AM > To: ccjason@us.ibm.com; w3c-dist-auth@w3.org > Subject: RE: Bindings, Locks, and MOVE > > > > Ahhh OK so I take back some of my last post. I am beginning > to see clearer > now. > > Correct me if I am wrong. > > /a/b.html and /x/y.html both point to resource R via BINDS. > > > 1) I take out an "Exclusive Write" lock L1 on /a/b.html. > Once this is > done, user2 > > - can READ /a/b.html and /x/y.html (GET) > - cannot DELETE /a/b.html (LOCKED) > - can DELETE /x/y.html (will simply remove the binding) > - cannot PROPPATCH /a/b.html OR /x/y.html (Resource is LOCKED) > - cannot PUT /a/b.html OR /x/y.html (Resource is LOCKED) > - can COPY /a/b.html and /x/y.html > - cannot MOVE /a/b.html (LOCKED) > - can MOVE /x/y.html (will simply move the binding URI, resource not > changed) > - cannot LOCK /x/y.html OR /a/b.html (LOCKED) > - can PROPFIND /x/y.html and /a/b.html (its a write lock) > - cannot MOVE or COPY TO /x/y.html or /a/b.html (Destination > resource is > LOCKED) Actually MOVE/COPY TO /x/y.html makes an interesting > point of do you > A) Do the delete first which UNBinds the resource and then > complete the > MOVE/COPY, or B) fail with resource LOCKED. I think you have to do B > otherwise you end up with 2 resources where you used to have 1. > > 2) I take out a "Depth-Infinity Exclusive Write" lock L2 on > /a. Once this > is done, user2 > > - can READ /a/b.html and /x/y.html (GET) > - cannot DELETE /a/b.html (LOCKED) > - can DELETE /x/y.html (will simply remove the binding) > - cannot PROPPATCH /a/b.html OR /x/y.html (Resource is LOCKED) > - cannot PUT /a/b.html OR /x/y.html (Resource is LOCKED) > - can COPY /a/b.html and /x/y.html > - cannot MOVE /a/b.html (LOCKED) > - can MOVE /x/y.html (will simply move the binding URI, resource not > changed) > - cannot LOCK /x/y.html or /a/b.html (LOCKED) > - can PROPFIND /x/y.html and /a/b.html (its a write lock) > - cannot MOVE or COPY TO /x/y.html or /a/b.html (Destination > resource is > LOCKED) > > 3) I take out a "Depth-Zero Exclusive Write" lock L3 on /a. > Once this is > done, user2 > > - can READ /a/b.html and /x/y.html (GET) > - cannot DELETE /a/b.html (/a's namespace is LOCKED) > - can DELETE /x/y.html (will simply remove the binding) > - can PROPPATCH /a/b.html and /x/y.html (the resource is NOT Locked) > - can PUT /a/b.html and /x/y.html (the resource is NOT Locked) > - can COPY /a/b.html and /x/y.html > - cannot MOVE /a/b.html (/a's namespace is LOCKED) > - can move /x/y.html (will simply move the binding URI, resource not > changed) > - can LOCK /x/y.html and /a/b.html (they are not Locked) > - can PROPFIND /x/y.html and /a/b.html (its a write lock) > - can MOVE and COPY TO /x/y.html and /a/b.html (resource not locked) > > Is this correct?? > > Kevin > From w3c-dist-auth-request@w3.org Wed Sep 15 13:47: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 NAA16701 for ; Wed, 15 Sep 1999 13:47:35 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id MAA28777; Wed, 15 Sep 1999 12:56:32 -0400 (EDT) Resent-Date: Wed, 15 Sep 1999 12:56:32 -0400 (EDT) Resent-Message-Id: <199909151656.MAA28777@www19.w3.org> Date: Wed, 15 Sep 1999 12:56:17 -0400 Message-Id: <9909151656.AA03476@tantalum> From: "Geoffrey M. Clemm" To: w3c-dist-auth@w3.org In-Reply-To: <8E3CFBC709A8D21191A400805F15E0DBD24449@crte147.wc.eso.mc.xerox.com> (JSlein@crt.xerox.com) Subject: Re: Bindings, Locks, and MOVE Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3304 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: "Slein, Judith A" I like everything that you say here, but the MOVE / COPY TO cases raise a red flag for me. We claim in the bindings spec that the MOVE semantics we present is equivalent to the COPY + fixup + DELETE semantics defined in RFC 2518. But I doubt it when I look at this case. The author of the statement that "MOVE is logically equivalent to COPY+fixup+DELETE" (who will remain nameless although we all know who he is :-) has publicly renounced this statement. The problem of course is the wonderfully undefined "fixup" stage. *ANY* semantics is acceptable for MOVE, for some definition of "fixup". So let's see if all is well for this case with some suitably defined value of "fixup". Leave aside for a minute intuitions about what should really happen, and just see what would follow from the underlying semantic model: Suppose we define MOVE as "remove the binding identified by the Request-URI and add the binding identified by the Destination header". Now consider your case: /a/b.html and /x/y.html both point to resource R, and I have an exclusive write lock on /a/b.html. User2 tries to MOVE /c/d.html (which points to some other resource S) to /x/y.html. It seems this should be possible, because all that is happening is that the binding y.html in collection /x/ is being replaced with one that binds to a different resource. Nothing happens to resource R. But if we use the COPY + fixup + DELETE semantics for MOVE, resource S would have to be duplicated, overwriting R. And this would not be allowed, because R is locked. It doesn't overwrite R. A COPY to an existing resource will either fail (if Overwrite=FALSE) or issue a DELETE on the destination of the COPY. The DELETE of /x/y.html succeeds just fine (since DELETE is properly defined to just remove the binding named "y.html" from the collection "/x"), the COPY proceeds, and then the "fixup" step replaces the binding to the new resource created by the COPY with a binding to R, and then a DELETE is issued on the request URL of the MOVE, which then deletes the binding named "d.html" from the collection "/c". Of course, we can legislate this problem away by, for example, accepting your proposal that a MOVE or COPY like this one fail no matter which semantics you use. But I'm afraid other cases will turn up that reveal inconsistencies between the 2 models of MOVE. I believe there are no inconsistencies here ... just suitably creative definitions of "fixup" (:-). Cheers, Geoff From w3c-dist-auth-request@w3.org Wed Sep 15 14:06: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 OAA17078 for ; Wed, 15 Sep 1999 14:06:28 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id NAA02174; Wed, 15 Sep 1999 13:53:09 -0400 (EDT) Resent-Date: Wed, 15 Sep 1999 13:53:09 -0400 (EDT) Resent-Message-Id: <199909151753.NAA02174@www19.w3.org> Message-ID: <8E3CFBC709A8D21191A400805F15E0DBD2444B@crte147.wc.eso.mc.xerox.com> From: "Slein, Judith A" To: "'Geoffrey M. Clemm'" , w3c-dist-auth@w3.org Date: Wed, 15 Sep 1999 13:52:46 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Bindings, Locks, and MOVE Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3306 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list Actually I was confused by thinking that a write lock would prevent a COPY with Destination being the locked resource. (So I thought that the COPY step wouldn't be allowed to happen.) But I see that the definition of write lock doesn't address this case. I do have trouble following your description of the fixup stage, though. I take it you don't think we face the awkward situation Kevin described, where there end up being 2 resources where there used to be only one. But how do you avoid this? Before the MOVE we have: /a/b.html /x/y.html /c/d.html \ / | \ / | \ / | R S and user1 has a lock on R through /a/b.html Now user2 attempts to MOVE /c/d.html to /x/y.html. First the binding y.html is removed from collection /x/. Then S is duplicated, say to S' and a new binding y.html is created in /x/ to S'. That's the COPY step. At this point we have: /a/b.html /x/y.html /c/d.html | | | | | | R S' S The DELETE step is to remove the binding d.html from /c/. It doesn't look as if there needs to be any fixup, but we do have the awkward result that we now have 2 resources R and S' where there used to be just R. --Judy > -----Original Message----- > From: Geoffrey M. Clemm [mailto:gclemm@tantalum.atria.com] > Sent: Wednesday, September 15, 1999 12:56 PM > To: w3c-dist-auth@w3.org > Subject: Re: Bindings, Locks, and MOVE > > > > From: "Slein, Judith A" > > I like everything that you say here, but the MOVE / COPY > TO cases raise a > red flag for me. We claim in the bindings spec that the > MOVE semantics we > present is equivalent to the COPY + fixup + DELETE > semantics defined in RFC > 2518. But I doubt it when I look at this case. > > The author of the statement that "MOVE is logically equivalent > to COPY+fixup+DELETE" (who will remain nameless although we all know > who he is :-) has publicly renounced this statement. The problem of > course is the wonderfully undefined "fixup" stage. *ANY* semantics is > acceptable for MOVE, for some definition of "fixup". So let's see if > all is well for this case with some suitably defined value of "fixup". > > Leave aside for a minute intuitions about what should > really happen, and > just see what would follow from the underlying semantic model: > > Suppose we define MOVE as "remove the binding identified > by the Request-URI > and add the binding identified by the Destination header". > > Now consider your case: /a/b.html and /x/y.html both point > to resource R, > and I have an exclusive write lock on /a/b.html. User2 > tries to MOVE > /c/d.html (which points to some other resource S) to > /x/y.html. It seems > this should be possible, because all that is happening is > that the binding > y.html in collection /x/ is being replaced with one that binds to a > different resource. Nothing happens to resource R. > > But if we use the COPY + fixup + DELETE semantics for > MOVE, resource S would > have to be duplicated, overwriting R. And this would not > be allowed, > because R is locked. > > It doesn't overwrite R. A COPY to an existing resource will > either fail (if Overwrite=FALSE) or issue a DELETE on the destination > of the COPY. The DELETE of /x/y.html succeeds just fine (since DELETE > is properly defined to just remove the binding named "y.html" from the > collection "/x"), the COPY proceeds, and then the "fixup" step > replaces the binding to the new resource created by the COPY with a > binding to R, and then a DELETE is issued on the request URL of the > MOVE, which then deletes the binding named "d.html" from the > collection "/c". > > Of course, we can legislate this problem away by, for > example, accepting > your proposal that a MOVE or COPY like this one fail no > matter which > semantics you use. But I'm afraid other cases will turn > up that reveal > inconsistencies between the 2 models of MOVE. > > I believe there are no inconsistencies here ... just > suitably creative > definitions of "fixup" (:-). > > Cheers, > Geoff > From w3c-dist-auth-request@w3.org Wed Sep 15 14:16: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 OAA17160 for ; Wed, 15 Sep 1999 14:16:21 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id OAA02562; Wed, 15 Sep 1999 14:03:40 -0400 (EDT) Resent-Date: Wed, 15 Sep 1999 14:03:40 -0400 (EDT) Resent-Message-Id: <199909151803.OAA02562@www19.w3.org> From: ccjason@us.ibm.com X-Lotus-FromDomain: IBMUS To: "Kevin Wiggen" cc: w3c-dist-auth@w3.org Message-ID: <852567ED.00632B22.00@D51MTA07.pok.ibm.com> Date: Wed, 15 Sep 1999 14:09:58 -0400 Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Subject: RE: Bindings, Locks, and MOVE Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3307 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'll just respond to take what Judith and Geoff just said and apply it directly to Kevin's example... Ahhh OK so I take back some of my last post. I am beginning to see clearer now. Correct me if I am wrong. /a/b.html and /x/y.html both point to resource R via BINDS. 1) I take out an "Exclusive Write" lock L1 on /a/b.html. Once this is done, user2 - can READ /a/b.html and /x/y.html (GET) - cannot DELETE /a/b.html (LOCKED) - can DELETE /x/y.html (will simply remove the binding) - cannot PROPPATCH /a/b.html OR /x/y.html (Resource is LOCKED) - cannot PUT /a/b.html OR /x/y.html (Resource is LOCKED) - can COPY /a/b.html and /x/y.html - cannot MOVE /a/b.html (LOCKED) - can MOVE /x/y.html (will simply move the binding URI, resource not changed) - cannot LOCK /x/y.html OR /a/b.html (LOCKED) - can PROPFIND /x/y.html and /a/b.html (its a write lock) - cannot MOVE or COPY TO /x/y.html or /a/b.html (Destination resource is LOCKED) Actually MOVE/COPY TO /x/y.html makes an interesting point of do you A) Do the delete first which UNBinds the resource and then complete the MOVE/COPY, or B) fail with resource LOCKED. I think you have to do B otherwise you end up with 2 resources where you used to have 1. I think the point of COPY is to create more resources. So unless I misunderstand you, the COPY/MOVE to /x/y.html would ba allowed. In the case of MOVE... I think you end up with the same number that you started with. IOW's both operations would be allowed. BTW, I think it's important to highlight the fact that as currently defined, the destination of a COPY/DELETE is implicitly DELETED as the first substep of carrying out the method. 2) I take out a "Depth-Infinity Exclusive Write" lock L2 on /a. Once this is done, user2 - can READ /a/b.html and /x/y.html (GET) - cannot DELETE /a/b.html (LOCKED) - can DELETE /x/y.html (will simply remove the binding) - cannot PROPPATCH /a/b.html OR /x/y.html (Resource is LOCKED) - cannot PUT /a/b.html OR /x/y.html (Resource is LOCKED) - can COPY /a/b.html and /x/y.html - cannot MOVE /a/b.html (LOCKED) - can MOVE /x/y.html (will simply move the binding URI, resource not changed) - cannot LOCK /x/y.html or /a/b.html (LOCKED) - can PROPFIND /x/y.html and /a/b.html (its a write lock) - cannot MOVE or COPY TO /x/y.html or /a/b.html (Destination resource is LOCKED) Same as above. I believe you can copy/move to /x/y.html 3) I take out a "Depth-Zero Exclusive Write" lock L3 on /a. Once this is done, user2 - can READ /a/b.html and /x/y.html (GET) - cannot DELETE /a/b.html (/a's namespace is LOCKED) - can DELETE /x/y.html (will simply remove the binding) - can PROPPATCH /a/b.html and /x/y.html (the resource is NOT Locked) - can PUT /a/b.html and /x/y.html (the resource is NOT Locked) - can COPY /a/b.html and /x/y.html - cannot MOVE /a/b.html (/a's namespace is LOCKED) - can move /x/y.html (will simply move the binding URI, resource not changed) - can LOCK /x/y.html and /a/b.html (they are not Locked) - can PROPFIND /x/y.html and /a/b.html (its a write lock) - can MOVE and COPY TO /x/y.html and /a/b.html (resource not locked) I believe that final MOVE/COPY is not allowed against /a/b.html because it's preceeded by an implicit delete which affects that state of /a/ which is locked. From w3c-dist-auth-request@w3.org Wed Sep 15 14:22:43 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 OAA17362 for ; Wed, 15 Sep 1999 14:22:42 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id OAA02913; Wed, 15 Sep 1999 14:09:30 -0400 (EDT) Resent-Date: Wed, 15 Sep 1999 14:09:30 -0400 (EDT) Resent-Message-Id: <199909151809.OAA02913@www19.w3.org> Message-ID: <8E3CFBC709A8D21191A400805F15E0DBD2444C@crte147.wc.eso.mc.xerox.com> From: "Slein, Judith A" To: "'WebDAV'" Date: Wed, 15 Sep 1999 14:08:29 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Subject: Guaranteeing the Integrity of Bindings Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3308 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list Another in the series of messages about advanced collection design team proposals: Jim Amsden in his comments on the advanced collections spec said that he believes it is never possible to guarantee the integrity of bindings that cross servers. So requiring servers to guarantee the integrity of any binding that they allow to be created will have the result that no one will ever implement cross-server bindings. The kind of case he had in mind (I think) was one where the server where the resource resides becomes inaccessible to the server where bindings resides. So at least while the 2 servers are out of touch, the binding will be broken. We think that it is not impossible to guarantee integrity of bindings even in cases like this, if the server is willing to take enough trouble. It can store a copy of the target resource locally, and insure that no changes are allowed except when both servers are accessible. We agree that it is unlikely that cross-server bindings will be supported because of the difficulty of guaranteeing integrity, but we do want to insist the servers fail BIND requests where they can't guarantee integrity of the binding. (We are planning to remove all normative language about cross-server bindings, but just keep the generic statement that integrity of bindings has to be guaranteed.) If you don't care so much about integrity, and do want cross-server referencing, then redirect references are the better tool to use. --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 Sep 15 14: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 OAA17416 for ; Wed, 15 Sep 1999 14:25:52 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id OAA03015; Wed, 15 Sep 1999 14:12:54 -0400 (EDT) Resent-Date: Wed, 15 Sep 1999 14:12:54 -0400 (EDT) Resent-Message-Id: <199909151812.OAA03015@www19.w3.org> Message-ID: <37DFE178.37F6C062@ecal.com> Date: Wed, 15 Sep 1999 14:12:08 -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: <8E3CFBC709A8D21191A400805F15E0DBD2444A@crte147.wc.eso.mc.xerox.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: Resource-Type and Ref-Target Headers Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3309 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: > We were using Resource-Type only in 302 responses from redirect references. > Resource-Type was only there to let the client know that it was not getting > a 302 response from a plain HTTP resource, but rather a response from a > redirect reference. We can convey the same information by returning the > DAV:reftarget property in the response body. The presence of that property > indicates that the response is from a redirect reference. This is incompatible with a recommendation in RFC-2616 (section 10.3.3, second paragraph): Unless the request method was HEAD, the entity of the response SHOULD contain a short hypertext note with a hyperlink to the new URI(s). Do we want to override this? It's to provide pseudo-compatibility with old or broken browsers that don't understand 302. (Personally, I suspect we don't need to provide the resource type information on every request. It's available via PROPFIND with Passthrough: T; clients that need to know can find out.) -- /=================================================================\ |John Stracke | http://www.ecal.com |My opinions are my own. | |Chief Scientist |================================================| |eCal Corp. |I'm on a Mission From God to Save The World from| |francis@ecal.com|megalomania! | \=================================================================/ From w3c-dist-auth-request@w3.org Wed Sep 15 14:32: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 OAA17545 for ; Wed, 15 Sep 1999 14:32:19 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id OAA03497; Wed, 15 Sep 1999 14:19:28 -0400 (EDT) Resent-Date: Wed, 15 Sep 1999 14:19:28 -0400 (EDT) Resent-Message-Id: <199909151819.OAA03497@www19.w3.org> Message-ID: <8E3CFBC709A8D21191A400805F15E0DBD2444D@crte147.wc.eso.mc.xerox.com> From: "Slein, Judith A" To: "'WebDAV'" Date: Wed, 15 Sep 1999 14:19:06 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Subject: BIND Error Codes Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3310 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list Another in the series of messages from the advanced collections design team: We've agreed to remove all normative language about cross-server bindings, but we do think it would be useful to say something about the reason why a binding cannot be created, especially in the case of an attempt to create a cross-server binding. We haven't been able to agree on how best to do this. Currently the binding spec says that if the server can't guarantee the required binding behavior, it must fail the BIND request with a 501 (Not Implemented). Period. No further explanation. We could just leave it at that, but we think it would be useful to the client to know that the reason the BIND can't be done is that the server can't guarantee integrity of bindings to resources on another server (for example). We could use a different (new) error code for "Can't create cross-server binding." We could stick with 501, but provide further explanation in the response body. We could leave the spec as it is. Any preferences? --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 Sep 15 14:32: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 OAA17559 for ; Wed, 15 Sep 1999 14:32:52 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id OAA03544; Wed, 15 Sep 1999 14:20:22 -0400 (EDT) Resent-Date: Wed, 15 Sep 1999 14:20:22 -0400 (EDT) Resent-Message-Id: <199909151820.OAA03544@www19.w3.org> Message-ID: <37DFE348.C1DA85D9@ecal.com> Date: Wed, 15 Sep 1999 14:19:53 -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: <8E3CFBC709A8D21191A400805F15E0DBD2444C@crte147.wc.eso.mc.xerox.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: Guaranteeing the Integrity of Bindings Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3311 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: > We think that it is not impossible to guarantee integrity of bindings even > in cases like this, if the server is willing to take enough trouble. It can > store a copy of the target resource locally, and insure that no changes are > allowed except when both servers are accessible. It may not be feasible to make a copy of a dynamic resource. -- /=================================================================\ |John Stracke | http://www.ecal.com |My opinions are my own. | |Chief Scientist |================================================| |eCal Corp. |"Genius, Brain! But what if the dragon eats us?"| |francis@ecal.com|"That would alter our plans." | \=================================================================/ From w3c-dist-auth-request@w3.org Wed Sep 15 14:42: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 OAA17710 for ; Wed, 15 Sep 1999 14:42:52 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id NAA00198; Wed, 15 Sep 1999 13:22:09 -0400 (EDT) Resent-Date: Wed, 15 Sep 1999 13:22:09 -0400 (EDT) Resent-Message-Id: <199909151722.NAA00198@www19.w3.org> Message-ID: <8E3CFBC709A8D21191A400805F15E0DBD2444A@crte147.wc.eso.mc.xerox.com> From: "Slein, Judith A" To: "'WebDAV'" Date: Wed, 15 Sep 1999 13:22:08 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Subject: Resource-Type and Ref-Target Headers Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3305 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 the first of a series of messages reporting on proposals from the advanced collections design team. This one concerns reducing the number of new headers defined in the bindings and redirect references specs. Yaron suggested getting rid of the Resource-Type header because headers are not good for representing structured information, and we can anticipate that sooner or later we will want to put structured information into Resource-Type. Instead, we should put the information into an XML message body. Jim Amsden suggested getting rid of one or more of Destination, Location, and Ref-Target, since these headers all seem to carry similar information. We would like to get rid of both Resource-Type and Ref-Target, replacing them with the DAV:reftarget property in the message body. We were using Resource-Type only in 302 responses from redirect references. Resource-Type was only there to let the client know that it was not getting a 302 response from a plain HTTP resource, but rather a response from a redirect reference. We can convey the same information by returning the DAV:reftarget property in the response body. The presence of that property indicates that the response is from a redirect reference. We were using Ref-Target only in MKREF requests, to identify the resource that is the target of the reference being created. Again, the same information can be conveyed in the message body with the DAV:reftarget property. The value of DAV:reftarget differs from either Destination or Location in that a relative URL is allowed in DAV:reftarget. We didn't invent Destination or Location. We use Location because HTTP requires it to be present on a 302 response. We use Destination with the BIND request because it seemed like a good fit with the existing header, which was originally defined for use with MOVE and COPY. --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 Sep 15 15:00: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 PAA17879 for ; Wed, 15 Sep 1999 15:00:40 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id OAA04960; Wed, 15 Sep 1999 14:47:47 -0400 (EDT) Resent-Date: Wed, 15 Sep 1999 14:47:47 -0400 (EDT) Resent-Message-Id: <199909151847.OAA04960@www19.w3.org> From: ccjason@us.ibm.com X-Lotus-FromDomain: IBMUS To: "Slein, Judith A" cc: w3c-dist-auth@w3.org, "'Geoffrey M. Clemm'" Message-ID: <852567ED.00673430.00@D51MTA07.pok.ibm.com> Date: Wed, 15 Sep 1999 14:54:08 -0400 Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Subject: RE: Bindings, Locks, and MOVE Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3312 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list Actually I was confused by thinking that a write lock would prevent a COPY with Destination being the locked resource. (So I thought that the COPY step wouldn't be allowed to happen.) But I see that the definition of write lock doesn't address this case. I do have trouble following your description of the fixup stage, though. I take it you don't think we face the awkward situation Kevin described, where there end up being 2 resources where there used to be only one. But how do you avoid this? Before the MOVE we have: /a/b.html /x/y.html /c/d.html \ / | \ / | \ / | R S and user1 has a lock on R through /a/b.html Now user2 attempts to MOVE /c/d.html to /x/y.html. First the binding y.html is removed from collection /x/. Then S is duplicated, say to S' and a new binding y.html is created in /x/ to S'. That's the COPY step. At this point we have: /a/b.html /x/y.html /c/d.html | | | | | | R S' S The DELETE step is to remove the binding d.html from /c/. It doesn't look as if there needs to be any fixup, but we do have the awkward result that we now have 2 resources R and S' where there used to be just R. I have to agree that I couldn't quite understand what GC meant by "fixup" since it seemed none was necessary. I also don't understand what you are saying about extra resources. We began with R and S. In a COPY we end with R, S, and S'. That's one more resource than we started with, but it's a "copy", so we should be surprised if that means there's one more new resource in the world. It's the same thing that we see when we go to a xerox/copy (:-)) machine. We walk go there with one copy of a document and walk away with two. As for the MOVE, we start with two resources and end with two. No surprise once again. The only surprise might be that some folks might intuitively think of a MOVE/COPY as replacing of the destination's state, but since we say it deletes the destination first, what we see isn't a change of state... but a change of resource at the destination. From w3c-dist-auth-request@w3.org Wed Sep 15 15:06: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 PAA18011 for ; Wed, 15 Sep 1999 15:06:20 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id OAA05066; Wed, 15 Sep 1999 14:53:32 -0400 (EDT) Resent-Date: Wed, 15 Sep 1999 14:53:32 -0400 (EDT) Resent-Message-Id: <199909151853.OAA05066@www19.w3.org> Message-ID: <8E3CFBC709A8D21191A400805F15E0DBD2444E@crte147.wc.eso.mc.xerox.com> From: "Slein, Judith A" To: "'WebDAV'" Date: Wed, 15 Sep 1999 14:53:13 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Subject: Trailing "/" in BIND Requests Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3313 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list Both Yaron and Jim Amsden our attempts to enforce consistency between the Request-URI and the Destination header in BIND requests are not appropriate. We wanted to say that either both must end in a "/" or neither may end in a "/". But in reality a trailing "/" is not a reliable indicator of the type of resource being addressed, so we should allow servers to process BIND requests even if the Request-URI ends in "/" and the Destination header does not, or vice versa. We agree with these comments and will remove the constraints from the description of the BIND method and the related examples. Yaron also objected to our saying that the Request-URI cannot just consist of "/". That is, we currently say that you cannot use BIND to create a binding between the root and some resource. We say this because we define a binding to be a relation between a URI segment in its parent collection and some resource. That is, it's the triple (segment, collection, resource). Here there is no segment, and there is no parent collection. So you can't make sense of creating a binding for "/". --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 Sep 15 15:37:50 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 PAA19108 for ; Wed, 15 Sep 1999 15:37:49 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id PAA06147; Wed, 15 Sep 1999 15:24:43 -0400 (EDT) Resent-Date: Wed, 15 Sep 1999 15:24:43 -0400 (EDT) Resent-Message-Id: <199909151924.PAA06147@www19.w3.org> Date: Wed, 15 Sep 1999 12:21:04 -0700 From: Kevin Wiggen In-reply-to: <852567ED.00673430.00@D51MTA07.pok.ibm.com> To: ccjason@us.ibm.com, "Slein, Judith A" Cc: w3c-dist-auth@w3.org, "'Geoffrey M. Clemm'" Message-id: MIME-version: 1.0 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Content-type: text/plain; charset="iso-8859-1" Content-transfer-encoding: 7bit Importance: Normal X-MSMail-Priority: Normal X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3155.0 X-Priority: 3 (Normal) Subject: RE: Bindings, Locks, and MOVE Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3315 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 knew that the "Delete/Make New Resource" vrs "Merge" would come to haunt me one day. Kevin and John are working on a project. John creates a file /~john/projectX/fgd/dfgdfg/dfgdg/spec.html Kevin thinks john is long-winded and simply creates a bind to the resource /~kwiggen/projectX/spec.html Now they both can view/update the file, as they are working together. If Kevin does a PUT to his Bind, it will replace the file and John will see the update. However if Kevin tries to simply COPY or MOVE /~kwiggen/projectX/spec_mine.html to /~kwiggen/projectX/spec.html, his BIND will be deleted, and Kevin and John will no longer be working on the same document. All this and Kevin and John will probably not be any the wiser and blame each other for lack of updates :) I believe this is a major FLAW with MOVE/COPY and it really comes out in BIND. If the purpose is to have the ability for the same resource to exist in the namespace hierarchy (as the spec states in its introduction), then I would assume that BINDS last through MOVE/COPY just as they do through PUT and PROPPATCH. The overwrite flag does not help in this situation. If it is false, it means do not overwrite as before. Overwrite to T means "Create me my own resource" in this case, and I believe that is not the intended behavior of the user. 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: Wednesday, September 15, 1999 11:54 AM To: Slein, Judith A Cc: w3c-dist-auth@w3.org; 'Geoffrey M. Clemm' Subject: RE: Bindings, Locks, and MOVE Actually I was confused by thinking that a write lock would prevent a COPY with Destination being the locked resource. (So I thought that the COPY step wouldn't be allowed to happen.) But I see that the definition of write lock doesn't address this case. I do have trouble following your description of the fixup stage, though. I take it you don't think we face the awkward situation Kevin described, where there end up being 2 resources where there used to be only one. But how do you avoid this? Before the MOVE we have: /a/b.html /x/y.html /c/d.html \ / | \ / | \ / | R S and user1 has a lock on R through /a/b.html Now user2 attempts to MOVE /c/d.html to /x/y.html. First the binding y.html is removed from collection /x/. Then S is duplicated, say to S' and a new binding y.html is created in /x/ to S'. That's the COPY step. At this point we have: /a/b.html /x/y.html /c/d.html | | | | | | R S' S The DELETE step is to remove the binding d.html from /c/. It doesn't look as if there needs to be any fixup, but we do have the awkward result that we now have 2 resources R and S' where there used to be just R. I have to agree that I couldn't quite understand what GC meant by "fixup" since it seemed none was necessary. I also don't understand what you are saying about extra resources. We began with R and S. In a COPY we end with R, S, and S'. That's one more resource than we started with, but it's a "copy", so we should be surprised if that means there's one more new resource in the world. It's the same thing that we see when we go to a xerox/copy (:-)) machine. We walk go there with one copy of a document and walk away with two. As for the MOVE, we start with two resources and end with two. No surprise once again. The only surprise might be that some folks might intuitively think of a MOVE/COPY as replacing of the destination's state, but since we say it deletes the destination first, what we see isn't a change of state... but a change of resource at the destination. From w3c-dist-auth-request@w3.org Wed Sep 15 15:39: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 PAA19138 for ; Wed, 15 Sep 1999 15:39:32 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id PAA06237; Wed, 15 Sep 1999 15:26:32 -0400 (EDT) Resent-Date: Wed, 15 Sep 1999 15:26:32 -0400 (EDT) Resent-Message-Id: <199909151926.PAA06237@www19.w3.org> Message-ID: <8E3CFBC709A8D21191A400805F15E0DBD24450@crte147.wc.eso.mc.xerox.com> From: "Slein, Judith A" To: "'WebDAV'" Date: Wed, 15 Sep 1999 15:26:19 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Subject: Bindings and Other Methods (Section 10) Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3316 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 Section 10 of the Bindings spec we specify how bindings interact with the vast majority of HTTP and WebDAV methods (GET, HEAD, PUT, POST, OPTIONS, PROPFIND, PROPPATCH, ORDERPATCH). We would like to say the simple, straightforward thing: That for any of these methods, the results of applying the method through one binding are identical to the results of applying the same method with the same headers and body through another bindings to the same resource. What prevents us from saying this are executable resources, which generate responses dynamically and may be sensitive to which Request-URI is used to access them. If we try to take these executable resources into account, we are reduced to saying things that are so open-ended that they place no enforceable constraints on the behavior of GET, PUT, etc., when applied through different bindings to the same resource. So in the interest of being able to place useful constraints the behavior of these methods on alternative bindings to the same resource, we propose to say: The results of applying method XXX through one binding are identical to the results of applying XXX with the same headers and the same message body through any other binding to the same resource. The server MUST fail any BIND request for which it cannot guarantee this behavior. The upshot of this statement will be that it will not be possible to create bindings to executable resources that produce dynamic results. --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 Sep 15 15:41: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 PAA19163 for ; Wed, 15 Sep 1999 15:41:07 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id PAA06353; Wed, 15 Sep 1999 15:28:41 -0400 (EDT) Resent-Date: Wed, 15 Sep 1999 15:28:41 -0400 (EDT) Resent-Message-Id: <199909151928.PAA06353@www19.w3.org> Message-ID: <37DFF332.FCF9172A@ecal.com> Date: Wed, 15 Sep 1999 15:27:47 -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: <852567ED.006A4EC5.00@D51MTA07.pok.ibm.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: Guaranteeing the Integrity of Bindings Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3317 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 ccjason@us.ibm.com wrote: > > > We think that it is not impossible to guarantee integrity of bindings even > > > in cases like this, if the server is willing to take enough trouble. It can > > > store a copy of the target resource locally, and insure that no changes are > > > allowed except when both servers are accessible. > > > It may not be feasible to make a copy of a dynamic resource. > > > We've barely discussed dynamic resources in general. It doesn't take much discussion to realize that copying a dynamic resource is not something that can ever be expressed in a standard protocol; they're far too implementation-dependent. -- /================================================================\ |John Stracke | http://www.ecal.com |My opinions are my own. | |Chief Scientist |===============================================| |eCal Corp. |"Your reality, sir, is lies & balderdash, and I| |francis@ecal.com|am pleased to say I have no grasp on it | | |whatsoever!" --Baron Munchausen | \================================================================/ From w3c-dist-auth-request@w3.org Wed Sep 15 15:48: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 PAA19110 for ; Wed, 15 Sep 1999 15:37:50 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id PAA06086; Wed, 15 Sep 1999 15:21:42 -0400 (EDT) Resent-Date: Wed, 15 Sep 1999 15:21:42 -0400 (EDT) Resent-Message-Id: <199909151921.PAA06086@www19.w3.org> From: ccjason@us.ibm.com X-Lotus-FromDomain: IBMUS To: John Stracke cc: "'WebDAV'" Message-ID: <852567ED.006A4EC5.00@D51MTA07.pok.ibm.com> Date: Wed, 15 Sep 1999 15:27:56 -0400 Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Subject: Re: Guaranteeing the Integrity of Bindings Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3314 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 think that it is not impossible to guarantee integrity of bindings even > > in cases like this, if the server is willing to take enough trouble. It can > > store a copy of the target resource locally, and insure that no changes are > > allowed except when both servers are accessible. > It may not be feasible to make a copy of a dynamic resource. We've barely discussed dynamic resources in general. They need just as much clarification and cleanup as locks do/did, but we're not going to be able to cover them before the end of the month and I believe that's the deadline we face for the webdav base spec. I think until we do get that defined, server implementers are just going to have to experiment with their own ideas about dynamic (content) resources. As for COPY/MOVE'ing them. For now we'll just have to leave implementors with the guidelines that we have now. If they don't think they can support them (or anything else), then they need to reject requests that require they support them. They are going to need to make some judgement calls here. When we come back to dynamic resources, we can be more specific about what is expected. From w3c-dist-auth-request@w3.org Wed Sep 15 15:49: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 PAA19282 for ; Wed, 15 Sep 1999 15:49:23 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id PAA06843; Wed, 15 Sep 1999 15:36:47 -0400 (EDT) Resent-Date: Wed, 15 Sep 1999 15:36:47 -0400 (EDT) Resent-Message-Id: <199909151936.PAA06843@www19.w3.org> Message-ID: <37DFF521.F4FD6F1C@ecal.com> Date: Wed, 15 Sep 1999 15:36:01 -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: <8E3CFBC709A8D21191A400805F15E0DBD2444C@crte147.wc.eso.mc.xerox.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: Guaranteeing the Integrity of Bindings Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3318 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: > Jim Amsden in his comments on the advanced collections spec said that he > believes it is never possible to guarantee the integrity of bindings that > cross servers. So requiring servers to guarantee the integrity of any > binding that they allow to be created will have the result that no one will > ever implement cross-server bindings. > > The kind of case he had in mind (I think) was one where the server where the > resource resides becomes inaccessible to the server where bindings resides. > So at least while the 2 servers are out of touch, the binding will be > broken. Actually, it's more than that. You're (apparently) presuming that the servers can come up with some way of making DELETE on the resource trigger a DELETE on the binding. But suppose the resource is just a file, and it gets deleted from outside the server? I am not aware of any OS where you can get notification when a file is deleted. In the single-server case, this is not a problem, because the server can check to make sure the resource still exists before doing anything to indicate that the binding exists. In the cross-server case...well, you could still do it, but it'd make things like PROPFIND expensive (if a collection contains 15 cross-server bindings, you've got to do 15 HTTP requests to make sure they're all still there). -- /================================================================\ |John Stracke | http://www.ecal.com |My opinions are my own. | |Chief Scientist |===============================================| |eCal Corp. |I'm not a bibliophile, I'm a bibliophiliac. Put| |francis@ecal.com|me in a bookstore, & my wallet bleeds. | \================================================================/ From w3c-dist-auth-request@w3.org Wed Sep 15 15:55:30 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 PAA19381 for ; Wed, 15 Sep 1999 15:55:30 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id PAA07253; Wed, 15 Sep 1999 15:43:03 -0400 (EDT) Resent-Date: Wed, 15 Sep 1999 15:43:03 -0400 (EDT) Resent-Message-Id: <199909151943.PAA07253@www19.w3.org> Message-ID: <37DFF696.3BDDB6DD@ecal.com> Date: Wed, 15 Sep 1999 15:42:14 -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: <8E3CFBC709A8D21191A400805F15E0DBD24450@crte147.wc.eso.mc.xerox.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: Bindings and Other Methods (Section 10) Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3319 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: > e would like to say the simple, straightforward thing: That for any of > these methods, the results of applying the method through one binding are > identical to the results of applying the same method with the same headers > and body through another bindings to the same resource. > > What prevents us from saying this are executable resources, which generate > responses dynamically and may be sensitive to which Request-URI is used to > access them. If we try to take these executable resources into account, we > are reduced to saying things that are so open-ended that they place no > enforceable constraints on the behavior of GET, PUT, etc., when applied > through different bindings to the same resource. Why exactly is this a problem? Me, I'd consider it a feature; if I write code that's sensitive to the Request-URI, it's probably for a good reason. I may want to be able to write a script once and place bindings to it in different places that behave differently according to their location. In fact, I *have* written such a script. On my personal site, I don't have access to the logs, so I've placed index.cgi scripts in various directories that I want to monitor; they log the hit and return a 302 to redirect to Index.html. Since I didn't want to maintain N copies of the script, most of them are symlinks. Since the 302 requires an absolute URI, the script looks at the Request-URI to figure out where to redirect to. -- /==============================================================\ |John Stracke | http://www.ecal.com |My opinions are my own.| |Chief Scientist |=============================================| |eCal Corp. |Round up the usual disclaimers. | |francis@ecal.com| | \==============================================================/ From w3c-dist-auth-request@w3.org Wed Sep 15 16:19: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 QAA19756 for ; Wed, 15 Sep 1999 16:19:24 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id QAA08367; Wed, 15 Sep 1999 16:02:32 -0400 (EDT) Resent-Date: Wed, 15 Sep 1999 16:02:32 -0400 (EDT) Resent-Message-Id: <199909152002.QAA08367@www19.w3.org> Message-ID: <8E3CFBC709A8D21191A400805F15E0DBD24451@crte147.wc.eso.mc.xerox.com> From: "Slein, Judith A" To: "'WebDAV'" Date: Wed, 15 Sep 1999 16:02:09 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Subject: Proposal on MOVE and locks Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3320 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 a result of the discussions on the mailing list over the past week, the design team would like to make some changes in its proposal about MOVE and locks. We agree that we should not be specifying any different behavior for cross-server MOVEs than for MOVEs on the same server. So we plan to take out all normative language related to cross-server MOVEs. We do want to stand by our basic position that locks MOVE with a resource, since that is consistent with the underlying semantic model of bindings. A MOVE has no effect on the resource, but only involves creating a new binding between the final segment of the Destination URI in its collection and the resource, and removing the binding between the final segment of the Request-URI in its collection and the resource. The state of the resource itself -- including its lock state -- is unchanged. That leaves us with the following: For MOVE (assuming that the principal performing the MOVE owns all locks involved): 1. If there is a lock on the source resource that is rooted at the source resource (that is, the lock is not inherited from a parent collection), the lock moves with the resource to the destination. 2. If there is a lock on the destination resource that is rooted at the destination resource (that is, the lock is not inherited from a parent collection), its lock is gone after the MOVE. 3. If the source resource inherits a lock from a parent collection, and the resource is moved out of the tree affected by that lock, the lock no longer applies to the resource after the MOVE. 4. If the destination resource inherits a lock from a parent collection, the MOVEd resource inherits that lock after the MOVE. 5. If there is a lock on the source resource that is rooted at the source resource, and the destination resource inherits a lock from a parent collection, the MOVE fails due to a conflict between rules 1 and 4. 6. If a collection is MOVEd, and there are some locked resources in that collection, the locks on those resources move with the resources. For COPY: After the COPY, there will be no locks at the destination except what is inherited from above. Judith A. Slein XR&T/Xerox Architecture Center jslein@crt.xerox.com 8*222-5169 From w3c-dist-auth-request@w3.org Wed Sep 15 16:33: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 QAA19991 for ; Wed, 15 Sep 1999 16:33:49 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id QAA08974; Wed, 15 Sep 1999 16:21:22 -0400 (EDT) Resent-Date: Wed, 15 Sep 1999 16:21:22 -0400 (EDT) Resent-Message-Id: <199909152021.QAA08974@www19.w3.org> Message-ID: <8E3CFBC709A8D21191A400805F15E0DBD24453@crte147.wc.eso.mc.xerox.com> From: "Slein, Judith A" To: "'WebDAV'" Date: Wed, 15 Sep 1999 16:20:35 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Subject: Clarification of "Optional" for DAV:bindings Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3322 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 Amsden asked for clarification of what the spec authors mean by saying that the DAV:bindings property is optional. Like everything else in WebDAV, the property is optional per resource. It could be that some resources on a server have the DAV:bindings property, but other resources on the same server do not. If the property is present, it is required to have a complete list of all bindings to the resource. We think that this is possible because we require a guarantee of integrity for bindings. That guarantee can't be made unless the resource knows about all the bindings to it. --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 Sep 15 17:14: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 RAA20701 for ; Wed, 15 Sep 1999 17:14:39 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id RAA10696; Wed, 15 Sep 1999 17:02:00 -0400 (EDT) Resent-Date: Wed, 15 Sep 1999 17:02:00 -0400 (EDT) Resent-Message-Id: <199909152102.RAA10696@www19.w3.org> Date: Wed, 15 Sep 1999 17:01:47 -0400 Message-Id: <9909152101.AA03652@tantalum> From: "Geoffrey M. Clemm" To: w3c-dist-auth@w3.org In-Reply-To: <8E3CFBC709A8D21191A400805F15E0DBD2444B@crte147.wc.eso.mc.xerox.com> (JSlein@crt.xerox.com) Subject: Re: Bindings, Locks, and MOVE Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3323 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: "Slein, Judith A" I do have trouble following your description of the fixup stage, though. I take it you don't think we face the awkward situation Kevin described, where there end up being 2 resources where there used to be only one. But how do you avoid this? That's right. That's what the "fixup" step takes care of. Before the MOVE we have: /a/b.html /x/y.html /c/d.html \ / | \ / | \ / | R S and user1 has a lock on R through /a/b.html Yup. Now user2 attempts to MOVE /c/d.html to /x/y.html. First the binding y.html is removed from collection /x/. Then S is duplicated, say to S' and a new binding y.html is created in /x/ to S'. That's the COPY step. At this point we have: /a/b.html /x/y.html /c/d.html | | | | | | R S' S Yup again. The DELETE step is to remove the binding d.html from /c/. It doesn't look as if there needs to be any fixup, but we do have the awkward result that we now have 2 resources R and S' where there used to be just R. And that awkward result is exactly what the fixup step "fixes up", namely before the DELETE on /c/d.html, it issues a DELETE on /x/y.html and then creates a binding to S named "y.html" in the collection "/x". So immediately after the fixup step you have: /a/b.html /x/y.html /c/d.html | \ / | \ / R S A MOVE at the very least must guarantee that the GUID property of a resource remains the same after a MOVE, and the only way that can be is if /x/y.html is mapped to S (and not some copy of S) after the MOVE successfully completes. Cheers, Geoff -----Original Message----- From: Geoffrey M. Clemm [mailto:gclemm@tantalum.atria.com] From: "Slein, Judith A" I like everything that you say here, but the MOVE / COPY TO cases raise a red flag for me. We claim in the bindings spec that the MOVE semantics we present is equivalent to the COPY + fixup + DELETE semantics defined in RFC 2518. But I doubt it when I look at this case. The author of the statement that "MOVE is logically equivalent to COPY+fixup+DELETE" (who will remain nameless although we all know who he is :-) has publicly renounced this statement. The problem of course is the wonderfully undefined "fixup" stage. *ANY* semantics is acceptable for MOVE, for some definition of "fixup". So let's see if all is well for this case with some suitably defined value of "fixup". Leave aside for a minute intuitions about what should really happen, and just see what would follow from the underlying semantic model: Suppose we define MOVE as "remove the binding identified by the Request-URI and add the binding identified by the Destination header". Now consider your case: /a/b.html and /x/y.html both point to resource R, and I have an exclusive write lock on /a/b.html. User2 tries to MOVE /c/d.html (which points to some other resource S) to /x/y.html. It seems this should be possible, because all that is happening is that the binding y.html in collection /x/ is being replaced with one that binds to a different resource. Nothing happens to resource R. But if we use the COPY + fixup + DELETE semantics for MOVE, resource S would have to be duplicated, overwriting R. And this would not be allowed, because R is locked. It doesn't overwrite R. A COPY to an existing resource will either fail (if Overwrite=FALSE) or issue a DELETE on the destination of the COPY. The DELETE of /x/y.html succeeds just fine (since DELETE is properly defined to just remove the binding named "y.html" from the collection "/x"), the COPY proceeds, and then the "fixup" step replaces the binding to the new resource created by the COPY with a binding to R, and then a DELETE is issued on the request URL of the MOVE, which then deletes the binding named "d.html" from the collection "/c". Of course, we can legislate this problem away by, for example, accepting your proposal that a MOVE or COPY like this one fail no matter which semantics you use. But I'm afraid other cases will turn up that reveal inconsistencies between the 2 models of MOVE. I believe there are no inconsistencies here ... just suitably creative definitions of "fixup" (:-). From w3c-dist-auth-request@w3.org Wed Sep 15 17:23: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 RAA20826 for ; Wed, 15 Sep 1999 17:23:03 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id RAA11058; Wed, 15 Sep 1999 17:10:32 -0400 (EDT) Resent-Date: Wed, 15 Sep 1999 17:10:32 -0400 (EDT) Resent-Message-Id: <199909152110.RAA11058@www19.w3.org> Date: Wed, 15 Sep 1999 17:10:16 -0400 Message-Id: <9909152110.AA03662@tantalum> From: "Geoffrey M. Clemm" To: w3c-dist-auth@w3.org In-Reply-To: <852567ED.00673430.00@D51MTA07.pok.ibm.com> (ccjason@us.ibm.com) Subject: Re: Bindings, Locks, and MOVE Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3324 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 I do have trouble following your description of the fixup stage, though. I take it you don't think we face the awkward situation Kevin described, where there end up being 2 resources where there used to be only one. But how do you avoid this? I have to agree that I couldn't quite understand what GC meant by "fixup" since it seemed none was necessary. I also don't understand what you are saying about extra resources. This thread was one where Judy was concerned that our definition of MOVE was incompatible with being "logically equivalent to COPY/fixup/DELETE". So although an extra resource is what you would expect (rightly so) after a COPY, an extra resource is *not* what you would expect after a MOVE. In an earlier posting, I pointed out that the "fixup step" could be used to get rid of the extra resource. But to emphasize, defining MOVE as COPY/fixup/DELETE is *bad* (as in "bad dog, don't mess the carpet" :-) As for the MOVE, we start with two resources and end with two. No surprise once again. But without a "fixup", if you just do COPY/DELETE to implement your MOVE, Judy's example would end up with three resources following the MOVE, rather than two, thus her concern. Cheers, Geoff From w3c-dist-auth-request@w3.org Wed Sep 15 18:03: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 SAA21192 for ; Wed, 15 Sep 1999 18:03:28 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id RAA11973; Wed, 15 Sep 1999 17:45:46 -0400 (EDT) Resent-Date: Wed, 15 Sep 1999 17:45:46 -0400 (EDT) Resent-Message-Id: <199909152145.RAA11973@www19.w3.org> Date: Wed, 15 Sep 1999 17:45:38 -0400 Message-Id: <9909152145.AA03670@tantalum> From: "Geoffrey M. Clemm" To: w3c-dist-auth@w3.org In-Reply-To: (message from Kevin Wiggen on Wed, 15 Sep 1999 12:21:04 -0700) Subject: Re: Bindings, Locks, and MOVE Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3325 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: Kevin Wiggen /~kwiggen/projectX/spec.html" and /~john/projectX/fgd/dfgdfg/dfgdg/spec.html are bindings to the same resource. If Kevin does a PUT to his URL it will replace the file and John will see the update. I'd probably use the word "update" rather than "replace", since replace might be interpreted as saying that a new resource created, whereas PUT just updates the state of the resource. However if Kevin tries to simply COPY or MOVE /~kwiggen/projectX/spec_mine.html to /~kwiggen/projectX/spec.html, his BIND will be deleted, and Kevin and John will no longer be working on the same document. All this and Kevin and John will probably not be any the wiser and blame each other for lack of updates :) With the proposed advanced collection definition of MOVE, a MOVE will *preserve* the bindings, while a COPY will not. I believe this is a major FLAW with MOVE/COPY and it really comes out in BIND. If the purpose is to have the ability for the same resource to exist in the namespace hierarchy (as the spec states in its introduction), then I would assume that BINDS last through MOVE/COPY just as they do through PUT and PROPPATCH. MOVE preserves bindings, but COPY does not (it creates new resources). Both semantics are important, which is why we have two methods. The overwrite flag does not help in this situation. If it is false, it means do not overwrite as before. Overwrite to T means "Create me my own resource" in this case, and I believe that is not the intended behavior of the user. I agree that the Overwrite header should have nothing to do with whether or not bindings are preserved. In general though, Overwrite=T does not mean "create my own resource", but rather "delete whatever is currently there". Cheers, Geoff From w3c-dist-auth-request@w3.org Wed Sep 15 18:04:30 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 SAA21204 for ; Wed, 15 Sep 1999 18:04:30 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id RAA12050; Wed, 15 Sep 1999 17:48:17 -0400 (EDT) Resent-Date: Wed, 15 Sep 1999 17:48:17 -0400 (EDT) Resent-Message-Id: <199909152148.RAA12050@www19.w3.org> From: ccjason@us.ibm.com X-Lotus-FromDomain: IBMUS To: John Stracke cc: "'WebDAV'" Message-ID: <852567ED.0077BFA7.00@D51MTA07.pok.ibm.com> Date: Wed, 15 Sep 1999 17:54:50 -0400 Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Subject: Re: Guaranteeing the Integrity of Bindings Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3326 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 think that it is not impossible to guarantee integrity of bindings even > > > in cases like this, if the server is willing to take enough trouble. It can > > > store a copy of the target resource locally, and insure that no changes are > > > allowed except when both servers are accessible. > > > It may not be feasible to make a copy of a dynamic resource. Right. A copy might be difficult or inappropriate. Judith's copy example is just one possible approach. For resources that couldn't be copied, some cooperative proxying might be done for example. Each approach will have tradeoffs. I think Judith's point was that integrity *can* be insured. From w3c-dist-auth-request@w3.org Wed Sep 15 18:05: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 SAA21229 for ; Wed, 15 Sep 1999 18:05:18 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id RAA12114; Wed, 15 Sep 1999 17:49:35 -0400 (EDT) Resent-Date: Wed, 15 Sep 1999 17:49:35 -0400 (EDT) Resent-Message-Id: <199909152149.RAA12114@www19.w3.org> Date: Wed, 15 Sep 1999 17:49:26 -0400 Message-Id: <9909152149.AA03683@tantalum> From: "Geoffrey M. Clemm" To: w3c-dist-auth@w3.org In-Reply-To: <37DFE348.C1DA85D9@ecal.com> (message from John Stracke on Wed, 15 Sep 1999 14:19:53 -0400) Subject: Re: Guaranteeing the Integrity of Bindings Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3327 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: John Stracke "Slein, Judith A" wrote: > We think that it is not impossible to guarantee integrity of bindings even > in cases like this, if the server is willing to take enough trouble. It can > store a copy of the target resource locally, and insure that no changes are > allowed except when both servers are accessible. It may not be feasible to make a copy of a dynamic resource. True. In which case (as in all other cases where it cannot guarantee BIND semantics) the server has to fail the BIND request. Cheers, Geoff From w3c-dist-auth-request@w3.org Wed Sep 15 18:06:30 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 SAA21240 for ; Wed, 15 Sep 1999 18:06:30 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id RAA12573; Wed, 15 Sep 1999 17:53:02 -0400 (EDT) Resent-Date: Wed, 15 Sep 1999 17:53:02 -0400 (EDT) Resent-Message-Id: <199909152153.RAA12573@www19.w3.org> Message-ID: <37E0151F.880B2019@ecal.com> Date: Wed, 15 Sep 1999 17:52:31 -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: <852567ED.0077BFA7.00@D51MTA07.pok.ibm.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: Guaranteeing the Integrity of Bindings Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3329 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 ccjason@us.ibm.com wrote: > > > It may not be feasible to make a copy of a dynamic resource. > > Right. A copy might be difficult or inappropriate. Judith's copy example is > just one possible approach. For resources that couldn't be copied, some > cooperative proxying might be done for example. But the copy suggestion was for when the servers can't talk to each other. -- /==============================================================\ |John Stracke | http://www.ecal.com |My opinions are my own.| |Chief Scientist |=============================================| |eCal Corp. |In the long run, there is no middle ground | |francis@ecal.com|between justice and genocide. | \==============================================================/ From w3c-dist-auth-request@w3.org Wed Sep 15 18:06: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 SAA21251 for ; Wed, 15 Sep 1999 18:06:38 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id RAA12485; Wed, 15 Sep 1999 17:52:18 -0400 (EDT) Resent-Date: Wed, 15 Sep 1999 17:52:18 -0400 (EDT) Resent-Message-Id: <199909152152.RAA12485@www19.w3.org> Date: Wed, 15 Sep 1999 17:52:09 -0400 Message-Id: <9909152152.AA03690@tantalum> From: "Geoffrey M. Clemm" To: francis@ecal.com Cc: w3c-dist-auth@w3.org In-Reply-To: <37DFF332.FCF9172A@ecal.com> (message from John Stracke on Wed, 15 Sep 1999 15:27:47 -0400) Subject: Re: Guaranteeing the Integrity of Bindings Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3328 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list To give that dead horse one more kick (:-), I agree with John and Jason that there is little useful we can say about the semantics of dynamic resources. The best we can do is give them some standard properties like "source". Cheers, Geoff Date: Wed, 15 Sep 1999 15:27:47 -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 References: <852567ED.006A4EC5.00@D51MTA07.pok.ibm.com> Content-Transfer-Encoding: 7bit Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3317 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: 27 Content-Type: text/plain; charset="us-ascii"; conversions="7bit" Content-Length: 1145 ccjason@us.ibm.com wrote: > > > We think that it is not impossible to guarantee integrity of bindings even > > > in cases like this, if the server is willing to take enough trouble. It can > > > store a copy of the target resource locally, and insure that no changes are > > > allowed except when both servers are accessible. > > > It may not be feasible to make a copy of a dynamic resource. > > > We've barely discussed dynamic resources in general. It doesn't take much discussion to realize that copying a dynamic resource is not something that can ever be expressed in a standard protocol; they're far too implementation-dependent. From w3c-dist-auth-request@w3.org Wed Sep 15 18:14: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 SAA21310 for ; Wed, 15 Sep 1999 18:14:10 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id QAA08786; Wed, 15 Sep 1999 16:15:50 -0400 (EDT) Resent-Date: Wed, 15 Sep 1999 16:15:50 -0400 (EDT) Resent-Message-Id: <199909152015.QAA08786@www19.w3.org> Message-ID: <8E3CFBC709A8D21191A400805F15E0DBD24452@crte147.wc.eso.mc.xerox.com> From: "Slein, Judith A" To: "'WebDAV'" Date: Wed, 15 Sep 1999 16:14:56 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Subject: DAV:guid Property Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3321 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 Amsden suggested in his review comments that we define a guid property that could be used to determine whether 2 bindings are bindings to the same resource. The advanced collections authors like this idea and propose to define such a property. We could do something similar to what RFC 2518 does for lock tokens -- require that the value of the guid be globally unique, and provide a sample algorithm that implementers can use to generate values, but not require the use of any particular algorithm. --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 Sep 15 18:22: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 SAA21370 for ; Wed, 15 Sep 1999 18:22:11 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id SAA13019; Wed, 15 Sep 1999 18:00:15 -0400 (EDT) Resent-Date: Wed, 15 Sep 1999 18:00:15 -0400 (EDT) Resent-Message-Id: <199909152200.SAA13019@www19.w3.org> Message-ID: <37E016D1.D90AB3D7@ecal.com> Date: Wed, 15 Sep 1999 17:59:45 -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: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Cross-server bindings: second thoughts Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3330 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 After making all this fuss, I just realized that cross-server bindings are probably a bad idea in the first place. You've got problems with authentication (the credentials to one server may not work at another server), scalability (a redirect gets the first server out of the loop faster), and security (the server with the binding on it may be able to reach servers that the client shouldn't be able to). So, if they just don't work, then maybe it's not worth worrying about how smoothly they don't work. :-) -- /==============================================================\ |John Stracke | http://www.ecal.com |My opinions are my own.| |Chief Scientist |=============================================| |eCal Corp. |In the long run, there is no middle ground | |francis@ecal.com|between justice and genocide. | \==============================================================/ From w3c-dist-auth-request@w3.org Wed Sep 15 18:45: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 SAA21550 for ; Wed, 15 Sep 1999 18:45:01 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id SAA14072; Wed, 15 Sep 1999 18:32:22 -0400 (EDT) Resent-Date: Wed, 15 Sep 1999 18:32:22 -0400 (EDT) Resent-Message-Id: <199909152232.SAA14072@www19.w3.org> From: ccjason@us.ibm.com X-Lotus-FromDomain: IBMUS To: John Stracke cc: "'WebDAV'" Message-ID: <852567ED.007BC7A2.00@D51MTA07.pok.ibm.com> Date: Wed, 15 Sep 1999 18:38:53 -0400 Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Subject: Re: Bindings and Other Methods (Section 10) Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3331 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list > e would like to say the simple, straightforward thing: That for any of > these methods, the results of applying the method through one binding are > identical to the results of applying the same method with the same headers > and body through another bindings to the same resource. > > What prevents us from saying this are executable resources, which generate > responses dynamically and may be sensitive to which Request-URI is used to > access them. If we try to take these executable resources into account, we > are reduced to saying things that are so open-ended that they place no > enforceable constraints on the behavior of GET, PUT, etc., when applied > through different bindings to the same resource. Why exactly is this a problem? Me, I'd consider it a feature; if I write code that's sensitive to the Request-URI, it's probably for a good reason. I may want to be able to write a script once and place bindings to it in different places that behave differently according to their location. In fact, I *have* written such a script. On my personal site, I don't have access to the logs, so I've placed index.cgi scripts in various directories that I want to monitor; they log the hit and return a 302 to redirect to Index.html. Since I didn't want to maintain N copies of the script, most of them are symlinks. Since the 302 requires an absolute URI, the script looks at the Request-URI to figure out where to redirect to. John, I don't think there's anything wrong with that. Judith, I also think your wording is a reasonable attempt to define an *enforceable* "same resource" without tying yourself in knots or use recursive definitions. I suspect we all have the same model of how we'd like bindings to work. Question: Do we need any **enforcable** constraints? Or do we just need to express the model that is to be followed? Or is what we need somewhere in between? -- Anyway, what type of enforcability do we ***need***? What properties *MUST* not change depending on the binding operations? What *SHOULD* not change? My thinking is that if the folks before us couldn't give us enforcable definition of resource... then we're going to have difficulty defining an enforcable defintion of "same resource". Therefore we can talk about "same resource", but we shouldn't really try to *strictly* define it. The main issue I see with not defining it strictly is that cach'ing might be a problem with some resources. But that's always the case. Some resources or properties always be changing regardless of bindings... so making a restriction for bindings is probably not the right solution. That being the case, we later can come up with a cach'abilty extension to webdav if we all feel it's needed. Judith?.... From w3c-dist-auth-request@w3.org Wed Sep 15 19:47: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 TAA22319 for ; Wed, 15 Sep 1999 19:47:55 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id TAA15653; Wed, 15 Sep 1999 19:34:27 -0400 (EDT) Resent-Date: Wed, 15 Sep 1999 19:34:27 -0400 (EDT) Resent-Message-Id: <199909152334.TAA15653@www19.w3.org> Message-ID: <078292D50C98D2118D090008C7E9C6A603C96612@STAY.platinum.corp.microsoft.com> From: "Yaron Goland (Exchange)" To: "'Slein, Judith A'" , "'WebDAV'" Date: Wed, 15 Sep 1999 16:33:43 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Proposal on MOVE and locks Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3332 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 exact same question, regarding moves and locks, came up in the past and the group consensus was that we should not allow locks to MOVE with resources. To revoke this decision is to pull the rug out of implementers who took WebDAV in good faith. This is exactly the sort of behavior which makes some many companies wary of dealing with the IETF. The rules change too often. There is an alternative route which I believe meets everyone's needs. We define a new header, which can optionally be used with mandatory, that specifies that the move is only to succeed if the lock (if any) is moved with it. If the header is absent the server MUST NOT move the lock. The benefit of this system is that existing clients will continue to properly interoperate with both existing WebDAV servers and future WebDAV servers. In addition existing WebDAV servers will be able to properly interoperate with both existing WebDAV clients and future WebDAV clients. Yaron > -----Original Message----- > From: Slein, Judith A [mailto:JSlein@crt.xerox.com] > Sent: Wed, September 15, 1999 1:02 PM > To: 'WebDAV' > Subject: Proposal on MOVE and locks > > > As a result of the discussions on the mailing list over the > past week, the > design team would like to make some changes in its proposal > about MOVE and > locks. > > We agree that we should not be specifying any different behavior for > cross-server MOVEs than for MOVEs on the same server. So we > plan to take > out all normative language related to cross-server MOVEs. > > We do want to stand by our basic position that locks MOVE > with a resource, > since that is consistent with the underlying semantic model > of bindings. A > MOVE has no effect on the resource, but only involves > creating a new binding > between the final segment of the Destination URI in its > collection and the > resource, and removing the binding between the final segment of the > Request-URI in its collection and the resource. The state of > the resource > itself -- including its lock state -- is unchanged. > > That leaves us with the following: > > For MOVE (assuming that the principal performing the MOVE > owns all locks > involved): > > 1. If there is a lock on the source resource that is rooted > at the source > resource (that is, the lock is not inherited from a parent > collection), the > lock moves with the resource to the destination. > > 2. If there is a lock on the destination resource that is > rooted at the > destination resource (that is, the lock is not inherited from a parent > collection), its lock is gone after the MOVE. > > 3. If the source resource inherits a lock from a parent > collection, and the > resource is moved out of the tree affected by that lock, the > lock no longer > applies to the resource after the MOVE. > > 4. If the destination resource inherits a lock from a parent > collection, the > MOVEd resource inherits that lock after the MOVE. > > 5. If there is a lock on the source resource that is rooted > at the source > resource, and the destination resource inherits a lock from a parent > collection, the MOVE fails due to a conflict between rules 1 and 4. > > 6. If a collection is MOVEd, and there are some locked > resources in that > collection, the locks on those resources move with the resources. > > For COPY: > > After the COPY, there will be no locks at the destination > except what is > inherited from above. > > Judith A. Slein > XR&T/Xerox Architecture Center > jslein@crt.xerox.com > 8*222-5169 > From w3c-dist-auth-request@w3.org Wed Sep 15 20:03: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 UAA22521 for ; Wed, 15 Sep 1999 20:03:03 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id TAA15943; Wed, 15 Sep 1999 19:50:26 -0400 (EDT) Resent-Date: Wed, 15 Sep 1999 19:50:26 -0400 (EDT) Resent-Message-Id: <199909152350.TAA15943@www19.w3.org> Message-ID: <078292D50C98D2118D090008C7E9C6A603C96614@STAY.platinum.corp.microsoft.com> From: "Yaron Goland (Exchange)" To: "'Slein, Judith A'" , "'WebDAV'" Date: Wed, 15 Sep 1999 16:49:58 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Trailing "/" in BIND Requests Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3333 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 inability to bind "/" simply means that your model is broken. There is nothing exceptionally special about the "/" resource name other than it doesn't have a parent. It must be just as bindable as any other resource name. > -----Original Message----- > From: Slein, Judith A [mailto:JSlein@crt.xerox.com] > Sent: Wed, September 15, 1999 11:53 AM > To: 'WebDAV' > Subject: Trailing "/" in BIND Requests > > > Both Yaron and Jim Amsden our attempts to enforce consistency > between the > Request-URI and the Destination header in BIND requests are > not appropriate. > We wanted to say that either both must end in a "/" or > neither may end in a > "/". > > But in reality a trailing "/" is not a reliable indicator of > the type of > resource being addressed, so we should allow servers to process BIND > requests even if the Request-URI ends in "/" and the > Destination header does > not, or vice versa. > > We agree with these comments and will remove the constraints from the > description of the BIND method and the related examples. > > Yaron also objected to our saying that the Request-URI cannot > just consist > of "/". That is, we currently say that you cannot use BIND > to create a > binding between the root and some resource. We say this > because we define a > binding to be a relation between a URI segment in its parent > collection and > some resource. That is, it's the triple (segment, > collection, resource). > Here there is no segment, and there is no parent collection. > So you can't > make sense of creating a binding for "/". > > --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 Sep 15 20:06: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 UAA22545 for ; Wed, 15 Sep 1999 20:06:10 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id TAA16200; Wed, 15 Sep 1999 19:53:53 -0400 (EDT) Resent-Date: Wed, 15 Sep 1999 19:53:53 -0400 (EDT) Resent-Message-Id: <199909152353.TAA16200@www19.w3.org> Message-ID: <078292D50C98D2118D090008C7E9C6A603C96615@STAY.platinum.corp.microsoft.com> From: "Yaron Goland (Exchange)" To: "'Slein, Judith A'" , "'WebDAV'" Date: Wed, 15 Sep 1999 16:53:23 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Subject: RE: BIND Error Codes Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3334 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list Adding yet another error code for this is probably a waste. I think 501 is the right code but you should add an XML body with an element indicating what went wrong. You could use a header but the error status is something (as you are now finding) that people will want to be able to expand in the future. XML is expandable, headers are not. Yaron > -----Original Message----- > From: Slein, Judith A [mailto:JSlein@crt.xerox.com] > Sent: Wed, September 15, 1999 11:19 AM > To: 'WebDAV' > Subject: BIND Error Codes > > > Another in the series of messages from the advanced > collections design team: > > We've agreed to remove all normative language about > cross-server bindings, > but we do think it would be useful to say something about the > reason why a > binding cannot be created, especially in the case of an > attempt to create a > cross-server binding. > > We haven't been able to agree on how best to do this. > > Currently the binding spec says that if the server can't guarantee the > required binding behavior, it must fail the BIND request with > a 501 (Not > Implemented). Period. No further explanation. We could > just leave it at > that, but we think it would be useful to the client to know > that the reason > the BIND can't be done is that the server can't guarantee integrity of > bindings to resources on another server (for example). > > We could use a different (new) error code for "Can't create > cross-server > binding." > > We could stick with 501, but provide further explanation in > the response > body. > > We could leave the spec as it is. > > Any preferences? > > --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 Sep 15 20:45: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 UAA22801 for ; Wed, 15 Sep 1999 20:45:55 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id UAA18494; Wed, 15 Sep 1999 20:32:25 -0400 (EDT) Resent-Date: Wed, 15 Sep 1999 20:32:25 -0400 (EDT) Resent-Message-Id: <199909160032.UAA18494@www19.w3.org> Message-ID: <37E03806.1B98E3A8@lyra.org> Date: Wed, 15 Sep 1999 17:21:26 -0700 From: Greg Stein X-Mailer: Mozilla 3.01 (X11; I; Linux 2.0.28 i586) MIME-Version: 1.0 To: "Yaron Goland (Exchange)" CC: w3c-dist-auth@w3.org References: <078292D50C98D2118D090008C7E9C6A603C96612@STAY.platinum.corp.microsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: Proposal on MOVE and locks Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3335 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 Yaron Goland (Exchange) wrote: >... > There is an alternative route which I believe meets everyone's needs. We > define a new header, which can optionally be used with mandatory, that > specifies that the move is only to succeed if the lock (if any) is moved > with it. If the header is absent the server MUST NOT move the lock. The > benefit of this system is that existing clients will continue to properly > interoperate with both existing WebDAV servers and future WebDAV servers. In > addition existing WebDAV servers will be able to properly interoperate with > both existing WebDAV clients and future WebDAV clients. Why a new header? MOVE has a defined body. Add a new XML element in there. Cheers, -g -- Greg Stein, http://www.lyra.org/ From w3c-dist-auth-request@w3.org Thu Sep 16 09:02:30 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 JAA13139 for ; Thu, 16 Sep 1999 09:02:29 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id IAA07192; Thu, 16 Sep 1999 08:45:14 -0400 (EDT) Resent-Date: Thu, 16 Sep 1999 08:45:14 -0400 (EDT) Resent-Message-Id: <199909161245.IAA07192@www19.w3.org> Date: Thu, 16 Sep 1999 08:44:58 -0400 Message-Id: <9909161244.AA03951@tantalum> From: "Geoffrey M. Clemm" To: w3c-dist-auth@w3.org In-Reply-To: <078292D50C98D2118D090008C7E9C6A603C96615@STAY.platinum.corp.microsoft.com> (yarong@Exchange.Microsoft.com) Subject: Re: BIND Error Codes Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3336 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 also prefer the explanatory XML body approach. Cheers, Geoff From: "Yaron Goland (Exchange)" Adding yet another error code for this is probably a waste. I think 501 is the right code but you should add an XML body with an element indicating what went wrong. You could use a header but the error status is something (as you are now finding) that people will want to be able to expand in the future. XML is expandable, headers are not. Yaron > From: Slein, Judith A [mailto:JSlein@crt.xerox.com] > Currently the binding spec says that if the server can't guarantee the > required binding behavior, it must fail the BIND request with > a 501 (Not > Implemented). Period. No further explanation. We could > just leave it at > that, but we think it would be useful to the client to know > that the reason > the BIND can't be done is that the server can't guarantee integrity of > bindings to resources on another server (for example). > > We could use a different (new) error code for "Can't create > cross-server > binding." > > We could stick with 501, but provide further explanation in > the response > body. > > We could leave the spec as it is. > > Any preferences? > > --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 Sep 16 10:39: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 KAA19273 for ; Thu, 16 Sep 1999 10:39:03 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id KAA10469; Thu, 16 Sep 1999 10:21:08 -0400 (EDT) Resent-Date: Thu, 16 Sep 1999 10:21:08 -0400 (EDT) Resent-Message-Id: <199909161421.KAA10469@www19.w3.org> Date: Thu, 16 Sep 1999 10:20:56 -0400 Message-Id: <9909161420.AA04005@tantalum> From: "Geoffrey M. Clemm" To: w3c-dist-auth@w3.org In-Reply-To: <078292D50C98D2118D090008C7E9C6A603C96614@STAY.platinum.corp.microsoft.com> (yarong@Exchange.Microsoft.com) Subject: Re: Trailing "/" in BIND Requests Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3337 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)" The inability to bind "/" simply means that your model is broken. There is nothing exceptionally special about the "/" resource name other than it doesn't have a parent. It must be just as bindable as any other resource name. The BIND operation is the way of linking a resource by name into a collection resource (i.e. giving it another parent). If a BIND were allowed to succeed on "/", it would result in "/" having a parent, which would violate the very thing that you identified as being special about "/", namely that it has no parent. Another way to see why this is so, is to observe that BIND is really is a 3 argument operation: BIND(source-resource-URL, destination-collection-URL, binding-name). For convenience, we have encoded it as: BIND source-resource-URL Destination: destination-collection-URL/binding-name This is unambiguous, since you strip off a trailing slash (if any) from the Destination URL, use the last segment of the resulting URL to get the binding-name, and the remainder of the Destination URL is the destination-collection-URL. This works for every URL except for "/", since stripping off the trailing slash will leave you with the empty string from which you can get neither a legal binding-name nor a legal destination-collection-URL. Judy: We might want some form of this preceding paragraph to the spec to make sure servers parse the Destination header of the BIND properly. Cheers, Geoff From w3c-dist-auth-request@w3.org Thu Sep 16 11:22: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 LAA20470 for ; Thu, 16 Sep 1999 11:22:47 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id LAA13027; Thu, 16 Sep 1999 11:08:32 -0400 (EDT) Resent-Date: Thu, 16 Sep 1999 11:08:32 -0400 (EDT) Resent-Message-Id: <199909161508.LAA13027@www19.w3.org> From: ccjason@us.ibm.com X-Lotus-FromDomain: IBMUS To: "Geoffrey M. Clemm" cc: w3c-dist-auth@w3.org Message-ID: <852567EE.0053268A.00@D51MTA07.pok.ibm.com> Date: Thu, 16 Sep 1999 11:14:55 -0400 Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Subject: Re: Trailing "/" in BIND Requests Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3338 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, I think Yaron's point is that he believes / should be able to refer to any resource. Right now it's stuck with whatever it started with. Or at least it appears that it stuck. I think his words were a bit harsh and that we can address his concerns. It just needs more thought. Unless someone has a quick answer, I think this should go on our issue list. Judy... you've got the issue list, right? :-) ------------------------------------------ Phone: 914-784-7569, ccjason@us.ibm.com From w3c-dist-auth-request@w3.org Thu Sep 16 11:31: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 LAA20760 for ; Thu, 16 Sep 1999 11:31:38 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id LAA13680; Thu, 16 Sep 1999 11:19:00 -0400 (EDT) Resent-Date: Thu, 16 Sep 1999 11:19:00 -0400 (EDT) Resent-Message-Id: <199909161519.LAA13680@www19.w3.org> Date: Thu, 16 Sep 1999 11:18:48 -0400 Message-Id: <9909161518.AA04108@tantalum> From: "Geoffrey M. Clemm" To: w3c-dist-auth@w3.org In-Reply-To: <852567EE.0053268A.00@D51MTA07.pok.ibm.com> (ccjason@us.ibm.com) Subject: Re: Trailing "/" in BIND Requests Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3339 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 I think Yaron's point is that he believes / should be able to refer to any resource. Right now it's stuck with whatever it started with. Or at least it appears that it stuck. Fair enough. We could certainly overload "BIND" and/or "MOVE" to make a BIND/MOVE to "/" be a special case that doesn't affect bindings, but rather modifies the current mapping of "/". Cheers, Geoff From w3c-dist-auth-request@w3.org Thu Sep 16 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 NAA23178 for ; Thu, 16 Sep 1999 13:30:35 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id NAA16430; Thu, 16 Sep 1999 13:14:09 -0400 (EDT) Resent-Date: Thu, 16 Sep 1999 13:14:09 -0400 (EDT) Resent-Message-Id: <199909161714.NAA16430@www19.w3.org> From: ccjason@us.ibm.com X-Lotus-FromDomain: IBMUS To: "Geoffrey M. Clemm" cc: w3c-dist-auth@w3.org Message-ID: <852567EE.005EA219.00@D51MTA07.pok.ibm.com> Date: Thu, 16 Sep 1999 13:20:19 -0400 Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Subject: Re: Bindings, Locks, and MOVE Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3342 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, please check me if I'm wrong... but I think kevin is talking about COPY/MOVE'ing ***TO** the multiply bound resource, not from. As currently written, the COPY/MOVE does a delete on the destination right up front... so the binding to a shared object is lost. A PUT to either URI of the resource doesn't break their ability to share the resource. Ooops! Jason is completely right. Sorry about the bandwidth wastage. So I'd like to retract my earlier posting, and just agree with Kevin that a COPY that preserves destination bindings is a useful operation that is currently not provided by the protocol. As a form of penance, I will propose a solution to this problem: Add "DAV:merge" as a new potential value of the Overwrite header when used with the COPY request. The semantics COPY with Overwrite=DAV:merge is to "merge" the source resource into the destination resource. In case of non-collection resources, this is just the equivalent of a PUT and a PROPPATCH into the Destination. In case of collection resources, it means recursively PUT/PROPPATCH from the members of the source collection into the corresponding member of the destination collection. Any takers? I'm a taker. I think this is good. Very good. But I'm not sure if I want to add something that seems entirely new when we have less than three weeks before our deadline. Let's see how things go. (BTW, I can also envision a MOVE version of this... but that's messier and a tangent.) Anyway, just to clarify... for a given source resource.... given what is at it's intended destination, what action must occur... \ orig \ Dest S\ r \ c \ \ empty | non-Coll | Collection +---------------+------------------+---------------- |NC->E |NC->NC |NC->C non | | | Coll | copy it | ?replace? | ? | | (bind new copy?) | | | | -+---------------+------------------+---------------- |C->E |C->NC |C->C | | | Coll | copy it | ? | copy members | & members | | only | | | | | | I've also labeled each box for reference: NC->E, etc. J. From w3c-dist-auth-request@w3.org Thu Sep 16 13:39:46 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 NAA23441 for ; Thu, 16 Sep 1999 13:39:44 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id MAA15093; Thu, 16 Sep 1999 12:28:59 -0400 (EDT) Resent-Date: Thu, 16 Sep 1999 12:28:59 -0400 (EDT) Resent-Message-Id: <199909161628.MAA15093@www19.w3.org> From: ccjason@us.ibm.com X-Lotus-FromDomain: IBMUS To: w3c-dist-auth@w3.org Message-ID: <852567EE.005A7FE4.00@D51MTA07.pok.ibm.com> Date: Thu, 16 Sep 1999 12:35:08 -0400 Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Subject: Re: Trailing "/" in BIND Requests Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3341 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 I think Yaron's point is that he believes / should be able to refer to any resource. Right now it's stuck with whatever it started with. Or at least it appears that it stuck. Fair enough. We could certainly overload "BIND" and/or "MOVE" to make a BIND/MOVE to "/" be a special case that doesn't affect bindings, but rather modifies the current mapping of "/". Sounds fair. There's nothing in the syntax of the protocol to suggest that it can't be done or that there's anything special about it. Obviously we can't lock the "parent" of / if we wanted to lock a whole tree, but if we lock / itself, the URI protection feature will have the same effect. It's only our data model... and perhaps some implementations that might have to twist themselves a bit to handle this. Can any server implementers comment on the difficulty of this? Note: changing the root is sort of an academic case. Unless you are going cross server, the new / will actually be "deleted" in the delete phase before it becomes the new resource. At least in the model. Next question... do we want to make replacement of the / resource a MUST? Next question... Folks have talked about mixed webdav/non-webdav servers. Do we have a similar situation at the interfaces between the webdav and non-webdav portion of a site? (Honest question. I don't have a clue how these mixed servers work.) From w3c-dist-auth-request@w3.org Thu Sep 16 13:39: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 NAA23451 for ; Thu, 16 Sep 1999 13:39:47 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id MAA14954; Thu, 16 Sep 1999 12:24:43 -0400 (EDT) Resent-Date: Thu, 16 Sep 1999 12:24:43 -0400 (EDT) Resent-Message-Id: <199909161624.MAA14954@www19.w3.org> Date: Thu, 16 Sep 1999 12:24:31 -0400 Message-Id: <9909161624.AA04171@tantalum> From: "Geoffrey M. Clemm" To: w3c-dist-auth@w3.org In-Reply-To: <852567EE.00592CA0.00@D51MTA07.pok.ibm.com> (ccjason@us.ibm.com) Subject: Re: Bindings, Locks, and MOVE Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3340 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, please check me if I'm wrong... but I think kevin is talking about COPY/MOVE'ing ***TO** the multiply bound resource, not from. As currently written, the COPY/MOVE does a delete on the destination right up front... so the binding to a shared object is lost. A PUT to either URI of the resource doesn't break their ability to share the resource. Ooops! Jason is completely right. Sorry about the bandwidth wastage. So I'd like to retract my earlier posting, and just agree with Kevin that a COPY that preserves destination bindings is a useful operation that is currently not provided by the protocol. As a form of penance, I will propose a solution to this problem: Add "DAV:merge" as a new potential value of the Overwrite header when used with the COPY request. The semantics COPY with Overwrite=DAV:merge is to "merge" the source resource into the destination resource. In case of non-collection resources, this is just the equivalent of a PUT and a PROPPATCH into the Destination. In case of collection resources, it means recursively PUT/PROPPATCH from the members of the source collection into the corresponding member of the destination collection. Any takers? Cheers, Geoff From: Kevin Wiggen /~kwiggen/projectX/spec.html" and /~john/projectX/fgd/dfgdfg/dfgdg/spec.html are bindings to the same resource. However if Kevin tries to simply COPY or MOVE /~kwiggen/projectX/spec_mine.html to /~kwiggen/projectX/spec.html, his BIND will be deleted, and Kevin and John will no longer be working on the same document. All this and Kevin and John will probably not be any the wiser and blame each other for lack of updates :) I believe this is a major FLAW with MOVE/COPY and it really comes out in BIND. If the purpose is to have the ability for the same resource to exist in the namespace hierarchy (as the spec states in its introduction), then I would assume that BINDS last through MOVE/COPY just as they do through PUT and PROPPATCH. The overwrite flag does not help in this situation. If it is false, it means do not overwrite as before. Overwrite to T means "Create me my own resource" in this case, and I believe that is not the intended behavior of the user. From w3c-dist-auth-request@w3.org Fri Sep 17 07:50: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 HAA01223 for ; Fri, 17 Sep 1999 07:50:07 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id AAA27984; Fri, 17 Sep 1999 00:24:48 -0400 (EDT) Resent-Date: Fri, 17 Sep 1999 00:24:48 -0400 (EDT) Resent-Message-Id: <199909170424.AAA27984@www19.w3.org> Date: Fri, 17 Sep 1999 00:24:37 -0400 Message-Id: <9909170424.AA04396@tantalum> From: "Geoffrey M. Clemm" To: w3c-dist-auth@w3.org In-Reply-To: <852567EE.005EA219.00@D51MTA07.pok.ibm.com> (ccjason@us.ibm.com) Subject: Re: Bindings, Locks, and MOVE Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3343 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 Add "DAV:merge" as a new potential value of the Overwrite header when used with the COPY request. The semantics COPY with Overwrite=DAV:merge is to "merge" the source resource into the destination resource. In case of non-collection resources, this is just the equivalent of a PUT and a PROPPATCH into the Destination. In case of collection resources, it means recursively PUT/PROPPATCH from the members of the source collection into the corresponding member of the destination collection. S\ Dest r \ c \ \ empty | non-Coll | Collection +---------------+------------------+---------------- |NC->E |NC->NC |NC->C non | | | Coll | copy it | ?replace? | ? | | (bind new copy?) | -+---------------+------------------+---------------- |C->E |C->NC |C->C Coll | copy it | ? | copy members | & members | | only NC->NC is a combined PUT/PROPPATCH. All bindings to the destination continue to be valid. C->NC replaces NC with a copy of C. Any bindings to NC are now bindings to the copy of C. If the server cannot do this rebinding, it must fail the COPY request. NC->C replaces C with a copy of NC. Any bindings to C are now bindings to the copy of NC. If the server cannot do this rebinding, it must fail the COPY request. C->C Recursively perform the merge MOVE from every member of the source collection to the corresponding member of the destination collection. Cheers, Geoff From w3c-dist-auth-request@w3.org Fri Sep 17 08:18: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 IAA08232 for ; Fri, 17 Sep 1999 08:18:36 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id IAA03367; Fri, 17 Sep 1999 08:04:06 -0400 (EDT) Resent-Date: Fri, 17 Sep 1999 08:04:06 -0400 (EDT) Resent-Message-Id: <199909171204.IAA03367@www19.w3.org> Message-Id: <199909171203.IAA04303@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: w3c-dist-auth@w3.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Fri, 17 Sep 1999 08:03:14 -0400 Subject: I-D ACTION:draft-ietf-webdav-propfind-space-00.txt Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3344 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 PROPFIND Extension To List Specified Namespaces Author(s) : J. Stracke Filename : draft-ietf-webdav-propfind-space-00.txt Pages : 6 Date : 16-Sep-99 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 URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-webdav-propfind-space-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-propfind-space-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-propfind-space-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: <19990916073944.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-webdav-propfind-space-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-webdav-propfind-space-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19990916073944.I-D@ietf.org> --OtherAccess-- --NextPart-- From w3c-dist-auth-request@w3.org Fri Sep 17 09:48: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 JAA17165 for ; Fri, 17 Sep 1999 09:48:47 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id JAA05175; Fri, 17 Sep 1999 09:32:18 -0400 (EDT) Resent-Date: Fri, 17 Sep 1999 09:32:18 -0400 (EDT) Resent-Message-Id: <199909171332.JAA05175@www19.w3.org> From: ccjason@us.ibm.com X-Lotus-FromDomain: IBMUS To: "Geoffrey M. Clemm" cc: w3c-dist-auth@w3.org Message-ID: <852567EF.004A4CF4.00@D51MTA07.pok.ibm.com> Date: Fri, 17 Sep 1999 09:38:08 -0400 Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Subject: Re: Bindings, Locks, and MOVE Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3345 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list ------------------------------------------ Phone: 914-784-7569, ccjason@us.ibm.com "Geoffrey M. Clemm" @w3.org on 09/17/99 12:24:37 AM Sent by: w3c-dist-auth-request@w3.org To: w3c-dist-auth@w3.org cc: Subject: Re: Bindings, Locks, and MOVE S\ Dest r \ c \ \ empty | non-Coll | Collection +---------------+------------------+---------------- |NC->E |NC->NC |NC->C non | | | Coll | copy it | ?replace? | ? | | (bind new copy?) | -+---------------+------------------+---------------- |C->E |C->NC |C->C Coll | copy it | ? | copy members | & members | | only NC->NC is a combined PUT/PROPPATCH. All bindings to the destination continue to be valid. C->NC replaces NC with a copy of C. Any bindings to NC are now bindings to the copy of C. If the server cannot do this rebinding, it must fail the COPY request. NC->C replaces C with a copy of NC. Any bindings to C are now bindings to the copy of NC. If the server cannot do this rebinding, it must fail the COPY request. C->C Recursively perform the merge MOVE from every member of the source collection to the corresponding member of the destination collection. Note: there might be a client-side need for a version of this that isn't destructive. For example, what you recommend for NC->C can end up knocking a lot of resources out of the URI space. If the client is a human, she may not have realized that she was doing that... and may in fact not realize this until later. From w3c-dist-auth-request@w3.org Fri Sep 17 10:37: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 KAA19456 for ; Fri, 17 Sep 1999 10:37:27 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id KAA06102; Fri, 17 Sep 1999 10:23:36 -0400 (EDT) Resent-Date: Fri, 17 Sep 1999 10:23:36 -0400 (EDT) Resent-Message-Id: <199909171423.KAA06102@www19.w3.org> Date: Fri, 17 Sep 1999 10:23:26 -0400 Message-Id: <9909171423.AA04545@tantalum> From: "Geoffrey M. Clemm" To: w3c-dist-auth@w3.org In-Reply-To: <852567EF.004A4CF4.00@D51MTA07.pok.ibm.com> (ccjason@us.ibm.com) Subject: Re: Bindings, Locks, and MOVE Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3346 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 This is a discussion about a proposed COPY/Overwrite=merge operation, where X->Y means a copy of X to Y, and where C is a collection and NC is not a collection. NC->NC is a combined PUT/PROPPATCH. All bindings to the destination continue to be valid. C->NC replaces NC with a copy of C. Any bindings to NC are now bindings to the copy of C. If the server cannot do this rebinding, it must fail the COPY request. NC->C replaces C with a copy of NC. Any bindings to C are now bindings to the copy of NC. If the server cannot do this rebinding, it must fail the COPY request. C->C Recursively perform the merge MOVE from every member of the source collection to the corresponding member of the destination collection. Note: there might be a client-side need for a version of this that isn't destructive. For example, what you recommend for NC->C can end up knocking a lot of resources out of the URI space. If the client is a human, she may not have realized that she was doing that... and may in fact not realize this until later. The challenge is to define "non-destructive" in a way that is consistent and correct (i.e. does what the user wants). I predict that the only way to do a non-destructive COPY/merge is to have the client use the protocol to iterate through the source and destination resources, asking the user what to do in cases where something is being overwritten. This dialog is not something we can capture in a single HTTP method. I'd be happy to say that C->NC and NC->C just fail, thereby forcing the client to handle this case explicitly. Cheers, Geoff From w3c-dist-auth-request@w3.org Fri Sep 17 20:14: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 UAA03007 for ; Fri, 17 Sep 1999 20:14:54 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id TAA20962; Fri, 17 Sep 1999 19:57:24 -0400 (EDT) Resent-Date: Fri, 17 Sep 1999 19:57:24 -0400 (EDT) Resent-Message-Id: <199909172357.TAA20962@www19.w3.org> Message-ID: <37E2D321.102BC7BC@lyra.org> Date: Fri, 17 Sep 1999 16:47:45 -0700 From: Greg Stein X-Mailer: Mozilla 3.01 (X11; I; Linux 2.0.28 i586) MIME-Version: 1.0 To: francis@ecal.com CC: dav References: <199909171203.IAA04303@ietf.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: I-D ACTION:draft-ietf-webdav-propfind-space-00.txt Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3347 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 Internet-Drafts@ietf.org wrote: > > 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 PROPFIND Extension To List Specified Namespaces > Author(s) : J. Stracke > Filename : draft-ietf-webdav-propfind-space-00.txt > Pages : 6 > Date : 16-Sep-99 > > 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. This is quite cool, and mod_dav could easily support something like this. Just a few comments: * rather than specifying the uri as an XML attribute, shouldn't it be part of the elem contents? [I think I saw an argument somehwere (by Yaron?) that stated is was "best form" to avoid attributes that are specifiers, rather than modifiers] * do you want to explicitly state that can only appear as a child of and ? * your sample request in 5.2 has the propname/propfind end-elements swapped. Cheers, -g -- Greg Stein, http://www.lyra.org/ From w3c-dist-auth-request@w3.org Fri Sep 17 22:25:54 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 WAA04834 for ; Fri, 17 Sep 1999 22:25:52 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id WAA27208; Fri, 17 Sep 1999 22:09:03 -0400 (EDT) Resent-Date: Fri, 17 Sep 1999 22:09:03 -0400 (EDT) Resent-Message-Id: <199909180209.WAA27208@www19.w3.org> From: "Larry Masinter" To: "Yaron Goland (Exchange)" Cc: "'WebDAV'" Date: Fri, 17 Sep 1999 19:08:53 PDT Message-ID: <000401bf017a$c164a660$8b67010d@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: <078292D50C98D2118D090008C7E9C6A603C96612@STAY.platinum.corp.microsoft.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Subject: Good faith & protocol changes Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3348 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 exact same question, regarding moves and locks, came up in the past and > the group consensus was that we should not allow locks to MOVE with > resources. To revoke this decision is to pull the rug out of implementers > who took WebDAV in good faith. This is exactly the sort of behavior which > makes some many companies wary of dealing with the IETF. The rules change > too often. I suppose it's necessary to repeat this in every working group. The IETF rules for "Proposed Standard" are very clear and explicit. The rule hasn't changed. From RFC 2026: Implementors should treat Proposed Standards as immature specifications. It is desirable to implement them in order to gain experience and to validate, test, and clarify the specification. However, since the content of Proposed Standards may be changed if problems are found or better solutions are identified, deploying implementations of such standards into a disruption-sensitive environment is not recommended. Those who choose to implement and ship product based on Proposed Standard do so to gain the advantage of early market entry, against the risk that product changes might be necessary. I don't believe that changes from Proposed Standard should be made lightly or without good reason, but it is not "bad faith" to consider changes based on experience with the protocol. The ability to update protocols between Proposed and Draft Standard based on experience is a strength, not a weakness, of the IETF process. WebDAV is at an early stage of development and deployment, compared to what we will see in the future. Don't avoid doing the right thing just because some early implementors want to avoid shipping an update to their beta customers. Larry -- http://www.parc.xerox.com/masinter From w3c-dist-auth-request@w3.org Mon Sep 20 11:56:00 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 LAA04909 for ; Mon, 20 Sep 1999 11:56:00 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id LAA19525; Mon, 20 Sep 1999 11:41:59 -0400 (EDT) Resent-Date: Mon, 20 Sep 1999 11:41:59 -0400 (EDT) Resent-Message-Id: <199909201541.LAA19525@www19.w3.org> Message-ID: <37E655A3.126C9A1B@ecal.com> Date: Mon, 20 Sep 1999 11:41:23 -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: dav References: <199909171203.IAA04303@ietf.org> <37E2D321.102BC7BC@lyra.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: I-D ACTION:draft-ietf-webdav-propfind-space-00.txt Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3349 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 Greg Stein wrote: > Just a few comments: > > * rather than specifying the uri as an XML attribute, shouldn't it be > part of the elem contents? [I think I saw an argument somehwere (by > Yaron?) that stated is was "best form" to avoid attributes that are > specifiers, rather than modifiers] Mmm...yes, OK, that makes sense. Do you think should contain the URI directly, or contain ? The former reduces bandwidth & complexity by a tiny amount; the latter leverages the existing definitions better. > * do you want to explicitly state that can only appear > as a child of and ? Yes, that makes sense. Here's my new text: Purpose: The namespaces XML element introduces a set of namespace elements (below). appears inside or , and specifies that the PROPFIND request applies only to properties belonging to the namespaces listed in the enclosed namespace elements. > * your sample request in 5.2 has the propname/propfind end-elements > swapped. Whoops, so it does. Fixed. -- /==============================================================\ |John Stracke | http://www.ecal.com |My opinions are my own.| |Chief Scientist |=============================================| |eCal Corp. |Peace, justice, morality, culture, family, | |francis@ecal.com|sport, and the extinction of all other life | | |forms! | \==============================================================/ From w3c-dist-auth-request@w3.org Mon Sep 20 15:52:43 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 PAA09191 for ; Mon, 20 Sep 1999 15:52:43 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id PAA28742; Mon, 20 Sep 1999 15:37:52 -0400 (EDT) Resent-Date: Mon, 20 Sep 1999 15:37:52 -0400 (EDT) Resent-Message-Id: <199909201937.PAA28742@www19.w3.org> Date: Mon, 20 Sep 1999 15:37:41 -0400 Message-Id: <9909201937.AA06159@tantalum> From: "Geoffrey M. Clemm" To: w3c-dist-auth@w3.org Subject: URI mappings created by bindings Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3350 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 comments on the Adv. Collection protocol was that sections 5.3 and 5.4 were confusing. I suggest we replace those two sections with the following text: ---------------------------------------------------- 5.3 URI Mappings Created by a BIND Suppose a BIND request causes a binding from "Binding-Name" to resource R to be added to a collection, C. Then if C-MAP is the set of URL's that were mapped to C before the BIND request, then for all members, "C-URL" of C-MAP, the URL "C-URL/Binding-Name" is mapped to resource R following the BIND request. Note that if a binding is made to the collection itself (or to a parent of the collection), an infinite number of mappings is introduced. 5.4 Example: URI Mappings Created by a BIND For example, if a binding from "index.html" to R is added to the collection C, and if the following URL's are mapped to C: http://www.fuzz.com/A/1 http://fuzz.com/A/one then the following new mappings to R are introduced: http://www.fuzz.com/A/1/index.html http://fuzz.com/A/one/index.html If a binding from "myself" to C is then added to C, the following infinite number of additional mappings to C are introduced: http://www.fuzz.com/A/1/myself http://www.fuzz.com/A/1/myself/myself ... and the following infinite number of additional mappings to R are introduced: http://www.fuzz.com/A/1/myself/index.html http://www.fuzz.com/A/1/myself/myself/index.html ... ---------------------------------------------------- Cheers, Geoff From w3c-dist-auth-request@w3.org Mon Sep 20 21:51: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 VAA13004 for ; Mon, 20 Sep 1999 21:51:51 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id VAA05052; Mon, 20 Sep 1999 21:36:36 -0400 (EDT) Resent-Date: Mon, 20 Sep 1999 21:36:36 -0400 (EDT) Resent-Message-Id: <199909210136.VAA05052@www19.w3.org> Message-ID: <37E6DE39.712D1F64@lyra.org> Date: Mon, 20 Sep 1999 18:24:09 -0700 From: Greg Stein X-Mailer: Mozilla 3.01 (X11; I; Linux 2.0.28 i586) MIME-Version: 1.0 To: John Stracke CC: dav References: <199909171203.IAA04303@ietf.org> <37E2D321.102BC7BC@lyra.org> <37E655A3.126C9A1B@ecal.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: I-D ACTION:draft-ietf-webdav-propfind-space-00.txt Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3351 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 John Stracke wrote: > > Greg Stein wrote: > > > Just a few comments: > > > > * rather than specifying the uri as an XML attribute, shouldn't it be > > part of the elem contents? [I think I saw an argument somehwere (by > > Yaron?) that stated is was "best form" to avoid attributes that are > > specifiers, rather than modifiers] > > Mmm...yes, OK, that makes sense. Do you think should contain the URI directly, or > contain ? The former reduces bandwidth & complexity by a tiny amount; the latter leverages the > existing definitions better. The namespace is a URI. I believe an href is typically a URL (certainly "href" connotes this meaning). So... I would recommend that it just directly contains the URI rather than yet-another-element. Cheers, -g -- Greg Stein, http://www.lyra.org/ From w3c-dist-auth-request@w3.org Tue Sep 21 09:49: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 JAA02861 for ; Tue, 21 Sep 1999 09:49:39 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id JAA15250; Tue, 21 Sep 1999 09:36:01 -0400 (EDT) Resent-Date: Tue, 21 Sep 1999 09:36:01 -0400 (EDT) Resent-Message-Id: <199909211336.JAA15250@www19.w3.org> Message-ID: <37E7899B.EE02D2DE@ecal.com> Date: Tue, 21 Sep 1999 09:35:23 -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: dav References: <199909171203.IAA04303@ietf.org> <37E2D321.102BC7BC@lyra.org> <37E655A3.126C9A1B@ecal.com> <37E6DE39.712D1F64@lyra.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: I-D ACTION:draft-ietf-webdav-propfind-space-00.txt Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3352 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 Greg Stein wrote: > John Stracke wrote: > > > Mmm...yes, OK, that makes sense. Do you think should contain the URI directly, or > > contain ? The former reduces bandwidth & complexity by a tiny amount; the latter leverages the > > existing definitions better. > > The namespace is a URI. I believe an href is typically a URL (certainly > "href" connotes this meaning). ...the DAV spec says "URI". > So... I would recommend that it just directly contains the URI rather > than yet-another-element. This was the way I was leaning, too. The main question that made me wonder was, suppose someone wants to define a type of namespace that's defined by something other than a URI? (In such a case, it might be best to be able to swap out the element for something else.) However, I think the answer is that they should just define a new URI scheme. -- /=================================================================\ |John Stracke | http://www.ecal.com |My opinions are my own. | |Chief Scientist |================================================| |eCal Corp. |When rats leave a sinking ship, where exactly do| |francis@ecal.com|they think they're going? | \=================================================================/ From w3c-dist-auth-request@w3.org Tue Sep 21 10:21: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 KAA03693 for ; Tue, 21 Sep 1999 10:21:22 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id KAA16211; Tue, 21 Sep 1999 10:07:55 -0400 (EDT) Resent-Date: Tue, 21 Sep 1999 10:07:55 -0400 (EDT) Resent-Message-Id: <199909211407.KAA16211@www19.w3.org> Message-ID: <37E7911E.824FC085@ecal.com> Date: Tue, 21 Sep 1999 10:07:26 -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: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Motivation for draft-stracke-webdav-propfind-space-00 Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3353 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 Someone asked me offline what problem draft-stracke-webdav-propfind-space-00 was meant to solve; apparently my vague appeal to "A WebDAV application using a custom namespace for application-specific data" wasn't good enough. :-) Unfortunately, the application that required the extension is not yet public knowledge, but I can provide a couple of other scenarios. First, a bandwidth argument. Consider a Dublin Core application which is using draft-ietf-webdav-dublin-core (or something like it) to store DC metadata on a WebDAV server; it doesn't care about non-DC properties. It may prefer to send: http://purl.org/dc/elements/1.0/ rather than a listing the 15 DC elements. Second, consider the same DC application, except now it's also extensible: it wants to provide some minimal functionality for DC elements which did not exist when it was written, so it provides a UI to manipulate them, even if it can't tell the user what they mean. In this case, if it's using base WebDAV, it can't get every property in the DC namespace without getting every property, period. It could do a followed by a with all the property names it finds, but that's going to be really inefficient, since it requires two round trips. The extension enables it to get just the properties it wants, in one round trip. Third, consider a WebDAV server which is exposing some application-specific dataset as WebDAV resources. This dataset includes a property store which (for its own reasons) does not permit listing all properties; it can only list properties in a specific namespace. When an comes in without a , the server can't provide any properties from that store. -- /===============================================================\ |John Stracke | http://www.ecal.com |My opinions are my own. | |Chief Scientist |==============================================| |eCal Corp. |The Net was designed to survive nukes, but not| |francis@ecal.com|lawsuits. Wait a minute. | \===============================================================/ From w3c-dist-auth-request@w3.org Tue Sep 21 11:04:30 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 LAA04447 for ; Tue, 21 Sep 1999 11:04:30 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id KAA17428; Tue, 21 Sep 1999 10:51:01 -0400 (EDT) Resent-Date: Tue, 21 Sep 1999 10:51:01 -0400 (EDT) Resent-Message-Id: <199909211451.KAA17428@www19.w3.org> Message-ID: <8E3CFBC709A8D21191A400805F15E0DBD24461@crte147.wc.eso.mc.xerox.com> From: "Slein, Judith A" To: "'Geoffrey M. Clemm'" , w3c-dist-auth@w3.org Date: Tue, 21 Sep 1999 10:50:24 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Subject: RE: URI mappings created by bindings Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3354 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 great improvement, I think. More below. > -----Original Message----- > From: Geoffrey M. Clemm [mailto:gclemm@tantalum.atria.com] > Sent: Monday, September 20, 1999 3:38 PM > To: w3c-dist-auth@w3.org > Subject: URI mappings created by bindings > > > > One of the comments on the Adv. Collection protocol was that > sections 5.3 and 5.4 were confusing. I suggest we replace those > two sections with the following text: > > ---------------------------------------------------- > > > 5.3 URI Mappings Created by a BIND > > Suppose a BIND request causes a binding from "Binding-Name" to > resource R to be added to a collection, C. Then if C-MAP is the set > of URL's that were mapped to C before the BIND request, then for all > members, "C-URL" of C-MAP, the URL "C-URL/Binding-Name" is mapped to > resource R following the BIND request. > If R is a collection, additional URI mappings are created to the descendents of R. For each new URI mapping to R, there is a new URI mapping to each of its descendents. > Note that if a binding is made to the collection itself (or to a > parent of the collection), an infinite number of mappings is > introduced. > I get this now that I've looked at the examples, but it might be clearer if stated a little more formally, as you did in the first paragraph. "If R is identical to C or to a parent of C, an infinite number of URI mappings is introduced." > 5.4 Example: URI Mappings Created by a BIND > > For example, if a binding from "index.html" to R is added to the > collection C, and if the following URL's are mapped to C: > http://www.fuzz.com/A/1 > http://fuzz.com/A/one > then the following new mappings to R are introduced: > http://www.fuzz.com/A/1/index.html > http://fuzz.com/A/one/index.html > > If a binding from "myself" to C is then added to C, > the following infinite number of additional mappings to C are > introduced: > http://www.fuzz.com/A/1/myself > http://www.fuzz.com/A/1/myself/myself > ... > and the following infinite number of additional mappings to R > are introduced: > http://www.fuzz.com/A/1/myself/index.html > http://www.fuzz.com/A/1/myself/myself/index.html > ... > > ---------------------------------------------------- > > Cheers, > Geoff > > From w3c-dist-auth-request@w3.org Tue Sep 21 15:01: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 PAA08132 for ; Tue, 21 Sep 1999 15:01:34 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id OAA24858; Tue, 21 Sep 1999 14:45:44 -0400 (EDT) Resent-Date: Tue, 21 Sep 1999 14:45:44 -0400 (EDT) Resent-Message-Id: <199909211845.OAA24858@www19.w3.org> Message-ID: <078292D50C98D2118D090008C7E9C6A603C96651@STAY.platinum.corp.microsoft.com> From: "Yaron Goland (Exchange)" To: "'Slein, Judith A'" , "'Brian Stiles'" , w3c-dist-auth@w3.org, "Jim Whitehead (E-mail)" Date: Tue, 21 Sep 1999 11:45:22 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Clarification on MKCOL needed Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3355 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 an old and well known issue that many people mistakenly think is solved. The server is completely free to return to a PUT or MKCOL with a 200 O.k. and throw on a location header which points to the "real name" of the new resource while throwing away the client's proposed name. In practice no server I'm aware of does this and no client I'm aware of could properly handle this. If memory serves this issue is already on the WebDAV open issues list. Personally I think we should just adopt current practice which says that you must either accept the name or reject the request but that is just my $0.02. Yaron > -----Original Message----- > From: Slein, Judith A [mailto:JSlein@crt.xerox.com] > Sent: Monday, September 13, 1999 8:57 AM > To: 'Brian Stiles'; w3c-dist-auth@w3.org > Subject: RE: Clarification on MKCOL needed > > > I agree with you that this is a problem for all document > management systems. > I believe it is the most fundamental mismatch between the > WebDAV operational > model and the way document management systems work. It > affects not only > MKCOL, but all methods that result in the creation of new > resources (COPY, > MKREF, PUT, MKRESOURCE). > > It's also wound up with the requirement that WebDAV resource > names reflect > the collection hierarchy, which the server-generated names in document > management systems generally do not do. > > Document Management Systems will probably be forced to do > aliasing between > client names and server names, no matter how costly and > annoying that turns > out to be. > > --Judy > > Judith A. Slein > Xerox Corporation > jslein@crt.xerox.com > (716)422-5169 > 800 Phillips Road 105/50C > Webster, NY 14580 > > > > > -----Original Message----- > > From: Brian Stiles [mailto:bstiles@starbase.com] > > Sent: Friday, September 10, 1999 5:56 PM > > To: w3c-dist-auth@w3.org > > Subject: Clarification on MKCOL needed > > > > > > How can a WebDAV server support MKCOL if the repository the > server is > > built upon assigns names to newly created collections (as opposed to > > allowing clients to specify the name)? Put another way, how can a > > client create a collection on a WebDAV server using MKCOL if the > > collection that gets created must be assigned a URI by the server? > > For example, suppose that each collection is assigned an ID that is > > unique to the database that underlies the WebDAV server and > this ID is > > used to identify the collection in a URI (e.g., > > http://foo.com/121/13/4/). If a client wants to create a new > > collection, it must issue a MKCOL request to > > http://foo.com/121/13/4// but because of the fact that the > > server essentially controls the namespace, not the client, > the client > > can't know what to send for NEW_NAME. > > > > Am I missing some important piece of information here? I > assume that > > document management systems might be likely to encounter > this kind of > > problem. If so, has anyone dealt with it? > > > > Although it doesn't seem to be explicitly forbidden, I am assuming > > that it is inappropriate for the server to ignore the name in the > > request-URI and respond with a Location header that identifies the > > name assigned by the server. Though this seems like a possible > > solution, it seems contrary to the intent expressed in the spec. Or > > am I wrong in this assumption? > > > > -- > > Brian Stiles > > > From w3c-dist-auth-request@w3.org Tue Sep 21 15:28: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 PAA08402 for ; Tue, 21 Sep 1999 15:28:12 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id PAA25364; Tue, 21 Sep 1999 15:08:22 -0400 (EDT) Resent-Date: Tue, 21 Sep 1999 15:08:22 -0400 (EDT) Resent-Message-Id: <199909211908.PAA25364@www19.w3.org> Date: Tue, 21 Sep 1999 15:08:10 -0400 From: gclemm@atria.com (Geoffrey M. Clemm) Message-Id: <9909211908.AA06772@tantalum> To: w3c-dist-auth@w3.org X-Sun-Charset: US-ASCII Subject: RE: Clarification on MKCOL needed Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3357 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list Make the $0.04 (i.e. I agree with Yaron). Cheers, Geoff > To: "'Slein, Judith A'" , > > This is an old and well known issue that many people mistakenly think is > solved. > > The server is completely free to return to a PUT or MKCOL with a 200 O.k. > and throw on a location header which points to the "real name" of the new > resource while throwing away the client's proposed name. > > In practice no server I'm aware of does this and no client I'm aware of > could properly handle this. > > If memory serves this issue is already on the WebDAV open issues list. > Personally I think we should just adopt current practice which says that you > must either accept the name or reject the request but that is just my $0.02. > > Yaron > > > -----Original Message----- > > From: Slein, Judith A [mailto:JSlein@crt.xerox.com] > > > > I agree with you that this is a problem for all document > > management systems. > > I believe it is the most fundamental mismatch between the > > WebDAV operational > > model and the way document management systems work. It > > affects not only > > MKCOL, but all methods that result in the creation of new > > resources (COPY, > > MKREF, PUT, MKRESOURCE). > > > > It's also wound up with the requirement that WebDAV resource > > names reflect > > the collection hierarchy, which the server-generated names in document > > management systems generally do not do. > > > > Document Management Systems will probably be forced to do > > aliasing between > > client names and server names, no matter how costly and > > annoying that turns > > out to be. > > > > > > > -----Original Message----- > > > From: Brian Stiles [mailto:bstiles@starbase.com] > > > How can a WebDAV server support MKCOL if the repository the > > server is > > > built upon assigns names to newly created collections (as opposed to > > > allowing clients to specify the name)? Put another way, how can a > > > client create a collection on a WebDAV server using MKCOL if the > > > collection that gets created must be assigned a URI by the server? > > > For example, suppose that each collection is assigned an ID that is > > > unique to the database that underlies the WebDAV server and > > this ID is > > > used to identify the collection in a URI (e.g., > > > http://foo.com/121/13/4/). If a client wants to create a new > > > collection, it must issue a MKCOL request to > > > http://foo.com/121/13/4// but because of the fact that the > > > server essentially controls the namespace, not the client, > > the client > > > can't know what to send for NEW_NAME. > > > > > > Am I missing some important piece of information here? I > > assume that > > > document management systems might be likely to encounter > > this kind of > > > problem. If so, has anyone dealt with it? > > > > > > Although it doesn't seem to be explicitly forbidden, I am assuming > > > that it is inappropriate for the server to ignore the name in the > > > request-URI and respond with a Location header that identifies the > > > name assigned by the server. Though this seems like a possible > > > solution, it seems contrary to the intent expressed in the spec. Or > > > am I wrong in this assumption? From w3c-dist-auth-request@w3.org Tue Sep 21 15: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 PAA08412 for ; Tue, 21 Sep 1999 15:28:13 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id PAA25305; Tue, 21 Sep 1999 15:07:49 -0400 (EDT) Resent-Date: Tue, 21 Sep 1999 15:07:49 -0400 (EDT) Resent-Message-Id: <199909211907.PAA25305@www19.w3.org> Message-ID: <078292D50C98D2118D090008C7E9C6A603C96653@STAY.platinum.corp.microsoft.com> From: "Yaron Goland (Exchange)" To: "'ccjason@us.ibm.com'" , "Yaron Goland (Exchange)" Cc: w3c-dist-auth@w3.org Date: Tue, 21 Sep 1999 12:07:25 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Subject: RE: LOCK NULL reserves what? Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3356 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list To quote from section 7.5: A write lock on a collection, whether created by a "Depth: 0" or "Depth: infinity" lock request, prevents the addition or removal of member URIs of the collection by non-lock owners. Hence if a/b is WRITE locked then a singleton WRITE lock on a/ will fail because the WRITE lock on a/b, as specified in section 7.1, reserves the write for DELETE. In other words: 1. a/b is WRITE locked and thus has exclusive use of DELETE 2. The depth: 0 WRITE lock on a/ reserves the write to DELETE on a/ and its immediate children. 3. Since a/b is WRITE locked the WRITE lock depth:0 request on a/ MUST fail. Yaron > -----Original Message----- > From: ccjason@us.ibm.com [mailto:ccjason@us.ibm.com] > Sent: Thursday, August 19, 1999 4:47 PM > To: Yaron Goland (Exchange) > Cc: w3c-dist-auth@w3.org > Subject: RE: LOCK NULL reserves what? > > > > >> > 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 Tue Sep 21 17:40: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 RAA10257 for ; Tue, 21 Sep 1999 17:40:38 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id RAA28391; Tue, 21 Sep 1999 17:27:24 -0400 (EDT) Resent-Date: Tue, 21 Sep 1999 17:27:24 -0400 (EDT) Resent-Message-Id: <199909212127.RAA28391@www19.w3.org> From: ccjason@us.ibm.com X-Lotus-FromDomain: IBMUS To: "Yaron Goland (Exchange)" cc: w3c-dist-auth@w3.org Message-ID: <852567F3.00753C0C.00@D51MTA07.pok.ibm.com> Date: Tue, 21 Sep 1999 17:27:02 -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/3358 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list To quote from section 7.5: A write lock on a collection, whether created by a "Depth: 0" or "Depth: infinity" lock request, prevents the addition or removal of member URIs of the collection by non-lock owners. Hence if a/b is WRITE locked then a singleton WRITE lock on a/ will fail because the WRITE lock on a/b, as specified in section 7.1, reserves the write for DELETE. I take it you mean the "right to delete" rather than "write for DELETE". If not perhaps you can explain your phrasing. Also 7.1 of RFC 2518 doesn't talk about rights that the lock gives you, only what it prevents other folks from doing. In other words: 1. a/b is WRITE locked and thus has exclusive use of DELETE 2. The depth: 0 WRITE lock on a/ reserves the write to DELETE on a/ and its immediate children. 3. Since a/b is WRITE locked the WRITE lock depth:0 request on a/ MUST fail. 1. Hmm. Since I guess I asked for original intent, I guess this is fine, but my reading of the spec is that it doesn't give rights as much as it blocks other people's rights. If it's write locked, you have to hold the lock to modify it. If it's exclusively locked, noone else can get a write lock on it. BTW, I take it you mean that the write lock on a/b gives the holder the right to delete a/b. Although believable, that's interesting, because deletion has been thought to be an operation on the parent collection. And because this is the only case (except for URI protection) where a lock would lock a specific part of a collection. I do think this is valuable though. 2. Once again, I miss the part where the spec says a lock reserves a right... other than to block another principle. This might be implicit in the spec though. Of course, I asked intent, not what the spec says. 2. Also, Does a lock on a/ reserver the right to DELETE a/? We have been saying that locking a/ only controls the membership of a/ and doesn't apply to deleting a/ itself. If what you say was the intent, I think something has changed since this was originally conceived. 3. Interesting. Thanks. This definitely deserves discussion. BTW, the reason I make the distinction between a write lock giving one the right to modify a resource and a lock simply blocking others is because of URI protection. (You also provided a potential example.) I had assumed that if a resource deep in a tree was locked and therefore the URI was protected, another principle would still be allowed to write lock an ancestor collection. But that that write lock wouldn't give the second principle the right to break the protected URI. /a/b/c If /a/b/c is locked and the /a/b/c URI is protected... I assume someone else (person S) can write lock /a/. And I assume that the write lock on /a/ doesn't actually give person S the right to delete /a/b because that binding is protected by the lock at /a/b/c which he doesn't hold. But it does give person S the right to prevent someone else from deleting /a/b. This does of course beg the question of the effect of obtaining these locks in reverse order. This might be contrary to our expectations. I don't think of this as a problem with protection as much as a problem with our definitions of write lock... or more importantly, our lack of any other type of lock. J. From w3c-dist-auth-request@w3.org Tue Sep 21 19:26: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 TAA11294 for ; Tue, 21 Sep 1999 19:26:56 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id TAA00592; Tue, 21 Sep 1999 19:12:46 -0400 (EDT) Resent-Date: Tue, 21 Sep 1999 19:12:46 -0400 (EDT) Resent-Message-Id: <199909212312.TAA00592@www19.w3.org> Date: Tue, 21 Sep 1999 16:06:51 -0700 Message-ID: <6982-Tue21Sep1999160651-0700-bill@carpenter.ORG> X-Mailer: 20.4 "Emerald" XEmacs Lucid (via feedmail 9-beta-8 I); 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: <078292D50C98D2118D090008C7E9C6A603C96651@STAY.platinum.corp.microsoft.com> References: <078292D50C98D2118D090008C7E9C6A603C96651@STAY.platinum.corp.microsoft.com> Subject: RE: Clarification on MKCOL needed Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3359 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 yg> The server is completely free to return to a PUT or MKCOL with a yg> 200 O.k. and throw on a location header which points to the "real yg> name" of the new resource while throwing away the client's yg> proposed name. I don't think that's so. (Nit #1 is that "201 Created" is the response for a new resource.) More importantly, RFC-2068 has specific language about this situation for PUT (the following compares PUT to POST): In contrast, the URI in a PUT request identifies the entity enclosed with the request -- the user agent knows what URI is intended and the server MUST NOT attempt to apply the request to some other resource. If the server desires that the request be applied to a different URI, it MUST send a 301 (Moved Permanently) response; the user agent MAY then make its own decision regarding whether or not to redirect the request. I agree that a precise reading of the RFC-2518 definition of MKCOL allows a 201 response with a LOCATION: header, but one certainly has the impression from RFC-2518 that "MKCOL is just like PUT, but there is no enclosed entity comprising the contents of the new resource". If it is the intent that MKCOL differ from PUT is this fairly significant respect, I suggest that appropriate clarifying language be added, but I don't particularly see why such a difference should exist. The RFC-2068 specified behavior for PUT could be used to solve the problem of server-generated collection names if applied to MKCOL. When issuing the LOCATION: header, the server could secretly keep a record (with a timeout) of the fact that it had been sent. A couple hundred milliseconds later, the redirected request comes in with the same credentials and succeeds. If no redirected request comes within some timeout, the collection name could be harvested. -- 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 Tue Sep 21 22:30: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 WAA13432 for ; Tue, 21 Sep 1999 22:30:36 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id WAA02607; Tue, 21 Sep 1999 22:10:07 -0400 (EDT) Resent-Date: Tue, 21 Sep 1999 22:10:07 -0400 (EDT) Resent-Message-Id: <199909220210.WAA02607@www19.w3.org> Message-ID: <078292D50C98D2118D090008C7E9C6A603C9665F@STAY.platinum.corp.microsoft.com> From: "Yaron Goland (Exchange)" To: "'bill@carpenter.ORG'" , w3c-dist-auth@w3.org Date: Tue, 21 Sep 1999 19:09:36 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Subject: RE: Clarification on MKCOL needed Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3360 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 like it. > -----Original Message----- > From: bill@carpenter.ORG [mailto:bill@carpenter.ORG] > Sent: Tuesday, September 21, 1999 4:07 PM > To: w3c-dist-auth@w3.org > Subject: RE: Clarification on MKCOL needed > > > yg> The server is completely free to return to a PUT or MKCOL with a > yg> 200 O.k. and throw on a location header which points to the "real > yg> name" of the new resource while throwing away the client's > yg> proposed name. > > I don't think that's so. (Nit #1 is that "201 Created" is the > response for a new resource.) More importantly, RFC-2068 has specific > language about this situation for PUT (the following compares PUT to > POST): > > In contrast, the URI in a PUT request identifies the > entity enclosed > with the request -- the user agent knows what URI is > intended and the > server MUST NOT attempt to apply the request to some other > resource. > If the server desires that the request be applied to a > different URI, > it MUST send a 301 (Moved Permanently) response; the user agent MAY > then make its own decision regarding whether or not to redirect the > request. > > I agree that a precise reading of the RFC-2518 definition of MKCOL > allows a 201 response with a LOCATION: header, but one certainly has > the impression from RFC-2518 that "MKCOL is just like PUT, but there > is no enclosed entity comprising the contents of the new resource". > > If it is the intent that MKCOL differ from PUT is this fairly > significant respect, I suggest that appropriate clarifying > language be > added, but I don't particularly see why such a difference should > exist. > > The RFC-2068 specified behavior for PUT could be used to solve the > problem of server-generated collection names if applied to MKCOL. > When issuing the LOCATION: header, the server could secretly keep a > record (with a timeout) of the fact that it had been sent. A couple > hundred milliseconds later, the redirected request comes in with the > same credentials and succeeds. If no redirected request comes within > some timeout, the collection name could be harvested. > -- > 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 Sep 22 22:48: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 WAA18060 for ; Wed, 22 Sep 1999 22:48:09 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id WAA09417; Wed, 22 Sep 1999 22:33:22 -0400 (EDT) Resent-Date: Wed, 22 Sep 1999 22:33:22 -0400 (EDT) Resent-Message-Id: <199909230233.WAA09417@www19.w3.org> From: jamsden@us.ibm.com X-Lotus-FromDomain: IBMUS To: w3c-dist-auth@w3.org Message-ID: <852567F5.000E019E.00@d54mta03.raleigh.ibm.com> Date: Wed, 22 Sep 1999 22:11:22 -0400 Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Subject: Re: Bindings, Locks, and MOVE Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3361 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 only rationale that has been presented for having locks be lost after a MOVE is the case of cross-server MOVEs. The source server and destination server may use different URI schemes for lock tokens, so that the destination server may be unwilling to keep the same lock token for the MOVEd resource. We can make support for cross-server MOVEs of locked resources optional, and allow the destination server to replace the lock token with a different lock token. We'll provide a response header for it to use to report the new lock token. This is not the only rational for loosing locks. It is possible that the resource will be moved from one repository to another in the same WebDAV server, or from one pyysical drive to another. That is, the actual server implementation may change depending on the source and/or destination resources and/or the URLs used to access them. DAV4J supports multiple repository managers in the same server so clients can access resources from them without being aware of how the resources are actually stored. Unfortunately, MOVE is sometimes the same resource in a new location, and sometimes a new resource. Cross server MOVEs are almost certainly new resources. Depending on server implementations, MOVE within the same server might be too. I don't think the semantics of MOVE can depend on whether the resource is actually copied or not. Note that it is also possible that the supported live properties may change from location to location in the same server as well as across servers for the same reasons. If we want to control this behavior, we have to have two moves, one that copies and one that renames. Then servers can fail the operations if they can't support them. Finally, much of the justification for protocol changes is based on "user expectation". I would submit that the COPY/MOVE/LOCKing semantics are getting so complicated that most users will not be able to determine if their expectation is being meant or not. I continue to believe that MOVE and COPY need to be treated as a server convenience to reduce client/server interaction, and their semantics should be defined completely in terms of more primitive methods like GET/PROPFIND and PUT/PROPPATCH with or without DELETE. If this can't be done, then there might be something wrong with these methods, not COPY and MOVE. From w3c-dist-auth-request@w3.org Wed Sep 22 22:48: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 WAA18076 for ; Wed, 22 Sep 1999 22:48:39 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id WAA09511; Wed, 22 Sep 1999 22:36:36 -0400 (EDT) Resent-Date: Wed, 22 Sep 1999 22:36:36 -0400 (EDT) Resent-Message-Id: <199909230236.WAA09511@www19.w3.org> From: jamsden@us.ibm.com X-Lotus-FromDomain: IBMUS To: w3c-dist-auth@w3.org Message-ID: <852567F5.000E00F0.00@d54mta03.raleigh.ibm.com> Date: Wed, 22 Sep 1999 21:31:25 -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/3362 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list 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? :-) I don't really care that much one way or the other about lock-null resources. I think they add a lot of complexity to the protocol for little functional gain and wouldn't be opposed to removing them. But if they stay, that's OK too. If lock-null stays, then I think it would be reasonable for delete on a locked resource to change the state of the resource to a lock-null resource. To complete the delete, the client would have to do the unlock. This is at least consistent semantics and allows the protocol to support symmetric resource life-times. From w3c-dist-auth-request@w3.org Thu Sep 23 11:40: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 LAA09266 for ; Thu, 23 Sep 1999 11:40:50 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id LAA23380; Thu, 23 Sep 1999 11:22:02 -0400 (EDT) Resent-Date: Thu, 23 Sep 1999 11:22:02 -0400 (EDT) Resent-Message-Id: <199909231522.LAA23380@www19.w3.org> Date: Thu, 23 Sep 1999 11:21:46 -0400 Message-Id: <9909231521.AA07586@tantalum> From: "Geoffrey M. Clemm" To: jamsden@us.ibm.com Cc: w3c-dist-auth@w3.org In-Reply-To: <852567F5.000E00F0.00@d54mta03.raleigh.ibm.com> (jamsden@us.ibm.com) Subject: Re: DELETE leaving a lock-null resource; was LOCK Scenarios Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3363 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list After slightly wavering, I'm firmly back in the: "just say no to lock-null resources" camp. We just don't need the complexity of a "non-resource resource" for the minimal gain it provides. Cheers, Geoff From: jamsden@us.ibm.com 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? :-) I don't really care that much one way or the other about lock-null resources. I think they add a lot of complexity to the protocol for little functional gain and wouldn't be opposed to removing them. But if they stay, that's OK too. If lock-null stays, then I think it would be reasonable for delete on a locked resource to change the state of the resource to a lock-null resource. To complete the delete, the client would have to do the unlock. This is at least consistent semantics and allows the protocol to support symmetric resource life-times. From w3c-dist-auth-request@w3.org Thu Sep 23 13:34: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 NAA10762 for ; Thu, 23 Sep 1999 13:34:19 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id NAA27406; Thu, 23 Sep 1999 13:21:48 -0400 (EDT) Resent-Date: Thu, 23 Sep 1999 13:21:48 -0400 (EDT) Resent-Message-Id: <199909231721.NAA27406@www19.w3.org> From: Jim Whitehead To: WebDAV WG Date: Thu, 23 Sep 1999 10:17: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 Importance: Normal Subject: FW: Internet-Draft Cut-off for DC IETF Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3364 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 FYI. - Jim -----Original Message----- From: scoya@cnri.reston.va.us [mailto:scoya@cnri.reston.va.us]On Behalf Of Internet-Drafts Administrator Sent: Thursday, September 23, 1999 5:11 AM To: IETF-Announce: ; Subject: Internet-Draft Cut-off for DC IETF The cut-off for Internet-Draft submissions prior to the Washington, DC IETF meeting is Friday, October 22, 1999 at 5pm ET. Internet-Drafts received after this time will not be announced nor made available in the Internet-drafts Directories. We will begin processing Internet-Draft submissions the week of the meeting, though announcements will NOT be sent until the IETF meeting is over. Thank you for your understanding and cooperation. Please do not hesitate to contact us if you have any questions or concerns. Note: ALL initial submissions (-00.txt) with a filename beginning with draft-ietf MUST be approved by the appropriate WG chair prior to processing and announcing. WG Chair approval must be received prior to the I-D cutoff date. As such, -00 submissions received the day of the cut-off will NOT be processed as WG documents. Do NOT wait until the last minute. From w3c-dist-auth-request@w3.org Fri Sep 24 02:55: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 CAA29338 for ; Fri, 24 Sep 1999 02:55:18 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id CAA08903; Fri, 24 Sep 1999 02:40:35 -0400 (EDT) Resent-Date: Fri, 24 Sep 1999 02:40:35 -0400 (EDT) Resent-Message-Id: <199909240640.CAA08903@www19.w3.org> Message-ID: <078292D50C98D2118D090008C7E9C6A603C96678@STAY.platinum.corp.microsoft.com> From: "Yaron Goland (Exchange)" To: "'Geoffrey M. Clemm'" , jamsden@us.ibm.com Cc: w3c-dist-auth@w3.org Date: Thu, 23 Sep 1999 23:40:19 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Subject: RE: DELETE leaving a lock-null resource; was LOCK Scenarios Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3365 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 suggestion has been made that we introduce transactioning. I hope you will not think me cheeky if I summarily reject the suggestion of using transactioning. I, for one, would really like to be able to sell webdav servers for something under $100,000 a piece. Small problems need small solutions. Big problems need big solutions. Lock-null solves a small problem. We do not in the 99% case need transactioning. There are systems that need transactioning and for those guys I would recommend looking at TIP (RFC 2371). I actually released a spec at one point specifying how to use TIP with HTTP and I have another spec I haven't released which shows how to implement the TIP protocol itself using HTTP. I did the later mostly because I hate seeing people inventing arbitrary new protocols which can be implemented with existing systems for no particularly good reason. But I digress... Either way, lock null, much like PROPPATCH and LOCKs themselves, were introduced to cover small areas of transactioning like semantics that even low end systems require. Believe me, we WANTED to require transactioning. Every time I look at PROPPATCH I want to vomit. It violates just about every principal of good protocol design. I have similar feelings about multi-status but that was required due to a flaw in HTTP's design not due to the lock of transactioning. In either case, we had to make a choice between designing a system that people could implement and one that read well on paper. BTW, in so far as what happens when you DELETE a locked resource I completely oppose the suggestion that DELETING a resource results in a lock-null resource. That is absolutely contrary to the definition of DELETE. DELETE deletes the resource not the name. Since the lock is associated with the resources deleting a locked resource deletes both the resource and the lock. Yaron > -----Original Message----- > From: Geoffrey M. Clemm [mailto:gclemm@tantalum.atria.com] > Sent: Thursday, September 23, 1999 8:22 AM > To: jamsden@us.ibm.com > Cc: w3c-dist-auth@w3.org > Subject: Re: DELETE leaving a lock-null resource; was LOCK Scenarios > > > After slightly wavering, I'm firmly back in the: > "just say no to lock-null resources" camp. > We just don't need the complexity of a "non-resource resource" > for the minimal gain it provides. > > Cheers, > Geoff > > From: jamsden@us.ibm.com > > > 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? :-) > > > > I don't really care that much one way or the other about > lock-null resources. I > think they add a lot of complexity to the protocol for > little functional gain > and wouldn't be opposed to removing them. But if they > stay, that's OK too. If > lock-null stays, then I think it would be reasonable for > delete on a locked > resource to change the state of the resource to a > lock-null resource. To > complete the delete, the client would have to do the > unlock. This is at least > consistent semantics and allows the protocol to support > symmetric resource > life-times. > > > From w3c-dist-auth-request@w3.org Fri Sep 24 06:41: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 GAA00784 for ; Fri, 24 Sep 1999 06:41:26 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id FAA12564; Fri, 24 Sep 1999 05:48:33 -0400 (EDT) Resent-Date: Fri, 24 Sep 1999 05:48:33 -0400 (EDT) Resent-Message-Id: <199909240948.FAA12564@www19.w3.org> Date: Fri, 24 Sep 1999 05:48:22 -0400 Message-Id: <9909240948.AA08092@tantalum> From: "Geoffrey M. Clemm" To: w3c-dist-auth@w3.org In-Reply-To: <078292D50C98D2118D090008C7E9C6A603C96678@STAY.platinum.corp.microsoft.com> (yarong@Exchange.Microsoft.com) Subject: Re: DELETE leaving a lock-null resource; was LOCK Scenarios Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3366 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)" The suggestion has been made that we introduce transactioning. I hope you will not think me cheeky if I summarily reject the suggestion of using transactioning. ... I agree with Yaron that we do not want to bite off general transactioning support as part of WebDAV. BTW, in so far as what happens when you DELETE a locked resource I completely oppose the suggestion that DELETING a resource results in a lock-null resource. That is absolutely contrary to the definition of DELETE. DELETE deletes the resource not the name. Since the lock is associated with the resources deleting a locked resource deletes both the resource and the lock. If lock were *really* just associated with the resource, I'd be a happy camper. For one thing, it would mean that when multiple URL's are mapped to a single resource, you could issue the LOCK against any of those URL's and the result would be identical. Similarly, you could later on issue on UNLOCK against any of those URL's and again, the result would be identical. But I have seen various arguments in the past that a LOCK should also protect the URL to resource mapping. If "protect" just means "keep from being deleted", then your conclusion still holds, i.e. it makes no sense to LOCK a deleted resource. But if protect also means "reserves the right to change the URL to resource mapping", then it is perfectly sensible to keep a LOCK after the resource is deleted (that is pretty much what a lock-null resource is anyway). I personally believe that the best answer is to fix the LOCK semantics so it *really* is just on the resource (and not on the name). Then things are simpler and consistent, even in the case of multiple URL mappings to a resource. Rather than "protecting" a URL to resource mapping, I'd propose that a locked resource be allowed to MOVE (this is just a change to the state of the parent collection, not to the state of the resource being moved), but that an attempt to access the MOVE'd resource with that lock just returns a 302 indicating where it has MOVE'd to. And as for the question of whether DELETE deletes all bindings to a resource or whether it just DELETE's the binding named in the DELETE request-URL, I am an adamant supporter of the current advanced collection protocol specification which states that it *only* deletes the binding named in the DELETE request-URL. This behavior is *essential* in order to allow versioning-unaware clients to be able to issue a DELETE without destroying the history of a resource. So there are really multiple threads here: - Should locking be on a resource or also/instead on a URL-to-resource mapping? (we know what it is now, but what *should* it be) * I vote "on a resource". - Does a DELETE delete all bindings to a resource, or just the one specified in the request-URL. * I vote "just the one named by the request-URL". - Should a DELETE delete a LOCK? * I vote, "no". A DELETE modifies the state of the collection containing the binding, not that of the resource. In particular, all other mappings to that resource will continue to exist and display the LOCK'ed semantics. If you want to prevent a DELETE, you put the LOCK on the collection whose state is being modified. I realize that this requires changes to 2518, and I would not make such a suggestion lightly. The problem is that 2518 was specified without the use cases of multiple bindings and versioning in mind, and needs to be revisited now that those use cases have been elaborated. Cheers, Geoff From w3c-dist-auth-request@w3.org Fri Sep 24 08:00: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 IAA01474 for ; Fri, 24 Sep 1999 08:00:24 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id HAA13706; Fri, 24 Sep 1999 07:02:23 -0400 (EDT) Resent-Date: Fri, 24 Sep 1999 07:02:23 -0400 (EDT) Resent-Message-Id: <199909241102.HAA13706@www19.w3.org> Message-ID: <37EB59FE.8785C4AF@de.bosch.com> Date: Fri, 24 Sep 1999 13:01:18 +0200 From: Edgar Schwarz X-Mailer: Mozilla 4.05 [en] (X11; I; HP-UX B.10.20 9000/778) MIME-Version: 1.0 To: w3c-dist-auth@w3.org References: <9909240948.AA08092@tantalum> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: DELETE leaving a lock-null resource; was LOCK Scenarios Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3367 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 Geoffrey M. Clemm wrote: > But I have seen various arguments in the past that a LOCK should > also protect the URL to resource mapping. For my part I was just concerned that the locker should be able to find his locked resource after a MOVE. > to resource mapping, I'd propose that a locked resource be allowed to > MOVE (this is just a change to the state of the parent collection, not > to the state of the resource being moved), but that an attempt to > access the MOVE'd resource with that lock just returns a 302 indicating > where it has MOVE'd to. This would give me what I wanted. I even could imagine that it is enough that only a access with the lock token MUST get the new location. For all others it's just gone, like other resources which are moved. So a server could just remember lock tokens together with old and new URLs and keep this data until it is accessed by the locker or the lock expires. > So there are really multiple threads here: > - Should locking be on a resource or also/instead on a URL-to-resource > mapping? (we know what it is now, but what *should* it be) > * I vote "on a resource". > - Does a DELETE delete all bindings to a resource, or just the one > specified in the request-URL. > * I vote "just the one named by the request-URL". > - Should a DELETE delete a LOCK? > * I vote, "no". A DELETE modifies the state of the collection containing > the binding, not that of the resource. In particular, all other > mappings to that resource will continue to exist and display the > LOCK'ed semantics. If you want to prevent a DELETE, you put the > LOCK on the collection whose state is being modified. Agreement on all points. The last couple of days I thought that already too much energy was spent with this topic. This proposal seems to be as simple as possible, but not simpler. Regards, Edgar -- Edgar.Schwarz@de.bosch.com ON/EUE1, 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 Fri Sep 24 09:25: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 JAA03002 for ; Fri, 24 Sep 1999 09:25:38 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id IAA15390; Fri, 24 Sep 1999 08:59:41 -0400 (EDT) Resent-Date: Fri, 24 Sep 1999 08:59:41 -0400 (EDT) Resent-Message-Id: <199909241259.IAA15390@www19.w3.org> Date: Fri, 24 Sep 1999 08:59:28 -0400 Message-Id: <9909241259.AA08183@tantalum> From: "Geoffrey M. Clemm" To: w3c-dist-auth@w3.org In-Reply-To: <37EB59FE.8785C4AF@de.bosch.com> (message from Edgar Schwarz on Fri, 24 Sep 1999 13:01:18 +0200) Subject: Re: DELETE leaving a lock-null resource; was LOCK Scenarios Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3368 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: Edgar Schwarz > But I have seen various arguments in the past that a LOCK should > also protect the URL to resource mapping. For my part I was just concerned that the locker should be able to find his locked resource after a MOVE. Yes, I believe that is the essential functionality to be provided, in addition to the lock on the state of the resource. to resource mapping, I'd propose that a locked resource be allowed to MOVE (this is just a change to the state of the parent collection, not to the state of the resource being moved), but that an attempt to access the MOVE'd resource with that lock just returns a 302 indicating where it has MOVE'd to. This would give me what I wanted. I even could imagine that it is enough that only a access with the lock token MUST get the new location. For all others it's just gone, like other resources which are moved. So a server could just remember lock tokens together with old and new URLs and keep this data until it is accessed by the locker or the lock expires. Ah yes, *much* better than the 302's, and provides better compatibility with clients written against the existing locking protocol. Great idea, Edgar! > So there are really multiple threads here: > - Should locking be on a resource or also/instead on a URL-to-resource > mapping? (we know what it is now, but what *should* it be) > * I vote "on a resource". > - Does a DELETE delete all bindings to a resource, or just the one > specified in the request-URL. > * I vote "just the one named by the request-URL". > - Should a DELETE delete a LOCK? > * I vote, "no". A DELETE modifies the state of the collection containing > the binding, not that of the resource. In particular, all other > mappings to that resource will continue to exist and display the > LOCK'ed semantics. If you want to prevent a DELETE, you put the > LOCK on the collection whose state is being modified. Agreement on all points. The last couple of days I thought that already too much energy was spent with this topic. This proposal seems to be as simple as possible, but not simpler. I've been agonizing for months over trying to make the existing locking protocol work unmodified in the presence of multiple bindings and versioning. There are massive numbers of edge cases and things that just plain don't work. If you just say that a lock is on a resource, and then use Edgar's proposal that a lock token combined with the original URL guarantee access to that resource, then multiple bindings and versioning semantics interacts can be combined with locking in a manageable fashion. I'll make a pass through the current version of 2518 to identify the sections that would need to be modified, and will run this against Judy's list of use cases for locking in the presence of multiple bindings, to see how the details play out. Cheers, Geoff From w3c-dist-auth-request@w3.org Fri Sep 24 10:03: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 KAA04079 for ; Fri, 24 Sep 1999 10:03:35 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id JAA16892; Fri, 24 Sep 1999 09:47:19 -0400 (EDT) Resent-Date: Fri, 24 Sep 1999 09:47:19 -0400 (EDT) Resent-Message-Id: <199909241347.JAA16892@www19.w3.org> From: jamsden@us.ibm.com X-Lotus-FromDomain: IBMUS To: w3c-dist-auth@w3.org Message-ID: <852567F6.004BA9FE.00@d54mta03.raleigh.ibm.com> Date: Fri, 24 Sep 1999 09:44:50 -0400 Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Subject: DELETE Semantics Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3369 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 personally believe that the best answer is to fix the LOCK semantics so it *really* is just on the resource (and not on the name). Then things are simpler and consistent, even in the case of multiple URL mappings to a resource. Rather than "protecting" a URL to resource mapping, I'd propose that a locked resource be allowed to MOVE (this is just a change to the state of the parent collection, not to the state of the resource being moved), but that an attempt to access the MOVE'd resource with that lock just returns a 302 indicating where it has MOVE'd to. But some moves will result in a change in state of the resource being moved, and this is server dependent. The new parent collection may be in a collection that has different OPTIONS then the old parent, e.g., in a different repository manager. It may also have different live properties. This isn't just a cross-server move issue. The semantics of MOVE can't be defined as rebind (rename) and copy/delete at the same time. MOVE can however be implemented that way. As a result, one doesn't know if the resource is new or not after a MOVE, and therefore locks can't be guaranteed to be retained. Therefore, the semantics must pick the conservative case and not move locks. Take for example moves in typical file systems. Sometimes the file actually moves (gets a new INODE in UNIX) and sometimes it doesn't Users don't see this unless they are manipulating INODES directly which is playing with the implementation, not the protocol. Moving locks has lots of other problems too as there is a possible conflict with the potentially inherited lock from the new destination parent collection. Lock tokens are server dependent, and may be repository dependent too. Seems like loosing the lock is the lesser of the evils. So there are really multiple threads here: - Should locking be on a resource or also/instead on a URL-to-resource mapping? (we know what it is now, but what *should* it be) * I vote "on a resource". I agree. The resource is the thing being manipulated, not the URL. The URL is only a way to get to the resource. There may be other ways, and no way. - Does a DELETE delete all bindings to a resource, or just the one specified in the request-URL. * I vote "just the one named by the request-URL". I have to disagree with this one as it is not consistent with LOCK. If LOCK, GET, PUT, etc. apply to the resource, then so should DELETE. If bindings are created with a BIND method, then they should be removed with an UNBIND method. Otherwise, URL to resource mappings (i.e., bindings) must be exposed as separate resources (direct and redirect referencs) so they can be managed discretely. DELETE should stick to manipulating resources as defined in HTTP/1.1. - Should a DELETE delete a LOCK? * I vote, "no". A DELETE modifies the state of the collection containing the binding, not that of the resource. In particular, all other mappings to that resource will continue to exist and display the LOCK'ed semantics. If you want to prevent a DELETE, you put the LOCK on the collection whose state is being modified. I wish I could agree with this one, but I can't. DELETE deletes a resource and as a side effect it modifies the state of its parent collection(s). It is unfortunate that PUT and DELETE are resource behaviors instead of having addMember, removeMember be operations on the parent collection. It is hard to recover from the resulting mixed semantics, but WebDAV does a reasonable job already. I think we should leave this alone. From w3c-dist-auth-request@w3.org Fri Sep 24 11:11: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 LAA06262 for ; Fri, 24 Sep 1999 11:11:34 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id KAA18560; Fri, 24 Sep 1999 10:58:43 -0400 (EDT) Resent-Date: Fri, 24 Sep 1999 10:58:43 -0400 (EDT) Resent-Message-Id: <199909241458.KAA18560@www19.w3.org> Date: Fri, 24 Sep 1999 10:58:31 -0400 Message-Id: <9909241458.AA08300@tantalum> From: "Geoffrey M. Clemm" To: w3c-dist-auth@w3.org In-Reply-To: <852567F6.004BA9FE.00@d54mta03.raleigh.ibm.com> (jamsden@us.ibm.com) Subject: Re: DELETE Semantics Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3370 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: jamsden@us.ibm.com I personally believe that the best answer is to fix the LOCK semantics so it *really* is just on the resource (and not on the name). Then things are simpler and consistent, even in the case of multiple URL mappings to a resource. Rather than "protecting" a URL to resource mapping, I'd propose that a locked resource be allowed to MOVE (this is just a change to the state of the parent collection, not to the state of the resource being moved), but that an attempt to access the MOVE'd resource with that lock just returns a 302 indicating where it has MOVE'd to. Note: Amend this to use Edgar's proposal that the pair always access the locked resource. But some moves will result in a change in state of the resource being moved, and this is server dependent. The new parent collection may be in a collection that has different OPTIONS then the old parent, e.g., in a different repository manager. It may also have different live properties. This isn't just a cross-server move issue. A MOVE (as being proposed by the advanced collection protocol) is not allowed to change the state of the resource - it just changes the state of the source and destination collections that contain the resource. If a server cannot implement the MOVE without changing the state of the resource, the MOVE MUST fail, and the client may resort to a COPY/DELETE if it does not need MOVE (i.e. state preserving) semantics. The semantics of MOVE can't be defined as rebind (rename) and copy/delete at the same time. I completely agree. I should be defined as a rebind (rename). I hope we're not bringing back the "logically equivalent to a COPY/fixup/DELETE" dead horse? It has been thoroughly flogged (:-). MOVE can however be implemented that way. Not if it is going to support advanced collections (and not if it is going to support most people's intuition of how a MOVE differs from a COPY). A MOVE produces no new resources, but changes one of the bindings to an existing resource. A COPY/DELETE produces a new resource with just one binding, and leaves an existing resource with one less binding. As a result, one doesn't know if the resource is new or not after a MOVE, and therefore locks can't be guaranteed to be retained. I believe that if we leave the semantics of MOVE as vague as they are in 2518 (i.e. some arbitrary "fixup" step is involved), we will continue to see the confusion about what a MOVE does/should mean that we see today. The proposed semantics are simple: if you can't guarantee that locks are retained, the MOVE MUST fail. If the client wants the locks to be removed, it can (and should) explicitly remove them. A key use case here is with multiple bindings. You issue a LOCK on /x/y.html. It turns out that is bound to the same resource as /a/b.html. Now you move /a/b.html to /a/oldb.html. So you now lose your lock on /x/y.html? I'm not a happy client if that's the case. Therefore, the semantics must pick the conservative case and not move locks. Take for example moves in typical file systems. Sometimes the file actually moves (gets a new INODE in UNIX) and sometimes it doesn't Users don't see this unless they are manipulating INODES directly which is playing with the implementation, not the protocol. As a general comment, there is no reason for us to exactly mimic Unix file behavior (although I agree that there is lots of wisdom embedded in the Unix file system that we should learn from). As a particular comment, as you point out, the INODE is part of the file system implementation that is rarely exposed/used by a client. The fact that the inode changes is largely not a visible state change from a clients perspective, and that is the perspective that matters. Moving locks has lots of other problems too as there is a possible conflict with the potentially inherited lock from the new destination parent collection. This is not a problem (although I am against inherited locks for other reasons). If there is a conflict, the server simply MUST fail the operation that would cause the conflict. Better that than removing locks as a side-effect of the MOVE operation. Lock tokens are server dependent, and may be repository dependent too. Seems like loosing the lock is the lesser of the evils. What evil are we avoiding? If the MOVE fails (because of inability to keep the lock on the resource), the client is notified, and is then free to explicitly removes the locks and then requests the MOVE again. So there are really multiple threads here: - Should locking be on a resource or also/instead on a URL-to-resource mapping? (we know what it is now, but what *should* it be) * I vote "on a resource". I agree. The resource is the thing being manipulated, not the URL. The URL is only a way to get to the resource. There may be other ways, and no way. Whew ... at least we agree on that! (:-). - Does a DELETE delete all bindings to a resource, or just the one specified in the request-URL. * I vote "just the one named by the request-URL". I have to disagree with this one as it is not consistent with LOCK. I disagree (see below). But even if this were true, I'd suggest that we fix the LOCK semantics rather than making DELETE unusable against versioning servers. If LOCK, GET, PUT, etc. apply to the resource, then so should DELETE. Why exactly? I believe that what matters is getting the semantics right so that clients and servers can interoperate. I believe it is important to have a definition of DELETE that works in the presence of versioning, and the "delete-all-bindings" semantics does not. If bindings are created with a BIND method, then they should be removed with an UNBIND method. Otherwise, URL to resource mappings (i.e., bindings) must be exposed as separate resources (direct and redirect referencs) so they can be managed discretely. DELETE should stick to manipulating resources as defined in HTTP/1.1. Then a versioning server will have to refuse every DELETE operation issued by a non-versioning aware server. Roy Fielding has verified that the single binding definition of DELETE matches his intentions when the HTTP-1.1 spec was defined. So what is the benefit we are reaping that matches the cost of non-interoperability between versioning servers and non-versioning aware clients? - Should a DELETE delete a LOCK? * I vote, "no". A DELETE modifies the state of the collection containing the binding, not that of the resource. In particular, all other mappings to that resource will continue to exist and display the LOCK'ed semantics. If you want to prevent a DELETE, you put the LOCK on the collection whose state is being modified. I wish I could agree with this one, but I can't. DELETE deletes a resource and as a side effect it modifies the state of its parent collection(s). It is unfortunate that PUT and DELETE are resource behaviors instead of having addMember, removeMember be operations on the parent collection. It is hard to recover from the resulting mixed semantics, but WebDAV does a reasonable job already. I think we should leave this alone. This is too broken to leave alone, and too easy to fix to not do so. Define DELETE and MOVE as binding operations, and you get full compatibility with existing HTTP behavior, simple semantics, and interoperability between versioning/binding aware and versioning/binding unaware clients and servers. Cheers, Geoff From w3c-dist-auth-request@w3.org Fri Sep 24 14:47: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 OAA10866 for ; Fri, 24 Sep 1999 14:47:06 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id OAA24964; Fri, 24 Sep 1999 14:33:47 -0400 (EDT) Resent-Date: Fri, 24 Sep 1999 14:33:47 -0400 (EDT) Resent-Message-Id: <199909241833.OAA24964@www19.w3.org> From: Jim Whitehead To: w3c-dist-auth@w3.org MMDF-Warning: Parse error in original version of preceding line at gremlin-relay.ics.uci.edu Date: Fri, 24 Sep 1999 11:29: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: <078292D50C98D2118D090008C7E9C6A603C965A0@STAY.platinum.corp.microsoft.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Importance: Normal Subject: RE: WebDAV Working Group Meeting Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3371 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 Well, I was off-net for several weeks when this first came up, and am only now at the point where I can give it some attention. *sigh* > General comment: Why do we need a meeting for this? This sounds like great > material for an e-mail list and it will have the extra added benefit of > allowing everyone to participate. I don't know about you folks but NC is > REALLY far away from where I am. Well, Yaron's comment is well-taken: these issues can all be discussed on the mailing list. So, in the next few messages, I'll be starting threads on several of these issues -- I look forward to list discussion on them. - Jim > > > 1. Discuss creating a WebDAV support organization ("webdav.org") > > But, it already exists. http://webdav.org > > > 2. Discuss the future of the WebDAV effort > > > > With the WG closing soon, we should determine if is a need to > > create a new WG > > (DAVEXT, say) for known extensions (access control, schemas, > > etc.). What work > > items should be addressed by this new WG? > > Individual submissions sound fine to me. No need to clutter up > the IETF with > a whole bunch of WGs for every effort under the sun. If an effort gets big > enough then it can go for WG status. > > > 3. Organizing an interoperability event > > Why? I know bake offs are popular but WebDAV seems to have been having a > continual back off for months now just by having folks put their > implementations on the net. Unless I have seriously missed something it > seems to work damn well. > > > 4. Moving RFC 2518 to Draft Standard > > Personally, I would like to see this held off for at least a year. I think > it was a huge mistake for HTTP/1.1 to push to draft status long > before there > was any real experience with the protocol. Except for a few propeller head > implementations there wasn't a single full featured commercial HTTP/1.1 > client or proxy implementation available when HTTP/1.1 started going to > draft status. The end result is that RFC 2616 added very little > value and a > lot of confusion. I think we should take this as a model of what > not to do. > Instead we should wait until a number of implementations, both on > the client > and server side, are widely deployed and we get some real world > experience. > That has not happened yet, not even close. > > > 5. Final review on the Advanced Collections specifications > > The only relevant review of the AC draft is, of course, on the e-mail list > but I can certainly appreciate why you would want to do this at a meeting. > However I think we have enough time at the IETF for this. > > > 6. Discuss/review/work on the Access Control specification > > Indeed, this has been a real problem. I am going to get out a new > version of > the ACL draft which I think basically has it right, it just needs > some clean > up. Comments are always welcome. If anyone has the meeting notes for the > Florida ACL chat please put up a link, I think the discussion was > extremely > informative as to why there hasn't been a lot of progress on ACLs. > > > 7. Review/work on DASL (DAV Searching and Locating) > > Huh? Isn't that why we have a DASL WG? > > > 8. Discussion/review/work on the Delta-V protocol > > How about we first get a charter. But, that having been said, a meeting on > Delta-V would obviously be very useful. > > > > > IBM is considering hosting this meeting at our Research > > Triangle Park facility > > in RTP NC during the week of October 25. > > Sigh... I wish we could do this after the IETF. The week of Oct 20th is > pretty bad for me. But of course, that is just me. > > > We would like some > > feedback to see if > > there is sufficient interest, additional agenda items, and an > > indication of how > > may working group members would be interested in attending. > > If there is > > sufficient interest and attendance, we will petition the area > > directors for > > permission to schedule the meeting. Thank you for you > > continued interest in > > WebDAV. > > ADs do not give permission to schedule meetings outside the IETF. > Why would > they? The only place you can do anything "on the record" is on the e-mail > list. The IETF meetings are just a convenience to help the mailing lists > better function and meetings outside of the IETF meetings are completely > outside the purview of the IETF. The only time the IETF gets involved with > meetings held completely outside the IETF process is if those > meetings start > being where real work is done to the detriment of the mailing > list. In that > case the ADs will step in. A classic example of what not to do > would be the > IPP effort. > > Either way, unless Keith has changed his mind, as of the end of this month > WebDAV is closed. There is no more WebDAV, there are no more > meetings. That > doesn't mean you shouldn't have meetings on ACLs and on Delta-V. > In fact, by > the next IETF Delta-V should be a WG (Keith?). I know we have had ACL > meetings but I don't know if we ever had a BOF. > > > > > Sent by Jim Amsden and Jim Whitehead > > > > Send by Yaron > From w3c-dist-auth-request@w3.org Fri Sep 24 15:04: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 PAA11245 for ; Fri, 24 Sep 1999 15:04:41 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id OAA25641; Fri, 24 Sep 1999 14:52:19 -0400 (EDT) Resent-Date: Fri, 24 Sep 1999 14:52:19 -0400 (EDT) Resent-Message-Id: <199909241852.OAA25641@www19.w3.org> From: jamsden@us.ibm.com X-Lotus-FromDomain: IBMUS To: w3c-dist-auth@w3.org Message-ID: <852567F6.00679E57.00@d54mta03.raleigh.ibm.com> Date: Fri, 24 Sep 1999 14:49:47 -0400 Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Subject: Re: DELETE Semantics Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3372 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 everything Geoff says below. The problems we're having result from mixing the semantics of: 1. a resource and its contents/properties 2. URLs we use to access a resource. Note that a resource may have some server-dependent objectId that distinguishes it from all other resources managed by that server, but this is not a URL and is not exposed to HTTP clients. This is the ID the server maps URL bindings to. 3. membership in a collection Here's a summary of what I think we agreed to: 1. all URL references to a resource are bindings, including the PUT or MKCOL used to create the resource in the first place. 2. DELETE is effectively an UNBIND. A server is free to garbage collect and actually destroy the resource if there are no remaining bindings, but this is not defined by the protocol. 3. There is no DESTROY method that deletes the resource and all its bindings. 4. LOCK locks the resource, not the bindings. If the namespace needs to be controlled, then the user should lock the applicable parent collections. 5. MOVE is really REBIND (or BIND followed by DELETE). So the resource in the repository is guaranteed to be the same resource and locks can be retained. 6. There is no MOVE operation that is effectively COPY followed by DELETE or GET/PROPFIND followed by PUT/PROPPATCH and DELETE. If a MOVE operation fails because the binding to the destination cannot be created, then the user is free to do a COPY followed by a DELETE if that meets their needs. Client applications are free to hide these operations inside a move menu item if they desire. "Geoffrey M. Clemm" on 09/24/99 10:58:31 AM To: w3c-dist-auth@w3.org cc: Subject: Re: DELETE Semantics From: jamsden@us.ibm.com I personally believe that the best answer is to fix the LOCK semantics so it *really* is just on the resource (and not on the name). Then things are simpler and consistent, even in the case of multiple URL mappings to a resource. Rather than "protecting" a URL to resource mapping, I'd propose that a locked resource be allowed to MOVE (this is just a change to the state of the parent collection, not to the state of the resource being moved), but that an attempt to access the MOVE'd resource with that lock just returns a 302 indicating where it has MOVE'd to. Note: Amend this to use Edgar's proposal that the pair always access the locked resource. But some moves will result in a change in state of the resource being moved, and this is server dependent. The new parent collection may be in a collection that has different OPTIONS then the old parent, e.g., in a different repository manager. It may also have different live properties. This isn't just a cross-server move issue. A MOVE (as being proposed by the advanced collection protocol) is not allowed to change the state of the resource - it just changes the state of the source and destination collections that contain the resource. If a server cannot implement the MOVE without changing the state of the resource, the MOVE MUST fail, and the client may resort to a COPY/DELETE if it does not need MOVE (i.e. state preserving) semantics. The semantics of MOVE can't be defined as rebind (rename) and copy/delete at the same time. I completely agree. I should be defined as a rebind (rename). I hope we're not bringing back the "logically equivalent to a COPY/fixup/DELETE" dead horse? It has been thoroughly flogged (:-). MOVE can however be implemented that way. Not if it is going to support advanced collections (and not if it is going to support most people's intuition of how a MOVE differs from a COPY). A MOVE produces no new resources, but changes one of the bindings to an existing resource. A COPY/DELETE produces a new resource with just one binding, and leaves an existing resource with one less binding. As a result, one doesn't know if the resource is new or not after a MOVE, and therefore locks can't be guaranteed to be retained. I believe that if we leave the semantics of MOVE as vague as they are in 2518 (i.e. some arbitrary "fixup" step is involved), we will continue to see the confusion about what a MOVE does/should mean that we see today. The proposed semantics are simple: if you can't guarantee that locks are retained, the MOVE MUST fail. If the client wants the locks to be removed, it can (and should) explicitly remove them. A key use case here is with multiple bindings. You issue a LOCK on /x/y.html. It turns out that is bound to the same resource as /a/b.html. Now you move /a/b.html to /a/oldb.html. So you now lose your lock on /x/y.html? I'm not a happy client if that's the case. Therefore, the semantics must pick the conservative case and not move locks. Take for example moves in typical file systems. Sometimes the file actually moves (gets a new INODE in UNIX) and sometimes it doesn't Users don't see this unless they are manipulating INODES directly which is playing with the implementation, not the protocol. As a general comment, there is no reason for us to exactly mimic Unix file behavior (although I agree that there is lots of wisdom embedded in the Unix file system that we should learn from). As a particular comment, as you point out, the INODE is part of the file system implementation that is rarely exposed/used by a client. The fact that the inode changes is largely not a visible state change from a clients perspective, and that is the perspective that matters. Moving locks has lots of other problems too as there is a possible conflict with the potentially inherited lock from the new destination parent collection. This is not a problem (although I am against inherited locks for other reasons). If there is a conflict, the server simply MUST fail the operation that would cause the conflict. Better that than removing locks as a side-effect of the MOVE operation. Lock tokens are server dependent, and may be repository dependent too. Seems like loosing the lock is the lesser of the evils. What evil are we avoiding? If the MOVE fails (because of inability to keep the lock on the resource), the client is notified, and is then free to explicitly removes the locks and then requests the MOVE again. So there are really multiple threads here: - Should locking be on a resource or also/instead on a URL-to-resource mapping? (we know what it is now, but what *should* it be) * I vote "on a resource". I agree. The resource is the thing being manipulated, not the URL. The URL is only a way to get to the resource. There may be other ways, and no way. Whew ... at least we agree on that! (:-). - Does a DELETE delete all bindings to a resource, or just the one specified in the request-URL. * I vote "just the one named by the request-URL". I have to disagree with this one as it is not consistent with LOCK. I disagree (see below). But even if this were true, I'd suggest that we fix the LOCK semantics rather than making DELETE unusable against versioning servers. If LOCK, GET, PUT, etc. apply to the resource, then so should DELETE. Why exactly? I believe that what matters is getting the semantics right so that clients and servers can interoperate. I believe it is important to have a definition of DELETE that works in the presence of versioning, and the "delete-all-bindings" semantics does not. If bindings are created with a BIND method, then they should be removed with an UNBIND method. Otherwise, URL to resource mappings (i.e., bindings) must be exposed as separate resources (direct and redirect referencs) so they can be managed discretely. DELETE should stick to manipulating resources as defined in HTTP/1.1. Then a versioning server will have to refuse every DELETE operation issued by a non-versioning aware server. Roy Fielding has verified that the single binding definition of DELETE matches his intentions when the HTTP-1.1 spec was defined. So what is the benefit we are reaping that matches the cost of non-interoperability between versioning servers and non-versioning aware clients? - Should a DELETE delete a LOCK? * I vote, "no". A DELETE modifies the state of the collection containing the binding, not that of the resource. In particular, all other mappings to that resource will continue to exist and display the LOCK'ed semantics. If you want to prevent a DELETE, you put the LOCK on the collection whose state is being modified. I wish I could agree with this one, but I can't. DELETE deletes a resource and as a side effect it modifies the state of its parent collection(s). It is unfortunate that PUT and DELETE are resource behaviors instead of having addMember, removeMember be operations on the parent collection. It is hard to recover from the resulting mixed semantics, but WebDAV does a reasonable job already. I think we should leave this alone. This is too broken to leave alone, and too easy to fix to not do so. Define DELETE and MOVE as binding operations, and you get full compatibility with existing HTTP behavior, simple semantics, and interoperability between versioning/binding aware and versioning/binding unaware clients and servers. Cheers, Geoff From w3c-dist-auth-request@w3.org Fri Sep 24 15:11:46 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 PAA11332 for ; Fri, 24 Sep 1999 15:11:45 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id OAA25788; Fri, 24 Sep 1999 14:59:29 -0400 (EDT) Resent-Date: Fri, 24 Sep 1999 14:59:29 -0400 (EDT) Resent-Message-Id: <199909241859.OAA25788@www19.w3.org> Message-ID: <37EBC9E6.1FBA539F@ecal.com> Date: Fri, 24 Sep 1999 14:58:46 -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: <852567F6.00679E57.00@d54mta03.raleigh.ibm.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: DELETE Semantics Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3373 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 jamsden@us.ibm.com wrote: > The problems we're having result from > mixing the semantics of: > 1. a resource and its contents/properties > 2. URLs we use to access a resource. This is probably unavoidable--as far as HTTP is concerned, a resource has no identity apart from its URL. -- /==============================================================\ |John Stracke | http://www.ecal.com |My opinions are my own.| |Chief Scientist |=============================================| |eCal Corp. |Guide us, oh holy Lemming Herder! | |francis@ecal.com| | \==============================================================/ From w3c-dist-auth-request@w3.org Fri Sep 24 15:17: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 PAA11449 for ; Fri, 24 Sep 1999 15:17:38 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id PAA26140; Fri, 24 Sep 1999 15:05:40 -0400 (EDT) Resent-Date: Fri, 24 Sep 1999 15:05:40 -0400 (EDT) Resent-Message-Id: <199909241905.PAA26140@www19.w3.org> Date: Fri, 24 Sep 1999 15:05:31 -0400 From: gclemm@atria.com (Geoffrey M. Clemm) Message-Id: <9909241905.AA08465@tantalum> To: w3c-dist-auth@w3.org X-Sun-Charset: US-ASCII Subject: Re: DELETE Semantics Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3375 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: John Stracke > jamsden@us.ibm.com wrote: > > > The problems we're having result from > > mixing the semantics of: > > 1. a resource and its contents/properties > > 2. URLs we use to access a resource. > > This is probably unavoidable--as far as HTTP is concerned, a resource has no > identity apart from its URL. > Yes, but we are talking about extending HTTP (in a backward compatible way). So just because HTTP-1.1 clients do not have any way of identifying a resource other than its URL, does not imply that the same is true for clients and servers that understand an extension of HTTP-1.1. In particular, the advanced collection protocol proposes a GUID property, as does the versioning protocol. Cheers, Geoff From w3c-dist-auth-request@w3.org Fri Sep 24 15:17:43 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 PAA11460 for ; Fri, 24 Sep 1999 15:17:42 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id PAA26099; Fri, 24 Sep 1999 15:05:27 -0400 (EDT) Resent-Date: Fri, 24 Sep 1999 15:05:27 -0400 (EDT) Resent-Message-Id: <199909241905.PAA26099@www19.w3.org> From: Jim Whitehead To: w3c-dist-auth@w3.org MMDF-Warning: Parse error in original version of preceding line at gremlin-relay.ics.uci.edu Cc: Sally Khudairi Date: Fri, 24 Sep 1999 12:01:30 -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: <078292D50C98D2118D090008C7E9C6A603C965A0@STAY.platinum.corp.microsoft.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Importance: Normal Subject: Creating a WebDAV support organization Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3374 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 One of the items I'd like to discuss is creating a "WebDAV support organization". What do I mean by this? From Yaron's comments... > > 1. Discuss creating a WebDAV support organization ("webdav.org") > > But, it already exists. http://webdav.org ...it's clear the name itself is insufficient to convey what I have in mind. The early life of a standard has two main phases, development and adoption. In the IETF, working groups are where development occurs, and the IETF culture typically results in high-quality standards being produced. However, the IETF is typically not involved in the myriad activities that help a standard become adopted. The IETF doesn't do press releases, talk with analysts, rarely does end-user education, doesn't arrange for demos at trade shows, etc., yet these are all extremely important for the adoption of a standard. In fact, just doing one, without doing the other can cripple a standard. To paraphrase the old philosophical question, what sound does an interoperability standard make if noone is around to hear it? The purpose of the WebDAV support organization is to build on what Greg Stein has already done with the webdav.org site, and in fact my choice for a name for this organization would be "webdav.org". But, while webdav.org is a passive web site, waiting for people to come to it, I envision the webdav.org organization being more active, performing activities such as (and I list them to give you a sense of what I have in mind, not to be particularly normative about what is/isn't involved -- there's lots more that could be done here): - developing a WebDAV brand, with all this entails - developing a logo/icon/badge organizations/products could use - what the brand means, what it projects to people - develop a more constant press presence - quarterly (or more frequent) releases on DAV status - announcements of major specifications being completed - organize appearances at trade shows - end user education - what is WebDAV, how do I use it? - developer education - what is WebDAV, why should I include it in my next product? - what webdav.org does today -- act as a repository for specs., information, projects - develop T-shirts, other giveaways It's important to note that webdav.org would not be a standards development organization -- this is work the IETF does. The support organization would, instead, work to bridge the gap between the working group, and the various developer communities that could use WebDAV and put it in their software, and the broad user community where people have a need for collaborative authoring, but don't know that DAV tools are available to do this. I tihnk creating a WebDAV support organization would be a big plus for the various organizations which have adopted WebDAV so far. By pooling efforts to inform and educate people about WebDAV, they increase the value of their DAV investment, and increase the value of their individual product-specific efforts. Marketing the standard and marketing an individual DAV-supporting product are complementary activities. The way I see it, there is a clear need for a WebDAV support organization. But, it's not clear to me how it will happen, and get funded. Unfortunately, I personally don't have the time to push this forward; I need to focus on my studies and graduate (after 7+ years it's time :-) So, what this effort needs is someone to pick it up as their own, and champion it. So, I'm interested in your thoughts. Do you feel there is a need for a support organization? If there was one, would you support it? Most importantly, is there anyone out there who feels they could help organize such a thing? You wouldn't have to do everything -- the press activities should be performed by a PR firm, and I know of one that is very interested in this activity. But, someone needs to focus the goals, and sell it to companies to get initial funding to support the press and educational activities. All right, enough from me. Your turn. - Jim From w3c-dist-auth-request@w3.org Fri Sep 24 15:31: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 PAA11723 for ; Fri, 24 Sep 1999 15:31:31 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id PAA26642; Fri, 24 Sep 1999 15:19:15 -0400 (EDT) Resent-Date: Fri, 24 Sep 1999 15:19:15 -0400 (EDT) Resent-Message-Id: <199909241919.PAA26642@www19.w3.org> Message-ID: <078292D50C98D2118D090008C7E9C6A603C9667E@STAY.platinum.corp.microsoft.com> From: "Yaron Goland (Exchange)" To: "'jamsden@us.ibm.com'" , w3c-dist-auth@w3.org Date: Fri, 24 Sep 1999 12:18:38 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Subject: RE: DELETE Semantics Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3376 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list DELETE nukes the resource. If the resource gets nuked so does its bindings since they are associated with the resource. Hence DELETE is DESTROY. BTW, I personally believe that MOVE SHOULD allow the lock to be moved. The reason we didn't do this had to do with supporting the majority of existing systems. I would love to see a WebDAV extension that introduced a header which specified "MOVE the lock or fail." Yaron > -----Original Message----- > From: jamsden@us.ibm.com [mailto:jamsden@us.ibm.com] > Sent: Fri, September 24, 1999 11:50 AM > To: w3c-dist-auth@w3.org > Subject: Re: DELETE Semantics > > > > > I agree with everything Geoff says below. The problems we're > having result from > mixing the semantics of: > 1. a resource and its contents/properties > 2. URLs we use to access a resource. Note that a resource > may have some > server-dependent objectId that distinguishes it from all > other resources managed > by that server, but this is not a URL and is not exposed to > HTTP clients. This > is the ID the server maps URL bindings to. > 3. membership in a collection > > Here's a summary of what I think we agreed to: > > 1. all URL references to a resource are bindings, including > the PUT or MKCOL > used to create the resource in the first place. > > 2. DELETE is effectively an UNBIND. A server is free to > garbage collect and > actually destroy the resource if there are no remaining > bindings, but this is > not defined by the protocol. > > 3. There is no DESTROY method that deletes the resource and > all its bindings. > > 4. LOCK locks the resource, not the bindings. If the > namespace needs to be > controlled, then the user should lock the applicable parent > collections. > > 5. MOVE is really REBIND (or BIND followed by DELETE). So the > resource in the > repository is guaranteed to be the same resource and locks > can be retained. > > 6. There is no MOVE operation that is effectively COPY > followed by DELETE or > GET/PROPFIND followed by PUT/PROPPATCH and DELETE. If a MOVE > operation fails > because the binding to the destination cannot be created, > then the user is free > to do a COPY followed by a DELETE if that meets their needs. > Client applications > are free to hide these operations inside a move menu item if > they desire. > > > > > > > "Geoffrey M. Clemm" on 09/24/99 > 10:58:31 AM > > To: w3c-dist-auth@w3.org > cc: > > Subject: Re: DELETE Semantics > > > > From: jamsden@us.ibm.com > > > I personally believe that the best answer is to fix the LOCK > semantics so it *really* is just on the resource (and not on the > name). Then things are simpler and consistent, even in the case of > multiple URL mappings to a resource. Rather than > "protecting" a URL > to resource mapping, I'd propose that a locked resource be > allowed to > MOVE (this is just a change to the state of the parent > collection, not > to the state of the resource being moved), but that an attempt to > access the MOVE'd resource with that lock just returns a > 302 indicating > where it has MOVE'd to. > Note: Amend this to use Edgar's proposal that the > > pair always access the locked resource. > > > But some moves will result in a change in state of the > resource being > moved, and this is server dependent. The new parent > collection may be > in a collection that has different OPTIONS then the old > parent, e.g., > in a different repository manager. It may also have different live > properties. This isn't just a cross-server move issue. > > A MOVE (as being proposed by the advanced collection protocol) > is not allowed to change the state of the resource - it just changes > the state of the source and destination collections that contain the > resource. If a server cannot implement the MOVE without changing the > state of the resource, the MOVE MUST fail, and the client may resort > to a COPY/DELETE if it does not need MOVE (i.e. state preserving) > semantics. > > The semantics of MOVE can't be defined as rebind (rename) > and copy/delete at the same time. > > I completely agree. I should be defined as a rebind (rename). > I hope we're not bringing back the "logically equivalent to a > COPY/fixup/DELETE" dead horse? It has been thoroughly flogged (:-). > > MOVE can however be implemented that way. > > Not if it is going to support advanced collections (and not if > it is going to support most people's intuition of how a MOVE differs > from a COPY). A MOVE produces no new resources, but changes one of > the bindings to an existing resource. A COPY/DELETE produces a new > resource with just one binding, and leaves an existing resource with > one less binding. > > As a result, one doesn't know if the resource is new or not after > a MOVE, and therefore locks can't be guaranteed to be retained. > > I believe that if we leave the semantics of MOVE as vague > as they are in 2518 (i.e. some arbitrary "fixup" step is involved), > we will continue to see the confusion about what a MOVE does/should > mean that we see today. The proposed semantics are simple: > if you can't guarantee that locks are retained, the MOVE MUST fail. > If the client wants the locks to be removed, it can (and should) > explicitly remove them. > > A key use case here is with multiple bindings. You issue a > LOCK on /x/y.html. It turns out that is bound to the same resource > as /a/b.html. Now you move /a/b.html to /a/oldb.html. So you now > lose your lock on /x/y.html? I'm not a happy client if > that's the case. > > Therefore, the semantics must pick the conservative case > and not move > locks. Take for example moves in typical file systems. > Sometimes the > file actually moves (gets a new INODE in UNIX) and > sometimes it doesn't > Users don't see this unless they are manipulating INODES > directly which > is playing with the implementation, not the protocol. > > As a general comment, there is no reason for us to exactly > mimic Unix file behavior (although I agree that there is lots of > wisdom embedded in the Unix file system that we should learn from). > As a particular comment, as you point out, the INODE is part of the > file system implementation that is rarely exposed/used by a client. > The fact that the inode changes is largely not a visible state change > from a clients perspective, and that is the perspective that matters. > > Moving locks has lots of other problems too as there is a > possible conflict > with the potentially inherited lock from the new destination parent > collection. > > This is not a problem (although I am against inherited locks > for other reasons). If there is a conflict, the server simply MUST > fail the operation that would cause the conflict. Better that than > removing locks as a side-effect of the MOVE operation. > > Lock tokens are server dependent, and may be repository > dependent too. > Seems like loosing the lock is the lesser of the evils. > > > What evil are we avoiding? If the MOVE fails (because of > inability to keep the lock on the resource), the client is notified, > and is then free to explicitly removes the locks and then requests the > MOVE again. > > So there are really multiple threads here: > - Should locking be on a resource or also/instead on a > URL-to-resource > mapping? (we know what it is now, but what *should* it be) > * I vote "on a resource". > > > I agree. The resource is the thing being manipulated, not > the URL. The > URL is only a way to get to the resource. There may be > other ways, and > no way. > > > Whew ... at least we agree on that! (:-). > > > - Does a DELETE delete all bindings to a resource, or just the one > specified in the request-URL. > * I vote "just the one named by the request-URL". > > > I have to disagree with this one as it is not consistent with LOCK. > > I disagree (see below). But even if this were true, I'd > suggest that we fix the LOCK semantics rather than making DELETE > unusable against versioning servers. > > If LOCK, GET, PUT, etc. apply to the resource, then so > should DELETE. > > Why exactly? I believe that what matters is getting the > semantics right so that clients and servers can interoperate. I > believe it is important to have a definition of DELETE that works in > the presence of versioning, and the "delete-all-bindings" semantics > does not. > > If bindings are created with a BIND method, then they > should be removed with > an UNBIND method. Otherwise, URL to resource mappings > (i.e., bindings) > must be exposed as separate resources (direct and redirect > referencs) > so they can be managed discretely. DELETE should stick to > manipulating > resources as defined in HTTP/1.1. > > > Then a versioning server will have to refuse every DELETE operation > issued by a non-versioning aware server. Roy Fielding has verified > that the single binding definition of DELETE matches his intentions > when the HTTP-1.1 spec was defined. So what is the benefit we are > reaping that matches the cost of non-interoperability between > versioning > servers and non-versioning aware clients? > > - Should a DELETE delete a LOCK? > * I vote, "no". A DELETE modifies the state of the > collection containing > the binding, not that of the resource. In particular, all other > mappings to that resource will continue to exist and display the > LOCK'ed semantics. If you want to prevent a DELETE, you put the > LOCK on the collection whose state is being modified. > > I wish I could agree with this one, but I can't. DELETE > deletes a resource > and as a side effect it modifies the state of its parent > collection(s). > It is unfortunate that PUT and DELETE are resource > behaviors instead > of having addMember, removeMember be operations on the > parent collection. > It is hard to recover from the resulting mixed semantics, > but WebDAV does > a reasonable job already. I think we should leave this alone. > > > This is too broken to leave alone, and too easy to fix > to not do so. > Define DELETE and MOVE as binding operations, and you get > full compatibility > with existing HTTP behavior, simple semantics, and > interoperability between > versioning/binding aware and versioning/binding unaware > clients and servers. > > Cheers, > Geoff > > > > > > > > From w3c-dist-auth-request@w3.org Fri Sep 24 15:32:09 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 PAA11758 for ; Fri, 24 Sep 1999 15:32:08 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id PAA26672; Fri, 24 Sep 1999 15:20:02 -0400 (EDT) Resent-Date: Fri, 24 Sep 1999 15:20:02 -0400 (EDT) Resent-Message-Id: <199909241920.PAA26672@www19.w3.org> From: Jim Whitehead To: WebDAV WG Date: Fri, 24 Sep 1999 12:15: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: Interoperability event? Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3377 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 So, in response to the call for a meeting, Yaron wrote, on the topic of whether to have an in-person interoperability event: > > 3. Organizing an interoperability event > > Why? I know bake offs are popular but WebDAV seems to have been having a > continual back off for months now just by having folks put their > implementations on the net. Unless I have seriously missed something it > seems to work damn well. While it's true there have been lots of good experiences testing clients and servers over the net, with each server having a test location at a known address, these tests have been limited in some ways. Existing clients don't test the full range of capabilities of WebDAV -- none use PROPPATCH, and Depth locking is not used either. So, one purpose of such an event would be to do more thorough compiance testing, as well as just interoperability. But, still, this could potentially be done remotely. In my view, the big benefit from holding it face to face comes from getting a critical mass of WebDAV developers together in the same room, so they could meet each other, exchange tips and ideas, and in general build a stronger community. Side benefits come from being able to quickly iterate through a test-fix-test cycle. If the event is a success, it could be possible to send out a press release, something along the lines of "Successful DAV interoperability demonstrated". But, like the support organization, many of the hurdles to holding such an event are organizational. Since this event needs to be vendor-neutral, it typically should be held somewhere that isn't a company facility. People need to bring themselves, and some machines in. The sponsoring organization needs to arrange for net access, and a network in the room. Security is antoher consideration. Someone needs to coordinate this activity. So, the question is, should we try to hold a face-to-face interoperability event, or should we instead continue with the current online-based testing? What do you think? - Jim From w3c-dist-auth-request@w3.org Fri Sep 24 15:40: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 PAA11872 for ; Fri, 24 Sep 1999 15:40:37 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id PAA26799; Fri, 24 Sep 1999 15:28:41 -0400 (EDT) Resent-Date: Fri, 24 Sep 1999 15:28:41 -0400 (EDT) Resent-Message-Id: <199909241928.PAA26799@www19.w3.org> From: jamsden@us.ibm.com X-Lotus-FromDomain: IBMUS To: w3c-dist-auth@w3.org Message-ID: <852567F6.006AF130.00@d54mta03.raleigh.ibm.com> Date: Fri, 24 Sep 1999 15:27:31 -0400 Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Subject: Re: Creating a WebDAV support organization Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3378 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list Sounds like a great idea. Definitely needed. However, you're talking about a significant cost in resource time and money. This is typically done by a product marketing organization. I suspect the players building significant WebDAV client applications and/or servers will have to step up to this task in order to sell their products. However, this does not foster the WebDAV community as a whole, or create interest in the standard before products are available. Perhaps webdav.org can minimally play this role while products are being introduced and then individual marketing organizations can create the WebDAV drag needed to foster a larger community. This a compromise, but its also relatively easy to achieve. From w3c-dist-auth-request@w3.org Fri Sep 24 15:48: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 PAA11941 for ; Fri, 24 Sep 1999 15:48:55 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id PAA27016; Fri, 24 Sep 1999 15:36:42 -0400 (EDT) Resent-Date: Fri, 24 Sep 1999 15:36:42 -0400 (EDT) Resent-Message-Id: <199909241936.PAA27016@www19.w3.org> From: jamsden@us.ibm.com X-Lotus-FromDomain: IBMUS To: w3c-dist-auth@w3.org Message-ID: <852567F6.006BAEBF.00@d54mta03.raleigh.ibm.com> Date: Fri, 24 Sep 1999 15:32:50 -0400 Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Subject: Re: Interoperability event? Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3379 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 an interoperability test suite would be more useful over a longer period of time, and would accomplish a lot of the same goals. If we had a client/server test framework, it would be possible for companies to submit tests to the suite. Then other interested parties could run the tests against their products. In addition, a test suite is the best way of determining if the protocol is complete, consistent, implementable, and in some sense, useful. IBM is thinking about creating the basis of such a suite, and would like to make it open-source so others could contribute. Again, webdav.org would be the logical place to host and deploy it. From w3c-dist-auth-request@w3.org Fri Sep 24 15:51: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 PAA11995 for ; Fri, 24 Sep 1999 15:51:47 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id PAA27097; Fri, 24 Sep 1999 15:39:42 -0400 (EDT) Resent-Date: Fri, 24 Sep 1999 15:39:42 -0400 (EDT) Resent-Message-Id: <199909241939.PAA27097@www19.w3.org> Date: Fri, 24 Sep 1999 15:39:34 -0400 From: gclemm@atria.com (Geoffrey M. Clemm) Message-Id: <9909241939.AA08497@tantalum> To: w3c-dist-auth@w3.org X-Sun-Charset: US-ASCII Subject: Re: DELETE Semantics Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3380 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list Very nice summary Jim. I agree with each point. Just one comment on point #1: The mapping from "/" to a resource is not a binding, because there is no collection in which the binding can live. So the mapping from "/" to a collection is done through some other (server defined) means. We could define some way of re-mapping "/" to some other currently namable resource, but in general (and certainly to get started) you need some server defined way of mapping "/" to a resource, so I don't think it would be worth special casing the re-mapping of "/" to some current descendent of "/". Also of course, this only applies to resources that support the WebDAV protocol. Cheers, Geoff > From: jamsden@us.ibm.com > > 1. all URL references to a resource are bindings, including the PUT or MKCOL > used to create the resource in the first place. > 2. DELETE is effectively an UNBIND. A server is free to garbage collect and > actually destroy the resource if there are no remaining bindings, but this is > not defined by the protocol. > > 3. There is no DESTROY method that deletes the resource and all its bindings. > > 4. LOCK locks the resource, not the bindings. If the namespace needs to be > controlled, then the user should lock the applicable parent collections. > > 5. MOVE is really REBIND (or BIND followed by DELETE). So the resource in the > repository is guaranteed to be the same resource and locks can be retained. > > 6. There is no MOVE operation that is effectively COPY followed by DELETE or > GET/PROPFIND followed by PUT/PROPPATCH and DELETE. If a MOVE operation fails > because the binding to the destination cannot be created, then the user is free > to do a COPY followed by a DELETE if that meets their needs. Client applications > are free to hide these operations inside a move menu item if they desire. From w3c-dist-auth-request@w3.org Fri Sep 24 15:54:00 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 PAA12043 for ; Fri, 24 Sep 1999 15:53:59 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id PAA27224; Fri, 24 Sep 1999 15:41:19 -0400 (EDT) Resent-Date: Fri, 24 Sep 1999 15:41:19 -0400 (EDT) Resent-Message-Id: <199909241941.PAA27224@www19.w3.org> Message-ID: <078292D50C98D2118D090008C7E9C6A603C96681@STAY.platinum.corp.microsoft.com> From: "Yaron Goland (Exchange)" To: "'Geoffrey M. Clemm'" , w3c-dist-auth@w3.org Date: Fri, 24 Sep 1999 12:41:08 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Subject: RE: DELETE leaving a lock-null resource; was LOCK Scenarios Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3381 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list Sigh... I have had to delete a lot of WebDAV mail recently unread. WebDAV is no longer the focus of my existence and my other duties are pressing so it is difficult for me to properly contribute to these conversations. I will throw in a few points of general experience that I hope will help: 1) I guarantee that if you change the way LOCK works you will end up with a protocol that will be unimplementable on the majority of existing systems. The namespace is locked by a LOCK request for a damn good reason, if you change it, most of us implementers will probably just be forced to ignore you so we can properly support our users. 2) A link to the history resource should never appear to a down level client, they should only see a URL to a tip version. If this is not the case with the version design then the version design is broken. 3) MOVE doesn't move locks due to interoperability issues. If you want a protocol no one but a couple of super high end providers can ship then go right ahead, make the change. The problem here is that the people really working hard on this protocol, folks like Geoffrey and JimA, are basically super high end people. They are not used to having to live in the crappy, confined, miserable, limited hell known as consumer software. Therefore they make proposals which are 100% consistent, elegant and imminently reasonable, if you are shipping a super high end system. I don't see any voices actively participating in the mailing list who speak for the dirty masses yearning to be free. I also see absolutely no voices speaking for people who actually write clients for a living. Asad and I used to represent the dirty masses and I did a good pitch at representing clients (having worked on IE for all those years) but no one seems to have taken our place. The discussions here are very far removed from the reality of consumer software. You are creating a standard that will only be implementable on brand new, high end systems. Existing users will simply be screwed. WebDAV's current success has been that 2518 is easy to implement. The stuff you guys are creating and the changes you are proposing to 2518 to allow you to implement your super high end features will kill the lower end market. As a last note, SHOW SOME ORIGINALITY! I mean, come on! You guys are so.... wooden. "Gee I got a DELETE on the history which doesn't have the magic 'foobar' header. I guess I better just delete the link." Come on! Protocols are fun. Stop being so limited in your thinking. "Must change whole protocol to fix down level problem." Like hell. We put in versioning and ignore rules for a bloody reason! Come on folks, a little out of the box thinking, please. Either way, you better find someone who works on clients and consumer software who actually has time to devote to WebDAV and fast or you will fail to produce a protocol that will be widely implementable. I assure you, you are already far along the path of unimplementability as it is. Yaron > -----Original Message----- > From: Geoffrey M. Clemm [mailto:gclemm@tantalum.atria.com] > Sent: Fri, September 24, 1999 2:48 AM > To: w3c-dist-auth@w3.org > Subject: Re: DELETE leaving a lock-null resource; was LOCK Scenarios > > > > From: "Yaron Goland (Exchange)" > > The suggestion has been made that we introduce > transactioning. I > hope you will not think me cheeky if I summarily reject > the suggestion > of using transactioning. ... > > I agree with Yaron that we do not want to bite off general > transactioning support as part of WebDAV. > > BTW, in so far as what happens when you DELETE a > locked resource I > completely oppose the suggestion that DELETING a resource > results in a > lock-null resource. That is absolutely contrary to the > definition of DELETE. > DELETE deletes the resource not the name. Since the lock > is associated with > the resources deleting a locked resource deletes both the > resource and the > lock. > > If lock were *really* just associated with the > resource, I'd be a > happy camper. For one thing, it would mean that when multiple URL's > are mapped to a single resource, you could issue the LOCK against any > of those URL's and the result would be identical. Similarly, > you could > later on issue on UNLOCK against any of those URL's and > again, the result > would be identical. > > But I have seen various arguments in the past that a > LOCK should > also protect the URL to resource mapping. If "protect" just means > "keep from being deleted", then your conclusion still holds, i.e. > it makes no sense to LOCK a deleted resource. But if protect also > means "reserves the right to change the URL to resource mapping", > then it is perfectly sensible to keep a LOCK after the resource is > deleted (that is pretty much what a lock-null resource is anyway). > > I personally believe that the best answer is to fix the LOCK > semantics so it *really* is just on the resource (and not on the > name). Then things are simpler and consistent, even in the case of > multiple URL mappings to a resource. Rather than "protecting" a URL > to resource mapping, I'd propose that a locked resource be allowed to > MOVE (this is just a change to the state of the parent collection, not > to the state of the resource being moved), but that an attempt to > access the MOVE'd resource with that lock just returns a 302 > indicating > where it has MOVE'd to. > > And as for the question of whether DELETE deletes all bindings > to a resource or whether it just DELETE's the binding named in the > DELETE request-URL, I am an adamant supporter of the current advanced > collection protocol specification which states that it *only* > deletes the binding named in the DELETE request-URL. This behavior > is *essential* in order to allow versioning-unaware clients to > be able to issue a DELETE without destroying the history of a > resource. > > So there are really multiple threads here: > - Should locking be on a resource or also/instead on a URL-to-resource > mapping? (we know what it is now, but what *should* it be) > * I vote "on a resource". > - Does a DELETE delete all bindings to a resource, or just the one > specified in the request-URL. > * I vote "just the one named by the request-URL". > - Should a DELETE delete a LOCK? > * I vote, "no". A DELETE modifies the state of the > collection containing > the binding, not that of the resource. In particular, all other > mappings to that resource will continue to exist and display the > LOCK'ed semantics. If you want to prevent a DELETE, you put the > LOCK on the collection whose state is being modified. > > I realize that this requires changes to 2518, and I would not > make such a suggestion lightly. The problem is that 2518 was > specified > without the use cases of multiple bindings and versioning in mind, > and needs to be revisited now that those use cases have been > elaborated. > > Cheers, > Geoff > From w3c-dist-auth-request@w3.org Fri Sep 24 15:58: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 PAA12098 for ; Fri, 24 Sep 1999 15:58:49 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id PAA27506; Fri, 24 Sep 1999 15:46:39 -0400 (EDT) Resent-Date: Fri, 24 Sep 1999 15:46:39 -0400 (EDT) Resent-Message-Id: <199909241946.PAA27506@www19.w3.org> Date: Fri, 24 Sep 1999 12:40:34 -0700 Message-ID: <4295-Fri24Sep1999124034-0700-bill@carpenter.ORG> X-Mailer: 20.4 "Emerald" XEmacs Lucid (via feedmail 9-beta-8 I); 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: References: Subject: RE: Interoperability event? Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3384 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 >> > 3. Organizing an interoperability event >> >> Why? I know bake offs are popular but WebDAV seems to have been >> having a continual back off for months now just by having folks put >> their implementations on the net. Unless I have seriously missed >> something it seems to work damn well. jw> While it's true there have been lots of good experiences testing jw> clients and servers over the net, with each server having a test jw> location at a known address, these tests have been limited in some jw> ways. Existing clients don't test the full range of capabilities jw> of WebDAV -- none use PROPPATCH, and Depth locking is not used jw> either. So, one purpose of such an event would be to do more jw> thorough compiance testing, as well as just interoperability. jw> But, still, this could potentially be done remotely. Another important purpose of a bake-off, whether held in a single location or done over a wide area, is to get demonstrable buy-in from the purveyors of clients and servers. In the context of a mailing list, it's just too easy for someone to Keep-Their-Mouth-Shut when problems with a particular implementation are mentioned. If that happens in the context of a bake-off, the silence or non-participation can in and of itself be interpreted as a statement of intent. It's both a cultural and a process difference. This is not a hypothetical problem for WebDAV. -- 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 Fri Sep 24 15:59: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 PAA12113 for ; Fri, 24 Sep 1999 15:59:05 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id PAA27325; Fri, 24 Sep 1999 15:44:16 -0400 (EDT) Resent-Date: Fri, 24 Sep 1999 15:44:16 -0400 (EDT) Resent-Message-Id: <199909241944.PAA27325@www19.w3.org> Message-ID: <8EAE75D3D142D211A45200A0C99B60238A36E2@ZEUS> From: David Pool To: "'jamsden@us.ibm.com'" , w3c-dist-auth@w3.org Date: Fri, 24 Sep 1999 12:36:00 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="windows-1252" Subject: RE: Creating a WebDAV support organization Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3382 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list Having tried this with XML, it is not easy. We did end up with XML.org so it was worth the effort. I would suggest high level conversation with SoftBank or the guys at Internet world as a start. I will take Microsoft/Sun/IBM to step up and commit resources and people. I would be glad to facilitate and help out. I also believe we need to push WebDAV into HTTP-NG and get broader support at the distributed computing level from the W3C. My one bit! Pool -----Original Message----- From: jamsden@us.ibm.com [mailto:jamsden@us.ibm.com] Sent: Friday, September 24, 1999 12:28 PM To: w3c-dist-auth@w3.org Subject: Re: Creating a WebDAV support organization Sounds like a great idea. Definitely needed. However, you're talking about a significant cost in resource time and money. This is typically done by a product marketing organization. I suspect the players building significant WebDAV client applications and/or servers will have to step up to this task in order to sell their products. However, this does not foster the WebDAV community as a whole, or create interest in the standard before products are available. Perhaps webdav.org can minimally play this role while products are being introduced and then individual marketing organizations can create the WebDAV drag needed to foster a larger community. This a compromise, but its also relatively easy to achieve. From w3c-dist-auth-request@w3.org Fri Sep 24 15:59: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 PAA12124 for ; Fri, 24 Sep 1999 15:59:17 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id PAA27458; Fri, 24 Sep 1999 15:45:39 -0400 (EDT) Resent-Date: Fri, 24 Sep 1999 15:45:39 -0400 (EDT) Resent-Message-Id: <199909241945.PAA27458@www19.w3.org> From: jamsden@us.ibm.com X-Lotus-FromDomain: IBMUS To: w3c-dist-auth@w3.org Message-ID: <852567F6.006C8360.00@d54mta03.raleigh.ibm.com> Date: Fri, 24 Sep 1999 15:40:37 -0400 Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Subject: RE: DELETE Semantics Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3383 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list DELETE nukes the resource. If the resource gets nuked so does its bindings since they are associated with the resource. Hence DELETE is DESTROY. This could be interpreted as the HTTP/1.1 definition, but it is not useful in situations where multiple bindings and versions are available. We would like DELETE to mean subsequent requests on that URL return 404 Not Found. UNBIND has these semantics and supports multiple bindings and multiple versions. Geoff says that this definition is not inconsistent with the intent of HTTP/1.1 according to Roy Fielding. From w3c-dist-auth-request@w3.org Fri Sep 24 16:02: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 QAA12222 for ; Fri, 24 Sep 1999 16:02:25 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id PAA27669; Fri, 24 Sep 1999 15:49:49 -0400 (EDT) Resent-Date: Fri, 24 Sep 1999 15:49:49 -0400 (EDT) Resent-Message-Id: <199909241949.PAA27669@www19.w3.org> From: jamsden@us.ibm.com X-Lotus-FromDomain: IBMUS To: w3c-dist-auth@w3.org Message-ID: <852567F6.006CE41C.00@d54mta03.raleigh.ibm.com> Date: Fri, 24 Sep 1999 15:47:59 -0400 Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Subject: Re: DELETE Semantics Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3385 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list Agreed. gclemm@atria.com (Geoffrey M. Clemm) on 09/24/99 03:39:34 PM To: w3c-dist-auth@w3.org cc: Subject: Re: DELETE Semantics Very nice summary Jim. I agree with each point. Just one comment on point #1: The mapping from "/" to a resource is not a binding, because there is no collection in which the binding can live. So the mapping from "/" to a collection is done through some other (server defined) means. We could define some way of re-mapping "/" to some other currently namable resource, but in general (and certainly to get started) you need some server defined way of mapping "/" to a resource, so I don't think it would be worth special casing the re-mapping of "/" to some current descendent of "/". Also of course, this only applies to resources that support the WebDAV protocol. Cheers, Geoff > From: jamsden@us.ibm.com > > 1. all URL references to a resource are bindings, including the PUT or MKCOL > used to create the resource in the first place. > 2. DELETE is effectively an UNBIND. A server is free to garbage collect and > actually destroy the resource if there are no remaining bindings, but this is > not defined by the protocol. > > 3. There is no DESTROY method that deletes the resource and all its bindings. > > 4. LOCK locks the resource, not the bindings. If the namespace needs to be > controlled, then the user should lock the applicable parent collections. > > 5. MOVE is really REBIND (or BIND followed by DELETE). So the resource in the > repository is guaranteed to be the same resource and locks can be retained. > > 6. There is no MOVE operation that is effectively COPY followed by DELETE or > GET/PROPFIND followed by PUT/PROPPATCH and DELETE. If a MOVE operation fails > because the binding to the destination cannot be created, then the user is free > to do a COPY followed by a DELETE if that meets their needs. Client applications > are free to hide these operations inside a move menu item if they desire. From w3c-dist-auth-request@w3.org Fri Sep 24 16:03: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 QAA12238 for ; Fri, 24 Sep 1999 16:03:15 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id PAA27756; Fri, 24 Sep 1999 15:51:08 -0400 (EDT) Resent-Date: Fri, 24 Sep 1999 15:51:08 -0400 (EDT) Resent-Message-Id: <199909241951.PAA27756@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: <852567F6.006CFF4A.00@D51MTA03.pok.ibm.com> Date: Fri, 24 Sep 1999 15:56:44 -0400 Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Subject: Re: DELETE Semantics Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3386 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. all URL references to a resource are bindings, including the PUT or MKCOL used to create the resource in the first place. Just to clarify. I think you're suggesting that PUT and MKCOL are operations on bindings. I agree... they create new bindings, if there isn't a resource there already. But in the case of PUT, if there's a (non-collection) resource already there, then it's an action on the resource... not the binding. 4. LOCK locks the resource, not the bindings. If the namespace needs to be controlled, then the user should lock the applicable parent collections. I agree that that's what seems to be suggested. I just want to add, "ouch! That's a painful way to protect a URI.". From w3c-dist-auth-request@w3.org Fri Sep 24 16:09: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 QAA12327 for ; Fri, 24 Sep 1999 16:09:11 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id PAA28025; Fri, 24 Sep 1999 15:56:54 -0400 (EDT) Resent-Date: Fri, 24 Sep 1999 15:56:54 -0400 (EDT) Resent-Message-Id: <199909241956.PAA28025@www19.w3.org> Message-ID: <37EBD764.619D38DA@ecal.com> Date: Fri, 24 Sep 1999 15:56:21 -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: <852567F6.006BAEBF.00@d54mta03.raleigh.ibm.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: Interoperability event? Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3387 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 jamsden@us.ibm.com wrote: > IBM is thinking > about creating the basis of such a suite, and would like to make it open-source > so others could contribute. I would hope so--otherwise nobody can tell for certain whether a bug is in their code or in the test suite, so they'll just blame the suite. :-) -- /==============================================================\ |John Stracke | http://www.ecal.com |My opinions are my own.| |Chief Scientist |=============================================| |eCal Corp. |Stock up and save! Limit one. | |francis@ecal.com| | \==============================================================/ From w3c-dist-auth-request@w3.org Fri Sep 24 16:20: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 QAA12428 for ; Fri, 24 Sep 1999 16:20:55 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id QAA28788; Fri, 24 Sep 1999 16:08:22 -0400 (EDT) Resent-Date: Fri, 24 Sep 1999 16:08:22 -0400 (EDT) Resent-Message-Id: <199909242008.QAA28788@www19.w3.org> From: jamsden@us.ibm.com X-Lotus-FromDomain: IBMUS To: w3c-dist-auth@w3.org Message-ID: <852567F6.006E5D29.00@d54mta03.raleigh.ibm.com> Date: Fri, 24 Sep 1999 16:04:06 -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/3388 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list Sigh... I have had to delete a lot of WebDAV mail recently unread. WebDAV is no longer the focus of my existence and my other duties are pressing so it is difficult for me to properly contribute to these conversations. I will throw in a few points of general experience that I hope will help: Too bad, your participation will be missed. 1) I guarantee that if you change the way LOCK works you will end up with a protocol that will be unimplementable on the majority of existing systems. The namespace is locked by a LOCK request for a damn good reason, if you change it, most of us implementers will probably just be forced to ignore you so we can properly support our users. The issue of namespace control and resource contents control are separate. Namespaces are the domain of collections. If a user wants to control a namespace, then the collection managing or defining that namespace can be (shallow) locked. Multiple bindings and versions introduce new locking problems which we have to address. Some of these issues may require us to go back and rethink existing semantics. 2) A link to the history resource should never appear to a down level client, they should only see a URL to a tip version. If this is not the case with the version design then the version design is broken. non-versioning aware clients will see revisions selected by the default workspace. Tip revisions alone would not provide any way for a site administrator to provide a consistent set of revisions to these clients. non-versioning aware clients can access all unversioned resources, including the history resource and interpret the contents any way they want. It might not be useful, but there's really no need to prevent it. 3) MOVE doesn't move locks due to interoperability issues. If you want a protocol no one but a couple of super high end providers can ship then go right ahead, make the change. The problem here is that the people really working hard on this protocol, folks like Geoffrey and JimA, are basically super high end people. They are not used to having to live in the crappy, confined, miserable, limited hell known as consumer software. Therefore they make proposals which are 100% consistent, elegant and imminently reasonable, if you are shipping a super high end system. I have to strongly differ Yaron. Geoff and I have both consistently pushed for simplicity and elimination of design by special case. Elegant, simple, useable, and implementable go together. The process of getting there is MUCH harder. Asad and I used to represent the dirty masses and I did a good pitch at representing clients (having worked on IE for all those years) but no one seems to have taken our place. The discussions here are very far removed from the reality of consumer software. You are creating a standard that will only be implementable on brand new, high end systems. Existing users will simply be screwed. WebDAV's current success has been that 2518 is easy to implement. The stuff you guys are creating and the changes you are proposing to 2518 to allow you to implement your super high end features will kill the lower end market. WebDAV will continue to be a layered protocol with lots of options. Server implementors will have lots of freedom to provide simple support, or extended functions for users that need them. Adding bindings and versioning does not require all server vendors to implement them. B.T.W., there's lots of client activity going on based on the versioning extensions, and these extensions are based on many existing client applications and use cases. So I don't agree that we are so far off the mark. From w3c-dist-auth-request@w3.org Fri Sep 24 16:23: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 QAA12450 for ; Fri, 24 Sep 1999 16:23:01 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id QAA28925; Fri, 24 Sep 1999 16:11:06 -0400 (EDT) Resent-Date: Fri, 24 Sep 1999 16:11:06 -0400 (EDT) Resent-Message-Id: <199909242011.QAA28925@www19.w3.org> From: jamsden@us.ibm.com X-Lotus-FromDomain: IBMUS To: w3c-dist-auth@w3.org Message-ID: <852567F6.006EBB34.00@d54mta03.raleigh.ibm.com> Date: Fri, 24 Sep 1999 16:05:53 -0400 Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Subject: Re: DELETE Semantics Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3389 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 09/24/99 03:56 PM To: jamsden@us.ibm.com cc: w3c-dist-auth@w3.org Subject: Re: DELETE Semantics (Document link: Jim Amsden) 1. all URL references to a resource are bindings, including the PUT or MKCOL used to create the resource in the first place. Just to clarify. I think you're suggesting that PUT and MKCOL are operations on bindings. I agree... they create new bindings, if there isn't a resource there already. But in the case of PUT, if there's a (non-collection) resource already there, then it's an action on the resource... not the binding. Yes 4. LOCK locks the resource, not the bindings. If the namespace needs to be controlled, then the user should lock the applicable parent collections. I agree that that's what seems to be suggested. I just want to add, "ouch! That's a painful way to protect a URI.". Then what are collections for if not to manage and control the namespace? What else could locking a collection mean? Note that it does not have to be a deep lock. From w3c-dist-auth-request@w3.org Fri Sep 24 16:35: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 QAA12690 for ; Fri, 24 Sep 1999 16:35:23 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id QAA29402; Fri, 24 Sep 1999 16:23:23 -0400 (EDT) Resent-Date: Fri, 24 Sep 1999 16:23:23 -0400 (EDT) Resent-Message-Id: <199909242023.QAA29402@www19.w3.org> Date: Fri, 24 Sep 1999 16:23:13 -0400 From: gclemm@atria.com (Geoffrey M. Clemm) Message-Id: <9909242023.AA08556@tantalum> To: w3c-dist-auth@w3.org X-Sun-Charset: US-ASCII Subject: RE: DELETE Semantics Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3390 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 nukes the resource. Another point of view is that DELETE on a URL ensures that the next GET on that URL returns the appropriate error status. Furthermore, unless you want downlevel clients to trash the history of a versioned resource, DELETE *must* have UNBIND semantics rather than DESTROY semantics. > If the resource gets nuked so does its bindings > since they are associated with the resource. Hence DELETE is DESTROY. I don't see how this follows. Embedded HREF's in xml documents are also associated with the resource they reference, but they are unaffected by any operation on the resource. > BTW, I personally believe that MOVE SHOULD allow the lock to be moved. The > reason we didn't do this had to do with supporting the majority of existing > systems. In the past, I've only heard this said for Windows95. I have not been able to find anything in Windows95 resembling WebDAV locking behavior. Is this some internal implementation thing not exposed to end users? Or is this a reference to how it was implemented in Office-2000? In either case, although it should influence locking semantics, I don't think we should let it determine locking semantics, if it results in a complex or confusing protocol. For example, with multiple bindings to a resource (say /a/x.html and /b/y.html), if you issue a LOCK on /a/x.html, can you move /b/y.html? Cheers, Geoff From w3c-dist-auth-request@w3.org Fri Sep 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 QAA12848 for ; Fri, 24 Sep 1999 16:49:43 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id QAA29847; Fri, 24 Sep 1999 16:32:22 -0400 (EDT) Resent-Date: Fri, 24 Sep 1999 16:32:22 -0400 (EDT) Resent-Message-Id: <199909242032.QAA29847@www19.w3.org> Message-ID: <37EBDFB2.FDB32FDB@ecal.com> Date: Fri, 24 Sep 1999 16:31:46 -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: <9909242023.AA08556@tantalum> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: DELETE Semantics Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3391 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 "Geoffrey M. Clemm" wrote: > > From: "Yaron Goland (Exchange)" > > > > DELETE nukes the resource. > > Another point of view is that DELETE > on a URL ensures that the next GET on that URL returns the appropriate > error status. Furthermore, unless you want downlevel clients to trash > the history of a versioned resource, DELETE *must* have UNBIND semantics > rather than DESTROY semantics. You don't even need to appeal to versioning for this one. Suppose I use two DAV clients, an editor with some minimal file-management features and a file manager with full AdvCol support. In the file manager, I do some BINDs to make one of my documents appear in multiple places. Then, while I'm editing, I decide I no longer want it one of those places. I'm in the editor, so I use its DELETE command...and discover I've lost my document, no just the one binding I wanted to remove. -- /==============================================================\ |John Stracke | http://www.ecal.com |My opinions are my own.| |Chief Scientist |=============================================| |eCal Corp. |Due to circumstances beyond your control, you| |francis@ecal.com|are master of your fate, and captain of your | | |soul. | \==============================================================/ From w3c-dist-auth-request@w3.org Fri Sep 24 17:41: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 RAA13323 for ; Fri, 24 Sep 1999 17:41:16 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id RAA01748; Fri, 24 Sep 1999 17:28:09 -0400 (EDT) Resent-Date: Fri, 24 Sep 1999 17:28:09 -0400 (EDT) Resent-Message-Id: <199909242128.RAA01748@www19.w3.org> From: Jim Whitehead To: w3c-dist-auth@w3.org MMDF-Warning: Parse error in original version of preceding line at gremlin-relay.ics.uci.edu Date: Fri, 24 Sep 1999 14:24:09 -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: <9909241259.AA08183@tantalum> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Subject: RE: DELETE leaving a lock-null resource; was LOCK Scenarios Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3392 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 Geoff Clemm and Edgar Schwarz write: > to resource mapping, I'd propose that a locked resource > be allowed to > MOVE (this is just a change to the state of the parent collection, not > to the state of the resource being moved), but that an attempt to > access the MOVE'd resource with that lock just returns a 302 indicating > where it has MOVE'd to. > > This would give me what I wanted. I even could imagine that it > is enough that only a access with the lock token MUST get the new > location. For all others it's just gone, like other resources which > are moved. So a server could just remember lock tokens together with > old and new URLs and keep this data until it is accessed by the locker > or the lock expires. > > Ah yes, *much* better than the 302's, and provides better > compatibility with clients written against the existing locking > protocol. Great idea, Edgar! I'm not convinced this will work, since it only handles the case where the resource is moved just once. What happens if a resource is locked, then moved, and moved again? How many steps is the server required to remember? > I've been agonizing for months over trying to make the existing > locking protocol work unmodified in the presence of multiple bindings > and versioning. There are massive numbers of edge cases and things > that just plain don't work. If you just say that a lock is on a > resource, and then use Edgar's proposal that a lock token combined > with the original URL guarantee access to that resource, then multiple > bindings and versioning semantics interacts can be combined with > locking in a manageable fashion. > > I'll make a pass through the current version of 2518 to identify the > sections that would need to be modified, and will run this against > Judy's list of use cases for locking in the presence of multiple > bindings, to see how the details play out. I'm looking forward to this. - Jim From w3c-dist-auth-request@w3.org Fri Sep 24 17:49: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 RAA13343 for ; Fri, 24 Sep 1999 17:49:14 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id RAA02057; Fri, 24 Sep 1999 17:37:11 -0400 (EDT) Resent-Date: Fri, 24 Sep 1999 17:37:11 -0400 (EDT) Resent-Message-Id: <199909242137.RAA02057@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: <852567F6.0076B8D4.00@D51MTA03.pok.ibm.com> Date: Fri, 24 Sep 1999 17:42:59 -0400 Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Subject: Re: DELETE Semantics Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3393 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list 4. LOCK locks the resource, not the bindings. If the namespace needs to be controlled, then the user should lock the applicable parent collections. I agree that that's what seems to be suggested. I just want to add, "ouch! That's a painful way to protect a URI.". Then what are collections for if not to manage and control the namespace? What else could locking a collection mean? Note that it does not have to be a deep lock. I agree that collections are to manage and control namespace. My editorial comment was that locking a whole collection to protect a single binding seems like a lot of overkill. And if you want to protect a URI mapping... you'd have to lock the collection chain up to the root. Even more overkill. From w3c-dist-auth-request@w3.org Fri Sep 24 17:57: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 RAA13398 for ; Fri, 24 Sep 1999 17:57:20 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id RAA02290; Fri, 24 Sep 1999 17:44:58 -0400 (EDT) Resent-Date: Fri, 24 Sep 1999 17:44:58 -0400 (EDT) Resent-Message-Id: <199909242144.RAA02290@www19.w3.org> Date: Fri, 24 Sep 1999 17:44:50 -0400 Message-Id: <9909242144.AA08607@tantalum> From: "Geoffrey M. Clemm" To: w3c-dist-auth@w3.org In-Reply-To: <078292D50C98D2118D090008C7E9C6A603C96681@STAY.platinum.corp.microsoft.com> (yarong@Exchange.Microsoft.com) Subject: Re: DELETE leaving a lock-null resource; was LOCK Scenarios Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3394 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)" Sigh... I have had to delete a lot of WebDAV mail recently unread. WebDAV is no longer the focus of my existence and my other duties are pressing so it is difficult for me to properly contribute to these conversations. That is definitely a major loss ... would a write-in campaign to BG get him to lighten your load? (Probably not ... :-). I will throw in a few points of general experience that I hope will help: 1) I guarantee that if you change the way LOCK works you will end up with a protocol that will be unimplementable on the majority of existing systems. The namespace is locked by a LOCK request for a damn good reason, if you change it, most of us implementers will probably just be forced to ignore you so we can properly support our users. The proposed protocol would allow a server to lock the namespace, but would not *require* it to do so. This lets a low-end server just lock the namespace, while letting a high-end server support versioning and multiple bindings while ensuring a low-end (or any) client access to his/her locked resource. A win/win, I believe. 2) A link to the history resource should never appear to a down level client, they should only see a URL to a tip version. If this is not the case with the version design then the version design is broken. It's not the appearance of the history resource that is the issue. It is the DELETE being applied by a down level client to a revision that is supposed to remain part of the history of that resource. The down level client is not aware of versioning ... it just wants that resource to no longer appear at that URL. If a DELETE is a DESTROY, that naive DELETE from a down level client is required to blast that supposedly immutable persistent revision out of existence ... a very bad thing. Think Unix hard links (or for that matter, any implementation of a reference in any programming language you can think of). It's easy to implement a delete of the reference, probably easier (and certainly *safer*) than destroying the object. 3) MOVE doesn't move locks due to interoperability issues. If you want a protocol no one but a couple of super high end providers can ship then go right ahead, make the change. In a file system, if you move a resource, it keeps its permissions. I don't consider a file system something provided by only a super high end provider, but they have no trouble moving permission style information along with a resource (I know permissions are not locks, but analogous implementations can be used). The problem here is that the people really working hard on this protocol, folks like Geoffrey and JimA, are basically super high end people. They are not used to having to live in the crappy, confined, miserable, limited hell known as consumer software. Therefore they make proposals which are 100% consistent, elegant and imminently reasonable, if you are shipping a super high end system. See above. It's true that I want versioning, but I also want things to work smoothly and simply for legacy HTTP-1.x clients, locking clients, and simple versioning clients. Any argument that is based on "cannot easily implement on a low end server or client" is one I care about intensely. I don't see any voices actively participating in the mailing list who speak for the dirty masses yearning to be free. I also see absolutely no voices speaking for people who actually write clients for a living. Asad and I used to represent the dirty masses and I did a good pitch at representing clients (having worked on IE for all those years) but no one seems to have taken our place. The discussions here are very far removed from the reality of consumer software. You are creating a standard that will only be implementable on brand new, high end systems. Existing users will simply be screwed. WebDAV's current success has been that 2518 is easy to implement. The stuff you guys are creating and the changes you are proposing to 2518 to allow you to implement your super high end features will kill the lower end market. I'll need to see something specific in the proposed protocol that has the characteristics that you describe. I know you don't have time personally to bring this up, but I can promise that if anyone does, that I care deeply that the protocol allow a simple implementation, and will take all such issues very seriously. As a last note, SHOW SOME ORIGINALITY! I mean, come on! You guys are so.... wooden. "Gee I got a DELETE on the history which doesn't have the magic 'foobar' header. I guess I better just delete the link." Come on! Protocols are fun. Stop being so limited in your thinking. "Must change whole protocol to fix down level problem." Like hell. We put in versioning and ignore rules for a bloody reason! Come on folks, a little out of the box thinking, please. Well, that's what I believe all of us have been trying to do for the last few months (I *know* that I have), and the current proposal is intended to be exactly that. Keep interoperability with existing clients and servers, while modifying the protocol to simplify it and to make it support the extensions that were not fleshed out when the current draft was written. Either way, you better find someone who works on clients and consumer software who actually has time to devote to WebDAV and fast or you will fail to produce a protocol that will be widely implementable. I assure you, you are already far along the path of unimplementability as it is. I need at least one example of such an unimplementable feature of the protocol before I can address the issue. Cheers, Geoff From w3c-dist-auth-request@w3.org Fri Sep 24 18:17: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 SAA13538 for ; Fri, 24 Sep 1999 18:17:32 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id SAA02811; Fri, 24 Sep 1999 18:05:11 -0400 (EDT) Resent-Date: Fri, 24 Sep 1999 18:05:11 -0400 (EDT) Resent-Message-Id: <199909242205.SAA02811@www19.w3.org> Date: Fri, 24 Sep 1999 18:05:00 -0400 Message-Id: <9909242205.AA08628@tantalum> From: "Geoffrey M. Clemm" To: ejw@ics.uci.edu Cc: w3c-dist-auth@w3.org In-Reply-To: (message from Jim Whitehead on Fri, 24 Sep 1999 14:24:09 -0700) Subject: Re: DELETE leaving a lock-null resource; was LOCK Scenarios Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3395 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: Jim Whitehead Edgar Schwarz write: So a server could just remember lock tokens together with old and new URLs and keep this data until it is accessed by the locker or the lock expires. I'm not convinced this will work, since it only handles the case where the resource is moved just once. What happens if a resource is locked, then moved, and moved again? How many steps is the server required to remember? Subsequent MOVE's are not relevant. The server is responsible for retrieving the same resource whenever the client gives it a URL and a lock token (think of it as a private binding that the server keeps around). The server could do this by just refusing to MOVE or DELETE the resource (as is required by the current 2518 draft), or by just remembering what resource is associated with that pair. All we are doing here is giving the server some additional flexibility in implementation that was constrained by the current language in 2518. Note: if a lock-token is included in a MOVE or DELETE request, it is used to satisfy any locks on the source and destination *collections*. Locks on the resource being moved or deleted are not even inspected (since the state of the resource being moved or deleted is not being modified). Cheers, Geoff From w3c-dist-auth-request@w3.org Fri Sep 24 18:25: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 SAA13587 for ; Fri, 24 Sep 1999 18:25:16 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id SAA02968; Fri, 24 Sep 1999 18:13:18 -0400 (EDT) Resent-Date: Fri, 24 Sep 1999 18:13:18 -0400 (EDT) Resent-Message-Id: <199909242213.SAA02968@www19.w3.org> Date: Fri, 24 Sep 1999 18:13:07 -0400 Message-Id: <9909242213.AA08637@tantalum> From: "Geoffrey M. Clemm" To: w3c-dist-auth@w3.org In-Reply-To: <852567F6.0076B8D4.00@D51MTA03.pok.ibm.com> (ccjason@us.ibm.com) Subject: Re: DELETE Semantics Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3396 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 I agree that collections are to manage and control namespace. My editorial comment was that locking a whole collection to protect a single binding seems like a lot of overkill. And if you want to protect a URI mapping... you'd have to lock the collection chain up to the root. Even more overkill. But the URL is "protected" by a LOCK, since we are requiring that a subsequent use of the URL with that lock token always select that locked resource. We're just removing the language in 2518 that over-constrained the server implementation (i.e. removing the language that said you cannot apply a MOVE or a DELETE to a locked resource). What 2518 didn't realize (and neither did I until Edgar pointed it out) you don't need to prevent the MOVE or DELETE just to keep a handle on the locked resource. So you only need to apply a lock to a collection if you really want to reserve the right to change the membership or properties of that collection. Cheers, Geoff From w3c-dist-auth-request@w3.org Fri Sep 24 19:21: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 TAA14049 for ; Fri, 24 Sep 1999 19:21:02 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id TAA03932; Fri, 24 Sep 1999 19:08:23 -0400 (EDT) Resent-Date: Fri, 24 Sep 1999 19:08:23 -0400 (EDT) Resent-Message-Id: <199909242308.TAA03932@www19.w3.org> From: ccjason@us.ibm.com X-Lotus-FromDomain: IBMUS To: "Geoffrey M. Clemm" cc: w3c-dist-auth@w3.org Message-ID: <852567F6.007F125A.00@D51MTA03.pok.ibm.com> Date: Fri, 24 Sep 1999 19:14:11 -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/3397 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 Yaron that we do not want to bite off general transactioning support as part of WebDAV. I agree. I also agree with his implying that NULL LOCKS aren't really a violation of this design philosophy. BTW, in so far as what happens when you DELETE a locked resource I completely oppose the suggestion that DELETING a resource results in a lock-null resource. That is absolutely contrary to the definition of DELETE. DELETE deletes the resource not the name. Since the lock is associated with the resources deleting a locked resource deletes both the resource and the lock. If lock were *really* just associated with the resource, I'd be a happy camper. For one thing, it would mean that when multiple URL's are mapped to a single resource, you could issue the LOCK against any of those URL's and the result would be identical. Similarly, you could later on issue on UNLOCK against any of those URL's and again, the result would be identical. I think if we say that locks are bound to URI's, I'm comfortable with a null lock resource being left after a delete. At least optionally. This can be very handy and leverages null lock resources well. OTOH, if we go with a model that locks are bound to resources and that DELETE deletes bindings, then something has to give. (If not, DELETE may actually create a lock so that the null resource has a lock and so the original resource also has a lock at its other bindings. Hmmm.) I think what has to give is that null locks go away. At least for DELETE in this model. I think Yaron just posted that DELETE deletes resources, not bindings. I prefer the "single UNBIND" model of DELETE. A lot of discussion has already gone into this. I personally believe that the best answer is to fix the LOCK semantics so it *really* is just on the resource (and not on the name). Then things are simpler and consistent, even in the case of multiple URL mappings to a resource. Rather than "protecting" a URL to resource mapping, I'd propose that a locked resource be allowed to MOVE (this is just a change to the state of the parent collection, not to the state of the resource being moved), but that an attempt to access the MOVE'd resource with that lock just returns a 302 indicating where it has MOVE'd to. I agree in principle about that changing to a pure model should be easier. (Pure URI or pure resource.) I'm uneasy though about the mechanism suggested to find where resources have moved to. Seems messy. Less so without depth locks though. More analysis later. So there are really multiple threads here: - Should locking be on a resource or also/instead on a URL-to-resource mapping? (we know what it is now, but what *should* it be) * I vote "on a resource". I'll play along for now. :-) - Does a DELETE delete all bindings to a resource, or just the one specified in the request-URL. * I vote "just the one named by the request-URL". Sounds fine. - Should a DELETE delete a LOCK? * I vote, "no". A DELETE modifies the state of the collection containing the binding, not that of the resource. In particular, all other mappings to that resource will continue to exist and display the LOCK'ed semantics. If you want to prevent a DELETE, you put the LOCK on the collection whose state is being modified. Sounds fine given the model. I do think locking a collection is a rather fat approach but I still agree with your point. From w3c-dist-auth-request@w3.org Fri Sep 24 20:36: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 UAA14641 for ; Fri, 24 Sep 1999 20:36:14 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id UAA05102; Fri, 24 Sep 1999 20:23:25 -0400 (EDT) Resent-Date: Fri, 24 Sep 1999 20:23:25 -0400 (EDT) Resent-Message-Id: <199909250023.UAA05102@www19.w3.org> Message-ID: <078292D50C98D2118D090008C7E9C6A603C9668C@STAY.platinum.corp.microsoft.com> From: "Yaron Goland (Exchange)" To: "'Geoffrey M. Clemm'" , w3c-dist-auth@w3.org Date: Fri, 24 Sep 1999 17:23:09 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Subject: RE: DELETE leaving a lock-null resource; was LOCK Scenarios Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3398 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list > That is definitely a major loss ... would a write-in campaign > to BG get > him to lighten your load? (Probably not ... :-). Oh but I'm working on such cool stuff!!!! SSDP, GENA and HTTP over UDP just rock the universe! What is really cool is how we are starting to integrate DASL into GENA. In addition I will be exploring some other really cool areas that I can't talk about but which will bring me right back to WebDAV. But for the moment I have to focus my attentions elsewhere. I will try my best to review specs when they reach "maturity" points. That is what I have been trying to do with the advanced collection specs. > The proposed protocol would allow a server to lock the namespace, > but would not *require* it to do so. This lets a low-end server > just lock the namespace, while letting a high-end server support > versioning and multiple bindings while ensuring a low-end (or any) > client access to his/her locked resource. A win/win, I believe. It is lose/lose if you are a client writer. When I write my client I MUST know EXACTLY what the behavior is. I can not have a situation where I am editing a document in Word, I lock the document and then the damn name changes! When I lock a resource I am also locking the name I am editing that resource under. It MUST NOT ever change. Any other behavior makes writing a simple client impossible. One of the really scary things I have heard both you and JimA say is how glad you are that WebDAV will offer many choices and allow for various gradations of service. THIS IS A MISTAKE! We are in the standards business, not the buffet business. Choice kills interoperability. That is what makes standard writing so damn hard. You can't give everyone everything and have interoperability so you have to screw over everybody. Hence the definition of compromise as "When no one gets what they want." I would remind everyone of two very important WebDAV maximums: 1) The spec is done when there is nothing left to cut. 2) There are two types of features, mandatory and not in the spec. Just making locking optional required six months of debate and almost resulted in bloodshed. > It's not the appearance of the history resource that is the issue. > It is the DELETE being applied by a down level client to a revision > that is supposed to remain part of the history of that resource. > The down level client is not aware of versioning ... it just wants > that resource to no longer appear at that URL. > If a DELETE is a DESTROY, that naive DELETE from a down level client > is required to blast that supposedly immutable persistent revision > out of existence ... a very bad thing. This is what I mean about thinking out of the box. Someone said "this resource is versioned." Once you have an affirmative command like that you can do anything you want. For example, you can say "A DELETE on a versioned resource without the magic foobar header deletes all links but the one to the history, not the resource." Now, before both you and JimA scream at me in stereo "BUT YOU MORON! THAT IS WHAT WE HAVE BEEN SAYING!" let me tell you what I heard you say: JimA & Jeff: A DELETE will delete a binding not the resource. Now let's compare that to what Yaron is saying. Yaron: A DELETE on a versioned resource without the magic foobar header deletes all bindings but the one to the history, not the resource. Notice the difference. The default behavior for DELETE is still to nuke the resource. But in a case where we have positive affirmation that the behavior is to change then change away. Also notice that this DOES NOT mean that DELETEing a resource with references only deletes the reference. It only applies to the particular case of a versioned resource. > In a file system, if you move a resource, it keeps its permissions. > I don't consider a file system something provided by only a super high > end provider, but they have no trouble moving permission > style information > along with a resource (I know permissions are not locks, but analogous > implementations can be used). True but it doesn't keep its locks. The file system has no way to maintain the lock across moves. This becomes especially important for the average case where you need to expose that lock through multiple protocols. These are the sorts of nitty gritty issues you only live and breath if you ship file systems for a living. The problem is that none of the active members seem to do that. > I need at least one example of such an unimplementable > feature of the protocol before I can address the issue. How about locks surviving moves? How about allowing the name of a file to change when locked? The first can't be done by most servers and the second can't be handled by most clients. Yaron From w3c-dist-auth-request@w3.org Fri Sep 24 21:45: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 VAA15932 for ; Fri, 24 Sep 1999 21:45:39 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id VAA08498; Fri, 24 Sep 1999 21:33:00 -0400 (EDT) Resent-Date: Fri, 24 Sep 1999 21:33:00 -0400 (EDT) Resent-Message-Id: <199909250133.VAA08498@www19.w3.org> From: ccjason@us.ibm.com X-Lotus-FromDomain: IBMUS To: "Geoffrey M. Clemm" cc: ejw@ics.uci.edu, w3c-dist-auth@w3.org Message-ID: <852567F7.000876CF.00@D51MTA03.pok.ibm.com> Date: Fri, 24 Sep 1999 21:38:41 -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/3399 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 a server could just remember lock tokens together with old and new URLs and keep this data until it is accessed by the locker or the lock expires. I'm not convinced this will work, since it only handles the case where the resource is moved just once. What happens if a resource is locked, then moved, and moved again? How many steps is the server required to remember? Subsequent MOVE's are not relevant. The server is responsible for retrieving the same resource whenever the client gives it a URL and a lock token (think of it as a private binding that the server keeps around). Geoff, I think Jim's point was that the same lock could have been rooted at many places over the course of time as it has moved. In fact due to multiple bindings and such... we've added even one more multiplier to the size of the list that needs to be maintained. His question though was how long does the server need to maintain it. I guess the server/lock would need to remember all of it's URI's until the resource is eventually UNLOCK'd. The server could do this by just refusing to MOVE or DELETE the resource (as is required by the current 2518 draft), or by just remembering what resource is associated with that pair. All we are doing here is giving the server some additional flexibility in implementation that was constrained by the current language in 2518. I see. So the proposal is that a server either to protect the URI... or to maintain a way for a client to follow where it moved to... and you're proposing the mechanism to do the latter. Interesting. It could be a market differentiator. It would mean a bit more complexity for the client to support either type of server though. Not much though. I think if the client supported what you're proposing, they'd also work with a system that does URI protection. They'd just wouldn't execute the code that deals with what happens after a remapping. Also note: in the presence of depth locks... zillions of resources can be locked. I don't think this necessarily increases the size of the list of lock URI's maintained since I believe only the URI's of the root of the lock need to be maintained... but it does mean that the resolution algorithm has to be more sophisticated since it would also need to remap the URI of child resources also. This means that a client must submit lock tokens with GETs and PROPFIND's just to insure it gets redirected when necessary. No biggie I suppose. I'm not sure this would work well with clients that seperate the lock action from subsequent actions on the locked resources. That is, a human is running the client code. The human requests the locks. Then a human requests various actions on resources that "just happen to be locked". I guess that whenever the human requests an action on a resource, the client application would just need to make a point of finding all locks that apply to a resource... even if inherited... and submit them with the request. I guess this sort of client app often would have to do this anyway, but now they must also do it for PROPFIND and GET also. Okay, no biggie. It also means that I believe for the first time in WebDAV, it actually becomes functionally important to specify the URI at which we think a lock is rooted when we submit the lock token. Note: all of this also needs to apply to DELETE (UNBIND) in addition to MOVE. It also in turn applies to a COPY that deletes the destination due to the implicit DELETE phase. It also applies to a BIND that deletes a previous binding. Note: if a lock-token is included in a MOVE or DELETE request, it is used to satisfy any locks on the source and destination *collections*. Locks on the resource being moved or deleted are not even inspected (since the state of the resource being moved or deleted is not being modified). I don't think this is what you were trying to say, but what you just said inspired a thought. If someone does a MOVE... and all the tokens of all the would-be protected URI's are submitted, the server doesn't need to maintain a remapping list because the client already knows which locks have lost those mappings. It's only the URI's for locks for which no tokens were submitted that the server needs to remember the remapping. This might provide for more efficient operation. A lock can have many mappings and a single operation can delete multiple mappings of a lock. Previously we said that each lock had a particular URI that was protected... and only when that URI was moved, did feel compelled to do any kind of lock remapping. Although we could probably guess, t now claim to know what lock mapping(s) the client really cares about. None are more privledged. I think the previous paragraph has to be modified to state that if any of these locks have other mappings than the mappings submitted with the token, then all of those others that are broken by an operation need to go onto the remapping list for that lock. Is this really *required*? I think technically yes... but probably not in practice. The client probably only knows a lock by one mapping... and it will be the one that the client will submit. Protecting a URI is sounding easier. :-) From w3c-dist-auth-request@w3.org Sat Sep 25 00:57: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 AAA18689 for ; Sat, 25 Sep 1999 00:57:07 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id AAA13062; Sat, 25 Sep 1999 00:44:19 -0400 (EDT) Resent-Date: Sat, 25 Sep 1999 00:44:19 -0400 (EDT) Resent-Message-Id: <199909250444.AAA13062@www19.w3.org> Date: Sat, 25 Sep 1999 00:44:06 -0400 Message-Id: <9909250444.AA08814@tantalum> From: "Geoffrey M. Clemm" To: w3c-dist-auth@w3.org In-Reply-To: <078292D50C98D2118D090008C7E9C6A603C9668C@STAY.platinum.corp.microsoft.com> (yarong@Exchange.Microsoft.com) Subject: Re: DELETE leaving a lock-null resource; was LOCK Scenarios Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3400 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)" The proposed protocol would allow a server to lock the namespace, but would not *require* it to do so. This lets a low-end server just lock the namespace, while letting a high-end server support versioning and multiple bindings while ensuring a low-end (or any) client access to his/her locked resource. A win/win, I believe. It is lose/lose if you are a client writer. When I write my client I MUST know EXACTLY what the behavior is. I can not have a situation where I am editing a document in Word, I lock the document and then the damn name changes! When I lock a resource I am also locking the name I am editing that resource under. It MUST NOT ever change. Any other behavior makes writing a simple client impossible. First, let's be clear on what the proposal is: When you issue a write lock request on a URL that maps to a resource R, the state (i.e. body and properties) of R can only be updated by PUT and PROPPATCH when the request is accompanied by the lock token. Furthermore, until an UNLOCK is performed, a GET, PUT, PROPFIND, and PROPPATCH to the original URL when accompanied by that lock token will always apply to that resource, even if that resource has been MOVE'd or DELETE'd subsequent to the LOCK request. One way a server can implement these semantics is to fail any MOVE's or DELETE's that would modify this URL mapping. Another way would be to just remember what resource the URL with that lock token maps to. Same protocol, different implementation choices. In either case, the desired effect, namely that I can: LOCK U => token-55 GET U, token-55 => entity PUT U, token-55, body PUT U, token-55, body UNLOCK U, token-55 with the guarantee that all the GET's and PUT's will refer to the same resource, and that only a client with token-55 can update U after the LOCK request until the UNLOCK request has been issued. I admit that the requirement that the token be used with the GET statement is an incompatibility with the old spec, but it is by no means complex for clients to handle. One of the really scary things I have heard both you and JimA say is how glad you are that WebDAV will offer many choices and allow for various gradations of service. THIS IS A MISTAKE! We are in the standards business, not the buffet business. Choice kills interoperability. That is what makes standard writing so damn hard. You can't give everyone everything and have interoperability so you have to screw over everybody. Hence the definition of compromise as "When no one gets what they want." There are two very separate issues here. The first is whether the protocol should be compatible with a variety of server implementations. I (and I'm sure JimA) feel that is a good thing. The second is whether a protocol should have many or any "optional" parts. If there's anything that JimA has been adamantly opposed to, it is any "optional" protocol parts. I share that view entirely (for all the obvious reasons having to do with interoperability and minimizing client complexity). It is only with great anguish (easily commensurate with that involved in making locking optional) that we have broken the versioning protocol into "core" and "extended" functionality. But that is not what is going on here with locking, so lets defer that discussion until we're dealing with the versioning protocol. For the locking protocol, the flexibility that is being discussed is only of the first kind, i.e. there being one single (simple) protocol definition, that admits a variety of implementation choices by servers. I would remind everyone of two very important WebDAV maximums: 1) The spec is done when there is nothing left to cut. 2) There are two types of features, mandatory and not in the spec. I am a strong believer in both of these maxims. In particular, the main changes I want to make to 2518 is in the "cutting" area. For example, lock-null resources. As for optional features, it is only as a *very* last resort that a protocol is split into two pieces, but as can be seen in the 2518, sometimes the last resort is the only place you can go. Just making locking optional required six months of debate and almost resulted in bloodshed. Our experience with versioning as well, on the issue of breaking the spec into "core" and "extended". This is what I mean about thinking out of the box. Someone said "this resource is versioned." Once you have an affirmative command like that you can do anything you want. For example, you can say "A DELETE on a versioned resource without the magic foobar header deletes all links but the one to the history, not the resource." The versioning example was just an example. The decision by the advanced collection team to propose that DELETE be "unbind" was done independently of any needs of versioning. John Stracke recently posted a simple authoring example of why unbind is the "right" semantics in the presence of multiple bindings. Yaron: A DELETE on a versioned resource without the magic foobar header deletes all bindings but the one to the history, not the resource. The presence of magic foobar headers that significantly change the semantics of basic operations is not in my view a recipe for success. One then has to define the correct behavior of all those magic headers when combined in various ways, and the likelihood of two servers doing all the magic in compatible ways decreases severely. Just look at all the mail about the behavior of depth locking and URI protection and null resource locking in the presence of multiple bindings. Imagine trying to make sense of this if there was a magical header that changed the meaning for versioning, and another magical header that changed the locking behavior of MOVE. Notice the difference. The default behavior for DELETE is still to nuke the resource. But in a case where we have positive affirmation that the behavior is to change then change away. I have seen no convincing reason for having DELETE nuke the resource. For downlevel clients and servers that do not support multiple bindings, there is no difference between unbind and destroy. What incompatibility are you trying to avoid by making the semantics be destroy? Also notice that this DOES NOT mean that DELETEing a resource with references only deletes the reference. It only applies to the particular case of a versioned resource. As above, special casing is not a path that leads to simplicity, either for clients or for servers. In a file system, if you move a resource, it keeps its permissions. I don't consider a file system something provided by only a super high end provider, but they have no trouble moving permission style information along with a resource (I know permissions are not locks, but analogous implementations can be used). True but it doesn't keep its locks. That's fine. Then it just fails the move, and the client has to unlock before moving. But just for my own edification, I'd *really* be interested in knowing what these file system locks are that you refer to. What locks?? I've seen no user visible locks (in the WebDAV sense, with lock tokens) in either Unix file systems or the Windows95 file system. I don't say that there aren't any, but I've never seen them exposed. Is this some internal implementation thing that is under the hood? Did I just miss them (I believe you've seen this question from me before :-). The file system has no way to maintain the lock across moves. This becomes especially important for the average case where you need to expose that lock through multiple protocols. These are the sorts of nitty gritty issues you only live and breath if you ship file systems for a living. The problem is that none of the active members seem to do that. If a server can't support a move of a lock, it simply fails the move. The client gets the error code back, unlocks the resource, and then performs the move. Easy for the client, easy for the server. I continue to fail to see any problem here. > I need at least one example of such an unimplementable > feature of the protocol before I can address the issue. How about locks surviving moves? A server is free to refuse a move request it cannot honor for any reason, whether because it cannot move locks, or because it cannot perform cross-server moves, or whatever. In the former case, the client unlocks and retries the move. In the latter case, the client tries a copy/delete if that is OK. Easy for server to detect and implement, well defined error codes, simple client responses. How about allowing the name of a file to change when locked? If you have the request-URL for the lock and the lock-token that was returned, you are guaranteed to be able to keep using them to access the locked resource. That's the key use case, and it still works. So I'm still waiting for something hard for the server or the client (:-). Cheers, Geoff From w3c-dist-auth-request@w3.org Sun Sep 26 03:25:57 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 DAA03076 for ; Sun, 26 Sep 1999 03:25:57 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id DAA23592; Sun, 26 Sep 1999 03:12:37 -0400 (EDT) Resent-Date: Sun, 26 Sep 1999 03:12:37 -0400 (EDT) Resent-Message-Id: <199909260712.DAA23592@www19.w3.org> Message-ID: <078292D50C98D2118D090008C7E9C6A603C96692@STAY.platinum.corp.microsoft.com> From: "Yaron Goland (Exchange)" To: "'Geoffrey M. Clemm'" , w3c-dist-auth@w3.org Date: Sun, 26 Sep 1999 00:12:19 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Subject: RE: DELETE leaving a lock-null resource; was LOCK Scenarios Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3401 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 admit that the requirement that the token be used with the GET > statement is an incompatibility with the old spec, but it is by > no means complex for clients to handle. Perhaps I don't understand the proposal. I have provided examples below which demonstrate how it appears to me that the proposal works. Please let me know if I have analyzed the situation correctly. Example #1 - Hiro is writing up his new web page using Microsoft Word. Word is supposed to be WYSIWYG but he knows that HTML handling is more art than science. So he boots up Netscape, which many of his users use, to see how the document looks in Netscape. Unfortunately the document isn't there anymore. He goes back to Word, Word insists the document is still there! What is going on? What has happened is that Word has locked the document but someone else moved the document. Since Word continued to send in the lock token to the old resource it appeared to Word that everything was fine. However when Hiro went to use Netscape, which knew nothing of the lock token, the document was gone. Example #2 - Irit is at work working on a document. Unfortunately people keep popping by her office every five minutes to ask her questions. She really needs to get some work done so she decides to go home. However she wants to make sure that no one messes with her documents while she is going home. So she takes out a long term lock on the document and then shuts down her computer. She drives home and logs in from home. She tells her word processor to edit the document. The word processor tells her that the document is gone! What happened? She had a lock, who messed with her document? What has happened is that the lock is still there but someone moved the document. Since Irit's word processor doesn't know about this move there is no way for her word processor find out where the document, with her lock still on it, is. BTW, if the document hadn't been moved then the word processor would have gotten a lock error when it tried to lock the document, examined the lock, saw that it belonged to Irit and started to use the lock token. Because the document was moved the word processor never got the chance to go through this process. Yaron From w3c-dist-auth-request@w3.org Sun Sep 26 03:43:00 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 DAA05344 for ; Sun, 26 Sep 1999 03:43:00 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id DAA23732; Sun, 26 Sep 1999 03:30:51 -0400 (EDT) Resent-Date: Sun, 26 Sep 1999 03:30:51 -0400 (EDT) Resent-Message-Id: <199909260730.DAA23732@www19.w3.org> Message-ID: <078292D50C98D2118D090008C7E9C6A603C96693@STAY.platinum.corp.microsoft.com> From: "Yaron Goland (Exchange)" To: "'Geoffrey M. Clemm'" , w3c-dist-auth@w3.org Cc: "Jim Whitehead (E-mail)" Date: Sun, 26 Sep 1999 00:30:32 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Subject: Thoughts on writing standards that real clients can support Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3402 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 spoke Geoffrey M. Clemm: > A server is free to refuse a move request it cannot honor for any > reason, whether because it cannot move locks, or because it cannot > perform cross-server moves, or whatever. In the former case, the > client unlocks and retries the move. In the latter case, the client > tries a copy/delete if that is OK. Easy for server to detect and > implement, well defined error codes, simple client responses. For the edification of the working group I am now going to give you a peek into the mind of someone who creates File dialogs to support WebDAV in Office: (With apologies to my friends in Office, you know who you are =) "Well, um... uh... coffee? Yes, have coffee... Sugar? Wait where is the sugar? Oh.. here it is. O.k. Um.. Move... there is no cross-server protocol so any MOVE requests across namespaces is probably always going to fail. O.k. fine, don't allow the UI to support cross-server moves. Um... what about single namespaces physically split between multiple services? You know, http://foo/bar/ is on one machine but http://foo/ack is on another. Ahh screw 'em. They have no business making namespaces like that visible to the user or at least they should figure out how to connect them. If we get an error trying to do a MOVE in that case then put up a catastrophic error dialog telling the user that their server is completely busted and they need to complain to the server manufacturer. Just DON'T CALL US. The support bill for the protocol for the last release was unbelievable. Every time the screwy servers did something we got the damn call! If I can't figure out how to reduce the support costs we are going to have to kill support for the protocol. Oy... O.k. um... hum.... some servers will let me MOVE a locked file and um... some won't. Hum... o.k. um.. pick one. Flip coin. Heads, o.k. I will assume that all servers can support moving a locked file, if one fails then I will treat it as a catastrophic failure and put up a big warning telling the user that their server is a piece of garbage." This is the life of a client. This is why a good standard only uses "MUST" and why a bad standard uses "SHOULD" and "MAY". The argument that "we give a good failure indication to the client so we can allow the server to do whatever it wants" is a 100% reliable sign that you are creating a crappy standard. You pick one default behavior and anything that isn't that behavior should generally be a catastrophic failure. In this case this means that ALL servers MUST either support moving locked files or MUST NOT support moving locked files. One may somewhat reasonably but very naively ask "well why can't we just say that clients SHOULD NOT expect that locked files can be moved but if a server wants to allow it, so much the better?" Now put yourself in the shoes of the client maker. What are his choices? He writes his code, it is going to have to make some assumption as the default case. Does he always assume he can MOVE the file if it is locked? If he does then he has to be ready for a "non-catastrophic" failure (meaning - sorry, I don't support that feature) and write a back up code path which can do the unlock followed by a MOVE trick. This means he has two code paths he has to develop and test. A common mistake I see in the IETF is people thinking that the hard part is writing the code, I have lost count of the number of times I have heard "why are your complaining, it is ten lines of code?" It may very well be ten lines of code, but it is ten lines of code with two alternate paths both of which have to be tested. It isn't the code that kills you, it is the testing. In the end the client maker will just choose one path and 5 lines of code so that the number of test cases gets cut in half and he has a chance of actually shipping on time. A second problem with the "but the server can always say no" philosophy of protocol design is that clients depend on failure conditions. That is, clients will depend on MOVEs failing if a file is locked. For example, a client maker will allow users to move files in the file dialog depending on the fact that if other users are using files in that same tree the files will be locked so that the first user's MOVE commands will fail on those files. Put another way, a good standard provides both clear success and clear failure conditions. Saying "The server MAY move a file that is locked" fails the "clear success condition" test because a client won't know, baring catastrophic failure, if a MOVE on a locked file should work or not. This means that the client has to write two code paths which have to be tested. It means the client has to write two UIs, which have to be tested. This generally also ends up screwing up the client's APIs as well since a MOVE on a locked file could get an error both from moving the locked file and possibly from the unlocked/move pair that is used if the server doesn't supporting moving locked files. Saying "We will just tell clients that servers generally don't move locked files but we will let servers move locked files so that future more advanced clients can take advantage of the feature" fails the "clear failure condition" test. Either a MOVE on a locked file is supposed to succeed and a failure is an unrecoverable catastrophic event or a MOVE on a locked file is required to always fail. In either case the client has a single code path/UI design/API to code and test. But saying "maybe it works, maybe it doesn't" means that code/UI/API all have to be doubled. It is hard, very hard, painful in fact, to have to cut a feature which seems so reasonable. But it is only in making these hard decisions and really constraining the hell out of the defined functionality that you get interoperability. Of course the art to good protocol design is to know what not to define, what functionality to not include in the standard. That way you leave yourself ways out in the future. This is all summarized in the two maxims I put up before: 1) The spec is done when there is nothing left to cut. 2) There are only two types of features, mandatory and not in the spec. Yaron P.S. Although Jim Whitehead didn't help write this post he shares a lot of guilt for its contents. The philosophy explained here was developed by he and I in a series of arguments over the question of "well the server can always say no". This p.s. is added as my bit to help ensure that blame is properly apportioned. From w3c-dist-auth-request@w3.org Sun Sep 26 17:55: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 RAA09193 for ; Sun, 26 Sep 1999 17:55:20 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id RAA00494; Sun, 26 Sep 1999 17:42:40 -0400 (EDT) Resent-Date: Sun, 26 Sep 1999 17:42:40 -0400 (EDT) Resent-Message-Id: <199909262142.RAA00494@www19.w3.org> From: ccjason@us.ibm.com X-Lotus-FromDomain: IBMUS To: "Yaron Goland (Exchange)" cc: "'Geoffrey M. Clemm'" , w3c-dist-auth@w3.org, "Jim Whitehead (E-mail)" Message-ID: <852567F8.007739BD.00@D51MTA03.pok.ibm.com> Date: Sun, 26 Sep 1999 17:48:09 -0400 Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Subject: Re: Thoughts on writing standards that real clients can support Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3403 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, I think you have some good points. Although one of you client arguments against *optional* features don't quiet have the impact that you might expect if I understand the proposals. 1) The proposal that is currently going around is that MOVE moves locks. It isn't optional in that proposal. 2) If all the lock tokens are provided, the move will succeed. (Baring other conditions like lock conflicts at the dest.) 3) Lock URI protection is optional in the most recent thread... but this only involves the locks of other principles... so a client is unlikely to be able to detect this before hand and take an optional preemptive code path. (It will alway provide tokens.) And if there is a failure due to this type of conflict, the client app is still unlikely to take an alternate path... other than to tell the user of the problem which is a codepath that is always there. This only deals with the optional path topic... and only the issue of LOCK URI protection. I think you have good points about locking with Word for example. J. ------------------------------------------ Phone: 914-784-7569, ccjason@us.ibm.com From w3c-dist-auth-request@w3.org Mon Sep 27 15:31:30 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 PAA12069 for ; Mon, 27 Sep 1999 15:31:30 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id PAA01841; Mon, 27 Sep 1999 15:10:25 -0400 (EDT) Resent-Date: Mon, 27 Sep 1999 15:10:25 -0400 (EDT) Resent-Message-Id: <199909271910.PAA01841@www19.w3.org> Message-ID: <37EFC0F6.82186934@ecal.com> Date: Mon, 27 Sep 1999 15:09: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: <078292D50C98D2118D090008C7E9C6A603C96693@STAY.platinum.corp.microsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: Thoughts on writing standards that real clients can support Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3404 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 agree with Yaron. Having lots of alternatives sounds good, but so what? We had lots of alternatives to start with. :-) (telnet vs. FTP vs. FrontPage vs. Netscape content management extensions...). "Yaron Goland (Exchange)" wrote: > O.k. fine, don't allow the UI to support cross-server moves. Um... what > about single namespaces physically split between multiple services? You > know, http://foo/bar/ is on one machine but http://foo/ack is on another. > Ahh screw 'em. They have no business making namespaces like that visible to > the user or at least they should figure out how to connect them. For all my fellow MS-bashers out there: this sort of thought is not unique to MS. In fact, I don't think I've ever heard of any software company that couldn't have produced this monologue. :-) -- /=================================================================\ |John Stracke | http://www.ecal.com |My opinions are my own. | |Chief Scientist |================================================| |eCal Corp. |In the country of the blind, the one-eyed man is| |francis@ecal.com|in therapy. | \=================================================================/ From w3c-dist-auth-request@w3.org Mon Sep 27 18:12: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 SAA17301 for ; Mon, 27 Sep 1999 18:12:51 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id RAA08018; Mon, 27 Sep 1999 17:50:43 -0400 (EDT) Resent-Date: Mon, 27 Sep 1999 17:50:43 -0400 (EDT) Resent-Message-Id: <199909272150.RAA08018@www19.w3.org> From: Jim Whitehead To: WebDAV WG Date: Mon, 27 Sep 1999 14:46:36 -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: WebDAV WG meeting at Washington IETF Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3405 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 FYI, I have requested a meeting slot for WebDAV at the Washington, DC IETF meeting, November 7-12, 1999. Details on the IETF meeting can be found at: http://www.ietf.org/meetings/IETF-46.html I do not yet know when during this week the WebDAV meeting will be held, though from what I have heard from people, I have requested the meeting to be on either Wednesday or Thursday. I'll let you know when the meeting is scheduled. At present, I'm planning on having some discussion on Advanced Collections -- please send me email if you have another item for the agenda. - Jim From w3c-dist-auth-request@w3.org Wed Sep 29 16:47: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 QAA14259 for ; Wed, 29 Sep 1999 16:47:47 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id QAA21846; Wed, 29 Sep 1999 16:33:44 -0400 (EDT) Resent-Date: Wed, 29 Sep 1999 16:33:44 -0400 (EDT) Resent-Message-Id: <199909292033.QAA21846@www19.w3.org> From: jamsden@us.ibm.com X-Lotus-FromDomain: IBMUS To: w3c-dist-auth@w3.org, ietf-dav-versioning@w3.org cc: lrn@us.ibm.com, chayman@us.ibm.com Message-ID: <852567FB.0070C574.00@d54mta03.raleigh.ibm.com> Date: Wed, 29 Sep 1999 16:32:21 -0400 Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Subject: DELTA-V Working Group Update Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3406 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list Welcome to the new WebDAV DELTA-V working group! DELTA-V was formed to define extensions to HTTP and the WebDAV Distributed Authoring Protocol necessary to enable distributed Web authoring tools to perform, in an interoperable manner, versioning and configuration management of Web resources. I would like to thank all the people who have already contributed to the versioning specification, and inspirit them to continue their valued input. I would also like to welcome anyone who is interested in versioning, configuration management, support for multi-user, distributed parallel development, document management systems, and web authoring to join the DELTA-V working group and put your mark on the 'V' in WebDAV. The discussion list for DELTA-V is at ietf-dav-versioning@w3.org. To join the discussion list, and the working group, send an email with "Subject: subscribe" to ietf-dav-versioning-request@w3.org. You can find a copy of the DELTA-V charter at http://www.webdav.org/deltav/charter.txt. We have some strawmen documents that will let this working group hit the road running. First, there the versioning goals document at http://www.webdav.org/deltav/goals/draft-ietf-webdav-version-goals-01.txt. This document augments the scenarios and goals of the original WebDAV scenarios with items specific to distributed, multi-user versioning and configuration management. These goals and use cases were then used to construct a high-level UML model of WebDAV versioning available at http://www.webdav.org/deltav/model/model990209/. From the model, we derived a first pass at a protocol that extends HTTP and WebDAV to support the versioning semantics. The protocol specification is available at http://www.webdav.org/deltav/protocol/draft-ietf-webdav-versioning-02.txt. There's lots of work left to be done. The protocol specification is just getting started. Only the MKRESOURCE method, which was graciously done by Jim Whitehead, is complete and is the model for how we hope to complete the rest of the methods. Geoff Clemm and Chris Kaler are the authors of this document. Don't hesitate to give them your input. So far, we are pretty much on the schedule given in the charter. We are perhaps a little behind in the protocol specification, but hope to have a completed initial draft in time for the Washington IETF. We plan on having our first DELTA-V working group meeting at the Washington IETF and will use the time to review the protocol specification. Keep watching http://www.ietf.org/meetings/IETF-46.html for further information. Again, thanks for your participation. Versioning is an important part of controlled distributed authoring on the Web. Its hard, and there are lots of issues and compromises we have to address. But where there's a challenge, there's also an opportunity. I look forward to working with all of you to bring this important protocol extension to timely completion. From w3c-dist-auth-request@w3.org Wed Sep 29 18:28: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 SAA15975 for ; Wed, 29 Sep 1999 18:28:31 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id SAA24754; Wed, 29 Sep 1999 18:12:27 -0400 (EDT) Resent-Date: Wed, 29 Sep 1999 18:12:27 -0400 (EDT) Resent-Message-Id: <199909292212.SAA24754@www19.w3.org> From: Jim Whitehead To: WebDAV WG Date: Wed, 29 Sep 1999 15:08:04 -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: Adv. Col. breakout planned at DC IETF Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3407 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, Participants during the advanced collections teleconference today convinced me that it would be worthwhile to hold a separate breakout session, in addition to the WebDAV WG meeting, on the topic of Advanced Collections. Since we don't yet know when the WebDAV meeting will be held, it's a bit hard to schedule the Advanced Collections Breakout. But, schedules permitting, we'd like to hold it the same day as the WebDAV meeting (which I've requested to be either Wednesday or Thursday), with a tentative length of half a day. I'll send out more information once I know what the schedule looks like, hope this helps in your trip planning. - Jim From w3c-dist-auth-request@w3.org Wed Sep 29 20:36: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 UAA17084 for ; Wed, 29 Sep 1999 20:36:27 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id UAA28753; Wed, 29 Sep 1999 20:20:09 -0400 (EDT) Resent-Date: Wed, 29 Sep 1999 20:20:09 -0400 (EDT) Resent-Message-Id: <199909300020.UAA28753@www19.w3.org> From: Jim Whitehead To: WebDAV WG Date: Wed, 29 Sep 1999 17:15: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 V5.00.2314.1300 Subject: Proposed Extensions for WebDAV Properties Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3408 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 Well, looking back through the WebDAV mailing list archives, it doesn't look like the Internet Draft, "Proposed Extensions for WebDAV Properties", , was ever announced to the mailing list. For the record, the I-D is written by Jim Amsden, and describes three minor extensions to the current properties protocol: 1) allow PROPPATCH to create and initialize the properties of a resource that did not exist, 2) distinguish between adding a new property, and setting the value of an existing property of a resource, and 3) give client applications more control in specifying how PROPPATCH errors should be handled. The document is available at: http://www.ics.uci.edu/pub/ietf/webdav/props/draft-ietf-webdav-properties-ex tension-00.txt It's also available via the WebDAV WG home page, at: http://www.ics.uci.edu/pub/ietf/webdav/ I look forward to your comments on this proposal. - Jim