rfc2518 issue: LOCK_REFRESH_BY_METHODS

It sounds like we're winding down on the locknull discussions, so here's
the next issue....


Jim Amsden brought up the following issue.  I don't have a record of us
resolving it, so let's do that.

The specification requires a lock to be refreshed if any method is
executed, by anybody, on a locked resource.  This can cause some
performance problems.  More importantly, the semantics of this refresh do
not seem to be right -- why should a random GET by a third party cause all
locks to be refreshed?

The text in question seems to be:

   The timeout counter SHOULD be restarted any time an owner of the lock
   sends a method to any member of the lock, including unsupported
   methods, or methods which are unsuccessful.  However the lock MUST be
   refreshed if a refresh LOCK method is successfully received.

In section 9.8 of RFC2518.

Also...

   contact information for the owner of the lock.  The server has an
   activity-based timeout policy in place on this resource, which causes
   the lock to automatically be removed after 1 week (604800 seconds).

in section 8.10.8 seems to be alluding to the same behavior.


Do we want to change 2518?

J.

------------------------------------------
Phone: 914-784-7569,   ccjason@us.ibm.com

Received on Friday, 10 August 2001 14:58:30 UTC