Re: Interop issue: Proposal for fixing lock token provision

<<
In the light of this, is it useful to add another header where lock
token can also be supplied? What do client implementors say?
>>
In light of that and everything else I said of course. :-)

Boy the discussion on this topic seems light....

Anyway, I'll continue...

Stephan, for me the issue is about good design, not ease for the
client.  We'll make sure it's easy for the client to do the basics,
but right the use of the If: header is not fully and clearly defined
in the spec.  Before 2518bis the spec suggests that the If: header can be
used
for three purposes: (1) Client driven verification checks, (2)
submission of lock tokens for server side locking checks and (3) lock
refresh token submission.  The spec only goes in to any detail and
explicitly mentions (1).  In regard to (3), 2518bis moved that function
in to a seperate header.   And (2) is not defined in any spec;... only
mentioned.  Now that (3) is largely
solved, it's (2) that concerns me.  It makes it impossible for the
server writers to *always* get it "right" because "right" isn't clearly
defined.  We need to come up  with a way to describe what activity in
the If: header constitutes token submission.   We could have a rule
like, "if the token is mentioned in the If: header, then the server
can assume that the client is submitting the token".  But what if
the client checks a resource that is locked by that lock but that is
not relevant to the operation?  What if the client checks that the lock
is not applied to a resource that indeed it is not, then should that
be considered submitting the lock?   And if our If: headers become
more sophisticated, then what?   If the client asserts that either
or both of two tokens are applied to a resource, is that a submission?
We really need to seperate and clearly define the mechanism for token
submission.

It's not just a matter of affecting our ability to submit lock tokens.
It also affects a client's ability to fully and confidently use the If:
header to check assertions. The mix of purposes is already is affecting
our current design.  See the following paragraph from 9.5.1.1

   When the If header is applied to a particular resource, the Tagged-
   list productions MUST be searched to determine if any of the listed
   resources match the operand resource(s) for the current method.  If
   none of the resource productions match the current resource then the
   header MUST be ignored.  If one of the resource productions does
   match the name of the resource under consideration then the list
   productions following the resource production MUST be applied to the
   resource in the manner specified in the previous section.

So I believe this is saying that the server should only check the If header
for resources that the server feels are relevant to the operation.  I'm
guessing
this was placed in the spec to support the checking of locks by the
server, but it impacts a client's ability to check assertions on other
resources
that the server might not think are relevant and are in scope for the If:
header.  It also makes the semantics of the If: header simply difficult to
understand.

We faced a similar problem when it came to refreshing locks in 2518.  One
had to use the If: header in that spec to submit locks for refreshing.
After some discussion we decided to use a Lock-Token header for the purpose
of submitting a token to be refreshed.  2518bis.2 reflects this
change.

I'm suggesting that we do the same thing for client driven assertion
checking.  This will give us one purpose for each header.  Then we can
clearly define the semantics of each header and only face design
constraints that are relevant to the purpose of that header.

J.

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

Received on Wednesday, 2 October 2002 00:56:43 UTC