- From: Clemm, Geoff <gclemm@rational.com>
- Date: Wed, 15 Aug 2001 17:15:44 -0400
- To: Webdav WG <w3c-dist-auth@w3c.org>
Personally, I believe that any use case that assumes a long-lived lock is broken. Those use cases should be handled by access control, not locks. ACL's have no timeouts, and are principal based, which gives us a clean way of handling all the problems that have arisen when people have tried to use locks where they should be using ACL's. When you only use locks for short term reservations of a resource, all of these concerns about timeouts and locks being stolen evaporate. With the ACL draft in last call, we no longer have any reason to use locks as a poor man's ACL. Cheers, Geoff -----Original Message----- From: Jason Crawford [mailto:ccjason@us.ibm.com] Sent: Wednesday, August 15, 2001 3:03 PM To: Webdav WG Subject: Webdav issue: UNLOCK_BY_NON_LOCK_OWNERS I'm posting in part to get our subject line to actually describe what we're talking about. And to express an opinion and questions and observations... I think Shaun has some points. Almost every explanation and discussion has focused on why a client should be able to deal with the lock going away. Given that, Shaun's reaction seems reasonable. We appear to be undermining some of the intent of the locks if that's all we say. I can imagine a lot of other readers of 2518's next draft scratching their head when we say people can just pick up the token and unlock the resource. Please let's not forget to include some mention of the fact that this capability is recommended to be under some sort of ACL control and it should not be possible to have one person unlock another person's resources willy-nilly and that it's not even required to support it. Note: I don't think 2518 actually requires servers to reveal the lock token in a the lock-discovery property. Do we care? I would feel a lot better about all this if we had a good explanation about strategies to deal with lock timeouts. How long should a client request the time out to be in various scenarios? What pitfalls are there? What solutions are there? What ACL strategies would work best? What refresh strategies? For example, I take out the lock. I think I'll only need it for an hour. But I have to run home and the lock times out. How must the client and server and human behave to handle that? Should the client have requested a long timeout even though it didn't expect to need that much time? I want to lock a file, grab it, give it to a non-webDAV enabled friend to edit. Then put it back on the server in a day or week or year. What if I over estimate or underestimate the time needed? What if a reboot is needed? Or we forget that we did all this or I leave the company and the company needs to get the friend's change in there. What is the best way to deal with these situations? Long timeouts? Frequest refreshs? Exposed tokens in GUI's? Lock stealing clients? Lock stealing only of your own lock? Clients that store tokens persistantly? Servers that only expose tokens to certain principals? Calls to the administrator? ACL strategies? How do these strategies vary in different environments? At the NSA? In a classroom? Often workign offline? Simply on localhost? I'm not sure if this could go in to the draft, but perhaps we could provide a checklist for client (and server?) implementations and server administrators to make sure they can handle situations like these. Or perhaps we could discover that we only need a narrow set of optional behaviors to chose from. J. ------------------------------------------ Phone: 914-784-7569, ccjason@us.ibm.com
Received on Wednesday, 15 August 2001 17:06:33 UTC