RE: Interop issue: Proposal for fixing lock token provision

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.  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.  A server could put in logic to handle both the old and the
new headers, but again, you've just increased the interoperation
complexity of servers, not decreased it.

There is another question, which is that even if we leave the
semantics of the If header alone (to maintain interoperability between
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.

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 purpose
of an etag.  An etag prevents lost updates.  You will be notified if
you are about to overwrite some other user's update, but you are then
left with a merge situation.  A lock prevents merge situations (and
thereby also prevents lost updates).  If you only care about lost
updates, then you can just use etags.  The only reason to use locks is
if: (1) you want to prevent merge situations, or (2) the resource
supports locks but not etags.  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.

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.
Therefore, I believe that the use of the If header should be clarified
in RFC2518 bis (and in particular, guidance for how to use it to
submit lock tokens), but that the If semantics should remain
unchanged, and a new header which allows the submission of invalid
lock tokens should not be added.

Cheers,
Geoff

-----Original Message-----
From: Jason Crawford [mailto:nn683849@smallcue.com]
Sent: Friday, October 04, 2002 7:06 PM
To: Lisa Dusseault
Cc: 'Stefan Eissing'; 'Webdav WG'
Subject: RE: Interop issue: Proposal for fixing lock token provision







We need to hear more from folks.  Things have been unusually quiet on this
subject.

Jason and Lisa have spoken up in favor of splitting the functionality.

http://lists.w3.org/Archives/Public/w3c-dist-auth/2002JulSep/0397.html (and
previous postings)
http://lists.w3.org/Archives/Public/w3c-dist-auth/2002OctDec/0003.html
http://lists.w3.org/Archives/Public/w3c-dist-auth/2002OctDec/0004.html

Stefan has spoken against it before that time, but it is unclear if he
understood the
proposal.  Hopefully the proposal is clearer now.

Let's hear from you folks...

J.

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