RE: Interop issue: Proposal for fixing lock token provision

Jason pointed out to me in some private email that the questions in
his last posting were not rhetorical questions advocating one proposal
or another, but rather real questions that he thought we need to
answer.  I'd like to apologize to Jason for misreading his message,
and try to answer them properly this time.

   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." 
   > 
   > 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 a server knows that no condition specifiable in an If can cause a
GET to fail, then it can skip the If check.  But if it is not
absolutely sure, then yes, it has to check the If header.

   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.

Whether we can define what URLs are relevant will depend somewhat on
whether we can get server consensus on that question.  We may need to
have a few "MAY depend" clauses.  But optimally, we can avoid that
and make everything a MUST.

   And define what constitutes submission.

Yes, we definitely have to clearly 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. 

Yes.  (I assume you meant "to be broken" rather than "from being broken").

   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.  We have been discussing whether to make a special case for the
UNLOCK request, but this may end up being decided more on
interoperability grounds (i.e. if existing servers require the
request-URL to be the lock-root, then for interoperability, we should
at least advise clients that they should use the lock-root for
interoperability).

   And what is "modifying"? A PUT/PROPPATCH to an ordinary 
   resouce modifies it.

Yes, in this case, I think we can clearly state that only the
lock on the resource specified by the request-URL must be
submitted.

   Also operations that add or remove children 
   of a collection are considered to modify the collection. 

To add a child, you would have to submit tokens for any locks
on the collection.  To remove a child you would have to submit
tokens for any locks on the collection, any locks on the child 
being removed, and if the child is a collection, any locks on
any member of the child collection.

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

Yes.

   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 think it is simplest to just 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.

   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. 

This raises a good (although tangential) point.
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, so
I think we're OK here to require that the lock-root be the
tag for the submitted token.

Cheers, 
Geoff