GULP (version 4)

We are about to submit a new ID for the BIND extension, and as part of
that work, we are verifying that locking semantics is clearly defined
in the presence of multiple bindings to a single resource.  The last
time we were working on locking for the bind proposal (about 2.5 years
ago :-), I submitted a series of GULPs (Grand Unified Locking
Proposals), the last of which was V3:
<http://lists.w3.org/Archives/Public/w3c-dist-auth/2000JanMar/0061.html>.
The most complex part of this proposal was capturing the semantics
of lock-null resources (and was a significant factor in my crusade
agains them :-).  Happily, now that we have cleaned up locking by
removing lock-null resources, we can also significantly simplify
the description of write-lock semantics:

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

Grand Unified Lock Proposal (V4)

- 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 request causes a resource with a direct lock to no longer be
  mapped to the lock-root of that lock, then that lock MUST be removed
  from that resource.

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

- If a request would modify the content, dead properties, or bindings
  of a locked resource, the request MUST fail unless the lock-token
  for that lock is specified in the request.

- If a request would remove a lock from a resource, the request MUST
  fail unless the lock-token for that lock is specified in the
  request.

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

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

If you have any locking use cases (no matter how obscure or unlikely)
that are not properly covered by this proposal, please let me know.
We're especially interested in obscure multiple binding use cases,
such as cyclic bindings.

Cheers,
Geoff