Our existing code only uses LOCK to (1) get a new exclusive lock and
(2) to refresh the exclusive locks we own. We parse the lockdiscovery
response for a lock-token in both cases. I looked through the various
versions of our code and I *think* that it wouldn't matter if the
lockdiscovery response were not returned in the LOCK refresh
response, but without a server to test against, I cannot be sure.
So I agree with Geoff, but would add the requirement of returning the
lockdiscovery response for a LOCK refresh because it would be useful
for the same reasons you'd want the lockdiscovery response when a
lock is created (to get the locktoken, timeout value, etc). This
should not be a lock privacy problem because the client has proved it
knows about the lock via the If header in the request.
- Jim
On Nov 18, 2005, at 9:31 AM, Geoffrey M Clemm wrote:
>
> From a lock privacy perspective, putting all information about the
> newly created lock in the lockdiscovery response to a LOCK
> request is (of course) no problem, so requiring that is fine with me.
>
> Perhaps the new text could require that full information about a LOCK
> be returned in the lockdiscovery response to a LOCK, while information
> about other locks is optional in the lockdiscovery response to a LOCK.
>
> Cheers,
> Geoff
>
> Julian wrote on 11/18/2005 12:06:21 PM:
> >
> > Geoff, any input about how a server concerned with the privacy of
> lock
> > information would return the actual timeout value (as compared to
> the
> > one sent by the client)?