- From: Eric Sedlar <eric.sedlar@oracle.com>
- Date: Wed, 15 Aug 2001 16:13:44 -0700
- To: "Webdav WG" <w3c-dist-auth@w3c.org>
The other issue, Geoff, is that people are using LOCK as a poor person's CHECKOUT, also assuming that LOCK's won't timeout. The RFC2518 revision should clearly state that LOCKs aren't to be used for this purpose. --Eric > -----Original Message----- > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Clemm, Geoff > Sent: Wednesday, August 15, 2001 2:16 PM > To: Webdav WG > Subject: RE: Webdav issue: UNLOCK_BY_NON_LOCK_OWNERS > > > 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 19:09:32 UTC