RE: [dav-dev] Deleting a locked collection

On Mon, 17 Apr 2000, Hall, Shaun wrote:
>...
> >> 	IF <http://foo.com/Parent> (lock token A)
> >> 	   <http://foo.com/Target> (lock token B)
>...
> >Actually, this should succeed :-)
> 
> >If there are no matching tagged-list productions, then the server should
> >act as if the If: header is not present (S9.4.2, 2nd Para, 2nd sentence).
> >S7.6 states that the locktoken (B in this case) must be submitted in the
> >If: header. It was, so the children pass.
> 
> My interpretation is that it should fail. Agreed about the IF header is not
> present, it will be ignored. However, when the children are tested for a
> corresponding lock token for the operation (DELETE), there is no matching
> lock token (as effectively there is no IF) and therefore the operation
> (DELETE) would fail.

It should act as if it wasn't present, but I'm interpreting it to mean
that it won't use it for precondition checking. But: that it is available
for looking for locktokens.

The whole point of submitting a locktoken is to show that you "know" the
correct locktoken for the resource. Consider the scenario presented in
S7.6.

There are two operations that are occurring:

1) assertions are made about specified resources (Parent and Target in
   this case)
2) locktokens are provided for the relevant locks, to show that the client
   is aware of what they are doing

Since there were no matching productions for the children, there are no
assertions (1) to be made about them. We must still satisfy (2) and
looking into that If: header is sufficient.

> Looking at the W3C list as well, why are people suggesting to extend the
> Lock-Token header to support multiple lock tokens when the no-tag-list does
> exactly this (it is the same principle in my opinion)? Am I missing
> something here (please correct me if I am)?

You are quite correct. The If: header with a no-tag-list does most of the
work. But if Target had a depth==0, then the If: header would also need
some "Not" productions in there (per one of my posts to w3c-dist-auth).

I think the Lock-Token header thing was possible a reaction/solution to
the If: problem. Breaking the problem into the two parts that I list
above, it becomes *very* apparent that we want to make the Lock-Token
header change.

1) assertions -- handled by If:
2) provisions -- handled by Lock-Token:

>...
> PS I'm not trying to argue with all these emails, just trying to clarify the
> RFC.

Me neither :-) ... yes, this stuff is complicated and unclear. These
emails are great for elucidating the spec. I believe we are just about
there.

> PPS Perhaps these things should just be discussed on the W3C-dist-auth list
> and taken off this list as these are RFC clarifications, not mod_dav
> specific. What do you think?

I've CC'd the main list. Conversation is fine here, as long we present
some final data to the main list along with background/conclusions/etc.
Specifically, if we recommend changing the Lock-Token header then that
conversation should occur on w3c-dist-auth.

Cheers,
-g

-- 
Greg Stein, http://www.lyra.org/

Received on Monday, 17 April 2000 16:03:00 UTC