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

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