RE: UNLOCK from the middle of a locked tree

I agree with Kevin.
Cheers,
Geoff

-----Original Message-----
From: Kevin Wiggen [mailto:wiggs@wiggenout.com]
Sent: Friday, March 10, 2000 4:17 PM
To: Slein, Judith A; w3c-dist-auth@w3.org
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: w3c-dist-auth-request@w3.org
[mailto:w3c-dist-auth-request@w3.org]On Behalf Of Slein, Judith A
Sent: Friday, March 10, 2000 1:03 PM
To: 'w3c-dist-auth@w3.org'
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".

Received on Friday, 10 March 2000 17:06:24 UTC