Re: Interop issue: Proposal for fixing lock token provision

This was written after having made the comments below. To me it is 
becoming
unclear what exactly we are disucssing here. In

http://lists.w3.org/Archives/Public/w3c-dist-auth/2002JulSep/0275.html

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

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?

Especially in your original mail
(http://lists.w3.org/Archives/Public/w3c-dist-auth/2002JulSep/0398.html)
you said:

 > It's not really the length that's the problem in my mind.  It's
 > the fact that we have to define what it means for the If:
 > header to have *submitted* the token.  The If: header
 > can be quite sophisticated and we might choose to make
 > it even more sophisticated as we discover more requirements.
 > If we combine the functionality, then it constrains how much
 > we can extend the If: header.
 >
 > Yes, we could say that clients can support multiple If:
 > headers.  (I forget if we already do.)  But we'd end up
 > defining two types of If: headers for the two purposes.
 >
 > I'd prefer to seperate those explicitly.  WebDAV is only
 > in version 1 now and hopefully a design decision like
 > this will clarify the protocol now and avoid specification
 > headaches down the road.

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?

//Stefan

Am Mittwoch, 02.10.02, um 06:36 Uhr (Europe/Berlin) schrieb Jason 
Crawford:
> <<
> 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. :-)

Must be the language barrier. I never meant to say that your
arguments should not be considered.

> 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

Unless I do not fully understand your point, (2) is defined by me in
2518 ch. 7.6:
   "In order to prevent these collisions a lock token MUST be submitted
     by an authorized principal in the If header for all locked 
resources that
     a method may interact with or the method MUST fail."

Now, I fully agree to your point that the set of affected resources is
not clearly defined for all methods. Particularly it is not clearly 
defined
what the untagged production applies to and how deep locks are
handled. I'm all for clarifying in 2518bis how the If header should
be used and what it should look like, so clients and servers
implementations do not have to guess.

> 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

Those are all good questions. Do you think this needs to be defined
in 2518bis or is this an argument for dropping lock-tokens from the
If header because it is impossible to get it right?

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

Agreed.

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

Again, I agree that it is not easy to understand. As you say, this is
partly due to the current wording in the spec. The other complexity
is due to the use cases it tries to solve.

>
> 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 05:24:34 UTC