RE: Is this LOCK model correct?

Bits snipped, all IMHO. As usual, corrections please.

> -----Original Message-----
> From: Alan Kent [mailto:ajk@mds.rmit.edu.au]
> Sent: 21 June 2001 06:43
> To: w3c-dist-auth@w3.org
> Subject: Is this LOCK model correct?
> 
> WebDAV talks about moving a resource under one locked 
> collection to under
> another locked collection, and the old lock being lost and 
> the new lock
> being gained. I am trying to get the semantic model in my head right.
> Comments on my model below would be appreciated.
> 
> I am trying to work out if you do a LOCK with depth infinity, what is
> actually locked. Are the resources locked, or the URI's to 
> the resources?

I think the lock applies to the URIs and any descendant of it.

Imperfect example is a file system implementation. Infinite depth lock is
applied to a directory and all its descendants (sub directories and files).
Oh and of course, as HTTP/WebDAV are "root directory" based, a request with
infinite depth lock on root (if permitted) would lock the entire server. Yes
this does have uses, e.g. an administrator wants to perform a backup but
nobody can make changes in the meantime.

RFC2518 sec 8.10.3 states that "locks apply to resources, not URIs" and
"LOCK request on a resource MUST NOT succeed if can not be honored by all
the URIs through which the resource is addressable."

If you think about it, the first statement makes sense when you consider the
second statement.

However, I think the server applies locks to resources, but our
visualisation is that locks apply to URIs.

> Since some of the lock description is URI based, and other 
> says resources
> are locked, I have come to the following model of locking. 
> Please correct
> me if its wrong:
> 
> - Locks are based on URIs.

See above.

> 
> - A depth 0 lock puts a lock on that URI only.

Depends on what you mean. A resource can have one or more URIs mapped to it
(RFC 2518 sec 5.1). The resource would be locked and thus all the URIs that
map to it. So no matter what URI (that was mapped to the resource) that was
used by the client, the resource would appear to be locked as far as the
client is concerned. However, none of the descendants would be locked.

> 
> - A depth infinity lock identifies the leading path of a URI 
> - any URI with
>   additional path components is covered by the lock as well.

Correct, although you might want to word it a little different -
"descendants" is probably better.

> 
> - To check if a resource is locked, *all* of the URIs to the resource
>   (if multiple bindings exist) must be checked against the locks that
>   currently exist.

As stated above, a resource MUST NOT be locked if the lock cannot be honored
by all the URIs which address it. You shouldn't have an occurrence where a
resource is locked, but using a URI that maps to it indicates the resource
isn't lock. So in *theory*, you shouldn't have to check all the URIs because
any of the URIs (that map to the locked resource) can be used to discover
that the resource is indeed locked.

> 
> In my understanding, locks are not really associated directly with
> resources because moving things to different URIs does not keep the
> lock. So the lock is not independent of the URI - hence locks are
> really best thought of as attached to URIs. Resources are locked
> if any of the URIs to the resource is locked.
> 
> Alan
> 

Of course, its all a lot simpler if your server only supports one URI per
resource. It makes the understanding of locking a lot easier :-)

Regards

Shaun Hall
Xerox Europe

Received on Friday, 22 June 2001 05:04:03 UTC