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

OK,

this is really an important issue RFC2518bis has to solve (I'd say, if 
we can't resolve it, we shouldn't publish a revision at all).

So far I've seen two people agreeing that the semantics described by 
GULP for this situation are indeed correct/desirable, and nobody 
speaking against. I also note that this is what our server implements 
(running code!), and nobody has so far made a proposal to define lock 
semantics differently (not on a case-by-case basis, but with a 
explanation spanning all methods/situations).

So any additional feedback would be highly appreciated.

Best regards, Julian


Julian Reschke wrote:
> 
> 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>
> 
> 


-- 
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760

Received on Tuesday, 13 December 2005 09:16:40 UTC