Subject: Re: RFC-2518 LOCK-TOKEN: header

From: [email-masked]
Date: Mon, 31 Jan 2000 07:59:17 -0500

<geoff>
As is made clear in rfc2518, restricting use of a lock-token to the
principal that requested the lock does not provide overwrite protection,
since a principal can have *multiple* clients acting on his behalf.
The only reason for having lock-tokens is to provide overwrite protection,
and overwrite protection requires that a lock-token be only used by
the *client* (not the principal) that created the lock-token.
So the fact that your client is acting on behalf of a certain principal
is irrelevant to the proper use of lock-tokens.  What matters is that
a client only uses lock-tokens that it has issued.

Alternatively, if clients aren't going to restrict themselves to using
the lock tokens that they created via LOCK, but will grab any
lock-token that was created by their principal, then there is no
reason to have the complexity of lock-tokens in the protocol.
</geoff>
<jra>
We're getting there. The reason for associating the lock token with a
principal is to give that principal the flexibility of running concurrent
clients that may update the same resource. Since not all these clients
actually locked the resource but got the lock token some other way, they
are aware that there might be other clients that have the same lock token
and can warn the principal before using the lock token to update a locked
resource. To enforce Geoff's semantics, that is to make locks more than
just advisory, the lock token would have to be associated with the
particular client application, and HTTP does not support such an identity.
So although I agree that complete overwrite protection would require all
clients to get their own lock token, I don't think this is an acceptable
solution because:

1. locks are only advisory, any client, including clients of another
principal can simply ignore them and overwrite the resource.

2. enforcing such locks would require specific client identification which
is not possible using HTTP.

3. Multiple clients run by the same principal would have to get there own
possibly exclusive write locks which would limit data availability by a
single principal who likely knows what they are doing at the moment, and if
it is safe to proceed with an update. For example, the principal may be
running many concurrent clients, but only one of them is active at a time.
The others are all waiting for input.

So I think associating the lock token with a principal is a reasonable and
useful compromise. It doesn't give absolute and complete overwrite
protection for multiple current clients run by the same principal, but it
does guarantee overwrite protection between principals.

Note that GULP R8 is consistent with associating principals with lock
tokens:

R8: If a resource has a write lock with target ".", a request cannot
modify the body or dead properties of that resource unless the
principal of the request owns a write lock with target "." on that
resource and the token of that write lock is specified in an IF
header.

---

From: "Geoffrey M. Clemm" <[email-masked]>
Date: Mon, 31 Jan 2000 10:37:24 -0500

From: [email-masked]

   <geoff>
   ... if clients aren't going to restrict themselves to using
   the lock tokens that they created via LOCK, but will grab any
   lock-token that was created by their principal, then there is no
   reason to have the complexity of lock-tokens in the protocol.
   </geoff>

   <jra>
   We're getting there. The reason for associating the lock token with a
   principal is to give that principal the flexibility of running concurrent
   clients that may update the same resource.

A principal can run concurrent clients that may update the same resource,
whether or not a lock token is associated with a principal.

   Since not all these clients
   actually locked the resource but got the lock token some other way, they
   are aware that there might be other clients that have the same lock token
   and can warn the principal before using the lock token to update a locked
   resource.

So every time such a client does a PUT/PROPPATCH to a "locked" resource,
it pops up a warning message saying "this might overwrite updates pending
in other clients working on your behalf, but I have no idea whether it
does or not because we use each others' lock tokens".  This is not a
behavior for which I would deliberately design a protocol.

Alternatively, the clients could be written to first UNLOCK a resource that
was locked by some other client, and then that other client (whether it
belonged to you or some other principal) would know this has occurred as
soon as it tries to make its next update, and could then notify that other
client's user that a merge conflict has occurred because someone
UNLOCK'ed your lock.

   ...

As a side note, "shared locks" are just, well, to be blunt, silly.
RFC2518 says you can take out a shared lock if you are a "principal
with appropriate access".  But if you are a principal with appropriate
access, you should just UNLOCK the resource and take out your own
exclusive lock on it.  This gives you all the benefits of "shared
locks", without losing the overwrite protection of exclusive locks.
Perhaps "silly" is a bit harsh ... or perhaps it is not harsh enough (:-).

Now as for the limiting data availability, how does the need to first
UNLOCK a locked-by-another client resource limit data availability?
Your client confirms (by asking you) that you really want to "steal" the
resource from another client (using the DAV:owner field to give a more
informative message), then UNLOCKs the resource, and then LOCKs
the resource to get its own locktoken.

I believe that you are try to get ACL behavior out of locktokens ...
I'd prefer to use ACL's to get ACL behavior (:-).  An ACL lets
you control which principals have write access to a resource (to prevent
damage from "hostile" principals), while locktokens lets cooperating
clients avoid merge conflicts.  An ACL is resource based and associated
with principals; a locktoken is URL-based and associated with clients.

Associating a lock token with a principal is both too strong (it prevents
another principal with the same or higher access rights from authoring
that resource) and is too weak (it doesn't help avoid merge conflicts
between clients acting on behalf of the same client).

If this approach were consistent with our future direction (associating
ACL's with resources), I'd be more willing to accept it, but it isn't.
Requiring that only a principal that issued a LOCK can cancel that LOCK
will conflict with any attempts to allow a wider "trust" group for
that operation.

   tokens.

Yes, that has been fixed (:-).  All mention of a "principal" has been
removed from R8.

Cheers,
Geoff