RE: Submitting lock tokens without a validity check

   From: Lisa Dusseault [mailto:lisa@xythos.com]

   > > If a client uses "If: urlA (tokenA) (Not tokenA)" then the
   > > client will *not* find out that their lock is invalid.

   > Wow. You managed to completely puzzle me.
   > I thought that was exactly the point of this kind of request.

   Weird, eh?  By using the If-Not-If hack, the client asks the
   request to succeed if the locktoken is invalid, or the locktoken is
   valid.  So the client never finds out if the locktoken is invalid,
   because the if-not-if combination never fails.

And if the client uses the proposed new header, the exact same thing
occurs, i.e. the client never finds out if the locktoken is invalid,
because the new header never fails.  What puzzled Julian was not
the semantics that you were describing, but rather the fact that
you dislike the semantics when it is marshalled in an If header,
but like it when it is marshalled in the new header.

   The issue to be solved is that all the client developers who have
   spoken up about the if header say that it's too hard to make
   interoperable.

And we have two proposals for how to fix this.  We are now debating
the relative merits of those two proposals.

   Every time the client is tested against a new server, some operations on
   locked resources fail.  Usually they fail because 
    1. the server expects to see a lock token that the client hasn't
   provided,
    2. the server expects a lock token to apply to a specific URL and the
   client didn't use the correct URL, 
    3. the client provides a locktoken for a URL that isn't even affected
   in the request, and that lock token or URL is incorrect, or 
    4. the lock expired.

   The reason why I suggested the approach of defining '*' as a wildcard
   for the IF header is because 
    - it removes the need to figure out which URL to put the locktoken on
   (fixing #2)

Since the only safe way (i.e. that prevents lost updates) to avoid
checking the validity of the lock token is to also specify an If
header with an etag for the resource, the client must specify
the appropriate URL for the etag.  And if it can remember what etag
goes with a URL, it can remember what lock token goes with a URL.

This is one of my objections to this separate header.  It makes it too
easy for a client writer who finds the If header "too complicated" to
just use this new header, omit to specify an If header with
appropriate etags, and then overwrite changes made by other clients to
resources whose locks have expired.  Conversely, a client that can
properly keep track of an etag (which requires keeping track of what
URL it goes with), can use the same data structures to keep track of
what lock token goes with that URL (and therefore #2 would not be an
issue).

    - when multiple resources are under the same lock, and when the lock
   token appears with '*', it's clear that  it applies to any resource
   locked with that token (fixing #2 even more);

As above, * doesn't work with etags (which must be used if locks are
not going to be checked), and if a client is going to accurately track
the etag for a URL, it can use the same data structure to accurately
track the lock token for a URL.

    - it makes it easier to include lock tokens that aren't actually
   required (fixing #3 and making #1 less likely)

A debate of which method is "easier" is unlikely to be productive.
Those of us that prefer the If/Not method believe it is "easier"
because it is more regular and more accurately reflects the semantics
being used.

    - It's shorter than putting the full URL (although we may still need
   comma support) (making #1 easier to achieve by including more lock
   tokens before running up against length limitations)

We have agreed that the "new header" method has 25% fewer non-constant
strings per locked resource (3 instead of 4).  But several of us feel
that the 25% savings in header length for this use case does not merit
the introduction of a new header.

   From: Lisa Dusseault [mailto:lisa@xythos.com]

   Julian said: "Checking: the desired semantics are that the request
   succeeds independently of the lock still being present or not?"

   Geoff said: "Yes."

   My response: I don't agree with that narrow definition of what's
   desired.  I think the problem statement is that the if header is
   constantly causing interoperability problems. The desired semantics
   are "some semantics that make locks easier to use".

Julian was not asking for a problem statement.  He was asking for the
desired semantics for the proposed new header.

Cheers,
Geoff