RE: Interop issue: Proposal for fixing lock token provision

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

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

My answer was poorly worded.  I meant to say that if the server can
tell just by scanning the If header that it doesn't apply to the GET,
then it can skip the If header.  For example, if the If is a tagged
list, and the tag did not identify the request-URL, since a GET only
applies to the request-URL, it can ignore that 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.

Parsing problem (:-).  I meant: "the lock on (the resource specified by
the request-URL) must be submitted", not "(the lock on the resource)
specified by the request-URL must be submitted".

So yes, to address some interoperability problems that have been
reported, the proposal is to require that the tag in the If header be
the lock-root of the lock.

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

I meant that it might be sufficient for the server to just
parse the If: header, and not actually evaluate them against
any resources.

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

I could go either way, but I'd probably be inclined to not say
anything special about the NOT.  This means that putting a NOT
around a lock token is guaranteed to fail (i.e. because either it
is locked with that token, so the NOT fails, or it is not locked
with that token, so it is an invalid lock token, and it fails).
Alternatively, we could say that it is only a submission of the
lock token if it does not appear in a NOT, but all that buys the
client is the ability to have a request succeed only if the
resource is not locked by a particular lock token, which seems
like a pretty pointless semantics to support.  But I'm happy 
to do it either way.

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

Good point.  Will do.

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

I'll keep the statement but clarify the parsing of the earlier
paragraph (:-).

Cheers,
Geoff