Subject: GULP (version 5)

From: "Clemm, Geoff" <[email-masked]>
Date: Thu, 10 Oct 2002 16:59:49 -0400

Here is a new GULP, that tries to address the points raised in the
mailing list (i.e. UNLOCK, lock state clarification, submission of
lock tokens).

************************** 

Grand Unified Lock Proposal (V5) 

- A lock is either direct or indirect. 

- A LOCK request places a direct lock on the resource identified by 
  the request-URL.  The "lock-root" of the new lock is the request-URL.

- If a collection has a direct depth:infinity lock with token X, all 
  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.

- 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.

- A lock token is "submitted" in a request when it appears in an If
  header tagged-list whose tag is the lock-root of the lock.

- 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.

- If a request causes a resource with a direct lock to no longer be 
  mapped to the lock-root of that lock, then the request MUST 
  fail unless the lock-token for that lock is submitted in the 
  request.  If the request succeeds, then that lock MUST have been
 removed from that resource by that request. 

- If a request would cause two different exclusive locks to appear on 
  the same resource, the request MUST fail. 

**************************

---

From: "Julian Reschke" <[email-masked]>
Date: Fri, 11 Oct 2002 09:47:56 +0200

> From: [email-masked] [mailto:[email-masked]]On
> Behalf Of Clemm, Geoff
> Sent: Thursday, October 10, 2002 11:00 PM
> To: 'Webdav WG'
> Subject: GULP (version 5)
>
> ..
>
> ...

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...)

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?

Julian

--
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760