Subject: Write Locks on Collections

From: Kevin Wiggen <[email-masked]>
Date: Tue, 23 Nov 1999 10:35:03 -0800

Jim Davis and I are having a discussion on what the appropriate behavior of
a write lock on a collection should be.

Re 7.5

A write lock on a collection, whether created by a "Depth: 0" or "Depth:
infinity" lock request, prevents the addition or removal of member URIs of
the collection by non-lock owners.

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.

What does this mean when a collection is locked via a Depth 0 lock:

1)  When a new resource is added to the collection, the resource is added
without a lock as the parent has only a Depth 0 lock.

2)  When a new resource is added to the collection, the resource is added
and inherits the lock from above (via the second paragraph above)

I will keep my ideas off this post (as this will just be the question), but
will send a follow up with my ideas.

Thanks,

Kevin

---

From: "Geoffrey M. Clemm" <[email-masked]>
Date: Tue, 23 Nov 1999 16:19:42 -0500

From: Kevin Wiggen <[email-masked]>

   Re 7.5

I believe it says "internal member".

I believe this statement should only apply to non-Depth:0 locks.
Otherwise, this results in the inability to independently lock
a collection and members of the collection.  This should be clarified/fixed
in the next draft of 2518.

That's what I believe it should mean.

That would be a very bad thing, if the collection lock is depth:0.

Cheers,
Geoff

---

From: Greg Stein <[email-masked]>
Date: Tue, 23 Nov 1999 13:41:32 -0800 (PST)

On Tue, 23 Nov 1999, Geoffrey M. Clemm wrote:
>...

Nope. It just says "member".

> in the next draft of 2518.

I completely agree.

> That's what I believe it should mean.

Same here. mod_dav implements collection locks this way.

Cheers,
-g

-- 
Greg Stein, http://www.lyra.org/

---

From: Jim Davis <[email-masked]>
Date: Tue, 23 Nov 1999 23:26:13 +0100

>I believe this statement should only apply to non-Depth:0 locks.

Why do you believe this?

>a collection and members of the collection.  

How so?  please provide a sequence of operations that would be impossible
under this interpretation.

>That would be a very bad thing, if the collection lock is depth:0.

Why would it be bad?  What bad thing would occur, or what good thing would
be prevented?

sorry, but I just can't invent one my self.

best regards

Jim

---

From: Kevin Wiggen <[email-masked]>
Date: Tue, 23 Nov 1999 15:20:30 -0800

Xythos will currently only add a resource to a collection lock if its
depth is infinity.  Depth 0 locks will always only be on one resource.

  Kevin

  Jim Davis and I are having a discussion on what the appropriate behavior
of a write lock on a collection should be.

  Re 7.5

  I will keep my ideas off this post (as this will just be the question),
but will send a follow up with my ideas.

  Thanks,

  Kevin

---

From: Jim Davis <[email-masked]>
Date: Wed, 24 Nov 1999 09:08:03 +0100

A followup question for clarification 

Suppose I have a collection locked (at depth infinity), and I LOCK a  null
resource (7.4) within it.

Does this action constitute adding a resource  "as an internal member URI
of a locked collection " as in 7.5?

If so, then the locked-null resource now has two locks on it, right?

---

From: Greg Stein <[email-masked]>
Date: Wed, 24 Nov 1999 00:58:57 -0800 (PST)

> If so, then the locked-null resource now has two locks on it, right?

Yup. That's what mod_dav does.

Note that both locks must be shared.

And here is something that is really whacky: now remove the new lock --
the lock-null resource should still stick around since it had inherited
the lock from its parent collection. It will remain until that parent
collection's lock has been removed.

Fun, eh? :-)

Cheers,
-g

---

From: "Geoffrey M. Clemm" <[email-masked]>
Date: Wed, 24 Nov 1999 11:35:06 -0500

From: Greg Stein <[email-masked]>

Greg is correct.  I must have been been misled by what I *wanted* it
to say.  But the next sentence in 7.5 says:

   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
   DELETE to remove a resource which has a URI which is an existing
   internal member URI of a write locked collection, this request MUST
   fail if the principal does not have a write lock on the collection.

which leads one to believe that the intent was to talk about internal
members.  In any case, whatever the original intent may have been,
I would propose that the statement in question be modified to explicitly
state "internal member", since depth:0 locks should only affect the
addition and removal of internal members.

Cheers,
Geoff

---

From: "Geoffrey M. Clemm" <[email-masked]>
Date: Wed, 24 Nov 1999 11:46:06 -0500

X-Sender: [email-masked]
   X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 
   Date: Tue, 23 Nov 1999 23:26:13 +0100
   From: Jim Davis <[email-masked]>
   References: <[email-masked]>
   Mime-Version: 1.0
   Resent-From: [email-masked]
   X-Mailing-List: <[email-masked]> archive/latest/3638
   X-Loop: [email-masked]
   Sender: [email-masked]
   Resent-Sender: [email-masked]
   Precedence: list
   Content-Type: text/plain; charset="us-ascii"
   Content-Length: 1426

I lock a collection, because I'm going to be adding members
to that collection.  If a depth:0 lock applies to all the
immediate members of a collection as well, then I have prevented
anyone from updating the state of one of the existing internal members of
that collection.  If I'd wanted that behavior, I would have issued a
depth:1 lock.  And quoting from the definition of what depth means:

   The Depth header is used with methods executed on resources which
   could potentially have internal members to indicate whether the
   method is to be applied only to the resource ("Depth: 0"), to the
   resource and its immediate children, ("Depth: 1"), or the resource
   and all its progeny ("Depth: infinity").

Cheers,
Geoff

---

From: Jim Davis <[email-masked]>
Date: Fri, 26 Nov 1999 00:30:50 +0100

At 11:35 AM 11/24/99 -0500, Geoffrey M. Clemm wrote:
>... propose that the statement in question be modified to explicitly

internal members, as opposed to those added by, say, BIND?

Fine with me.

---

From: Jim Davis <[email-masked]>
Date: Fri, 26 Nov 1999 00:37:56 +0100

At 11:46 AM 11/24/99 -0500, Geoffrey M. Clemm wrote:
>that collection.  

But that's not what I asked about, or at least not what I thought I asked
about.

If I lock a collection with depth infinity lock, then create a new
interrnal member of that collection  (e.g. with PUT) I have to provide the
lock token to do the PUT, and the new internal member is added to the lock.

We all agree on this, right?

Now  suppose the lock were depth 0 not depth infinity.

1) to add a new internal member, I still have to provide the lock token, right?

2) Previously exising members are not affected.  I can PUT or PROPPATCH to
them at my whim, right?

3) However, I can't DELETE them without the lock token, right?

So where we seem to disagree is:

If I add a new internal member, is it added to the lock, or not? 

I interpret 7.5 as saying Yes.  You seem to think that the answer is, or
should be, no.

Can you please explain this?  I don't see how this depth 0 lock would
prevent anyone from updating the state of existing members.

with all best wishes

Jim

---

From: Greg Stein <[email-masked]>
Date: Fri, 26 Nov 1999 11:17:40 -0800 (PST)

> We all agree on this, right?

Yes.

> 1) to add a new internal member, I still have to provide the lock

Right.

> 2) Previously exising members are not affected.  I can PUT or PROPPATCH to

Right.

> 3) However, I can't DELETE them without the lock token, right?

Right. You must supply the locktoken because you are altering the
collection (on the theory that the set of names of internal members is
part of its state).

> If I add a new internal member, is it added to the lock, or not? 

It is not.

> prevent anyone from updating the state of existing members.

The depth:0 lock does not prevent people from updating existing members.
It prevents you from altering the collections state: the set of names of
internal members. Therefore, you cannot add or remove internal members.
This means you must supply a locktoken with PUT, MKCOL, or a DELETE. Note
that you shouldn't be able to create a locknull resource either(!) without
supplying a locktoken.

Cheers,
-g

---

From: "Geoffrey Clemm" <[email-masked]>
Date: Sun, 28 Nov 1999 13:37:44 -0500

> internal members, as opposed to those added by, say, BIND?

As opposed to members that are not internal members (where an internal
member is as it is defined in rfc2518).  For example, /a/b and /a/c are
internal members of /a, while /a/b/x and /a/c/y are members of /a but are
not internal members of /a.

Cheers,
Geoff

---

From: "Geoffrey Clemm" <[email-masked]>
Date: Sun, 28 Nov 1999 13:40:36 -0500

I agree with everything Greg says in this message.