Subject: Re: Interop issue: Proposal for fixing lock token provision

From: Jason Crawford <[email-masked]>
Date: Tue, 24 Sep 2002 15:27:58 -0400

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

---

From: Stefan Eissing <[email-masked]>
Date: Wed, 25 Sep 2002 16:36:54 +0200

Am Dienstag, 24.09.02, um 21:27 Uhr (Europe/Berlin) schrieb Jason 

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

Without having been present at the meeting, I undestand item (3) like
this:

If a client does not bother with the If: header any longer and only uses
the new, to-be-defined header, it will never notice that locks have
expired. If the server returns the invalid lock tokens, the client
does not have to check itself.

That's how I understand it. I have not thought through if I like
the idea, though.

Now for (2): Except for the "unqualified" part, this can be expressed
with current If header syntax as

If: <resource-uri>(<lock-token>)(Not<lock-token>)

I'm not sure wether we need the unqualified part. It would be nice
thought to bring "comma support" into If header so that there can
be multiple If header lines in a request. Does anyone see a possibility
for this?

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

See my explanation above.

>> because the Timeout header only exists once per request too.

dito.

>> functionality in the If header.

It's good to clarify this. My client stumbled over different
server interpretations for COPY. It's never clear if an unqualified
token identifies the request resource, its children or even also the
destination resource as well. I refrain from using unqualified tokens.

So, I'd say this clarification is needed.

//Stefan