Re: RFC-2518 LOCK-TOKEN: header

gmc> Section 6.3 of RFC-2518 states that you can get the lock token
gmc> through the lock discovery property:

Yeah, that's what I was thinking (especially as the lock discovery
property is the prescribed payload returned after a successful LOCK
request).  But Jim Amsden is right that that's not sufficient.

ja> That's because the active lock element of the lock discovery
ja> property does not contain the authentication id of the principal
ja> owning the lock.

gmc> I can find no authentication id defined or required by RFC-2518.

Yeah, you're right, too, and that's the problem.  The DAV:owner
property is just so much commentary by the LOCK requester.  It
explicitly has no bearing on the out-of-band authentication.  In
short, it can be a complete lie or completely irrelevant.  I think the
idea of DAV:owner was for human consumption, in case you want to track
down the LOCK owner and beat him/her with a stick until s/he releases
the LOCK.  It is by design not at all helpful to the server in
deciding whether the principal attempting a change is the LOCK holder
or not.

For exclusive LOCKs, you can assume from the lock discovery part of a
successful response that you got the applicable token mentioned.  For
shared LOCKs, you need the LOCK-TOKEN: header or some additional goop
in lock discovery conveying "authenticated" ownership.  For the
problem you mention, of multiple clients being run by the same
principal, there is no sanctioned, unambiguous way to do lock
discovery.

I agree that that is an issue needing a solution.
-- 
bill@carpenter.ORG   (WJCarpenter)           PGP
bill@bubblegum.net                    0x91865119
38 95 1B 69 C9 C6 3D 25  73 46 32 04 69 D6 ED F3

Received on Tuesday, 25 January 2000 14:09:50 UTC