RE: Interop issue: Proposal for fixing lock token provision

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

I don't understand that answer.  It sounds like you're saying
that it's up to the server to decide what clauses should be 
checked.   Could you explain more?


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

OK.  Sounds right to me.



>    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"). 
Yes, that's what I meant.

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

BTW... I meant the URL of the root of the *lock*.  :-)

Sounds fair enough.  We aren't using the If: header of UNLOCK now anyway
and this discussion is about the If: header.



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

The request URL?   I guess that's okay.  I had actually proposed
the root of the lock rather than the request  URL.  I think lower
in this note you also said it should be the root of the lock.


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

Sounds right.


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

Okay, but you should clarify what you said near the top of this note 
because it
sounded to me like you said the server might not 
evaluate the assertions for some resources specified in the
If: header.


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

And what do we have to say anything about  NOT in an IF: header
or does that work out? 


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

You might want to say more about this in a newly named thread.
It will be lost in this thread. :-)  (I'd start the thread but I don't 
want to
misstate what you just tried to say. )

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

Okay... but I think a few paragraphs ago you suggested it
be on the request URI.  Do you want to alter that statement
when you reply?


------------------------------------------
Phone: 914-784-7569

Received on Wednesday, 9 October 2002 02:43:11 UTC