Subject: RE: GULP (version 5)

From: "Clemm, Geoff" <[email-masked]>
Date: Fri, 11 Oct 2002 09:19:48 -0400

From: Julian Reschke [mailto:[email-masked]]

   > From: Clemm, Geoff
   >
   > - If a request would modify the content or dead properties of a
   > locked resource, or would modify the bindings of a locked
   > collection, the request MUST fail unless the lock-token for that
   > lock is submitted in the request.

   Again, this is incomplete. We really need to get to a proper
   definition about what the state of a resource is.  At a minimun, it
   consists of:
   - content
   - dead properties
   - internal members (for collections)
   and
   - *some* live properties (DAV:lockdiscovery, DAV:getcontenttype,
   DAV:label-set, DAV:checked-in...)

Yes, you did already point that out, and I meant to add that.  Sorry
about the omission.

   Not that I like it but maybe any definition of live properties will
   have to specify whether the property would be proteced by a lock?

Yes, I think that is our only alternative.  (RFC-3253 does so).

Cheers,
Geoff

---

From: "Clemm, Geoff" <[email-masked]>
Date: Fri, 11 Oct 2002 09:19:47 -0400

From: Jason Crawford [mailto:[email-masked]]

   On Thursday, 10/10/2002 at 04:59 AST, "Clemm, Geoff" wrote:

   > - If a collection has a direct depth:infinity lock with token X,
   > - all

   Actually it doesn't matter if it's direct or not in this
   sentence.... or is "members" a recursive term?

Yes, members is a recursive term ("internal member" is the
non-recursive term).

   >   members of that collection (other than the collection itself)
   >   will have an indirect depth:infinity lock with token X.  In
   >   particular, if a binding to a resource is added to a collection
   >   with a depth:infinity lock with token X, and if the resource
   >   does not have a lock with token X, then an indirect lock with
   >   token X is added to the resource.  Conversely, if a resource
   >   has an indirect lock with token X, and if the result of
   >   removing a binding to the resource is that the resource is no
   >   longer a member of the collection with the direct lock with
   >   token X, then the lock with token X is removed from the
   >   resource.

   Again, it doesn't need to be direct at the parent, just the ancestor
   unless "members" is recursive.

Think about recursive bindings, where A is locked and A contains
a binding to B, B contains a binding to C, and C contains a binding
to B. If you remove the binding in A to B, you don't want B or
C to continue being locked (gotta handle those edge cases :-).

   > - An UNLOCK request removes all locks (both direct and indirect)
   > that have the lock token specified in the Lock-Token header of
   > the request.

   >   The request-URL of the request MUST identify a resource that
   >   has a lock (either direct or indirect) with the specified lock
   >   token.

   I am uncomfortable refering to multiple locks.  I've always thought
   of it as one lock that affects multiple resources.  I'm also
   uncomfortable saying a resource *has* as lock as opposed to saying
   it *is* locked.  But I have to admit that how you're saying it so
   far is very easy to understand.

I agree with you that we need to emphasize that a LOCK creates a
single lock that can protect the state of multiple resources.  I will
reword the proposal to do so.

   Do you want to say what happens if you lock an unmapped URL?

Yeah, I guess we should add that (:-).

    That leaves the issue of how much of the If header is evaluated.
    I'll start a seperate thread on that as Geoff requested.

Great!

Cheers,
Geoff