Subject: RE: UNLOCK from the middle of a locked tree

From: "Clemm, Geoff" <[email-masked]>
Date: Fri, 10 Mar 2000 17:05:58 -0500

I agree with Kevin.
Cheers,
Geoff

-----Original Message-----
From: Kevin Wiggen [mailto:[email-masked]]
Sent: Friday, March 10, 2000 4:17 PM
To: Slein, Judith A; [email-masked]
Cc: Hall, Shaun
Subject: RE: UNLOCK from the middle of a locked tree

I think the spec is trying to state A.  In fact that is what Xythos does
(well we don't need to traverse hierarchies, but that's an implementation
point).

From anywhere in a depth lock, if you send a correct lock token with a
unlock request, the lock is removed, thus unlocking the entire tree.

Kevin

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]On Behalf Of Slein, Judith A
Sent: Friday, March 10, 2000 1:03 PM
To: [email-masked]'
Cc: Hall, Shaun
Subject: UNLOCK from the middle of a locked tree

I have this question from a product team in my company.  Any opinions?  I
would say that (b) is not an option, but failing the unlock request might
be.

--Judy

Section 8.11 UNLOCK Method. The first sentence states "...and all other
resources included in the lock". Does this mean that a client should only
Unlock from the point where the lock starts? For example, in a hierarchy:

		Collection 1
		|	  |
	    Collection 2	Collection 3
		|	  |
	    Resource 4	Resource 5

If the lock was created with a Depth of infinity on "Collection 1", should
the user only perform the UNLOCK on "Collection 1"?

We're concerned that a client may try and unlock from a sub-point within the
hierarchy eg UNLOCK "Collection 2", which means to meet the first sentence
in the RFC, we either:

a) Have to traverse the entire hierarchy (parents and all) removing the lock
from all resources (in the above example, "Collection 1", "Collection 3" and
"File 5").

b) Only remove the lock from "Collection 2" and "File 4".

---

From: [email-masked]
Date: Fri, 10 Mar 2000 19:27:10 -0500

I agree.  (b) is not an option.  UNLOCK is all or nothing.

Whether the unlock is/shouldbe sensitive to the request URI is not clear to
me.    I'll agree with whatever the majority prefers.

------------------------------------------
Phone: 914-784-7569,   [email-masked]

---

From: [email-masked]
Date: Sat, 11 Mar 2000 12:11:14 -0500

I didn't read the spec exactly this way. I considered depth locks a
convenience for setting many locks on the same resource using the same lock
token in a single request. Depth in all other methods applies to the target
resource and recursively all its children. It never applies to a parent of
the target.

DAV4J gives an error if you attempt to unlock a depth locked resource from
any resource but the one that was originally locked. It does this by
checking to see if the immediate parent of the target resource is locked
with the same lock token.
|------------------------+------------------------>
|                        |   Kevin Wiggen         |
|                        |   <[email-masked]>|
|                        |   Sent by:             |
|                        |   w3c-dist-auth-request|
|                        |   @w3.org              |
|                        |                        |
|                        |   03/10/2000 04:17 PM  |
|                        |                        |
|------------------------+------------------------>
  >------------------------|
  |                        |
  |           To:          |
  |   "Slein, Judith A"    |
  |   <[email-masked]|
  |   >,                   |
  |   [email-masked] |
  |           cc:          |
  |   "Hall, Shaun"        |
  |   <[email-masked]|
  |   .COM>                |
  |           Subject:     |
  |   RE: UNLOCK from the  |
  |   middle of a locked   |
  |   tree                 |
  >------------------------|

Kevin

-----Original Message-----

--Judy

                Collection 1
               |          |

We're concerned that a client may try and unlock from a sub-point within
the
hierarchy eg UNLOCK "Collection 2", which means to meet the first sentence
in the RFC, we either:

a) Have to traverse the entire hierarchy (parents and all) removing the
lock
from all resources (in the above example, "Collection 1", "Collection 3"
and
"File 5").