- From: Geoffrey M. Clemm <gclemm@tantalum.atria.com>
- Date: Sat, 11 Sep 1999 15:26:16 -0400
- To: w3c-dist-auth@w3.org
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