Re: Crossserver ops and lock token swapping.

   From: ccjason@us.ibm.com

   <jc/> I'm tending to agree with you (and Yaron) that cross server
   moves shouldn't be a special case in the protocol.  No lock token
   swapping for example.... BTW, before I get to the verbage, I just want
   to say that even if we agree that cross server isn't a special case,
   I'd kind of like the spec to mention cross server operations...  Just
   to say that various URI's *CAN* include the host name for example
   would be an example of what we can say to remind the reader of the
   cross server compatibility.  I just want to bring attention to the
   fact that WebDAV should be cross server compatible and to remind us
   that we shouldn't really add anything that prevents this.

<gmc/> I agree.  I think one of the problems has been that we (and
certainly, *I*) have sometimes failed to distinguish between:
- using cross-server issues to influence the protocol design (*good*)
- defining different protocol behavior for intra-server and cross-server
  operations (*bad*)
Motivating a particular protocol design choice by appealing to
cross-server issues is perfectly reasonable, but addressing cross-server
issues by defining *different* protocol behavior in this case produces
an unacceptable complexity in the protocol and therefore in clients that
try to use it.

   <jc/> I'd like to propose that moving a lock across servers not change the
   lock token for a lock on that moved resource.  

<gmc/> I agree.  Greg and others gave various reasons why a
cross-server MOVE might not be able to preserve locks.  That's fine.
The server is then just responsible for failing the MOVE request.  The
client can then do an UNLOCK/MOVE/LOCK or a COPY/LOCK.  Trying to
hardwire certain variants of UNLOCK/MOVE/LOCK or COPY/fixup/LOCK into
the MOVE semantics is virtually guaranteed to produce non-interoperable
behavior.  (Heck, look at how the simple MOVE request was implemented
by some as a "merge" request ... just imagine how many ways the
lock renewal semantics could be misinterpreted).

   <jc/> The reason I say this
   is because we are claiming in the proposal that locks are on
   resources... not bindings or URI's.  Well, a MOVE operation is
   basically just a rebinding and in that sense, the resource itself has
   not moved.  MOVE just changes some of the URI's at which resources are
   accessable.  In this case the resource(s) is now accessable via a URI
   on another server.  (Note: It may still be accessable at the source
   server via another URI.)  In order to achieve this, we implicitly
   require (except for special cases) that server pairs cooperate on
   bindings... and therefore locks since a locked resource can be
   accessed via a URI on either machine.

<gmc/>  I agree with all this, except for the "except for special cases".
What did you have in mind here?  Either the server pairs cooperate on
bindings so that bindings semantics is maintained, or they must fail
the BIND or MOVE request that would have created the cross server binding.

   <jc/> An argument against what I've just said is... what if someone wants to
   move a resource (or tree) between servers.

<gmc/> Then they either UNLOCK the tree before the move (if the server cannot
move the locks), or they do a COPY/DELETE (if the move would have
resulted in cross server bindings and the server cannot support them).

   <jc/> And neither server really
   supports bindings.  (Is server support for multiple bindings to a
   resource a MUST?)

<gmc/> It is a MUST if they support the advanced collection protocol.

   <jc>
   These are really simple servers with simple
   mappings.  One mapping per resource.  But one wants to move resources
   between these servers.  Nothing fancy.  Just move them.  Can we
   actually expect unsophisticated servers to actually support locks
   generated by other servers?  So this suggests...

   1) MOVE does not move locks from source to destination in any sense.
   (But this breaks model of resource is what is locked.) or

<gmc/> I agree.  Unless we want to define two different MOVE
protocols, the protocol has to make sense not only for simple servers,
but also servers that do support multiple bindings to a resource.  And
deleting the locks from the source of the copy does not work if there
are multiple bindings to a resource that still expect it to be locked.

   2) We let the destination reassign lock tokens.  (Is this situation
   important enough to take this approach and complicate the spec? And
   wouldn't they still face authentication issues?), or

<gmc/> I agree.
I do not believe that this situation is important enough to warrant
the complexity it would introduce in both the protocol and in clients
using the protocol.  

   3) MOVE wouldn't be allowed between these these servers.  The client
   would have to use COPY/DELETE.  (Keeps protocol simple.
   Probably is good enough for those with cheap servers.)
   </jc>

<gmc/> I agree.  Simple and sufficient for the key use cases.  I'd defer
enhancements until the need for them has been clearly demonstrated.

   From: Greg Stein <gstein@lyra.org>

   <gs/> There is an issue, though: what of the old locktoken? Did it get moved
   (and changed) or did it remain? Hrm. This isn't an issue, though, if we
   state that it always remains (yes, this is different than Judy's latest
   proposal; it also follows my suggestion about it remaining and
   establishing a locknull resource). If the lock remains, then client can
   always know what happens -- the source lock remains, the resource now
   falls under the lock specified by the returned Lock-Token.

<gmc/> Having the lock continue to apply to the source (null) resource
would be problematical in the presence of multiple bindings to the same
resource.  The lock would apply to both the null resource, and to the
resource as it is known by other mappings.  Now you create a new resource
at the null resource location.  This inherits the lock, which means that
the same lock applies to both the old and the new resources.  This leads
to a large number of anomalies.

   From: "Yaron Goland (Exchange)" <yarong@Exchange.Microsoft.com>

   <yg/> For example, imagine that after the response with the
   new lock token is sent the connection is lost and the client never actually
   receives the response. The client can, of course, perform lock discovery on
   the destination (after checking that the source is gone) and get the new
   lock token. The only problem is that the client now doesn't know if the
   resource has been locked the whole time. For example, did another program
   also under the user's control happen to ask for a lock on the resource, thus
   explaining why the program can access the lock? Because the lock token isn't
   the same there is no way for the program to know if the lock it took out was
   outstanding the whole time so any consistency guarantees provided by the
   continuing existence of the lock are abrogated and the client is S.O.L. Of
   course we could try to work around this problem by either providing some
   sort of lock equivalence statement or using timers but those lead to their
   own complications.

This is such a good example of what can happen when a lock token is
effectively "re-identified" that I thought I'd just quote it verbatim (:-).

   <yg/> One of the first lessons learned years ago in the database world is to
   absolutely never put any useful information into an identifier. It always
   bites you.

   <gs/> Forgive me if my jaw hits the floor.
   [good examples of why info is encoded in URI's deleted]

<gmc/> It's important to distinguish an identifier (in the sense that
I believe Yaron intended, namely a GUID or a UUID) from a URL or name.
A URL or name will commonly encode some semantic information.  An
identifier (or URN) is there to determine identity.  If you depend on
non-identity information appearing in the identifier, then things break
badly when that non-identity information is no longer true about
that resource.

   <yg/> While it is true that we can hack up the protocol to make it support
   allowing the lock token to be changed on a request by request basis this is
   an abysmally bad idea.

   <gs/> Excellent point! I agree with you here. That leads me to believe that
   locks MUST NOT move with the resource since the Destination may not
   support the transfer of the locktoken (heck, what happens if the
   Destination doesn't support locking!).

<gmc/> The alternative conclusion is that unless the server can maintain
the lock token, it must fail the MOVE request.  I think this is a more
scalable/extensible approach than defining special behavior for the
MOVE with respect to various resource behavior (such as locks and bindings).

   <gs/> However, I still disagree on your notion that locktokens cannot be
   defined by the server (to include useful info). And I *really* disagree
   with your (unsupported) view that this implies the server is badly
   written.

<gmc/> If you encode anything in the token, you must then constrain
the resource to always satisfy whatever information is stored in that
encoding (or else anything that counts on this encoded information will
be misled).  That means that operations will fail in various server
defined ways depending on what they decided to encode in those tokens.
So I'm with Yaron on this one.

   From: John Stracke <francis@ecal.com>

   <js/> It occurs to me that the biggest reason you'd want to MOVE the
   lock is because you want to keep control over the resource in the new
   location.  Couldn't you do that by locking the destination and then
   MOVEing the resource?

<gmc/> Good point.  I may have to withdraw my objection to the null-resource
lock, since only the null-resource lock survives a MOVE.

Cheers,
Geoff

Received on Saturday, 11 September 1999 15:26:20 UTC