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

I mentioned PROPFIND just to make the point that this rule
doesn't hold in general, so there is no apriori requirement
that it hold for locking and lock tokens.

Cheers,
Geoff


Lisa Dusseault <lisa@osafoundation.org> wrote on 12/14/2005 05:10:48 PM:

> 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
> >  > >
> >  >
> >  >