RE: a Grand Unified Locking Proposal (GULP, or perhaps, GULP! :-)

A problem with this proposal (and, to be fair, the same problem is shared by
RFC 2518) is it never defines what a lock *is*. That is, there is no
sentence here that begins, "A lock is a ...". As a result, this makes it
hard to assess whether statements such as the following make sense: "A lock
is on a URL. Every lock has a lock token and a lock owner."

Initially, a lock was a metaphor, extending the meaning of real-world locks
into the realm of computer data.  Real-world locks have several properties.
They have mass and volume.  That is, there is a physical lock mechanism that
takes up space, and hence be located someplace.  Examples are a lock set
into a door, and a padlock, where the lock is separate from the thing being
locked, and is connected by hooks, or a chain. Locks also have some way to
open them, and provide access to the locked item, either via a key, or a
combination.  When locking a volume of space, such as a room, it is possible
to simultaneously lock people out (prevent access), and lock people in
(guarantee exclusive access).  Ownership of a real world lock is separate
from the ability to lock and unlock it.  While typically the owner of a lock
also has the ability to lock and unlock it, there are often others who have
the same ability. Think of your office door -- you probably don't own the
door, but you can unlock it.

A WebDAV lock is an abstraction that arbitrates operations on resources. A
WebDAV write lock simultaneously guarantees that only the lock owner (or
owners, in the case of a shared lock), can write to the resource, and that
non-lock-owners are prevented from writing to the resource. Lock ownership
in WebDAV is synonymous having the ability to perform the lock-arbitrated
operation and unlock the locked resource.

WebDAV locks have state, the equivalent to mass and volume for real-world
locks.  The only description of the state of a lock in RFC 2518 can be found
in the lock discovery property, which gives the state of a lock as
containing:

  - lock type
  - lock scope
  - lock depth
  - lock timeout time
  - lock token
  - lock owner
  - lock URL (implicit)

For any stateful abstraction, such as a lock, there are several meaningful
questions.  Is the abstraction a first-class object?  That is, is its state
and existence independent of other system objects, and does it have its own
independent identity?  Or is the abstraction a component of some other
object.  Following the real-world lock analogy, is the lock more akin to a
padlock, independent of the items being locked, or a door lock, where the
lock is a component of the door.

So far in WebDAV, lock state has been part of a resource, since resources
are the only stateful objects in HTTP.  The GULP proposal, with statements
like, "a LOCK request creates a lock on the request URL," seems to imply
that lock state is part of a URL.  This is a troubling assertion since URLs
have not, to date, been stateful objects.  But, a further examination of
GULP (in the section "a LOCK request creates a lock on the request URL")
shows that the lock state is kept on the locked resource's collection, and
perhaps on the locked resource as well. Thus the lock is not "on" the URL at
all, but is instead on the locked resource's parent collection, and on the
resource.  The lock certaintly affects the URL, but it isn't "on" the URL.

Having the lock state as part of the collection is troublesome, since it
implies that only WebDAV resources inside WebDAV collections may be locked.
This is an additional (and unnecessary) restriction over anything specified
in RFC 2518.  Furthermore, duplicating the lock state in the resource and
its parent collection seems unnecessary.

So, before we proceed, I would like to see a definition of a lock that
begins with "A lock is a ...", and I'd like to see a better description of
what constitutes the state of a lock, and where this state is kept.
Answering these questions will help clarify the rest of the semantics
described in the GULP proposal.

- Jim


> -----Original Message-----
> From: w3c-dist-auth-request@w3.org
> [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Geoffrey M. Clemm
> Sent: Wednesday, January 12, 2000 3:13 PM
> To: w3c-dist-auth@w3.org
> Subject: a Grand Unified Locking Proposal (GULP, or perhaps, GULP! :-)
>
>
>
> Eric suggests that a URL-based locking model should be mapped into the
> underlying collection resources that implement the namespace.  I agree
> with both this conclusion and the reasoning leading up to it.
>
> But I think it is simpler to model namespace protection and state
> protection as being two results of a single kind of lock, as opposed
> to the result of two different kinds of locks.  This avoids the
> problem of describing how namespace locks and state locks interact.
>
> In an attempt to make the proposal both understandable and complete,
> I've broken it into two parts.  The first part is a series of bullets,
> which largely correspond to the "URL-based locking" proposal I mailed out
> a while ago.  The second part is the same series of bullets fleshed out
> with a more formal description of each bullet in terms of an underlying
> resource model and effects on the visible lock state of resources.
>
> **************************
>
> GULP: Part I
>
> - A URL identifies a resource.
> - A LOCK request creates a lock on the request URL.
> - An UNLOCK request removes all locks with the specified lock token.
> - A lock on a URL protects which resource is identified by that URL.
> - A Depth:N lock on a URL locks any URL that extends the locked URL by no
> more than N segments.
> - A Depth:infinity lock on a URL locks all URL's that extend the
> locked URL.
> - If an exclusive lock identifies a resource, no other lock of
> that type can
> identify that resource.
> - A write-lock on a URL protects the body and dead properties of any
> resource identified by that URL.
>
> **************************
>
> GULP: Part II
>
> - A URL identifies a resource.
>
> The URL "/" identifies a resource. A collection contains a set of
> bindings,
> where a binding is a mapping from a URL segment to a resource. If "/path"
> identifies a collection C, and C contains a binding that maps the segment
> "x" to resource R, then the URL "/path/x" identifies resource R.
>
> - A lock is on a URL. Every lock has a lock token and a lock owner.
>
> Every lock on a resource has a name which is a relative URL (i.e. a slash
> separated sequence of URL segments). Every LOCK request that succeeds
> results in a new globally unique lock token. Every lock token has an owner
> that is the principal of the LOCK request.
>
> - A LOCK request creates a lock on the request URL.
>
> When a request of the form "LOCK /pathX" succeeds, a lock named "pathY/."
> with a new lock token is added to the resource identified by "/", where
> "pathY" is the result of applying standard URL path transformations to
> remove all segments named "." or ".." from "pathX". If a
> collection C has a
> binding from "segX" to resource R, and a request adds a lock named
> "segX/pathZ" with token "L" to C, then the request adds a lock
> named "pathZ"
> with token "L" to R. Similarly, if a collection C has a lock named
> "segX/pathZ" with token "L", and a request (e.g. PUT, COPY, MOVE,
> BIND) adds
> a binding in C from "segX" to resource R, then the request adds a
> lock named
> "pathZ" with token "L" to R. If the attempt to add the lock named
> "pathZ" to
> R fails, the request MUST fail.
>
> - An UNLOCK request removes all locks with the specified lock token.
>
> When a request of the form "UNLOCK /pathX; Lock-Token L"
> succeeds, then the
> lock with token "L" is removed from the resource identified by "/". If a
> collection C has a binding from "segX" to resource R, and a
> request removes
> a lock named "segX/pathZ" with token "L" from C, then the request
> removes a
> lock named "pathZ" with token "L" from R. Similarly, if a collection has a
> lock named "segX/pathZ" with token "L", and a request (e.g. DELETE, MOVE)
> removes a binding in C from "segX" to resource R, then a lock
> named "pathZ"
> with token "L" is removed from R.
>
> - A lock on a URL protects which resource is identified by that URL.
>
> If a collection identified by the URL "/colX" contains a lock
> named "pathZ"
> with token "L", if a request would change the resource identified by
> "/colX/pathZ", the request MUST specify token "L" in an IF header and the
> request principal MUST be the owner of token "L".
>
> - A Depth:N lock on a URL locks any URL that extends the locked URL by no
> more than N segments.
>
> If a collection C has a binding to resource R, and a request adds
> a Depth:N
> lock named "." with token "L" to C, then the request adds a Depth:N-1 lock
> named "." with token "L" to R. Similarly, if a collection C has a Depth:N
> lock named "." with token "L", and a request adds a binding in C
> to resource
> R, then the request adds a Depth:N-1 lock named "." with token
> "L" to R. If
> the attempt to add the lock named "." to R fails, the request MUST fail.
> Conversely, the Depth:N-1 lock is removed from R whenever a
> binding to R or
> the Depth:N lock is removed from C.
>
> - A Depth:infinity lock on a URL locks all URL's that extend the
> locked URL.
>
> If a collection C has a binding to resource R, and a request adds a
> Depth:infinity lock named "." with token "L" to C, and this is the first
> Depth:infinity lock named "." with token "L" on C, then the request adds a
> Depth:infinity lock named "." with token "L" to R. Similarly, if a
> collection C has a Depth:infinity lock named "." with token "L", and a
> request adds a binding in C to resource R, then the request adds a
> Depth:infinity lock named "." with token "L" to R. If the attempt
> to add the
> lock named "." to R fails, the request MUST fail. If a collection C has a
> binding to resource R, and a request removes the last Depth:infinity lock
> named "." with token "L" from C, then the request removes a Depth:infinity
> lock named "." with token "L" from R. Similarly, if a collection has a
> Depth:infinity lock named "." with token "L", and a request removes a
> binding in C to resource R, then a Depth:infinity lock named "."
> with token
> "L" is removed from R. Note that multiple Depth:infinity locks named "."
> with the same token can be placed on the same resource due to multiple
> bindings to that resource in a Depth:infinity locked collection.
>
> - If an exclusive lock identifies a resource, no other lock of
> that type can
> identify that resource.
>
> If a request attempts to add a lock named "pathZ" with token "L"
> and type T
> to resource R, and R already has an exclusive lock named "pathZ" with type
> "L" but with a different token, the request MUST fail. Similarly, if a
> request attempts to add an exclusive lock named "pathZ" with token "L" and
> type T to resource R, and R already has a lock named "pathZ" with
> type T but
> with a different token, the request MUST fail.
>
> - A write-lock on a URL protects the body and dead properties of any
> resource identified by that URL.
>
> If a resource has a write lock named "." with token "L", in order
> to modify
> the body or dead properties of that resource, a request MUST specify token
> "L" in an IF header and the request principal must be the principal that
> created the lock.
>
> **************************
>
> OK, Jason, Yaron, Eric, et. al, what did I forget this time? (:-)
>
> Cheers,
> Geoff
>

Received on Thursday, 13 January 2000 20:06:57 UTC