Interop issue: Proposal for fixing lock token provision

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

Received on Sunday, 15 September 2002 14:32:51 UTC