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

Why wouldn't it hold for UNBIND -- or for DELETE implemented as UNBIND 
which I agree is a good thing?

How does my proposed rule affect PROPFIND at all?  I suggested that 
methods behave the same *with respect to requiring lock tokens*, thus 
the proposal is about the lock model, not about property models.

lisa

On Dec 14, 2005, at 2:06 PM, Geoffrey M Clemm wrote:

>
> Note that we have discussed at great length on this mailing
> list as to whether all live properties must have the same value
> for all URL's that map to a given resource, and have concluded
> that they do not, therefore Lisa's proposed rule minimally
> does not apply to PROPFIND.
>
> It also does not apply to UNBIND and REBIND.
>
> And unless you want to argue against the previous consensus
> that a server is allowed to implement DELETE as UNBIND
> (if it so wishes), this also means that Lisa's proposed rule
> does not hold for DELETE.
>
> So I would conclude that this proposed rule would not be
> a valid basis for disagreeing with the GULP model, since
> the proposed rule does not hold for a variety of methods.
>
> Cheers,
> Geoff
>
> Lisa wrote on 12/13/2005 12:49:05 PM:
>
>  >
>  > Well, I disagree with that model.  I propose that all methods work 
> the  
>  > same on all bindings to a resource with respect to requiring the 
> lock  
>  > token, including DELETE.
>  >
>  > Lisa
>  >
>  > On Dec 13, 2005, at 1:15 AM, Julian Reschke wrote:
>  >
>  > >
>  > > 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
>  > >
>  >
>  >