- From: Hall, Shaun <Shaun.Hall@gbr.xerox.com>
- Date: Wed, 15 Aug 2001 09:53:31 +0100
- To: Webdav WG <w3c-dist-auth@w3c.org>
Bits snipped. Lets kill these things before they go any further IMHO... > -----Original Message----- > From: Lisa Dusseault [mailto:lisa@xythos.com] > Sent: 14 August 2001 21:21 > To: Webdav WG > Cc: minutes@ietf.org > Subject: Notes from DAV meeting > > > > I haven't received the actual notes yet from the notetaker > (hint, nudge) but > here's what I wrote down from the WebDAV meeting last week in > London. Note > these are incomplete. Lots of progress made; various threads > to pick up and > continue on the list. [Bits snipped] > RFC 2518 Issues list > -------------------- > > - 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 know locks can disappear at any time, but it could cause problems for example - the original lock creator has a document locked and has made changes but not PUT them back. Supposing the new lock creator UNLOCKs the document, LOCKs it and keeps the lock for days, weeks etc. The new lock creator makes changes to the document, re-PUTs it and UNLOCKs it. The original lock creator still has their copy of the document with their changes, but cannot re-PUT them for all this time (weeks?). What are they suppose to do? They could discard their changes or after the new lock creator has UNLOCKed the document, the original lock creator may then be able to PUT their changes in (after weeks?). But then, there could be merge type problems or lost update type problems if they discarded their changes because they get fed up waiting, had to switch their client machine off etc. > Servers should > never allow users other than lock creaters to update a locked > resource, even > if they use the correct lock token. I know what this statement is meant to mean, but one could say this 2nd statement contradicts the 1st because the new lock creator is not the original lock creator. After all, look at the confusion "null resource" caused. > - Lock Owner - > > Consensus: > (a) WHen client provides value for lock owner, server should > preserve this > value and not modify or overwrite it. When client does not > provide a value, > Server MAY provide a helpful value. Not sure what the server could provide here or how helpful it would be. What were people thinking of e.g. IP address of the client ? Agree with the first sentence though. > Idea: RFC2518 maybe should add "lock creator" value to lock > information, in > order to reduce confusion, and specify that lock creator is > server-calculated (protected) Disagree with this. There is no need to introduce a new property. Also, this is an implementation detail and may give sensitive information away e.g. an OS account name, which might be retrieved say with PROPFIND or returned in a (failed) LOCK request. The lock owner property is sufficient as it can contain contact information e.g. tel no, email addy etc. Clients should be using this when issuing LOCK requests. Fix the clients, don't change the RFC. > > Lisa > Regards Shaun Hall Xerox Europe
Received on Wednesday, 15 August 2001 04:54:14 UTC