RE: Interop issue: Proposal for fixing lock token provision

   From: Jason Crawford [mailto:nn683849@smallcue.com]

   On Monday, 10/07/2002 "Clemm, Geoff" 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?

If the client submitted an If header, then the server must check it,
yes.  But a client will not submit an If header with lock tokens for a
GET request, so I don't see how this is relevant to this thread.

   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.

Using a different header to submit tokens doesn't make it any easier
for a client to decide what tokens to submit in the header.  And yes,
we do need to define what constitutes submission.  I propose that
keep the semantics as stated in 2518, i.e. submission means appearance
in the If header.

   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.

Yes, the client always remembers both the root of the lock and the
lock token of the lock, and submits them together in the tagged list.

   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.

This question has to be asked/answered, whether we use the If
header or some new header.

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

True.

   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.

I disagree that we will be adding any new constructs to the If
header (at least, I do not plan on supporting any new constructs).
If we need new constructs, we should define a new header, for
interoperability reasons, if nothing else.  So all we need to deal
with is NOT.  I'm happy to keep things simple, and state that the
appearance of the lock token anywhere in the tagged list for the
resource is sufficient.

   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.

I agree that we need to clarify in 2518 bis how to submit a lock
token, but I think it is sufficient to state that the lock token
must appear somewhere in the tagged list for the resource.

   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.

The BIND protocol "clarifies" the 2518 DELETE semantics, to
state that it is the "mappings" to all the members that are
removed by the DELETE of a collection, not the bindings.
I believe this clarification should appear in 2518bis.
But even if some (misguided :-) server did destroy all the
bindings, the last one destroyed will be the lock-root, which
is what we're proposing to be the required tag for that token.

Cheers,
Geoff