RE: Simplifying RFC-2518 Locking: A proposal

Geoff Clemm writes:
> A LOCK/UNLOCK request without a depth header places/removes a lock on
> exactly one resource (the resource identified by the request-URL).  A
> LOCK/UNLOCK request on a URL that is not mapped to a resource will
> fail with a 404.  You can use a depth header to place/remove locks on
> a collection and its members at the time of the lock.  This
> placement/removal of locks MUST be performed atomically, or the
> LOCK request MUST fail.

So far I'm in agreement -- the only divergence from RFC 2518 is the removal
of Null Locking.

> Only an explicit LOCK request ever adds a lock to a resource, and only
> an explicit UNLOCK request ever removes a lock from a resource.  In
> particular, locks are not deleted as a side effect of a MOVE or a
> DELETE

This too is OK.  Even though it's a divergence from RFC2518 for MOVE/DELETE
behavior, it's the approach that best minimizes user surprises for handing
resources that have multiple URL mappings.

>, and locks are not added as a side effect of a MOVE due to
> "inheriting a lock" from a collection.

This I disagree with.  The intent of depth locks was to (a) support locking
of composite objects with a single request, and (b) avoid two (or more)
clients from splitting up locks if both try to lock the same collection at
the same time using individual locks.  While removing the "inheritance"
qualities of locks would not affect (b), it would affect (a).

Furthermore, this proposal for simplifying locks doesn't give any rationale
for the change.  Several servers have been able to implement this feature
without any undue difficulty. Why do you consider this functionality to be
so broken it needs to be changed?

> A request fails with a 423 if the request would modify the state of a
> write-locked resource for which you don't hold the lock token.

... or the request does not contain both the lock token and authentication
credentials.

> The state of a basic resource is its body and its dead properties.

Live properties *are* part of the state of a resource, but are state that
isn't affected by a lock.  How can you have a processing action (i.e., the
action that is required to create the value of a live property) without
state?  Furthermore, some live properties could have state, if, for example,
the liveness of the property is merely a syntax check on the value of the
property when it is set using PROPFIND.

> The state of a collection is its set of bindings and its dead properties.

A collection can also have a body as its state. This body would be affected
by a lock.

> A write-lock request on a resource that is already write-locked will
> fail with a 423.

It's completely unacceptable to have locks whose timeout cannot be
refreshed. Since the way to refresh a lock is to re-issue a lock request to
a locked resource, your proposal would prevent lock timeout refreshes.
Making this change would result in significant interoperability problems
with existing clients, a bad idea.

- Jim

Received on Sunday, 17 October 1999 20:13:56 UTC