- From: Hall, Shaun <Shaun.Hall@gbr.xerox.com>
- Date: Wed, 15 Aug 2001 16:02:36 +0100
- To: Webdav WG <w3c-dist-auth@w3c.org>
> -----Original Message----- > From: Clemm, Geoff [mailto:gclemm@rational.com] > Sent: 15 August 2001 14:56 > To: Webdav WG > Subject: RE: Notes from DAV meeting > > > From: Hall, Shaun [mailto:Shaun.Hall@gbr.xerox.com] > > I agree with all of Shaun's comments, except for: > > > - Lock Permissions - > > Consensus around: Users other than lock creators MAY be able to > > UNLOCK a resource by discovering and using the correct lock > > token. > > Assuming your are referring to "ordinary" users i.e. not say when > an Administrator removes a lock because an employee has left the > company sort of thing: > > I strongly disagree with this. It should not be allowed at all. > > I strongly agree with the consensus opinion. > > A client holding a lock already has to deal with locks being lost > through timeouts. Allowing another client to effectively force the > timeout is a valuable feature that does not increase the complexity of > the locking client. A server can use access control to control what > users have permission to force the timeout. > > I know locks can disappear at any time, but it could cause problems > for example ... > > Any such problem already occurs because of timeouts, so > clients have to > deal with all these situations anyway. Allowing a client to force > a timeout decreases the need to have an automatic server timeout, > and therefore this capability will actually decrease the number of > unnecessary timeouts (since the server can be written to assume that > timeouts will be forced by clients that need them). Supposing the server only supported infinite timed locks (which is allowed) and therefore lost locks through timeouts are not an issue. You've just bypassed the lock mechanism as we know it. In my crude example, what is the original lock creator suppose to do ? > > Cheers, > Geoff > Regards Shaun Hall Xerox Europe
Received on Wednesday, 15 August 2001 11:03:21 UTC