Subject: Interop issue: Proposal for fixing lock token provision

From: "Lisa Dusseault" <[email-masked]>
Date: Sun, 15 Sep 2002 11:31:53 -0700

At this week's Interop event, as at last year's, many interoperability
problems were found with scenarios involving change methods where a lock
token is required.  A long, animated, exciting conversation was held to
finally achieve  consensus among attendees on goals for a new way to
supply lock tokens to servers.

GOALS for Lock Token Provision
------------------------------

1. Clients should be able to provide lock tokens in conditional requests
that cause the request to fail if the token does not still match the
state. This goal is currently met by the If header, but this goal must
continue to be met by any new solution.

2. Clients should ALSO be able to provide multiple unqualified lock
tokens in order to prove that they have those tokens and can do write
requests legally, in a way that does not impose conditions on the
success of the request. This mechanism should not use or affect the
Lock-Token header which is required in UNLOCK to specify a single lock
token to remove or refresh. This mechanism should be capable of
supporting many values.

3. Servers should be able to inform clients when lock tokens being used
in any way are no longer valid.   This helps clients keep their
understanding of the server's state up-to-date.

Discussions on how to solve
---------------------------

1. Already solved by If header. Only slight clarifications needed to
improve basic interoperability of this header (see below).

2. The mechanism to provide multiple tokens could easily be a new
header. The syntax should involve comma-separated values, because then
lines can be split across multiple instances of the header according to
RFC2616 header rules.

3. A new response header or two could allow servers to return invalid or
unnecessary lock tokens.  This should be a response header so that the
information can easily be marshaled even on responses that already
contain a body. Again, the response header syntax should be
comma-separated.

Slight changes to existing definitions
--------------------------------------

- The existing Lock-Token header is used to specify a single lock token,
in methods that must operate on a single lock.  It is used on UNLOCK to
remove a lock.  The LOCK refresh request should ALSO use this header
(and the If header should continue to be supported by servers in order
to handle existing clients).  This includes the clarification that LOCK
refresh can only be used to refresh a single lock.  That's a good thing,
because the Timeout header only exists once per request too.

 - An untagged token in the IF header should apply ONLY to the resource
named in the Request-URI.  The original definition is that they apply to
any resources "affected" by the request. This has turned out to be too
ambiguous and arduous to determine.  Also most lock tokens only apply to
one resource, not the entire set of resources "affected" by a request
like MOVE/COPY. Since any token in the IF header can be tagged with a
URL in order to make it explicit what resource the token refers to, we
can make the untagged token equally explicit without removing any client
functionality in the If header.

Lisa

---

From: Jason Crawford <[email-masked]>
Date: Wed, 25 Sep 2002 13:41:22 -0400

On Wednesday, 09/25/2002 at 04:36 ZE2, Stefan Eissing  wrote:
> Am Dienstag, 24.09.02, um 21:27 Uhr (Europe/Berlin) schrieb Jason
> Crawford:
>
> >> ...
> Now for (2): Except for the "unqualified" part, this can be expressed
> with current If header syntax as
> ...

I think part of their point here was that they want to seperate the
submission of lock tokens to satisfy the server's enforcement of
locking rules  from the clients' submission of pre-reqs for the
request   One type of submission (tokens) is pretty simple.
The other (conditional expressions) is not quite as simple.  But in
combination in the same header it makes for messy semantics.
For that reason, the If: header wasn't advocated for (2).   At least that's
what
I assume based on previous  discussions.

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

---

From: "Clemm, Geoff" <[email-masked]>
Date: Fri, 27 Sep 2002 09:42:21 -0400

Could someone post what exactly were the interoperability problems
that were found?  As far as I can tell, the If header is a superior
way of handling the locking scenarios than the alternatives being
proposed.

In particular, I do not find the "separation of concerns" argument
convincing, since issue #3 (detecting when you have an
invalid lock token) is exactly the reason why a single header
is used both to check state and demonstrate possession of the
required token (i.e. I believe the concerns are inherently linked).

In particular, I do not support #2, because it leads a client to
perform updates against resources that it has lost its lock on.
Why would a client ever want to do that, instead of reacquiring
a lock?  A key benefit of locks as currently defined is that they
solve the lost update problem for servers that cannot provide etags,
but updating a resource for which you have lost your lock 
opens you up to the lost update problem.

Note: If lengthy If headers has proven to be a problem, I am
happy to allow a "," to separate If clauses, so that
you can submit multiple If headers in one request.

Cheers,
Geoff

-----Original Message-----
From: Jason Crawford [mailto:[email-masked]]

This thread seemed to get overlooked, so I want to get discussion going on
it...

> GOALS for Lock Token Provision

I basically agree with (1) and (2).  I value keeping the server driven
submission
of tokens seperate from client driven consistancy checks.  Hopefully this
will
simplify the If: header semantics.

(3) is new to me.  I'd like to hear more discussion on it.  Perhaps as a
seperate
thread.

> Discussions on how to solve

OK

> lines can be split across multiple instances of the header according to

OK.  I can see how that can be implemented without breaking compatibility.

> contain a body. Again, the response header syntax should be

I'd like to hear more about the requirement for this.

> Slight changes to existing definitions

OK with me.

> functionality in the If header.

OK.

So what do other people have to say?

J.