Subject: Crossserver ops and lock token swapping.

From: [email-masked]
Date: Fri, 10 Sep 1999 13:54:57 -0400

Geoff,
   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.
Here's a bit of verbage the issue of lock token swapping....

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.

Now the verbage...

I'd like to propose that moving a lock across servers not change the lock token
for a lock on that moved resource..  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.

An argument against what I've just said is... what if someone wants to move a
resource (or tree) between servers.  And neither server really supports
bindings.  (Is server support for multiple bindings to a resource a MUST?)
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
   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
   3) MOVE wouldn't be allowed between these these servers.  The client would
have to use
DELETE/COPY/DELETE.  (Keeps protocol simple.  Probably is good enough for those
with cheap servers.)

Thoughts?

Further thoughts on cross server.  As some have pointed out, right now the spec
is nowhere near close enough to actually enable two independently developed
servers to do cross server operations besides possibly COPY.  Things like
cooperative authentication and lock and binding protocols are are needed.  And
we need to specify that lock tokens be standardized.  (We might want to address
this now rather than retrofit this later.)  (Judith pointed this out.)  So are
we agree'ing that WebDAV is to be cross server friendly/compatible... but not
enabling?  (Is that what Yaron was trying to say? :-))

J.

------------------------------------------
Phone: 914-784-7569,   [email-masked]

---

From: Greg Stein <[email-masked]>
Date: Fri, 10 Sep 1999 14:44:40 -0700

[email-masked] wrote:
>...

This is rather neat philosophically/academically, but from a pragmatic
standpoint, I don't think it really holds water.

Let's just take a simple example of a resource being moved from a
filesystem into a database. The filesystem prefers scheme X to represent
the locks. The database prefers Y. Sure, they could both use
opaquelocktokens, but they aren't -- they're each using a scheme to
optimize their behavior.

Now what are you going to do?

I say the MOVE allows the lock token to change, or it just isn't going
to happen.

> resources are accessable.  In this case the resource(s) is now accessable via a

Again: neat philosophy. Go implement this and I'll buy it.

>...

Nope. But that was probably a rhetorical question :-)

> this breaks model of resource is what is locked.)

Works for me.

[although, as I stated in reply to Judy's initial proposal: I'm also
fine with moving the lock. I think it isn't making as much sense (to me)
to move it, though. more below]

> face authentication issues?)

I prefer this option.

Why not just allow the MOVE to return a Lock-Token header? The
Lock-Token header would specify the lock that the (moved) resources now
fall under at the destination.

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.

> DELETE/COPY/DELETE.  (Keeps protocol simple.  Probably is good enough for those

This is *always* an option. A server can always return Bad Gateway if it
chooses not to do a move.

> enabling?  (Is that what Yaron was trying to say? :-))

I believe Yaron was trying to say that we should not be considering
server-to-server communication. The WebDAV charter explicitly states
that this is not in scope. As a result, any portion of the specification
that are necessary *only* for server-server communication should be
axed. If you can argue a DAV client would use it, then it can stay :-)

Cheers,
-g

--
Greg Stein, http://www.lyra.org/

---

From: "Geoffrey M. Clemm" <[email-masked]>
Date: Sat, 11 Sep 1999 15:26:16 -0400

From: [email-masked]

   <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 <[email-masked]>

   <gs/> There is an issue, though: what of the old locktoken? Did it get moved

<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)" <[email-masked]>

   <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 <[email-masked]>

   <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