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

I agree that the locking semantics outlined for (2) are correct.

I also agree that it is essential that there be a single 
place in the doc which provides a comprehensive 
normative description of locking semantics (similar, but
not necessarily identical to GULP) that provides an answer
to questions such as (2).

Cheers,
Geoff

Julian wrote on 12/08/2005 09:46:06 AM:
> 
> 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>
>