Subject: [Bug 54] Locks vs multiple bindings

From: [email-masked]
Date: Wed, 7 Dec 2005 11:26:53 -0800

http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=54

[email-masked] changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         [email-masked]    [email-masked]
             Status|ASSIGNED                    |NEW

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

---

From: Julian Reschke <[email-masked]>
Date: Thu, 08 Dec 2005 15:46:06 +0100

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>

---

From: Geoffrey M Clemm <[email-masked]>
Date: Thu, 8 Dec 2005 11:23:54 -0500

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

Cheers,
Geoff

> [1] 
<http://lists.w3.org/Archives/Public/w3c-dist-auth/2005OctDec/1003.html>

---

From: Julian Reschke <[email-masked]>
Date: Tue, 13 Dec 2005 10:15:01 +0100

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

-- 
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760

---

From: Cullen Jennings <[email-masked]>
Date: Tue, 13 Dec 2005 15:32:34 -0800

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?

---

From: Julian Reschke <[email-masked]>
Date: Wed, 14 Dec 2005 03:53:58 +0100

> one of the few where if we can't solve it, we should not publish an update.

That was probably a bit radical, but locking clarifications certainly 
*are* what people expect from us.

> ...

GULP wasn't around when we implemented locking, but as far I can tell, 
it closely describes the model we actually did implement after reading 
the spec, reading the rationals (Yaron's WebDAV Book of Why, 
<http://www.webdav.org/papers/> and having lots of conversations over 
here (which eventually resulted in people writing GULP down).

> call, I felt this was what people wanted. Did I totally miss this? Thoughts?

I have no strong feelings about this, as long as the result is as 
precise as what we have today with GULP. If there's a different approach 
to that which could work, I'm interested to see it.

> email is that we *do* agree on how the PUT would work. I'm not sure we agree

Yes, that's because PUT affects the "lockable" state of the resource 
(something we at some point need to define, and which RFC2518bis 
currently doesn't).

> deleted and that /foo/a will still point at the resource? Does the spec

No, there's no guarantee for that. Indeed this is the containment model 
RFC2518 *required* people to implement, and which we got rid of.

> not? If so, do we need to allow the server to be able to select a locking

That's my understanding. RFC2518bis allows servers to vary, while BIND 
requires specific semantics (where destroying the resource and removing 
URL mappings to the resource in general are separate tasks).

> infinity, do we agree on these.

I think GULP works just fine.

If you do have an hypothetical server that upon DELETEing /foo/b also 
destroys the resource mapped to, and all other bindings to it, then yes, 
  you'll need the lock token even though the resource was only locked 
through /foo/a. The difference here is not in the locking model (it's 
the same), but in the implemented semantics of DELETE.

As a matter of fact, the same question could be asked regarding access 
permissions on the container collections. If you do have /foo1/a and 
/foo2/a mapped to the same resource, do yo need DAV:unbind privileges 
for both if you DELETE /foo1/a? The answer depends on what your server 
is doing upon DELETE.

> really key question to decide how it works?

I think the best starting point is indeed GULP, and to let people raise 
potential problems they see with that model.

Best regards, Julian

---

From: Geoffrey M Clemm <[email-masked]>
Date: Tue, 13 Dec 2005 22:45:42 -0500

> > ... On the topic of how it works, does anyone care to help me frame 
the
> potential problems they see with that model.

I agree.

Cheers,
Geoff

---

From: Cullen Jennings <[email-masked]>
Date: Tue, 13 Dec 2005 21:07:24 -0800

Ok, I'll wait a bit and see if others provide comments on any of this, but
given what you are saying here, I think I can imagine how to propose a way
of including GULP that meets various folks needs.

---

From: Lisa Dusseault <[email-masked]>
Date: Tue, 13 Dec 2005 09:49:05 -0800

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:

>> 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.
>> (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?
>> 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]

---

From: Julian Reschke <[email-masked]>
Date: Wed, 14 Dec 2005 21:55:04 +0100

> same on all bindings to a resource with respect to requiring the lock 

Hm. Trying to clarify...: are you also opposed to distinguish between 
resources being locked and URLs being protected? Or is this terminology 
you agree with that we can use in our discussions?

Best regards, Julian

---

From: Lisa Dusseault <[email-masked]>
Date: Wed, 14 Dec 2005 13:05:47 -0800

Good question, and I'm not sure -- it depends what the consequences are 
of assuming this distinction.  It seemed like a useful distinction 
until it led to what, to me, were unexpected or undesired consequences.

Do any servers implement multiple URLs, locking and DELETE (regardless 
of whether they support the exact model of BIND)?   If so, what do 
existing implementations do?

lisa

On Dec 14, 2005, at 12:55 PM, Julian Reschke wrote:

> Lisa Dusseault wrote:
>> 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.
>
> resources being locked and URLs being protected? Or is this 
> terminology you agree with that we can use in our discussions?
>
> Best regards, Julian
>

---

From: Julian Reschke <[email-masked]>
Date: Wed, 14 Dec 2005 22:15:31 +0100

Lisa Dusseault wrote:
> of assuming this distinction.  It seemed like a useful distinction until 
> it led to what, to me, were unexpected or undesired consequences.

Well. If not using this term, how do you distinguish between the 
resources that are actually locked, and the URLs that are protected? So 
for instance, with a

/a/b

being lcoked (through a LOCK request on /a/b), how do you describe the 
fact that the URL is protected by the lock (that is, you'll need a 
lock-token to MOVE /a itself)?

> existing implementations do?

Yes, we do, and of course we implement the model we discuss.

Best regards, Julian

---

From: Lisa Dusseault <[email-masked]>
Date: Wed, 14 Dec 2005 13:24:48 -0800

One could imagine the lock applying to the resource and to all its 
bindings, considering  the bindings to be part of the state of the 
resource.  If I recall, I think this is the model I'd always assumed 
until GULP.  With this model, if A and B are bindings to a resource, 
and a LOCK token to A is successful, then for the duration of the lock 
the token is required to change either A or B.

In today's server implementations, does a LOCK of depth 0 on a 
collection prevent MOVE from being used to change resource names inside 
the collection?  This is another possible case that might be different 
depending on whether bindings were considered part of the collection, 
part of the resource state, or both.

Lisa

On Dec 14, 2005, at 1:15 PM, Julian Reschke wrote:

> Lisa Dusseault wrote:
>> Good question, and I'm not sure -- it depends what the consequences 
>> are of assuming this distinction.  It seemed like a useful 
>> distinction until it led to what, to me, were unexpected or undesired 
>> consequences.
>
> resources that are actually locked, and the URLs that are protected? 
> So for instance, with a
>
> /a/b
>
>> Do any servers implement multiple URLs, locking and DELETE 
>> (regardless of whether they support the exact model of BIND)?   If 
>> so, what do existing implementations do?
>

---

From: Geoffrey M Clemm <[email-masked]>
Date: Wed, 14 Dec 2005 17:06:06 -0500

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

---

From: Lisa Dusseault <[email-masked]>
Date: Wed, 14 Dec 2005 14:10:48 -0800

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

---

From: Julian Reschke <[email-masked]>
Date: Wed, 14 Dec 2005 23:17:57 +0100

> resource.  If I recall, I think this is the model I'd always assumed 

Well, I'm not aware of a single server that supports multiple bindings 
to one resource, but which considers bindings as part of the state of 
the resource. Do you?

I also note that this point of view is incompatible to the model used in 
RFC3744, where you need a DAV:unbind privilege on the parent collection 
to remove a binding 
(<http://greenbytes.de/tech/webdav/rfc3744.html#rfc.section.B>).

> until GULP.  With this model, if A and B are bindings to a resource, and 
> a LOCK token to A is successful, then for the duration of the lock the 
> token is required to change either A or B.

Are you aware of a single implementation working that way?

> part of the resource state, or both.

I'll claim that all servers that implement depth 0 locks on collections 
work that way, and that RFC2518 requires them do work that way 
(<http://greenbytes.de/tech/webdav/rfc2518.html#rfc.section.7.5>):

"A write lock on a collection, whether created by a "Depth: 0" or 
"Depth: infinity" lock request, prevents the addition or removal of 
member URIs of the collection by non-lock owners. As a consequence, when 
a principal issues a PUT or POST request to create a new resource under 
a URI which needs to be an internal member of a write locked collection 
to maintain HTTP namespace consistency, or issues a DELETE to remove a 
resource which has a URI which is an existing internal member URI of a 
write locked collection, this request MUST fail if the principal does 
not have a write lock on the collection."

Again, if you have evidence of servers working differently, please 
provide it.

Best regards, Julian

---

From: Geoffrey M Clemm <[email-masked]>
Date: Wed, 14 Dec 2005 18:01:06 -0500

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 <[email-masked]> wrote on 12/14/2005 05:10:48 PM:

> >  > > So far I've seen two people agreeing that the semantics described 

> > by  

 
> >  > >> the URI /foo/b does not affect the state of resource Z, nor does 

> > it  

> >  > >> This may be confusing, but follows from the fact that the URI of 

> > a

---

From: Cullen Jennings <[email-masked]>
Date: Wed, 14 Dec 2005 16:20:12 -0800

> to one resource, but which considers bindings as part of the state of

I was just sort of thinking, if one implemented a server using a XML
database, and one used the database locks to implement the DAV LOCK, it
seems like you would end up with the lock locking the resource not the URI.
Perhaps that would just not be a legal way to implement it. I'm not making
an argument one way or another, I was just sort of pondering this and
wondering if my assumption that using the database lock to implement LOCK
would result in this model.

---

From: Elias Sinderson <[email-masked]>
Date: Wed, 14 Dec 2005 16:54:44 -0800

Julian Reschke wrote:

>> 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
> I think the best starting point is indeed GULP, and to let people 
> raise potential problems they see with that model. 

In the absence of any other proposed text, I tend to agree with this 
approach -- at the very least it is a good starting point for further 
discussion.

Due to the editorial overhead, I am opposed to moving all of the 
normative text on locking into one place, however desireable that may be 
otherwise. As such, I'm not averse to having normative text appear in 
the to-be-added discussion of the locking model that WebDAV employs.

Best,
Elias

---

From: Geoffrey M Clemm <[email-masked]>
Date: Wed, 14 Dec 2005 21:33:40 -0500

I'm not aware of XML providing a mechanism for defining multiple bindings
to the same resource, so I don't see how an XML database implementation
bears on this discussion.

Cheers,
Geoff

---

From: Cullen Jennings <[email-masked]>
Date: Wed, 14 Dec 2005 20:17:04 -0800

Perhaps you could explain how one gets multiple bindings when not using an
XML database?

---

From: Julian Reschke <[email-masked]>
Date: Thu, 15 Dec 2005 10:01:37 +0100

> seems like you would end up with the lock locking the resource not the URI.

If an implementor would expose database locks directly as WebDAV locks, 
then this would probably the case. However, that wouldn't be compliant 
to RFC2518.

Best regards, Julian

---

From: Julian Reschke <[email-masked]>
Date: Thu, 15 Dec 2005 10:04:15 +0100

Cullen Jennings wrote:
> 
> Perhaps you could explain how one gets multiple bindings when not using 
> an XML database?

As Geoff, I really don't see what this would have to do with an XML 
database.

You can get multiple bindings if

- you support BIND and/or
- if your underlying store supports something similar, such as a 
filesystem supporting hard links

Best regards, Julian

---

From: Julian Reschke <[email-masked]>
Date: Thu, 15 Dec 2005 16:14:20 +0100

Julian Reschke wrote:
>> collection prevent MOVE from being used to change resource names 
>> inside the collection?  This is another possible case that might be 
>> different depending on whether bindings were considered part of the 
>> collection, part of the resource state, or both.
> 

For the record, I just tested with all servers that do support 
collection locks (SAP Netweaver, Apache/moddav, Xythos), and all of them 
require the lock token when moving things inside a locked collection 
(test case attached).

So unless there's any new evidence, it would be nice if we could stop 
arguing about this topic...

Best regards, Julian

---

From: Julian Reschke <[email-masked]>
Date: Fri, 16 Dec 2005 20:42:13 +0100

During today's teleconference, we came across another disagreement, 
where it was questioned that GULP's [1] statement about URLs being 
protected by a LOCK:

" - If a request causes a directly locked resource to no longer be
     mapped to the lock-root of that lock, then the request MUST
     fail unless the lock-token for that lock is submitted in the
     request.  If the request succeeds, then that lock MUST have been
     deleted by that request."

indeed reflects what servers do.

I just tested a MOVE on a collection containing one locked child 
resource, and 4 out of 4 tested servers (Xythos, Apache, MS IIS 5.1, SAP 
KM) rejected the request. All except IIS returned a 423 (IIS returned a 
207 with a 423 status contained).

Thus I'll conclude that GULP here indeed describes what servers do (test 
case attached).

We can probably go on like this for a long time, but at this point I 
don't see any way to make progress here unless those who dislike GULP 
come up with concrete examples of where it fails to describe running 
code, and then optimally make suggestions about how to fix this.

Best regards, Julian

---

From: Geoffrey M Clemm <[email-masked]>
Date: Fri, 16 Dec 2005 21:38:07 -0500

+1 for Julian's suggestion about how to make progress.

In particular, I suggest we provide some kind of deadline for
identifying such instances of where GULP incorrectly describes
current locking behavior of the majority of current implementations.
If no such instances are identified I suggest we just adopt
the GULP text as currently written, so that we can close down
this thread and make progress on the remaining other issues.

Cheers,
Geoff

> [attachment "url_protection.js" deleted by Geoffrey M 
Clemm/Lexington/IBM]

---

From: Cullen Jennings <[email-masked]>
Date: Mon, 19 Dec 2005 21:30:12 -0800

> filesystem supporting hard links

Right, no big deal but it seems like a XML database that say had a regular
expression for mapping one URI to another could easily get multiple bindings
to one resource. 

The questions was could you use the DB lock mechanism (or for that matter a
files system lock) to implement DAV locks. Julian said this would not be
compliant with 2516 which I believe but I don't yet understand why it would
not be. 

Now Lisa proposed a model for locking slightly different than GULP which
would, by my understanding, would allow an implementation like GULP but
would also allow implementation like the one I just described to also be
compliant. For a server that supported BIND, it would probably have to be a
GULP like implementation.

Now I have no idea what is best, but I am poking at the form of the
argument. You are arguing the 4 servers tested are compliant with GULP
therefore do GULP. However the 4 servers, by my understanding (happy to be
corrected if I am wrong here), also are compliant with what Lisa proposed
given GULP is a subset of it.

I strongly suspect that there are some DAV like servers out there that try
to use file and data base locking mechanism to do locks - I don't know if
they are 2516 compliant or not. I also suspect there are some servers that
do run regular expression on URL to create multiple bindings to files on a
file system and DELETE will remove both all at the same time. Again, don't
know if this should be legal for a server or not but practically it does not
make much difference for the client so servers will continue to do it.

I like the idea of looking at what is running code today to determine how to
move forward. (I won't ask about if those 4 servers you tested can store gif
files or not :-) 

I'd like to see this discussion have more on what the model should and and
why. So far I can summarize it as:
1) gulp would probably work
2) an alternative model might work
3) some people prefer 1 some 2
4) I've learned a bunch about weak and strong tags and PUT in HTTP - this is
good
5) I'm not seeing the insights that help people understand why one model or
another would be better or worse.

I really like the posts Dan and Jim where having on the meaning and
implications of etags on PUT. I could read it and understand why one might
want or not want various options.

---

From: Julian Reschke <[email-masked]>
Date: Tue, 20 Dec 2005 10:06:52 +0100

> compliant with 2516 which I believe but I don't yet understand why it would

If the server would use just the DB lock (on the resource), and nothing 
else, it wouldn't be compliant to several URL related locking 
requirements, namely that you can't MOVE a parent without providing the 
lock token (thus the URL of the locked resource is protected from 
getting changed), and the lock to disappear when the resource itself is 
moved. Both of these require the server to store the URL to what the 
lock request was sent with the lock.

> GULP like implementation.

I'll assume you're referring to 
<http://lists.w3.org/Archives/Public/w3c-dist-auth/2005OctDec/1282.html>?

Which reads:

LD> One could imagine the lock applying to the resource and to all its
LD> bindings, considering  the bindings to be part of the state of the
LD> resource.  If I recall, I think this is the model I'd always assumed
LD> until GULP.  With this model, if A and B are bindings to a resource,
LD> and a LOCK token to A is successful, then for the duration of the lock
LD> the token is required to change either A or B.

This implies that a binding is part of the state of the resource, and I 
think both RFC2518 and RFC3744 are very clear that it's not. Namely, in 
<http://greenbytes.de/tech/webdav/rfc2518.html#rfc.section.7.5>:

'A write lock on a collection, whether created by a "Depth: 0" or 
"Depth: infinity" lock request, prevents the addition or removal of 
member URIs of the collection by non-lock owners.'

So this is clearly different from what RFC2518 says, so it's not a 
proposed model, but a change request.

LD> In today's server implementations, does a LOCK of depth 0 on a
LD> collection prevent MOVE from being used to change resource names inside
LD> the collection?  This is another possible case that might be different
LD> depending on whether bindings were considered part of the collection,
LD> part of the resource state, or both.

Checked and confirmed that servers indeed implement RFC2518 as written. 
I'm not sure why we're still arguing this.

> given GULP is a subset of it.

GULP not only describes the locking model in RFC2518, it's also 
implemented. Lisa's proposal describes something else. It's as simple as 
that.

> they are 2516 compliant or not. I also suspect there are some servers that

They aren't, unless they keep the locked URL somewhere as well (of 
course they won't need to do that if there's only one, but then cnecking 
it on every namespace operation may get expensive).

> move forward. (I won't ask about if those 4 servers you tested can store gif

At least one of them may not be able to do so for some URLs.

> another would be better or worse.

So far, I haven't seen a model other than GULP that indeed describes 
what RFC2518 says and what servers implement. Making a binding part of 
the state of the resource instead of the collection containing it is a 
non-starter, sorry.

Best regards, Julian

---

From: Geoffrey M Clemm <[email-masked]>
Date: Tue, 20 Dec 2005 08:41:09 -0500

Cullen wrote on 12/20/2005 12:30:12 AM:

> ... it seems like a XML database that say had a regular

No, the semantics of a binding is defined to be a relationship to the 
bound
resource that is independent of other bindings to that bound resource.
If you tried to implement a binding, B, with a URI mapping, any change to 
any
of the bindings that define that URI mapping would disrupt the binding B.

The best you can get with a URI mapping implementation is an 
"auto-redirect"
functionality, which is not something defined by any current WebDAV spec
(several years ago, there was a "WebDAV Reference" spec that some folks 
were working
on for this, but that got dropped for lack of interest).

> compliant with 2518 which I believe but I don't yet understand why it 
would
> not be. 

WebDAV locks require that lock request URI be "protected", in addition to 
the resource
being "locked".  DB locks do not "protect" the lock request URI.

> compliant. 

I am not aware of any locking model being proposed by Lisa.
There was the posting about whether the DELETE method should be required
(or at least allowed) to delete all bindings to the resource being
deleted (rather than just the one binding identified by the DELETE
request-URL), but that was a discussion about the semantics of DELETE,
not about a different locking model.

> they are 2518 compliant or not. 

I'm not sure what point you are making here ... a server can chose to not
be compliant with the spec, and how that will harm interoperability will 
depend on what areas they are not compliant and what functionality is
assumed/needed by the client.

> I also suspect there are some servers that
> file system and DELETE will remove both all at the same time. 

Those wouldn't be bindings, as defined by the BIND specification.

> Again, don't

As you say, a server can do whatever it wants, but it does make a 
difference
to a client if the server claims they are bindings (say, by declaring 
support
for BIND/UNBIND/REBIND), which it doesn't.

> another would be better or worse.

I believe that is because there is no alternative model that has been 
proposed. 

Cheers,
Geoff

---

From: Lisa Dusseault <[email-masked]>
Date: Tue, 20 Dec 2005 10:12:18 -0800

On Dec 20, 2005, at 1:06 AM, Julian Reschke wrote:

> This implies that a binding is part of the state of the resource, and  
> I think both RFC2518 and RFC3744 are very clear that it's not. Namely,  
> in <http://greenbytes.de/tech/webdav/rfc2518.html#rfc.section.7.5>:

No, that's not a correct conclusion.  This model only implies that all  
bindings are covered by the LOCK as well as the resource itself.  The  
resource state is still the resource state and that doesn't include  
*any* bindings.

It's actually very similar to the model proposed in GULP.  In that  
model, the LOCK covers one binding as well as the resource.  The GULP  
model does not imply that the locked binding is part of the state of  
the resource either.  What a lock covers is a separate concept from  
what a resource state includes.

Lisa

---

From: Julian Reschke <[email-masked]>
Date: Tue, 20 Dec 2005 19:50:32 +0100

> resource state is still the resource state and that doesn't include 

Well, it's what you said. Quoting again:

> model does not imply that the locked binding is part of the state of the 
> resource either.  What a lock covers is a separate concept from what a 
> resource state includes.

Well, it's not completely separate because if affects how Depth 0 locks 
in collections behave.

Anyway, I don't think we'll make any progress unless you tell us exactly 
which part of GULP you're unhappy with, and how you propose to change it.

Best regards, Julian

---

From: Lisa Dusseault <[email-masked]>
Date: Tue, 20 Dec 2005 11:09:20 -0800

>> what a resource state includes.

You're right, I used language in a sloppy way in describing the model.  
Anyway, to update my language, I don't see why the model for a LOCK 
can't cover more than only the binding that was locked and the resource 
(and its state) itself.  We should be picking a model that results in 
desirable behaviors.

>
> Well, it's not completely separate because if affects how Depth 0 
> locks in collections behave.
>
> Anyway, I don't think we'll make any progress unless you tell us 
> exactly which part of GULP you're unhappy with, and how you propose to 
> change it.

I'm unhappy with the consequence of the GULP model that a DELETE of a 
binding to a locked resource may or may not work depending on whether 
that binding was the one locked.  I propose to change it by requiring 
that a DELETE of a binding to a locked resource needs a lock token.

Lisa

---

From: Julian Reschke <[email-masked]>
Date: Tue, 20 Dec 2005 20:23:50 +0100

> (and its state) itself.  We should be picking a model that results in 

Yes, that's possible.

> that a DELETE of a binding to a locked resource needs a lock token.

I still don't see concrete text, but anyway...

1) The cost of locking a resource with multiple bindings will be 
significantly higher.

2) I don't see any gain to a client. The purpose of a lock is that while 
the resource is locked the client is protected from others moving away 
the resource, or modifying it's lockable state. Just protecting the 
binding that was locked achieves exactly that.

3) Multiple bindings to a resource cause the server behaviour to become 
more complex, yes. But the change you suggest doesn't help here; for 
instance it would mean that a client (without the lock token) is allowed 
to add a new binding to a locked resource, but not to remove it.

As long as the model describes the semantics in RFC2518, and a client 
gets what it wants, I don't see any reason for coming up with a more 
complex model.

So the summary is... Why does it matter, and how does that justify a 
more expensive implementation?

Best regards, Julian

---

From: Lisa Dusseault <[email-masked]>
Date: Tue, 20 Dec 2005 11:35:59 -0800

> I still don't see concrete text, but anyway...

You could consider the current draft to hold concrete text.

> 2) I don't see any gain to a client. The purpose of a lock is that 
> while the resource is locked the client is protected from others 
> moving away the resource, or modifying it's lockable state. Just 
> protecting the binding that was locked achieves exactly that.

It's simpler for the client -- simpler client logic, fewer special 
cases.  In particular, it's a model that plain RFC2518 clients (clients 
that haven't implemented any of BIND) can understand.

>
> 3) Multiple bindings to a resource cause the server behaviour to 
> become more complex, yes. But the change you suggest doesn't help 
> here; for instance it would mean that a client (without the lock 
> token) is allowed to add a new binding to a locked resource, but not 
> to remove it.

Since that's covered in the BIND request, which is not part of RFC2518, 
I didn't see a need to get into that.  DELETE is part of RFC2518 thus 
we have to cover its behavior.

> more expensive implementation?

I'm not convinced it' s a more expensive implementation.  The best case 
for that argument is that it's a more expensive *server* 
implementation, for those servers which implement BIND.  It seems 
simpler for everybody else.

It matters because of the behavior with clients that are not aware of 
BIND.

Lisa

---

From: Julian Reschke <[email-masked]>
Date: Tue, 20 Dec 2005 20:56:10 +0100

> You could consider the current draft to hold concrete text.

1) We are trying to come up with a paragraph that summarizes lock 
semantics. RFC2518(bis) does not have this.

2) Please point to a piece of text that's not in sync with GULP, in 
particular saying what you think it says about DELETEing "other" 
bindings to a locked resource.

> that haven't implemented any of BIND) can understand.

How does it affect the client? How do things get simpler for a client? 
Please explain.

> I didn't see a need to get into that.  DELETE is part of RFC2518 thus we 
> have to cover its behavior.

I don't think that's helpful.

> for that argument is that it's a more expensive *server* implementation, 
> for those servers which implement BIND.  It seems simpler for everybody 
> else.
> 
> It matters because of the behavior with clients that are not aware of BIND.

I'm still waiting for an example *why* it matters. Just stating that 
some client implementors may find that behavior surprising is hardly a 
technical argument. For instance, when you have multiple URLs for one 
resource, updating URL a may also affect URL b. That's also "surprising" 
for clients that do not expect that.

Best regards, Julian