Subject: Re: One lock per resource per person?

From: [email-masked]
Date: Fri, 15 Oct 1999 15:31:53 -0400

A principal can only have one lock on a resource. If the lock is exclusive, then
there can only be one. If the lock is shared, then getting another shared lock
would not give owning principal any further capability. I don't have the spec if
front of me, but I believe this is spelled out.

[email-masked] on 10/15/99 03:13:59 PM

To:   [email-masked]
cc:

Subject:  One lock per resource per person?

In an offline discussion, the following question came up...

   Is it possible for a single principle to have multiple locks per resource?

I'd like to hear some opinions... but here are some mental exercises...

Lock tokens were invented to deal with the situation where the left hand and the
right hand don't know what each other is doing.   Otherwise it would be
sufficient to be authenticated as the entity that owns the lock.  It's important
to actually hold the lock to demonstrate awareness of it.  (It's also why we
supposedly also have to be careful how we use lockdiscovery.)

This philosophy suggests that there can only be a single exclusive lock on a
resource.  No exceptions.  If the left hand and right hand really know that they
won't step on each other... they can simply use the same lock token.   Even the
owner of the existing exclusive lock can't get another of the same type.  I
suppose the one possible exception would be if they submit the existing lock
token.  Buf for now I'll suggest that there can only be one exclusive lock per
resource.  Period.

This leaves the case of shared locks.   I think the answer here is different.
We don't exclude different people from holding the same lock.  Why should we
exclude the right hand and left hand?  Also in the case of...

   /a/b

I believe PersonX can already shared depth lock /a/ and still have another
shared lock on /a/b.  So I believe it's already possible for one principal to
have multiple locks per resource.

Comments?

Do we require a modification to 2518?

------------------------------------------
Phone: 914-784-7569,   [email-masked]

---

From: [email-masked]
Date: Fri, 15 Oct 1999 16:34:33 -0400

I believe the spec implies what you say.  Feel free to double check that.  It
would be useful to know where it says/implies that... but I'm also suggesting
a change if that's what the spec says... not just asking what the spec says.

It does give new capability though.  It's the right hand/left hand thing.  Two
independent client tools using the same ID.  They both want to block writes to
(coincidentally) the same resource.  Sure the second locker could do a lock
discovery... but then they'd also have to work out who is the last one that
wants to release the the lock.  Remember... these are independent tools.  It
won't work without some cooperation.  And having multiple locks on the same
resource solves this problem neatly.

As my note says, it looks like the spec already supports this for inherited
shared lock to some degree.  If so, the issue then becomes... "Can the two
shared locks owned by the same entity be rooted at the same resource?"  I'm
suggesting they should.

J.

---

From: "Yaron Goland (Exchange)" <[email-masked]>
Date: Mon, 18 Oct 1999 16:52:09 -0700

Lock tokens were also made unique so that we could use them across
resources. For example, I may want to say "Only make this change to resource
A if resource B is still locked."

There were two ways to do this:

Way 1 - Specifying a URI/identifier pair, e.g. If: <http://foo/bar,
ickygladsfyu>
Way 2 - Require the lock identifier to be globally unique, e.g. if:
ook:dldifjsojeferfoo/bar/ickygladsfyu

The problem with Way 1 is that if the URI of the resource is ever handed
over to a different system that system may not necessarily be away of all
the identifiers that the previous owner issued. This same problem exists for
E-Tags.

We considered this a flaw in the system and fixed it by using Way 2,
requiring that all identifiers be globally unique. Given how cheap and easy
it is to generate GUIDs we didn't feel the requirement was particularly
onerous.

		Yaron (who is NOT reading the group, really, I'm not, if I
were I would be screaming bloody murder about the horrors Jeff wants to
visit upon our lock design but I'm not reading the group, I'm not damn it!)

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Mon, October 18, 1999 2:50 PM
> To: [email-masked]
> Subject: RE: One lock per resource per person?
> 
> 
> jw> The strongest requirement for globally unique lock tokens comes
> jw> from looking at the future where there could be multiple WebDAV
> jw> servers participating in a cooperative cluster.  In that case,
> jw> having globally unique lock tokens would prevent lock token
> jw> collisions.
> 
> Isn't this a quality-of-implementation issue?  If multiple servers
> need to access the same physical repository, a privately-arranged
> scheme can be used to keep them from colliding with each other
> (possibly even some server acting as a clearinghouse for doling out
> LOCK tokens).
> -- 
> [email-masked]   (WJCarpenter)           PGP
> [email-masked]                    0x91865119
> 38 95 1B 69 C9 C6 3D 25  73 46 32 04 69 D6 ED F3
>

---

From: [email-masked]
Date: Tue, 19 Oct 1999 16:15:24 -0400

Yes Chris, but this is locking, not checkout. We can cover your case in WebDAV
versioning and don't have to do it with locking. Locking is an access control
mechanism for serializing updates to a resource. It is not at all the same thing
as checkout.

"Chris Kaler (Exchange)" <[email-masked]> on 10/19/99 02:51:01 PM

To:   Jim Amsden/Raleigh/IBM@IBMUS, [email-masked]
cc:

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Friday, October 15, 1999 12:32 PM
To: [email-masked]
Subject: Re: One lock per resource per person?

<ja>
A principal can only have one lock on a resource. If the lock is exclusive,
then
there can only be one. If the lock is shared, then getting another shared
lock
would not give owning principal any further capability. I don't have the
spec if
front of me, but I believe this is spelled out.
</ja>

<ck/> I think this is too restrictive.  Using SCC systems today, I can
      create multiple shared locks against the same resource.  In
      general you can do this by "checking it out" multiple times, but
      the basic notion is that I may be engaged in parallel activities
      at my client even though I am the same principal.

---

From: [email-masked]
Date: Wed, 20 Oct 1999 10:05:07 -0400

<ck/> Using SCC systems today, I can

   It's very important to distinguish "multiple checkouts" from "shared
   locks".  Multiple checkouts are safe and do not suffer from any lost
   update problem.  Shared write locks are not safe, and you are
   susceptible to getting your update's trashed by anyone else that
   shares that lock.

True.  And I expect shared write locks aren't going to be used much because
they depend on cooperation between clients.  But shared read locks
(write blocking locks) should get used A LOT.  That and future
types of locks is really where support for multiple locks per resource
would get exercised.  But in the meantime, since we do support shared write
locks, I'd like to get this defined.

My original posting is at...

http://lists.w3.org/Archives/Public/w3c-dist-auth/1999OctDec/0071.html
  and
http://lists.w3.org/Archives/Public/w3c-dist-auth/1999OctDec/0075.html

Is there a problem with supporting it?  Does the proposed clarification
sound reasonable?  I'd really feel better if more folks spoke up.  Then we
could put this issue to bed.

---

From: [email-masked]
Date: Wed, 27 Oct 1999 23:26:31 -0400

Sure, I can agree with all of this too. What I was attempting to point out
though is that lock tokens by themselves don't do anything unless the
concurrent client applications do something with them. That is, having two
lock tokens by the same principal using concurrent applications is like
having no lock token at all. Either application, having a shared lock token
can do its update and overwrite the other. Its the one lock token scenario
that works, but only if the client applications are aware of how they got
the lock token, so they know there is a possibility that some other
application has one too. Even then doing something with this information is
up to the client, the server and protocol don't add anything. The multiple
authentication approach just makes the locks easier to differentiate.

In any case, potential overwrite conflicts resulting from multiple shared
locks must be managed by client applications using some out of band
mechanism. This is one of the trust levels spelled out in the spec. It
doesn't matter who has the multiple shared locks, only that they are
shared. So I don't know what having a second shared lock on a resource
allows principals to do that they couldn't do with a single lock.

Greg Stein <[email-masked]> on 10/27/99 05:18:38 PM

To:   Jim Amsden/Raleigh/IBM@IBMUS
cc:   [email-masked]

On Wed, 27 Oct 1999 [email-masked] wrote:
> What this implies is that a principal is really some unit of concurrent
> processing. That's the only way update conflicts can occur anyway.
However,
> WebDAV specifies the principal as a (potentially) authenticated user
agent,
> which is not generally a process. Of course it could be, but this is
> outside the scope of WebDAV. The current locking semantics leaves the
> responsibility of managing current processing by the same principle with
> the principle, not the protocol and server. The principle can use lock
> tokens to distinguish applications that got the token by locking vs. some
> other out-of-band means. The management of this is, and should be,
outside
> the scope of WebDAV.

I think you're using semantics as an excuse here. I do not read the same
behavior from the spec (I see the same principle as being able to get
multiple, shared locks); therefore, I think you're stating it [as above]
solely in a way to support your hypotheses.

> I would suggest that Gregs example would be better
> handled by the principal wanting to distinguish locks by application A
and
> B using two different authentication aliases.

NO. As a user, I am assigned a *single* authentication alias on the
server. In an NT environment, it is my domain\username; in a Kerberos
environment, it is my login user/ticket; etc. There is no easy way for the
user to just "well, I'll use a second alias to differentiate these." That
is out of the user's scope and reliant upon the network/security
administrator. I *really* don't think the admin is about to say "well,
let's see... they're going to use up to three apps simultaneously against
our DAV server, so I guess that I'll create three users for this person;
oh wait, but what if they want to run four apps? I guess that I tell the
person they can't do that." The admin isn't going to do this for any
number of reasons.

And the user? There is no way they're going to go through a separate
authentication processes with the server simply to use more than one app
at a time. As a user, one of the best things that I like about Windows is
that it automatically supplies my credentials to servers -- that I only
have to supply them once. In the Unix world, I'm starting to change over
to ssh to get similar functionality, but still..

Cheers,
-g

--
Greg Stein, http://www.lyra.org/

---

From: [email-masked]
Date: Fri, 29 Oct 1999 15:18:50 -0400

Sure, I can agree with all of this too. What I was attempting to point
out
  though is that lock tokens by themselves don't do anything unless the
  concurrent client applications do something with them. That is, having
two
  lock tokens by the same principal using concurrent applications is like
  having no lock token at all. Either application, having a shared lock
token
  can do its update and overwrite the other.

So can totally different principals.  This argument is not unique
to the issue of the same principal holding multiple locks on the same
resource.  I believe that was the issue we were trying to resolve.
More in a sec...

  Its the one lock token scenario
  that works, but only if the client applications are aware of how they got
  the lock token, so they know there is a possibility that some other
  application has one too.

Actually not much really works for shared *write* locks.  Not without the
clients identifying each other to insure that they get along with the
other lockers, cooperating with the other lockers, and coordinating via
another mechanism.  I consider shared write locks to be a poor example of
what shared locks can do but some other folks might find they offer an
opportunity to develop their own cooperative locking schemes.

As I said, I personally don't value shared write locks, but if someone
values them
between separate principal's, then they should also value them between
indepedent
applications using the same authentication credentials.  There is no
difference.

I feel shared *read* locks are more valuable, and  allowing independent
parts of the same prinicple create separate locks works very well for
shared
read locks and saves client code that would be necessary to work around
this if the server limitted things to one lock per principal.

And if some servers adopt Geoff's redirected locatable lock proposal (and
even if they don't).  A separate locatable lock class could
be invented whose only purpose is to track the location of a resource.
These
would also work very well if multiple independent applications using the
same
credentials were allowed to create locks.  And without allowing multiple
locks
by the same principal, they couldn't work reliably.

I don't know what other types of locks might be invented in the future, but
the general rules seems to be
that multiple independent applications using the same credentials should be
allowed to create *shared*
locks on the same resource.

<tangent>Although authentication is useful for ACL's, the authentication
part of the
locking support at this point only seems to be to insure that someone isn't
submitting someone else's token.
And in fact this whole locking system could work just fine with everyone
using the *same* credentials if no one
shared their tokens and the server didn't reveal them within the lock
discovery process.  (Servers appear to
have this option in 2518.)</tangent>

<tangent 2>
BTW, the locatable lock class I mentioned above is kind of interesting for
depth locks.  It gives you a way,
with URI protection, to declare that no resources can be removed from a
collection, but folks can add
resources to a collection.  This is unlike write locking the collection
because locking a collection blocks both
the addition and the removal of resources.  And depending if the depth
locking is dynamic or not also adds an
interesting twist to the semantics.  If dynamic, once added, it can't be
removed by other folks.  If static. other
principals can remove resources they've added.
</tangent>