RE: v6: 12.9 lockdiscovery

I just finished getting caught up on this thread -- it's giving me 
flashbacks to Design Team meetings held early last year...

Another way to justify the provision of lock tokens is by viewing them (in 
conjunction with the If-State-Match headers) as a mechanism that allows 
programs to reliably use locks in an environment where the locks may (but 
not frequently) disappear at any moment from a locked resource.  Locks can 
disappear due to administrator removal, or due to timeout.  Since HTTP does 
not have a notification mechanism, there is no way for a server to notify 
the user agent which took out the lock that the lock has disappeared.  If a 
program requires the lock to be present to guarantee freedom from data 
conflicts, it has to be able to inform the server, only perform this action 
if the lock still exists. Using the If-State-Match and lock token for the 
lock, the program is able to state, "only perform this action if the exact 
lock I took out still exists."

But, for this case, Dylan is arguing that only a weaker form of statement 
is required, namely, "only perform this action if *any* lock I took out 
still exists."  This, as Dylan points out, only requires authentication, 
rather than a lock token (lock identifier).

The generic justification for an identifier (like a lock token) is that 
there must be a need to individually address a particular object (like a 
lock).  As Dylan notes, for locks we currently have two pieces of 
identifying information, the principal's authentication credentials, and 
the lock token. Dylan's argument is that only the principal's 
authentication credentials are needed to identify a lock, that the lock 
token is redundant identification information.

Yaron argues that the multiple programs run by the same principal scenario 
shows why an extra piece of identifying information is needed to 
disambiguate between a program and a principal.  However, since Dylan 
doesn't agree this a compelling scenario, I'll show other cases where the 
principal's authentication credentials are not sufficient.

One case which quickly comes to mind is a future where there may be more 
than just write locks.  In this case, a principal can easily have more than 
one simultaneous lock (or a different type) active on a resource, and the 
lock token can be used to disambiguate between different locks of the same 
type.

Another argument in favor of lock tokens is their stability.  Since opaque 
lock tokens are guaranteed to be unique across space and time, they are 
arguably more stable than a principle's authentication credentials.  So, if 
a program is using authentication credentials to identify a lock and these 
credentials change (e.g., due to a weekly or monthly password change 
regime) then the lock identification information could be stale.  A lock 
token would not have this problem.

Plus, I really don't feel that implementing opaque lock tokens is that 
onerous.  Having read through Paul Leach's UUID/GUID specification, which 
includes C language source code for generating UUIDs, it appears quite easy 
to implement lock tokens.  Paul's spec. is precise and clear, it contains 
step-by-step descriptions of the algorithm to generate UUIDS, it contains 
sample source code, and there are existing implementations.  What more 
could anyone need?

- Jim


On Tuesday, February 03, 1998 4:37 PM, Dylan Barrell 
[SMTP:dbarrell@opentext.ch] wrote:
> Dylan, we provide a very specific example for why we believe that lock
> tokens are absolutely required.
>
> [Dylan Barrell]  As I said, the example is weak at best. If a user takes 
out a lock THEY KNOW THEY HAVE TAKEN IT OUT. If they then perform PUT with 
another application to that locked resource THEY KNOW WHY. The advantages 
of requiring  lock token just so that the application can then warn them 
that a lock exists on the resource (when it could do this without requiring 
the lock token) IS NOT WORTH THE EFFORT. My belief is that a standard sh  
ould have the minimum requirements to allow disparate systems to 
interoperate effectively. Lock tokens are not required in order to fulfill 
this requirement.

Received on Wednesday, 4 February 1998 17:47:05 UTC