Subject: Webdav issue: UNLOCK_BY_NON_LOCK_OWNERS

From: "Jason Crawford" <[email-masked]>
Date: Wed, 15 Aug 2001 15:03:28 -0400

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,   [email-masked]

---

From: "Jason Crawford" <[email-masked]>
Date: Mon, 20 Aug 2001 23:57:02 -0400

It sounds like we might have consensus opinion that the power to unlock
someone else's locked resource should be under ACL control.   Could someone
that feels strongly about this propose a wording and placement in 2518 that
makes this proposal concrete?

Thanks,

J.

---

From: "Clemm, Geoff" <[email-masked]>
Date: Tue, 21 Aug 2001 12:40:26 -0400

OK, by me.  If we do, we probably should have separate "lock" and "unlock"
privileges.
But I'd be happy to add this in later, if it is at all contentious.

Cheers,
Geoff

-----Original Message-----
From: Eric Sedlar [mailto:[email-masked]]
Sent: Tuesday, August 21, 2001 11:35 AM
To: Webdav WG
Subject: RE: Webdav issue: UNLOCK_BY_NON_LOCK_OWNERS

Should we define an UNLOCK privilege as a part of the ACL spec?

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Clemm, Geoff
> Sent: Monday, August 20, 2001 9:19 PM
> To: Webdav WG
> Subject: RE: Webdav issue: UNLOCK_BY_NON_LOCK_OWNERS
>
>
> Well, that's a really easy change, i.e. all you have to do is
> absolutely nothing (:-).  Currently, section 11 in 2518 places
> no constraints on who can do an UNLOCK operation (i.e. if you
> can discover the lock token, you can request an UNLOCK).  The ACL spec
> introduces ways to constrain who can do an operation.  So we're done (:-).
>
> Cheers,
> Geoff
>
> -----Original Message-----
> From: Jason Crawford [mailto:[email-masked]]
> Sent: Monday, August 20, 2001 11:57 PM
> To: Webdav WG
> Subject: RE: Webdav issue: UNLOCK_BY_NON_LOCK_OWNERS
>
>
>
>
>

---

From: "Clemm, Geoff" <[email-masked]>
Date: Tue, 21 Aug 2001 14:36:47 -0400

I'd probably avoid the whole "when is a checkout like a lock"
discussion.  They are pretty much orthogonal concepts, where
a checkout takes an unwriteable thing, and makes it writeable
(or makes a writeable copy of it), while
a lock takes a writeable thing and limits who can write to it.

So locking a checked-out thing can be a sensible thing to do
(i.e. now that it is writeable, you want to limit
who can write to it), and even locking a checked-in thing can
be sensible (if you want to limit who can update the live
properties that are affected by locking but are not affected
by the resource being checked in).

Cheers,
Geoff

-----Original Message-----
From: Eric Sedlar [mailto:[email-masked]]
Sent: Tuesday, August 21, 2001 1:33 PM
To: Jason Crawford
Cc: Webdav WG
Subject: RE: Webdav issue: UNLOCK_BY_NON_LOCK_OWNERS

Well, checkout doesn't allow things to timeout, nor can you grab
a resource checked out into another workspace the way you can grab
somebody else's lock.

> Sent: Sunday, August 19, 2001 9:20 AM
> To: Eric Sedlar
> Cc: Webdav WG
> <<
> The other issue, Geoff, is that people are using LOCK as a poor person's
> CHECKOUT, also assuming that LOCK's won't timeout.
> >>
> I agree.
> 
> <<
>   The RFC2518 revision
> should clearly state that LOCKs aren't to be used for this purpose.
> >>
> ???? - I assume the purpose of locking is to avoid lost updates.  What is
> the distinction between a "poor man's CHECKOUT"  and "avoidance 
> of the lost
> update problem"?   In the absense of actual versioning, aren't they the
> same?
> 
> J.
> 
> 
>