Re: Interop issue: Proposal for fixing lock token provision

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

On Sunday, 09/15/2002 at 11:31 MST, "Lisa Dusseault" wrote:
> 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.

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
> ---------------------------
>
> 1. Already solved by If header. Only slight clarifications needed to
> improve basic interoperability of this header (see below).

OK

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

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


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

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


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

OK with me.


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

OK.

So what do other people have to say?

J.

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

Received on Tuesday, 24 September 2002 15:32:51 UTC