[Bug 229] GULP / Lock timeout discussion

http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=229





------- Additional Comments From lisa@osafoundation.org  2006-02-10 17:38 -------
I moved the Timeout text and found some additional issues with it.  The text as
it stood made timeouts rather advisory for servers to respect, because it
described the outcome passively ("the lock may be lost") rather than with a
normative statement ("the server SHOULD remove the lock").  I've taken a stab at
including normative text because I think this can affect interoperability.

For example, a client that allows advertised timeouts to expire ought to be
justified in believing that the lock should be gone and a new LOCK is required
or that other clients can now edit the resource.  The language about the lock
still being there should allow for wiggle room (e.g. we don't require
milli-second accuracy in lock cleanup) but not for completely ignoring timeout.



------- You are receiving this mail because: -------
You are the QA contact for the bug, or are watching the QA contact.

Received on Saturday, 11 February 2006 01:38:58 UTC