Subject: Re: DELETE Semantics

From: [email-masked]
Date: Fri, 24 Sep 1999 17:42:59 -0400

<ja>
    4. LOCK locks the resource, not the bindings. If the namespace needs to be
    controlled, then the user should lock the applicable parent collections.
    </ ja>

    <jlc>
    I agree that that's what seems to be suggested.  I just want to add, "ouch!
    That's a painful way to protect a URI.".
    </jlc>

  <jra>
  Then what are collections for if not to manage and control the namespace? What
  else could locking a collection mean? Note that it does not have to be a deep
  lock.
  </jra>

<jlc/> I agree that collections are to manage and control namespace.  My
editorial comment was that locking a whole collection to protect a single
binding seems like a lot of overkill.  And if you want to protect a URI
mapping... you'd have to lock the collection chain up to the root.  Even more
overkill.

---

From: "Geoffrey M. Clemm" <[email-masked]>
Date: Fri, 24 Sep 1999 18:13:07 -0400

From: [email-masked]

<gmc/> But the URL is "protected" by a LOCK, since we are requiring
that a subsequent use of the URL with that lock token always select
that locked resource.  We're just removing the language in 2518 that
over-constrained the server implementation (i.e. removing the language
that said you cannot apply a MOVE or a DELETE to a locked resource).
What 2518 didn't realize (and neither did I until Edgar pointed it
out) you don't need to prevent the MOVE or DELETE just to keep a
handle on the locked resource.

So you only need to apply a lock to a collection if you really want to
reserve the right to change the membership or properties of that
collection.

Cheers,
Geoff