Subject: Simplifying RFC-2518 Locking: A proposal

From: "Geoffrey M. Clemm" <[email-masked]>
Date: Fri, 15 Oct 1999 13:48:45 -0400

Encouraged by some degree of enthusiasm expressed on this list for
simplifying RFC-2518 locking, I've modified my earlier non-proposal in
light of the recent discussions on the mailing list, and now have a
real "proposal" to make.

**********

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.

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, and locks are not added as a side effect of a MOVE due to
"inheriting a lock" from a collection.

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.  The
state of a basic resource is its body and its dead properties.  The
state of a collection is its set of bindings and its dead properties.
A write-lock request on a resource that is already write-locked will
fail with a 423.

**********

And that's it.  This does lose some functionality.  It doesn't guarantee
that your handle on a locked resource will always be valid, and it doesn't
allow you to "add a resource" to a lock.  If one or both of these
are considered essential, I would be willing (but not happy :-) to add
one or both of the following extensions:

A Lock-Token header containing a lock token returned by a prior LOCK
request can be included in a subsequent LOCK request to extend an
existing LOCK.  A server may fail this request if the specified
lock token cannot be extended to the specified resource.

A Lock-Token header may be included in any request, which
will cause the request-URL to identify the resource that was identified
by that URL at the time it was locked with that lock token.

**********

I'll know Yaron is back from traveling when my in-box suddenly
bursts into flames before my eyes (:-).

Cheers,
Geoff

---

From: Jim Whitehead <[email-masked]>
Date: Sun, 17 Oct 1999 17:12:59 -0700

Geoff Clemm writes:
> 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.

> 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

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?

> 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

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