Subject: RE: Creating a lock-null in a locked collection

From: "Yaron Goland (Exchange)" <[email-masked]>
Date: Thu, 30 Dec 1999 12:04:22 -0800

The depth 0 lock controls the ability to add level 1 children to the
collection.
A lock null resource is a resource and hence is a member of whatever
collections it exists within.
Therefore to create a lock null resource as a level 1 child of a collection
with a depth 0 lock one must have the depth 0 lock.

In other words, yes, you must submit the token on the LOCK on /foo/bar.

			Yaron

> -----Original Message-----
> From: Joe Orton [mailto:[email-masked]]
> Sent: Thu, December 30, 1999 6:45 AM
> To: [email-masked]
> Subject: Creating a lock-null in a locked collection
> 
> 
> I have an depth 0 write lock on /foo/. If I do LOCK /foo/bar 
> to create a
> lock-null resource, do I need to submit the locktoken for /foo/ in the
> LOCK request? Or only in the PUT to /foo/bar later?
> 
> (Or is it decided that lock-null resources are going to go away?)
> 
> joe
>

---

From: "Geoffrey M. Clemm" <[email-masked]>
Date: Thu, 30 Dec 1999 17:33:05 -0500

As an addendum to Yaron's response, I'll note that there is a proposal
that WebDAV locking is better understood as locks on URL's rather than
on resources.  This not only makes the current WebDAV locking behavior
easier to motivate (e.g. a resource "loses" a lock after a move
because it is no longer identified by the locked URL), but removes the
need to define a "lock null resource".

One effect of this proposal would be that the answer to Joe's question
would change, i.e. that a LOCK request *never* requires a lock token.
A LOCK request can fail (such as when it would collide with an existing
exclusive lock), but no failure would be resolvable through the addition
of a lock token.

FYI, the current state of the lock proposal is:

A lock can be placed on a URL with a LOCK request.  This URL is called
the "lock base".  If the lock is Depth:N, then a lock is induced on
any URL that consists of the lock base extended by N or fewer
segments.  Only an authorized holder of a lock token for a locked URL
can modify either the state of the resource identified by the URL, or
which resource is identified by the URL.  A URL MAY NOT be locked
with two exclusive locks with the same locktype.

Cheers,
Geoff

   From: "Yaron Goland (Exchange)" <[email-masked]>

			   Yaron

---

From: Joe Orton <[email-masked]>
Date: Fri, 31 Dec 1999 00:37:59 +0000

> In other words, yes, you must submit the token on the LOCK on /foo/bar.

Okay, thanks. It just seemed slightly weird, that if you LOCK or UNLOCK a
lock-null resource, you are modifying the state of the parent collection;
when if you do the same to a normal resource, you are not.

Regards,

joe

---

From: "Geoffrey M. Clemm" <[email-masked]>
Date: Thu, 30 Dec 1999 22:35:23 -0500

From: Joe Orton <[email-masked]>

   ... It just seemed slightly weird, that if you LOCK or UNLOCK a
   lock-null resource, you are modifying the state of the parent collection;
   when if you do the same to a normal resource, you are not.

Yes, that is one of the reasons I strongly object to the notion of a
"lock null resource".  It sometimes acts like a resource (modifies the
parent collection), and sometimes does not (returns a 404 when you GET
it).  This makes it very hard to predict what its behavior should be
whenever you extend the protocol (i.e. should it act like a resource,
or act like not a resource).  For example:

- the BIND protocol (can you "BIND" a lock null resource to
  another URL?)
- the versioning protocol (do you have to checkout a versioned collection
  in order to add a lock null resource to it?)

Cheers,
Geoff