Re: Interop issue: Proposal for fixing lock token provision

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

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

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?

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

See my explanation above.

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

dito.

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

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

Received on Wednesday, 25 September 2002 10:37:20 UTC