W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > July to September 2001


From: Greg Stein <gstein@lyra.org>
Date: Thu, 13 Sep 2001 18:34:59 -0700
To: Jason Crawford <ccjason@us.ibm.com>
Cc: Webdav WG <w3c-dist-auth@w3c.org>
Message-ID: <20010913183459.R27051@lyra.org>
I don't think it is right to allow somebody other than the lock owner to
unlock the thing, but the position below does give me room to refuse to do
so. Thus, I am comfortable with that position.


On Wed, Sep 05, 2001 at 10:54:26AM -0400, Jason Crawford wrote:
> Hey WebDAV'ers,
>    A couple of the disagreeing parties (JimW, GeoffC, LisaD) put there
> heads together to come up with a compromise on the issue of allowing
> non-lock owners to UNLOCK a resouce.  The compromise is that the following
> items should be said in the spec.
> - A server MAY allow principals other than a lock owner to unlock a
> resource
> -  If a server supports the unlocking of a resource by someone other than
> the lock owner, this capability SHOULD be under access control.
> - There is a tradeoff in allowing non-owners of a lock to unlock a
> resource.  It can be beneficial to allow non-lock owners to perform UNLOCK
> requests because it allows the adminstrator of the server to configure the
> server to grant longer lock timeouts because the administrator knows that
> there is a process in place to allow users to deal with forgotten locks
> left by other users.  On the other hand, a disadvantage of unlocking
> someone else's lock is that can create a situation where two users are
> working on modifications to the same resource at the same time which can
> result in a client having to perform an merge that wasn't previously
> planned.
> If we have a consensus around this, the wording that we will use will be
> very close to this.   If you have any comments on the position or wording,
> please speak up.
> J.
> ------------------------------------------
> Phone: 914-784-7569,   ccjason@us.ibm.com

Greg Stein, http://www.lyra.org/
Received on Thursday, 13 September 2001 21:32:29 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:01:23 UTC