From w3c-dist-auth-request@w3.org Mon Oct 4 16:56: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 QAA08711 for ; Mon, 4 Oct 1999 16:56:27 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id QAA26230; Mon, 4 Oct 1999 16:41:58 -0400 (EDT) Resent-Date: Mon, 4 Oct 1999 16:41:58 -0400 (EDT) Resent-Message-Id: <199910042041.QAA26230@www19.w3.org> From: Jim Whitehead To: WebDAV WG Date: Mon, 4 Oct 1999 13:37:39 -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: WebDAV DTD Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3409 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 Accidentally caught by the spam filter. I've sent in a request to have Tim's email address added to the accept2 list, so hopefully this won't happen again. - Jim -----Original Message----- From: Tim Ellison OTT [mailto:Tim_Ellison@oti.com] Sent: Monday, October 04, 1999 12:48 PM To: w3c-dist-auth Subject: [Moderator Action] WebDAV DTD One rule in the DTD states: I suggest that this is modified to read so that streaming clients can retrieve the status of a property before they retireve the property itself , and thereby know whether the data is valid or not. In the current rule, such a client is required to read the prop data in its entirety, possibly to discover that the data is invalid only after the fact. Comments? ------------- Trivia: In RFC2518 Feb 1999 8.2.2 Example - PROPPATCH (1) The property is set as but the response stat is given as . Note the case switch. (2) The responsedescription states 'Copyright Owner can not..' the property was 'Copyright-Owner'. Either the response description is a canned response, in which case the hyphen is missing, or the server is doing something I don't understand! Tim From w3c-dist-auth-request@w3.org Mon Oct 4 16:59: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 QAA08749 for ; Mon, 4 Oct 1999 16:59:36 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id QAA26591; Mon, 4 Oct 1999 16:48:32 -0400 (EDT) Resent-Date: Mon, 4 Oct 1999 16:48:32 -0400 (EDT) Resent-Message-Id: <199910042048.QAA26591@www19.w3.org> Message-ID: <37F91279.5CAAF926@ecal.com> Date: Mon, 04 Oct 1999 16:47: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 WG References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: WebDAV DTD Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3410 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list Content-Transfer-Encoding: 7bit Jim Whitehead wrote: > One rule in the DTD states: > > > I suggest that this is modified to read > > > so that streaming clients can retrieve the status of a property before they > retireve the property itself Hmm. Is there anybody out there whose code this would break? I know my client code wouldn't mind; it passes the entire entity to an XML parser and then, given a propstat element, asks the parser "OK, give me the first status element and the first prop element". -- /==============================================================\ |John Stracke | http://www.ecal.com |My opinions are my own.| |Chief Scientist |=============================================| |eCal Corp. |"What now, Brain?" "We should flee in terror.| |francis@ecal.com|Yes, that would be the wisest course." | \==============================================================/ From w3c-dist-auth-request@w3.org Mon Oct 4 20:54: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 UAA10635 for ; Mon, 4 Oct 1999 20:54:00 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id UAA01378; Mon, 4 Oct 1999 20:39:17 -0400 (EDT) Resent-Date: Mon, 4 Oct 1999 20:39:17 -0400 (EDT) Resent-Message-Id: <199910050039.UAA01378@www19.w3.org> Message-ID: <003001bf0ecb$ccf32520$88c3173f@netdrive.com> From: "William Bjorge" To: Date: Mon, 4 Oct 1999 17:51:45 -0700 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Subject: Is it possible to license the Dav4J client? Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3411 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list Is IBM's DavJ4 client still available only through a 90 day license, or does anyone know if it can or will be available for use in production systems? Thanks for you help! Bill Bjorge Software Engineer bjorge@netdrive.com From w3c-dist-auth-request@w3.org Tue Oct 5 11:13: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 LAA04812 for ; Tue, 5 Oct 1999 11:13:29 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id KAA16368; Tue, 5 Oct 1999 10:59:24 -0400 (EDT) Resent-Date: Tue, 5 Oct 1999 10:59:24 -0400 (EDT) Resent-Message-Id: <199910051459.KAA16368@www19.w3.org> From: jamsden@us.ibm.com X-Lotus-FromDomain: IBMUS To: "William Bjorge" cc: w3c-dist-auth@w3.org Message-ID: <85256801.00524CF7.00@d54mta03.raleigh.ibm.com> Date: Tue, 5 Oct 1999 10:58:57 -0400 Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Subject: Re: Is it possible to license the Dav4J client? Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3412 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 is still only available through alphaWorks with the typical alphaWorks license. We are exploring the possibility of open sourcing DAV4J in order to facilitate the construction of WebDAV client applications, and WebDAV enabling existing repository managers. We'll keep you informed on this mailing list. "William Bjorge" on 10/04/99 08:51:45 PM To: w3c-dist-auth@w3.org cc: Subject: Is it possible to license the Dav4J client? Is IBM's DavJ4 client still available only through a 90 day license, or does anyone know if it can or will be available for use in production systems? Thanks for you help! Bill Bjorge Software Engineer bjorge@netdrive.com From w3c-dist-auth-request@w3.org Thu Oct 7 12:11: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 MAA19888 for ; Thu, 7 Oct 1999 12:11:17 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id LAA27950; Thu, 7 Oct 1999 11:52:35 -0400 (EDT) Resent-Date: Thu, 7 Oct 1999 11:52:35 -0400 (EDT) Resent-Message-Id: <199910071552.LAA27950@www19.w3.org> From: Tim_Ellison@oti.com (Tim Ellison OTT) To: w3c-dist-auth@w3.org (w3c-dist-auth) Message-ID: <1999Oct07.114800.1250.1345137@otismtp.ott.oti.com> X-Mailer: Microsoft Mail via PostalUnion/SMTP for Windows NT Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Organization: Object Technology International Inc Date: Thu, 07 Oct 1999 11:51:04 -0400 Subject: href element interpretation Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3413 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list Please can someone confirm that when a server responds with an element (RFC2518 section 12.3) containing a relative URI, the base URI will always be the retrieval URI (RFC 2396 section 5.1.3) (i.e. the Request-URI). All the examples in RFC2518 seem to return absolute-URIs. Thanks Tim From w3c-dist-auth-request@w3.org Thu Oct 7 12:54: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 MAA20699 for ; Thu, 7 Oct 1999 12:54:58 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id MAA00095; Thu, 7 Oct 1999 12:39:48 -0400 (EDT) Resent-Date: Thu, 7 Oct 1999 12:39:48 -0400 (EDT) Resent-Message-Id: <199910071639.MAA00095@www19.w3.org> Date: Thu, 7 Oct 1999 12:39:38 -0400 Message-Id: <9910071639.AA15825@tantalum> From: "Geoffrey M. Clemm" To: w3c-dist-auth@w3.org Subject: Simplifying RFC-2518 Locking: A non-proposal Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3414 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 non-proposal is as follows: Modify RFC-2518 to: - remove depth locks, shared locks, and lock null resources - add a Target-Selector header for reliable access to a locked resource - make simple single resource locking mandantory. This will simplify the implementation of both clients and servers, captures the key functionality that is in use today while deferring the more speculative elements of the protocol. The reason this is a non-proposal is that I'm afraid that the energy that it would require to get this change accepted would detract from what I believe is a more time critical task, namely, producing the DeltaV versioning protocol. But as one last tilt against this particular windmill, I'll include a "diff" indicating how I would change 2518 "if I ran the zoo" (:-). Cheers, Geoff This is similar to "diff -c" format, i.e. the old text comes first, and then the new text. Lines deleted are marked with a "-". Lines added are marked with a "+". Lines changed are marked with an "!". *** Original Text *** Locking: The ability to keep more than one person from working on a ! document at the same time. This prevents the "lost update problem," ! in which modifications are lost as first one author then another ! writes changes without merging the other author's changes. ! ! Null Resource - A resource which responds with a 404 (Not Found) to ! any HTTP/1.1 or DAV method except for PUT, MKCOL, OPTIONS and LOCK. ! A NULL resource MUST NOT appear as a member of its parent collection. 6 Locking --- New Text --- Locking: The ability to keep more than one person from working on a ! document at the same time. This prevents the "update merge problem," ! in which two author concurrently change the same resource, resulting ! in the need to merge the resulting documents. 6 Locking *** Original Text *** access to that resource. Using a lock, an authoring client can provide a reasonable guarantee that another principal will not modify a resource while it is being edited. In this way, a client can ! prevent the "lost update" problem. ! ! This specification allows locks to vary over two client-specified ! parameters, the number of principals involved (exclusive vs. shared) ! and the type of access to be granted. This document defines locking ! for only one access type, write. However, the syntax is extensible, ! and permits the eventual specification of locking for other access ! types. ! ! 6.1 Exclusive Vs. Shared Locks ! ! The most basic form of lock is an exclusive lock. This is a lock ! where the access right in question is only granted to a single ! principal. The need for this arbitration results from a desire to ! avoid having to merge results. ! ! However, there are times when the goal of a lock is not to exclude ! others from exercising an access right but rather to provide a ! mechanism for principals to indicate that they intend to exercise ! their access rights. Shared locks are provided for this case. A ! shared lock allows multiple principals to receive a lock. Hence any ! principal with appropriate access can get the lock. ! ! With shared locks there are two trust sets that affect a resource. ! The first trust set is created by access permissions. Principals who ! are trusted, for example, may have permission to write to the ! resource. Among those who have access permission to write to the ! resource, the set of principals who have taken out a shared lock also ! must trust each other, creating a (typically) smaller trust set ! within the access permission write set. ! ! Starting with every possible principal on the Internet, in most ! situations the vast majority of these principals will not have write ! access to a given resource. Of the small number who do have write ! access, some principals may decide to guarantee their edits are free ! from overwrite conflicts by using exclusive write locks. Others may ! decide they trust their collaborators will not overwrite their work ! (the potential set of collaborators being the set of principals who ! have write permission) and use a shared lock, which informs their ! collaborators that a principal may be working on the resource. ! ! The WebDAV extensions to HTTP do not need to provide all of the ! communications paths necessary for principals to coordinate their ! activities. When using shared locks, principals may use any out of ! band communication channel to coordinate their work (e.g., face-to- ! face interaction, written notes, post-it notes on the screen, ! telephone conversation, Email, etc.) The intent of a shared lock is ! to let collaborators know who else may be working on a resource. ! ! Shared locks are included because experience from web distributed ! authoring systems has indicated that exclusive locks are often too ! rigid. An exclusive lock is used to enforce a particular editing ! process: take out an exclusive lock, read the resource, perform ! edits, write the resource, release the lock. This editing process ! has the problem that locks are not always properly released, for ! example when a program crashes, or when a lock owner leaves without ! unlocking a resource. While both timeouts and administrative action ! can be used to remove an offending lock, neither mechanism may be ! available when needed; the timeout may be long or the administrator ! may not be available. ! ! 6.2 Required Support ! ! A WebDAV compliant server is not required to support locking in any ! form. If the server does support locking it may choose to support ! any combination of exclusive and shared locks for any access types. ! ! The reason for this flexibility is that locking policy strikes to the ! very heart of the resource management and versioning systems employed ! by various storage repositories. These repositories require control ! over what sort of locking will be made available. For example, some ! repositories only support shared write locks while others only ! provide support for exclusive write locks while yet others use no ! locking at all. As each system is sufficiently different to merit ! exclusion of certain locking features, this specification leaves ! locking as the sole axis of negotiation within WebDAV. 6.3 Lock Tokens --- New Text --- access to that resource. Using a lock, an authoring client can provide a reasonable guarantee that another principal will not modify a resource while it is being edited. In this way, a client can ! prevent the "update merge" problem. 6.3 Lock Tokens *** Original Text *** 7.1 Methods Restricted by Write Locks A write lock MUST prevent a principal without the lock from ! successfully executing a PUT, POST, PROPPATCH, LOCK, UNLOCK, MOVE, ! DELETE, or MKCOL on the locked resource. All other current methods, GET in particular, function independently of the lock. Note, however, that as new methods are created it will be necessary --- New Text --- 7.1 Methods Restricted by Write Locks A write lock MUST prevent a principal without the lock from ! successfully executing a PUT, POST, PROPPATCH, LOCK, or UNLOCK ! on the locked resource. A write lock on a collection MUST ! prevent a principal without the lock from successfully creating ! a new internal member or deleting an existing internal member ! of that collection. All other current methods, GET in particular, function independently of the lock. Note, however, that as new methods are created it will be necessary *** Original Text *** 7.2 Write Locks and Lock Tokens ! A successful request for an exclusive or shared write lock MUST result in the generation of a unique lock token associated with the ! requesting principal. Thus if five principals have a shared write ! lock on the same resource there will be five lock tokens, one for ! each principal. 7.3 Write Locks and Properties --- New Text --- 7.2 Write Locks and Lock Tokens ! A successful request for a write lock MUST result in the generation of a unique lock token associated with the ! requesting principal. This lock token can then be specified in ! a Target-Request header to reliably access the locked resource, ! even if the locked resource has been MOVE'd or DELETE'd. 7.3 Write Locks and Properties *** Original Text *** Only dead properties and live properties defined to respect locks are guaranteed not to change while write locked. - 7.4 Write Locks and Null Resources - - It is possible to assert a write lock on a null resource in order to - lock the name. - - A write locked null resource, referred to as a lock-null resource, - MUST respond with a 404 (Not Found) or 405 (Method Not Allowed) to - any HTTP/1.1 or DAV methods except for PUT, MKCOL, OPTIONS, PROPFIND, - LOCK, and UNLOCK. A lock-null resource MUST appear as a member of - its parent collection. Additionally the lock-null resource MUST have - defined on it all mandatory DAV properties. Most of these - properties, such as all the get* properties, will have no value as a - lock-null resource does not support the GET method. Lock-Null - resources MUST have defined values for lockdiscovery and - supportedlock properties. - - Until a method such as PUT or MKCOL is successfully executed on the - lock-null resource the resource MUST stay in the lock-null state. - However, once a PUT or MKCOL is successfully executed on a lock-null - resource the resource ceases to be in the lock-null state. - - If the resource is unlocked, for any reason, without a PUT, MKCOL, or - similar method having been successfully executed upon it then the - resource MUST return to the null state. - 7.5 Write Locks and Collections ! 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. As a consequence, when a principal issues a PUT or POST request to create a new resource under a URI which needs to be an internal member of a write locked collection to maintain HTTP namespace consistency, or issues a --- New Text --- Only dead properties and live properties defined to respect locks are guaranteed not to change while write locked. 7.5 Write Locks and Collections ! A write lock on a collection prevents the addition or removal of ! immediate member URIs of the collection by non-lock owners. As a consequence, when a principal issues a PUT or POST request to create a new resource under a URI which needs to be an internal member of a write locked collection to maintain HTTP namespace consistency, or issues a *** Original Text *** internal member URI of a write locked collection, this request MUST fail if the principal does not have a write lock on the collection. - However, if a write lock request is issued to a collection containing - member URIs identifying resources that are currently locked in a - manner which conflicts with the write lock, the request MUST fail - with a 423 (Locked) status code. - - If a lock owner causes the URI of a resource to be added as an - internal member URI of a locked collection then the new resource MUST - be automatically added to the lock. This is the only mechanism that - - allows a resource to be added to a write lock. Thus, for example, if - the collection /a/b/ is write locked and the resource /c is moved to - /a/b/c then resource /a/b/c will be added to the write lock. - 7.6 Write Locks and the If Request Header If a user agent is not required to have knowledge about a lock when --- New Text --- internal member URI of a write locked collection, this request MUST fail if the principal does not have a write lock on the collection. 7.6 Write Locks and the If Request Header If a user agent is not required to have knowledge about a lock when *** Original Text *** 7.7 Write Locks and COPY/MOVE A COPY method invocation MUST NOT duplicate any write locks active on ! the source. However, as previously noted, if the COPY copies the ! resource into a collection that is locked with "Depth: infinity", ! then the resource will be added to the lock. ! ! A successful MOVE request on a write locked resource MUST NOT move ! the write lock with the resource. However, the resource is subject to ! being added to an existing lock at the destination, as specified in ! section 7.5. For example, if the MOVE makes the resource a child of a ! collection that is locked with "Depth: infinity", then the resource ! will be added to that collection's lock. Additionally, if a resource ! locked with "Depth: infinity" is moved to a destination that is ! within the scope of the same lock (e.g., within the namespace tree ! covered by the lock), the moved resource will again be a added to the ! lock. In both these examples, as specified in section 7.6, an If ! header must be submitted containing a lock token for both the source ! and destination. 7.8 Refreshing Write Locks --- New Text --- 7.7 Write Locks and COPY/MOVE A COPY method invocation MUST NOT duplicate any write locks active on ! the source. ! ! A successful MOVE request on a write locked resource MUST move ! the write lock with the resource. 7.8 Refreshing Write Locks *** Original Text *** - - - - - --- New Text --- *** Original Text *** - - - - - --- New Text --- *** Original Text *** specific properties assert that "container" was created on December 1, 1997, at 5:42:21PM, in a time zone 8 hours west of GMT (creationdate), has a name of "Example collection" (displayname), a ! collection resource type (resourcetype), and supports exclusive write ! and shared write locks (supportedlock). The resource http://www.foo.bar/container/front.html has nine properties defined on it: --- New Text --- specific properties assert that "container" was created on December 1, 1997, at 5:42:21PM, in a time zone 8 hours west of GMT (creationdate), has a name of "Example collection" (displayname), a ! collection resource type (resourcetype), and supports write locks ! (supportedlock). The resource http://www.foo.bar/container/front.html has nine properties defined on it: *** Original Text *** "text/html" (getcontenttype), an entity tag of "zzyzx" (getetag), was last modified on Monday, January 12, 1998, at 09:25:56 GMT (getlastmodified), has an empty resource type, meaning that it is not ! a collection (resourcetype), and supports both exclusive write and ! shared write locks (supportedlock). 8.1.3 Example - Using propname to Retrieve all Property Names --- New Text --- "text/html" (getcontenttype), an entity tag of "zzyzx" (getetag), was last modified on Monday, January 12, 1998, at 09:25:56 GMT (getlastmodified), has an empty resource type, meaning that it is not ! a collection (resourcetype), and supports write ! locks (supportedlock). 8.1.3 Example - Using propname to Retrieve all Property Names *** Original Text *** >>Request ! DELETE /container/ HTTP/1.1 Host: www.foo.bar >>Response --- New Text --- >>Request ! DELETE /container/resource3 HTTP/1.1 Host: www.foo.bar >>Response *** Original Text *** In this example the attempt to delete http://www.foo.bar/container/resource3 failed because it is locked, ! and no lock token was submitted with the request. Consequently, the ! attempt to delete http://www.foo.bar/container/ also failed. Thus the ! client knows that the attempt to delete http://www.foo.bar/container/ ! must have also failed since the parent can not be deleted unless its ! child has also been deleted. Even though a Depth header has not been ! included, a depth of infinity is assumed because the method is on a ! collection. 8.8.5 COPY Status Codes --- New Text --- In this example the attempt to delete http://www.foo.bar/container/resource3 failed because it is locked, ! and no lock token was submitted with the request. 8.8.5 COPY Status Codes *** Original Text *** resource MUST NOT succeed if can not be honored by all the URIs through which the resource is addressable. ! 8.10.4 Depth and Locking ! The Depth header may be used with the LOCK method. Values other than ! 0 or infinity MUST NOT be used with the Depth header on a LOCK ! method. All resources that support the LOCK method MUST support the ! Depth header. ! ! A Depth header of value 0 means to just lock the resource specified ! by the Request-URI. ! ! If the Depth header is set to infinity then the resource specified in ! the Request-URI along with all its internal members, all the way down ! the hierarchy, are to be locked. A successful result MUST return a ! single lock token which represents all the resources that have been ! locked. If an UNLOCK is successfully executed on this token, all ! associated resources are unlocked. If the lock cannot be granted to ! all resources, a 409 (Conflict) status code MUST be returned with a ! response entity body containing a multistatus XML element describing ! which resource(s) prevented the lock from being granted. Hence, ! partial success is not an option. Either the entire hierarchy is ! locked or no resources are locked. ! ! If no Depth header is submitted on a LOCK request then the request ! MUST act as if a "Depth:infinity" had been submitted. ! ! 8.10.5 Interaction with other Methods ! ! The interaction of a LOCK with various methods is dependent upon the ! lock type. However, independent of lock type, a successful DELETE of ! a resource MUST cause all of its locks to be removed. ! ! 8.10.6 Lock Compatibility Table ! ! The table below describes the behavior that occurs when a lock ! request is made on a resource. ! ! Current lock state/ | Shared Lock | Exclusive ! Lock request | | Lock ! =====================+=================+============== ! None | True | True ! ---------------------+-----------------+-------------- ! Shared Lock | True | False ! ---------------------+-----------------+-------------- ! Exclusive Lock | False | False* ! ------------------------------------------------------ ! ! Legend: True = lock may be granted. False = lock MUST NOT be ! granted. *=It is illegal for a principal to request the same lock ! twice. ! ! The current lock state of a resource is given in the leftmost column, ! and lock requests are listed in the first row. The intersection of a ! row and column gives the result of a lock request. For example, if a ! shared lock is held on a resource, and an exclusive lock is ! requested, the table entry is "false", indicating the lock must not ! be granted. 8.10.7 Status Codes --- New Text --- resource MUST NOT succeed if can not be honored by all the URIs through which the resource is addressable. ! 8.10.6 Lock Compatibility ! If a resource is locked, any attempt to lock that resource (other ! than to refresh an existing lock) must fail. 8.10.7 Status Codes *** Original Text *** - http://www.ics.uci.edu/~ejw/contact.html --- New Text --- http://www.ics.uci.edu/~ejw/contact.html *** Original Text *** - - Infinity --- New Text --- *** Original Text *** ! This example shows the successful creation of an exclusive write lock on resource http://webdav.sb.aol.com/workspace/webdav/proposal.doc. The resource http://www.ics.uci.edu/~ejw/contact.html contains contact information for the owner of the lock. The server has an --- New Text --- ! This example shows the successful creation of a write lock on resource http://webdav.sb.aol.com/workspace/webdav/proposal.doc. The resource http://www.ics.uci.edu/~ejw/contact.html contains contact information for the owner of the lock. The server has an *** Original Text *** - - Infinity http://www.ics.uci.edu/~ejw/contact.html --- New Text --- http://www.ics.uci.edu/~ejw/contact.html *** Original Text *** opaque fields have not been calculated in the Authorization request header. - 8.10.10 Example - Multi-Resource Lock Request - - >>Request - - LOCK /webdav/ HTTP/1.1 - Host: webdav.sb.aol.com - Timeout: Infinite, Second-4100000000 - Depth: infinity - Content-Type: text/xml; charset="utf-8" - Content-Length: xxxx - Authorization: Digest username="ejw", - realm="ejw@webdav.sb.aol.com", nonce="...", - uri="/workspace/webdav/proposal.doc", - response="...", opaque="..." - - - - - - - http://www.ics.uci.edu/~ejw/contact.html - - - - >>Response - - HTTP/1.1 207 Multi-Status - Content-Type: text/xml; charset="utf-8" - Content-Length: xxxx - - - - - http://webdav.sb.aol.com/webdav/secret - HTTP/1.1 403 Forbidden - - - http://webdav.sb.aol.com/webdav/ - - - HTTP/1.1 424 Failed Dependency - - - - - This example shows a request for an exclusive write lock on a - collection and all its children. In this request, the client has - specified that it desires an infinite length lock, if available, - otherwise a timeout of 4.1 billion seconds, if available. The request - entity body contains the contact information for the principal taking - out the lock, in this case a web page URL. - - The error is a 403 (Forbidden) response on the resource - http://webdav.sb.aol.com/webdav/secret. Because this resource could - not be locked, none of the resources were locked. Note also that the - lockdiscovery property for the Request-URI has been included as - required. In this example the lockdiscovery property is empty which - means that there are no outstanding locks on the resource. - - In this example, the nonce, response, and opaque fields have not been - calculated in the Authorization request header. - 8.11 UNLOCK Method The UNLOCK method removes the lock identified by the lock token in --- New Text --- opaque fields have not been calculated in the Authorization request header. 8.11 UNLOCK Method The UNLOCK method removes the lock identified by the lock token in *** Original Text *** In this example, the lock identified by the lock token "opaquelocktoken:a515cfa4-5da4-22e1-f5b5-00a0451e6bf7" is successfully removed from the resource ! http://webdav.sb.aol.com/workspace/webdav/info.doc. If this lock ! included more than just one resource, the lock is removed from all ! resources included in the lock. The 204 (No Content) status code is used instead of 200 (OK) because there is no response entity body. In this example, the nonce, response, and opaque fields have not been calculated in the Authorization request header. --- New Text --- In this example, the lock identified by the lock token "opaquelocktoken:a515cfa4-5da4-22e1-f5b5-00a0451e6bf7" is successfully removed from the resource ! http://webdav.sb.aol.com/workspace/webdav/info.doc. ! The 204 (No Content) status code is used instead of 200 (OK) because there is no response entity body. In this example, the nonce, response, and opaque fields have not been calculated in the Authorization request header. *** Original Text *** --- New Text --- 9.3 Target-Selector Header Target-Selector = The Target-Selector header specifies the URI of a lock token. When a Target-Selector header is present, the resource identifed by the request-URL will be the resource identified by that URL when the lock was issued, which may be different from resource currently identified by that URL. *** Original Text *** Namespace: DAV: Purpose: Describes a lock on a resource. ! 12.1.2 locktoken XML Element --- New Text --- Namespace: DAV: Purpose: Describes a lock on a resource. ! 12.1.2 locktoken XML Element *** Original Text *** Purpose: Defines the types of locks that can be used with the resource. ! 12.6 lockinfo XML Element --- New Text --- Purpose: Defines the types of locks that can be used with the resource. ! 12.6 lockinfo XML Element *** Original Text *** Purpose: The lockinfo XML element is used with a LOCK method to specify the type of lock the client wishes to have created. ! ! ! 12.7 lockscope XML Element ! ! Name: lockscope ! Namespace: DAV: ! Purpose: Specifies whether a lock is an exclusive lock, or a ! shared lock. ! ! ! ! 12.7.1 exclusive XML Element ! ! Name: exclusive ! Namespace: DAV: ! Purpose: Specifies an exclusive lock ! ! ! ! 12.7.2 shared XML Element ! ! Name: shared ! Namespace: DAV: ! Purpose: Specifies a shared lock ! ! 12.8 locktype XML Element --- New Text --- Purpose: The lockinfo XML element is used with a LOCK method to specify the type of lock the client wishes to have created. ! 12.8 locktype XML Element *** Original Text *** - - 0 Jane Smith Infinite --- New Text --- Jane Smith Infinite *** Original Text *** ! This resource has a single exclusive write lock on it, with an infinite timeout. 13.11 supportedlock Property --- New Text --- ! This resource has a write lock on it, with an infinite timeout. 13.11 supportedlock Property *** Original Text *** - - --- New Text --- From w3c-dist-auth-request@w3.org Thu Oct 7 13:21: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 NAA21288 for ; Thu, 7 Oct 1999 13:21:39 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id NAA01818; Thu, 7 Oct 1999 13:10:14 -0400 (EDT) Resent-Date: Thu, 7 Oct 1999 13:10:14 -0400 (EDT) Resent-Message-Id: <199910071710.NAA01818@www19.w3.org> Date: Thu, 7 Oct 1999 13:10:06 -0400 Message-Id: <9910071710.AA15858@tantalum> From: "Geoffrey M. Clemm" To: w3c-dist-auth@w3.org In-Reply-To: <1999Oct07.114800.1250.1345137@otismtp.ott.oti.com> (Tim_Ellison@oti.com) Subject: Re: href element interpretation Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3416 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: Tim_Ellison@oti.com (Tim Ellison OTT) Please can someone confirm that when a server responds with an element (RFC2518 section 12.3) containing a relative URI, the base URI will always be the retrieval URI (RFC 2396 section 5.1.3) (i.e. the Request-URI). All the examples in RFC2518 seem to return absolute-URIs. RFC-2518 is broken in this regard. It says that: A collection is a resource whose state consists of at least a list of internal member URIs ... the internal member URI is equal to a containing collection's URI plus an additional segment for non- collection resources, or additional segment plus trailing slash "/" for collection resources, where segment is defined in section 3.3 of [RFC2396]. This means that the "state" of a collection varies according to which URI you use to reference it. It *should* have said: ... the internal member URI is a relative URI equal to "./" plus an additional segment for non-collection resources,... Until that bug is fixed, I believe the consensus is that the href should be relative to the retrieval URI. Judy: This is something we need to mention in the Bindings protocol as a bug in 2518 that needs to be fixed. Cheers, Geoff From w3c-dist-auth-request@w3.org Thu Oct 7 13:24: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 NAA21323 for ; Thu, 7 Oct 1999 13:24:00 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id NAA01496; Thu, 7 Oct 1999 13:08:44 -0400 (EDT) Resent-Date: Thu, 7 Oct 1999 13:08:44 -0400 (EDT) Resent-Message-Id: <199910071708.NAA01496@www19.w3.org> From: jamsden@us.ibm.com X-Lotus-FromDomain: IBMUS To: w3c-dist-auth@w3.org Message-ID: <85256803.005E24A1.00@d54mta03.raleigh.ibm.com> Date: Thu, 7 Oct 1999 13:09:04 -0400 Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Subject: Re: href element interpretation Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3415 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list I think the spec silent about this, and the clients are free to interpert the relative URLs as they wish. Your suggestion is a most reasonable interpretation.. Tim_Ellison@oti.com (Tim Ellison OTT) on 10/07/99 11:51:04 AM To: w3c-dist-auth@w3.org (w3c-dist-auth) cc: Subject: href element interpretation Please can someone confirm that when a server responds with an element (RFC2518 section 12.3) containing a relative URI, the base URI will always be the retrieval URI (RFC 2396 section 5.1.3) (i.e. the Request-URI). All the examples in RFC2518 seem to return absolute-URIs. Thanks Tim From w3c-dist-auth-request@w3.org Thu Oct 7 14:30: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 OAA23254 for ; Thu, 7 Oct 1999 14:30:52 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id OAA05843; Thu, 7 Oct 1999 14:19:35 -0400 (EDT) Resent-Date: Thu, 7 Oct 1999 14:19:35 -0400 (EDT) Resent-Message-Id: <199910071819.OAA05843@www19.w3.org> Date: Thu, 7 Oct 1999 11:19:05 -0700 Message-ID: <137-Thu07Oct1999111905-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: <9910071639.AA15825@tantalum> References: <9910071639.AA15825@tantalum> Subject: RE: Simplifying RFC-2518 Locking: A non-proposal Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3417 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 gmc> My non-proposal is as follows: Modify RFC-2518 to: gmc> - remove depth locks, shared locks, and lock null resources gmc> - add a Target-Selector header for reliable access to a locked resource gmc> - make simple single resource locking mandantory. "Stop it ... You're getting me *hot*! :-)" -- Server implementers everywhere -- 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 Thu Oct 7 17:51: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 RAA25955 for ; Thu, 7 Oct 1999 17:51:29 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id RAA12077; Thu, 7 Oct 1999 17:40:02 -0400 (EDT) Resent-Date: Thu, 7 Oct 1999 17:40:02 -0400 (EDT) Resent-Message-Id: <199910072140.RAA12077@www19.w3.org> From: ccjason@us.ibm.com X-Lotus-FromDomain: IBMUS To: w3c-dist-auth@w3.org Message-ID: <85256803.0076FBA8.00@D51MTA03.pok.ibm.com> Date: Thu, 7 Oct 1999 17:44:37 -0400 Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Subject: Re: PROPPATCH Error minimization Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3418 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list Say we invoke PROPATCH so that it sets property1 and property2 on resourceX. if both of these return an error, I believe we are allowed to return... ... resourceX HTTP/1.1 409 Conflict ... but are we allowed to skip the PROP tag if all of the element have the same result?... ... resourceX HTTP/1.1 409 Conflict ... And are we allowed to skip the PROPSTAT altogether and just return a status for the URI?... ... resourceX HTTP/1.1 409 Conflict ... Or even return it in the response header? Does this change if the response code is "200 OK" rather than 4XX? If the spec doesn't already do so, it should provide a guideline here so that clients know all the possibilities to expect and can code for them. J. ------------------------------------------ Phone: 914-784-7569, ccjason@us.ibm.com From w3c-dist-auth-request@w3.org Thu Oct 7 19:44: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 TAA27036 for ; Thu, 7 Oct 1999 19:43:59 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id TAA14043; Thu, 7 Oct 1999 19:32:05 -0400 (EDT) Resent-Date: Thu, 7 Oct 1999 19:32:05 -0400 (EDT) Resent-Message-Id: <199910072332.TAA14043@www19.w3.org> From: Jim Whitehead To: WebDAV WG Date: Thu, 7 Oct 1999 16:31:32 -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: Adv. Col. TeleConf minutes Oct. 6, 1999 Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3419 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 from the October 6, 1999 Advanced Collections teleconference are now available at: http://www.ics.uci.edu/pub/ietf/webdav/collection/dt/Minutes991006.txt Many thanks to Judy Slein for organizing the teleconference, and recording the minutes! Additionally, minutes from the past several teleconferences are also available on the WebDAV WG web site: http://www.ics.uci.edu/pub/ietf/webdav/collection/dt/Minutes990914.txt http://www.ics.uci.edu/pub/ietf/webdav/collection/dt/Minutes990921.txt http://www.ics.uci.edu/pub/ietf/webdav/collection/dt/Minutes990929.txt - Jim From w3c-dist-auth-request@w3.org Thu Oct 7 20:12: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 UAA27331 for ; Thu, 7 Oct 1999 20:12:09 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id UAA14471; Thu, 7 Oct 1999 20:00:31 -0400 (EDT) Resent-Date: Thu, 7 Oct 1999 20:00:31 -0400 (EDT) Resent-Message-Id: <199910080000.UAA14471@www19.w3.org> From: Jim Whitehead To: w3c-dist-auth Date: Thu, 7 Oct 1999 16:59: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) In-Reply-To: <1999Oct07.114800.1250.1345137@otismtp.ott.oti.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Importance: Normal Subject: RE: href element interpretation Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3420 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 Our original intent was to use the algorithm described in Section 5.1 "Establishing a Base URI" of RFC 2376 ("Uniform Resource Identifiers (URI): Generic Syntax") . In particular, the language in Section 5.1.3, "Base URI from the Retrieval URI" applies most to WebDAV. Or, in short, I agree with your interpretation. :-) - Jim > > Please can someone confirm that when a server responds with an > element (RFC2518 section 12.3) containing a relative URI, the > base URI will > always be the retrieval URI (RFC 2396 section 5.1.3) (i.e. the > Request-URI). > > All the examples in RFC2518 seem to return absolute-URIs. > > Thanks > Tim > From w3c-dist-auth-request@w3.org Thu Oct 7 20:57: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 UAA27724 for ; Thu, 7 Oct 1999 20:57:56 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id UAA15221; Thu, 7 Oct 1999 20:46:05 -0400 (EDT) Resent-Date: Thu, 7 Oct 1999 20:46:05 -0400 (EDT) Resent-Message-Id: <199910080046.UAA15221@www19.w3.org> From: jamsden@us.ibm.com X-Lotus-FromDomain: IBMUS To: w3c-dist-auth@w3.org Message-ID: <85256804.00042D53.00@d54mta03.raleigh.ibm.com> Date: Thu, 7 Oct 1999 20:42:36 -0400 Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Subject: Re: PROPPATCH Error minimization Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3421 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list According to the WebDAV DTD, prop and status are required, and a multistatus must have at least one response. The optimizations you describe look good, but the really complicate client implementations. ccjason@us.ibm.com on 10/07/99 05:44:37 PM To: w3c-dist-auth@w3.org cc: Subject: Re: PROPPATCH Error minimization Say we invoke PROPATCH so that it sets property1 and property2 on resourceX. if both of these return an error, I believe we are allowed to return... ... resourceX HTTP/1.1 409 Conflict ... but are we allowed to skip the PROP tag if all of the element have the same result?... ... resourceX HTTP/1.1 409 Conflict ... And are we allowed to skip the PROPSTAT altogether and just return a status for the URI?... ... resourceX HTTP/1.1 409 Conflict ... Or even return it in the response header? Does this change if the response code is "200 OK" rather than 4XX? If the spec doesn't already do so, it should provide a guideline here so that clients know all the possibilities to expect and can code for them. J. ------------------------------------------ Phone: 914-784-7569, ccjason@us.ibm.com From w3c-dist-auth-request@w3.org Fri Oct 8 08:07: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 IAA16430 for ; Fri, 8 Oct 1999 08:07:04 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id HAA24209; Fri, 8 Oct 1999 07:53:26 -0400 (EDT) Resent-Date: Fri, 8 Oct 1999 07:53:26 -0400 (EDT) Resent-Message-Id: <199910081153.HAA24209@www19.w3.org> Date: Fri, 8 Oct 1999 07:53:16 -0400 Message-Id: <9910081153.AA16305@tantalum> From: "Geoffrey M. Clemm" To: w3c-dist-auth@w3.org In-Reply-To: <85256804.00042D53.00@d54mta03.raleigh.ibm.com> (jamsden@us.ibm.com) Subject: Re: PROPPATCH Error minimization Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3422 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 suggest we just make it clear that these optimizations are not allowed. They save some bandwidth over the wire, but would complicate both server and client implementations. Cheers, Geoff From: jamsden@us.ibm.com According to the WebDAV DTD, prop and status are required, and a multistatus must have at least one response. The optimizations you describe look good, but the really complicate client implementations. ccjason@us.ibm.com on 10/07/99 05:44:37 PM To: w3c-dist-auth@w3.org cc: Subject: Re: PROPPATCH Error minimization Say we invoke PROPATCH so that it sets property1 and property2 on resourceX. if both of these return an error, I believe we are allowed to return... ... resourceX HTTP/1.1 409 Conflict ... but are we allowed to skip the PROP tag if all of the element have the same result?... ... resourceX HTTP/1.1 409 Conflict ... And are we allowed to skip the PROPSTAT altogether and just return a status for the URI?... ... resourceX HTTP/1.1 409 Conflict ... Or even return it in the response header? Does this change if the response code is "200 OK" rather than 4XX? If the spec doesn't already do so, it should provide a guideline here so that clients know all the possibilities to expect and can code for them. J. ------------------------------------------ Phone: 914-784-7569, ccjason@us.ibm.com From w3c-dist-auth-request@w3.org Sat Oct 9 05:19: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 FAA18520 for ; Sat, 9 Oct 1999 05:19:55 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id FAA17816; Sat, 9 Oct 1999 05:06:58 -0400 (EDT) Resent-Date: Sat, 9 Oct 1999 05:06:58 -0400 (EDT) Resent-Message-Id: <199910090906.FAA17816@www19.w3.org> From: ccjason@us.ibm.com X-Lotus-FromDomain: IBMUS To: "Geoffrey M. Clemm" cc: w3c-dist-auth@w3.org Message-ID: <85256804.006E393E.00@D51MTA03.pok.ibm.com> Date: Fri, 8 Oct 1999 16:08:53 -0400 Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Subject: Re: PROPPATCH Error minimization Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3423 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list http://lists.w3.org/Archives/Public/w3c-dist-auth/1999OctDec/0013.html I'd suggest we just make it clear that these optimizations are not allowed. They save some bandwidth over the wire, but would complicate both server and client implementations. All of them? Even if "200 OK"? Do we have consensus? ------------------------------------------ Phone: 914-784-7569, ccjason@us.ibm.com From w3c-dist-auth-request@w3.org Mon Oct 11 04:02: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 EAA25497 for ; Mon, 11 Oct 1999 04:02:41 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id DAA16330; Mon, 11 Oct 1999 03:50:09 -0400 (EDT) Resent-Date: Mon, 11 Oct 1999 03:50:09 -0400 (EDT) Resent-Message-Id: <199910110750.DAA16330@www19.w3.org> Date: Mon, 11 Oct 1999 00:49:27 -0700 (PDT) From: Greg Stein To: w3c-dist-auth@w3.org In-Reply-To: <9910071710.AA15858@tantalum> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: Re: href element interpretation Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3424 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, 7 Oct 1999, Geoffrey M. Clemm wrote: >... > This means that the "state" of a collection varies according to > which URI you use to reference it. It *should* have said: > > ... the internal member URI is a relative URI equal to "./" > plus an additional segment for non-collection resources,... > > Until that bug is fixed, I believe the consensus is that the > href should be relative to the retrieval URI. This is the position that mod_dav takes. It has been argued in the past that the element should only contain an absoluteURI. I'm not sure that I agree with that position, though. Cheers, -g -- Greg Stein, http://www.lyra.org/ From w3c-dist-auth-request@w3.org Mon Oct 11 04:44: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 EAA25699 for ; Mon, 11 Oct 1999 04:44:51 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id EAA16983; Mon, 11 Oct 1999 04:32:52 -0400 (EDT) Resent-Date: Mon, 11 Oct 1999 04:32:52 -0400 (EDT) Resent-Message-Id: <199910110832.EAA16983@www19.w3.org> Date: Mon, 11 Oct 1999 01:32:33 -0700 (PDT) From: Greg Stein To: ccjason@us.ibm.com cc: w3c-dist-auth@w3.org In-Reply-To: <85256804.006E393E.00@D51MTA03.pok.ibm.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: Re: PROPPATCH Error minimization Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3425 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 Fri, 8 Oct 1999 ccjason@us.ibm.com wrote: > > I'd suggest we just make it clear that these > optimizations are not allowed. They save some > bandwidth over the wire, but would complicate both server and client > implementations. > > > All of them? > Even if "200 OK"? > Do we have consensus? Stripping the response down to just a "200 OK" from a multistatus would be a Serious Pain. I'd vote against this kind of response compression. Cheers, -g -- Greg Stein, http://www.lyra.org/ From w3c-dist-auth-request@w3.org Mon Oct 11 09:48: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 JAA03431 for ; Mon, 11 Oct 1999 09:48:49 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id JAA20104; Mon, 11 Oct 1999 09:20:07 -0400 (EDT) Resent-Date: Mon, 11 Oct 1999 09:20:07 -0400 (EDT) Resent-Message-Id: <199910111320.JAA20104@www19.w3.org> From: ccjason@us.ibm.com X-Lotus-FromDomain: IBMUS To: Greg Stein cc: w3c-dist-auth@w3.org Message-ID: <85256807.00493862.00@D51MTA03.pok.ibm.com> Date: Mon, 11 Oct 1999 09:24:11 -0400 Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Subject: Re: PROPPATCH Error minimization Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3426 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list >> Stripping the response down to just a "200 OK" from a multistatus would be a Serious Pain. >> Note: This would be a client's responsibility and the client might already require that it first determine if there are any errors before it actually processes them individually. In that case, the minimization code would need to be there anyway. DAV4J already has this in the client code... but it's nice to define what minimizations are allowed to deal with the code that iterates through the errors... which might be expressed in various ways... and perhaps some that the coder hasn't thought of... unless we limit the possibilities. > I'd vote against this kind of response compression. That's 2 - 0 against minimization so far. It sounds like both votes are against any minimizations. Anyone else? From w3c-dist-auth-request@w3.org Mon Oct 11 14:43: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 OAA11707 for ; Mon, 11 Oct 1999 14:43:48 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id OAA26467; Mon, 11 Oct 1999 14:12:27 -0400 (EDT) Resent-Date: Mon, 11 Oct 1999 14:12:27 -0400 (EDT) Resent-Message-Id: <199910111812.OAA26467@www19.w3.org> Date: Mon, 11 Oct 1999 11:11:44 -0700 Message-ID: <3033-Mon11Oct1999111144-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: <85256804.006E393E.00@D51MTA03.pok.ibm.com> Subject: Re: PROPPATCH Error minimization Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3427 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 gs> Stripping the response down to just a "200 OK" from a multistatus gs> would be a Serious Pain. I thought we weren't talking about a mandatory conversion. I can see how doing that could be tricky for some server set-ups. However, I don't think this specific case would be much trouble for client implementors. (It doesn't really simplify anything either, since the client has to be prepared for the non-simplified case anyhow.) -- 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 Mon Oct 11 16:20: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 QAA14186 for ; Mon, 11 Oct 1999 16:20:45 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id PAA00158; Mon, 11 Oct 1999 15:53:05 -0400 (EDT) Resent-Date: Mon, 11 Oct 1999 15:53:05 -0400 (EDT) Resent-Message-Id: <199910111953.PAA00158@www19.w3.org> From: jamsden@us.ibm.com X-Lotus-FromDomain: IBMUS To: w3c-dist-auth@w3.org Message-ID: <85256807.006D2925.00@d54mta03.raleigh.ibm.com> Date: Mon, 11 Oct 1999 15:50:51 -0400 Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Subject: LOCK and UNLOCK methods Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3428 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 spec (version 10) doesn't exactly say that LOCK and UNLOCK methods return. Section 8.10.4 says a LOCK method returns a DAV:multistatus in the case where the LOCK fails, but does not say what is returned in the normal case. The examples show a DAV:prop element containing the lock discovery, but this is never stated as the output. If the lock is a depth infinity lock, is a multi status returned containing the lock discovery for all the locked elements (they may be different because some of them may have other shared locks). DAV4J does this, but I'm not sure it is correct. UNLOCK does not define what it returns. DAV4J returns the same thing LOCK returns, a prop element containing the lock discovery, or a multistatus if there was an error, or many items unlocked. This is not consistent with the example in the spec which has no entity response body. Could someone clarify what these methods are supposed to return, and update the spec accordingly. Thanks. From w3c-dist-auth-request@w3.org Tue Oct 12 09:49: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 JAA14876 for ; Tue, 12 Oct 1999 09:49:32 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id JAA24433; Tue, 12 Oct 1999 09:36:36 -0400 (EDT) Resent-Date: Tue, 12 Oct 1999 09:36:36 -0400 (EDT) Resent-Message-Id: <199910121336.JAA24433@www19.w3.org> From: Tim_Ellison@oti.com (Tim Ellison OTT) To: ccjason@us.ibm.com (ccjason), w3c-dist-auth@w3.org (w3c-dist-auth) Message-ID: <1999Oct12.093200.1250.1348966@otismtp.ott.oti.com> X-Mailer: Microsoft Mail via PostalUnion/SMTP for Windows NT Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Organization: Object Technology International Inc Date: Tue, 12 Oct 1999 09:34:48 -0400 Subject: Re: PROPPATCH Error minimization Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3429 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 cast my vote against error minimization for the same reasons that Bill describes below. Tim ---------- >From: WJCarpenter >To: w3c-dist-auth >Subject: Re: PROPPATCH Error minimization >Date: Monday, October 11, 1999 2:14PM > >gs> Stripping the response down to just a "200 OK" from a multistatus >gs> would be a Serious Pain. > >I thought we weren't talking about a mandatory conversion. I can see >how doing that could be tricky for some server set-ups. However, I >don't think this specific case would be much trouble for client >implementors. (It doesn't really simplify anything either, since the >client has to be prepared for the non-simplified case anyhow.) >-- >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 Oct 12 11:30: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 LAA18730 for ; Tue, 12 Oct 1999 11:30:11 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id LAA29416; Tue, 12 Oct 1999 11:16:37 -0400 (EDT) Resent-Date: Tue, 12 Oct 1999 11:16:37 -0400 (EDT) Resent-Message-Id: <199910121516.LAA29416@www19.w3.org> From: Tim_Ellison@oti.com (Tim Ellison OTT) To: w3c-dist-auth@w3.org (w3c-dist-auth) Message-ID: <1999Oct12.111300.1250.1349140@otismtp.ott.oti.com> X-Mailer: Microsoft Mail via PostalUnion/SMTP for Windows NT Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Organization: Object Technology International Inc Date: Tue, 12 Oct 1999 11:16:00 -0400 Subject: RE: WebDAV DTD Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3430 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list Is there any support within the group for this change to the DTD? Without it I fail to see how clients can receive large properties without inhaling the entire contents. Tim -----Original Message----- From: Tim Ellison OTT [mailto:Tim_Ellison@oti.com] Sent: Monday, October 04, 1999 12:48 PM To: w3c-dist-auth Subject: [Moderator Action] WebDAV DTD One rule in the DTD states: I suggest that this is modified to read so that streaming clients can retrieve the status of a property before they retireve the property itself , and thereby know whether the data is valid or not. In the current rule, such a client is required to read the prop data in its entirety, possibly to discover that the data is invalid only after the fact. Comments? From w3c-dist-auth-request@w3.org Tue Oct 12 13:27:34 1999 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22265 for ; Tue, 12 Oct 1999 13:27:34 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id NAA04939; Tue, 12 Oct 1999 13:15:28 -0400 (EDT) Resent-Date: Tue, 12 Oct 1999 13:15:28 -0400 (EDT) Resent-Message-Id: <199910121715.NAA04939@www19.w3.org> From: jamsden@us.ibm.com X-Lotus-FromDomain: IBMUS To: w3c-dist-auth@w3.org Message-ID: <85256808.005EBF24.00@d54mta03.raleigh.ibm.com> Date: Tue, 12 Oct 1999 13:12:50 -0400 Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Subject: RE: WebDAV DTD Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3431 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list Seems OK to me. Tim_Ellison@oti.com (Tim Ellison OTT) on 10/12/99 11:16:00 AM To: w3c-dist-auth@w3.org (w3c-dist-auth) cc: Subject: RE: WebDAV DTD Is there any support within the group for this change to the DTD? Without it I fail to see how clients can receive large properties without inhaling the entire contents. Tim -----Original Message----- From: Tim Ellison OTT [mailto:Tim_Ellison@oti.com] Sent: Monday, October 04, 1999 12:48 PM To: w3c-dist-auth Subject: [Moderator Action] WebDAV DTD One rule in the DTD states: I suggest that this is modified to read so that streaming clients can retrieve the status of a property before they retireve the property itself , and thereby know whether the data is valid or not. In the current rule, such a client is required to read the prop data in its entirety, possibly to discover that the data is invalid only after the fact. Comments? From w3c-dist-auth-request@w3.org Tue Oct 12 16:26: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 QAA25980 for ; Tue, 12 Oct 1999 16:26:36 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id QAA14048; Tue, 12 Oct 1999 16:14:28 -0400 (EDT) Resent-Date: Tue, 12 Oct 1999 16:14:28 -0400 (EDT) Resent-Message-Id: <199910122014.QAA14048@www19.w3.org> From: Jim Whitehead To: w3c-dist-auth Date: Tue, 12 Oct 1999 13:13:41 -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: <1999Oct12.111300.1250.1349140@otismtp.ott.oti.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Subject: RE: WebDAV DTD Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3432 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 > Is there any support within the group for this change to the DTD? > > Without it I fail to see how clients can receive large properties without > inhaling the entire contents. A couple of responses. First, it was never our intent for the ordering of XML elements given in the DAV DTD to be normative, and this was one of the reasons we specified that XML in DAV is only well formed, and is not required to meet the more stringent validity requirements. However, we should be more explicit about this intent in the spec., since someone reading the DTD would certainly get the impression that the ordering there is normative. So, answer #1 is that you already have permission to make the change you suggested in your code. > One rule in the DTD states: > > > I suggest that this is modified to read > > > so that streaming clients can retrieve the status of a property > before they retireve the property itself , and thereby know whether the data > is valid or not. In the current rule, such a client is required to read the prop data > in its entirety, possibly to discover that the data is invalid only after > the fact. That said, I don't find this to be a particularly compelling argument. In general you'll need to parse the entire propstat block anyway just so you can find its end. And, clients will need to be able to accept either ordering, since there are existing servers that send the data as prop, status, responsedescription. So, I'm not sure what benefit this change gains you. - Jim From w3c-dist-auth-request@w3.org Tue Oct 12 16:42: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 QAA26261 for ; Tue, 12 Oct 1999 16:42:19 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id QAA14326; Tue, 12 Oct 1999 16:30:16 -0400 (EDT) Resent-Date: Tue, 12 Oct 1999 16:30:16 -0400 (EDT) Resent-Message-Id: <199910122030.QAA14326@www19.w3.org> Message-ID: <38039A30.7BB3DD9F@ecal.com> Date: Tue, 12 Oct 1999 16:29: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 References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: WebDAV DTD Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3433 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list Content-Transfer-Encoding: 7bit Jim Whitehead wrote: > > One rule in the DTD states: > > > > > > I suggest that this is modified to read > > > > > > so that streaming clients can retrieve the status of a property > > before they retireve the property itself , and thereby know whether the > data > > is valid or not. In the current rule, such a client is required to read > the prop data > > in its entirety, possibly to discover that the data is invalid only after > > the fact. > > That said, I don't find this to be a particularly compelling argument. In > general you'll need to parse the entire propstat block anyway just so you > can find its end. And, clients will need to be able to accept either > ordering, since there are existing servers that send the data as prop, > status, responsedescription. So, I'm not sure what benefit this change gains > you. The benefit is that, if the client sees the status first, and knows the operation failed, then it can avoid buffering the contents of the prop element. With an existing server, the only problem would be that it would have to buffer all the time. Uh...but now I'm wondering whether this actually makes sense. Is there any case where the operation failed but you get a prop with an actual value in it? -- /==============================================================\ |John Stracke | http://www.ecal.com |My opinions are my own.| |Chief Scientist |=============================================| |eCal Corp. |But this one goes to 11x. | |francis@ecal.com| | \==============================================================/ From w3c-dist-auth-request@w3.org Tue Oct 12 17:11: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 RAA26830 for ; Tue, 12 Oct 1999 17:11:24 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id QAA14706; Tue, 12 Oct 1999 16:59:56 -0400 (EDT) Resent-Date: Tue, 12 Oct 1999 16:59:56 -0400 (EDT) Resent-Message-Id: <199910122059.QAA14706@www19.w3.org> From: Tim_Ellison@oti.com (Tim Ellison OTT) To: francis@ecal.com (John Stracke), w3c-dist-auth@w3.org (w3c-dist-auth) Message-ID: <1999Oct12.165535.1250.1349828@otismtp.ott.oti.com> X-Mailer: Microsoft Mail via PostalUnion/SMTP for Windows NT Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Organization: Object Technology International Inc Date: Tue, 12 Oct 1999 16:55:55 -0400 Subject: Re: WebDAV DTD Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3434 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 benefit is that, if the client sees the status first, and knows >the operation failed, then it can avoid buffering the contents of >the prop element. With an existing server, the only problem >would be that it would have to buffer all the time. Exactly -- I can see it now, some bright spark chooses to store a hunk of video in a property ... or a long live property ... >Uh...but now I'm wondering whether this actually makes sense. >Is there any case where the operation failed but you get a prop >with an actual value in it? The only cases that seem to make sense to me are those where the server manages to retrieve partial content before the error occurs. Presumably these would result in error code (500 Internal Server Error). Tim ---------- >From: John Stracke >To: w3c-dist-auth >Subject: Re: WebDAV DTD >Date: Tuesday, October 12, 1999 4:32PM > ><> >Jim Whitehead wrote: > >> > One rule in the DTD states: >> > >> > >> > I suggest that this is modified to read >> > >> > >> > so that streaming clients can retrieve the status of a property >> > before they retireve the property itself , and thereby know whether the >> data >> > is valid or not. In the current rule, such a client is required to read >> the prop data >> > in its entirety, possibly to discover that the data is invalid only after >> > the fact. >> >> That said, I don't find this to be a particularly compelling argument. In >> general you'll need to parse the entire propstat block anyway just so you >> can find its end. And, clients will need to be able to accept either >> ordering, since there are existing servers that send the data as prop, >> status, responsedescription. So, I'm not sure what benefit this change gains >> you. > >The benefit is that, if the client sees the status first, and knows the >operation failed, then it can avoid buffering the contents of the prop >element. With an existing server, the only problem would be that it would >have >to buffer all the time. > >Uh...but now I'm wondering whether this actually makes sense. Is there any >case where the operation failed but you get a prop with an actual value in it? > >-- >/==============================================================\ >|John Stracke | http://www.ecal.com |My opinions are my own.| >|Chief Scientist |=============================================| >|eCal Corp. |But this one goes to 11x. | >|francis@ecal.com| | >\==============================================================/ > > > > From w3c-dist-auth-request@w3.org Tue Oct 12 18:13: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 SAA27879 for ; Tue, 12 Oct 1999 18:13:27 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id RAA15723; Tue, 12 Oct 1999 17:58:48 -0400 (EDT) Resent-Date: Tue, 12 Oct 1999 17:58:48 -0400 (EDT) Resent-Message-Id: <199910122158.RAA15723@www19.w3.org> From: Jim Whitehead To: w3c-dist-auth Date: Tue, 12 Oct 1999 14:58:02 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <1999Oct12.165535.1250.1349828@otismtp.ott.oti.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Subject: RE: WebDAV DTD Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3435 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 Um, wait a minute, this still doesn't make sense. If a server uses your recommended oredering for the propstat XML element and sends the status first, then starts streaming data out of its property store, and then detects an error ... there's no way to put that error into the response, since you've already sent the status, right? Assuming the server isn't streaming the data out doesn't work either -- if the server reads the entire property out before marshalling the response, then it can detect ahead of time that there was an error, and just not send any information at all for the property, thereby avoiding the case that motivates the ordering change in propstat. > >Uh...but now I'm wondering whether this actually makes sense. > >Is there any case where the operation failed but you get a prop > >with an actual value in it? > > The only cases that seem to make sense to me are those where the server > manages to retrieve partial content before the error occurs. Presumably > these would result in error code (500 Internal Server Error). > > >> > One rule in the DTD states: > >> > > >> > > >> > I suggest that this is modified to read > >> > > >> > - Jim From w3c-dist-auth-request@w3.org Tue Oct 12 19:08: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 TAA28481 for ; Tue, 12 Oct 1999 19:08:39 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id SAA16795; Tue, 12 Oct 1999 18:57:13 -0400 (EDT) Resent-Date: Tue, 12 Oct 1999 18:57:13 -0400 (EDT) Resent-Message-Id: <199910122257.SAA16795@www19.w3.org> From: Jim Whitehead To: WebDAV WG Date: Tue, 12 Oct 1999 15:56:27 -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: IETF meeting: Monday, 1930-2200 Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3436 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 At present, the WebDAV WG meeting at the Washington, DC IETF has been scheduled for Monday, November 8, 1999, from 7:30PM - 10:00PM. Since I received some schedule preferences for holding the meeting later in the week, I'll ask Keith and Patrik to see if we can be switched to Wednesday or Thursday, but I'm not going to hold my breath for a change. - Jim From w3c-dist-auth-request@w3.org Tue Oct 12 19:12: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 TAA28549 for ; Tue, 12 Oct 1999 19:12:17 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id TAA16990; Tue, 12 Oct 1999 19:00:42 -0400 (EDT) Resent-Date: Tue, 12 Oct 1999 19:00:42 -0400 (EDT) Resent-Message-Id: <199910122300.TAA16990@www19.w3.org> From: ccjason@us.ibm.com X-Lotus-FromDomain: IBMUS To: w3c-dist-auth@w3.org Message-ID: <85256808.007E5D9F.00@D51MTA03.pok.ibm.com> Date: Tue, 12 Oct 1999 19:04:54 -0400 Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Subject: Re: PROPPATCH Error minimization Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3437 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list It looks like "everyone" is against error response minimization for PROPPATCH. Can we get this listed in the spec? How about... Was... 8.2.1 Status Codes for use with 207 (Multi-Status) The following are examples of response codes one would expect to be used in a 207 (Multi-Status) response for this method. Note, however, that unless explicitly prohibited any 2/3/4/5xx series response code may be used in a 207 (Multi-Status) response. Insert before the first paragarph.... The response to a PROPPATCH SHOULD always be 207 (Multi-Status). No error minimization should be performed... even if all of the set and remove operations succeeded. This even applies to 200 (OK) response codes. I said SHOULD and not MUST because of protocol situations... like the resource isn't found. Am I correct? Or is it *always* going to be Multistatus? The problem I have with the above phrasing is that it might make it sounds like the following error minimization isn't allowed and I suspect it is... HTTP/1.1 403 Forbidden The user does not have access to the DingALing property. Are we prepared to eliminate this minimization? (I am.) Also note... if we say there is no minimization... that means even if the PROPPATCH had to back out everything due to one error, the response will still need to list all those 200's along with the single error that occured. Does it sound fine to outlaw the elmination of those 200's? And a tangent... Also, we don't say if a proppatch request can set a property several times. I guess it's implicit that it can. That does make for somewhat more complex server response generating code... unless we're going to allow each properties to generate more than one response if altered multiple times. Comments? J. From w3c-dist-auth-request@w3.org Wed Oct 13 05:06: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 FAA16477 for ; Wed, 13 Oct 1999 05:06:24 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id EAA24663; Wed, 13 Oct 1999 04:54:03 -0400 (EDT) Resent-Date: Wed, 13 Oct 1999 04:54:03 -0400 (EDT) Resent-Message-Id: <199910130854.EAA24663@www19.w3.org> Date: Wed, 13 Oct 1999 10:52:49 +0200 (MESZ) From: Edgar Schwarz X-Sender: Edgar.Schwarz@hpmx15.bk.bosch.de To: w3c-dist-auth@w3.org In-Reply-To: <137-Thu07Oct1999111905-0700-bill@carpenter.ORG> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: RE: Simplifying RFC-2518 Locking: A non-proposal Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3438 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list Hello, I'm back again after being in hospital for some weeks. It seems there was a hot debate over my proposal which is over now but I still would like to add my $0.02. Thu, 7 Oct 1999 bill@carpenter.ORG wrote: > gmc> My non-proposal is as follows: Modify RFC-2518 to: > gmc> - remove depth locks, shared locks, and lock null resources > gmc> - add a Target-Selector header for reliable access to a locked resource > gmc> - make simple single resource locking mandantory. > > "Stop it ... You're getting me *hot*! :-)" I think the cut is cool :-). You wanted a simpler standard Yaron, so how's this ? BTW, I'm trying to write a client for Oberon (http://www.oberon.ethz.ch) so my decisions aren't important for many people. Nevertheless, FYI I don't plan to spend time for the arcane features Geoff wants to drop (if I can avoid it). I don't think they are worth my time. Then I have a question. Why is a DELETE allowed ? Shouldn't be in my opinion (7.1 Methods Restricted by Write locks). Perhaps this should be clarified so that a DELETE for the locked binding is forbidden but an DELETE on other bindings is allowed. Here is a difference between DELETE and PUT,POST,... Now some global stuff :-) - I think that locks are here to stay in RFC2518, they are on the resource and move with the resource. - Now as a server administrator I absolutely want to be able to move locked resoures if it is necessary. - OTOH as a client I won't tolerate disappearing resources I have locked. - Therefore my proposal that an access to a moved resource (changed binding) with URL and locktoken must give me the new URL (not the resource). So the client can tell his user: Look this stuff has been moved ! And after it is accessed one time the server can drop his note about the move. The client now knows where it has gone to. So I also see no problems with the following scenarios. - Multiple moves: the client only wants to know where it is now. He isn't interested in intermediate bindings. This also should work with inter server moves. A server only has to remember the URL on the other server it is moved to. If there are more moves it's the responsibility of the receiving server to remember. Now Yarons problems: - Being at work, taking a lock: If you want to work at home then you obviously have to remember the lock. Then you can access it at home without any problem with lock and old URL. - Editing HTML in Word, validiating in Netscape: If somebody moves the resource inbetween Netscape won't find it, oops ! You go back to Word and e.g. try to reload the document. Word tells you that it has moved to another location. Then you just have to adapt the URL in Netscape. Not so complex I still think. Cheers, 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 Wed Oct 13 10:25: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 KAA25214 for ; Wed, 13 Oct 1999 10:25:27 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id KAA29205; Wed, 13 Oct 1999 10:13:31 -0400 (EDT) Resent-Date: Wed, 13 Oct 1999 10:13:31 -0400 (EDT) Resent-Message-Id: <199910131413.KAA29205@www19.w3.org> From: Tim_Ellison@oti.com (Tim Ellison OTT) To: ejw@ics.uci.edu (Jim Whitehead), w3c-dist-auth@w3.org (w3c-dist-auth) Message-ID: <1999Oct13.100700.1250.1350607@otismtp.ott.oti.com> X-Mailer: Microsoft Mail via PostalUnion/SMTP for Windows NT Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Organization: Object Technology International Inc Date: Wed, 13 Oct 1999 10:11:24 -0400 Subject: RE: WebDAV DTD Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3439 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're right -- I can't think of a case where there is both an 'a priori' error and data. I'll withdraw my request. Thanks Tim ---------- >From: Jim Whitehead >To: w3c-dist-auth >Subject: RE: WebDAV DTD >Date: Wednesday, October 13, 1999 9:06AM > ><> >Um, wait a minute, this still doesn't make sense. If a server uses your >recommended oredering for the propstat XML element and sends the status >first, then starts streaming data out of its property store, and then >detects an error ... there's no way to put that error into the response, >since you've already sent the status, right? Assuming the server isn't >streaming the data out doesn't work either -- if the server reads the entire >property out before marshalling the response, then it can detect ahead of >time that there was an error, and just not send any information at all for >the property, thereby avoiding the case that motivates the ordering change >in propstat. > >> >Uh...but now I'm wondering whether this actually makes sense. >> >Is there any case where the operation failed but you get a prop >> >with an actual value in it? >> >> The only cases that seem to make sense to me are those where the server >> manages to retrieve partial content before the error occurs. Presumably >> these would result in error code (500 Internal Server Error). >> > >> >> > One rule in the DTD states: >> >> > >> >> > >> >> > I suggest that this is modified to read >> >> > >> >> > > >- Jim > > From w3c-dist-auth-request@w3.org Wed Oct 13 11:20: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 LAA27096 for ; Wed, 13 Oct 1999 11:20:32 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id LAA00716; Wed, 13 Oct 1999 11:08:44 -0400 (EDT) Resent-Date: Wed, 13 Oct 1999 11:08:44 -0400 (EDT) Resent-Message-Id: <199910131508.LAA00716@www19.w3.org> From: Tim_Ellison@oti.com (Tim Ellison OTT) To: ccjason@us.ibm.com (ccjason), w3c-dist-auth@w3.org (w3c-dist-auth) Message-ID: <1999Oct13.110350.1250.1350772@otismtp.ott.oti.com> X-Mailer: Microsoft Mail via PostalUnion/SMTP for Windows NT Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Organization: Object Technology International Inc Date: Wed, 13 Oct 1999 11:05:36 -0400 Subject: RE: PROPPATCH Error minimization Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3440 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list Also note... if we say there is no minimization... that means even if the PROPPATCH had to back out everything due to one error, the response will still need to list all those 200's along with the single error that occured. Does it sound fine to outlaw the elmination of those 200's? If the server backs out changes then the 200's would become 424-Failed Dependency's wouldn't they? Also, we don't say if a proppatch request can set a property several times. I guess it's implicit that it can. That does make for somewhat more complex server response generating code... unless we're going to allow each properties to generate more than one response if altered multiple times. I guess it would. Imagine foo foo foo Since the order of the responses is not guaranteed (i.e. error minimization may rearrange the propstats) I may get foo & foo = Failed Dependency foo = Conflict So which of the update directives generated the conflict? From w3c-dist-auth-request@w3.org Wed Oct 13 12:50: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 MAA29652 for ; Wed, 13 Oct 1999 12:50:21 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id MAA02544; Wed, 13 Oct 1999 12:35:25 -0400 (EDT) Resent-Date: Wed, 13 Oct 1999 12:35:25 -0400 (EDT) Resent-Message-Id: <199910131635.MAA02544@www19.w3.org> From: ccjason@us.ibm.com X-Lotus-FromDomain: IBMUS To: w3c-dist-auth@w3.org (w3c-dist-auth) Message-ID: <85256809.005B0664.00@D51MTA03.pok.ibm.com> Date: Wed, 13 Oct 1999 12:38:49 -0400 Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Subject: resourcetype locknull Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3441 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've noted it in the lock issues list and I suspect Jim already has it in the 2518 issue list, but in the definition section it says that lock-null resources are not listed as children of their parent... and (by omiision) cannot accept UNLOCK and PROPFIND methods. Later in the document it says the opposite. I believe the later information is correct. Based on that assumption and a "problem" I encountered with LOCK support in the Linux version of mod_dav, I'd like to propose "lock-null" as a potential value for the resourcetype property. This will give clients a predictable value there for lock-null resources. What is the "problem" in linux mod_dav? Well it claims that the lock-null resource is a collection. That's not technically incorrect. So I'd like to insure that we specify exactly what is returned for the sake of clients. And it seems like a new value would be appropriate. ------------------------------------------ Phone: 914-784-7569, ccjason@us.ibm.com From w3c-dist-auth-request@w3.org Wed Oct 13 14:00: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 OAA01399 for ; Wed, 13 Oct 1999 14:00:41 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id NAA04243; Wed, 13 Oct 1999 13:46:04 -0400 (EDT) Resent-Date: Wed, 13 Oct 1999 13:46:04 -0400 (EDT) Resent-Message-Id: <199910131746.NAA04243@www19.w3.org> Date: Wed, 13 Oct 1999 13:45:57 -0400 From: gclemm@atria.com (Geoffrey M. Clemm) Message-Id: <9910131745.AA18652@tantalum> To: w3c-dist-auth@w3.org X-Sun-Charset: US-ASCII Subject: Re: resourcetype locknull Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3442 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list Could someone *pleeeassse* tell me what problem "lock null" resources are supposed to solve? I found a message from Yaron dated 3/22/98 where they appear to be introduced by an analogy with the need for "zero" when you are counting. I am not convinced (:-). If you want to "lock" a place where there is no resource, create some dummy resource there and lock that. Currently we're stuck with several paragraphs of verbiage telling us how a lock null resource behaves exactly like a regular resource except that it returns a "404" when you try to get its body. Is that feature so important that it warrants the incremental complexity and confusion that it adds to the spec? I propose that we strike all references to "lock null" resources in 2518. Note: Unlike my previous more radical non-proposal (which by the way is still what I wish we would do :-), this is a serious proposal. Cheers, Geoff > From w3c-dist-auth-request@w3.org Wed Oct 13 12:36 EDT 1999 > Resent-Date: Wed, 13 Oct 1999 12:35:25 -0400 (EDT) > Resent-Message-Id: <199910131635.MAA02545@www19.w3.org> > From: ccjason@us.ibm.com > X-Lotus-Fromdomain: IBMUS > To: w3c-dist-auth@w3.org (w3c-dist-auth) > Date: Wed, 13 Oct 1999 12:38:49 -0400 > Mime-Version: 1.0 > Content-Disposition: inline > Subject: resourcetype locknull > Resent-From: w3c-dist-auth@w3.org > X-Mailing-List: archive/latest/3441 > X-Loop: w3c-dist-auth@w3.org > Resent-Sender: w3c-dist-auth-request@w3.org > > > I've noted it in the lock issues list and I suspect Jim already has it in the > 2518 issue list, but in the definition section it says that lock-null resources > are not listed as children of their parent... and (by omiision) cannot accept > UNLOCK and PROPFIND methods. Later in the document it says the opposite. I > believe the later information is correct. > > Based on that assumption and a "problem" I encountered with LOCK support in the > Linux version of mod_dav, I'd like to propose "lock-null" as a potential value > for the resourcetype property. This will give clients a predictable value there > for lock-null resources. > > What is the "problem" in linux mod_dav? Well it claims that the lock-null > resource is a collection. That's not technically incorrect. So I'd like to > insure that we specify exactly what is returned for the sake of clients. And it > seems like a new value would be appropriate. > > ------------------------------------------ > Phone: 914-784-7569, ccjason@us.ibm.com > > From w3c-dist-auth-request@w3.org Wed Oct 13 14:55:02 1999 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02246 for ; Wed, 13 Oct 1999 14:55:02 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id OAA05362; Wed, 13 Oct 1999 14:43:18 -0400 (EDT) Resent-Date: Wed, 13 Oct 1999 14:43:18 -0400 (EDT) Resent-Message-Id: <199910131843.OAA05362@www19.w3.org> From: jamsden@us.ibm.com X-Lotus-FromDomain: IBMUS To: w3c-dist-auth@w3.org Message-ID: <85256809.0066C796.00@d54mta03.raleigh.ibm.com> Date: Wed, 13 Oct 1999 14:39:31 -0400 Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Subject: Re: resourcetype locknull Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3443 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 should make sure there is a DAV:resourcetype for every resource defined by the protocol. ccjason@us.ibm.com on 10/13/99 12:38:49 PM To: w3c-dist-auth@w3.org (w3c-dist-auth) cc: Subject: resourcetype locknull I've noted it in the lock issues list and I suspect Jim already has it in the 2518 issue list, but in the definition section it says that lock-null resources are not listed as children of their parent... and (by omiision) cannot accept UNLOCK and PROPFIND methods. Later in the document it says the opposite. I believe the later information is correct. Based on that assumption and a "problem" I encountered with LOCK support in the Linux version of mod_dav, I'd like to propose "lock-null" as a potential value for the resourcetype property. This will give clients a predictable value there for lock-null resources. What is the "problem" in linux mod_dav? Well it claims that the lock-null resource is a collection. That's not technically incorrect. So I'd like to insure that we specify exactly what is returned for the sake of clients. And it seems like a new value would be appropriate. ------------------------------------------ Phone: 914-784-7569, ccjason@us.ibm.com From w3c-dist-auth-request@w3.org Wed Oct 13 15:09: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 PAA02468 for ; Wed, 13 Oct 1999 15:09:15 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id OAA05890; Wed, 13 Oct 1999 14:57:30 -0400 (EDT) Resent-Date: Wed, 13 Oct 1999 14:57:30 -0400 (EDT) Resent-Message-Id: <199910131857.OAA05890@www19.w3.org> From: jamsden@us.ibm.com X-Lotus-FromDomain: IBMUS To: w3c-dist-auth@w3.org Message-ID: <85256809.00680DE1.00@d54mta03.raleigh.ibm.com> Date: Wed, 13 Oct 1999 14:48:53 -0400 Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Subject: Re: resourcetype locknull Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3444 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-null resources were introduced to allow a user to "reserve" a name in the namespace. That is, to sort of create the resource and lock it in a single method. Otherwise, there is a race condition between the time the resource is created and the time it is locked where some other user could get the lock or otherwise change the new resource. Lock-null resources represent an attempt to special case situations that arise from the need to have transaction semantics and stateful servers for distributed authoring. There are other cases (in the versioning spec too) where methods are overloaded with headers (control couples) to make them do something that could have been done with a number of other methods, but not atomically. There's also the argument of reducing round trips, but this is pretty limited in this case. HTTP can execute a lot of methods in a second, and authoring environments often have much lighter nonfunctional requirements that production server systems. It was a real pain to implement lock-null resources as it is full of special cases. I too would just as soon see it removed from the spec. It doesn't seem that the complexity it adds to the protocol is consistent with the potential problem it solves. But Geoff, how do you reall feel about lock-null resources? gclemm@atria.com (Geoffrey M. Clemm) on 10/13/99 01:45:57 PM To: w3c-dist-auth@w3.org cc: Subject: Re: resourcetype locknull Could someone *pleeeassse* tell me what problem "lock null" resources are supposed to solve? I found a message from Yaron dated 3/22/98 where they appear to be introduced by an analogy with the need for "zero" when you are counting. I am not convinced (:-). If you want to "lock" a place where there is no resource, create some dummy resource there and lock that. Currently we're stuck with several paragraphs of verbiage telling us how a lock null resource behaves exactly like a regular resource except that it returns a "404" when you try to get its body. Is that feature so important that it warrants the incremental complexity and confusion that it adds to the spec? I propose that we strike all references to "lock null" resources in 2518. Note: Unlike my previous more radical non-proposal (which by the way is still what I wish we would do :-), this is a serious proposal. Cheers, Geoff > From w3c-dist-auth-request@w3.org Wed Oct 13 12:36 EDT 1999 > Resent-Date: Wed, 13 Oct 1999 12:35:25 -0400 (EDT) > Resent-Message-Id: <199910131635.MAA02545@www19.w3.org> > From: ccjason@us.ibm.com > X-Lotus-Fromdomain: IBMUS > To: w3c-dist-auth@w3.org (w3c-dist-auth) > Date: Wed, 13 Oct 1999 12:38:49 -0400 > Mime-Version: 1.0 > Content-Disposition: inline > Subject: resourcetype locknull > Resent-From: w3c-dist-auth@w3.org > X-Mailing-List: archive/latest/3441 > X-Loop: w3c-dist-auth@w3.org > Resent-Sender: w3c-dist-auth-request@w3.org > > > I've noted it in the lock issues list and I suspect Jim already has it in the > 2518 issue list, but in the definition section it says that lock-null resources > are not listed as children of their parent... and (by omiision) cannot accept > UNLOCK and PROPFIND methods. Later in the document it says the opposite. I > believe the later information is correct. > > Based on that assumption and a "problem" I encountered with LOCK support in the > Linux version of mod_dav, I'd like to propose "lock-null" as a potential value > for the resourcetype property. This will give clients a predictable value there > for lock-null resources. > > What is the "problem" in linux mod_dav? Well it claims that the lock-null > resource is a collection. That's not technically incorrect. So I'd like to > insure that we specify exactly what is returned for the sake of clients. And it > seems like a new value would be appropriate. > > ------------------------------------------ > Phone: 914-784-7569, ccjason@us.ibm.com > > From w3c-dist-auth-request@w3.org Wed Oct 13 16:00: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 QAA03170 for ; Wed, 13 Oct 1999 16:00:50 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id PAA08903; Wed, 13 Oct 1999 15:47:59 -0400 (EDT) Resent-Date: Wed, 13 Oct 1999 15:47:59 -0400 (EDT) Resent-Message-Id: <199910131947.PAA08903@www19.w3.org> Date: Wed, 13 Oct 1999 15:47:50 -0400 Message-Id: <9910131947.AA18717@tantalum> From: "Geoffrey M. Clemm" To: w3c-dist-auth@w3.org In-Reply-To: <85256809.00680DE1.00@d54mta03.raleigh.ibm.com> (jamsden@us.ibm.com) Subject: Re: resourcetype locknull Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3445 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 Lock-null resources were introduced to allow a user to "reserve" a name in the namespace. That is, to sort of create the resource and lock it in a single method. Otherwise, there is a race condition between the time the resource is created and the time it is locked where some other user could get the lock or otherwise change the new resource. Isn't this functionally equivalent to someone getting the lock on the lock null resource between the time when you issued the lock request and the time it was handled by the server? The fact that they got the lock on the empty dummy resource you created, as opposed to a lock on a "lock null" resource doesn't seem to change the situation in any substantive way. (Jim: Since you don't like lock null resources anyway, you shouldn't feel compelled to answer this ... this question is intended for anyone who *is* in favor of lock null resources :-) Lock-null resources represent an attempt to special case situations that arise from the need to have transaction semantics and stateful servers for distributed authoring. There are other cases (in the versioning spec too) where methods are overloaded with headers (control couples) to make them do something that could have been done with a number of other methods, but not atomically. There's also the argument of reducing round trips, but this is pretty limited in this case. HTTP can execute a lot of methods in a second, and authoring environments often have much lighter nonfunctional requirements that production server systems. Yup, to all Jim says here. It was a real pain to implement lock-null resources as it is full of special cases. I too would just as soon see it removed from the spec. It doesn't seem that the complexity it adds to the protocol is consistent with the potential problem it solves. But Geoff, how do you reall feel about lock-null resources? Oh, still pretty ambivalent ... (not :-). Cheers, Geoff From w3c-dist-auth-request@w3.org Wed Oct 13 18:14: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 SAA05268 for ; Wed, 13 Oct 1999 18:14:20 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id SAA11141; Wed, 13 Oct 1999 18:00:36 -0400 (EDT) Resent-Date: Wed, 13 Oct 1999 18:00:36 -0400 (EDT) Resent-Message-Id: <199910132200.SAA11141@www19.w3.org> Message-ID: <380500E6.6BBC42CB@ecal.com> Date: Wed, 13 Oct 1999 18:00:06 -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: <9910131947.AA18717@tantalum> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: resourcetype locknull Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3446 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: > Isn't this functionally equivalent to someone getting the lock on the > lock null resource between the time when you issued the lock request > and the time it was handled by the server? The fact that they got the > lock on the empty dummy resource you created, as opposed to a lock on a > "lock null" resource doesn't seem to change the situation in any > substantive way. Consider what happens if you need to create a resource with a particular body and some particular properties. If you don't have lock-nulls (or transactions), then you do PUT, LOCK, PROPPATCH, UNLOCK (or maybe skip the LOCK/UNLOCK, since it's only protecting one operation). If you and somebody else are trying to create it at the same time, then you could get PUT1, PUT2, PROPPATCH2, PROPPATCH1, resulting in resource whose properties don't match its body. With lock-null, you can do LOCK, PUT, PROPPATCH, UNLOCK. -- /==============================================================\ |John Stracke | http://www.ecal.com |My opinions are my own.| |Chief Scientist |=============================================| |eCal Corp. |Never mind the GUIs--Unix won't be for the | |francis@ecal.com|masses until we fix backspace & delete. | \==============================================================/ From w3c-dist-auth-request@w3.org Wed Oct 13 23:21: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 XAA09922 for ; Wed, 13 Oct 1999 23:21:18 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id XAA16423; Wed, 13 Oct 1999 23:08:23 -0400 (EDT) Resent-Date: Wed, 13 Oct 1999 23:08:23 -0400 (EDT) Resent-Message-Id: <199910140308.XAA16423@www19.w3.org> Date: Wed, 13 Oct 1999 23:08:16 -0400 Message-Id: <9910140308.AA18909@tantalum> From: "Geoffrey M. Clemm" To: w3c-dist-auth@w3.org In-Reply-To: <380500E6.6BBC42CB@ecal.com> (message from John Stracke on Wed, 13 Oct 1999 18:00:06 -0400) Subject: Re: resourcetype locknull Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3447 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 Consider what happens if you need to create a resource with a particular body and some particular properties. If you don't have lock-nulls (or transactions), then you do PUT, LOCK, PROPPATCH, UNLOCK Actually, since you don't know whether or not something is there already, you'd always first try the LOCK. If the LOCK fails (because there is no resource there to LOCK), you do a PUT (with an empty body) followed by a LOCK. So what you do is: LOCK (if fail because no resource there, then PUT null-body; LOCK) PUT; PROPATCH; UNLOCK So all LOCK-NULL buys you is the avoidance of the extra PUT/LOCK in case there is no resource there yet. (or maybe skip the LOCK/UNLOCK, since it's only protecting one operation). Even if you just did a single operation, you still want the LOCK/UNLOCK to prevent another (locking) client from performing its edits using the state of the resource prior to your operation (i.e. you don't want to "lose" your operation). If you and somebody else are trying to create it at the same time, then you could get PUT1, PUT2, PROPPATCH2, PROPPATCH1, resulting in resource whose properties don't match its body. With lock-null, you can do LOCK, PUT, PROPPATCH, UNLOCK. Without lock null resources, you still wrap LOCK/UNLOCK around your sequence of operations. The only difference is that if your LOCK fails because there is no resource to LOCK, you issue a PUT with an empty body, followed by a retry of the LOCK. Note: If someone gets in ahead of you and locks the dummy resource you just created, that's no different than someone getting their lock-null LOCK request in ahead of you. Note 2: Hopefully there are some GET's and PROPFIND's mixed in with those PUT's and PROPPATCH's, or else you're going to lose the previous updates, whether or not you use LOCK's. Cheers, Geoff From w3c-dist-auth-request@w3.org Thu Oct 14 00:39: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 AAA11256 for ; Thu, 14 Oct 1999 00:39:33 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id AAA17567; Thu, 14 Oct 1999 00:25:27 -0400 (EDT) Resent-Date: Thu, 14 Oct 1999 00:25:27 -0400 (EDT) Resent-Message-Id: <199910140425.AAA17567@www19.w3.org> From: ccjason@us.ibm.com X-Lotus-FromDomain: IBMUS To: John Stracke cc: w3c-dist-auth@w3.org Message-ID: <8525680A.00184238.00@D51MTA03.pok.ibm.com> Date: Thu, 14 Oct 1999 00:29:26 -0400 Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Subject: Re: resourcetype locknull Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3448 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list Consider what happens if you need to create a resource with a particular body and some particular properties. If you don't have lock-nulls (or transactions), then you do PUT, LOCK, PROPPATCH, UNLOCK (or maybe skip the LOCK/UNLOCK, since it's only protecting one operation). If you and somebody else are trying to create it at the same time, then you could get PUT1, PUT2, PROPPATCH2, PROPPATCH1, resulting in resource whose properties don't match its body. With lock-null, you can do LOCK, PUT, PROPPATCH, UNLOCK. Or similarly LOCK, DELETE (leave null lock flag), PUT, PROPATCH, UNLOCK.... ala MKRESOURCE. Or LOCK, DELETE (null lock left), COPY (tree perhaps), play, UNLOCK. Or xserver COPY... LOCK (depth), DELETE, PUT, MKCOL, PROPATCH, MKCOL, etc UNLOCK. And reduces possible error conditions in the middle of sequences of methods that a client might want to invoke. And facilitates backing things out if it has an error... because it knows what the state is and can feel safer about backing it out... (depth null lock) Question... what situations are complicated by lock null resources. I'm sure we must have covered this, but I forget what they were and I didn't record them. I'd like to record this in the issues list. From w3c-dist-auth-request@w3.org Thu Oct 14 07:53: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 HAA26321 for ; Thu, 14 Oct 1999 07:53:21 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id HAA23721; Thu, 14 Oct 1999 07:39:19 -0400 (EDT) Resent-Date: Thu, 14 Oct 1999 07:39:19 -0400 (EDT) Resent-Message-Id: <199910141139.HAA23721@www19.w3.org> From: jamsden@us.ibm.com X-Lotus-FromDomain: IBMUS To: w3c-dist-auth@w3.org Message-ID: <8525680A.003FFBB2.00@d54mta03.raleigh.ibm.com> Date: Thu, 14 Oct 1999 07:32:11 -0400 Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Subject: Re: resourcetype locknull Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3449 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-null resources were introduced to allow a user to "reserve" a name in the namespace. That is, to sort of create the resource and lock it in a single method. Otherwise, there is a race condition between the time the resource is created and the time it is locked where some other user could get the lock or otherwise change the new resource. Isn't this functionally equivalent to someone getting the lock on the lock null resource between the time when you issued the lock request and the time it was handled by the server? The fact that they got the lock on the empty dummy resource you created, as opposed to a lock on a "lock null" resource doesn't seem to change the situation in any substantive way. We could eliminate lock-null resources, and keep the ability to reserve a name in the namespace if LOCK on a null resource created a resource with an empty body and locked it. Since LOCK on a null resource isn't going to respond with 404 Not Found anyway, it might as well create the resource. From w3c-dist-auth-request@w3.org Thu Oct 14 09: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 JAA00287 for ; Thu, 14 Oct 1999 09:39:45 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id JAA27116; Thu, 14 Oct 1999 09:25:44 -0400 (EDT) Resent-Date: Thu, 14 Oct 1999 09:25:44 -0400 (EDT) Resent-Message-Id: <199910141325.JAA27116@www19.w3.org> From: jamsden@us.ibm.com X-Lotus-FromDomain: IBMUS To: w3c-dist-auth@w3.org Message-ID: <8525680A.0049B8D8.00@d54mta03.raleigh.ibm.com> Date: Thu, 14 Oct 1999 09:23:25 -0400 Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Subject: Re: resourcetype locknull Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3450 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list Or LOCK, DELETE (null lock left)... DELETE on a locked resource does not result in a lock-null resource, the resource is deleted and the lock is lost. From w3c-dist-auth-request@w3.org Thu Oct 14 10:06: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 KAA01448 for ; Thu, 14 Oct 1999 10:06:14 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id JAA28129; Thu, 14 Oct 1999 09:54:48 -0400 (EDT) Resent-Date: Thu, 14 Oct 1999 09:54:48 -0400 (EDT) Resent-Message-Id: <199910141354.JAA28129@www19.w3.org> From: jamsden@us.ibm.com X-Lotus-FromDomain: IBMUS To: w3c-dist-auth@w3.org Message-ID: <8525680A.004C572C.00@d54mta03.raleigh.ibm.com> Date: Thu, 14 Oct 1999 09:53:19 -0400 Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Subject: New version of DAV4J Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3451 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 is a new version of DAV4J available at http://www.alphaworks.ibm.com/tech/dav4j, version 1.0.28.7. This version still uses Apache 1.3.6 and WebSphere AppServer 2.0.2, so you don't need to change anything else. Version 1.0.28.7 contains a number of bug fixes, and is interoperable with mod_dav version 0.9.11 except for a few problems with locking. See the readme file for details. From w3c-dist-auth-request@w3.org Thu Oct 14 10:28: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 KAA02425 for ; Thu, 14 Oct 1999 10:28:45 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id KAA29374; Thu, 14 Oct 1999 10:17:18 -0400 (EDT) Resent-Date: Thu, 14 Oct 1999 10:17:18 -0400 (EDT) Resent-Message-Id: <199910141417.KAA29374@www19.w3.org> Date: Thu, 14 Oct 1999 10:17:10 -0400 Message-Id: <9910141417.AA19123@tantalum> From: "Geoffrey M. Clemm" To: w3c-dist-auth@w3.org In-Reply-To: <8525680A.00184238.00@D51MTA03.pok.ibm.com> (ccjason@us.ibm.com) Subject: Re: resourcetype locknull Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3452 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 Or similarly LOCK, DELETE (leave null lock flag), PUT, PROPATCH, UNLOCK.... ala MKRESOURCE. Or LOCK, DELETE (null lock left), COPY (tree perhaps), play, UNLOCK. Or xserver COPY... LOCK (depth), DELETE, PUT, MKCOL, PROPATCH, MKCOL, etc UNLOCK. And reduces possible error conditions in the middle of sequences of methods that a client might want to invoke. And facilitates backing things out if it has an error... because it knows what the state is and can feel safer about backing it out... (depth null lock) As Jim Amsden mentioned, according to 2518 you will lose your LOCK as soon as you issue a DELETE, so you will have to request another LOCK, and there will be a window of opportunity for someone to get in ahead of you with their LOCK. But their doing so does not introduce any lost update issues, but just says that you have to wait for them to finish instead of the other way round. This is just the normal situation in distributed authoring. Question... what situations are complicated by lock null resources. I'm sure we must have covered this, but I forget what they were and I didn't record them. I'd like to record this in the issues list. With lock null resources, a client has to think about what special thing they might need to do in case what appears to be no resource in some cases (404 coming back from a GET), appears to be a resource in other cases (PROPFIND). In particular, the client needs to indicate this fact somehow to a user when the user requests information about a collection. So it is not just the client but the user that pays a cost for this feature. If you look at it from the server side, removing lock null resources is of course an unconditional win (Jim Amsden already made that point in an earlier message). Cheers, Geoff From w3c-dist-auth-request@w3.org Thu Oct 14 10:35: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 KAA02744 for ; Thu, 14 Oct 1999 10:35:37 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id KAA29641; Thu, 14 Oct 1999 10:23:35 -0400 (EDT) Resent-Date: Thu, 14 Oct 1999 10:23:35 -0400 (EDT) Resent-Message-Id: <199910141423.KAA29641@www19.w3.org> Date: Thu, 14 Oct 1999 10:23:30 -0400 Message-Id: <9910141423.AA19142@tantalum> From: "Geoffrey M. Clemm" To: w3c-dist-auth@w3.org In-Reply-To: <8525680A.003FFBB2.00@d54mta03.raleigh.ibm.com> (jamsden@us.ibm.com) Subject: Re: resourcetype locknull Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3453 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 We could eliminate lock-null resources, and keep the ability to reserve a name in the namespace if LOCK on a null resource created a resource with an empty body and locked it. Since LOCK on a null resource isn't going to respond with 404 Not Found anyway, it might as well create the resource. Having LOCK create a null resource as a side effect? This can't be "no control coupling" Jim Amsden talking here! (:-). But seriously, I could easily live with this proposal. Although I am aesthetically against control coupling of this kind (i.e. creating a resource and locking a resource should be two separate and orthogonal requests), I could live with it if that's what it takes to get rid of lock null resources. Cheers, Geoff From w3c-dist-auth-request@w3.org Thu Oct 14 11:38: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 LAA04652 for ; Thu, 14 Oct 1999 11:38:00 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id LAA01637; Thu, 14 Oct 1999 11:23:11 -0400 (EDT) Resent-Date: Thu, 14 Oct 1999 11:23:11 -0400 (EDT) Resent-Message-Id: <199910141523.LAA01637@www19.w3.org> Message-Id: <199910141523.KAA28129@nuinfo.nwu.edu> To: gclemm@tantalum.atria.com Date: Thu, 14 Oct 1999 10:23:04 CDT Cc: w3c-dist-auth@w3.org In-Reply-To: <9910141423.AA19142@tantalum>; from "Geoffrey M. Clemm" at Oct 14, 99 10:23 am From: Albert-Lunde@nwu.edu (Albert Lunde) Reply-To: Albert-Lunde@nwu.edu (Albert Lunde) X-Mailer: Elm [revision: 212.4] Subject: Re: resourcetype locknull Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3454 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 LOCK create a null resource as a side effect? > This can't be "no control coupling" Jim Amsden talking here! (:-). > > But seriously, I could easily live with this proposal. Although I am > aesthetically against control coupling of this kind (i.e. creating a > resource and locking a resource should be two separate and orthogonal > requests), I could live with it if that's what it takes to get rid > of lock null resources. But would this work if one intended to reserve a URL to create a collection? -- Albert Lunde Albert-Lunde@nwu.edu From w3c-dist-auth-request@w3.org Thu Oct 14 11:55: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 LAA05149 for ; Thu, 14 Oct 1999 11:55:32 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id LAA02350; Thu, 14 Oct 1999 11:40:54 -0400 (EDT) Resent-Date: Thu, 14 Oct 1999 11:40:54 -0400 (EDT) Resent-Message-Id: <199910141540.LAA02350@www19.w3.org> From: ccjason@us.ibm.com X-Lotus-FromDomain: IBMUS To: "Geoffrey M. Clemm" cc: w3c-dist-auth@w3.org Message-ID: <8525680A.00561AE5.00@D51MTA03.pok.ibm.com> Date: Thu, 14 Oct 1999 11:42:34 -0400 Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Subject: Re: resourcetype locknull Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3455 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 could eliminate lock-null resources, and keep the ability to reserve a name in the namespace if LOCK on a null resource created a resource with an empty body and locked it. Since LOCK on a null resource isn't going to respond with 404 Not Found anyway, it might as well create the resource. Having LOCK create a null resource as a side effect? This can't be "no control coupling" Jim Amsden talking here! (:-). But seriously, I could easily live with this proposal. Although I am aesthetically against control coupling of this kind (i.e. creating a resource and locking a resource should be two separate and orthogonal requests), I could live with it if that's what it takes to get rid of lock null resources. This proposal essentially creates a resource and that resource has special properties... no guid? special resourcetype? MKCOL?. I guess that could be fine... but it also sounds like it's largely the same as our current lock null resource. At least in implementation and behavior... even if different in conceptual model. The thing is, the goal of this isn't really to create a resource... it's to reserve the the namespace and perhaps to provide for some atomicity subsequently. The ideal would be a lock that is rooted in the slot of the parent collection where the binding resides. This doesn't fit our current data model since we never really talk about slots. This does resolve a few problems though. (No, I'm not making a proposal at this point. Just brainstorming.) From w3c-dist-auth-request@w3.org Thu Oct 14 12:08: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 LAA05157 for ; Thu, 14 Oct 1999 11:55:46 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id LAA02393; Thu, 14 Oct 1999 11:41:06 -0400 (EDT) Resent-Date: Thu, 14 Oct 1999 11:41:06 -0400 (EDT) Resent-Message-Id: <199910141541.LAA02393@www19.w3.org> From: ccjason@us.ibm.com X-Lotus-FromDomain: IBMUS To: "Geoffrey M. Clemm" cc: w3c-dist-auth@w3.org Message-ID: <8525680A.0056214F.00@D51MTA03.pok.ibm.com> Date: Thu, 14 Oct 1999 11:44:42 -0400 Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Subject: Re: resourcetype locknull Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3456 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list Whoops, I thought I already sent this... From: ccjason@us.ibm.com Or similarly LOCK, DELETE (leave null lock flag), PUT, PROPATCH, UNLOCK.... ala MKRESOURCE. Or LOCK, DELETE (null lock left), COPY (tree perhaps), play, UNLOCK. Or xserver COPY... LOCK (depth), DELETE, PUT, MKCOL, PROPATCH, MKCOL, etc UNLOCK. And reduces possible error conditions in the middle of sequences of methods that a client might want to invoke. And facilitates backing things out if it has an error... because it knows what the state is and can feel safer about backing it out... (depth null lock) As Jim Amsden mentioned, according to 2518 you will lose your LOCK as soon as you issue a DELETE, so you will have to request another LOCK, and there will be a window of opportunity for someone to get in ahead of you with their LOCK. But their doing so does not introduce any lost update issues, but just says that you have to wait for them to finish instead of the other way round. This is just the normal situation in distributed authoring. Right. That's what 2518 says. That's why I explicitly noted it. But we haven't completed the spec. The assumption is that we'd support this. If we do... we could use lock null resources in this way. See my previous postings on this. Right, deleting the lock doesn't create a lost update problem. It does cause a problem where someone else can slip in a lock, thus block you, abort themselves because what they expected there is no longer there. But of course you've already done the delete, so you've only done a partial execution and you can't really back out. You've lost atomicity. So to get around this a client app might do a MOVE instead of a delete... so at least it has a chance of backing out your change, but once again someone else's lock can block it even if it's a temporary lock. As you see... this type of atomicity is not achievable without the this type of lock. Question... what situations are complicated by lock null resources. I'm sure we must have covered this, but I forget what they were and I didn't record them. I'd like to record this in the issues list. With lock null resources, a client has to think about what special thing they might need to do in case what appears to be no resource in some cases (404 coming back from a GET), appears to be a resource in other cases (PROPFIND). In particular, the client needs to indicate this fact somehow to a user when the user requests information about a collection. So it is not just the client but the user that pays a cost for this feature. Interesting. I'll note that... and give it more thought. JimA just posted a proposal that would resolve this. Something about giving the null resource a body. To some extent... it no longer would be a null resource then though. More thought. If you look at it from the server side, removing lock null resources is of course an unconditional win (Jim Amsden already made that point in an earlier message). I'll look for that posting and list it here. From w3c-dist-auth-request@w3.org Thu Oct 14 12:56: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 MAA07187 for ; Thu, 14 Oct 1999 12:56:46 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id MAA04828; Thu, 14 Oct 1999 12:41:35 -0400 (EDT) Resent-Date: Thu, 14 Oct 1999 12:41:35 -0400 (EDT) Resent-Message-Id: <199910141641.MAA04828@www19.w3.org> Date: Thu, 14 Oct 1999 12:41:25 -0400 Message-Id: <9910141641.AA19266@tantalum> From: "Geoffrey M. Clemm" To: w3c-dist-auth@w3.org In-Reply-To: <199910141523.KAA28129@nuinfo.nwu.edu> (Albert-Lunde@nwu.edu) Subject: Re: resourcetype locknull Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3457 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: Albert-Lunde@nwu.edu (Albert Lunde) > Having LOCK create a null resource as a side effect? > This can't be "no control coupling" Jim Amsden talking here! (:-). > > But seriously, I could easily live with this proposal. Although I am > aesthetically against control coupling of this kind (i.e. creating a > resource and locking a resource should be two separate and orthogonal > requests), I could live with it if that's what it takes to get rid > of lock null resources. But would this work if one intended to reserve a URL to create a collection? Albert is of course right. So I can no longer live with Jim's proposal (:-). So I'm back to: - return a 404 if there is no resource to LOCK, - let the client create a "null" instance of what it wants there, - then the client locks that null instance and it is off and running. Cheers, Geoff From w3c-dist-auth-request@w3.org Thu Oct 14 13:26: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 NAA08259 for ; Thu, 14 Oct 1999 13:26:19 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id NAA05531; Thu, 14 Oct 1999 13:11:30 -0400 (EDT) Resent-Date: Thu, 14 Oct 1999 13:11:30 -0400 (EDT) Resent-Message-Id: <199910141711.NAA05531@www19.w3.org> From: jamsden@us.ibm.com X-Lotus-FromDomain: IBMUS To: w3c-dist-auth@w3.org Message-ID: <8525680A.005E5DA2.00@d54mta03.raleigh.ibm.com> Date: Thu, 14 Oct 1999 13:11:06 -0400 Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Subject: Re: resourcetype locknull Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3458 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, That's exactly how I feel about it too. With MKRESOURCE, perhaps even PUT shouldn't create resources as a side effect, but we have to be compatible with HTTP conventions. "Geoffrey M. Clemm" on 10/14/99 10:23:30 AM To: w3c-dist-auth@w3.org cc: Subject: Re: resourcetype locknull From: jamsden@us.ibm.com We could eliminate lock-null resources, and keep the ability to reserve a name in the namespace if LOCK on a null resource created a resource with an empty body and locked it. Since LOCK on a null resource isn't going to respond with 404 Not Found anyway, it might as well create the resource. Having LOCK create a null resource as a side effect? This can't be "no control coupling" Jim Amsden talking here! (:-). But seriously, I could easily live with this proposal. Although I am aesthetically against control coupling of this kind (i.e. creating a resource and locking a resource should be two separate and orthogonal requests), I could live with it if that's what it takes to get rid of lock null resources. Cheers, Geoff From w3c-dist-auth-request@w3.org Thu Oct 14 13:27: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 NAA08289 for ; Thu, 14 Oct 1999 13:27:44 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id NAA05632; Thu, 14 Oct 1999 13:13:13 -0400 (EDT) Resent-Date: Thu, 14 Oct 1999 13:13:13 -0400 (EDT) Resent-Message-Id: <199910141713.NAA05632@www19.w3.org> Date: Thu, 14 Oct 1999 13:13:07 -0400 Message-Id: <9910141713.AA19378@tantalum> From: "Geoffrey M. Clemm" To: w3c-dist-auth@w3.org In-Reply-To: <8525680A.0056214F.00@D51MTA03.pok.ibm.com> (ccjason@us.ibm.com) Subject: Re: resourcetype locknull Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3459 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 ... according to 2518 you will lose your LOCK as soon as you issue a DELETE, so you will have to request another LOCK, and there will be a window of opportunity for someone to get in ahead of you with their LOCK. But their doing so does not introduce any lost update issues, but just says that you have to wait for them to finish instead of the other way round. This is just the normal situation in distributed authoring. Right. That's what 2518 says. That's why I explicitly noted it. But we haven't completed the spec. The assumption is that we'd support this. If we do... we could use lock null resources in this way. See my previous postings on this. Fair enough. I was criticizing lock null resources as they are defined in 2518. Any attempt I have seen to improve the semantics of lock null resources ends up fixing some problems at the cost of even greater complexity. So I'm not saying that they don't solve any interesting problems (they do), but rather that the cost of providing them outweighs the benefits they provide. Question... what situations are complicated by lock null resources. I'm sure we must have covered this, but I forget what they were and I didn't record them. I'd like to record this in the issues list. With lock null resources, a client has to think about what special thing they might need to do in case what appears to be no resource in some cases (404 coming back from a GET), appears to be a resource in other cases (PROPFIND). In particular, the client needs to indicate this fact somehow to a user when the user requests information about a collection. So it is not just the client but the user that pays a cost for this feature. Interesting. I'll note that... and give it more thought. JimA just posted a proposal that would resolve this. Something about giving the null resource a body. To some extent... it no longer would be a null resource then though. Albert's point (in my opinion) squelched that proposal (:-). Unless you allow MKRESOURCE to "mutate" a resource to a new resource type, you will have to delete the resource created by LOCK in order to get the right resource type, and if we hold to the model that LOCK's are on resources (not URL's), then when that old resource is deleted, it's lock cannot be inherited by some new resource at that same URL. Now I suppose we *could* just say that you can use MKRESOURCE to "mutate" a resource of one type into a resource of another type, but that's probably a cure that is worse than the disease ... (:-). Cheers, Geoff From w3c-dist-auth-request@w3.org Thu Oct 14 13:30: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 NAA08375 for ; Thu, 14 Oct 1999 13:30:43 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id NAA05736; Thu, 14 Oct 1999 13:16:02 -0400 (EDT) Resent-Date: Thu, 14 Oct 1999 13:16:02 -0400 (EDT) Resent-Message-Id: <199910141716.NAA05736@www19.w3.org> From: jamsden@us.ibm.com X-Lotus-FromDomain: IBMUS To: w3c-dist-auth@w3.org Message-ID: <8525680A.005EBDCC.00@d54mta03.raleigh.ibm.com> Date: Thu, 14 Oct 1999 13:14:44 -0400 Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Subject: Re: resourcetype locknull Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3460 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 it wouldn't, unless we did something with URLs ending in /. Getting ugly isn't it. Albert-Lunde@nwu.edu (Albert Lunde) on 10/14/99 11:23:04 AM Please respond to Albert-Lunde@nwu.edu (Albert Lunde) To: gclemm@tantalum.atria.com cc: w3c-dist-auth@w3.org Subject: Re: resourcetype locknull > Having LOCK create a null resource as a side effect? > This can't be "no control coupling" Jim Amsden talking here! (:-). > > But seriously, I could easily live with this proposal. Although I am > aesthetically against control coupling of this kind (i.e. creating a > resource and locking a resource should be two separate and orthogonal > requests), I could live with it if that's what it takes to get rid > of lock null resources. But would this work if one intended to reserve a URL to create a collection? -- Albert Lunde Albert-Lunde@nwu.edu From w3c-dist-auth-request@w3.org Thu Oct 14 13:38: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 NAA08705 for ; Thu, 14 Oct 1999 13:38:20 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id NAA06467; Thu, 14 Oct 1999 13:23:54 -0400 (EDT) Resent-Date: Thu, 14 Oct 1999 13:23:54 -0400 (EDT) Resent-Message-Id: <199910141723.NAA06467@www19.w3.org> Date: Thu, 14 Oct 1999 13:23:46 -0400 Message-Id: <9910141723.AA19402@tantalum> From: "Geoffrey M. Clemm" To: w3c-dist-auth@w3.org In-Reply-To: <8525680A.005E5DA2.00@d54mta03.raleigh.ibm.com> (jamsden@us.ibm.com) Subject: Re: resourcetype locknull Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3462 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's good to hear ... that means the body-snatchers didn't get you after all (:-). I'm actually not as concerned about PUT and MKRESOURCE being allowed to both create and update resources, since they both know what kind of resource should be there when they are done. I think LOCK is very different because you *can't* infer from the LOCK call what kind of resource should be created if none is there at the moment. Cheers, Geoff From: jamsden@us.ibm.com Geoff, That's exactly how I feel about it too. With MKRESOURCE, perhaps even PUT shouldn't create resources as a side effect, but we have to be compatible with HTTP conventions. "Geoffrey M. Clemm" on 10/14/99 10:23:30 AM Having LOCK create a null resource as a side effect? This can't be "no control coupling" Jim Amsden talking here! (:-). From w3c-dist-auth-request@w3.org Thu Oct 14 13:38: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 NAA08743 for ; Thu, 14 Oct 1999 13:38:58 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id NAA06449; Thu, 14 Oct 1999 13:23:52 -0400 (EDT) Resent-Date: Thu, 14 Oct 1999 13:23:52 -0400 (EDT) Resent-Message-Id: <199910141723.NAA06449@www19.w3.org> From: jamsden@us.ibm.com X-Lotus-FromDomain: IBMUS To: w3c-dist-auth@w3.org Message-ID: <8525680A.005F7C9C.00@d54mta03.raleigh.ibm.com> Date: Thu, 14 Oct 1999 13:23:46 -0400 Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Subject: RE: Revision names - id patterns Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3461 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, just some minor points: The server isn't doing anything arbitrary in this case, it is just doing what some client told it to do. So having the server move a label as the (somewhat) indirect consequence of a client request doesn't seem that different than having some other client do it directly. In one case the label moves because a client created a new revision which happened to pick an already used label. In the other case, it moves because a client labeled a revision. Doesn't seem that different. Brad's argument is the best one I've see so far for separate namespaces. Unfortunately, the argument applies to every client who wants stable labels, not just the server. This is what configurations are for as they do no depend on fixed labels. I still think separating the namespace adds complexity to the versioning model that is not consistent with the problems it solves. But I don't feel that strongly about it. Bradley Sergeant on 10/14/99 11:29:18 AM To: ietf-dav-versioning@w3.org cc: Subject: RE: Revision names - id patterns In my neck of the woods it would be considered rude for the server to automatically, unconditionally, irrevocably, and without warning move a clients label. I think this is quite different from having a client (who has been given access) move a label. Labels are used as important indicators. The fact that other authorized users can move them doesn't mean that it's OK for the server to do so arbitrarily. It's much better to keep clients from putting themselves in harms way, that is keep them from using labels that will conflict with revision ids. A 403 is a far better solution than automatically moving labels. Even better would be a separate name space. --Sarge -----Original Message----- From: jamsden@us.ibm.com [mailto:jamsden@us.ibm.com] Sent: Wednesday, October 13, 1999 11:59 AM To: ietf-dav-versioning@w3.org Subject: Re: Revision names - id patterns Good point Brad, but I don't think this is a problem. When the server creates a new revision, if the label name (id) it wants to put on the revision is already used as a user label, it will just be moved to the new revision, just like it would if any other client reused the label. The server guarantees it will never reuse this label on any other revision, and that it will never move again, but the first time doesn't matter. So I don't think the id space needs to be reserved. Bradley Sergeant on 10/13/99 02:10:26 PM To: ietf-dav-versioning@w3.org cc: Subject: Revision names - id patterns Assume there is a single namespace for revision ids and revision labels. If the server has a simple pattern for generating revision ids, then would it be legal for it to disallow a particular grammar being used for labels? Example: If the server wants to use the following sequence for revision ids: 1.0 1.1 1.2 ... And a user tries to add a label "1.3", then can the server return a status of 403 Forbidden and force the user to choose another name? This would mean that some labels could be added to some servers, but not to others with different revision-id grammars. For some servers it may not only be the conflicts of existing revision ids and labels that matter, but also of those not yet created. I suggest we at least grant the servers this degree of control over the revision-id namespace. --Sarge -----Original Message----- From: jamsden@us.ibm.com [mailto:jamsden@us.ibm.com] Sent: Tuesday, October 12, 1999 7:53 AM To: ietf-dav-versioning@w3.org Subject: Re: Revision names We can think of the server as another collaborator in distributed authoring systems, one that provides a set of services. In particular, there can be little distinction between a revision name (something that distinguishes one revision from another in this context) specified by some other client and one specified by the server. In both cases there is the possibility for collisions, and in both cases, there is the desire to use the revision name to select a revision. As Tim points out below, there is also a desire for the syntax of label names to be consistent with URLs, and to be able to marshall revision names in request and response entity bodies (in XML) as well as in headers. The only difference I can see is that the server's revision name, the revision id, can't be moved or reused - its an immutable or fixed label that ensures revisions can always be distinguished. Any attempt to move or reuse the label id results in an error. This makes potential client/server collisions even safer than client/client collisions as there is no possibility of some other client getting an unexpected revision because some other client or the server moved the label id. The only reason to separate id and label name spaces seemed to be to avoid client/server label name collisions. But it is clear that client/client name collisions are much more likely to happen, and have greater consequences (as measured by the principle of least astonishment). I continue to find it hard to justify the complexity separate label namespaces adds to the protocol vs. the problems it solves. Does anyone else see other issues that separate namespaces would avoid? Tim_Ellison@oti.com (Tim Ellison OTT) on 10/12/99 10:26:17 AM To: ietf-dav-versioning@w3.org (ietf-dav-versioning) cc: Subject: Revision names As mentioned by both Jeff (by phone) and Geoff (in an earlier positing), revision id's must be legal URI path segments if we envisage the ability to refer to a revision by a URL (i.e. DAV:history's revisions collection "/" DAV:revision-id). Maybe we will also want to refer to a particular labelled resource by a URL in a similar fashion. If we choose to differentiate labels and revision id's by extra syntax surrounding the value this would lead to bizzare looking URLs. Having listened to the discussions, I think that the argument for avoiding collisions between labels & revision ids has been largely debunked; and the protocol would undoubtably be simpler if there was not requirement to separate namespaces. However, labels and revision ids have different characteristics from the client's perspective and it would be immensely reassuring to know which you are dealing with at all times. I just don't see yet how this would fit into the protocol. Tim From w3c-dist-auth-request@w3.org Thu Oct 14 13:40: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 NAA08787 for ; Thu, 14 Oct 1999 13:40:06 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id NAA06783; Thu, 14 Oct 1999 13:25:42 -0400 (EDT) Resent-Date: Thu, 14 Oct 1999 13:25:42 -0400 (EDT) Resent-Message-Id: <199910141725.NAA06783@www19.w3.org> Date: Thu, 14 Oct 1999 10:24:50 -0700 Message-ID: <8843-Thu14Oct1999102450-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: <9910141641.AA19266@tantalum> References: <199910141523.KAA28129@nuinfo.nwu.edu> <9910141641.AA19266@tantalum> Subject: Re: resourcetype locknull Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3463 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 gmc> So I'm back to: gmc> - return a 404 if there is no resource to LOCK, gmc> - let the client create a "null" instance of what it wants there, gmc> - then the client locks that null instance and it is off and running. 1. There is a Very Popular Client which does just about this when creating a new resource. 2. The main problem with "lock null resources" is that the spec is a little weak on exactly what they are. That causes me as a server implementor to try to think too hard, when instead I could be having a delicious latte on the veranda. To my mind, this really reduces the chances of most servers ending up with compatible semantics for this. 3. OK, how about this implementation? I grant "lock null resource" requests, but my server has discretion to vaporize the locks whenever it wants, and it wants to vaporize them one clock tick after it creates them. Bwahh-ha-ha-ha! Take that, pesky clients! :-) 4. I run a lot of applications every day that work with my local filesystem, and they seem to cope without the equivalent of "lock null resource". If there is a namespace collision, which there often is, I, as a user, deal with that (including the occasional walk to educate Wally in the next cubicle). It's an everyday occurrence. That's what open() with the O_EXCL flag is all about, right? Could it be paralleled in WebDAV with either (a) expanded use of the OVERWRITE: header, or (b) HTTP/1.1 PUT, etc, with "IF-NONE-MATCH: *"? -- 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 Thu Oct 14 14:40: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 OAA10714 for ; Thu, 14 Oct 1999 14:40:39 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id OAA09554; Thu, 14 Oct 1999 14:22:09 -0400 (EDT) Resent-Date: Thu, 14 Oct 1999 14:22:09 -0400 (EDT) Resent-Message-Id: <199910141822.OAA09554@www19.w3.org> Date: Thu, 14 Oct 1999 11:21:00 -0700 Message-ID: <442-Thu14Oct1999112100-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: <9910141713.AA19378@tantalum> References: <8525680A.0056214F.00@D51MTA03.pok.ibm.com> <9910141713.AA19378@tantalum> Subject: Re: resourcetype locknull Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3464 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 gmc> So I'm not saying that they don't solve any interesting problems gmc> (they do), but rather that the cost of providing them outweighs gmc> the benefits they provide. Back when this was invented, someone must've thought there were scenarios where it was pretty important to be able to reserve namespace to be used later. Would someone care to lay out some scenarios where this is pretty important? (I'm not disputing it. Just looking for an education.) -- 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 Thu Oct 14 20:53: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 UAA15948 for ; Thu, 14 Oct 1999 20:53:56 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id UAA18784; Thu, 14 Oct 1999 20:42:49 -0400 (EDT) Resent-Date: Thu, 14 Oct 1999 20:42:49 -0400 (EDT) Resent-Message-Id: <199910150042.UAA18784@www19.w3.org> From: Jim Whitehead To: w3c-dist-auth@w3.org, Yaron Goland MMDF-Warning: Parse error in original version of preceding line at gremlin-relay.ics.uci.edu Date: Thu, 14 Oct 1999 17:41:53 -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: <380500E6.6BBC42CB@ecal.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Subject: RE: resourcetype locknull Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3465 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: > > > Isn't this functionally equivalent to someone getting the lock on the > > lock null resource between the time when you issued the lock request > > and the time it was handled by the server? The fact that they got the > > lock on the empty dummy resource you created, as opposed to a lock on a > > "lock null" resource doesn't seem to change the situation in any > > substantive way. > > Consider what happens if you need to create a resource with a particular > body and some particular properties. If you don't have lock-nulls (or > transactions), then you do PUT, LOCK, PROPPATCH, UNLOCK (or maybe skip the > LOCK/UNLOCK, since it's only protecting one operation). If you and > somebody else are trying to create it at the same time, then you could get > PUT1, PUT2, PROPPATCH2, PROPPATCH1, resulting in resource whose properties > don't match its body. With lock-null, you can do LOCK, PUT, PROPPATCH, > UNLOCK. This is a pretty good restatement of the original rationale for lock-null resources. Given the preponderance of evidence that indicates this is a difficult feature to implement, and since the arguments claiming that the feature is not strictly necessary appear to be sound, I would be happy to remove this feature as we move from Proposed to Draft standard, assuming that doing so does not create any interoperability problems. Yaron's currently on vacation, he may wish to defend this feature when he returns. I'm certainly not going to, unless I hear a compelling counter argument. - Jim From w3c-dist-auth-request@w3.org Thu Oct 14 21:42:52 1999 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA16374 for ; Thu, 14 Oct 1999 21:42:51 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id VAA19700; Thu, 14 Oct 1999 21:32:03 -0400 (EDT) Resent-Date: Thu, 14 Oct 1999 21:32:03 -0400 (EDT) Resent-Message-Id: <199910150132.VAA19700@www19.w3.org> From: ccjason@us.ibm.com X-Lotus-FromDomain: IBMUS To: Jim Whitehead cc: w3c-dist-auth@w3.org, Yaron Goland Message-ID: <8525680B.00086688.00@D51MTA03.pok.ibm.com> Date: Thu, 14 Oct 1999 21:36:02 -0400 Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Subject: RE: resourcetype locknull Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3466 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list Given the preponderance of evidence that indicates this is a difficult feature to implement, Jim, could you point me to that evidence. Earlier today Geoff defered that question to a note he said JimA wrote. I did a search for it and didn't find it. The best I've been able to find is simply folks saying it's hard... but not explaining why. I'd like to document this. From w3c-dist-auth-request@w3.org Thu Oct 14 23:16: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 XAA18906 for ; Thu, 14 Oct 1999 23:16:09 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id XAA20850; Thu, 14 Oct 1999 23:04:27 -0400 (EDT) Resent-Date: Thu, 14 Oct 1999 23:04:27 -0400 (EDT) Resent-Message-Id: <199910150304.XAA20850@www19.w3.org> Date: Thu, 14 Oct 1999 23:04:19 -0400 Message-Id: <9910150304.AA19606@tantalum> From: "Geoffrey M. Clemm" To: w3c-dist-auth@w3.org In-Reply-To: <8525680B.00086688.00@D51MTA03.pok.ibm.com> (ccjason@us.ibm.com) Subject: Re: resourcetype locknull Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3467 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 Given the preponderance of evidence that indicates this is a difficult feature to implement, Jim, could you point me to that evidence. Earlier today Geoff defered that question to a note he said JimA wrote. I did a search for it and didn't find it. The best I've been able to find is simply folks saying it's hard... but not explaining why. I'd like to document this. Jason: Both Jim and I were referring to the fact the server writers that have contributed to this thread have said that lock null resources were unpleasant/hard to implement, and that they'd prefer to see them removed from the spec. You are correct the reasons for why it was hard were not detailed. My arguments have largely been focused on the fact that they don't do much for a client, and in some ways can make life harder for both clients and users. As a server writer, the following are some of the problems with lock null resources: They don't act like normal resources. They return 404's to a GET as if they didn't exist, but show up in PROPFIND's. Are they a binding, and therefore part of the state of a collection, or something else? If you have a versioning server, do you have to checkout a collection in order to add a lock-null resource to it, or not? If you checkin a versioned collection that has a lock-null resource in it, does that make that lock-null resource "immutable" (whatever that means)? Do you have to checkout the versioned collection in order to remove a lock-null resource from it? When you do a DELETE, does that delete the lock-null resource at that spot, or does it leave it alone? When you DELETE a locked resource, should it delete the lock, or leave a lock-null resource in its place? Those are a few of the questions that a server writer must answer, and then hope that the client writers are expecting that behavior. And then the server writer has to figure out how to model this behavior with their underlying implementation objects. Let me know if you'd like more ... (:-). Cheers, Geoff From w3c-dist-auth-request@w3.org Fri Oct 15 07:57: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 HAA05914 for ; Fri, 15 Oct 1999 07:57:30 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id HAA01364; Fri, 15 Oct 1999 07:43:53 -0400 (EDT) Resent-Date: Fri, 15 Oct 1999 07:43:53 -0400 (EDT) Resent-Message-Id: <199910151143.HAA01364@www19.w3.org> Date: Fri, 15 Oct 1999 07:43:44 -0400 Message-Id: <9910151143.AA19732@tantalum> From: "Geoffrey M. Clemm" To: w3c-dist-auth@w3.org In-Reply-To: (ABabich@filenet.com) Subject: Static depth locking Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3468 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list Here is (what I consider) to be an extremely sensible proposal from Alan Babich (from a few months ago). He basically says that if you are going to do depth locking, it should be static, i.e. it should be a lock on the current members of the collection. If you MOVE things into and out of collections (because you have the appropriate lock tokens for the appropriate collections), it has no effect on the locks on those resources. This not only has very straightforward semantics (a depth lock is just a macro operation to produce and remove a large number of singleton locks), but is also compatible with versioning (it is the dynamic aspect of current depth locking that is the primary problem). I'll include Alan's message here in case you don't have it memorized (:-). Cheers, Geoff From: "Babich, Alan" Date: Thu, 5 Aug 1999 15:38:42 -0700 Why don't we do this: When you lock a collection: depth 0: shared lock placed on the collection resource: no one can add or delete members exclusive lock placed on the collection resource: only you can add or delete members. depth 1: shared lock on coll.: no one can add or delete members. First level members that exist at that time have a shared lock placed on them. exclusive lock on coll.: only you can add or delete members. First level members that exist at that time have an exclusive lock placed on them. depth infinity: shared lock on coll.: no one can add or delete members. Members at any level(including subcollections) that exist at that time have a shared lock placed on them. exclusive lock on coll.: only you can add or delete members. Members at any level (including subcollections) that exist at that time have a shared lock placed on them. When a resource is moved out of or into a collection, the lock(s) of the resource don't change (assume the move is allowed). No locks are ever created or deleted as a result of an ordinary resource or collection resource being moved (assume the move is allowed). When you unlock a collection, depth n, you do the inverse of the operation described above on the members that exist at the time the unlock of the collection is executed. Remember that a resource can be in multiple collections at the same time. In fact, in some systems, that is the normal case. If a resource X is in two collections C1 and C2, locking C1 does not prevent the resource X from being removed from collection C2. Nor does it prevent the resource X from being inserted into collection C3. There are no locks placed or removed as side effects of MOVE. Only LOCK, UNLOCK, and DELETE mess with locks. Alan Babich From w3c-dist-auth-request@w3.org Fri Oct 15 08:24: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 IAA07122 for ; Fri, 15 Oct 1999 08:24:54 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id IAA01869; Fri, 15 Oct 1999 08:13:04 -0400 (EDT) Resent-Date: Fri, 15 Oct 1999 08:13:04 -0400 (EDT) Resent-Message-Id: <199910151213.IAA01869@www19.w3.org> Date: Fri, 15 Oct 1999 08:12:58 -0400 Message-Id: <9910151212.AA19763@tantalum> From: "Geoffrey M. Clemm" To: w3c-dist-auth@w3.org In-Reply-To: <9910151143.AA19732@tantalum> (gclemm@tantalum.atria.com) Subject: Re: Static depth locking Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3469 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list Ooops. Forgot one comment. I would modify Alan's proposal to say: Only LOCK and UNLOCK can add or remove a lock to a resource. In particular, DELETE does not add or remove locks on resources. The reason is that a DELETE simply modifies the state of a collection (by removing one of its bindings). There still can be other bindings to that resource, and the lock should continue to apply. Only if the last binding to a resource is deleted can the server garbage collect that resource, which effectively deletes the lock. I believe that the simplicity of this rule far outweighs any benefits achieved by special casing MOVE's and DELETE's (and dynamic depth locking), both from a clients perspective (it can predict what operation will have what effect) and from a servers perspective (it doesn't have to worry about how to move/delete locks based on combinations of the user request and the state of the arguments to that request). To give a flavor of the complexity of deciding this behavior otherwise, consider the following variants of locking for a MOVE operation: pick 1 from the following 4 choices: Source is unlocked. Source inherits depth infinity lock. Source is locked. Source contains member(s) with locks. pick 1 from the following 2 choices: Parent of Source is unlocked. Parent of Source is depth 0 locked. pick 1 from the following 2 choices: Lock is a regular lock. Lock is a null lock. pick 1 from the following 2 choices Lock is by requestor. Lock is by other. pick 1 from the following 2 choices Lock is through this mapping. Lock is through different mapping. That gives us 64 interesting Source combinations. Now do the same for the Destination. That gives us 4048 interesting combinations of Source and Destination locking states for a MOVE. This situation is not conducive to enumerating the behavior for each interesting combination. Cheers, Geoff From: "Babich, Alan" Date: Thu, 5 Aug 1999 15:38:42 -0700 Why don't we do this: When you lock a collection: depth 0: shared lock placed on the collection resource: no one can add or delete members exclusive lock placed on the collection resource: only you can add or delete members. depth 1: shared lock on coll.: no one can add or delete members. First level members that exist at that time have a shared lock placed on them. exclusive lock on coll.: only you can add or delete members. First level members that exist at that time have an exclusive lock placed on them. depth infinity: shared lock on coll.: no one can add or delete members. Members at any level(including subcollections) that exist at that time have a shared lock placed on them. exclusive lock on coll.: only you can add or delete members. Members at any level (including subcollections) that exist at that time have a shared lock placed on them. When a resource is moved out of or into a collection, the lock(s) of the resource don't change (assume the move is allowed). No locks are ever created or deleted as a result of an ordinary resource or collection resource being moved (assume the move is allowed). When you unlock a collection, depth n, you do the inverse of the operation described above on the members that exist at the time the unlock of the collection is executed. Remember that a resource can be in multiple collections at the same time. In fact, in some systems, that is the normal case. If a resource X is in two collections C1 and C2, locking C1 does not prevent the resource X from being removed from collection C2. Nor does it prevent the resource X from being inserted into collection C3. There are no locks placed or removed as side effects of MOVE. Only LOCK, UNLOCK, and DELETE mess with locks. Alan Babich From w3c-dist-auth-request@w3.org Fri Oct 15 09:25: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 JAA09936 for ; Fri, 15 Oct 1999 09:25:01 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id JAA02609; Fri, 15 Oct 1999 09:12:10 -0400 (EDT) Resent-Date: Fri, 15 Oct 1999 09:12:10 -0400 (EDT) Resent-Message-Id: <199910151312.JAA02609@www19.w3.org> Date: Fri, 15 Oct 1999 09:12:04 -0400 From: gclemm@atria.com (Geoffrey M. Clemm) Message-Id: <9910151312.AA19799@tantalum> To: w3c-dist-auth@w3.org Subject: Re: Static depth locking Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3470 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 might wonder why 64x64 gives you 4048 interesting choices. I'd like to say that I evaluated all 4096 possibilities and found that 48 of them weren't interesting. I'm not saying that was what happened, but that's what I'd like to say (:-). Cheers, Geoff > From w3c-dist-auth-request@w3.org Fri Oct 15 08:16 EDT 1999 > Resent-Date: Fri, 15 Oct 1999 08:13:04 -0400 (EDT) > Resent-Message-Id: <199910151213.IAA01870@www19.w3.org> > Date: Fri, 15 Oct 1999 08:12:58 -0400 > From: "Geoffrey M. Clemm" > To: w3c-dist-auth@w3.org > Subject: Re: Static depth locking > Resent-From: w3c-dist-auth@w3.org > X-Mailing-List: archive/latest/3469 > X-Loop: w3c-dist-auth@w3.org > Resent-Sender: w3c-dist-auth-request@w3.org > > > Ooops. Forgot one comment. I would modify Alan's proposal to say: > > Only LOCK and UNLOCK can add or remove a lock to a resource. > > In particular, DELETE does not add or remove locks on resources. > The reason is that a DELETE simply modifies the state of a collection > (by removing one of its bindings). There still can be other bindings > to that resource, and the lock should continue to apply. Only if > the last binding to a resource is deleted can the server garbage collect > that resource, which effectively deletes the lock. > > I believe that the simplicity of this rule far outweighs any benefits > achieved by special casing MOVE's and DELETE's (and dynamic depth locking), > both from a clients perspective (it can predict what operation will have > what effect) and from a servers perspective (it doesn't have to worry > about how to move/delete locks based on combinations of the user request > and the state of the arguments to that request). > > To give a flavor of the complexity of deciding this behavior otherwise, > consider the following variants of locking for a MOVE operation: > > pick 1 from the following 4 choices: > Source is unlocked. > Source inherits depth infinity lock. > Source is locked. > Source contains member(s) with locks. > > pick 1 from the following 2 choices: > Parent of Source is unlocked. > Parent of Source is depth 0 locked. > > pick 1 from the following 2 choices: > Lock is a regular lock. > Lock is a null lock. > > pick 1 from the following 2 choices > Lock is by requestor. > Lock is by other. > > pick 1 from the following 2 choices > Lock is through this mapping. > Lock is through different mapping. > > That gives us 64 interesting Source combinations. > > Now do the same for the Destination. > > That gives us 4048 interesting combinations of Source and Destination > locking states for a MOVE. This situation is not conducive to enumerating > the behavior for each interesting combination. > > Cheers, > Geoff > > From: "Babich, Alan" > Date: Thu, 5 Aug 1999 15:38:42 -0700 > > Why don't we do this: > > When you lock a collection: > depth 0: > shared lock placed on the collection resource: > no one can add or delete members > exclusive lock placed on the collection resource: > only you can add or delete members. > depth 1: > shared lock on coll.: no one can add or delete members. > First level members that exist at that time have > a shared lock placed on them. > exclusive lock on coll.: only you can add or delete members. > First level members that exist at that time have > an exclusive lock placed on them. > depth infinity: > shared lock on coll.: no one can add or delete members. > Members at any level(including subcollections) > that exist at that time have > a shared lock placed on them. > exclusive lock on coll.: only you can add or delete members. > Members at any level (including subcollections) > that exist at that time have > a shared lock placed on them. > When a resource is moved out of or into a collection, the lock(s) > of the resource don't change (assume the move is allowed). > No locks are ever created or deleted as a result of an ordinary > resource or collection resource being moved (assume the move is > allowed). > > When you unlock a collection, depth n, you do the inverse > of the operation described above on the members that exist > at the time the unlock of the collection is executed. > > Remember that a resource can be in multiple collections at > the same time. In fact, in some systems, that is the normal > case. If a resource X is in two collections C1 and C2, > locking C1 does not prevent the resource X from being removed > from collection C2. Nor does it prevent the resource X from > being inserted into collection C3. There are no locks > placed or removed as side effects of MOVE. Only LOCK, > UNLOCK, and DELETE mess with locks. > > Alan Babich > > > > > > > From w3c-dist-auth-request@w3.org Fri Oct 15 09:59: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 JAA11426 for ; Fri, 15 Oct 1999 09:59:38 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id JAA03150; Fri, 15 Oct 1999 09:45:18 -0400 (EDT) Resent-Date: Fri, 15 Oct 1999 09:45:18 -0400 (EDT) Resent-Message-Id: <199910151345.JAA03150@www19.w3.org> Message-ID: <38072FD2.735274F5@ecal.com> Date: Fri, 15 Oct 1999 09:44:50 -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: <9910141641.AA19266@tantalum> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: resourcetype locknull Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3471 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: > - return a 404 if there is no resource to LOCK, > - let the client create a "null" instance of what it wants there, > - then the client locks that null instance and it is off and running. For collections, this doesn't work properly with your/Alan's proposal for static depth locking. If I'm creating a collection, I do LOCK (404), MKCOL, LOCK--but this LOCK only locks the resources that are there now (i.e., none). So anybody else is free to come along and add new resources, and my lock means nothing. For collections that are meant to model compound documents or some such, where the entire state of the collection needs to be treated as a unit, this is a Bad Thing. -- /==============================================================\ |John Stracke | http://www.ecal.com |My opinions are my own.| |Chief Scientist |=============================================| |eCal Corp. |Illiterate? Write today for free help! | |francis@ecal.com| | \==============================================================/ From w3c-dist-auth-request@w3.org Fri Oct 15 10:37: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 KAA12935 for ; Fri, 15 Oct 1999 10:37:55 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id KAA04200; Fri, 15 Oct 1999 10:25:37 -0400 (EDT) Resent-Date: Fri, 15 Oct 1999 10:25:37 -0400 (EDT) Resent-Message-Id: <199910151425.KAA04200@www19.w3.org> Date: Fri, 15 Oct 1999 10:25:28 -0400 Message-Id: <9910151425.AA19862@tantalum> From: "Geoffrey M. Clemm" To: francis@ecal.com Cc: w3c-dist-auth@w3.org In-Reply-To: <38072FD2.735274F5@ecal.com> (message from John Stracke on Fri, 15 Oct 1999 09:44:50 -0400) Subject: Re: resourcetype locknull Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3472 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 "Geoffrey M. Clemm" wrote: > - return a 404 if there is no resource to LOCK, > - let the client create a "null" instance of what it wants there, > - then the client locks that null instance and it is off and running. For collections, this doesn't work properly with your/Alan's proposal for static depth locking. If I'm creating a collection, I do LOCK (404), MKCOL, LOCK--but this LOCK only locks the resources that are there now (i.e., none). Your lock on the collection locks the state of that collection, i.e. the bindings. That means that only someone with the lock can modify the state of that collection, such as adding new bindings to it. So anybody else is free to come along and add new resources, and my lock means nothing. Not unless they have the lock. See above. For collections that are meant to model compound documents or some such, where the entire state of the collection needs to be treated as a unit, this is a Bad Thing. As long as you partition the compound object clearly into disjoint pieces, and provide a mechanism for locking each of those pieces (including the pieces that glue the other pieces together, i.e. the collections!), then you can effectively treat it as a unit by locking "every piece". The problem with the current state of locking in 2518 is that the various locks overlap in various complex ways, making the interaction between locks hard for clients to predict and hard for servers to implement. But I think that we can adjust the protocol to remove this locking overlap in a way that makes it largely consistent with the existing clients and servers. Cheers, Geoff From w3c-dist-auth-request@w3.org Fri Oct 15 10:49: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 KAA13311 for ; Fri, 15 Oct 1999 10:49:58 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id KAA04417; Fri, 15 Oct 1999 10:37:45 -0400 (EDT) Resent-Date: Fri, 15 Oct 1999 10:37:45 -0400 (EDT) Resent-Message-Id: <199910151437.KAA04417@www19.w3.org> X-Authentication-Warning: pentaventures.com: Host nap-pm3-02-11.gulfaccess.net [209.26.59.74] claimed to be brain Message-ID: <003201bf1719$63f4ebc0$1711a8c0@brain.pentaventures.com> From: "David Motes" To: "Geoffrey M. Clemm" Cc: Date: Fri, 15 Oct 1999 10:27:18 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.3110.5 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Subject: Re: resourcetype locknull Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3473 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 -----Original Message----- From: Geoffrey M. Clemm To: francis@ecal.com Cc: w3c-dist-auth@w3.org Date: Friday, October 15, 1999 10:26 AM Subject: Re: resourcetype locknull > From: John Stracke > > "Geoffrey M. Clemm" wrote: > > > - return a 404 if there is no resource to LOCK, > > - let the client create a "null" instance of what it wants there, > > - then the client locks that null instance and it is off and running. > > For collections, this doesn't work properly with your/Alan's proposal > for static depth locking. If I'm creating a collection, I do LOCK > (404), MKCOL, LOCK--but this LOCK only locks the resources that are > there now (i.e., none). > >Your lock on the collection locks the state of that collection, i.e. >the bindings. That means that only someone with the lock can modify >the state of that collection, such as adding new bindings to it. > > So anybody else is free to come along and add > new resources, and my lock means nothing. > >Not unless they have the lock. See above. Huh? In your original post about static depth locking you say: Here is (what I consider) to be an extremely sensible proposal from Alan Babich (from a few months ago). He basically says that if you are going to do depth locking, it should be static, i.e. it should be a lock on the current members of the collection. If you MOVE things into and out of collections (because you have the appropriate lock tokens for the appropriate collections), it has no effect on the locks on those resources. Lock the CURRENT members of the collection. I believe that is what John was commenting on. This is giving me a headache :-) -David From w3c-dist-auth-request@w3.org Fri Oct 15 12:14: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 MAA16204 for ; Fri, 15 Oct 1999 12:14:20 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id MAA06518; Fri, 15 Oct 1999 12:02:41 -0400 (EDT) Resent-Date: Fri, 15 Oct 1999 12:02:41 -0400 (EDT) Resent-Message-Id: <199910151602.MAA06518@www19.w3.org> From: jamsden@us.ibm.com X-Lotus-FromDomain: IBMUS To: w3c-dist-auth@w3.org Message-ID: <8525680B.005810B2.00@d54mta03.raleigh.ibm.com> Date: Fri, 15 Oct 1999 12:01:11 -0400 Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Subject: Re: Static depth locking Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3474 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 like this, but let's see how many cases are left even after these simplifications. In addition, I still think we have a problem with locks moving with a resource when the move goes across server boundries. Its the old rebind vs. copy/delete sementics of move. We can move the lock for rebind semantics, but can't for copy/delete. I think your suggestion was that MOVE across servers always fails unless the collaborating servers can support distributed bind. Client applications that want to do a MOVE across servers can hide the operation in a COPY/DELETE. I am also assuming that locks aren't copied. Is this correct? "Geoffrey M. Clemm" on 10/15/99 08:12:58 AM To: w3c-dist-auth@w3.org cc: Subject: Re: Static depth locking Ooops. Forgot one comment. I would modify Alan's proposal to say: Only LOCK and UNLOCK can add or remove a lock to a resource. In particular, DELETE does not add or remove locks on resources. The reason is that a DELETE simply modifies the state of a collection (by removing one of its bindings). There still can be other bindings to that resource, and the lock should continue to apply. Only if the last binding to a resource is deleted can the server garbage collect that resource, which effectively deletes the lock. I believe that the simplicity of this rule far outweighs any benefits achieved by special casing MOVE's and DELETE's (and dynamic depth locking), both from a clients perspective (it can predict what operation will have what effect) and from a servers perspective (it doesn't have to worry about how to move/delete locks based on combinations of the user request and the state of the arguments to that request). To give a flavor of the complexity of deciding this behavior otherwise, consider the following variants of locking for a MOVE operation: pick 1 from the following 4 choices: Source is unlocked. Source inherits depth infinity lock. Source is locked. Source contains member(s) with locks. pick 1 from the following 2 choices: Parent of Source is unlocked. Parent of Source is depth 0 locked. pick 1 from the following 2 choices: Lock is a regular lock. Lock is a null lock. pick 1 from the following 2 choices Lock is by requestor. Lock is by other. pick 1 from the following 2 choices Lock is through this mapping. Lock is through different mapping. That gives us 64 interesting Source combinations. Now do the same for the Destination. That gives us 4048 interesting combinations of Source and Destination locking states for a MOVE. This situation is not conducive to enumerating the behavior for each interesting combination. Cheers, Geoff From: "Babich, Alan" Date: Thu, 5 Aug 1999 15:38:42 -0700 Why don't we do this: When you lock a collection: depth 0: shared lock placed on the collection resource: no one can add or delete members exclusive lock placed on the collection resource: only you can add or delete members. depth 1: shared lock on coll.: no one can add or delete members. First level members that exist at that time have a shared lock placed on them. exclusive lock on coll.: only you can add or delete members. First level members that exist at that time have an exclusive lock placed on them. depth infinity: shared lock on coll.: no one can add or delete members. Members at any level(including subcollections) that exist at that time have a shared lock placed on them. exclusive lock on coll.: only you can add or delete members. Members at any level (including subcollections) that exist at that time have a shared lock placed on them. When a resource is moved out of or into a collection, the lock(s) of the resource don't change (assume the move is allowed). No locks are ever created or deleted as a result of an ordinary resource or collection resource being moved (assume the move is allowed). When you unlock a collection, depth n, you do the inverse of the operation described above on the members that exist at the time the unlock of the collection is executed. Remember that a resource can be in multiple collections at the same time. In fact, in some systems, that is the normal case. If a resource X is in two collections C1 and C2, locking C1 does not prevent the resource X from being removed from collection C2. Nor does it prevent the resource X from being inserted into collection C3. There are no locks placed or removed as side effects of MOVE. Only LOCK, UNLOCK, and DELETE mess with locks. Alan Babich From w3c-dist-auth-request@w3.org Fri Oct 15 12:25: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 MAA16542 for ; Fri, 15 Oct 1999 12:25:46 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id MAA06817; Fri, 15 Oct 1999 12:13:40 -0400 (EDT) Resent-Date: Fri, 15 Oct 1999 12:13:40 -0400 (EDT) Resent-Message-Id: <199910151613.MAA06817@www19.w3.org> Date: Fri, 15 Oct 1999 12:13:35 -0400 Message-Id: <9910151613.AA19935@tantalum> From: "Geoffrey M. Clemm" To: w3c-dist-auth@w3.org In-Reply-To: <003201bf1719$63f4ebc0$1711a8c0@brain.pentaventures.com> (david@pentaventures.com) Subject: Re: resourcetype locknull Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3475 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 "summary" of the proposal was too terse. When I said: "if you are going to do depth locking, it should be static, i.e. it should be a lock on the current members of the collection" I should have said: "... it should be a lock on the collection and its current members" So every successful LOCK locks at least one resource (with no Depth header, it is exactly one resource). A key point here (which I managed to successfully obscure :-) is that a collection is a distinct resource, and a lock on the collection is independent of a lock on any of its members (separate resources, separate locks). And to emphasize, a DELETE and a MOVE are modifications to the state of the collection containing the resource being deleted/moved. For a MOVE, it is also a modification to the state of the collection containing the Destination of the move. In either case, it is not a modification to the state of the resource being deleted/moved. Cheers, Geoff From: "David Motes" -----Original Message----- From: Geoffrey M. Clemm > From: John Stracke > > For collections, this doesn't work properly with your/Alan's proposal > for static depth locking. If I'm creating a collection, I do LOCK > (404), MKCOL, LOCK--but this LOCK only locks the resources that are > there now (i.e., none). > >Your lock on the collection locks the state of that collection, i.e. >the bindings. That means that only someone with the lock can modify >the state of that collection, such as adding new bindings to it. > > So anybody else is free to come along and add > new resources, and my lock means nothing. > >Not unless they have the lock. See above. Huh? In your original post about static depth locking you say: Here is (what I consider) to be an extremely sensible proposal from Alan Babich (from a few months ago). He basically says that if you are going to do depth locking, it should be static, i.e. it should be a lock on the current members of the collection. If you MOVE things into and out of collections (because you have the appropriate lock tokens for the appropriate collections), it has no effect on the locks on those resources. Lock the CURRENT members of the collection. I believe that is what John was commenting on. This is giving me a headache :-) -David From w3c-dist-auth-request@w3.org Fri Oct 15 12:44: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 MAA17095 for ; Fri, 15 Oct 1999 12:44:30 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id MAA07354; Fri, 15 Oct 1999 12:33:05 -0400 (EDT) Resent-Date: Fri, 15 Oct 1999 12:33:05 -0400 (EDT) Resent-Message-Id: <199910151633.MAA07354@www19.w3.org> Date: Fri, 15 Oct 1999 12:32:59 -0400 Message-Id: <9910151632.AA19948@tantalum> From: "Geoffrey M. Clemm" To: w3c-dist-auth@w3.org In-Reply-To: <8525680B.005810B2.00@d54mta03.raleigh.ibm.com> (jamsden@us.ibm.com) Subject: Re: Static depth locking Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3476 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 like this, but let's see how many cases are left even after these simplifications. In addition, I still think we have a problem with locks moving with a resource when the move goes across server boundries. Its the old rebind vs. copy/delete sementics of move. We can move the lock for rebind semantics, but can't for copy/delete. I agree, but I'd state it a little differently: Neither MOVE (rebind) nor COPY "moves" a lock (only an explicit UNLOCK and LOCK can do that). The difference between a MOVE and a COPY/DELETE is that one adjusts bindings to an existing resource (leaving the locks in place) while the other creates a new resource (which will not be locked). Neither one moves locks. I think your suggestion was that MOVE across servers always fails unless the collaborating servers can support distributed bind. Yes, but note that if there is only one binding to a resource, a cross server MOVE presents no bindings challenges, because there will be no cross-server bindings that result from the MOVE. This is orthogonal to the locking question though. Client applications that want to do a MOVE across servers can hide the operation in a COPY/DELETE. Yes, with emphasis on the word *client*, and with a suitably loose definition of "hide" (i.e. there are no bindings or locks that will expose the fraud :-). I am also assuming that locks aren't copied. Is this correct? Yes. Cheers, Geoff From w3c-dist-auth-request@w3.org Fri Oct 15 13:05: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 NAA17599 for ; Fri, 15 Oct 1999 13:05:15 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id MAA08232; Fri, 15 Oct 1999 12:53:34 -0400 (EDT) Resent-Date: Fri, 15 Oct 1999 12:53:34 -0400 (EDT) Resent-Message-Id: <199910151653.MAA08232@www19.w3.org> Reply-To: From: To: "'David Motes'" , "'Geoffrey M. Clemm'" Cc: Date: Fri, 15 Oct 1999 09:47:16 -0700 Message-ID: <000401bf172d$78664a40$0100007f@conclave> 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 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3155.0 In-Reply-To: <003201bf1719$63f4ebc0$1711a8c0@brain.pentaventures.com> Subject: RE: resourcetype locknull Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3477 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 Uh, something has been taken out of context. In Alan Babich's proposal (which I favor a LOT), the depth-0 exclusive lock on the collection arranges that only the lock holder can add or delete members. Even with a depth-1 exclusive lock (which prevents alteration of existing immediate members by anyone but the lock holder) there is no problem about new members. The lock holder creates them with an exclusive lock and then inserts them in the exclusively-locked collection. This provides more than one lock to remove ultimately, but no one said this was effortless. (A multi-lock unlock-any-of-these operation would be handy and a boon to clients without doing much to server's in Alan's simply-deterministic unlock model.) If you look at the combinatorial complexity and housekeeping requirements, I say this will be an easy winner so long as depth locking is important. The fact that you can explain this simple model -- and people can still misread it -- says a lot about what you are saddled with in 2518. It takes something to implement the Babich model without literally implementing the invariants of Alan's proposal, and that tells you something about 2518's current model too. I'd say you win simply on the reduced complexity of validation and regression confirmation of an implementation. For me, being able to explain it and understand its deterministic behavior under all conditions is the key element. (Yes, I am treating LOCK NULL as orthogonal to this model.) -- Dennis Dennis E. Hamilton - - - - - - - - - - - - - mailto:infonuovo@email.com tel: +1-206-779-9430 (gsm) fax: +1-425-793-0283 http://www.infonuovo.com -----Original Message----- From: w3c-dist-auth-request@w3.org [mailto:w3c-dist-auth-request@w3.org]On Behalf Of David Motes Sent: Friday, 15 October 1999 07:27 To: Geoffrey M. Clemm Cc: w3c-dist-auth@w3.org Subject: Re: resourcetype locknull -----Original Message----- From: Geoffrey M. Clemm To: francis@ecal.com Cc: w3c-dist-auth@w3.org Date: Friday, October 15, 1999 10:26 AM Subject: Re: resourcetype locknull > From: John Stracke > > "Geoffrey M. Clemm" wrote: > > > - return a 404 if there is no resource to LOCK, > > - let the client create a "null" instance of what it wants there, > > - then the client locks that null instance and it is off and running. > > For collections, this doesn't work properly with your/Alan's proposal > for static depth locking. If I'm creating a collection, I do LOCK > (404), MKCOL, LOCK--but this LOCK only locks the resources that are > there now (i.e., none). > >Your lock on the collection locks the state of that collection, i.e. >the bindings. That means that only someone with the lock can modify >the state of that collection, such as adding new bindings to it. > > So anybody else is free to come along and add > new resources, and my lock means nothing. > >Not unless they have the lock. See above. Huh? In your original post about static depth locking you say: Here is (what I consider) to be an extremely sensible proposal from Alan Babich (from a few months ago). He basically says that if you are going to do depth locking, it should be static, i.e. it should be a lock on the current members of the collection. If you MOVE things into and out of collections (because you have the appropriate lock tokens for the appropriate collections), it has no effect on the locks on those resources. Lock the CURRENT members of the collection. I believe that is what John was commenting on. This is giving me a headache :-) -David From w3c-dist-auth-request@w3.org Fri Oct 15 14:00: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 OAA18965 for ; Fri, 15 Oct 1999 14:00:22 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id NAA10373; Fri, 15 Oct 1999 13:48:55 -0400 (EDT) Resent-Date: Fri, 15 Oct 1999 13:48:55 -0400 (EDT) Resent-Message-Id: <199910151748.NAA10373@www19.w3.org> Date: Fri, 15 Oct 1999 13:48:45 -0400 Message-Id: <9910151748.AA20014@tantalum> From: "Geoffrey M. Clemm" To: w3c-dist-auth@w3.org Subject: Simplifying RFC-2518 Locking: A proposal Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3478 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list Encouraged by some degree of enthusiasm expressed on this list for simplifying RFC-2518 locking, I've modified my earlier non-proposal in light of the recent discussions on the mailing list, and now have a real "proposal" to make. ********** A LOCK/UNLOCK request without a depth header places/removes a lock on exactly one resource (the resource identified by the request-URL). A LOCK/UNLOCK request on a URL that is not mapped to a resource will fail with a 404. You can use a depth header to place/remove locks on a collection and its members at the time of the lock. This placement/removal of locks MUST be performed atomically, or the LOCK request MUST fail. Only an explicit LOCK request ever adds a lock to a resource, and only an explicit UNLOCK request ever removes a lock from a resource. In particular, locks are not deleted as a side effect of a MOVE or a DELETE, and locks are not added as a side effect of a MOVE due to "inheriting a lock" from a collection. A request fails with a 423 if the request would modify the state of a write-locked resource for which you don't hold the lock token. The state of a basic resource is its body and its dead properties. The state of a collection is its set of bindings and its dead properties. A write-lock request on a resource that is already write-locked will fail with a 423. ********** And that's it. This does lose some functionality. It doesn't guarantee that your handle on a locked resource will always be valid, and it doesn't allow you to "add a resource" to a lock. If one or both of these are considered essential, I would be willing (but not happy :-) to add one or both of the following extensions: A Lock-Token header containing a lock token returned by a prior LOCK request can be included in a subsequent LOCK request to extend an existing LOCK. A server may fail this request if the specified lock token cannot be extended to the specified resource. A Lock-Token header may be included in any request, which will cause the request-URL to identify the resource that was identified by that URL at the time it was locked with that lock token. ********** I'll know Yaron is back from traveling when my in-box suddenly bursts into flames before my eyes (:-). Cheers, Geoff From w3c-dist-auth-request@w3.org Fri Oct 15 15:15: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 PAA20464 for ; Fri, 15 Oct 1999 15:15:54 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id PAA12557; Fri, 15 Oct 1999 15:04:09 -0400 (EDT) Resent-Date: Fri, 15 Oct 1999 15:04:09 -0400 (EDT) Resent-Message-Id: <199910151904.PAA12557@www19.w3.org> From: jamsden@us.ibm.com X-Lotus-FromDomain: IBMUS To: w3c-dist-auth@w3.org Message-ID: <8525680B.0068A4E1.00@d54mta03.raleigh.ibm.com> Date: Fri, 15 Oct 1999 15:00:56 -0400 Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Subject: Re: resourcetype locknull Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3479 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, Locking a collection means users that do not own the lock cannot modify the collection. That is, they cannot add or remove members and cannot modify the collections properties. John Stracke on 10/15/99 09:44:50 AM To: w3c-dist-auth@w3.org cc: Subject: Re: resourcetype locknull "Geoffrey M. Clemm" wrote: > - return a 404 if there is no resource to LOCK, > - let the client create a "null" instance of what it wants there, > - then the client locks that null instance and it is off and running. For collections, this doesn't work properly with your/Alan's proposal for static depth locking. If I'm creating a collection, I do LOCK (404), MKCOL, LOCK--but this LOCK only locks the resources that are there now (i.e., none). So anybody else is free to come along and add new resources, and my lock means nothing. For collections that are meant to model compound documents or some such, where the entire state of the collection needs to be treated as a unit, this is a Bad Thing. -- /==============================================================\ |John Stracke | http://www.ecal.com |My opinions are my own.| |Chief Scientist |=============================================| |eCal Corp. |Illiterate? Write today for free help! | |francis@ecal.com| | \==============================================================/ From w3c-dist-auth-request@w3.org Fri Oct 15 15:21: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 PAA20510 for ; Fri, 15 Oct 1999 15:21:45 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id PAA12687; Fri, 15 Oct 1999 15:10:20 -0400 (EDT) Resent-Date: Fri, 15 Oct 1999 15:10:20 -0400 (EDT) Resent-Message-Id: <199910151910.PAA12687@www19.w3.org> From: ccjason@us.ibm.com X-Lotus-FromDomain: IBMUS To: w3c-dist-auth@w3.org Message-ID: <8525680B.00694296.00@D51MTA03.pok.ibm.com> Date: Fri, 15 Oct 1999 15:13:59 -0400 Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Subject: One lock per resource per person? Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3480 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 an offline discussion, the following question came up... Is it possible for a single principle to have multiple locks per resource? I'd like to hear some opinions... but here are some mental exercises... Lock tokens were invented to deal with the situation where the left hand and the right hand don't know what each other is doing. Otherwise it would be sufficient to be authenticated as the entity that owns the lock. It's important to actually hold the lock to demonstrate awareness of it. (It's also why we supposedly also have to be careful how we use lockdiscovery.) This philosophy suggests that there can only be a single exclusive lock on a resource. No exceptions. If the left hand and right hand really know that they won't step on each other... they can simply use the same lock token. Even the owner of the existing exclusive lock can't get another of the same type. I suppose the one possible exception would be if they submit the existing lock token. Buf for now I'll suggest that there can only be one exclusive lock per resource. Period. This leaves the case of shared locks. I think the answer here is different. We don't exclude different people from holding the same lock. Why should we exclude the right hand and left hand? Also in the case of... /a/b I believe PersonX can already shared depth lock /a/ and still have another shared lock on /a/b. So I believe it's already possible for one principal to have multiple locks per resource. Comments? Do we require a modification to 2518? ------------------------------------------ Phone: 914-784-7569, ccjason@us.ibm.com From w3c-dist-auth-request@w3.org Fri Oct 15 15:45: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 PAA20979 for ; Fri, 15 Oct 1999 15:45:55 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id PAA13512; Fri, 15 Oct 1999 15:34:13 -0400 (EDT) Resent-Date: Fri, 15 Oct 1999 15:34:13 -0400 (EDT) Resent-Message-Id: <199910151934.PAA13512@www19.w3.org> From: jamsden@us.ibm.com X-Lotus-FromDomain: IBMUS To: w3c-dist-auth@w3.org Message-ID: <8525680B.006B6FBF.00@d54mta03.raleigh.ibm.com> Date: Fri, 15 Oct 1999 15:31:53 -0400 Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Subject: Re: One lock per resource per person? Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3481 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list A principal can only have one lock on a resource. If the lock is exclusive, then there can only be one. If the lock is shared, then getting another shared lock would not give owning principal any further capability. I don't have the spec if front of me, but I believe this is spelled out. ccjason@us.ibm.com on 10/15/99 03:13:59 PM To: w3c-dist-auth@w3.org cc: Subject: One lock per resource per person? In an offline discussion, the following question came up... Is it possible for a single principle to have multiple locks per resource? I'd like to hear some opinions... but here are some mental exercises... Lock tokens were invented to deal with the situation where the left hand and the right hand don't know what each other is doing. Otherwise it would be sufficient to be authenticated as the entity that owns the lock. It's important to actually hold the lock to demonstrate awareness of it. (It's also why we supposedly also have to be careful how we use lockdiscovery.) This philosophy suggests that there can only be a single exclusive lock on a resource. No exceptions. If the left hand and right hand really know that they won't step on each other... they can simply use the same lock token. Even the owner of the existing exclusive lock can't get another of the same type. I suppose the one possible exception would be if they submit the existing lock token. Buf for now I'll suggest that there can only be one exclusive lock per resource. Period. This leaves the case of shared locks. I think the answer here is different. We don't exclude different people from holding the same lock. Why should we exclude the right hand and left hand? Also in the case of... /a/b I believe PersonX can already shared depth lock /a/ and still have another shared lock on /a/b. So I believe it's already possible for one principal to have multiple locks per resource. Comments? Do we require a modification to 2518? ------------------------------------------ Phone: 914-784-7569, ccjason@us.ibm.com From w3c-dist-auth-request@w3.org Fri Oct 15 15:47: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 PAA21011 for ; Fri, 15 Oct 1999 15:47:49 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id PAA13611; Fri, 15 Oct 1999 15:35:54 -0400 (EDT) Resent-Date: Fri, 15 Oct 1999 15:35:54 -0400 (EDT) Resent-Message-Id: <199910151935.PAA13611@www19.w3.org> From: jamsden@us.ibm.com X-Lotus-FromDomain: IBMUS To: w3c-dist-auth@w3.org Message-ID: <8525680B.006B73BF.00@d54mta03.raleigh.ibm.com> Date: Fri, 15 Oct 1999 15:32:21 -0400 Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Subject: Re: Simplifying RFC-2518 Locking: A proposal Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3482 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list ---------------------- Forwarded by Jim Amsden/Raleigh/IBM on 10/15/99 03:32 PM --------------------------- Jim Amsden 10/15/99 03:28 PM To: "Geoffrey M. Clemm" cc: Subject: Re: Simplifying RFC-2518 Locking: A proposal (Document link: Jim Amsden) I'm all for it. You also loose the ability to reserve a name in the namespace by locking a resource that doesn't exist. (Boy when you say it that way, it really doesn't make sense). I would resist the second extension. My server currently does not associate anything with the lock token except the locked resource. In particular, it doesn't remember the URL used to lock the resource, and there is no special case URL mapping that would somehow add lock tokens to namespace resolution calculations, some of which happen outside my server's domain. It seems like if we have to do this, we're still missing something. I think the solution is that if the user is conserned about someone moving his locked resource, then he should lock the parent collection. That's what locking collections is for, to control the namespace. Alternatively, we can fail any move whose souce is locked, and the requesting principal either doesn't own the lock, or didn't specify the lock token. The confusion here is that PUT and DELETE are resource methods that effect their parent collection as a side effect. It would be better to have some addMember/removeMember methods on a collection to do this. The problems result form the behavior being in the wrong place. But this is inherited from HTTP which didn't have collections, so we'll have to work around it. Now, while we're on a role, how about getting rid of those pesky lock tokens! The only thing they seem to do is let a particular principle who is running concurrent authoring applications that might be updating the same resources detect the possibility of overwrite conflicts by distinguishing which application got the lock token by doing the LOCK, and which one got it from some other mechanism (like IPC or the user typed it in). The application that directly got the lock could proceed with its operation while the others could put up a warning indicating there might be some other application that could be updating the resource at the same time, and you might want to think about whether you want to do this operation now or not. (Now there's a warning for you). It took me quite a while to figure this out, and I may not have it right yet, but that's my interpretation of the spec. Note that clients don't have to do anything with the lock token except hang on to them and send them back when needed. The above is just a suggested convention. Not also that having a lock token doesn't give any other principle any privilege as you must own a lock token to be able to use it. I submit the problem being solved is not worth the protocol complexity and client inconvence (having to retain all those lock tokens). Note also that other systems either associate the lock with the process id (which we can't do in an HTTP server), or let the user be responsible for concurrent process he might have started up. I'd be happy that. "Geoffrey M. Clemm" on 10/15/99 01:48:45 PM To: w3c-dist-auth@w3.org cc: Subject: Simplifying RFC-2518 Locking: A proposal Encouraged by some degree of enthusiasm expressed on this list for simplifying RFC-2518 locking, I've modified my earlier non-proposal in light of the recent discussions on the mailing list, and now have a real "proposal" to make. ********** A LOCK/UNLOCK request without a depth header places/removes a lock on exactly one resource (the resource identified by the request-URL). A LOCK/UNLOCK request on a URL that is not mapped to a resource will fail with a 404. You can use a depth header to place/remove locks on a collection and its members at the time of the lock. This placement/removal of locks MUST be performed atomically, or the LOCK request MUST fail. Only an explicit LOCK request ever adds a lock to a resource, and only an explicit UNLOCK request ever removes a lock from a resource. In particular, locks are not deleted as a side effect of a MOVE or a DELETE, and locks are not added as a side effect of a MOVE due to "inheriting a lock" from a collection. A request fails with a 423 if the request would modify the state of a write-locked resource for which you don't hold the lock token. The state of a basic resource is its body and its dead properties. The state of a collection is its set of bindings and its dead properties. A write-lock request on a resource that is already write-locked will fail with a 423. ********** And that's it. This does lose some functionality. It doesn't guarantee that your handle on a locked resource will always be valid, and it doesn't allow you to "add a resource" to a lock. If one or both of these are considered essential, I would be willing (but not happy :-) to add one or both of the following extensions: A Lock-Token header containing a lock token returned by a prior LOCK request can be included in a subsequent LOCK request to extend an existing LOCK. A server may fail this request if the specified lock token cannot be extended to the specified resource. A Lock-Token header may be included in any request, which will cause the request-URL to identify the resource that was identified by that URL at the time it was locked with that lock token. ********** I'll know Yaron is back from traveling when my in-box suddenly bursts into flames before my eyes (:-). Cheers, Geoff From w3c-dist-auth-request@w3.org Fri Oct 15 16:20: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 QAA21505 for ; Fri, 15 Oct 1999 16:20:44 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id QAA14957; Fri, 15 Oct 1999 16:08:58 -0400 (EDT) Resent-Date: Fri, 15 Oct 1999 16:08:58 -0400 (EDT) Resent-Message-Id: <199910152008.QAA14957@www19.w3.org> Date: Fri, 15 Oct 1999 13:08:08 -0700 Message-ID: <4434-Fri15Oct1999130808-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: <8525680B.00694296.00@D51MTA03.pok.ibm.com> References: <8525680B.00694296.00@D51MTA03.pok.ibm.com> Subject: RE: One lock per resource per person? Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3483 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> Lock tokens were invented to deal with the situation where ccjason> the left hand and the right hand don't know what each other ccjason> is doing. Which reminds me of yet another locks-and-simplification issue.... RFC-2518 wants LOCK tokens to be universally unique. Isn't it actually sufficient that they be unique relative to the LOCKed resource, kind of along the same lines as entity tags are unique? In fact, as an implementation choice (and imagining the spec didn't explicitly prohibit it), if a server only supported exclusive write LOCKs, couldn't a server choose to trust clients to do the right thing, and use the string "button-button-you've-got-the-button" for every LOCK token issued? -- 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 Oct 15 16:42: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 QAA21729 for ; Fri, 15 Oct 1999 16:42:15 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id QAA15794; Fri, 15 Oct 1999 16:30:37 -0400 (EDT) Resent-Date: Fri, 15 Oct 1999 16:30:37 -0400 (EDT) Resent-Message-Id: <199910152030.QAA15794@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: <8525680B.0070A2D1.00@D51MTA03.pok.ibm.com> Date: Fri, 15 Oct 1999 16:34:33 -0400 Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Subject: Re: One lock per resource per person? Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3484 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list >> A principal can only have one lock on a resource. If the lock is exclusive, then there can only be one. If the lock is shared, then getting another shared lock would not give owning principal any further capability. I don't have the spec if front of me, but I believe this is spelled out. >> I believe the spec implies what you say. Feel free to double check that. It would be useful to know where it says/implies that... but I'm also suggesting a change if that's what the spec says... not just asking what the spec says. It does give new capability though. It's the right hand/left hand thing. Two independent client tools using the same ID. They both want to block writes to (coincidentally) the same resource. Sure the second locker could do a lock discovery... but then they'd also have to work out who is the last one that wants to release the the lock. Remember... these are independent tools. It won't work without some cooperation. And having multiple locks on the same resource solves this problem neatly. As my note says, it looks like the spec already supports this for inherited shared lock to some degree. If so, the issue then becomes... "Can the two shared locks owned by the same entity be rooted at the same resource?" I'm suggesting they should. J. From w3c-dist-auth-request@w3.org Fri Oct 15 16:50: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 QAA21803 for ; Fri, 15 Oct 1999 16:50:06 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id QAA15955; Fri, 15 Oct 1999 16:38:30 -0400 (EDT) Resent-Date: Fri, 15 Oct 1999 16:38:30 -0400 (EDT) Resent-Message-Id: <199910152038.QAA15955@www19.w3.org> From: ccjason@us.ibm.com X-Lotus-FromDomain: IBMUS To: bill@carpenter.ORG (WJCarpenter) cc: w3c-dist-auth@w3.org Message-ID: <8525680B.00715C0F.00@D51MTA03.pok.ibm.com> Date: Fri, 15 Oct 1999 16:42:27 -0400 Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Subject: RE: Why are lock tokens unique? Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3485 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list Which reminds me of yet another locks-and-simplification issue.... RFC-2518 wants LOCK tokens to be universally unique. Isn't it actually sufficient that they be unique relative to the LOCKed resource, kind of along the same lines as entity tags are unique? Well. 2518 does support depth locks... so a single lock token could apply to many resources. A resource could have two locks on it with the same token then. Shared locks, albeit. Also some recent proposals... like the one to remap locked request URI's would depend on unique tokens. From w3c-dist-auth-request@w3.org Sat Oct 16 21:21: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 VAA15300 for ; Sat, 16 Oct 1999 21:21:29 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id VAA04889; Sat, 16 Oct 1999 21:09:31 -0400 (EDT) Resent-Date: Sat, 16 Oct 1999 21:09:31 -0400 (EDT) Resent-Message-Id: <199910170109.VAA04889@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: <8525680D.0006571C.00@D51MTA03.pok.ibm.com> Date: Sat, 16 Oct 1999 21:13:20 -0400 Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Subject: Re: Simplifying RFC-2518 Locking: A proposal Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3486 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 would resist the second extension. My server currently does not associate anything with the lock token except the locked resource. In particular, it doesn't remember the URL used to lock the resource, Hey, it's just a little matter of coding. :-) It sounds like the server would need to maintain a lock + URI -> new URI mapping or something like that. There really wouldn't be any point in storing it with resource. That mapping table would need to be global (at least to the workspace). It would need an entry for every URI locked by a depth lock if we plan to remap each of those independently. Issues... i1) I suspect Geoff didn't mean it, but I think he said (by using the word "identify") that the server "tells" the client where the resource has moved to. (If this is not what Geoff meant... skip to (i2).) This can be a bad thing. The server should internally redirect the request to the resource at it's new location. The reason it's bad is that by the time the client accesses that new location it couild have moved again. That means the client has to go back to the original URI to to ask where it has moved again. So this means the client has to chase down the resource. It's a potential race condition and the client can never safely use the second location/URI in a request. It always has to remember the first location. -- Now this could be improved (client view) if Geoff says that a resource doesn't just remember the original location of the resource... but also subsequent. (This was what Geoff proposed a few weeks ago.) We'd need to define this more clearly but it might work. BTW this second alteration by itself doesn't save the client from chasing down the resource... but if we can define a useful deterministic behavior, it allows the client to only remember the most recent URI that he was given. This second change would also allow one to use a lock obtained via lock discovery. i2) This proposal breaks our model whereby all webdav resources have parents at their analagous parent URI. This would not be the case here unless URI protection were added. That is... a whole tree of URI's could be locked, but if someone does a MOVE above the root of that URI at which the lock request was originally directed, then there will be a gap in the parentage tree. -- I personally don't care about this, but a lot of folks went through a ton of time defining and refining how webdav resources must have a parent at their parent URI. A ton. They must feel this is a valuable feature. -- Also a lesser namespace incongruity like this was also the reason that it was claimed that lock null resources are a pain for the client. If that was to believed there... it should be a consideration here. i3) Because this model doesn't protect a URI, it isn't just possible to move a locked resource from the namespace... it's also possible to delete it from the namespace and thus removing all apparent URI's for it. Redirection won't work then. Perhaps internal redirection would still though. i4) For depth locks, we'd need to define behaivor. Given /a/b/c and a depth lock placed on /a/b/. It's pretty clear what the redirection does for an access to /a/b/. But what about /a/b/c? Does it refer to the resource that was originally at that location? Or does it refer to the current "c" member of the collection that was orginally at /a/b/. i5) We'd have to work out when the redirection is triggered. It's probably not sufficient to say it's triggered when there is no resource at a URI. It would need to also deal with the situation where a different resource is now at that location. But that does create another ambiguity rlated to (i4). Ah... it's a bit of a mess. I'm not going to get into it here. and there is no special case URL mapping that would somehow add lock tokens to namespace resolution calculations, some of which happen outside my server's domain. ??? wakarimasen (I don't understand.) It seems like if we have to do this, we're still missing something. I think the solution is that if the user is conserned about someone moving his locked resource, then he should lock the parent collection. That's what locking collections is for, to control the namespace. Lacking URI protection, he'd also lock all the collections to the root. Alternatively, we can fail any move whose souce is locked, and the requesting principal either doesn't own the lock, or didn't specify the lock token. This sounds like a version of URI protection. The version where all URI's of a lock are protected. It actually sounds fine/benign the way you describe it, but in an earlier thread Geoff and I determined that this can be expensive. (It might have been an offline thread between the AdvColl folks.) I have to admit... it really does sound attractive here though. :-) The confusion here is that PUT and DELETE are resource methods that effect their parent collection as a side effect. It would be better to have some addMember/removeMember methods on a collection to do this. The problems result form the behavior being in the wrong place. But this is inherited from HTTP which didn't have collections, so we'll have to work around it. What PUT and DELETE problem are you refering to that is related to this discussion? Now, while we're on a role, how about getting rid of those pesky lock tokens! The only thing they seem to do is let a particular principle who is running concurrent authoring applications that might be updating the same resources detect the possibility of overwrite conflicts by distinguishing which application got the lock token by doing the LOCK, and which one got it from some other mechanism (like IPC or the user typed it in). The application that directly got the lock could proceed with its operation while the others could put up a warning indicating there might be some other application that could be updating the resource at the same time, and you might want to think about whether you want to do this operation now or not. (Now there's a warning for you). It took me quite a while to figure this out, and I may not have it right yet, but that's my interpretation of the spec. I think you got that right... the part about determining which application got the token via the primary mechanism isn't right, but it doesn't affect what you say below. Note that clients don't have to do anything with the lock token except hang on to them and send them back when needed. I guess so. I don't know else they might do that you are suggesting is avoided. The above is just a suggested convention. You're losing me. :-) Not also that having a lock token doesn't give any other principle any privilege as you must own a lock token to be able to use it. Right. You can't get past a lock by stealing a lock token... unless you appear to be the principal that took out the lock in the first place. I submit the problem being solved is not worth the protocol complexity and client inconvence (having to retain all those lock tokens). Note also that other systems either associate the lock with the process id (which we can't do in an HTTP server), or let the user be responsible for concurrent process he might have started up. I'd be happy that. I think you're essentially saying that when one authenticates, there should be a way to distinguish between the applications using the same ID... or perhaps that they really should use different ID"s. The use of distinct ID's or session ID's has been discussed before. (Yaron and I had an exchange on this about two years ago... but I can't find the posting.) Yaron shot down that proposal. Reasons for tokens rather than just principles 1) Reduces the dependency on a clients generating unique and unpredictable session identifiers. (Puts control in the server's hands.) 2) Still allows the same principal to share a capability between his left and right hands if it deems it appropriate. (puts some control in the lock owner's hands.) 2.1) It's never stated, but I suspect they might have also envisioned using this as a the basis of capabilities passing system that wasn't dependent on authentication. 3) It allows for the possibility of multiple locks per resource by the same principal... without chaos. 3.1) It's a convenient way for UNLOCK to specify the lock it is removing. 4) It allows for URI remapping schemes like Geoff's. 5) The original authors seemed to feel it was important that the client at times to provide verification that it knows what locks are located where. This actually becomes essential if we don't protect URI's or remap them. (if-match headers don't support guids yet.) I think it's an interesting coincidence that you seem to have suggested the possible removal of lock tokens. I was actually mulling over another possibility. Removal of locks altogether. It was inspired by recent arguments against URI protection and lock null resources... which both are intended to protect the namespace. I eventually decided that locks are still a good thing even without URI protection (which I still advocate) and LNRs. Locks do more than just prevent the lost update problem. Later, J. From w3c-dist-auth-request@w3.org Sat Oct 16 23:16:10 1999 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA17571 for ; Sat, 16 Oct 1999 23:16:09 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id XAA05732; Sat, 16 Oct 1999 23:04:56 -0400 (EDT) Resent-Date: Sat, 16 Oct 1999 23:04:56 -0400 (EDT) Resent-Message-Id: <199910170304.XAA05732@www19.w3.org> Date: Sat, 16 Oct 1999 23:04:49 -0400 Message-Id: <9910170304.AA20533@tantalum> From: "Geoffrey M. Clemm" To: w3c-dist-auth@w3.org In-Reply-To: <8525680D.0006571C.00@D51MTA03.pok.ibm.com> (ccjason@us.ibm.com) Subject: Re: Simplifying RFC-2518 Locking: A proposal Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3487 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 would resist the second extension. My server currently does not associate anything with the lock token except the locked resource. In particular, it doesn't remember the URL used to lock the resource, Hey, it's just a little matter of coding. :-) I was wondering the same thing. It seems like a fairly easy thing to compute. If somebody tries to "MOVE" the resource outside of the resources you control, you can just fail the MOVE. Otherwise, when someone comes at you with a URL and a Lock-Token header, just look the pair up in your table, and perform the request on that resource. It sounds like the server would need to maintain a lock + URI -> new URI mapping or something like that. lock + URI -> resource. No need for the server to indirect through another URI mapping ... that would just make things hard. The nice thing about being a server is that you have real resource handles and *don't* have to indirect through URI's. There really wouldn't be any point in storing it with resource. You could just store it in the resource, and then search for it every time you get a request, but that doesn't sound like the efficient way to do it. That mapping table would need to be global (at least to the workspace). It would need an entry for every URI locked by a depth lock if we plan to remap each of those independently. Which is reasonable with static depth locks, and quite the pain with dynamic depth locks, but I digress ... (:-). Issues... i1) I suspect Geoff didn't mean it, but I think he said (by using the word "identify") that the server "tells" the client where the resource has moved to. (If this is not what Geoff meant... skip to (i2).) You are correct, that's not what I meant (:-). By "identify", I mean the server figures out what the locked resource was, and applies the method to that resource. Clients are not involved at all, so I'll skip to i2 ... i2) This proposal breaks our model whereby all webdav resources have parents at their analagous parent URI. This would not be the case here unless URI protection were added. I believe that there is no more breakage in this regard than is introduced by multiple bindings. You have a new name for a resource *other* than the name it used to have (just like adding a binding). Unlike a normal binding, this new name (the pair) is stored off in some server maintained place where clients can't mess with it. Now it's true that this new name effectively exists in a non-WebDAV namespace, but WebDAV was carefully designed to ensure that these non-WebDAV namespaces can co-exist with the WebDAV ones. The fact that this new name is bound to the same resource that exists in WebDAV space should cause no confusion. That is... a whole tree of URI's could be locked, but if someone does a MOVE above the root of that URI at which the lock request was originally directed, then there will be a gap in the parentage tree. The WebDAV resource space will have no gaps. The name is still valid. It's true that you can't treat the new name as forming a tree of any interesting kind, but that's not what it is there for. It's a way to guarantee that a client has a reliable handle on the resource it locked (e.g. for a subsequent PUT/UNLOCK). I personally don't care about this, but a lot of folks went through a ton of time defining and refining how webdav resources must have a parent at their parent URI. A ton. They must feel this is a valuable feature. -- As do I. If I were violating it, I'd be concerned. I believe we are just "supplementing" it with some additional reliable names. Also a lesser namespace incongruity like this was also the reason that it was claimed that lock null resources are a pain for the client. If that was to believed there... it should be a consideration here. That was very different. The case against a lock null resource is that it was a URL masquerading as a resource. A lock null resource is just a sleight-of-mouth (:-) for locking a name while still pretending that there was some resource being locked. The complexities that resulted stemed from the fact that there really *was* no resource to hold this lock, and so the model would break down. i3) Because this model doesn't protect a URI, it isn't just possible to move a locked resource from the namespace... it's also possible to delete it from the namespace and thus removing all apparent URI's for it. except for the special name that will continue to provide access to it. Redirection won't work then. Perhaps internal redirection would still though. The server maps this special name to a resource, not to another URI. (Life is good, when you're a server :-). i4) For depth locks, we'd need to define behaivor. Given /a/b/c and a depth lock placed on /a/b/. It's pretty clear what the redirection does for an access to /a/b/. But what about /a/b/c? Does it refer to the resource that was originally at that location? If you use the Lock-Token header, it will be the resource that was at /a/b/c when you applied the lock. Or does it refer to the current "c" member of the collection that was orginally at /a/b/. No, the Lock-Token is just there to guarantee access to the original resource. If you want to play with the current members of the collection, you'd just BIND that collection into some working collection, and then issue your requests against that new binding without the Lock-Token header. i5) We'd have to work out when the redirection is triggered. It's probably not sufficient to say it's triggered when there is no resource at a URI. It would need to also deal with the situation where a different resource is now at that location. But that does create another ambiguity rlated to (i4). Ah... it's a bit of a mess. I'm not going to get into it here. I think you're still thinking of it as a " -> new-URL" mapping ... it's not. It's " -> resource". The server stores this information in its lock table at the time of the lock request, and doesn't change it until the UNLOCK request is made. The server knows when to use the lock table when it gets a Lock-Token header. Otherwise it just ignores the lock table. and there is no special case URL mapping that would somehow add lock tokens to namespace resolution calculations, some of which happen outside my server's domain. As long as the same server handles the same segment of the URL space (e.g. nobody messes with the Apache config file), all requests for Lock-Token based URL's will go to the same server. Sure, if the client holds onto the lock token long enough for that to no longer apply, then it won't find the resource. The server just handles that like a timeout, (probably it would have timed out anyway by then :-). It seems like if we have to do this, we're still missing something. I think the solution is that if the user is conserned about someone moving his locked resource, then he should lock the parent collection. That's what locking collections is for, to control the namespace. Lacking URI protection, he'd also lock all the collections to the root. No, just the subtree being worked on. If you ever "lose" the sub-tree you were working on, you can use your "lock-token" and the original subtree root URL to find your sub-tree, bind it somewhere so you can keep working on it. If somebody moves *that* away, heck, you've still got your lock token, and you can rebind to it as often as you need to. As for Jim's suggestion that we do away with lock tokens, as Jason points out, it would require designing a session mechanism, which is probably better but more complicated than lock tokens, so it wouldn't fit into my current "simplify 2518" jihad (:-). Cheers, Geoff From w3c-dist-auth-request@w3.org Sun Oct 17 20:02: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 UAA11081 for ; Sun, 17 Oct 1999 20:02:17 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id TAA13253; Sun, 17 Oct 1999 19:48:24 -0400 (EDT) Resent-Date: Sun, 17 Oct 1999 19:48:24 -0400 (EDT) Resent-Message-Id: <199910172348.TAA13253@www19.w3.org> From: ccjason@us.ibm.com X-Lotus-FromDomain: IBMUS To: "Geoffrey M. Clemm" cc: w3c-dist-auth@w3.org Message-ID: <8525680D.0082C031.00@D51MTA03.pok.ibm.com> Date: Sun, 17 Oct 1999 19:52:13 -0400 Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Subject: Re: Simplifying RFC-2518 Locking: A proposal, lock remapping Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3488 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 mapping table would need to be global (at least to the workspace). It would need an entry for every URI locked by a depth lock if we plan to remap each of those independently. Which is reasonable with static depth locks, and quite the pain with dynamic depth locks, but I digress ... (:-). On the contrary... You don't digress. I was only evaluating it based on your static proposal... which I will comments on when I get some time. i2) This proposal breaks our model whereby all webdav resources have parents at their analagous parent URI. This would not be the case here unless URI protection were added. I believe that there is no more breakage in this regard than is introduced by multiple bindings. You have a new name for a resource *other* than the name it used to have (just like adding a binding). Hmmm. "Interesting" way of looking at it. Unlike a normal binding, this new name (the pair) is stored off in some server maintained place where clients can't mess with it. Ummm. I'm not sure I follow you. I am talking from the client's perspective that the URI parentage is not continuous. I'm not concerned about servers. I expect them to be more sophisticated than clients. (I don't know what the folks that spent so much time defining parentage care about though. I just know that they must value continuous parentage to have put so much time in on it.) Now it's true that this new name effectively exists in a non-WebDAV namespace, but WebDAV was carefully designed to ensure that these non-WebDAV namespaces can co-exist with the WebDAV ones. The fact that this new name is bound to the same resource that exists in WebDAV space should cause no confusion. I don't think I'm following you. (At the same time... I do follow you but I feel like I'm being con'ed. :-)) That is... a whole tree of URI's could be locked, but if someone does a MOVE above the root of that URI at which the lock request was originally directed, then there will be a gap in the parentage tree. The WebDAV resource space will have no gaps. The name is still valid. It's true that you can't treat the new name as forming a tree of any interesting kind, but that's not what it is there for. It's a way to guarantee that a client has a reliable handle on the resource it locked (e.g. for a subsequent PUT/UNLOCK). I guess you could say it has no gaps if you say that a client is to forget the URI where it found/locked the resource and only be concerned about the resource itself now and it's special new compound name and access method. But if a client is showing a tree view of the server (ala Windows Explorer for example) and you need to show the resource you have a lock on... you can't really show the tree if it's parents have gone away. Or could you? :-) You might be able to figure out a way to show it... but I suspect this will require twisting the mind of the user in a way that it doesn't need to be twisted. -- BTW, I don't care about tree views much, but there are a couple folks down the hall from me the worship them. And we already know of one large software company that makes heavy use of them in a popular OS. I personally don't care about this, but a lot of folks went through a ton of time defining and refining how webdav resources must have a parent at their parent URI. A ton. They must feel this is a valuable feature. -- As do I. If I were violating it, I'd be concerned. I believe we are just "supplementing" it with some additional reliable names. You were one of those folks. :-) I'll give this "new namespace" idea some time to twist my mind. I do have the feeling that I'm being brain washed. (Recent discover! The sun rises in the west. People have just been holding their compasses upside down. :-)) Another thought... if we're just going to couch this as a "new namespace" why don't we just tell folks to use (locally) locatable guid's? (Never mind. I know the answer(s).) i4) For depth locks, we'd need to define behaivor. Given /a/b/c and a depth lock placed on /a/b/. It's pretty clear what the redirection does for an access to /a/b/. But what about /a/b/c? Does it refer to the resource that was originally at that location? If you use the Lock-Token header, it will be the resource that was at /a/b/c when you applied the lock. So if you lock /a/b/ and then replace /a/b/c with another resource... one that isn't locked... what happens when you do a GET on /a/b/c with a lock token? It sounds like you get what was originally there... not what's there now. What happens if you do it without a lock token? I'm guessing you get a failure since I guess there's nothing there in the normal URI namespace. How do you access the new c member of /a/b/? Add it to the lock before you move it there? Will that work? Or perhaps use another lock on it and then move it there... and address it at it's old URI with that second lock? It sounds like that might work... but will the MOVE really work? (I think this might have been what JimA was refering to about DELETE and MOVE.) Will the MOVE know that you are adding it to the ***locked*** collection... not to the URI that is now null? Or does it refer to the current "c" member of the collection that was orginally at /a/b/. No, the Lock-Token is just there to guarantee access to the original resource. If you want to play with the current members of the collection, you'd just BIND that collection into some working collection, and then issue your requests against that new binding without the Lock-Token header. Ah... And lock that "working" collection in turn so that you could handle someone moving/deleting that collection in turn. Or possibly do this all from the start so that you wouldn't have to react. LOCK /a/b/ at depth (since we might want to protect /a/b/c and /a/b/d, etc) ; let's call the resulting token tokB Check that /a/b/ is really the resource you expected there. Possibly check children too if it's important for the action. MKCOL /tempthing to the resource or collection we want to work with. LOCK /tempthing depth 0 ; call the resulting token tokTemp Check that /tempthing is the empty coll that you just created. (Too bad we don't have lock null resources) BIND /tempthing/b/ /a/b/ providing tokA for /a/b/ ; now to remove /a/b/c from /a/b/ I'm not quite sure how to do that. I think ; it is... It's not clear what DELETE /a/b/c will do, but I think the ; following will work. DELETE /tempthing/b/c providing the tokTemp token but definitely not the tokB token. ; But no... that won't work if /tempthing has moved... since the remapping works in ; a resource by resource manner. Adding the tokTemp token won't insure that I get ; the right c resource deleted... or even the right b parent. Because neither of ; those uses the tokTemp lock. I'm stuck. There is no way to delete c out of b. ; Not until we discuss (i6) below. ; but let's pretend the DELETE above works. Let's see how many more methods are ; needed... work gets done here on the locked area of the namespace. ; Now lets assume work is done. Now to clean up... UNLOCK tokB DELETE /tempthing/ ; but what if it moved. Will adding a token fix this? We need to figure ; out how DELETE with this resolution figures out what parent we're talking about. ; I think this was JimA's point. (see (i6) below) UNLOCK tokTemp /tempthing/ ; presumably it will use the token to figure out what resource I'm refering to ; in addition to figuring out what lock I'm removing. This is in contrast to the following with URI protection... LOCK /a/b/ at depth Check if what's at /a/b/ is really what you were planning to lock. Also check children if you like. DELETE /a/b/c do some other work UNLOCK tokA This looks a lot easier for the client. Sure the first one didn't need to go to so much trouble. It just did so so that it had deterministic behavior. The latter recipe achieves deterministic behavior at much less expense for the client. i5) We'd have to work out when the redirection is triggered. It's probably not sufficient to say it's triggered when there is no resource at a URI. It would need to also deal with the situation where a different resource is now at that location. But that does create another ambiguity rlated to (i4). Ah... it's a bit of a mess. I'm not going to get into it here. I think you're still thinking of it as a " -> new-URL" mapping ... it's not. It's " -> resource". The server stores this information in its lock table at the time of the lock request, and doesn't change it until the UNLOCK request is made. The server knows when to use the lock table when it gets a Lock-Token header. Otherwise it just ignores the lock table. I see what you're saying. The remapping is not triggered on finding a null resource at a URI. It's triggered by the existance of the special header in the request. If the header is there, remapping is enabled. If it is not, then it isn't. Now let's add another issue that was revealed as I was going through the scenario in (i4)... (i6) So what does it mean to DELETE /a/b/c with a token for /a/b/c? How does it know what parent to act on? In this case is the client expected to provide a token for the parent instead? I take it this would apply to BIND and MOVE also. What if the parent doesn't have a token. In the example above... I didn't lock the / URI because that would have caused problems for other clients pulling the same trick. So what would the DELETE operator be for /tempthing/? and there is no special case URL mapping that would somehow add lock tokens to namespace resolution calculations, some of which happen outside my server's domain. As long as the same server handles the same segment of the URL space (e.g. nobody messes with the Apache config file), all requests for Lock-Token based URL's will go to the same server. Sure, if the client holds onto the lock token long enough for that to no longer apply, then it won't find the resource. The server just handles that like a timeout, (probably it would have timed out anyway by then :-). I think you may have misunderstood his question. I think he was refering to the situation I had in (i4) above where I really didn't have a reliable way to denote a new resource at /a/b/c since the token only refers to the destination, not to specific subsegments of the URI. Of course we can refine things to handle this, but it's getting more complicated. I think you two were hinting at cross server bindings. The thought of that on top of what we've already said sure is boggling. It seems like if we have to do this, we're still missing something. I think the solution is that if the user is conserned about someone moving his locked resource, then he should lock the parent collection. That's what locking collections is for, to control the namespace. Lacking URI protection, he'd also lock all the collections to the root. No, just the subtree being worked on. If you ever "lose" the sub-tree you were working on, you can use your "lock-token" and the original subtree root URL to find your sub-tree, bind it somewhere so you can keep working on it. If somebody moves *that* away, heck, you've still got your lock token, and you can rebind to it as often as you need to. Whoops on both of us. I think JimA was way ahead of us. I think he was thinking about also needing to lock the parent to unambiguously deal with BIND, DELETE and MOVE. See (i6) above. You are correct that they wouldn't need to lock to the root. Just to and including the parent. (I assumed Jim was thinking of an alternative to the remapping scheme... that's why I said what I said.) My hat goes off to JimA... it was pretty sharp of him to realize we have a problem with the parent being ambiguous for some operations. J. From w3c-dist-auth-request@w3.org Sun Oct 17 20:25: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 UAA11153 for ; Sun, 17 Oct 1999 20:25:27 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id UAA13687; Sun, 17 Oct 1999 20:14:08 -0400 (EDT) Resent-Date: Sun, 17 Oct 1999 20:14:08 -0400 (EDT) Resent-Message-Id: <199910180014.UAA13687@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: Sun, 17 Oct 1999 17:12:59 -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: <9910151748.AA20014@tantalum> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Subject: RE: Simplifying RFC-2518 Locking: A proposal Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3489 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 writes: > A LOCK/UNLOCK request without a depth header places/removes a lock on > exactly one resource (the resource identified by the request-URL). A > LOCK/UNLOCK request on a URL that is not mapped to a resource will > fail with a 404. You can use a depth header to place/remove locks on > a collection and its members at the time of the lock. This > placement/removal of locks MUST be performed atomically, or the > LOCK request MUST fail. So far I'm in agreement -- the only divergence from RFC 2518 is the removal of Null Locking. > Only an explicit LOCK request ever adds a lock to a resource, and only > an explicit UNLOCK request ever removes a lock from a resource. In > particular, locks are not deleted as a side effect of a MOVE or a > DELETE This too is OK. Even though it's a divergence from RFC2518 for MOVE/DELETE behavior, it's the approach that best minimizes user surprises for handing resources that have multiple URL mappings. >, and locks are not added as a side effect of a MOVE due to > "inheriting a lock" from a collection. This I disagree with. The intent of depth locks was to (a) support locking of composite objects with a single request, and (b) avoid two (or more) clients from splitting up locks if both try to lock the same collection at the same time using individual locks. While removing the "inheritance" qualities of locks would not affect (b), it would affect (a). Furthermore, this proposal for simplifying locks doesn't give any rationale for the change. Several servers have been able to implement this feature without any undue difficulty. Why do you consider this functionality to be so broken it needs to be changed? > A request fails with a 423 if the request would modify the state of a > write-locked resource for which you don't hold the lock token. ... or the request does not contain both the lock token and authentication credentials. > The state of a basic resource is its body and its dead properties. Live properties *are* part of the state of a resource, but are state that isn't affected by a lock. How can you have a processing action (i.e., the action that is required to create the value of a live property) without state? Furthermore, some live properties could have state, if, for example, the liveness of the property is merely a syntax check on the value of the property when it is set using PROPFIND. > The state of a collection is its set of bindings and its dead properties. A collection can also have a body as its state. This body would be affected by a lock. > A write-lock request on a resource that is already write-locked will > fail with a 423. It's completely unacceptable to have locks whose timeout cannot be refreshed. Since the way to refresh a lock is to re-issue a lock request to a locked resource, your proposal would prevent lock timeout refreshes. Making this change would result in significant interoperability problems with existing clients, a bad idea. - Jim From w3c-dist-auth-request@w3.org Sun Oct 17 20:26: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 UAA11164 for ; Sun, 17 Oct 1999 20:26:23 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id UAA13839; Sun, 17 Oct 1999 20:15:12 -0400 (EDT) Resent-Date: Sun, 17 Oct 1999 20:15:12 -0400 (EDT) Resent-Message-Id: <199910180015.UAA13839@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: Sun, 17 Oct 1999 17:13:02 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <8525680B.006B73BF.00@d54mta03.raleigh.ibm.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Subject: RE: Simplifying RFC-2518 Locking: A proposal Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3490 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list Content-Transfer-Encoding: 7bit Jim Amsden writes: > Now, while we're on a role, how about getting rid of those pesky > lock tokens! ... and while we're at it, let's break the majority of existing WebDAV clients. For example, if lock-tokens were removed from the spec., existing clients that request a lock will be surprised when they do not receive a lock token back in the response, and will flag an error. > The only thing they seem to do is let a particular principle who > is running concurrent authoring applications that might be updating the same > resources detect the possibility of overwrite conflicts by distinguishing which > application got the lock token by doing the LOCK, and which one > got it from some other mechanism (like IPC or the user typed it in). The application that > directly got the lock could proceed with its operation while the > others could put up a warning indicating there might be some other application > that could be updating the resource at the same time, and you might want to think about > whether you want to do this operation now or not. (Now there's a > warning for you). It took me quite a while to figure this out, and I may not > have it right yet, but that's my interpretation of the spec. This is the rationale for this feature. > I submit the problem being solved is not worth the > protocol complexity and client inconvence (having to retain all those lock > tokens). You may be right. But, at this point, more interoperability problems would be introduced by "fixing" this problem than would be removed by removing lock tokens. As your implementation experience shows, client-side handling of lock tokens is simply tedious, and isn't a show-stopper. Given a tradeoff between potentially show-stopping interoperability problems with existing clients (removing lock tokens from 2518), and a non-show-stopping programming tedium (keeping things as is), I'm very much in favor of the status quo. - Jim From w3c-dist-auth-request@w3.org Sun Oct 17 20:28: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 UAA11175 for ; Sun, 17 Oct 1999 20:28:16 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id UAA13931; Sun, 17 Oct 1999 20:17:08 -0400 (EDT) Resent-Date: Sun, 17 Oct 1999 20:17:08 -0400 (EDT) Resent-Message-Id: <199910180017.UAA13931@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: Sun, 17 Oct 1999 17:16:10 -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: <4434-Fri15Oct1999130808-0700-bill@carpenter.ORG> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Subject: RE: One lock per resource per person? Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3491 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 wants LOCK tokens to be universally unique. Isn't it > actually sufficient that they be unique relative to the LOCKed > resource, kind of along the same lines as entity tags are unique? The strongest requirement for globally unique lock tokens comes from looking at the future where there could be multiple WebDAV servers participating in a cooperative cluster. In that case, having globally unique lock tokens would prevent lock token collisions. My original rationale for uniqueness can be found in the archives at: http://lists.w3.org/Archives/Public/w3c-dist-auth/1997JanMar/0325.html (I found this URL by going to Google http://www.google.com/ and searching on "lock token uniqueness"). - Jim From w3c-dist-auth-request@w3.org Mon Oct 18 02:48: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 CAA25768 for ; Mon, 18 Oct 1999 02:48:32 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id CAA17173; Mon, 18 Oct 1999 02:36:28 -0400 (EDT) Resent-Date: Mon, 18 Oct 1999 02:36:28 -0400 (EDT) Resent-Message-Id: <199910180636.CAA17173@www19.w3.org> Message-ID: <380ABFD4.F3D0D6B6@de.bosch.com> Date: Mon, 18 Oct 1999 08:36:04 +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: <9910170304.AA20533@tantalum> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: Simplifying RFC-2518 Locking: A proposal Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3492 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 was wondering the same thing. It seems like a fairly easy thing to > compute. If somebody tries to "MOVE" the resource outside of the > resources you control, you can just fail the MOVE. Otherwise, when > someone comes at you with a URL and a Lock-Token header, just look the > pair up in your table, and perform the request on that resource. > > It sounds like the server would > need to maintain a lock + URI -> new URI mapping or something > like that. > > lock + URI -> resource. No need for the server to indirect through > another URI mapping ... that would just make things hard. The nice > thing about being a server is that you have real resource handles > and *don't* have to indirect through URI's. I would vote for a lock + URI -> new URI mapping. More below. > i1) I suspect Geoff didn't mean it, but I think he said (by using the > word "identify") that the server "tells" the client where the resource > has moved to. (If this is not what Geoff meant... skip to (i2).) > > You are correct, that's not what I meant (:-). By "identify", I mean > the server figures out what the locked resource was, and applies the > method to that resource. Clients are not involved at all, so I'll > skip to i2 ... My idea was that the server will tell the client in this case just the new URI. Then he can forget the mapping because the client now knows the new URI and can reaccess it. Also the client can signal his user that the resource has moved. If it is moved again before accessing it (a rare event I think) the client will just get a new URI again. Do you see any problems ? BTW, I also don't want depth locks and lock null resources compicating my client. 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 Mon Oct 18 08:29:55 1999 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA00581 for ; Mon, 18 Oct 1999 08:29:52 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id IAA20990; Mon, 18 Oct 1999 08:15:58 -0400 (EDT) Resent-Date: Mon, 18 Oct 1999 08:15:58 -0400 (EDT) Resent-Message-Id: <199910181215.IAA20990@www19.w3.org> Date: Mon, 18 Oct 1999 08:15:48 -0400 Message-Id: <9910181215.AA21066@tantalum> From: "Geoffrey M. Clemm" To: w3c-dist-auth@w3.org In-Reply-To: <380ABFD4.F3D0D6B6@de.bosch.com> (message from Edgar Schwarz on Mon, 18 Oct 1999 08:36:04 +0200) Subject: Simplifying RFC-2518 Locking: A second proposal Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3493 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list First, thanks to JimW for pointing out several areas of poor word choice in the original proposal. I didn't mean to eliminate the ability to refresh a lock, and didn't mean to say that the live properties were not part of the state of a resource ... just that they were not part of the *lockable* state of the resource. From: Edgar Schwarz I suspect Geoff didn't mean it, but I think he said (by using the word "identify") that the server "tells" the client where the resource has moved to. My idea was that the server will tell the client in this case just the new URI. Then he can forget the mapping because the client now knows the new URI and can reaccess it. Also the client can signal his user that the resource has moved. If it is moved again before accessing it (a rare event I think) the client will just get a new URI again. Do you see any problems ? I actually see any problem with this ... I just wasn't thinking along those lines (even though after reviewing the mail archives, it's something that both you and Jason have brought up). And the more that I (finally! :-) do think about it, the more I like it. Returning a 302 is enshrined HTTP behavior (for good reason). We're even defining a new resource type (redirect references) just so that we can give the client the ability to specify this useful functionality. So clients in general will be designed to handle this case. Jason raised the issue of a "race" condition (i.e. every time you try to access your locked resource, you get back a new "302" because some other client keeps moving it). My response is that if your client just updates it's location table (as opposed to trying to move it back), there is no race condition. The probability of someone trying to rapidly move it around to a different locations is so low that I really don't think that we need to be concerned with that possibility. Finally, I think that the 302 approach gives us the best of both worlds. An implementation can chose to just fail any DELETE or MOVE that would make a locked resource no longer appear at the locking URL. Clients need to handle DELETE's and MOVE's failing anyway (e.g. the collection containing the resource is locked). Alternatively, an implementation can chose to allow the DELETE or MOVE, as long as it is tracking an alternative URL that it can give back to the client for the 302 response. Again, clients need to handle 302's anyway, so this is again straightforward for a client to deal with. Flexibility for server implementors with little/no additional cost to clients. BTW, I also don't want depth locks and lock null resources complicating my client. In my earlier proposal, I included static depth locking as a "compromise" for the depth locking advocates. But as JimW (as depth locking spokesman :-) points out, that's not what depth locking advocates want ... they want dynamic depth locking. So it's time to rev the lock simplification proposal: Add in the 302 behavior that Edgar advocates, and take out depth locking altogether. A couple of notes about depth locking: (1) I don't see client writers clamoring for it ... the only strong voices in its support appear to be the 2518 authors. It would be great if the client writers on this list would weigh in here with some opinions/guidance. (2) The reality is that depth locking is not provided in one of the key WebDAV platforms (Office 2000). As fun as it is to bash Microsoft, the Microsoft file system guys probably know as much or more than anyone about the proper use of file locks for concurrent access management. The fact that they chose not to support them is in my opinion significant. If nothing else, it is significant in that any client that wants to work against the Office 2000 server had better not expect a depth lock request to succeed. Obviously this can't be our sole reason for taking them out, but if it seems like a 50/50 call, it is a factor. So without more ado, here's the modified simplified locking proposal. Cheers, Geoff ***** Simplified RFC-2518 Locking, Version-2 ***** A LOCK/UNLOCK request places/removes a lock on exactly one resource (the resource identified by the request-URL). A LOCK/UNLOCK request on a URL that is not mapped to a resource will fail with a 404. Only an explicit LOCK request ever adds a lock to a resource, and only an explicit UNLOCK request ever removes a lock from a resource. In particular, locks are not deleted as a side effect of a MOVE or a DELETE, and locks are not added as a side effect of a MOVE due to "inheriting a lock" from a collection. A request fails with a 423 if the request would modify the state of a write-locked resource for which you don't hold (and specify) the lock token. The state of a basic resource that is affected by a lock is its body and its dead properties. The state of a collection that is affected by a lock is its set of bindings, its body, and its dead properties. A write-lock request on a resource that is already write-locked will fail with a 423 unless it is an explicit "refresh" of an existing lock. When a Lock-Token header is included in any request, if the locked resource is no longer available at that URL, the server MUST return a 302 indicating a new URL at which the locked resource is available. A server MAY refuse to perform a MOVE/DELETE that would cause a locked resource to no longer be available at the locked URL. ***** End: Simplified RFC-2518 Locking, Version-2 ***** From w3c-dist-auth-request@w3.org Mon Oct 18 09:17: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 JAA03168 for ; Mon, 18 Oct 1999 09:17:44 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id JAA22986; Mon, 18 Oct 1999 09:05:16 -0400 (EDT) Resent-Date: Mon, 18 Oct 1999 09:05:16 -0400 (EDT) Resent-Message-Id: <199910181305.JAA22986@www19.w3.org> From: jamsden@us.ibm.com X-Lotus-FromDomain: IBMUS To: w3c-dist-auth@w3.org Message-ID: <8525680E.0047C9AA.00@d54mta03.raleigh.ibm.com> Date: Mon, 18 Oct 1999 09:01:27 -0400 Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Subject: RE: Simplifying RFC-2518 Locking: A proposal Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3494 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list ---------------------- Forwarded by Jim Amsden/Raleigh/IBM on 10/18/99 09:01 AM --------------------------- Jim Amsden 10/18/99 09:01 AM To: Jim Whitehead cc: Subject: RE: Simplifying RFC-2518 Locking: A proposal (Document link: Jim Amsden) You may be right. But, at this point, more interoperability problems would be introduced by "fixing" this problem than would be removed by removing lock tokens. As your implementation experience shows, client-side handling of lock tokens is simply tedious, and isn't a show-stopper. Given a tradeoff between potentially show-stopping interoperability problems with existing clients (removing lock tokens from 2518), and a non-show-stopping programming tedium (keeping things as is), I'm very much in favor of the status quo. I don't know about other client writers, but I would be more than happy to take the lock token handling code out of my clients. It was a lot of work (persisting them, knowing what methods had to include them, etc.) that seemed to add very little. I suspect most clients would work just fine if the server returned a constant for the lock token for compatibility purposes. What do others think? I would also like to see the spec stabilize. This was just an attempt to see what other thought, and to be sure everyone knows what these lock tokens can and can't do. From w3c-dist-auth-request@w3.org Mon Oct 18 09:22: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 JAA03433 for ; Mon, 18 Oct 1999 09:22:35 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id JAA23378; Mon, 18 Oct 1999 09:10:48 -0400 (EDT) Resent-Date: Mon, 18 Oct 1999 09:10:48 -0400 (EDT) Resent-Message-Id: <199910181310.JAA23378@www19.w3.org> From: jamsden@us.ibm.com X-Lotus-FromDomain: IBMUS To: w3c-dist-auth@w3.org Message-ID: <8525680E.00485763.00@d54mta03.raleigh.ibm.com> Date: Mon, 18 Oct 1999 09:06:31 -0400 Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Subject: RE: Simplifying RFC-2518 Locking: A proposal Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3495 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list A collection can also have a body as its state. This body would be affected by a lock. I understand a MKCOL method can include an entity request body, but the use of that body is not yet defined in WebDAV. I believe the spec says something about the body being used to create initial members of the collection. I dont remember anything about a collection having a body. Servers can define what GET on a collection means, but this (by convention) usually means returning the body of some distinguished member of the collection, the index page or some such thing. From w3c-dist-auth-request@w3.org Mon Oct 18 11:38: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 LAA10148 for ; Mon, 18 Oct 1999 11:38:38 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id LAA28821; Mon, 18 Oct 1999 11:26:33 -0400 (EDT) Resent-Date: Mon, 18 Oct 1999 11:26:33 -0400 (EDT) Resent-Message-Id: <199910181526.LAA28821@www19.w3.org> Message-ID: <380B3C01.3B275FC5@ecal.com> Date: Mon, 18 Oct 1999 11:25: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: w3c-dist-auth@w3.org References: <8525680E.00485763.00@d54mta03.raleigh.ibm.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: Simplifying RFC-2518 Locking: A proposal Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3496 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: > > A collection can also have a body as its state. This body would be affected > by a lock. > > I understand a MKCOL method can include an entity request body, but the use of > that body is not yet defined in WebDAV. I believe the spec says something about > the body being used to create initial members of the collection. I dont remember > anything about a collection having a body. Servers can define what GET on a > collection means, but this (by convention) usually means returning the body of > some distinguished member of the collection, the index page or some such thing. Yes, and that's the body of the collection. -- /==============================================================\ |John Stracke | http://www.ecal.com |My opinions are my own.| |Chief Scientist |=============================================| |eCal Corp. |The plural of mongoose is polygoose. | |francis@ecal.com| | \==============================================================/ From w3c-dist-auth-request@w3.org Mon Oct 18 11:39: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 LAA10212 for ; Mon, 18 Oct 1999 11:39:10 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id LAA28864; Mon, 18 Oct 1999 11:27:06 -0400 (EDT) Resent-Date: Mon, 18 Oct 1999 11:27:06 -0400 (EDT) Resent-Message-Id: <199910181527.LAA28864@www19.w3.org> Message-ID: <380B3C2F.E05F950A@ecal.com> Date: Mon, 18 Oct 1999 11:26:39 -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: <8525680E.0047C9AA.00@d54mta03.raleigh.ibm.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: Simplifying RFC-2518 Locking: A proposal Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3497 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: > I suspect most clients would work just fine if the server returned a > constant for the lock token for compatibility purposes. What do others think? Constant lock tokens have the problem that they can't expire. -- /==============================================================\ |John Stracke | http://www.ecal.com |My opinions are my own.| |Chief Scientist |=============================================| |eCal Corp. |The plural of mongoose is polygoose. | |francis@ecal.com| | \==============================================================/ From w3c-dist-auth-request@w3.org Mon Oct 18 12:11: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 MAA11321 for ; Mon, 18 Oct 1999 12:11:47 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id LAA00243; Mon, 18 Oct 1999 11:59:57 -0400 (EDT) Resent-Date: Mon, 18 Oct 1999 11:59:57 -0400 (EDT) Resent-Message-Id: <199910181559.LAA00243@www19.w3.org> From: jamsden@us.ibm.com X-Lotus-FromDomain: IBMUS To: w3c-dist-auth@w3.org Message-ID: <8525680E.0057D565.00@d54mta03.raleigh.ibm.com> Date: Mon, 18 Oct 1999 11:57:14 -0400 Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Subject: Re: Simplifying RFC-2518 Locking: A proposal Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3498 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 lock can expire for the principle owning the lock, not the lock token. This implies a principle can't own multiple locks on the same resource which is already the case. John Stracke on 10/18/99 11:26:39 AM To: w3c-dist-auth@w3.org cc: Subject: Re: Simplifying RFC-2518 Locking: A proposal jamsden@us.ibm.com wrote: > I suspect most clients would work just fine if the server returned a > constant for the lock token for compatibility purposes. What do others think? Constant lock tokens have the problem that they can't expire. -- /==============================================================\ |John Stracke | http://www.ecal.com |My opinions are my own.| |Chief Scientist |=============================================| |eCal Corp. |The plural of mongoose is polygoose. | |francis@ecal.com| | \==============================================================/ From w3c-dist-auth-request@w3.org Mon Oct 18 18:02: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 SAA20195 for ; Mon, 18 Oct 1999 18:02:28 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id RAA09055; Mon, 18 Oct 1999 17:50:43 -0400 (EDT) Resent-Date: Mon, 18 Oct 1999 17:50:43 -0400 (EDT) Resent-Message-Id: <199910182150.RAA09055@www19.w3.org> Date: Mon, 18 Oct 1999 14:49:42 -0700 Message-ID: <3430-Mon18Oct1999144942-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: <4434-Fri15Oct1999130808-0700-bill@carpenter.ORG> Subject: RE: One lock per resource per person? Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3499 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 jw> The strongest requirement for globally unique lock tokens comes jw> from looking at the future where there could be multiple WebDAV jw> servers participating in a cooperative cluster. In that case, jw> having globally unique lock tokens would prevent lock token jw> collisions. Isn't this a quality-of-implementation issue? If multiple servers need to access the same physical repository, a privately-arranged scheme can be used to keep them from colliding with each other (possibly even some server acting as a clearinghouse for doling out LOCK tokens). -- 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 Mon Oct 18 18:10: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 SAA20277 for ; Mon, 18 Oct 1999 18:10:49 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id RAA09181; Mon, 18 Oct 1999 17:59:06 -0400 (EDT) Resent-Date: Mon, 18 Oct 1999 17:59:06 -0400 (EDT) Resent-Message-Id: <199910182159.RAA09181@www19.w3.org> Date: Mon, 18 Oct 1999 14:58:09 -0700 Message-ID: <3849-Mon18Oct1999145809-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: <8525680B.006B73BF.00@d54mta03.raleigh.ibm.com> Subject: RE: Simplifying RFC-2518 Locking: A proposal Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3500 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 jw> ... and while we're at it, let's break the majority of existing jw> WebDAV clients. IMHO, WebDAV is not so mature at this point that it is out-of-bounds to break existing implementations. Of course, what is sufficiently important for that is a bit subjective. One can see these distinct groups of implementations today, both in clients and servers: 1. Nobody much using them. (We don't care if they're broken by a change) 2. Nobody keeping them up. (Many of these are broken in other interesting ways ... if their creators don't care, why should we?) 3. Actively maintained. (Authors of these will accommodate reasonable changes. In fact, as others have mentioned from time to time, they would be happy to rip out implementations of hairy things even though they have already gone to all the bother of putting it in in the first place.) jw> For example, if lock-tokens were removed from the spec., existing clients jw> that request a lock will be surprised when they do not receive a lock token jw> back in the response, and will flag an error. Before I got around to implementing real LOCKs and tokens, I just returned the same static string for every request. This doesn't cover all cases and all scenarios, but for a client to object it would probably have to be correlating multiple LOCK tokens against different resources, and it would have to care about that. -- 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 Mon Oct 18 20:04: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 UAA21136 for ; Mon, 18 Oct 1999 20:04:12 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id TAA11647; Mon, 18 Oct 1999 19:52:19 -0400 (EDT) Resent-Date: Mon, 18 Oct 1999 19:52:19 -0400 (EDT) Resent-Message-Id: <199910182352.TAA11647@www19.w3.org> Message-ID: <078292D50C98D2118D090008C7E9C6A603C96726@STAY.platinum.corp.microsoft.com> From: "Yaron Goland (Exchange)" To: "'bill@carpenter.ORG'" , w3c-dist-auth@w3.org Date: Mon, 18 Oct 1999 16:52:09 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Subject: RE: One lock per resource per person? Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3501 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 were also made unique so that we could use them across resources. For example, I may want to say "Only make this change to resource A if resource B is still locked." There were two ways to do this: Way 1 - Specifying a URI/identifier pair, e.g. If: Way 2 - Require the lock identifier to be globally unique, e.g. if: ook:dldifjsojeferfoo/bar/ickygladsfyu The problem with Way 1 is that if the URI of the resource is ever handed over to a different system that system may not necessarily be away of all the identifiers that the previous owner issued. This same problem exists for E-Tags. We considered this a flaw in the system and fixed it by using Way 2, requiring that all identifiers be globally unique. Given how cheap and easy it is to generate GUIDs we didn't feel the requirement was particularly onerous. Yaron (who is NOT reading the group, really, I'm not, if I were I would be screaming bloody murder about the horrors Jeff wants to visit upon our lock design but I'm not reading the group, I'm not damn it!) > -----Original Message----- > From: bill@carpenter.ORG [mailto:bill@carpenter.ORG] > Sent: Mon, October 18, 1999 2:50 PM > To: w3c-dist-auth@w3.org > Subject: RE: One lock per resource per person? > > > jw> The strongest requirement for globally unique lock tokens comes > jw> from looking at the future where there could be multiple WebDAV > jw> servers participating in a cooperative cluster. In that case, > jw> having globally unique lock tokens would prevent lock token > jw> collisions. > > Isn't this a quality-of-implementation issue? If multiple servers > need to access the same physical repository, a privately-arranged > scheme can be used to keep them from colliding with each other > (possibly even some server acting as a clearinghouse for doling out > LOCK tokens). > -- > 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 Mon Oct 18 20:53: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 UAA21414 for ; Mon, 18 Oct 1999 20:53:02 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id UAA12216; Mon, 18 Oct 1999 20:41:50 -0400 (EDT) Resent-Date: Mon, 18 Oct 1999 20:41:50 -0400 (EDT) Resent-Message-Id: <199910190041.UAA12216@www19.w3.org> From: Jim Whitehead To: WebDAV WG Date: Mon, 18 Oct 1999 17:40:44 -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: New Advanced Collections I-Ds available Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3502 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 New revisions of the three Advanced Collections specifications have been submitted to the IETF. They'll be showing up in the Internet-Drafts repository in the next couple of days. I have placed these drafts up on the WebDAV WG web site . The drafts are: "WebDAV Bindings" http://www.ics.uci.edu/pub/ietf/webdav/collection/draft-ietf-webdav-binding- protocol-01.txt "WebDAV Redirect Reference Resources" http://www.ics.uci.edu/pub/ietf/webdav/collection/draft-ietf-webdav-redirect ref-protocol-01.txt "WebDAV Ordered Collections Protocol" http://www.ics.uci.edu/pub/ietf/webdav/collection/draft-ietf-webdav-ordering -protocol-01.txt The authors on all are Judith Slein, Jim Whitehead, Jim Davis, Geoff Clemm, Chuck Fay, Jason Crawford, Tyson Chihaya. Judy has done her typical excellent job of driving discussion forward on these drafts, as well as putting out the next drafts revisions. Thank you! Note that if you're planning on attending the WebDAV WG meeting in Washington, DC, we will be expecting that you have read through these drafts, and are ready and prepared to discuss them. Unlike previous WebDAV WG meetings, there will be no overview slides -- this material has been introduced many times in the past. - Jim From w3c-dist-auth-request@w3.org Mon Oct 18 20:54: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 UAA21439 for ; Mon, 18 Oct 1999 20:54:19 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id UAA12263; Mon, 18 Oct 1999 20:43:09 -0400 (EDT) Resent-Date: Mon, 18 Oct 1999 20:43:09 -0400 (EDT) Resent-Message-Id: <199910190043.UAA12263@www19.w3.org> From: ccjason@us.ibm.com X-Lotus-FromDomain: IBMUS To: bill@carpenter.ORG (WJCarpenter) cc: w3c-dist-auth@w3.org Message-ID: <8525680F.0003E9E0.00@D51MTA03.pok.ibm.com> Date: Mon, 18 Oct 1999 20:46:46 -0400 Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Subject: RE: Globally unique tokens. Was: One lock per resource per person? Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3503 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list jw> The strongest requirement for globally unique lock tokens comes jw> from looking at the future where there could be multiple WebDAV jw> servers participating in a cooperative cluster. In that case, jw> having globally unique lock tokens would prevent lock token jw> collisions. Isn't this a quality-of-implementation issue? If multiple servers need to access the same physical repository, a privately-arranged scheme can be used to keep them from colliding with each other (possibly even some server acting as a clearinghouse for doling out LOCK tokens). Bill, So you are suggesting that they don't need to be *globally* unique as long as they are unique within the cluster? From w3c-dist-auth-request@w3.org Mon Oct 18 21:06: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 VAA21596 for ; Mon, 18 Oct 1999 21:06:14 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id UAA12630; Mon, 18 Oct 1999 20:54:21 -0400 (EDT) Resent-Date: Mon, 18 Oct 1999 20:54:21 -0400 (EDT) Resent-Message-Id: <199910190054.UAA12630@www19.w3.org> From: ccjason@us.ibm.com X-Lotus-FromDomain: IBMUS To: w3c-dist-auth@w3.org Message-ID: <8525680F.0004EFDA.00@D51MTA03.pok.ibm.com> Date: Mon, 18 Oct 1999 20:57:57 -0400 Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Subject: Re: One lock per resource per person? Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3504 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 original question seems to have gotten lost in a tangent. I'd appreciate hearing more voices on this original issue which now is... "Can the two shared locks owned by the same principal be rooted at the same resource?" --------------------------------------------------------- To: w3c-dist-auth@w3.org Subject: Re: One lock per resource per person? A principal can only have one lock on a resource. If the lock is exclusive, then there can only be one. If the lock is shared, then getting another shared lock would not give owning principal any further capability. I don't have the spec if front of me, but I believe this is spelled out. I believe the spec implies what you say. Feel free to double check that. It would be useful to know where it says/implies that... but I'm also suggesting a change if that's what the spec says... not just asking what the spec says. It does give new capability though. It's the right hand/left hand thing. Two independent client tools using the same ID. They both want to block writes to (coincidentally) the same resource. Sure the second locker could do a lock discovery... but then they'd also have to work out who is the last one that wants to release the the lock. Remember... these are independent tools. It won't work without some cooperation. And having multiple locks on the same resource solves this problem neatly. As my note says, it looks like the spec already supports this for inherited shared lock to some degree. If so, the issue then becomes... "Can the two shared locks owned by the same entity be rooted at the same resource?" I'm suggesting they should. J. From w3c-dist-auth-request@w3.org Tue Oct 19 07:05: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 HAA08913 for ; Tue, 19 Oct 1999 07:05:32 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id GAA22752; Tue, 19 Oct 1999 06:53:36 -0400 (EDT) Resent-Date: Tue, 19 Oct 1999 06:53:36 -0400 (EDT) Resent-Message-Id: <199910191053.GAA22752@www19.w3.org> Message-Id: <199910191053.GAA08581@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: w3c-dist-auth@w3.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Tue, 19 Oct 1999 06:53:26 -0400 Subject: I-D ACTION:draft-ietf-webdav-redirectref-protocol-01.txt Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3507 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the WWW Distributed Authoring and Versioning Working Group of the IETF. Title : WebDAV Redirect Reference Resources Author(s) : J. Slein, E. Whitehead, J. Davis, G. Clemm, C. Fay, J. Crawford, T. Chaihaya Filename : draft-ietf-webdav-redirectref-protocol-01.txt Pages : 26 Date : 18-Oct-99 The WebDAV Distributed Authoring Protocol provides basic support for collections, offering the ability to create and list unordered collections. This specification is one of a group of three specifications that supplement the WebDAV Distributed Authoring Protocol to increase the power of WebDAV collections. This specification defines redirect reference resources, one mechanism for allowing a single resource to appear in more than one collection. A redirect reference resource is a resource in one collection that responds to most requests by redirecting the request (using an HTTP 1.1 302 Found response) to a different resource, possibly in a different collection. 'WebDAV Bindings'[B] defines bindings, another approach to allowing a single resource to be accessed from multiple collections. 'WebDAV Ordered Collections Protocol'[OC] provides ordered collections. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-webdav-redirectref-protocol-01.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-webdav-redirectref-protocol-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-webdav-redirectref-protocol-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <19991018122041.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-webdav-redirectref-protocol-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-webdav-redirectref-protocol-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19991018122041.I-D@ietf.org> --OtherAccess-- --NextPart-- From w3c-dist-auth-request@w3.org Tue Oct 19 07:05: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 HAA08924 for ; Tue, 19 Oct 1999 07:05:45 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id GAA22685; Tue, 19 Oct 1999 06:53:27 -0400 (EDT) Resent-Date: Tue, 19 Oct 1999 06:53:27 -0400 (EDT) Resent-Message-Id: <199910191053.GAA22685@www19.w3.org> Message-Id: <199910191053.GAA08567@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: w3c-dist-auth@w3.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Tue, 19 Oct 1999 06:53:20 -0400 Subject: I-D ACTION:draft-ietf-webdav-ordering-protocol-01.txt Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3506 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the WWW Distributed Authoring and Versioning Working Group of the IETF. Title : WebDAV Ordered Collections Protocol Author(s) : J. Slein, E. Whitehead, J. Davis, G. Clemm, C. Fay, J. Crawford, T. Chihaya Filename : draft-ietf-webdav-ordering-protocol-01.txt Pages : 22 Date : 18-Oct-99 The WebDAV Distributed Authoring Protocol provides basic support for collections, offering the ability to create and list unordered collections. This specification is one of a group of three specifications that supplement the WebDAV Distributed Authoring Protocol to increase the power of WebDAV collections. This specification defines a protocol supporting server-side ordering of collection members. The companion specifications 'WebDAV Bindings'[B] and 'WebDAV Redirect Reference Resources'[RR] define two mechanisms for allowing a single resource to appear in more than one collection. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-webdav-ordering-protocol-01.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-webdav-ordering-protocol-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-webdav-ordering-protocol-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <19991018122029.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-webdav-ordering-protocol-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-webdav-ordering-protocol-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19991018122029.I-D@ietf.org> --OtherAccess-- --NextPart-- From w3c-dist-auth-request@w3.org Tue Oct 19 07:06: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 HAA08935 for ; Tue, 19 Oct 1999 07:06:09 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id GAA22658; Tue, 19 Oct 1999 06:53:23 -0400 (EDT) Resent-Date: Tue, 19 Oct 1999 06:53:23 -0400 (EDT) Resent-Message-Id: <199910191053.GAA22658@www19.w3.org> Message-Id: <199910191053.GAA08553@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: w3c-dist-auth@w3.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Tue, 19 Oct 1999 06:53:15 -0400 Subject: I-D ACTION:draft-ietf-webdav-binding-protocol-01.txt Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3505 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the WWW Distributed Authoring and Versioning Working Group of the IETF. Title : WebDAV Bindings Author(s) : J. Slein, E. Whitehead, J. Davis, G. Clemm, C. Fay, J. Crawford, T. Chihaya Filename : draft-ietf-webdav-binding-protocol-01.txt Pages : 25 Date : 18-Oct-99 The WebDAV Distributed Authoring Protocol provides basic support for collections, offering the ability to create and list unordered collections. This specification is one of a group of three specifications that supplement the WebDAV Distributed Authoring Protocol to increase the power of WebDAV collections. This specification defines bindings, one mechanism for allowing a single resource to appear in more than one collection. Bindings make this possible by creating mappings of URIs to resources. The BIND method defined here gives clients the ability to create new bindings to existing resources. The second specification, 'WebDAV Redirect Reference Resources'[RR], defines redirect references, another approach to allowing a single resource to be accessed from multiple collections. The third specification, 'WebDAV Ordered Collections Protocol'[OC], provides a mechanism for ordering collections. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-webdav-binding-protocol-01.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-webdav-binding-protocol-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-webdav-binding-protocol-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <19991018122012.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-webdav-binding-protocol-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-webdav-binding-protocol-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19991018122012.I-D@ietf.org> --OtherAccess-- --NextPart-- From w3c-dist-auth-request@w3.org Tue Oct 19 11:32: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 LAA22368 for ; Tue, 19 Oct 1999 11:32:46 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id LAA01589; Tue, 19 Oct 1999 11:17:22 -0400 (EDT) Resent-Date: Tue, 19 Oct 1999 11:17:22 -0400 (EDT) Resent-Message-Id: <199910191517.LAA01589@www19.w3.org> From: jamsden@us.ibm.com X-Lotus-FromDomain: IBMUS To: w3c-dist-auth@w3.org Message-ID: <8525680F.0053CE57.00@d54mta03.raleigh.ibm.com> Date: Tue, 19 Oct 1999 11:15:39 -0400 Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Subject: Re: Versioning spec review - 02.3 Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3508 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 would like to personally thank you for the incredibly hard work you have done on the spec. I know I speak for everyone in the DELTA-V working group when I say how much we appreciate the effort. But I still don't like repositories! Some additional comments below in tags. "Geoffrey M. Clemm" on 10/19/99 01:44:03 AM To: ietf-dav-versioning@w3.org cc: Subject: Re: Versioning spec review - 02.3 Also, core is described as providing versioning of largely independent resources. Independent with respect to what? Most web applications are highly linked resources, so this level of versioning by implication isn't particularly useful. What exactly is meant by this statement? I think independent in this case refers at least in part to independent changes in the resources, not necessarily just independent resources. Core versioning does not provide baselines, activities, or versioned resources. Web resources may be highly linked, but core versioning doesn't give you anything in particular to version control those links. Again, I think the important thing is that the resources don't need to be independent, its the changes made to them that are not supported by core versioning alone, and therefore these changes should be largely independent. I think the paragraph is just a little missleading, and focuses on the wrong issue. Last paragraph: How about using components of versioning support instead of "levels"? "Components" is so over-used these days, that I hate to add another meaning. But they aren't levels. They are mostly independent features. How about "features" or "versioning functions"? 1.2, Versionable Resource: Might want to put what it means to place a null resource under version control. Does it become a resource with an empty body? That's a little hard, since what if you intended for it to be a collection? Do we just disallow putting a null resource under version control (for a similar reason that I advocate not supporting null locks :-) I don't see why it is necessary for a null resource to be versionable, and we should disallow it. Does a server have to support immutable revisions? Last paragraph says mutable revision support is optional, but doesn't say anything about immutable revisions. A server doesn't do anything special to support immutable revisions, other than failing an attempt to use DAV:overwrite as a DAV:checkin-option. So basically supporting mutable revisions is supporting the DAV:overwrite option. What I was asking has to do it IMmutable support. Can a server support ONLY mutable resources, or does it have to have support for immutable resources too? For example, DMS systems that don't currently support immutable revisions. In this case, the DAV:overwrite would always be T. B.T.W., this isn't mentioned in the semantics of CHECKIN. Looks like mutable revisions are missing from CHECKIN although the postconditions mentions the concept. 3.6.1: The revision selector for a baseline would have to include the URL of the associated collection, and the baseline id. A baseline is the only revision selector that has a compound name. This will complicate the revision selection rules. No need for a collection/id pair. Just use the URL to that baseline. What is the URL for the baseline? Is it something the server generated, or is it derived from the associated collection. The protocol doesn't say how a baseline is created, or how this URL is derived. Did I miss this? I don't see anything in CHECKIN. In any case, any place where a specific revision is required, but revision id must be specified. For example, putting a configuration in the RSR. The same must be true of baselines. 3.7.3: doesn't every baseline have to have a corresponding revision of the versioned collection? I'm not sure what you mean by "corresponding". Every baseline has to select a revision of its versioned collection, but several baselines of a versioned collection can select the same revision of that versioned collection. Right. This is fine. 3.7.4 Need more control over merge. To ensure semantics, should use a MERGE method instead of directly editing properties which are likely live and not the implementation of persistence for the merge successor/predecessors. Added constraint that only appropriate revisions can be added to the collection. How is constraining a "property collection" any harder than constraining a method. You write down the constraint, and servers and clients must follow it. A method can define specific semantics that are supported. It doesn't have to list a bunch of things you can't specify. 3.8.2: rsr-baseline: must have the URL for the collection and the id of the baseline. A baseline is like a revision and must be addressed by its id. See above. A baseline has a URL, and can be addressed by that. Again, I don't know what this URL is or how it was created. General question on the introduction of conflicts in the RSR: many of the revision selectors indicate they don't ever create conflicts, or only create conflicts in certain circumstances. Aren't conflicts created not by a particular revision selector, but by the presence of more than one revision selector in the RSR, each of which might pick a revision that is not on the same line of descent? Yes, but only for the DAV:rsr-merge operator (or for DAV:needed-activities). The DAV:rsr-or operator just does "first match". Then the statements that these things never create conflicts is missleading and needs clarification. rsr-configuration: this one is a problem as the RSR must be used to select the revision of the configuration that the RSR uses to see if the configuration contains a revision of the target resource. Since configurations can't contain configurations, this isn't a problem, but it may have undesirable implementation consequences. The configuration used by the RSR can change without anything changing in the RSR itself. Say the configuration selected is one labeled Foo, and Foo moves to a different configuration. Perhaps we need to restrict a revision selector to a revision of a configuration, just like baselines. Whenever a specific revision is required, the workspace isn't used, and a specific id is required. Can't use a label because that could move. Added constraint that a versioned-configuration cannot be used, but a configuration revision can be. It was always a configuration revision, the issue was how that revision was specified. So you mean by the constraint you added that you have to specify a particular revision with a revision, not just the URL letting the workspace pick a revision? Note it would be OK to use a workspace or label to find the correct configuration to put in the RSR, but what actually gets stored must be the specific selected revision, and this can't change just because the workspace changes (in an unrelated way), or labels get moved. I think what this means is the RSR must be reported with specific revisions using the revision id, not labels. 4.5 Seems like it should be OK to copy: workspace: it would be a new workspace with the same RSR, but none of the working resources activity: it would just create a new activity with some of the properties copied configuration: should work fine I think it would be misleading and not that useful to support a copy that cannot copy the key properties of the resource. Agree, but such restrictions point to a problem in the protocol semantics. We can just let the copy happen even though it isn't that useful in some circumstances. This doesn't seem consistent with lock. Lock is a dynamic access control mechanism. Locking a versioned resource should be the same as setting the single-checkout property. checking it out in the default workspace has the right semantics for down level clients working against auto-versioned resources ... the PUT that would auto- version fails because the resource is already checked out into the default workspace. Nice idea, but I think it overloads lock too much. Another way to look at it (from the point of view of a non-versioning aware client) is the lock prevents anyone else from checking out the revision. So the down-level client locks, does a bunch of PUTs knowing that no-one else can change the resource, and then does an unlock. Each PUT still does a CHECKOUT/PUT/CHECKIN, but only the down-level client can directly or indirectly checkout the revision. The effect is the same, but this keeps lock out of checkout/checkin which might be a good thing. Only the lock owner can do the checkout. Lock on a revision does the same thing for the revision. Lock on a workspace prevents any checkouts in that workspace (because only the lock owner can update the properties), etc. These are the semantics from the model introduction I think. I think these metadata items want ACL's, not lock tokens. But I've added it to the issues list in any case. Lock is an access control mechanism. We've already got the method and need to have it mean something. This is just an attempt to do something reasonable. If we want to keep locking optional though, we'll have to make sure none of this functionality is required. 4.11 OPTIONS is on the resource too, not just the server. I hope the client doesn't need to know repositories on the server. I think this is the repository question again? (:-) The details may be related to the repository, but a server could support versioning on one resource, and not another. So these new OPTIONS, like all HTTP options, need to be on the resource too. The preconditions should be specified more logically too. For example, If the DAV:single-checkout property of the selected versioned resource is set, the resource must not be already checked out in any other workspace. I'd be concerned that that would turns something very concrete that you can verify into a vaguer statement that might be misunderstood. We should discuss this. I could be argued into it. Concrete is good, but the gap between the semantics in the scenarios and the introduction is pretty wide. I'm not suggesting we remove the precise descriptions, only that we add what they mean. Last precondition: a revision cannot be checked out twice in the same workspace. That is implied by the fact that you can't apply CHECKOUT to a working resource. Exactly, but it takes a lot of mental energy to figure this out in some cases. Marshalling, how is the Target-Selector overridden with a specific label or id? It isn't. The Target-Selector with a label or id is just for folks with lightweight workspaces that don't have rsr's. For folks with workspaces, overriding with a specific label is far less common, and can be done by accessing the DAV:revisions or DAV:revision-labels collections. Two problems: if the Target-Selector is just a label, what is used to select the collection revisions in the URL path? Second, folks with workspaces will override with a specific label LOTS of times to do compares, browse old versions, prepare for merging, look at what other people are doing, etc. We need the Target-Selector to specify the workspace for collections in the URL path, while overriding the Target-Selector for the leaf element of the path. We could do that, but I argue we don't "need" to do it. I don't know how it would work without this capability. What revision of the collections would be used? Result: the checkout response must be in a multistatus, not just a response element. To handle the property update? The DTD for WebDAV shows a DAV:response in a DAV:multistatus, never by itself. Again, CHECKIN is doing PROPPATCH work. This is not a propertyupdate, its a set of parameters for the CHECKIN method. We should not reuse the propertyupdate, but rather create a new element, specific to the method. Otherwise we have to specify a whole bunch of restrictions about what can go in the propertyupdate. I don't think we need to put on any restrictions. This seems like a pretty natural place to allow you to specify CHECKIN options, but I could go either way. I don't think we need two ways of updating properties on a resource, PROPPATCH and CHECKIN. You say later on that some of the properties are not actually saved. This is even worse. Method parameters should be coupled with the method, not the resource. DAV:uncheckout is a control couple. This is not good style. Use a separate method. There's no reason to conserve them. Control couples appear to make the protocol smaller, but they really add complexity. Not if they are logically very similar in basic intent (i.e. "I'm done with this resource"). We already have DAV:overwrite which doesn't create a new revision, and DAV:identical-uncheckout which only creates a new revision if it has changed, so DAV:uncheckout seems to fit in very smoothly. But I think the intent of the two methods is the exact opposite. The intent of CHECKIN is to create a new revision an preserve changes unless perhaps there's no need to because there were no changes. The intent of UNCHECKOUT is to ensure a new revision is not created, and the changes are lost. Coupling these two concepts in the same method seems wrong. This is taking control couples too far. Notice that most of these checkin policies could be marshalled in simple headers. So we could use up the single header namespace, instead of using XML which has user-defined namespaces ? (:-) Since we own headers, there is no namespace issue. Users can't easily add headers without extending the protocol. There is always a tension between using headers and using entity request bodies for marshalling arguments. The WebDAV spec has a good rational for how this is done in WebDAV, section 1 under Namespace Operations. I think there is an opportunity to simplify the protocol by using headers instead of entity request bodies in some cases. It isn't important to do this now though. We can make a protocol optimization pass after we get all the methods done. 7. The paragraph about Target-Selector specfies a revision id or label is incorrect. The selector "self" cannot be applied to collections on the path because its a revision of the collection that's needed, not the versioned collection as a whole. And if so, it will "correctly" return an error (you should be using a workspace to look at things in versioned collections). But down-level clients can't do this. I'll include some locking semantics in another message. From w3c-dist-auth-request@w3.org Tue Oct 19 13:51: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 NAA27733 for ; Tue, 19 Oct 1999 13:51:24 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id NAA05969; Tue, 19 Oct 1999 13:36:12 -0400 (EDT) Resent-Date: Tue, 19 Oct 1999 13:36:12 -0400 (EDT) Resent-Message-Id: <199910191736.NAA05969@www19.w3.org> Date: Tue, 19 Oct 1999 10:35:06 -0700 Message-ID: <6396-Tue19Oct1999103506-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: <8525680F.0003E9E0.00@D51MTA03.pok.ibm.com> References: <8525680F.0003E9E0.00@D51MTA03.pok.ibm.com> Subject: RE: Globally unique tokens. Was: One lock per resource per person? Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3509 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 wjc> Isn't this a quality-of-implementation issue? If multiple wjc> servers need to access the same physical repository, a wjc> privately-arranged scheme can be used to keep them from colliding wjc> with each other (possibly even some server acting as a wjc> clearinghouse for doling out LOCK tokens). ccjason> So you are suggesting that they don't need to be *globally* ccjason> unique as long as they are unique within the cluster? No, actually. I'm still saying unique-within-resource. (My only caveat is that it's kind of vague to me what this cluster example is all about, so I've interpreted it to support what I'm saying. :-) If there are multiple hands in the cookie jar for the same resource, they just need a private agreement that will keep them from reaching for the same cookie. -- 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 Oct 19 14:45: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 OAA29359 for ; Tue, 19 Oct 1999 14:45:26 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id OAA07432; Tue, 19 Oct 1999 14:30:41 -0400 (EDT) Resent-Date: Tue, 19 Oct 1999 14:30:41 -0400 (EDT) Resent-Message-Id: <199910191830.OAA07432@www19.w3.org> From: ccjason@us.ibm.com X-Lotus-FromDomain: IBMUS To: bill@carpenter.ORG (WJCarpenter) cc: w3c-dist-auth@w3.org Message-ID: <8525680F.00657393.00@D51MTA03.pok.ibm.com> Date: Tue, 19 Oct 1999 14:32:08 -0400 Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Subject: RE: Globally unique tokens. Was: One lock per resource per person? Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3510 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list ccjason> So you are suggesting that they don't need to be *globally* ccjason> unique as long as they are unique within the cluster? wjc> No, actually. I'm still saying unique-within-resource. (My only wjc> caveat is that it's kind of vague to me what this cluster example is wjc> all about, so I've interpreted it to support what I'm saying. :-) If wjc> there are multiple hands in the cookie jar for the same resource, they wjc> just need a private agreement that will keep them from reaching for wjc> the same cookie. Bill, I can't speak for JimW's meaning of a cluster, but let me give you another interpretation... First... I assume the existance of depth locks and shared locks. Secondly... you seem to understand that the token needs to be unique within the resource. Now an example.... LOCK /a/b/ shared depth. LOCK /m/n shared BIND /a/b/n to the resource at /m/n Now after the bind, the resource /a/b/n inherits an additional lock. If both locks used the same token, now the resource has two locks with the same token. You've already recognized this as a bad thing. In a server that supports cross server bindings... the domain of necessary uniqueness extends to all servers that cooperate on bindings. As far as being *globally* unique. I don't have an explanation for that. Perhaps JimW and Yaron do. (I didn't fully understand their examples.) But requiring global uniqueness seems like a small price to pay. J. From w3c-dist-auth-request@w3.org Tue Oct 19 15:15: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 PAA00093 for ; Tue, 19 Oct 1999 15:15:27 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id PAA08834; Tue, 19 Oct 1999 15:01:41 -0400 (EDT) Resent-Date: Tue, 19 Oct 1999 15:01:41 -0400 (EDT) Resent-Message-Id: <199910191901.PAA08834@www19.w3.org> Message-ID: From: "Chris Kaler (Exchange)" To: "'jamsden@us.ibm.com'" , w3c-dist-auth@w3.org Date: Tue, 19 Oct 1999 11:51:01 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="windows-1252" Subject: RE: One lock per resource per person? Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3511 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: jamsden@us.ibm.com [mailto:jamsden@us.ibm.com] Sent: Friday, October 15, 1999 12:32 PM To: w3c-dist-auth@w3.org Subject: Re: One lock per resource per person? A principal can only have one lock on a resource. If the lock is exclusive, then there can only be one. If the lock is shared, then getting another shared lock would not give owning principal any further capability. I don't have the spec if front of me, but I believe this is spelled out. I think this is too restrictive. Using SCC systems today, I can create multiple shared locks against the same resource. In general you can do this by "checking it out" multiple times, but the basic notion is that I may be engaged in parallel activities at my client even though I am the same principal. From w3c-dist-auth-request@w3.org Tue Oct 19 16:31: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 QAA01848 for ; Tue, 19 Oct 1999 16:31:36 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id QAA12629; Tue, 19 Oct 1999 16:19:27 -0400 (EDT) Resent-Date: Tue, 19 Oct 1999 16:19:27 -0400 (EDT) Resent-Message-Id: <199910192019.QAA12629@www19.w3.org> From: jamsden@us.ibm.com X-Lotus-FromDomain: IBMUS To: w3c-dist-auth@w3.org Message-ID: <8525680F.006F79A8.00@d54mta03.raleigh.ibm.com> Date: Tue, 19 Oct 1999 16:15:24 -0400 Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Subject: RE: One lock per resource per person? Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3512 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list Yes Chris, but this is locking, not checkout. We can cover your case in WebDAV versioning and don't have to do it with locking. Locking is an access control mechanism for serializing updates to a resource. It is not at all the same thing as checkout. "Chris Kaler (Exchange)" on 10/19/99 02:51:01 PM To: Jim Amsden/Raleigh/IBM@IBMUS, w3c-dist-auth@w3.org cc: Subject: RE: One lock per resource per person? -----Original Message----- From: jamsden@us.ibm.com [mailto:jamsden@us.ibm.com] Sent: Friday, October 15, 1999 12:32 PM To: w3c-dist-auth@w3.org Subject: Re: One lock per resource per person? A principal can only have one lock on a resource. If the lock is exclusive, then there can only be one. If the lock is shared, then getting another shared lock would not give owning principal any further capability. I don't have the spec if front of me, but I believe this is spelled out. I think this is too restrictive. Using SCC systems today, I can create multiple shared locks against the same resource. In general you can do this by "checking it out" multiple times, but the basic notion is that I may be engaged in parallel activities at my client even though I am the same principal. From w3c-dist-auth-request@w3.org Tue Oct 19 23:10: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 XAA08026 for ; Tue, 19 Oct 1999 23:10:42 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id WAA20316; Tue, 19 Oct 1999 22:57:55 -0400 (EDT) Resent-Date: Tue, 19 Oct 1999 22:57:55 -0400 (EDT) Resent-Message-Id: <199910200257.WAA20316@www19.w3.org> Date: Tue, 19 Oct 1999 22:57:27 -0400 Message-Id: <9910200257.AA22000@tantalum> From: "Geoffrey M. Clemm" To: w3c-dist-auth@w3.org In-Reply-To: (ckaler@Exchange.Microsoft.com) Subject: Re: One lock per resource per person? Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3513 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: "Chris Kaler (Exchange)" Using SCC systems today, I can create multiple shared locks against the same resource. In general you can do this by "checking it out" multiple times, but the basic notion is that I may be engaged in parallel activities at my client even though I am the same principal. It's very important to distinguish "multiple checkouts" from "shared locks". Multiple checkouts are safe and do not suffer from any lost update problem. Shared write locks are not safe, and you are susceptible to getting your update's trashed by anyone else that shares that lock. Cheers, Geoff From w3c-dist-auth-request@w3.org Wed Oct 20 10:16: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 KAA03524 for ; Wed, 20 Oct 1999 10:16:34 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id KAA29977; Wed, 20 Oct 1999 10:03:39 -0400 (EDT) Resent-Date: Wed, 20 Oct 1999 10:03:39 -0400 (EDT) Resent-Message-Id: <199910201403.KAA29977@www19.w3.org> From: ccjason@us.ibm.com X-Lotus-FromDomain: IBMUS To: w3c-dist-auth@w3.org Message-ID: <85256810.004D0617.00@D51MTA03.pok.ibm.com> Date: Wed, 20 Oct 1999 10:05:07 -0400 Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Subject: Re: One lock per resource per person? Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3514 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list Using SCC systems today, I can create multiple shared locks against the same resource. In general you can do this by "checking it out" multiple times, but the basic notion is that I may be engaged in parallel activities at my client even though I am the same principal. It's very important to distinguish "multiple checkouts" from "shared locks". Multiple checkouts are safe and do not suffer from any lost update problem. Shared write locks are not safe, and you are susceptible to getting your update's trashed by anyone else that shares that lock. True. And I expect shared write locks aren't going to be used much because they depend on cooperation between clients. But shared read locks (write blocking locks) should get used A LOT. That and future types of locks is really where support for multiple locks per resource would get exercised. But in the meantime, since we do support shared write locks, I'd like to get this defined. My original posting is at... http://lists.w3.org/Archives/Public/w3c-dist-auth/1999OctDec/0071.html and http://lists.w3.org/Archives/Public/w3c-dist-auth/1999OctDec/0075.html Is there a problem with supporting it? Does the proposed clarification sound reasonable? I'd really feel better if more folks spoke up. Then we could put this issue to bed. From w3c-dist-auth-request@w3.org Wed Oct 20 14:18: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 OAA17242 for ; Wed, 20 Oct 1999 14:18:47 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id NAA06577; Wed, 20 Oct 1999 13:57:48 -0400 (EDT) Resent-Date: Wed, 20 Oct 1999 13:57:48 -0400 (EDT) Resent-Message-Id: <199910201757.NAA06577@www19.w3.org> Date: Wed, 20 Oct 1999 13:57:39 -0400 Message-Id: <9910201757.AA22372@tantalum> From: "Geoffrey M. Clemm" To: w3c-dist-auth@w3.org In-Reply-To: <380B3C01.3B275FC5@ecal.com> (message from John Stracke on Mon, 18 Oct 1999 11:25:53 -0400) Subject: Re: Simplifying RFC-2518 Locking: A proposal Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3515 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list Two key questions: - Do we want a lock on a collection to lock the "body" of the collection? - Does any locking implementation actually do this? If as Jim Amsden points out, the "body" of a collection is usually just a reference to some other resource, it would probably be better to define a lock on a collection as *not* applying to the body of that collection. Cheers, Geoff From: John Stracke A collection can also have a body as its state. This body would be affected by a lock. I understand a MKCOL method can include an entity request body, but the use of that body is not yet defined in WebDAV. I believe the spec says something about the body being used to create initial members of the collection. I dont remember anything about a collection having a body. Servers can define what GET on a collection means, but this (by convention) usually means returning the body of some distinguished member of the collection, the index page or some such thing. Yes, and that's the body of the collection. From w3c-dist-auth-request@w3.org Wed Oct 20 17:09:26 1999 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23778 for ; Wed, 20 Oct 1999 17:09:26 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id QAA12716; Wed, 20 Oct 1999 16:57:57 -0400 (EDT) Resent-Date: Wed, 20 Oct 1999 16:57:57 -0400 (EDT) Resent-Message-Id: <199910202057.QAA12716@www19.w3.org> Message-ID: <8E3CFBC709A8D21191A400805F15E0DBD244B4@crte147.wc.eso.mc.xerox.com> From: "Slein, Judith A" To: "'Whitehead, Jim'" Cc: "'WebDAV'" Date: Wed, 20 Oct 1999 16:57:32 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Subject: Advanced Collections issues for the RFC 2518 Issues List Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3516 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, It seems as if there should be an issue on the RFC 2518 list for everything we flag in the advanced collections drafts as inconsistent with RFC 2518. In effect, we are requesting a change to RFC 2518 for each of these. (If you are waiting to see which of these actually survive last call on the advanced collections drafts before adding them to the issues list, OK.) Here's what I see at the moment: In the bindings draft: 1. Separate the notion of binding from the notion of URI mapping, and change the definition of internal member URI and collection state accordingly. 2. Change DELETE on a collection to be an atomic operation. 3. Change Section 8.6.1 so that it doesn't require a server to remove all bindings to a resource for a DELETE operation. 4. Change MOVE to be rename rather than COPY / fixup / DELETE. 5. Change MOVE on a collection to be an atomic operation. 6. Change Section 7.7 to say that write locks do move when the locked resource is moved. 7. Weaken the requirement to protect URIs of locked resources to be only that the URI used to lock the resource be protected. In the redirect references draft: 8. Extend the DAV:response XML element to allow a DAV:prop element to be included: In the ordering draft: 9. A DAV:options element is defined in the ordering draft to allow clients to ask for more detailed information about capabilities than you can get just from a list of compliance classes in the DAV: response header. It might be better if the DAV:options element were defined in the WebDAV spec so that authors of other extension specs would be more likely to find it and use it rather than inventing their own. --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 Oct 20 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 VAA26413 for ; Wed, 20 Oct 1999 21:06:04 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id UAA20189; Wed, 20 Oct 1999 20:54:10 -0400 (EDT) Resent-Date: Wed, 20 Oct 1999 20:54:10 -0400 (EDT) Resent-Message-Id: <199910210054.UAA20189@www19.w3.org> From: Jim Whitehead To: WebDAV WG Date: Wed, 20 Oct 1999 17:53:01 -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: Final DC IETF meeting time: Mon., 7:30PM Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3517 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 meeting time for the WebDAV WG at the Washington, DC IETF has been finalized. We'll be meeting from 7:30PM to 10:00PM on Monday night (November 8, 1999). There will also be an additional breakout on Advanced Collections, but we're still working on the exact time of this--details to come. The complete IETF meeting schedule can be found at: http://www.ietf.org/meetings/agenda.txt Note that during the WebDAV WG meeting we will be discussing the advanced collections specifications (all available off the WebDAV WG home page, at http://www.ics.uci.edu/pub/ietf/webdav/), and we will expect attendees to have read these specifications. Unlike past meetings, there will not be a specification overview--we've done that enough already. If you show up at the meeting and haven't read the spec., don't be surprised if we hand you a spec. and a red pen, or if I give speaking preference to those who have read the specs. - Jim From w3c-dist-auth-request@w3.org Sat Oct 23 12:14: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 MAA05451 for ; Sat, 23 Oct 1999 12:14:07 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id LAA27680; Sat, 23 Oct 1999 11:57:16 -0400 (EDT) Resent-Date: Sat, 23 Oct 1999 11:57:16 -0400 (EDT) Resent-Message-Id: <199910231557.LAA27680@www19.w3.org> Date: Sat, 23 Oct 1999 11:56:52 -0400 Message-Id: <9910231556.AA23816@tantalum> From: "Geoffrey M. Clemm" To: w3c-dist-auth@w3.org In-Reply-To: <852567F7.000876CF.00@D51MTA03.pok.ibm.com> (ccjason@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/3518 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list OK, now that the new versioning protocol draft is out the door, time to get back to locking (:-). I'll try out the: "Simplified RFC-2518 Locking, Version-2" proposal against the issues raised here. From: ccjason@us.ibm.com .... 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 has to remember the association of a lock token with a particular resource. Since this is the server, it doesn't need to use some URL ... it just keeps a handle on the resource that is independent of the http URL space. 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. Right. 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. And if we do not support depth locks, the issue goes away completely (:-). 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. Right. The client uses the lock token for all requests on a locked resource, rather than only using them for requests that might update the locked resource. 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. Also note that a human would always need a client doing the real work in a locking context, since it is unlikely that a human ever would or could remember the lock token strings that are needed to work with a locked resource. 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. Without depth locking, the lock token is all that is needed. 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. If the server just keeps track of what resource is locked by a particular lock token, then remapping just consists of returning a valid URL to that resource in a 302. 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. :-) Associating a lock token with a single resource until it is unlocked is probably even easier (:-). Cheers, Geoff From w3c-dist-auth-request@w3.org Sat Oct 23 13: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 NAA06695 for ; Sat, 23 Oct 1999 13:52:43 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id NAA29423; Sat, 23 Oct 1999 13:38:18 -0400 (EDT) Resent-Date: Sat, 23 Oct 1999 13:38:18 -0400 (EDT) Resent-Message-Id: <199910231738.NAA29423@www19.w3.org> Date: Sat, 23 Oct 1999 13:38:12 -0400 Message-Id: <9910231738.AA23865@tantalum> From: "Geoffrey M. Clemm" To: w3c-dist-auth@w3.org In-Reply-To: <078292D50C98D2118D090008C7E9C6A603C96692@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/3519 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)" > 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. Using the updated proposal where a process gets back a 302 when it tries to access a locked resource that has moved, word will have to update its path to the document the next time it accesses it for read or write. When it does so, the user will know to look at the new place in a different process. Also note that a user is already used to some difference between what is seen in the process that has the lock and another process that does not. In particular, any changes that have not yet been saved will only appear in the process with the lock. 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? Probably somebody who had a good reason do so (perhaps fixing a bad copyright statement in her document). In either case, there is no lost update problem, since she has no pending updates to the document (except for those only in her head, which we can't take responsibility for :-). My generic response to this situation: locks are great for preventing lost updates. You LOCK,GET,edit,PUT,UNLOCK. The faster you get in and out with your lock, the better. If you want to leave the world locked up so that your job is easier, you're ignoring the needs of all the other people that need to get their jobs done. With the speed of development and deployment being forced by "internet time", I believe the days of locking up the world to get long-term stability are over. Cheers, Geoff From w3c-dist-auth-request@w3.org Sat Oct 23 18:00: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 SAA08694 for ; Sat, 23 Oct 1999 18:00:19 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id RAA03667; Sat, 23 Oct 1999 17:45:47 -0400 (EDT) Resent-Date: Sat, 23 Oct 1999 17:45:47 -0400 (EDT) Resent-Message-Id: <199910232145.RAA03667@www19.w3.org> Message-ID: <078292D50C98D2118D090008C7E9C6A603C96785@STAY.platinum.corp.microsoft.com> From: "Yaron Goland (Exchange)" To: "'Geoffrey M. Clemm'" , w3c-dist-auth@w3.org Date: Sat, 23 Oct 1999 14:45:33 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) 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/3520 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list > Using the updated proposal where a process gets back a 302 when it > tries to access a locked resource that has moved, word will have to > update its path to the document the next time it accesses it for read > or write. When it does so, the user will know to look > at the new place in a different process. > > Also note that a user is already used to some difference > between what is > seen in the process that has the lock and another process > that does not. > In particular, any changes that have not yet been saved will > only appear > in the process with the lock. How long do you expect the original resource to remember the forwarding information? So if you move foo/bar to foo/baz and someone else creates a new resource at foo/bar then the forwarding from foo/bar to foo/baz will be destroyed. These are file systems, they don't have long memories. Also, how do you think the UI in Hiro's word processor is going to tell him about the name change? "Dear Hiro, someone decided to move your file for you, it now lives at the following name." I can't ship that product, my users would revolt. > Probably somebody who had a good reason do so (perhaps fixing a bad > copyright statement in her document). In either case, there is no > lost update problem, since she has no pending updates to the document > (except for those only in her head, which we can't take responsibility > for :-). The only problem is that her document has mysteriously disappeared, even though she locked it. Admittedly this can happen anyway if the admin overrides her lock but that is a very rare circumstance and enough of a disaster that the admin would be expected to send e-mail out to those affected. The same would not be true here. If Joe comes along and moves the entire directory and isn't aware that Irit had a locked file he would never know he should tell Irit. So when Irit comes back her file is gone and she has no idea what has happened. Even if Joe knew, it wouldn't be sufficient. Irit wants her stuff staying where it is, that is why she took out the lock. You seem to believe that locks are just there to protect content. That simply isn't true. Locks are there to control the name for it is the name which gives access to everything. By controlling the name you control where the name can be moved as well as who can access the content pointed to by the name. Locks are more about names then they are about content. > > My generic response to this situation: locks are great for preventing > lost updates. You LOCK,GET,edit,PUT,UNLOCK. The faster you > get in and > out with your lock, the better. If you want to leave the world locked > up so that your job is easier, you're ignoring the needs of all the > other people that need to get their jobs done. > In our experience the over whelming majority of documents are one user at a time. That is, one user edits and then hands over control to another user. Locks prevent control from being transferred prematurely. They also prevent unwanted changes to shared namespaces. While documents are often single user, namespaces are often shared. Widespread use of collaborative editing is only now starting and is in its most infant stages. For a very long time most documents will be used by one and only one person and suffer the problems described in the previous paragraph. In fact, according to our studies, the #1 mechanism used to collaborate on a document is e-mail. Copies get sent around and someone acts as a redactor. > With the speed of development and deployment being forced by > "internet time", > I believe the days of locking up the world to get long-term > stability are over. > I don't know what is in the future, only what is in the present. WebDAV has to be able to do what we can already do today before it can move into uncharted territory. The locking proposal prevents scenarios that work today and thus prevents WebDAV's adoption by file system based programs that exist today. > Cheers, > Geoff > The bottom line is the question of the relationship of names to locks. In the file system world a name is the single most powerful piece of information one has. The name is used to retrieve, to change, to control. One of locking's most critical tasks is to provide for control over that name. That is why WebDAV causes names to be locked along with content. This wasn't an accident, it was a conscious choice based on experience shipping editing systems that work against file systems. Until the whole world moves over to powerful versioning systems we will have to deal with file systems and in file systems, file names are king. Thus my users MUST be able to pin down a name, own it and totally control it. So long as there are file systems locks MUST control names. Yaron From w3c-dist-auth-request@w3.org Sat Oct 23 20:26: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 UAA09668 for ; Sat, 23 Oct 1999 20:26:50 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id UAA04824; Sat, 23 Oct 1999 20:11:27 -0400 (EDT) Resent-Date: Sat, 23 Oct 1999 20:11:27 -0400 (EDT) Resent-Message-Id: <199910240011.UAA04824@www19.w3.org> Date: Sat, 23 Oct 1999 20:11:22 -0400 Message-Id: <9910240011.AA24000@tantalum> From: "Geoffrey M. Clemm" To: w3c-dist-auth@w3.org In-Reply-To: <078292D50C98D2118D090008C7E9C6A603C96785@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/3521 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)" > Using the updated proposal where a process gets back a 302 when it > tries to access a locked resource that has moved, word will have to > update its path to the document the next time it accesses it for read > or write. When it does so, the user will know to look > at the new place in a different process. How long do you expect the original resource to remember the forwarding information? In an implementation, it often isn't the resource that is remembering the forwarding information, but rather some locking authority. This is true for many WebDAV implementations (although certainly not all). The locking authority must maintain any forwarding information for the lifetime of the lock. So if you move foo/bar to foo/baz and someone else creates a new resource at foo/bar then the forwarding from foo/bar to foo/baz will be destroyed. These are file systems, they don't have long memories. If an implementation cannot maintain forwarding information, then it must fail the move (with a "locked" status). Also, how do you think the UI in Hiro's word processor is going to tell him about the name change? "Dear Hiro, someone decided to move your file for you, it now lives at the following name." I can't ship that product, my users would revolt. If Hiro's word processor is using HTTP (the premise of WebDAV), it had better be prepared to handle a 302. > Probably somebody who had a good reason do so (perhaps fixing a bad > copyright statement in her document). In either case, there is no > lost update problem, since she has no pending updates to the document > (except for those only in her head, which we can't take responsibility > for :-). The only problem is that her document has mysteriously disappeared, even though she locked it. Admittedly this can happen anyway if the admin overrides her lock but that is a very rare circumstance and enough of a disaster that the admin would be expected to send e-mail out to those affected. The same would not be true here. If Joe comes along and moves the entire directory and isn't aware that Irit had a locked file he would never know he should tell Irit. The lock is there, and Joe could easily notify all the lock holders (assuming the locks hold principal information, as is recommended). In fact, if he had a good client, it could largely automate the notification process. So when Irit comes back her file is gone and she has no idea what has happened. Even if Joe knew, it wouldn't be sufficient. Irit wants her stuff staying where it is, that is why she took out the lock. And I want to put red lights on all cross-roads of all the intersections on my way to work (:-). But I'm not allowed to do that because it interferes with everybody else's commute. Just a silly analogy, but not too far off the mark, I believe. You seem to believe that locks are just there to protect content. That simply isn't true. Locks are there to control the name for it is the name which gives access to everything. By controlling the name you control where the name can be moved as well as who can access the content pointed to by the name. Locks are more about names then they are about content. I think we agree that locks are there to prevent the lost update problem (i.e. protecting content). It is an interesting question as to whether they are appropriate for preventing other problems, and if so, how they are best used to do so. I believe that locks are useful for keeping a handle on where a locked resource is located, but that a server should be able to allow the move and return a 302, if it wants to maximize parallel work. A server can also just fail a moves if it cannot track the movement of a locked resource. In our experience the over whelming majority of documents are one user at a time. That is, one user edits and then hands over control to another user. Locks prevent control from being transferred prematurely. They also prevent unwanted changes to shared namespaces. While documents are often single user, namespaces are often shared. Yes, it is the shared nature of namespaces that causes me to resist requiring anything like a "namespace lock". To say that a server can do such a lock if that's the best it can to, then that's fine. But to say that all servers must act that way leaves out a useful alternative, namely, using 302's to let a client know the new location of their locked resource. Since a web client needs to know how to deal with 302's anyway, I believe there is little or no additional cost to clients. Cheers, Geoff From w3c-dist-auth-request@w3.org Sun Oct 24 13:02: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 NAA10926 for ; Sun, 24 Oct 1999 13:02:16 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id MAA22871; Sun, 24 Oct 1999 12:49:51 -0400 (EDT) Resent-Date: Sun, 24 Oct 1999 12:49:51 -0400 (EDT) Resent-Message-Id: <199910241649.MAA22871@www19.w3.org> Message-ID: <078292D50C98D2118D090008C7E9C6A603C96789@STAY.platinum.corp.microsoft.com> From: "Yaron Goland (Exchange)" To: "'Geoffrey M. Clemm'" , w3c-dist-auth@w3.org Date: Sun, 24 Oct 1999 09:49:30 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: text/plain Subject: Can you move a locked file? Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3522 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list While I understand your justifiable fear that the access linearization caused by locks will hinder collaboration you must understand that the reason my users use locks is exactly that - they want to PROHIBIT collaboration. My user's explicit goal is to prevent anyone, anywhere from have any ability to manipulate their "private data worlds" in anyway. This begins with the formation of the namespace and continues to the manipulation of content. For my users WebDAV is a great way to access a large number of "private data worlds." For your users, WebDAV is a great way to powerfully leverage the collaborative features of the web. Our two user's needs are in direct conflict. You have proposed two mitigating technologies, lock monitors and auto-email notifications. Even if I could include those in a $200 OS product (which I can't) I would not do so anyway because my users do not want to have to deal with the ramifications of these technologies. My users do not want to get an e-mail telling them their files have moved. They just want their files to stay where they were put. Given the contradictory needs of our user bases I see two choices. Choice 1 - We agree to disagree. Deciding the problem is irresolvable we create two types of locks in WebDAV. This, of course, destroys any hope for interoperability and puts blocks in the road of my users as they "grow" from their current "private data world" model to a more open "collaborative world model." Choice 2 - We agree that locks, as unfortunate as it may be, must lock the namespace and accept this limitation as the cost of bringing the widest number of users into WebDAV. Yaron > -----Original Message----- > From: Geoffrey M. Clemm [mailto:geoffrey.clemm@rational.com] > Sent: Saturday, October 23, 1999 5:11 PM > To: w3c-dist-auth@w3.org > Subject: Re: DELETE leaving a lock-null resource; was LOCK Scenarios > > > From: "Yaron Goland (Exchange)" > > > Using the updated proposal where a process gets back a > 302 when it > > tries to access a locked resource that has moved, word > will have to > > update its path to the document the next time it > accesses it for read > > or write. When it does so, the user will know to look > > at the new place in a different process. > > How long do you expect the original resource to remember > the forwarding > information? > > In an implementation, it often isn't the resource that is remembering > the forwarding information, but rather some locking > authority. This is > true for many WebDAV implementations (although certainly not all). > The locking authority must maintain any forwarding information > for the lifetime of the lock. > > So if you move foo/bar to foo/baz and someone else creates a > new resource at foo/bar then the forwarding from foo/bar > to foo/baz will be > destroyed. These are file systems, they don't have long memories. > > If an implementation cannot maintain forwarding information, > then it must > fail the move (with a "locked" status). > > Also, how do you think the UI in Hiro's word processor is > going to tell him > about the name change? "Dear Hiro, someone decided to move > your file for > you, it now lives at the following name." I can't ship > that product, > my users would revolt. > > If Hiro's word processor is using HTTP (the premise of > WebDAV), it had better > be prepared to handle a 302. > > > Probably somebody who had a good reason do so (perhaps > fixing a bad > > copyright statement in her document). In either case, > there is no > > lost update problem, since she has no pending updates to > the document > > (except for those only in her head, which we can't take > responsibility > > for :-). > > The only problem is that her document has mysteriously > disappeared, even > though she locked it. Admittedly this can happen anyway if > the admin > overrides her lock but that is a very rare circumstance > and enough of a > disaster that the admin would be expected to send e-mail > out to those > affected. The same would not be true here. If Joe comes > along and moves the > entire directory and isn't aware that Irit had a locked > file he would never > know he should tell Irit. > > The lock is there, and Joe could easily notify all the lock > holders (assuming > the locks hold principal information, as is recommended). In > fact, if he > had a good client, it could largely automate the notification process. > > So when Irit comes back her file is gone and she > has no idea what has happened. Even if Joe knew, it > wouldn't be sufficient. > Irit wants her stuff staying where it is, that is why she > took out the lock. > > And I want to put red lights on all cross-roads of all the > intersections > on my way to work (:-). But I'm not allowed to do that > because it interferes > with everybody else's commute. Just a silly analogy, but not too > far off the mark, I believe. > > You seem to believe that locks are just there to protect > content. That > simply isn't true. Locks are there to control the name for > it is the name > which gives access to everything. By controlling the name > you control where > the name can be moved as well as who can access the > content pointed to by > the name. Locks are more about names then they are about content. > > I think we agree that locks are there to prevent the lost update > problem (i.e. protecting content). It is an interesting question as > to whether they are appropriate for preventing other problems, and if > so, how they are best used to do so. I believe that locks are useful > for keeping a handle on where a locked resource is located, but that a > server should be able to allow the move and return a 302, if it wants > to maximize parallel work. A server can also just fail a moves if it > cannot track the movement of a locked resource. > > In our experience the over whelming majority of documents > are one user at a > time. That is, one user edits and then hands over control > to another user. > Locks prevent control from being transferred prematurely. > They also prevent > unwanted changes to shared namespaces. While documents are > often single > user, namespaces are often shared. > > Yes, it is the shared nature of namespaces that causes me to resist > requiring anything like a "namespace lock". To say that a server can > do such a lock if that's the best it can to, then that's fine. But > to say that all servers must act that way leaves out a useful > alternative, namely, using 302's to let a client know the new location > of their locked resource. Since a web client needs to know > how to deal with 302's anyway, I believe there is little or no > additional cost to clients. > > Cheers, > Geoff > From w3c-dist-auth-request@w3.org Sun Oct 24 14:36: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 OAA11942 for ; Sun, 24 Oct 1999 14:36:46 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id OAA24622; Sun, 24 Oct 1999 14:18:53 -0400 (EDT) Resent-Date: Sun, 24 Oct 1999 14:18:53 -0400 (EDT) Resent-Message-Id: <199910241818.OAA24622@www19.w3.org> Date: Sun, 24 Oct 1999 14:18:47 -0400 Message-Id: <9910241818.AA24328@tantalum> From: "Geoffrey M. Clemm" To: w3c-dist-auth@w3.org In-Reply-To: <078292D50C98D2118D090008C7E9C6A603C96789@STAY.platinum.corp.microsoft.com> (yarong@Exchange.Microsoft.com) Subject: Re: Can you move a locked file? Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3523 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)" While I understand your justifiable fear that the access linearization caused by locks will hinder collaboration you must understand that the reason my users use locks is exactly that - they want to PROHIBIT collaboration. Then they should just make sure to buy a server that blocks MOVE's of locked files (which I agree a server should be able to do). For your users, WebDAV is a great way to powerfully leverage the collaborative features of the web. Which means they probably will instead chose a server that does lock tracking and returns 302's. Our two user's needs are in direct conflict. So they buy different servers, but clients and servers can use the same protocol ... and everybody is as happy as one can reasonably expect. You have proposed two mitigating technologies, lock monitors and auto-email notifications. Even if I could include those in a $200 OS product (which I can't) I feel compelled to point out that $200 times 10 million users equals 2 billion dollars (:-). Also that the current complexity of that $200 OS product makes lock monitors and auto-email an unmeasurably small increase in complexity. But then again, probably the last thing it needs is even an unmeasurably small increase in complexity (:-). I would not do so anyway because my users do not want to have to deal with the ramifications of these technologies. My users do not want to get an e-mail telling them their files have moved. They just want their files to stay where they were put. Fair enough. So we make sure that the protocol allows their server to refuse to do the moves. Given the contradictory needs of our user bases I see two choices. Choice 1 - We agree to disagree. Deciding the problem is irresolvable we create two types of locks in WebDAV. This, of course, destroys any hope for interoperability and puts blocks in the road of my users as they "grow" from their current "private data world" model to a more open "collaborative world model." Bad choice. Choice 2 - We agree that locks, as unfortunate as it may be, must lock the namespace and accept this limitation as the cost of bringing the widest number of users into WebDAV. What about choice 3: Choice 3 - The protocol allows a server to either refuse the move (returning "locked" status) or to promise to track the move and return 302's as appropriate. No problem for the clients, since they have to deal with 302's anyway, and no problem for the servers, since they can do what they believe is the right thing for their users. Then we let the market decide which server was right ... and all the while, we have one common protocol to interoperate with. Cheers, Geoff From w3c-dist-auth-request@w3.org Sun Oct 24 16: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 QAA12602 for ; Sun, 24 Oct 1999 16:06:38 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id PAA25846; Sun, 24 Oct 1999 15:48:58 -0400 (EDT) Resent-Date: Sun, 24 Oct 1999 15:48:58 -0400 (EDT) Resent-Message-Id: <199910241948.PAA25846@www19.w3.org> Message-ID: <078292D50C98D2118D090008C7E9C6A603C9678D@STAY.platinum.corp.microsoft.com> From: "Yaron Goland (Exchange)" To: "'Geoffrey M. Clemm'" , w3c-dist-auth@w3.org Date: Sun, 24 Oct 1999 12:48:38 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: text/plain Subject: RE: Can you move a locked file? Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3524 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 are going in circles. You have made the "server can always say no" argument before and I have explained why I don't believe that philosophy is workable: http://lists.w3.org/Archives/Public/w3c-dist-auth/1999JulSep/0359.html. There are two differences in your arguments this time. #1 - Clients must be able to deal with 302s anyway. Clients do not have to currently deal with a 302 while their lock is outstanding because the lock prohibits the file from being moved. The only way a 302 could occur is if the lock failed and the client will treat that as a catastrophic error. For example, today if you try to use Office 2000 against a level 1 WebDAV server Office will disable "Save..." functionality and only allow "Save As...". The reason is that our users are trained to have very high expectations regarding the reliability provided by "Save" where as they have no expectations regarding "Save As..." Without namespace locking support we can not meet those expectations, so we are forced to disable "Save..." #2 - Mitigating features such as lock monitors and e-mail notification are becoming so cheap that they can be relied upon being widely available. Speaking from personal experience having helped to develop products which provide for e-mail tracing, your expectations of their pricing are unrealistic. Such systems are currently priced in the hundreds of thousands of dollar range and I know of some new ones that will only be in the thousands of dollar range. However it will be many years before they hit the $200 OS range. Even were they widely available our users would refuse to use them in practice because of the awful user experience they create. Irit doesn't want to receive a message telling her that Joe has moved her files. She just doesn't want her files to move. I believe this comes down to one and only one issue. Will allowing locked files to be moved cause an interoperability problem? As I previously argued, I believe the answer is yes. You believe the answer is no. Neither of us seems to be convincing the other. Since we aren't making any real progress might I suggest we table this topic until the next IETF? We can discuss this in our usual manner, an unbelievably good/expensive meal followed by pistols at 10 paces. I checked out http://www.zagat.com/search/results.asp?QueryType=RecordSet&strCategoryType= restaurant&handler=byCategory&sortBy=CategoryRestaurantRank&fList=10001&loca leID=7&searchPhrase=Favorite+Restaurants for ideas, Kinkeads looks both good and close. L'AUBERGE CHEZ FRANCOIS actually sounded perfect given our mutual preferences but it is a good hour away from the hotel. GERARD'S PLACE also sounded good but I could use a bit more of a boisterous environment. It will cover the noise of the gun shots. You remember the trouble we had last time. The gun shots scared away all the cabs! Yaron > -----Original Message----- > From: Geoffrey M. Clemm [mailto:geoffrey.clemm@rational.com] > Sent: Sunday, October 24, 1999 11:19 AM > To: w3c-dist-auth@w3.org > Subject: Re: Can you move a locked file? > > > > From: "Yaron Goland (Exchange)" > > While I understand your justifiable fear that the access > linearization > caused by locks will hinder collaboration you must > understand that the > reason my users use locks is exactly that - they want to PROHIBIT > collaboration. > > Then they should just make sure to buy a server that blocks MOVE's of > locked files (which I agree a server should be able to do). > > For your users, WebDAV is a great way to powerfully leverage the > collaborative features of the web. > > Which means they probably will instead chose a server that does lock > tracking and returns 302's. > > Our two user's needs are in direct conflict. > > So they buy different servers, but clients and servers can use the > same protocol ... and everybody is as happy as one can > reasonably expect. > > You have proposed two mitigating technologies, lock > monitors and auto-email > notifications. Even if I could include those in a $200 OS > product (which I > can't) > > I feel compelled to point out that $200 times 10 million users equals > 2 billion dollars (:-). Also that the current complexity of that $200 > OS product makes lock monitors and auto-email an unmeasurably small > increase in complexity. But then again, probably the last thing it > needs is even an unmeasurably small increase in complexity (:-). > > I would not do so anyway because my users do not want to > have to deal > with the ramifications of these technologies. My users do > not want to get an > e-mail telling them their files have moved. They just want > their files to > stay where they were put. > > Fair enough. So we make sure that the protocol allows their > server to refuse > to do the moves. > > Given the contradictory needs of our user bases I see two choices. > > Choice 1 - We agree to disagree. Deciding the problem is > irresolvable we > create two types of locks in WebDAV. This, of course, > destroys any hope for > interoperability and puts blocks in the road of my users > as they "grow" from > their current "private data world" model to a more open > "collaborative world > model." > > Bad choice. > > Choice 2 - We agree that locks, as unfortunate as it may > be, must lock the > namespace and accept this limitation as the cost of > bringing the widest > number of users into WebDAV. > > What about choice 3: > > Choice 3 - The protocol allows a server to either refuse the move > (returning "locked" status) or to promise to track the > move and return > 302's as appropriate. No problem for the clients, since > they have to > deal with 302's anyway, and no problem for the servers, > since they can > do what they believe is the right thing for their users. Then we > let the market decide which server was right ... and all the while, > we have one common protocol to interoperate with. > > Cheers, > Geoff > From w3c-dist-auth-request@w3.org Sun Oct 24 21:27: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 VAA14805 for ; Sun, 24 Oct 1999 21:27:02 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id VAA03631; Sun, 24 Oct 1999 21:14:33 -0400 (EDT) Resent-Date: Sun, 24 Oct 1999 21:14:33 -0400 (EDT) Resent-Message-Id: <199910250114.VAA03631@www19.w3.org> From: ccjason@us.ibm.com X-Lotus-FromDomain: IBMUS To: "Geoffrey M. Clemm" cc: w3c-dist-auth@w3.org Message-ID: <85256815.0006BEA7.00@D51MTA03.pok.ibm.com> Date: Sun, 24 Oct 1999 21:16:56 -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/3525 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 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 has to remember the association of a lock token with a particular resource. Since this is the server, it doesn't need to use some URL ... it just keeps a handle on the resource that is independent of the http URL space. Geoff, you're "forgetting" about depth locks again. :-) Multiple resource can have the same lock token. So providing a lock token doesn't uniquely define what resource you're acting on. The server needs a mapping for URI + token -> resource. My posting above predates your most recent proposal. I believe it's the case in the recent proposal that the server only needs to remember one URI for a single resource/lock pairing. Even if the resource moves, it's only the URI used when the lock was first created that needs to be remembered by the server. But no... it's not that easy. (1) If we say that, then it's up to the client to remember that original URI even if redirected... just in case it gets moved again. If the server is unable to redirect after a second move, then I assume the client can detect (via etag-uri combination) that there's been a second movement, and will reinvoke a method based on the original URI and lock token... just to determine where it has moved to again. Anyway, the point is that if the server doesn't remember a second URI, then the client must remember the first URI. (2) If the server remembers all URI's, then the client is relieved of this burden. (1&2) BTW, in either case, the client has to use etags because in the presence of depth locks where multiple resources can have the same locktoken, and if namespace manipulation has occured, a URI+token to resource mapping may not be unique... and I don't think a client can trust a server to somehow detect a collision and somehow do "the right thing". This is an admittedly rare thing... but if the client cares, they have to use uri-tagged etags. whoops! I don't mean etags... I mean guid tags... but we don't have that yet. It would need to be added to the spec. BTW, after the URI+token->resource mapping is done within the server, it also needs to do a resource->URI mapping so that it knows what to return. And of course if all bindings to the resource have been removed, the server will need to generate a binding/URI for that resource so that there is a URI to which to redirect the request. 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. Right. Given the exchange that I've heard between Yaron and company, I'd like to propose that the client also have some say over this. If the client wants the URI protected, he can request it. I suppose that would have to be a FLAG on the lock request. If the server can't respect the request, it has to fail the lock. I suppose we'd need an error code or something to express this so that a client could deal with that particular failure programaticly. 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. And if we do not support depth locks, the issue goes away completely (:-). I think you've mentioned that before. :-) 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. Right. The client uses the lock token for all requests on a locked resource, rather than only using them for requests that might update the locked resource. guid tags too I guess... as soon as we invent them. It doesn't seem like a huge burden but it could be. If a client cares enough about all this to do the guid tag stuff... then they also have to collect guids for all resource that it locked. That's a bunch of state for the client to remember rather than just a single URI that is the root of his lock. Especially in some of Yaron's scenarios. 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. Also note that a human would always need a client doing the real work in a locking context, since it is unlikely that a human ever would or could remember the lock token strings that are needed to work with a locked resource. 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. Without depth locking, the lock token is all that is needed. Yup. 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. If the server just keeps track of what resource is locked by a particular lock token, then remapping just consists of returning a valid URL to that resource in a 302. Also correct. 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. :-) Associating a lock token with a single resource until it is unlocked is probably even easier (:-). I think you missed my point. It single resource can have multiple URI's so we need to do what I mentioned above, which is a pain, or we need to say that simply finding a resource (perhaps at a different URI) and doing lock discovery to get a token won't work because the person doing the lock discovery doesn't know the URI that the server is protecting (via remapping in this case). No biggie. We don't get this with protected URI's either. I think we just need to remind clients of this. -- BTW, this could be done if lock discovery also provides a URI that supports the remapping. But then a client that tries this lock discovery approach would be at the mercy the lock owner who could MOVE the resource and unlock it before the second entity finds out. Anyway, this seems like another use of lock discovery that should be deprecated. BTW, do we require that one be the lock owner to use the token for this purpose? So if one application wants to pass the URI of a resource to another application... it also needs to pass a lock (and perhaps a guid). But if the second application isn't logged on as the first person, then? One other thing, the proposal would also have to clarify the target selector header. Well, maybe not HAVE TO. The problem I'm refering to is that for binding related requests like DELETE, BIND, MOVE, it isn't just the target that is important to be specified, but also the parent. It's the binding between the two that we want to specify. I had a target selector based solution to this in mind, but I think the real solution is to have guid tags for both parent and the resource in the request. If the guid check fails on either the parent or target, the client can try to figure out what to do. -- Another approach is to lock both the parent and the child... but if the redirected URI for the DELETE isn't the one that uses the parent, then you'd not get the right affect, so you'd still want the guid check anyway. That really seems to be the best approach in a server that lacks lock URI protection. Anyway, I propose that the **client** be able to specify if it needs the server to protect the LOCK URI. If the client specifies this and the server can't support it, it must reject the request with a new unique response code and the client figures out how to deal with that. J. From w3c-dist-auth-request@w3.org Mon Oct 25 15:51: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 PAA03899 for ; Mon, 25 Oct 1999 15:51:37 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id PAA13204; Mon, 25 Oct 1999 15:38:36 -0400 (EDT) Resent-Date: Mon, 25 Oct 1999 15:38:36 -0400 (EDT) Resent-Message-Id: <199910251938.PAA13204@www19.w3.org> From: Jim Whitehead To: "Slein, Judith A" Cc: "'WebDAV'" Date: Mon, 25 Oct 1999 12:37:12 -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: <8E3CFBC709A8D21191A400805F15E0DBD244B4@crte147.wc.eso.mc.xerox.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Importance: Normal Subject: RE: Advanced Collections issues for the RFC 2518 Issues List Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3526 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list Content-Transfer-Encoding: 7bit > It seems as if there should be an issue on > the RFC 2518 list for everything we flag in > the advanced collections drafts as inconsistent > with RFC 2518. In effect, we are requesting > a change to RFC 2518 for each of these. > > (If you are waiting to see which of these actually > survive last call on the advanced collections > drafts before adding them to the issues list, OK.) Well, I agree with you that these do need to be noted on the RFC 2518 issues list (currently maintained at: http://www.ics.uci.edu/pub/ietf/webdav/protocol/issues.html), but I also feel we should wait until the advanced collections spec. has passed last call. - Jim From w3c-dist-auth-request@w3.org Mon Oct 25 16:15: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 QAA04471 for ; Mon, 25 Oct 1999 16:15:02 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id QAA14262; Mon, 25 Oct 1999 16:01:46 -0400 (EDT) Resent-Date: Mon, 25 Oct 1999 16:01:46 -0400 (EDT) Resent-Message-Id: <199910252001.QAA14262@www19.w3.org> From: Jim Whitehead To: WebDAV WG Date: Mon, 25 Oct 1999 13:00: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) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Importance: Normal Subject: Breakouts on Advanced Collections, DASL, Delta-V at DC Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3527 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 now have a good idea on when and where breakout sessions on WebDAV-related topics will be held at the Washington, DC IETF meeting. Note that all meetings are open to all who wish to attend them. If you're planning on attending any of the the Delta-V breakout meetings, please send Jeff McAffer an email so he'll know how well to stock the mini-bar :-) (and so he'll know if we need to get more chairs...) Monday, November 8, 1999: ------------------------- * 1PM - 5:30PM Advanced Collections breakout (during Afternoon Sessions I and II) Location: TBD, someplace at the Omni Shoreham, the conference hotel, look on the message board by registration for the exact location. Topics: collect feedback on the advanced collections specs., hold spec. walkthroughs once that is done. * 7:30PM - 10PM WebDAV WG meeting Location: At the Omni Shoreham, look on the official schedule for room location Topics: advanced collections, proposed modifications to RFC 2518, restarting access control Tuesday, November 9, 1999: -------------------------- * 9AM - 12PM Delta-V breakout (during Morning Sessions I) Location: In Jeff McAffer's suite, *not* in the conference hotel. Details to be posted to the Delta-V list, and will also be posted on the message board, near the registration desk, at the Omni Shoreham. Topics: open issues from the protocol specification * 1PM - 3:15PM Delta-V WG meeting (during Afternoon Sessions I and II) Location: At the Omni Shoreham, look on the official schedule for room location Topics: discussion of open issues from the protocol specification * 3:45PM - 4:45PM Advanced Collections breakout (during Afternoon Sessions III) Location: TBD, at the Omni Shoreham, look on the message board for location information Topics: discussion of issues raised during the WebDAV WG meeting * 5PM - 6PM DASL breakout (during Afternoon Sessions IV) Location: TBD, at the Omni Shoreham, look on the message board for location information Topics: disussion of open issues from mailing list discussion, moving forward Wednesday, November 10, 1999: ----------------------------- * 9AM - 5PM (with lunch break) Delta-V breakout Location: In Jeff McAffer's suite, *not* in the conference hotel. Details to be posted to the Delta-V list, and will also be posted on the message board, near the registration desk, at the Omni Shoreham. Topics: open issues from the protocol specification and WG meeting - Jim From w3c-dist-auth-request@w3.org Mon Oct 25 17:54: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 RAA06401 for ; Mon, 25 Oct 1999 17:54:24 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id RAA17243; Mon, 25 Oct 1999 17:41:38 -0400 (EDT) Resent-Date: Mon, 25 Oct 1999 17:41:38 -0400 (EDT) Resent-Message-Id: <199910252141.RAA17243@www19.w3.org> Date: Mon, 25 Oct 1999 17:41:31 -0400 Message-Id: <9910252141.AA24961@tantalum> From: "Geoffrey M. Clemm" To: w3c-dist-auth@w3.org In-Reply-To: <8525680F.0053CE57.00@d54mta03.raleigh.ibm.com> (jamsden@us.ibm.com) Subject: Re: Versioning spec review - 02.3 Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3528 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 Last paragraph: How about using components of versioning support instead of "levels"? In the latest rev of the spec, the versioning options fell quite naturally into 3 levels, so given the client-side advantages of having 3 levels of support vs. multiple orthogonal versioning options, I'd like to go with levels, if at all possible. Can a server support ONLY mutable resources, or does it have to have support for immutable resources too? I assume by support for immutable resources, you mean providing a client with some way of saying "never allow a DAV:overwrite on this revision". To me, that's an access control issue, not a versioning issue, and I'd rather not mix in limited forms of access control that will just end up conflicting with the general forms when they are provided. Since neither DMS nor CM systems provide this functionality on a resource by resource basis, we gain no interoperability by specifying it. For example, DMS systems that don't currently support immutable revisions. In this case, the DAV:overwrite would always be T. A DMS must let you do a checkin with DAV:overwrite=F (otherwise you'd never have more than the initial version). The only difference in this regard between a DMS system and a standard CM system is that a DMS system allows you have DAV:overwrite=T, which a standard CM system would refuse. B.T.W., this isn't mentioned in the semantics of CHECKIN. Looks like mutable revisions are missing from CHECKIN although the postconditions mentions the concept. Do you mean something like "If DAV:overwrite=T then the server MUST support DAV:overwrite having the value T"? (:-) What is the URL for the baseline? Is it something the server generated, or is it derived from the associated collection. All baselines for a particular versioned collection can be found in the DAV:baselines collection of that versioned collection. The server generates the URL of that collection, and generates the name for a baseline in that collection. The protocol doesn't say how a baseline is created, or how this URL is derived. Did I miss this? I don't see anything in CHECKIN. I took that out, since I agree with your contention that it doesn't properly belong in CHECKIN. So you now just create baselines with the MKRESOURCE command. There's a ToDo note in the draft saying this should be explicitly mentioned in the MKRESOURCE method description. In any case, any place where a specific revision is required, but revision id must be specified. For example, putting a configuration in the RSR. The same must be true of baselines. Baselines and revisions are indicated in RSR's by their URL's. We could allow alternative compound notations as well, but is there a compelling reason to do so (it does add complexity). How is constraining a "property collection" any harder than constraining a method? You write down the constraint, and servers and clients must follow it. A method can define specific semantics that are supported. It doesn't have to list a bunch of things you can't specify. I had no trouble specifying the appropriate constraints on the appropriate properties in the protocol. Live properties commonly have their values constrained by the server, so this is nothing unusual for WebDAV. having a downlevel lock check out the resource into the default workspace has the right semantics for down level clients working against auto-versioned resources ... the PUT that would auto- version fails because the resource is already checked out into the default workspace. Nice idea, but I think it overloads lock too much. Another way to look at it (from the point of view of a non-versioning aware client) is the lock prevents anyone else from checking out the revision. So the down-level client locks, does a bunch of PUTs knowing that no-one else can change the resource, and then does an unlock. Each PUT still does a CHECKOUT/PUT/CHECKIN, but only the down-level client can directly or indirectly checkout the revision. The effect is the same, but this keeps lock out of checkout/checkin which might be a good thing. One of the bad things about creating a new revision on every downlevel PUT is that it fills the history of a resource with "non-interesting" revisions, but we have to do it to prevent lost updates. In contrast, a LOCK/UNLOCK request gives us exactly the information we need to implement a more intelligent revision creation policy. To not take advantage of this information when designing the protocol strikes me as remiss. Lock is an access control mechanism. We've already got the method and need to have it mean something. This is just an attempt to do something reasonable. If we want to keep locking optional though, we'll have to make sure none of this functionality is required. Current WebDAV locking (with lock tokens) are good for some things, but any time it is not reasonable to expect a client to hold and remember a lock token, WebDAV locks are not appropriate. It is better to just have the protocol treat the operation as undefined or an error, rather than increase the complexity of the protocol (and of servers that implement it) with functionality that is not useful. Marshalling, how is the Target-Selector overridden with a specific label or id? It isn't. The Target-Selector with a label or id is just for folks with lightweight workspaces that don't have rsr's. For folks with workspaces, overriding with a specific label is far less common, and can be done by accessing the DAV:revisions or DAV:revision-labels collections. Two problems: if the Target-Selector is just a label, what is used to select the collection revisions in the URL path? Core and Activity versioning servers will not be generating versioned collections, so there will be no collection revisions in the URL path. Versioned-Collection servers will provide repositories, which are required to be located in a non-versioned part of the namespace (i.e. under no versioned collections). In either case, the DAV:revision-labels collection will have no collection revisions in its URL path, so no collection revision selection is required. Second, folks with workspaces will override with a specific label LOTS of times to do compares, browse old versions, prepare for merging, look at what other people are doing, etc. The DAV:revision-labels collection is there to give clients easy access to any revision by using a label. No need for a specific header, and suitable for use in any context where a URL can be specified (as opposed to the Target-Selector, which just works for a Request-URL). CHECKIN is doing PROPPATCH work. This is not a propertyupdate, its a set of parameters for the CHECKIN method. We should not reuse the propertyupdate, but rather create a new element, specific to the method. Otherwise we have to specify a whole bunch of restrictions about what can go in the propertyupdate. Not if we place no restrictions on what can go in the property-update. Note that I'm happy to say no specification of the DAV:checkin-policy in a CHECKOUT request, but if we *do* allow it, I believe that the most appropriate way is to allow CHECKOUT to do an arbitrary PROPPATCH to "initialize" the new working resource. Think of CHECKOUT as a "MKRESOURCE" for working resources. I don't think we need two ways of updating properties on a resource, PROPPATCH and CHECKIN. You say later on that some of the properties are not actually saved. This is even worse. Method parameters should be coupled with the method, not the resource. We already have two: PROPATCH and MKRESOURCE. So if we add a third, there is at least precedent. Having "uncheckout" as an option to CHECKIN is reasonable because they are logically very similar in basic intent (i.e. "I'm done with this resource"). We already have DAV:overwrite which doesn't create a new revision, and DAV:identical-uncheckout which only creates a new revision if it has changed, so DAV:uncheckout seems to fit in very smoothly. But I think the intent of the two methods is the exact opposite. The intent of CHECKIN is to create a new revision an preserve changes unless perhaps there's no need to because there were no changes. The intent of UNCHECKOUT is to ensure a new revision is not created, and the changes are lost. Coupling these two concepts in the same method seems wrong. This is taking control couples too far. Both DAV:overwrite and DAV:indentical-uncheckout conflict with your description of the intent of CHECKIN. One never creates a new revision, and the other only sometimes creates a new revision. Notice that most of these checkin policies could be marshalled in simple headers. So we could use up the single header namespace, instead of using XML which has user-defined namespaces ? (:-) Since we own headers, there is no namespace issue. This "we" is a very diverse group (i.e. everyone proposing extensions to HTTP) with overlapping needs/interests. Using up a name that is "global" to this group is, in my opinion, a very significant issue. After all, we've already made life difficult for the archery extension group by defining the semantics of "Target-Selector" (:-). 7. The paragraph about Target-Selector specfies a revision id or label is incorrect. The selector "self" cannot be applied to collections on the path because its a revision of the collection that's needed, not the versioned collection as a whole. And if so, it will "correctly" return an error (you should be using a workspace to look at things in versioned collections). But down-level clients can't do this. Down-level clients won't be issuing requests with Target-Selector headers. Cheers, Geoff From w3c-dist-auth-request@w3.org Mon Oct 25 18:25: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 SAA06690 for ; Mon, 25 Oct 1999 18:25:17 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id SAA18076; Mon, 25 Oct 1999 18:12:59 -0400 (EDT) Resent-Date: Mon, 25 Oct 1999 18:12:59 -0400 (EDT) Resent-Message-Id: <199910252212.SAA18076@www19.w3.org> From: Jim Whitehead To: WebDAV WG Date: Mon, 25 Oct 1999 15:11:39 -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: Moving forward on access control Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3529 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 Long-time members of the working group will recall that an access control protocol has long been on the agenda of this working group. The basic idea is to develop a network protocol, a set of extensions to HTTP, for remotely controlling access permissions for a Web resource. The lack of this protocol has not, to date, been a showstopper. Though access control is unboudtedly a feature that an authoring server must provide, the existence of server-specific interfaces for setting access permissions has, to date, been sufficient. However, these interfaces are not interoperable, and are generally not usable via a programmatic interface. That is, they assume a human is driving them, not a program. Over the group's life, there has been significant work on this subject, with several Internet-Drafts and meetings on the topic. There is a goals document and a protocol document: WebDAV Access Control Goals http://www.ics.uci.edu/pub/ietf/webdav/acl/draft-ietf-webdav-acl-reqts-00.tx t WebDAV ACL Protocol http://www.ics.uci.edu/pub/ietf/webdav/acl/draft-ietf-webdav-acl-00.txt There was also a breakout session on access control at the Orlando IETF: http://www.ics.uci.edu/pub/ietf/webdav/orlando/acl_breakout.html In fact, if you give the documents a read, you'll find both of them are in really good shape, thanks to the hard work of their editors, and do not appear to require a huge amount of work to be completed. Unfortunately, due to me not making them a priority, and due to the working group being focused on the advanced collections protocols, work on access control has languished. I'd like to restart efforts to finish the access control protocol. So, I'm putting out a call for volunteers to work on the WebDAV Access Control Protocol. If you've been sitting on the sidelines waiting for a good opportunity to get involved, this may be it. If you feel access control is important to WebDAV, then I encourage you to get involved. I'll also be repeating this call for volunteers during the WebDAV WG meeting at the Washington DC IETF meeting. I'd like to see a couple of things: * Volunteers willing to work on the protocol * Someone willing to volunteer weekly or biweekly conference call facilities * Volunteers who would be willing to act as a document editor * Volunteers who would be willing to spearhead efforts on the protocol, coordinating meetings, delegating work to other volunteers, etc. Since I need to finish my Ph.D. studies, this person cannot be me, much as I might like to do it. If you're interested, please send me an email at ejw@ics.uci.edu. If someone volunteers some conference call facilities, we could hold a teleconference as early as next week. - Jim From w3c-dist-auth-request@w3.org Mon Oct 25 18:32: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 SAA06823 for ; Mon, 25 Oct 1999 18:32:54 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id SAA18561; Mon, 25 Oct 1999 18:20:20 -0400 (EDT) Resent-Date: Mon, 25 Oct 1999 18:20:20 -0400 (EDT) Resent-Message-Id: <199910252220.SAA18561@www19.w3.org> From: Jim Whitehead To: Kevin Wiggen , www-webdav-dasl@w3.org, WebDAV WG MMDF-Warning: Parse error in original version of preceding line at gremlin-relay.ics.uci.edu Date: Mon, 25 Oct 1999 15:18:57 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Importance: Normal Subject: DASL on Sharemation Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3530 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list Content-Transfer-Encoding: 7bit I'd like to congratulate Kevin and Xythos for having (to the best of my knowledge) the first implementation of the SEARCH method and the DAV:basicsearch search syntax in the DASL searching protocol, . Yeah! - Jim -----Original Message----- From: www-webdav-dasl-request@w3.org [mailto:www-webdav-dasl-request@w3.org]On Behalf Of Kevin Wiggen Sent: Monday, October 25, 1999 11:01 AM To: www-webdav-dasl@w3.org Subject: DASL on Sharemation Xythos Software Inc., is proud to announce that the Xythos Storage Server (and thus Sharemation at www.sharemation.com) is now a DASL server. We are proud to enter into a BETA test phase with you the other members of the DASL community. Some of the specifics of our server. 1) All valid directories and files can act as a DASL search arbiter. Thus I can send a "SEARCH" request at any directory or file (http://www.sharemation.com/~kwiggen for instance). 2) As of right now, the URI that the request is sent in on is ignored, and the SCOPE inside the FROM clause is used as a fully qualified path. 3) Sharemation security will run as part of the query. This means that you either need to be sending our security cookies, basic authentication header, or running against "PUBLIC" files and directories. I suggest making files and folders "PUBLIC" for your testing purposes. 4) QSD is not operational as of yet, but it is at the bottom of this note. Any questions, comments, bugs, enhancements, please send to me wiggs@xythos.com. I look forward to hearing from others in the DASL community and working on integration. Kevin Wiggen Xythos Software Inc. From w3c-dist-auth-request@w3.org Mon Oct 25 19:26: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 TAA07265 for ; Mon, 25 Oct 1999 19:26:37 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id TAA20551; Mon, 25 Oct 1999 19:14:38 -0400 (EDT) Resent-Date: Mon, 25 Oct 1999 19:14:38 -0400 (EDT) Resent-Message-Id: <199910252314.TAA20551@www19.w3.org> Message-ID: <078292D50C98D2118D090008C7E9C6A603C9679D@STAY.platinum.corp.microsoft.com> From: "Yaron Goland (Exchange)" To: "'Jim Whitehead'" , WebDAV WG Date: Mon, 25 Oct 1999 16:14:22 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Moving forward on access control Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3531 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list I am more than happy to continue in my roll as editor of the ACL protocol document assuming that we are able to get others sufficiently interested to continue with the requirements document and related work. Yaron > -----Original Message----- > From: Jim Whitehead [mailto:ejw@ics.uci.edu] > Sent: Mon, October 25, 1999 3:12 PM > To: WebDAV WG > Subject: Moving forward on access control > > > > Long-time members of the working group will recall that an > access control > protocol has long been on the agenda of this working group. > The basic idea > is to develop a network protocol, a set of extensions to > HTTP, for remotely > controlling access permissions for a Web resource. The lack > of this protocol > has not, to date, been a showstopper. Though access control > is unboudtedly a > feature that an authoring server must provide, the existence of > server-specific interfaces for setting access permissions > has, to date, been > sufficient. However, these interfaces are not interoperable, and are > generally not usable via a programmatic interface. That is, > they assume a > human is driving them, not a program. > > Over the group's life, there has been significant work on > this subject, with > several Internet-Drafts and meetings on the topic. There is a goals > document and a protocol document: > > WebDAV Access Control Goals > http://www.ics.uci.edu/pub/ietf/webdav/acl/draft-ietf-webdav-a > cl-reqts-00.tx > t > > WebDAV ACL Protocol > http://www.ics.uci.edu/pub/ietf/webdav/acl/draft-ietf-webdav-a cl-00.txt There was also a breakout session on access control at the Orlando IETF: http://www.ics.uci.edu/pub/ietf/webdav/orlando/acl_breakout.html In fact, if you give the documents a read, you'll find both of them are in really good shape, thanks to the hard work of their editors, and do not appear to require a huge amount of work to be completed. Unfortunately, due to me not making them a priority, and due to the working group being focused on the advanced collections protocols, work on access control has languished. I'd like to restart efforts to finish the access control protocol. So, I'm putting out a call for volunteers to work on the WebDAV Access Control Protocol. If you've been sitting on the sidelines waiting for a good opportunity to get involved, this may be it. If you feel access control is important to WebDAV, then I encourage you to get involved. I'll also be repeating this call for volunteers during the WebDAV WG meeting at the Washington DC IETF meeting. I'd like to see a couple of things: * Volunteers willing to work on the protocol * Someone willing to volunteer weekly or biweekly conference call facilities * Volunteers who would be willing to act as a document editor * Volunteers who would be willing to spearhead efforts on the protocol, coordinating meetings, delegating work to other volunteers, etc. Since I need to finish my Ph.D. studies, this person cannot be me, much as I might like to do it. If you're interested, please send me an email at ejw@ics.uci.edu. If someone volunteers some conference call facilities, we could hold a teleconference as early as next week. - Jim From w3c-dist-auth-request@w3.org Tue Oct 26 18:15: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 SAA01544 for ; Tue, 26 Oct 1999 18:15:52 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id SAA22832; Tue, 26 Oct 1999 18:03:18 -0400 (EDT) Resent-Date: Tue, 26 Oct 1999 18:03:18 -0400 (EDT) Resent-Message-Id: <199910262203.SAA22832@www19.w3.org> Message-ID: <381624FE.360EF337@ecal.com> Date: Tue, 26 Oct 1999 18:02: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: <078292D50C98D2118D090008C7E9C6A603C96789@STAY.platinum.corp.microsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: Can you move a locked file? Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3532 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: > My user's explicit goal is to prevent anyone, anywhere from have any ability > to manipulate their "private data worlds" in anyway. Uh...isn't that what access control is for? -- /==============================================================\ |John Stracke | http://www.ecal.com |My opinions are my own.| |Chief Scientist |=============================================| |eCal Corp. |Please do not adjust your mind--reality is | |francis@ecal.com|malfunctioning. | \==============================================================/ From w3c-dist-auth-request@w3.org Tue Oct 26 18:49: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 SAA03321 for ; Tue, 26 Oct 1999 18:49:35 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id SAA23960; Tue, 26 Oct 1999 18:37:43 -0400 (EDT) Resent-Date: Tue, 26 Oct 1999 18:37:43 -0400 (EDT) Resent-Message-Id: <199910262237.SAA23960@www19.w3.org> Date: Tue, 26 Oct 1999 15:38:31 -0700 (PDT) From: Greg Stein To: w3c-dist-auth@w3.org In-Reply-To: <381624FE.360EF337@ecal.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: Re: Can you move a locked file? Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3533 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 Tue, 26 Oct 1999, John Stracke wrote: > "Yaron Goland (Exchange)" wrote: > > > My user's explicit goal is to prevent anyone, anywhere from have any ability > > to manipulate their "private data worlds" in anyway. > > Uh...isn't that what access control is for? I don't think so. Access control is long-term, locks are shorter/transitory. I totally agree with Yaron here: if I'm editing a document (with a lock), then it sure as hell better not move on me. That is just annoying and wrong. This whole business about the server retaining redirects after a move of a locked resource seems really and arbitrarily complex. Why support something like that? Just say a server MUST refuse a move of a locked resource rather than "well, it might or it might not, but you really won't know unless you try." And if this nonsense does go thru as a "consensus change" to the move/lock behavior, then the default should be to refuse the move. There was a suggestion that an app should set a flag to state that it can't support locked resources that may move -- that's backwards since the current behavior is "I lock it and it stays there until I unlock it." In other words, an app should say "I can support you [the server] moving this locked resource on me and sending me a 301 response." (I still don't like it though because of the additional complexity on the client, which people seem to be ignoring, much to Yaron's dismay; who on this list is actually writing client software/tools/apps?) Personally, I'll refuse the darn move. I'm not going to start recording all these redirects on the server. Cheers, -g -- Greg Stein, http://www.lyra.org/ From w3c-dist-auth-request@w3.org Tue Oct 26 22:17: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 WAA13362 for ; Tue, 26 Oct 1999 22:17:58 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id WAA27798; Tue, 26 Oct 1999 22:06:14 -0400 (EDT) Resent-Date: Tue, 26 Oct 1999 22:06:14 -0400 (EDT) Resent-Message-Id: <199910270206.WAA27798@www19.w3.org> Date: Tue, 26 Oct 1999 19:06:51 -0700 (PDT) From: Greg Stein To: ccjason@us.ibm.com cc: w3c-dist-auth@w3.org In-Reply-To: <8525680F.0004EFDA.00@D51MTA03.pok.ibm.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: Re: One lock per resource per person? Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3534 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 Mon, 18 Oct 1999 ccjason@us.ibm.com wrote: > This original question seems to have gotten lost in a tangent. I'd appreciate > hearing more voices on this original issue which now is... > > "Can the two > shared locks owned by the same principal be rooted at the same resource?" I would say "absolutely." Consider Application A and Application B, each running on the user's machine, each wanting to take a shared lock on the particular resource. (shared because the two apps can't use an exclusive lock) Cheers, -g -- Greg Stein, http://www.lyra.org/ From w3c-dist-auth-request@w3.org Wed Oct 27 00:40: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 AAA19037 for ; Wed, 27 Oct 1999 00:40:41 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id AAA00231; Wed, 27 Oct 1999 00:28:58 -0400 (EDT) Resent-Date: Wed, 27 Oct 1999 00:28:58 -0400 (EDT) Resent-Message-Id: <199910270428.AAA00231@www19.w3.org> Date: Wed, 27 Oct 1999 00:28:52 -0400 Message-Id: <9910270428.AA25890@tantalum> From: "Geoffrey M. Clemm" To: w3c-dist-auth@w3.org In-Reply-To: (message from Greg Stein on Tue, 26 Oct 1999 15:38:31 -0700 (PDT)) Subject: Re: Can you move a locked file? Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3535 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: Greg Stein I totally agree with Yaron here: if I'm editing a document (with a lock), then it sure as hell better not move on me. That is just annoying and wrong. It's also annoying and wrong for a resource that is on my favorites list to be moved away and have me get a 302 back. Why not just leave the darn thing where it is? Well, there are sometimes good reasons to move it. And these reasons also apply, even if someone currently has a write lock out on some leaf resource. Luckily, it's quite easy to cope with a 302, so life goes on. If the proposal was that a server MUST allow the move and MUST provide 302's, I could see the server writers complaining. But that's not the case. A server is free to block the move, if that's what it thinks best serves its customers (or is the easiest to implement). I agree that getting a 302 on access to a locked resource would be new behavior, but I have heard no arguments (convincing or otherwise :-) as to how a 302 would be hard for a client to deal with. This whole business about the server retaining redirects after a move of a locked resource seems really and arbitrarily complex. Why support something like that? Just say a server MUST refuse a move of a locked resource rather than "well, it might or it might not, but you really won't know unless you try." What causes something to be renamed by a versioning server is not just a MOVE operation, but rather any change to any metadata that affects the revision selection for a versioned collection. Unless it re-computes all revision selection rules for all versioned collections before *any* requested metadata change (i.e. moving a label, changing the member of a configuration), it won't know whether or not the name of a locked resource will change. So although a versioning server can always tell you where your versioned resource is, it is computationally infeasible for it to detect whether the name of a locked resource is affected by a change. I'm just looking for a compromise that gives us interoperability between down-level clients and versioning servers. And if this nonsense does go thru as a "consensus change" to the move/lock behavior, then the default should be to refuse the move. There was a suggestion that an app should set a flag to state that it can't support locked resources that may move -- that's backwards since the current behavior is "I lock it and it stays there until I unlock it." In other words, an app should say "I can support you [the server] moving this locked resource on me and sending me a 301 response." I personally would not favor any flag that splits the locking behavior into two different flavors. Since I can't imagine clients putting in alternative code paths for these different flavors of locks, this just guarantees non-interoperability, as each flavor of server fails a client's request to provide the other flavor of lock. We should just pick one interoperable semantics. I'd just like us to pick a semantics that is implementable by both versioning and non-versioning servers. (I still don't like it though because of the additional complexity on the client, which people seem to be ignoring, much to Yaron's dismay; who on this list is actually writing client software/tools/apps?) Every versioning server implementor on this mailing list that I know of is also a client implementor. This is also true for all the document management system server implementors that I know of. Personally, I'll refuse the darn move. I'm not going to start recording all these redirects on the server. I'd be against any protocol that required you to do otherwise. I'd just like to see us produce a protocol that is compatible with versioning (after all, this is Distributed Authoring and Versioning :-). Cheers, Geoff From w3c-dist-auth-request@w3.org Wed Oct 27 09:19: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 JAA10865 for ; Wed, 27 Oct 1999 09:19:36 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id JAA13420; Wed, 27 Oct 1999 09:07:49 -0400 (EDT) Resent-Date: Wed, 27 Oct 1999 09:07:49 -0400 (EDT) Resent-Message-Id: <199910271307.JAA13420@www19.w3.org> Date: Wed, 27 Oct 1999 09:07:42 -0400 Message-Id: <9910271307.AA26053@tantalum> From: "Geoffrey M. Clemm" To: w3c-dist-auth@w3.org Subject: why URL protection is not feasible when you version collections Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3536 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 key pieces of functionality that a versioning server can provide is the ability to version collections. The versioning server remembers the states (revisions) of a collection (i.e. the list of internal members). This lets a client roll back to a previous state of the URL namespace, hold the namespace fixed while it is making changes and then updating to the current state, or even let let clients make changes to the namespace in parallel and then merge the results when appropriate. Now suppose you are a versioning unaware client, but you do know about locking. There is a default workspace (containg the revision selection rules that compute what revision of a collection will show up in the workspace) that all your requests work against. Suppose you LOCK /x/y/z/foo.html. The versioning server will automagically check it out into the default workspace, and lock the resulting working resource. But it's not just /x/y/z/foo.html that is versioned, but also the collections /x/y/z and /x/y and even /x, just for good measure. Now some other client wants to add a label to some revision of /x/y. Is this OK? Well, if locked resources cannot be renamed, before the server can let the label be added, it has to compute the revision selection rule to see if this would cause a new revision of /x/y to be selected in the default workspace. If this new revision of /x/y renames the member named "z" to be "oldz", the server must fail the label request (or else /x/y/z/foo.html will be renamed /x/y/oldz/foo.html). You have to run this check on *every* change to *any* metadata (e.g. label, activity), against *every* workspace that might use that metadata. Thus the term "computationally infeasible" (:-). So one alternative is the one I've proposed earlier ... require that *if* a server allows renaming of locked resources, then it MUST return a 302 indicating where that locked resource ended up. A server is of course free to refuse the move ... it's only servers that allow the move that need to do the tracking for 302 responses. Today's locking servers are all protocol compliant; versioning servers are protocol compliant; and clients just have to handle the occasional (but rare) 302 coming back on access to a locked resource. There is another alternative: have versioning servers tightly constrain the default workspace so that URL protection is feasible (perhaps, only allow a single label rule). Then define locking to have the above behavior whenever a Target-Selector header is included in the LOCK request (indicating a versioning aware client), but have the URL protection behavior if there is no Target-Selector header specified. I believe this is a significantly inferior alternative, since it defines two subtly different locking behaviors based on the presence of a non-lock related header. Its only benefit is that a versioning unaware client is protected from 302's. Since there are at least a couple of non-versioning implementors on this list that prefer the 302 behavior, I believe it is not just a complexity introduced by versioning, but rather it is something that is actually simpler for some classes of simple servers as well. I'd still like to hear a convincing argument as to why it is hard for a client to deal with a 302 on an access to a locked resource. Cheers, Geoff From w3c-dist-auth-request@w3.org Wed Oct 27 09:54: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 JAA12237 for ; Wed, 27 Oct 1999 09:54:27 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id JAA14647; Wed, 27 Oct 1999 09:42:56 -0400 (EDT) Resent-Date: Wed, 27 Oct 1999 09:42:56 -0400 (EDT) Resent-Message-Id: <199910271342.JAA14647@www19.w3.org> From: jamsden@us.ibm.com X-Lotus-FromDomain: IBMUS To: w3c-dist-auth@w3.org Message-ID: <85256817.004B325F.00@d54mta03.raleigh.ibm.com> Date: Wed, 27 Oct 1999 09:38:08 -0400 Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Subject: Re: Can you move a locked file? Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3537 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 have to agree with Greg and Yaron. I too think that locking a resource should prevent it from being moved except by the owner of the lock. It doesn't seem like the flexibility for allowing locked resources to be moved by others justifies the complexity it adds to the protocol semantics and server implementations. I would like to minimize the use of lock tokens rather than introducing them as part of namespace management. This does not mean that another principal is unable to create a new binding to the locked resource, only that they cannot remove an existing binding. However, I don't think this completely resolves the locking problem. The reason this came up was with respect to MOVE retaining locks. The current spec says locks are lost on move, even if the owner of the lock is doing the move. MOVE could be either a rename or copy/delete depending on how the server has to implement it. It is my understanding that the advanced collections specification has specified the semantics of MOVE as rename, and if clients want to do a COPY/DELETE, they can do that and hide it in their UI. This makes MOVE a kind of rebind that does not disturb other bindings, or actually require the physical resource to move. (Perhaps it should be called RENAME then). In this case, it doesn't make sense for the locks to be lost. Only the lock owner can do the MOVE, and the locks should be retained. There is no need to change COPY/DELETE semantics with respect to locks, only this new, more specific definition of MOVE. Greg Stein on 10/26/99 06:38:31 PM To: w3c-dist-auth@w3.org cc: Subject: Re: Can you move a locked file? On Tue, 26 Oct 1999, John Stracke wrote: > "Yaron Goland (Exchange)" wrote: > > > My user's explicit goal is to prevent anyone, anywhere from have any ability > > to manipulate their "private data worlds" in anyway. > > Uh...isn't that what access control is for? I don't think so. Access control is long-term, locks are shorter/transitory. I totally agree with Yaron here: if I'm editing a document (with a lock), then it sure as hell better not move on me. That is just annoying and wrong. This whole business about the server retaining redirects after a move of a locked resource seems really and arbitrarily complex. Why support something like that? Just say a server MUST refuse a move of a locked resource rather than "well, it might or it might not, but you really won't know unless you try." And if this nonsense does go thru as a "consensus change" to the move/lock behavior, then the default should be to refuse the move. There was a suggestion that an app should set a flag to state that it can't support locked resources that may move -- that's backwards since the current behavior is "I lock it and it stays there until I unlock it." In other words, an app should say "I can support you [the server] moving this locked resource on me and sending me a 301 response." (I still don't like it though because of the additional complexity on the client, which people seem to be ignoring, much to Yaron's dismay; who on this list is actually writing client software/tools/apps?) Personally, I'll refuse the darn move. I'm not going to start recording all these redirects on the server. Cheers, -g -- Greg Stein, http://www.lyra.org/ From w3c-dist-auth-request@w3.org Wed Oct 27 11:38: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 LAA17714 for ; Wed, 27 Oct 1999 11:38:55 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id LAA17434; Wed, 27 Oct 1999 11:16:52 -0400 (EDT) Resent-Date: Wed, 27 Oct 1999 11:16:52 -0400 (EDT) Resent-Message-Id: <199910271516.LAA17434@www19.w3.org> Date: Wed, 27 Oct 1999 11:16:44 -0400 Message-Id: <9910271516.AA26170@tantalum> From: "Geoffrey M. Clemm" To: w3c-dist-auth@w3.org In-Reply-To: <85256817.004B325F.00@d54mta03.raleigh.ibm.com> (jamsden@us.ibm.com) Subject: Re: Can you move a locked file? Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3538 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 too think that locking a resource should prevent it from being moved except by the owner of the lock. It doesn't seem like the flexibility for allowing locked resources to be moved by others justifies the complexity it adds to the protocol semantics and server implementations. OK, as that old campaign slogan went: "Show Me the Beef", or more precisely, "Show Me the Cost". First, there is no added cost to a server. A server can just refuse the move, if that's what it wants to do. The benefit to the server is that it has a degree of freedom it previously lacked. I described in an earlier message why this degree of freedom is essential for supporting versioned collections. Second, the only client cost of this approach is that a client will on rare occasion get back a 302 for a locked resource, at which point it updates its name table and moves on with its business. It may well be that this breaks clients in ways I haven't predicted, but I haven't heard any client implementor make this case. I would like to minimize the use of lock tokens rather than introducing them as part of namespace management. Lock tokens already take part in namespace management if they can "protect" the URL namespace. This does not mean that another principal is unable to create a new binding to the locked resource, only that they cannot remove an existing binding. When collections are versioned, changing a binding is not just an explicit operation. It is also the result of a revision rule evaluation against the versioning metadata (labels, activities, baselines). To prevent a binding from being removed, you have to precede every metadata update with an evaluation of every potentially affected revision selection rule in every workspace to ensure it does not violate "URL protection". However, I don't think this completely resolves the locking problem. The reason this came up was with respect to MOVE retaining locks. The current spec says locks are lost on move, even if the owner of the lock is doing the move. MOVE could be either a rename or copy/delete depending on how the server has to implement it. It is my understanding that the advanced collections specification has specified the semantics of MOVE as rename, and if clients want to do a COPY/DELETE, they can do that and hide it in their UI. This makes MOVE a kind of rebind that does not disturb other bindings, or actually require the physical resource to move. (Perhaps it should be called RENAME then). In this case, it doesn't make sense for the locks to be lost. Only the lock owner can do the MOVE, and the locks should be retained. There is no need to change COPY/DELETE semantics with respect to locks, only this new, more specific definition of MOVE. I agree with everything Jim says in the preceding paragraph. Cheers, Geoff From w3c-dist-auth-request@w3.org Wed Oct 27 12:46: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 MAA22144 for ; Wed, 27 Oct 1999 12:46:14 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id MAA20004; Wed, 27 Oct 1999 12:34:42 -0400 (EDT) Resent-Date: Wed, 27 Oct 1999 12:34:42 -0400 (EDT) Resent-Message-Id: <199910271634.MAA20004@www19.w3.org> Message-ID: <078292D50C98D2118D090008C7E9C6A603C967BD@STAY.platinum.corp.microsoft.com> From: "Yaron Goland (Exchange)" To: "'Geoffrey M. Clemm'" , w3c-dist-auth@w3.org Date: Wed, 27 Oct 1999 09:34:33 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BF2099.20EBA524" Subject: RE: why URL protection is not feasible when you version collectio ns Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3539 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 message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01BF2099.20EBA524 Content-Type: text/plain Geoff, if http://lists.w3.org/Archives/Public/w3c-dist-auth/1999JulSep/0359.html doesn't convince you why it is we won't handle 302s then frankly we aren't going to be able to convince you. The bottom line is, baring a change in policy (which is always possible) Office and products like it will refuse to enable "save" functionality with any server that allows locked files to be moved. The ramifications on the user experience (NOT THE DIFFICULTY OF CODING) is simply too high. Having spent a long time as a PM at MS I can tell you exactly how the conversation will go: Gee, so you're telling me that the user loads a document, locks it, wants to manipulate it through other tools and randomly it can just... move? What the hell are we supposed to do? Put up a dialog "Hello Dear User, sorry to disturb you, but for some reason the file you are editing has been moved, please don't panic, it is still locked, but um.. yeah... it's in this new place now. Please make sure you remember this when you try to access it from some place else." The support costs alone for dealing with the pissed off users would rob us of any profit on that sale of Office. The worst part is that most users won't be calling because they hate the fact that their locked file was moved. They will be calling because they didn't understand the dialog, went to play with their file and it was gone! They will call to ask where the hell it went. Which means that the poor support tech has to figure out if he is dealing with a file system problem, an Office problem, a server problem, or what have you. I'm already having nightmares about the support costs. As I said in section 4.7.1 of http://lists.w3.org/Archives/Public/w3c-dist-auth/1998OctDec/0305.html: When a company sells client software it usually has to give away a certain amount of free support. If a user picks up the phone to use their free support all the profit on that sale is generally negated as a function of the cost of providing help services. As such any sane Office PM is going to "just say no"(tm). BTW, I make no guarantees. I don't work for Office. I just work with them. I am only passing on to you my own experience in having worked with them. So, just to re-iterate, this isn't about coding difficulty. This is about user experience. No matter what the group passes, no matter what the standard says, there is absolutely 0% chance that any sane client developer is going to give their users a bad user experience. If the protocol mandates it then the developer has no alternative but to either be non-compliant or to use another protocol. How about we don't put the poor client developers into that position? Yaron > -----Original Message----- > From: Geoffrey M. Clemm [mailto:geoffrey.clemm@rational.com] > Sent: Wednesday, October 27, 1999 6:08 AM > To: w3c-dist-auth@w3.org > Subject: why URL protection is not feasible when you version > collections > > > > One of the key pieces of functionality that a versioning server can > provide is the ability to version collections. The versioning server > remembers the states (revisions) of a collection (i.e. the list of > internal members). This lets a client roll back to a previous state > of the URL namespace, hold the namespace fixed while it is making > changes and then updating to the current state, or even let let > clients make changes to the namespace in parallel and then merge the > results when appropriate. > > Now suppose you are a versioning unaware client, but you do know about > locking. There is a default workspace (containg the revision > selection > rules that compute what revision of a collection will show up in the > workspace) that all your requests work against. > > Suppose you LOCK /x/y/z/foo.html. The versioning server will > automagically check it out into the default workspace, and lock the > resulting working resource. > > But it's not just /x/y/z/foo.html that is versioned, but also the > collections /x/y/z and /x/y and even /x, just for good measure. Now > some other client wants to add a label to some revision of /x/y. Is > this OK? Well, if locked resources cannot be renamed, before the > server can let the label be added, it has to compute the revision > selection rule to see if this would cause a new revision of /x/y to be > selected in the default workspace. If this new revision of /x/y > renames the member named "z" to be "oldz", the server must fail the > label request (or else /x/y/z/foo.html will be renamed > /x/y/oldz/foo.html). > > You have to run this check on *every* change to *any* metadata > (e.g. label, activity), against *every* workspace that might use > that metadata. Thus the term "computationally infeasible" (:-). > > So one alternative is the one I've proposed earlier ... require > that *if* a server allows renaming of locked resources, then it MUST > return a 302 indicating where that locked resource ended up. > A server is of course free to refuse the move ... it's only servers > that allow the move that need to do the tracking for 302 responses. > Today's locking servers are all protocol compliant; versioning servers > are protocol compliant; and clients just have to handle the occasional > (but rare) 302 coming back on access to a locked resource. > > There is another alternative: have versioning servers tightly > constrain the default workspace so that URL protection is feasible > (perhaps, only allow a single label rule). Then define locking > to have the above behavior whenever a Target-Selector header is > included in the LOCK request (indicating a versioning aware client), > but have the URL protection behavior if there is no Target-Selector > header specified. > > I believe this is a significantly inferior alternative, since it > defines two subtly different locking behaviors based on the > presence of a non-lock related header. Its only benefit is that > a versioning unaware client is protected from 302's. > > Since there are at least a couple of non-versioning implementors > on this list that prefer the 302 behavior, I believe it is not > just a complexity introduced by versioning, but rather it is something > that is actually simpler for some classes of simple servers as > well. I'd still like to hear a convincing argument as to why it > is hard for a client to deal with a 302 on an access to a locked > resource. > > Cheers, > Geoff > ------_=_NextPart_001_01BF2099.20EBA524 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: why URL protection is not feasible when you version = collections

Geoff, if http://lists.w3.org/Archives/Public/w3c-dist-auth/1999= JulSep/0359.html doesn't convince you why it is we won't handle = 302s then frankly we aren't going to be able to convince = you.

The bottom line is, baring a change in policy (which = is always possible) Office and products like it will refuse to enable = "save" functionality with any server that allows locked files = to be moved. The ramifications on the user experience (NOT THE = DIFFICULTY OF CODING) is simply too high.

Having spent a long time as a PM at MS I can tell you = exactly how the conversation will go:

Gee, so you're telling me that the user loads a = document, locks it, wants to manipulate it through other tools and = randomly it can just... move? What the hell are we supposed to do? Put = up a dialog "Hello Dear User, sorry to disturb you, but for some = reason the file you are editing has been moved, please don't panic, it = is still locked, but um.. yeah... it's in this new place now. Please = make sure you remember this when you try to access it from some place = else."

The support costs alone for dealing with the pissed = off users would rob us of any profit on that sale of Office. The worst = part is that most users won't be calling because they hate the fact = that their locked file was moved. They will be calling because they = didn't understand the dialog, went to play with their file and it was = gone! They will call to ask where the hell it went. Which means that = the poor support tech has to figure out if he is dealing with a file = system problem, an Office problem, a server problem, or what have you. = I'm already having nightmares about the support costs.

As I said in section 4.7.1 of = http://lists.w3.org/Archives/Public/w3c-dist-auth/1998OctDec/0305.html:<= /FONT>

When a company sells client software it usually has = to give away a certain amount of free support. If a user picks up the = phone to use their free support all the profit on that sale is = generally negated as a function of the cost of providing help services. =

As such any sane Office PM is going to "just say = no"(tm).

BTW, I make no guarantees. I don't work for Office. I = just work with them. I am only passing on to you my own experience in = having worked with them.

So, just to re-iterate, this isn't about coding = difficulty. This is about user experience. No matter what the group = passes, no matter what the standard says, there is absolutely 0% chance = that any sane client developer is going to give their users a bad user = experience. If the protocol mandates it then the developer has no = alternative but to either be non-compliant or to use another protocol. = How about we don't put the poor client developers into that = position?

        =         =         Yaron

> -----Original Message-----
> From: Geoffrey M. Clemm [mailto:geoffrey.clemm@ration= al.com]
> Sent: Wednesday, October 27, 1999 6:08 = AM
> To: w3c-dist-auth@w3.org
> Subject: why URL protection is not feasible = when you version
> collections
>
>
>
> One of the key pieces of functionality that a = versioning server can
> provide is the ability to version = collections.  The versioning server
> remembers the states (revisions) of a = collection (i.e. the list of
> internal members).  This lets a client = roll back to a previous state
> of the URL namespace, hold the namespace fixed = while it is making
> changes and then updating to the current state, = or even let let
> clients make changes to the namespace in = parallel and then merge the
> results when appropriate.
>
> Now suppose you are a versioning unaware = client, but you do know about
> locking.  There is a default workspace = (containg the revision
> selection
> rules that compute what revision of a = collection will show up in the
> workspace) that all your requests work = against.
>
> Suppose you LOCK /x/y/z/foo.html.  The = versioning server will
> automagically check it out into the default = workspace, and lock the
> resulting working resource.
>
> But it's not just /x/y/z/foo.html that is = versioned, but also the
> collections /x/y/z and /x/y and even /x, just = for good measure.  Now
> some other client wants to add a label to some = revision of /x/y.  Is
> this OK?  Well, if locked resources cannot = be renamed, before the
> server can let the label be added, it has to = compute the revision
> selection rule to see if this would cause a new = revision of /x/y to be
> selected in the default workspace.  If = this new revision of /x/y
> renames the member named "z" to be = "oldz", the server must fail the
> label request (or else /x/y/z/foo.html will be = renamed
> /x/y/oldz/foo.html).
>
> You have to run this check on *every* change to = *any* metadata
> (e.g. label, activity), against *every* = workspace that might use
> that metadata.  Thus the term = "computationally infeasible" (:-).
>
> So one alternative is the one I've proposed = earlier ... require
> that *if* a server allows renaming of locked = resources, then it MUST
> return a 302 indicating where that locked = resource ended up.
> A server is of course free to refuse the move = ... it's only servers
> that allow the move that need to do the = tracking for 302 responses.
> Today's locking servers are all protocol = compliant; versioning servers
> are protocol compliant; and clients just have = to handle the occasional
> (but rare) 302 coming back on access to a = locked resource.
>
> There is another alternative: have versioning = servers tightly
> constrain the default workspace so that URL = protection is feasible
> (perhaps, only allow a single label = rule).  Then define locking
> to have the above behavior whenever a = Target-Selector header is
> included in the LOCK request (indicating a = versioning aware client),
> but have the URL protection behavior if there = is no Target-Selector
> header specified.
>
> I believe this is a significantly inferior = alternative, since it
> defines two subtly different locking behaviors = based on the
> presence of a non-lock related header.  = Its only benefit is that
> a versioning unaware client is protected from = 302's.
>
> Since there are at least a couple of = non-versioning implementors
> on this list that prefer the 302 behavior, I = believe it is not
> just a complexity introduced by versioning, but = rather it is something
> that is actually simpler for some classes of = simple servers as
> well.  I'd still like to hear a convincing = argument as to why it
> is hard for a client to deal with a 302 on an = access to a locked
> resource.
>
> Cheers,
> Geoff
>

------_=_NextPart_001_01BF2099.20EBA524-- From w3c-dist-auth-request@w3.org Wed Oct 27 13:28: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 NAA24934 for ; Wed, 27 Oct 1999 13:28:12 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id NAA22249; Wed, 27 Oct 1999 13:16:35 -0400 (EDT) Resent-Date: Wed, 27 Oct 1999 13:16:35 -0400 (EDT) Resent-Message-Id: <199910271716.NAA22249@www19.w3.org> Date: Wed, 27 Oct 1999 13:16:29 -0400 Message-Id: <9910271716.AA26330@tantalum> From: "Geoffrey M. Clemm" To: w3c-dist-auth@w3.org In-Reply-To: <078292D50C98D2118D090008C7E9C6A603C967BD@STAY.platinum.corp.microsoft.com> (yarong@Exchange.Microsoft.com) Subject: Re: why URL protection is not feasible when you version collectio ns Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3540 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)" Geoff, if http://lists.w3.org/Archives/Public/w3c-dist-auth/1999JulSep/0359.html doesn't convince you why it is we won't handle 302s then frankly we aren't going to be able to convince you. The bottom line is, baring a change in policy (which is always possible) Office and products like it will refuse to enable "save" functionality with any server that allows locked files to be moved. The ramifications on the user experience (NOT THE DIFFICULTY OF CODING) is simply too high. OK, we actually are making some progress here. The message you refer to above is primarily about how it makes coding difficult for a client writer, and that's been my major pushback ... I didn't see how this could be the case. (Note: I actually had a long response to that message all prepared, but after rereading it, various "humorous" comments could easily not be so funny from a different perspective, so I indulged in some self-censorship :-). Having spent a long time as a PM at MS I can tell you exactly how the conversation will go: OK, I always enjoy a good dramatization (:-). Gee, so you're telling me that the user loads a document, locks it, wants to manipulate it through other tools and randomly it can just... move? What the hell are we supposed to do? Put up a dialog "Hello Dear User, sorry to disturb you, but for some reason the file you are editing has been moved, please don't panic, it is still locked, but um.. yeah... it's in this new place now. Please make sure you remember this when you try to access it from some place else." Sounds about right to me, and you can even just re-use the code that you would use today when you get a 302 back from accessing an unlocked resource! Now I agree that a normal file system client doesn't know a 302 from a sharp stick in the eye, but I'm assuming that a WebDAV client has been web-enabled at least to the HTTP-1.0 level, in which case it's already handling 302 status codes. And as for that user, as soon as they unlock the file, that increasingly irritated co-worker who's been waiting for them to *finally* release their ?*?!@*! lock so they can get their job done, will move that file to the new place anyway, and the user will have to deal with it (without even getting the friendly 302 to warn them!). The support costs alone for dealing with the pissed off users would rob us of any profit on that sale of Office. The worst part is that most users won't be calling because they hate the fact that their locked file was moved. They will be calling because they didn't understand the dialog, went to play with their file and it was gone! I just don't see it. The file dialog popped up and told them that the file was moved. Heck, I *wish* that Word would do that today instead of keeping a long memory of all the places the file *used* to be. I just don't see users finding the concept of "moving a file to a new location" to be as mind-boggling as you suggest. For one reason, because they have to deal with it all the time! If I move a file (say in the Explorer), all of my other tools (on my desktop) that thought they know where the file was come back with "file not found". Here we're not saying "file not found", we're saying "file still found, but it's at this new location, which I will now remember for you". Now if only *all* my tools were this friendly! They will call to ask where the hell it went. But the tool just *told* them where it went. If the client is even a little bit friendly, it will update it's "file list history" with the new value. As opposed to the current protocol, where if a lock times out or gets deleted for administrative reasons (possibly because some poor co-worker needs to move the collection containing the locked resource :-), the user just gets told "sorry fella, not there anymore". Which means that the poor support tech has to figure out if he is dealing with a file system problem, an Office problem, a server problem, or what have you. I'm already having nightmares about the support costs. A user being told "your file is now here" scares you more than locks timing out and administrative lock removal? We've already got the second two things as part of the protocol. None of the three are likely, so it's not a "frequency of occurence" issue. So, just to re-iterate, this isn't about coding difficulty. This is about user experience. This is a good thing. It used to be about coding difficulty (:-). But I think the user experience issues are just as easy to address. No matter what the group passes, no matter what the standard says, there is absolutely 0% chance that any sane client developer is going to give their users a bad user experience. Well, actually, there's probably a very high chance that a client developer, sane or not, will give their users a bad user experience (:-). The question is: is the experience of being told that their file is at a new location (which they have to eventually cope with anyway once they unlock the file and the move occurs) a traumatic one at any significant level, and in addition, is it *more* traumatic than the experience of a user that needs to make a namespace change, but *can't* because there's always some file somewhere in that collection that has a lock on it. If the protocol mandates it then the developer has no alternative but to either be non-compliant or to use another protocol. How about we don't put the poor client developers into that position? Yes, the question is which proposal (if either) puts the developer in this position. Cheers, Geoff From w3c-dist-auth-request@w3.org Wed Oct 27 15:24: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 PAA02219 for ; Wed, 27 Oct 1999 15:24:29 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id PAA27065; Wed, 27 Oct 1999 15:12:44 -0400 (EDT) Resent-Date: Wed, 27 Oct 1999 15:12:44 -0400 (EDT) Resent-Message-Id: <199910271912.PAA27065@www19.w3.org> From: ccjason@us.ibm.com X-Lotus-FromDomain: IBMUS To: "Geoffrey M. Clemm" cc: w3c-dist-auth@w3.org Message-ID: <85256817.00697DD8.00@D51MTA03.pok.ibm.com> Date: Wed, 27 Oct 1999 15:15:10 -0400 Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Subject: Re: Simplifying RFC-2518 Locking: A proposal Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3541 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 going online with this one.... My thinking is that it could be possible for a collection to have a body, but we haven't defined how that works? As far collections often getting their content from elsewhere... that does kind of sound like something we'd see in a live/active/dynamic resource. But that doesn't mean a collection couldn't have a body. We just don't seem to have a reason to support or disallow it. If it does have a body... I would expect it to be locked. If it's getting it's body via another resource (and perhaps has a source property)... I would think the lock wouldn't matter since the client would go to another location to modify the source. The sense in which it matters would be that we need to let clients and servers know whether or not the collection lock "applies" to the "body", especially if that body is some other resource. If it does apply, then servers must lock that other resource in addition to the collection (and clients must expect this behavior). Leaving this undefined would leave clients and servers not knowing what to do in this case. Never mind. The more I think about it the more this becomes a rat hole. It's too similar to live resources and I don't want to get anywhere near that rathole. We're having a hard enough time dealing with locks. :-) I'll add locking of collection body to the list of locking issues, but I'd almost certainly defer discussion until the rest of locking is firm. From w3c-dist-auth-request@w3.org Wed Oct 27 16:42: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 QAA07154 for ; Wed, 27 Oct 1999 16:42:39 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id QAA28813; Wed, 27 Oct 1999 16:31:08 -0400 (EDT) Resent-Message-Id: <199910272031.QAA28813@www19.w3.org> X-Received: from e4.ny.us.ibm.com (e4.ny.us.ibm.com [32.97.182.104]) by nebula.lyra.org (8.9.3/8.9.3) with ESMTP id GAA12909 for ; Wed, 27 Oct 1999 06:51:36 -0700 From: jamsden@us.ibm.com X-Received: from southrelay02.raleigh.ibm.com (southrelay02.raleigh.ibm.com [9.37.3.209]) by e4.ny.us.ibm.com (8.9.3/8.9.3) with ESMTP id JAA144882 for ; Wed, 27 Oct 1999 09:49:41 -0400 X-Received: from d54mta03.raleigh.ibm.com (d54mta03.raleigh.ibm.com [9.67.228.35]) by southrelay02.raleigh.ibm.com (8.8.8m2/NCO v2.06) with SMTP id JAA23084 for ; Wed, 27 Oct 1999 09:50:10 -0400 X-Received: by d54mta03.raleigh.ibm.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id 85256817.004C033E ; Wed, 27 Oct 1999 09:50:14 -0400 X-Lotus-FromDomain: IBMUS To: Greg Stein Message-ID: <85256817.004BF083.00@d54mta03.raleigh.ibm.com> Date: Wed, 27 Oct 1999 09:48:33 -0400 Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline ReSent-Date: Wed, 27 Oct 1999 13:31:52 -0700 (PDT) ReSent-From: Greg Stein ReSent-To: w3c-dist-auth@w3.org ReSent-Subject: Re: One lock per resource per person? Subject: Re: One lock per resource per person? X-Mailing-List: archive/latest/3542 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list What this implies is that a principal is really some unit of concurrent processing. That's the only way update conflicts can occur anyway. However, WebDAV specifies the principal as a (potentially) authenticated user agent, which is not generally a process. Of course it could be, but this is outside the scope of WebDAV. The current locking semantics leaves the responsibility of managing current processing by the same principle with the principle, not the protocol and server. The principle can use lock tokens to distinguish applications that got the token by locking vs. some other out-of-band means. The management of this is, and should be, outside the scope of WebDAV. I would suggest that Gregs example would be better handled by the principal wanting to distinguish locks by application A and B using two different authentication aliases. We get the same function, but the server doesn't have to get into the business of managing multiple locks by the same principal. I also think this would make it easier for the actual principal to manage concurrent access because the aliases can be used to indicate what role he is playing in the potentially collaborating applications. These named roles will be a lot easier to understand and manage than opaque lock tokens handed out by the server. Greg Stein on 10/26/99 10:06:51 PM To: Jason Crawford/Watson/IBM@IBMUS cc: w3c-dist-auth@w3.org Subject: Re: One lock per resource per person? On Mon, 18 Oct 1999 ccjason@us.ibm.com wrote: > This original question seems to have gotten lost in a tangent. I'd appreciate > hearing more voices on this original issue which now is... > > "Can the two > shared locks owned by the same principal be rooted at the same resource?" I would say "absolutely." Consider Application A and Application B, each running on the user's machine, each wanting to take a shared lock on the particular resource. (shared because the two apps can't use an exclusive lock) Cheers, -g -- Greg Stein, http://www.lyra.org/ From w3c-dist-auth-request@w3.org Wed Oct 27 16:49: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 QAA07457 for ; Wed, 27 Oct 1999 16:49:02 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id QAA29005; Wed, 27 Oct 1999 16:37:37 -0400 (EDT) Resent-Date: Wed, 27 Oct 1999 16:37:37 -0400 (EDT) Resent-Message-Id: <199910272037.QAA29005@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: Wed, 27 Oct 1999 13:37:07 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 In-Reply-To: <9910271716.AA26330@tantalum> Importance: Normal Subject: RE: why URL protection is not feasible when you version collectio ns Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3543 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 actually tried to move the parent collection of a locked resource using some existing DAV tools, and here's what happened: User A: Opens document "/ejw/fun/survey.doc" with Word 2000. This locks the document. User A then goes and opens up Web folder on the desktop, displaying "/ejw/". User A then asks to rename folder "fun" to "notfun". An error message comes back, stating that the folder couldn't be renamed, but after manually refreshing the Web folder, it appears that a new folder "notfun" and the old folder "fun" are both still present. When the "fun" folder only contains "survey.doc", after the rename both folders contain distinct copies of "survey.doc". When "fun" contains more resources than just "survey.doc" before the move, the destination folder only contains these other resources, and does not contain "survey.doc" (Xythos), or contains all resources, including "survey.doc" (IIS 5 Beta 3). After the move, folder "fun" only contains "survey.doc". As I recall from RFC 2518, this is actually compliant behavior -- the move was performed best-effort. This suggests that part of the problem is the interplay between the new binding semantics of move, and the desire to preclude best-effort moves. - Jim From w3c-dist-auth-request@w3.org Wed Oct 27 17:19: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 RAA09454 for ; Wed, 27 Oct 1999 17:19:26 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id RAA29868; Wed, 27 Oct 1999 17:08:13 -0400 (EDT) Resent-Date: Wed, 27 Oct 1999 17:08:13 -0400 (EDT) Resent-Message-Id: <199910272108.RAA29868@www19.w3.org> Date: Wed, 27 Oct 1999 14:08:55 -0700 (PDT) From: Greg Stein To: Jim Whitehead cc: w3c-dist-auth@w3.org In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: RE: why URL protection is not feasible when you version collectio ns Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3544 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 Wed, 27 Oct 1999, Jim Whitehead wrote: >... > When "fun" contains more resources than just "survey.doc" before the move, > the destination folder only contains these other resources, and does not > contain "survey.doc" (Xythos), or contains all resources, including > "survey.doc" (IIS 5 Beta 3). After the move, folder "fun" only contains > "survey.doc". I'm not particularly set up to test this myself at the moment, but mod_dav should refuse the move entirely if you don't hold the lock. For a move of a collection, it scans the source tree looking for locks. (yes, you could argue there is a "better effort" than this... :-) Cheers, -g -- Greg Stein, http://www.lyra.org/ From w3c-dist-auth-request@w3.org Wed Oct 27 17:30: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 RAA10197 for ; Wed, 27 Oct 1999 17:30:23 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id RAA00368; Wed, 27 Oct 1999 17:19:01 -0400 (EDT) Resent-Date: Wed, 27 Oct 1999 17:19:01 -0400 (EDT) Resent-Message-Id: <199910272119.RAA00368@www19.w3.org> Date: Wed, 27 Oct 1999 14:18:38 -0700 (PDT) From: Greg Stein To: jamsden@us.ibm.com cc: w3c-dist-auth@w3.org In-Reply-To: <85256817.004BF083.00@d54mta03.raleigh.ibm.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: Re: One lock per resource per person? Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3546 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 Wed, 27 Oct 1999 jamsden@us.ibm.com wrote: > What this implies is that a principal is really some unit of concurrent > processing. That's the only way update conflicts can occur anyway. However, > WebDAV specifies the principal as a (potentially) authenticated user agent, > which is not generally a process. Of course it could be, but this is > outside the scope of WebDAV. The current locking semantics leaves the > responsibility of managing current processing by the same principle with > the principle, not the protocol and server. The principle can use lock > tokens to distinguish applications that got the token by locking vs. some > other out-of-band means. The management of this is, and should be, outside > the scope of WebDAV. I think you're using semantics as an excuse here. I do not read the same behavior from the spec (I see the same principle as being able to get multiple, shared locks); therefore, I think you're stating it [as above] solely in a way to support your hypotheses. > I would suggest that Gregs example would be better > handled by the principal wanting to distinguish locks by application A and > B using two different authentication aliases. NO. As a user, I am assigned a *single* authentication alias on the server. In an NT environment, it is my domain\username; in a Kerberos environment, it is my login user/ticket; etc. There is no easy way for the user to just "well, I'll use a second alias to differentiate these." That is out of the user's scope and reliant upon the network/security administrator. I *really* don't think the admin is about to say "well, let's see... they're going to use up to three apps simultaneously against our DAV server, so I guess that I'll create three users for this person; oh wait, but what if they want to run four apps? I guess that I tell the person they can't do that." The admin isn't going to do this for any number of reasons. And the user? There is no way they're going to go through a separate authentication processes with the server simply to use more than one app at a time. As a user, one of the best things that I like about Windows is that it automatically supplies my credentials to servers -- that I only have to supply them once. In the Unix world, I'm starting to change over to ssh to get similar functionality, but still.. Cheers, -g -- Greg Stein, http://www.lyra.org/ From w3c-dist-auth-request@w3.org Wed Oct 27 17:55: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 RAA11839 for ; Wed, 27 Oct 1999 17:55:36 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id RAA01397; Wed, 27 Oct 1999 17:39:13 -0400 (EDT) Resent-Date: Wed, 27 Oct 1999 17:39:13 -0400 (EDT) Resent-Message-Id: <199910272139.RAA01397@www19.w3.org> Date: Wed, 27 Oct 1999 14:37:43 -0700 Message-ID: <730-Wed27Oct1999143743-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: <9910270428.AA25890@tantalum> References: <9910270428.AA25890@tantalum> Subject: Re: Can you move a locked file? Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3547 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 gmc> I personally would not favor any flag that splits the locking gmc> behavior into two different flavors. Since I can't imagine gmc> clients putting in alternative code paths for these different gmc> flavors of locks, this just guarantees non-interoperability, as gmc> each flavor of server fails a client's request to provide the gmc> other flavor of lock. Well, uh, sheesh, I almost regret having to point this out, but the current LOCK method already describes two flavors of locking, and it seems to me that that overloading is what is causing the current disagreement and discussion. LOCKing a resource and LOCKing a namespace are different animals, whether you use the same verb or not. Having the method overloaded gives the opportunity for (1) implementation errors, and (2) wishing it weren't so. -- 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 Oct 27 18:04: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 SAA12482 for ; Wed, 27 Oct 1999 18:04:46 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id RAA02508; Wed, 27 Oct 1999 17:53:23 -0400 (EDT) Resent-Date: Wed, 27 Oct 1999 17:53:23 -0400 (EDT) Resent-Message-Id: <199910272153.RAA02508@www19.w3.org> Date: Wed, 27 Oct 1999 14:52:04 -0700 Message-ID: <4418-Wed27Oct1999145204-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: <9910271716.AA26330@tantalum> References: <078292D50C98D2118D090008C7E9C6A603C967BD@STAY.platinum.corp.microsoft.com> <9910271716.AA26330@tantalum> Subject: Re: why URL protection is not feasible when you version collectio ns Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3548 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 gmc> And as for that user, as soon as they unlock the file, that gmc> increasingly irritated co-worker who's been waiting for them to gmc> *finally* release their ?*?!@*! lock so they can get their job gmc> done, will move that file to the new place anyway, and the user gmc> will have to deal with it (without even getting the friendly 302 gmc> to warn them!). A lot of the discussion recently seems to have been assuming that this carpet-from-under-you movement is being done by someone else (or the same person) using a WebDAV MOVE. That seems *incredibly* unlikely and occasional to me. Though I'm sure that could occur sometime, the most likely scenario to me, it seems, is some Very Powerful Administrator moving things around directly on the server (or in the database or in the shoebox or whatever). It's hard for me to imagine a document repository where the only possible access mechanism is WebDAV. Even if the WebDAV server implementors do a complete and thorough job of tying LOCKing in with whatever other tools the administrator has available, it is the nature of administrative activity that there will certainly be a way to instantly nuke any LOCKs that get in the way. This is RFC-2518 compliant, and one presumes that clients will have to muddle through this. If you have a reasonable administrator, you'll get an email along these lines: "Tonight we're reorganizing the /whatsit/thatsit tree, in accordance with blah-blah-blah. Be sure to check in anything you have out before you go home tonight or be prepared to look for it in the new place." -- 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 Oct 27 18:14: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 SAA13075 for ; Wed, 27 Oct 1999 18:14:02 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id RAA00245; Wed, 27 Oct 1999 17:17:17 -0400 (EDT) Resent-Date: Wed, 27 Oct 1999 17:17:17 -0400 (EDT) Resent-Message-Id: <199910272117.RAA00245@www19.w3.org> Message-ID: <38176B49.A4D09786@raleigh.ibm.com> Date: Wed, 27 Oct 1999 17:14:49 -0400 From: Keith Wannamaker Reply-To: krw@raleigh.ibm.com Organization: IBM Corp. X-Mailer: Mozilla 4.61 [en] (WinNT; U) X-Accept-Language: ko,en MIME-Version: 1.0 To: w3c-dist-auth@w3.org References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: why URL protection is not feasible when you version collectio ns Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3545 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: > I'm not particularly set up to test this myself at the moment, but mod_dav > should refuse the move entirely if you don't hold the lock. For a move of > a collection, it scans the source tree looking for locks. This is correct, it will fail without moving anything. -- Keith Wannamaker IBM HTTP Server Development RTP NC, USA From w3c-dist-auth-request@w3.org Wed Oct 27 18:20: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 SAA13488 for ; Wed, 27 Oct 1999 18:20:54 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id SAA03534; Wed, 27 Oct 1999 18:09:20 -0400 (EDT) Resent-Date: Wed, 27 Oct 1999 18:09:20 -0400 (EDT) Resent-Message-Id: <199910272209.SAA03534@www19.w3.org> Date: Wed, 27 Oct 1999 15:10:17 -0700 (PDT) From: Greg Stein To: "Geoffrey M. Clemm" cc: w3c-dist-auth@w3.org In-Reply-To: <9910271516.AA26170@tantalum> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: Re: Can you move a locked file? Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3549 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 Wed, 27 Oct 1999, Geoffrey M. Clemm wrote: >... > When collections are versioned, changing a binding is not just an > explicit operation. It is also the result of a revision rule > evaluation against the versioning metadata (labels, activities, > baselines). To prevent a binding from being removed, you have to > precede every metadata update with an evaluation of every potentially > affected revision selection rule in every workspace to ensure it does > not violate "URL protection". Then why don't we look at the problems caused by selection rules, rather than assuming they are fixed and making everything else fit into their little world? Why can't we simply constrain the selection rules better, thereby avoiding the issues that you foresee with locks? Cheers, -g -- Greg Stein, http://www.lyra.org/ From w3c-dist-auth-request@w3.org Wed Oct 27 22:08: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 WAA23991 for ; Wed, 27 Oct 1999 22:08:05 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id VAA09089; Wed, 27 Oct 1999 21:56:34 -0400 (EDT) Resent-Date: Wed, 27 Oct 1999 21:56:34 -0400 (EDT) Resent-Message-Id: <199910280156.VAA09089@www19.w3.org> Date: Wed, 27 Oct 1999 21:56:27 -0400 Message-Id: <9910280156.AA26691@tantalum> From: "Geoffrey M. Clemm" To: w3c-dist-auth@w3.org In-Reply-To: (message from Greg Stein on Wed, 27 Oct 1999 15:10:17 -0700 (PDT)) Subject: Re: Can you move a locked file? Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3550 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: Greg Stein Then why don't we look at the problems caused by selection rules, rather than assuming they are fixed and making everything else fit into their little world? First I should emphasize that these issues only arise with level 3 versioning, which introduces versioned collections. Level 1 (Core) and Level 2 (Activity and Configuration) versioning do not provide namespace versioning, and therefore do not have this problem. But for many applications, versioning the URL namespace is essential, so we still need to face this issue for clients that desire support for namespace versioning. Why can't we simply constrain the selection rules better, thereby avoiding the issues that you foresee with locks? That is the essence of the fallback proposal I mentioned in an earlier message. In particular, you would need to: a) only provide URL protection in the default workspace b) constrain the selection rules in the default workspace Restriction (a) is needed because no matter how you restrict the selection rules, if you allow an arbitrary number of workspaces to have protected URL's, the cost of pre-computing the effect of even something simple like a label request will become arbitrarily large. Restriction (b) is needed because even if you only support URL protection in a single workspace, some selection rules (such as configurations and baselines) affect an arbitrary number of resources, and therefore the effect on the namespace of a baseline change would require arbitrarily large costs to pre-compute. Doing away with configurations and multiple workspaces entirely would eliminate much/most of the value of versioning. Cheers, Geoff From w3c-dist-auth-request@w3.org Wed Oct 27 23:43: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 XAA27414 for ; Wed, 27 Oct 1999 23:43:38 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id XAA11188; Wed, 27 Oct 1999 23:31:23 -0400 (EDT) Resent-Date: Wed, 27 Oct 1999 23:31:23 -0400 (EDT) Resent-Message-Id: <199910280331.XAA11188@www19.w3.org> From: jamsden@us.ibm.com X-Lotus-FromDomain: IBMUS To: w3c-dist-auth@w3.org Message-ID: <85256818.00134FB7.00@d54mta03.raleigh.ibm.com> Date: Wed, 27 Oct 1999 23:26:31 -0400 Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Subject: Re: One lock per resource per person? Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3551 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list Sure, I can agree with all of this too. What I was attempting to point out though is that lock tokens by themselves don't do anything unless the concurrent client applications do something with them. That is, having two lock tokens by the same principal using concurrent applications is like having no lock token at all. Either application, having a shared lock token can do its update and overwrite the other. Its the one lock token scenario that works, but only if the client applications are aware of how they got the lock token, so they know there is a possibility that some other application has one too. Even then doing something with this information is up to the client, the server and protocol don't add anything. The multiple authentication approach just makes the locks easier to differentiate. In any case, potential overwrite conflicts resulting from multiple shared locks must be managed by client applications using some out of band mechanism. This is one of the trust levels spelled out in the spec. It doesn't matter who has the multiple shared locks, only that they are shared. So I don't know what having a second shared lock on a resource allows principals to do that they couldn't do with a single lock. Greg Stein on 10/27/99 05:18:38 PM To: Jim Amsden/Raleigh/IBM@IBMUS cc: w3c-dist-auth@w3.org Subject: Re: One lock per resource per person? On Wed, 27 Oct 1999 jamsden@us.ibm.com wrote: > What this implies is that a principal is really some unit of concurrent > processing. That's the only way update conflicts can occur anyway. However, > WebDAV specifies the principal as a (potentially) authenticated user agent, > which is not generally a process. Of course it could be, but this is > outside the scope of WebDAV. The current locking semantics leaves the > responsibility of managing current processing by the same principle with > the principle, not the protocol and server. The principle can use lock > tokens to distinguish applications that got the token by locking vs. some > other out-of-band means. The management of this is, and should be, outside > the scope of WebDAV. I think you're using semantics as an excuse here. I do not read the same behavior from the spec (I see the same principle as being able to get multiple, shared locks); therefore, I think you're stating it [as above] solely in a way to support your hypotheses. > I would suggest that Gregs example would be better > handled by the principal wanting to distinguish locks by application A and > B using two different authentication aliases. NO. As a user, I am assigned a *single* authentication alias on the server. In an NT environment, it is my domain\username; in a Kerberos environment, it is my login user/ticket; etc. There is no easy way for the user to just "well, I'll use a second alias to differentiate these." That is out of the user's scope and reliant upon the network/security administrator. I *really* don't think the admin is about to say "well, let's see... they're going to use up to three apps simultaneously against our DAV server, so I guess that I'll create three users for this person; oh wait, but what if they want to run four apps? I guess that I tell the person they can't do that." The admin isn't going to do this for any number of reasons. And the user? There is no way they're going to go through a separate authentication processes with the server simply to use more than one app at a time. As a user, one of the best things that I like about Windows is that it automatically supplies my credentials to servers -- that I only have to supply them once. In the Unix world, I'm starting to change over to ssh to get similar functionality, but still.. Cheers, -g -- Greg Stein, http://www.lyra.org/ From w3c-dist-auth-request@w3.org Thu Oct 28 04:39: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 EAA12105 for ; Thu, 28 Oct 1999 04:39:42 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id EAA17089; Thu, 28 Oct 1999 04:28:15 -0400 (EDT) Resent-Date: Thu, 28 Oct 1999 04:28:15 -0400 (EDT) Resent-Message-Id: <199910280828.EAA17089@www19.w3.org> Message-ID: <38180886.CA7A919B@de.bosch.com> Date: Thu, 28 Oct 1999 10:25:42 +0200 From: Edgar Schwarz X-Mailer: Mozilla 4.05 [en] (X11; I; SunOS 5.6 sun4u) MIME-Version: 1.0 To: w3c-dist-auth@w3.org References: <078292D50C98D2118D090008C7E9C6A603C967BD@STAY.platinum.corp.microsoft.com> <9910271716.AA26330@tantalum> <4418-Wed27Oct1999145204-0700-bill@carpenter.ORG> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: why URL protection is not feasible when you version collectio ns Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3552 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 WJCarpenter wrote: > Even if the WebDAV server implementors do a complete and thorough job > of tying LOCKing in with whatever other tools the administrator has > available, it is the nature of administrative activity that there will > certainly be a way to instantly nuke any LOCKs that get in the way. > This is RFC-2518 compliant, and one presumes that clients will have to > muddle through this. And if you allow a lock to move with a 302 the admin has a clean WebDAV way to tell the locking user where his stuff has gone to instead of the client and its user "muddling through this". User: Hey, my locked file is gone ! Support: Did you already look in your mailbox ? You were warned that your file would be moved and to which place. But if it`s consensus that this method is user friendly, so be it. Cheers, 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 Oct 29 15:30: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 PAA14704 for ; Fri, 29 Oct 1999 15:30:34 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id PAA16471; Fri, 29 Oct 1999 15:18:20 -0400 (EDT) Resent-Date: Fri, 29 Oct 1999 15:18:20 -0400 (EDT) Resent-Message-Id: <199910291918.PAA16471@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: <85256819.0069D74F.00@D51MTA03.pok.ibm.com> Date: Fri, 29 Oct 1999 15:18:50 -0400 Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Subject: Re: One lock per resource per person? Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/3553 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list Sure, I can agree with all of this too. What I was attempting to point out though is that lock tokens by themselves don't do anything unless the concurrent client applications do something with them. That is, having two lock tokens by the same principal using concurrent applications is like having no lock token at all. Either application, having a shared lock token can do its update and overwrite the other. So can totally different principals. This argument is not unique to the issue of the same principal holding multiple locks on the same resource. I believe that was the issue we were trying to resolve. More in a sec... Its the one lock token scenario that works, but only if the client applications are aware of how they got the lock token, so they know there is a possibility that some other application has one too. Actually not much really works for shared *write* locks. Not without the clients identifying each other to insure that they get along with the other lockers, cooperating with the other lockers, and coordinating via another mechanism. I consider shared write locks to be a poor example of what shared locks can do but some other folks might find they offer an opportunity to develop their own cooperative locking schemes. As I said, I personally don't value shared write locks, but if someone values them between separate principal's, then they should also value them between indepedent applications using the same authentication credentials. There is no difference. I feel shared *read* locks are more valuable, and allowing independent parts of the same prinicple create separate locks works very well for shared read locks and saves client code that would be necessary to work around this if the server limitted things to one lock per principal. And if some servers adopt Geoff's redirected locatable lock proposal (and even if they don't). A separate locatable lock class could be invented whose only purpose is to track the location of a resource. These would also work very well if multiple independent applications using the same credentials were allowed to create locks. And without allowing multiple locks by the same principal, they couldn't work reliably. I don't know what other types of locks might be invented in the future, but the general rules seems to be that multiple independent applications using the same credentials should be allowed to create *shared* locks on the same resource. Although authentication is useful for ACL's, the authentication part of the locking support at this point only seems to be to insure that someone isn't submitting someone else's token. And in fact this whole locking system could work just fine with everyone using the *same* credentials if no one shared their tokens and the server didn't reveal them within the lock discovery process. (Servers appear to have this option in 2518.) BTW, the locatable lock class I mentioned above is kind of interesting for depth locks. It gives you a way, with URI protection, to declare that no resources can be removed from a collection, but folks can add resources to a collection. This is unlike write locking the collection because locking a collection blocks both the addition and the removal of resources. And depending if the depth locking is dynamic or not also adds an interesting twist to the semantics. If dynamic, once added, it can't be removed by other folks. If static. other principals can remove resources they've added.