Re: Interop issue: Proposal for fixing lock token provision

<<
I read three proposals:
1. more clearly define the If header and its scope.
2. Introduce an additional request header for relaxed lock
    checking. The client says: " this is the bag of lock tokens
   I have, server, take your pick."
3. Introduce an additional response header where the server
   can indicated which token from the bag are no longer valid.

I am all for (1).
>>
Good :-)

<<
Regarding (2) and (3) I argued that, as we still need the If header, is
it really worth it to add a new header with related semantics?
>>
I wasn't really talking about (3).  I was planning to cover that in
a seperate thread.   I don't want to tie (3) to the issue of (2).  (3)
is an optimization that only becomes realistic if you have (2).   If
people didn't accept (2), there is no point in talking about (3).

Regarding "related semantics"... one of my points is that their semantics
would not be related.  Each header would work independently
of the other and the functions that each would perform would not overlap
the functionality of the other.  I think this would be important to
make sure the spec is clear and simple.




<<
If I understand you correctly, you seem to extend Lisa's original
proposal. Do you think 2518bis should remove lock tokens
from the If header completely?
>>
I propose that lock tokens remain in If: headers.  The If: header would
continue to be a list
of assertions by the client that must be true before the server performs
the request.  Those assertions
could continue to mention etag and also lock tokens.    None of that would
change, but...

The spec speaks of the need for a client to "submit" a lock-token to be
able to do
operations on a resource that is locked.   That is a good thing, but I
propose (2a) that
the mentioning of a lock-token in an If: header not be considered a
"submission" of a
lock token.  There would be a seperate header whose only purpose is to
allow the client
to submit lock tokens to satisfy the server's need to make sure that only
the principal
that holds the lock can operate on a locked resource.

I also propose, (2b) that we not *require* that a client check if a lock is
on a resource (with the
If: header) when submitting the token with the new header.   But we can
*recommend* it
for compatibility reasons and because in many situations it's the only way
a client can
be certain that there is no lost-update situation on that resource.

That is a simplified explanation.  The original proposal (2) above mentions
relaxed lock
checking on that new header.   I support that and can make a small case for
that, but I
realize others might not support that.  I could also accept a situation
where the new
header doesn't just list a bag of tokens but also says something about the
location of
those locks.  If we have to do that, my only request on that point is that
we be very clear
and thoughtful about how we specify that.  If we can't specify that clearly
and thoughtfully,
then I prefer we use the "bag of tokens" approach.  I find that approach
acceptable
because in most cases the client has plenty of motivation to use the If:
header to check
if the lock is still there.  If they are going to check that anyway, I
don't see a lot of point
in complicating the definition of the new header.

Another thing I'd like to propose is that the paragraph I mentioned about
the server
only checking the If: clauses that it wanted to check be removed.  If not
now, then later.
That paragraph limits the possible use of the If: header.   Anyway... I
don't want to talk
about this much.   It's just another improvement that becomes possible if
we do move
lock token submission to a new header.

I hope this is clearer.

J.

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

Received on Wednesday, 2 October 2002 11:26:54 UTC