RE: HOW_TO_IDENTIFY_LOCK_OWNER

   From: Daniel Brotsky [mailto:dbrotsky@adobe.com]

   I think there are a variety of client needs here.  These are
   probably a little too fuzzy to be called requirements :^), but it's
   the best I can do right now.

   1. This came up at the first interop, and most servers seemed to be
   compliant by the second interop:

   The <owner> part of a lock is to be completely controlled by the
   client.  The server MUST not alter it (i.e., lock discovery, if it
   returns the <owner> information, must return exactly equivalent XML
   to that in the LOCK request).

   There's a lot of discussion of why this is needed in the archives;
   the gist is that it's the only client-controlled XML that's always
   associated with a LOCK, so clients of a given ilk can use it to
   exchange conventional information with each other about the lock.

I agree.

   2. There's some well-known specification of "principal" in the
   sense of "authenticated user ID whose authorization is being used
   for the current request."  Probably this is a string of some kind,
   and probably there are localization issues so we will want this
   string to be in a known encoding (e.g., UTF-8) or else all
   mechanisms that return this string must be able to return the
   encoding.

In general, the user will not map 1-1 with a "principal", but rather
a user will "match" one or more principals.  Therefore I do not see
that it is feasible or desireable to try to identify a particular
principal for the current user.

   3. Clients need to know/be able to discover which "principal" they
   are.  I don't really know enough about the range of authentication
   schemes to understand whether clients can always know for sure what
   "principal" the server is associating with them based on the
   client-generated authentication header, or whether the client might
   simply have been given some set of opaque credentials and need the
   server to tell it which "principal" those credentials make it.

I believe this is the same as (2), and the same counter-arguments
apply.

   4. Clients need to know/be able to discover which "principal" owns
   a given lock, that is, which principal made the original lock
   request.

We did agree in an earlier thread that a "DAV:can-lock" and a
"DAV:can-unlock" privilege should be supported, so that an ACL
can indicate who can lock or unlock a resource.

But I disagree that it is necessary or useful to identify a principal
that "owns" the lock, since it is the DAV:can-lock and DAV:can-unlock
ACL that matters, and that is not determinable from the "principal"
that created the lock. 

   5. Clients need to know/be able to discover where the "root
   resource" of a lock is; that is, the resource on which the lock
   owner can do an UNLOCK of the right depth and get the lock
   released.

I agree.

So my set of requirements would be:

A) The DAV:owner field of the lock is under client control.

B) A DAV:can-lock and DAV:can-unlock privilege should be defined.

C) The root resource of a lock should be discoverable.

Received on Thursday, 10 January 2002 23:43:51 UTC