W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > October to December 2005

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

From: Geoffrey M Clemm <geoffrey.clemm@us.ibm.com>
Date: Thu, 8 Dec 2005 11:23:54 -0500
To: " webdav" <w3c-dist-auth@w3.org>
Message-ID: <OF812C54E3.EBDB621A-ON852570D1.0059256C-852570D1.005A14E6@us.ibm.com>
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).


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] 
> [2] <http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=54>
Received on Thursday, 8 December 2005 16:45:43 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:01:34 UTC