GULP vs RFC251bis, was: [Bug 54] Locks vs multiple bindings

Hi.

yesterday's conference call resulted in kind of interesting
news on this issues.

As far as I can tell, the current authors of the draft for RFC2518bis 
took the position that the text called GULP - the Grand Unified Locking 
Proposal (see for instance [1]) - doesn't need to be incorporated into 
RFC2518bis because all it says is already covered over there.

When we discussed BugZilla issue 54 [2], we discovered that there's 
indeed disagreement on locking semantics, and that we need to resolve 
that one way or another.

So what we ended up are two separate questions, which are:

(1) Should there be a single (normative) place in the doc which provides 
a high-level overview of locking, similar but not necessarily identical 
with GULP?

As far as I can tell, the attendees of the conference call concluded 
that yes, we want that.

(2) What are the semantics for a lock on a resource having multiple 
bindings (issue 54)? Consider:

- A resource Z identified by URLs /foo/a and /foo/b.

- Z gets locked by a LOCK request on /foo/a.

In this situation, is a lock token required to DELETE /foo/b? GULP's 
answer to that one is that you don't need the lock token. Removing the 
URI /foo/b does not affect the state of resource Z, nor does it affect 
any URL that is protected by that lock (/foo/a and /foo/). A lock token 
would need to be provided if the resource /foo itself would be locked, 
but it isn't.

On the other hand, a PUT or a PROPPATCH applied to /foo/b will require 
the lock token because it affects the state of resource Z. This may be 
confusing, but follows from the fact that the URI of a resource is not 
part of it's lockable state. My assumption is that any other attempt to 
define this would be even more confusing.


Feedback appreciated,

Julian


[1] <http://lists.w3.org/Archives/Public/w3c-dist-auth/2005OctDec/1003.html>

[2] <http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=54>

Received on Thursday, 8 December 2005 14:47:57 UTC