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 17:06:33 UTC