RE: Interop issue: Proposal for fixing lock token provision

On Monday, 10/07/2002 at 10:25 AST, "Clemm, Geoff"  wrote:
> I continue to be strongly against splitting the If header
> functionality, primarily to maintain interoperability between new
> clients and old servers, and between old clients and new servers.
>
> Any new client that sends just the new header, without also sending
> the same information in the If header, will fail against all old
> servers.=A0 A client could put in logic to send the new header to new=

> servers and the If header to old servers, but then you've just
> increased the interoperation complexity of clients, not decreased it.=

>
> Similarly, any new server that only accepts the lock token list from
> the new header, and not from the If header, will fail against all old=

> clients.=A0 A server could put in logic to handle both the old and th=
e
> new headers, but again, you've just increased the interoperation
> complexity of servers, not decreased it.

I hope my posting to Stefan's note addressed this for you.


> There is another question, which is that even if we leave the
> semantics of the If header alone (to maintain interoperability betwee=
n
> new clients and old servers, and old clients and new servers), should=

> we introduce a new header that gives the client the ability to submit=

> a no longer valid lock token, and still have the request succeed.

An earlier posting already indicated a case where that was inefficient
and suggested that because the client knows when this is appropriate
and has plenty of motivation to check it, we don't need to specify that=

the server check this without being prompted by the client.


> I am against the addition of this new header, because I believe the
> arguments in favor of it confuse the purpose of a lock and the purpos=
e
> of an etag.=A0 An etag prevents lost updates.=A0 You will be notified=
 if
> you are about to overwrite some other user's update, but you are then=

> left with a merge situation.=A0 A lock prevents merge situations (and=

> thereby also prevents lost updates).=A0 If you only care about lost
> updates, then you can just use etags.=A0 The only reason to use locks=
 is
> if: (1) you want to prevent merge situations, or (2) the resource
> supports locks but not etags.

Right...

>  In either case, you always need to know
> about lost locks because in case (1), you are no longer protected
> against merge situations, or in case (2), you no longer are protected=

> against lost updates.
Right.

And if it has Etag support and it's the last PUT, you might not care
care if you've lost the lock as long as the content has not
been updated.  There's no point in checking for the lock in that
situation and spec'ing  that the check be done anyway, just causes
needless delay.

Only the client knows if this is that last PUT.  Let the client decide
if the check is done.  It's not as if the client doesn't have plenty of=

motivation to get this right.

> As a general principle, I believe that unless there is no alternative=
,
> we should do all we can to reward implementors that have fully and
> correctly implemented the specification, by maximizing the likelihood=

> that new clients and new servers will interoperate successfully with
> those correctly and fully implemented old clients and servers.

I hope my posting on compatibility covered that for you.  Old and
new would continue to interoperate and new would perform better
than old.


> Therefore, I believe that the use of the If header should be clarifie=
d
> in RFC2518 bis (and in particular, guidance for how to use it to
> submit lock tokens),
> but that the If semantics should remain
> unchanged,
> lock tokens should not be added.

This proposal is an attempt to clarify how to both use and process
the If: header as well as to clarify how to submit tokens and how they
should be checked.   In fact it seems to do a very good job of that
which should alleviate all the interop problems that Lisa indicated
in her posting.

It does seperate the functionality in to two headers, but without
giving up compatibility and while increasing performance in some
situations.

It's more than reasonable to come up with an alternate proposal
though.  It sounds like we're trying to do that now.  We'll see how
that goes.

J.

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

Received on Tuesday, 8 October 2002 02:47:33 UTC