RE: Crossserver ops and lock token swapping.

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. As such servers that put useful information into their lock
tokens are basically guaranteed to be badly written. In this case the first
manifestation of this "brokenness" will be when they try to coordinate with
other servers.

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

Given that the whole reason to jump into this pit is to enable servers to do
something they manifestly should never do I would recommend that the lock
tokens be required to remain the same.

		Yaron

> -----Original Message-----
> From: Greg Stein [mailto:gstein@lyra.org]
> Sent: Friday, September 10, 1999 2:45 PM
> To: ccjason@us.ibm.com
> Cc: w3c-dist-auth@w3.org
> Subject: Re: Crossserver ops and lock token swapping.
> 
> 
> ccjason@us.ibm.com wrote:
> >...
> > 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.
> 
> 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.
> 
> > 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
> 
> Again: neat philosophy. Go implement this and I'll buy it.
> 
> >...
> > move them.  Can we actually expect unsophisticated servers 
> to actually support
> > locks generated by other servers?  So this suggests...
> 
> Nope. But that was probably a rhetorical question :-)
> 
> >    1) MOVE does not move locks from source to destination 
> in any sense.  (But
> > 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]
> 
> >       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?)
> 
> 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.
> 
> >       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.)
> 
> This is *always* an option. A server can always return Bad 
> Gateway if it
> chooses not to do a move.
> 
> > 
> > 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? :-))
> 
> 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/
>

Received on Friday, 10 September 1999 19:33:47 UTC