RE: Interop issue: Proposal for fixing lock token provision

On Monday, 10/07/2002 at 02:14 AST, "Clemm, Geoff"
<nngclemm___at___Rational.Com@smallcue.com> wrote:
> Alternatively, we could just say:
>
> "A client MUST submit a tagged-list If header, using the
> DAV:lock-root of the lock as the tag for that lock token."
>
> A simple rule for new clients, that will interoperate with
> all correctly implemented old and new servers.
>
> If any of the tagged-list productions fail, the resource
> that is no longer locked will be indicated with a 412 in
> the multistatus return, telling the client to either remove
> that lock from its table, or request a new lock for that
> resource.

And ALL tag list productions would be evaluated, so that
even if the server didn't think it was relevant, it still would be
checked.    So for example I can do a GET on a resource
with an IF: header and the IF: header would be checked despite
the server thinking it is unnecessary to check for locks on a
GET request.    Does this sound fine?

And the client is required to submit a tag list for every URL/resource
that the server thinks is relevant in order to submit the token.
And we're going to have to define what URL's are relevant.  And
define what constitutes submission.

So for a situation where a token needs to be submitted to allow a
protected URL from being broken (lock destroyed), the root URL of the lock
in
question needs to be submitted.

And in a situation where a token is needed to allow a write locked
resource to be modified, the URL of the root of that resource needs
to be specified.

And what is "modifying"? A PUT/PROPPATCH to an ordinary
resouce modifies it.   Also operations that add or remove children
of a collection are considered to modify the collection.

The client is free to test any other resources it wants to test beyond the
one's the server requires.

We need a spec'ing of what tag list entries are sufficient to be considered
a submission.   That has to deal with NOT  and any other expression
constructs we might come up with.

BTW... yes, I know earlier tonight I said that it's okay to test against
any resource locked by a resource in order to submit the lock, but
I'm guessing the definition of "submit" will be easier if we are as
specific as possible about what it means to submit a token and
specifying what URL is definitely something that will help.

Also, in the case of 2518-style DELETE where lots of bindings
get destoryed and they probably get destroyed bottom up, I'd think
it would be best (or at least equal) in some server implementations
if the URL you specified for the submisssion was the one that got
destoryed last.

J.

Received on Tuesday, 8 October 2002 10:23:01 UTC