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

This is clearly a very important topic - Julian points out he thinks it is
one of the few where if we can't solve it, we should not publish an update.
Let me break it apart into a few different issues - I think we agree on most
of them and the others we might agree but I don't understand well enough to
be sure we do. So let me try and split these up and ask some questions to
help figure out how to either know we do agree or get to agreement.

In any system that supports locking, it is always a complex issues with many
tradeoffs. One topic is should we have a section in this document that
introduces the concepts, defines any terminology, explains the model,
explains way it works, and points out any gotchas that implementers may not
think of and should be aware of. I think we all agree having this in bis is
a *good* idea. 

>From this point, I think we get to two different areas. 1) what type of
locks to do we want 2) give agreement on how locks work, how do we want to
specify them. Let me discuss #2 first.

We have the question is if the level of text in the GULP provides enough
information to for interoperable implementations. I have never argued that a
specification should tell people how they have to implement something but it
should be written in such a way that is implementable. From reading GULP, is
it clear how you might implement it? Is it clear that there is a polynomial
time algorithm to implement locking? We could specify locks in many
different ways - one would be to describe the invariants of they system with
regards to the locks. This is basically the approach GULP takes. The other
would be to provide certain algorithmic rules that results in the same set
of invariants. This is the approach most specifications take. Both have
their place and useful. Now, we could normatively use algorithm and still
provide the GULP style description of the invariants. On the conference
call, I felt this was what people wanted. Did I totally miss this? Thoughts?
It is hard to call consensus on this because it is hard for people to
express their opinion until they see some text but unless I hear otherwise,
I will assume this is the path we are somewhat proceeding down towards
coming up with some text ask for consensus on.

Back to the first issue of what type of LOCKs are we building. This is by
far the more important issue. GULP provides one possible answer to this but
I'm not sure we have agreement on that. I will now refer to the PUT and
DELETE example that Julian put out earlier in this thread. My read of the
email is that we *do* agree on how the PUT would work. I'm not sure we agree
on how the DELETE should work. We might agree but I can't tell.  Let's
assume we are working on a server that does not support bind. I'm not clear
how DELETE works. If /foo/a and /foo/b both point at the same resource, and
/foo/b is deleted, is there a guarantee that the resource will not be
deleted and that /foo/a will still point at the resource? Does the spec
allow the server to choose a model and some might allow it and some might
not? If so, do we need to allow the server to be able to select a locking
model that follows this? There seems to be questions around depth and depth
infinity, do we agree on these.


These are probably the wrong questions but what I am trying to do is
separate this into two parts. 1 is how locks work, 2 is how we specify them
in bis. On the topic of how it works, does anyone care to help me frame the
really key question to decide how it works?






On 12/13/05 1:15 AM, "Julian Reschke" <julian.reschke@gmx.de> 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>
>> 
>> 
>

Received on Tuesday, 13 December 2005 23:32:37 UTC