Subject: [Bug 229] GULP / Lock timeout discussion

From: [email-masked]
Date: Thu, 9 Feb 2006 14:34:17 -0800

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

[email-masked] changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         [email-masked][email-masked]

------- Additional Comments From [email-masked]  2006-02-09 14:34 -------
OK, I have reviewed all text regarding Timeout behaviour and found
the following problems:

- there's text in the Write Locks section about refresh and timeouts. Why? How
is it specific to write locks?
- furthermore, that text talks about a timeout response header. There is none.
- Section 10.7 talks about a restriction on the value range to either Seconds-*
or Infinite. As the grammar doesn't allow any other values anyway (anymore),
this can go. It was in the wrong section anyway,
- Section 6 and Section 10.7 were inconsistent (NORMATIVELY) about whether
servers must do cleanup of time-out locks (I think we should stick with ehat
RFC2518 said).

Fixed all of that, plus

- moved most of the discussion of timeout semantics into 6.6, 
- updated Changes section (Seconds-* and Infinite being the only allowed
syntaxes for Timeout)
- add some cross references

Changes at
<http://greenbytes.de/tech/webdav/draft-reschke-webdav-rfc2518bis-latest.html#rfc.issue.bz229>
and below:

Section 6.6., para. 1:
OLD:

    A lock MAY have a limited lifetime.  The lifetime is suggested by the
    client when creating or refreshing the lock, but the server
    ultimately chooses the timeout value.  Servers MUST remove locks
    reasonably soon after the timeout expires if the lock is not
    refreshed and given a new timeout.

NEW:

    A lock MAY have a limited lifetime.  The lifetime is suggested by the
    client when creating or refreshing the lock, but the server
    ultimately chooses the timeout value.
 
    The timeout counter MUST be restarted if a refresh lock request is
    successful (see Section 9.10.2).  The timeout counter SHOULD NOT be
    restarted at any other time.
 
    If the timeout expires then the lock may be lost.  Specifically, if
    the server wishes to harvest the lock upon time-out, the server
    SHOULD act as if an UNLOCK method was executed by the server on the
    resource using the lock token of the timed-out lock, performed with
    its override authority.  Thus logs should be updated with the
    disposition of the lock, notifications should be sent, etc., just as
    they would be for an UNLOCK request.
 
    Servers are advised to pay close attention to the values submitted by
    clients, as they will be indicative of the type of activity the
    client intends to perform.  For example, an applet running in a
    browser may need to lock a resource, but because of the instability
    of the environment within which the applet is running, the applet may
    be turned off without warning.  As a result, the applet is likely to
    ask for a relatively small timeout value so that if the applet dies,
    the lock can be quickly harvested.  However, a document management
    system is likely to ask for an extremely long timeout because its
    user may be planning on going off-line.
 
    A client MUST NOT assume that just because the time-out has expired
    the lock has been lost.  Likewise, a client MUST NOT assume that just
    because the time-out has not expired, the lock still exists.

Section 6.6., para. 2:
OLD:

    Clients MUST assume that locks may arbitrarily disappear at any time,
    regardless of the value given in the Timeout header.  The Timeout
    header only indicates the behavior of the server if extraordinary
    circumstances do not occur.  For example, a sufficiently privileged
    user may remove a lock at any time or the system may crash in such a
    way that it loses the record of the lock's existence.

NEW:

    Clients MUST assume that locks may arbitrarily disappear at any time,
    regardless of the value given in the Timeout header (Section 10.7).
    The Timeout header only indicates the behavior of the server if
    extraordinary circumstances do not occur.  For example, a
    sufficiently privileged user may remove a lock at any time or the
    system may crash in such a way that it loses the record of the lock's
    existence.  For this reason, clients are encouraged to also take
    advantage of ETags (Section 8.5) in order to avoid overlapping
    updates.

Section 7.7., para. 3:
OLD:

    A server may return a Timeout header with a lock refresh that is
    different than the Timeout header returned when the lock was
    originally requested.  Additionally clients may submit Timeout
    headers of arbitrary value with their lock refresh requests.
    Servers, as always, may ignore Timeout headers submitted by the
    client.  Note that timeout is measured in seconds remaining until
    expiration.

NEW:

    [[anchor17: There is no such thing as a Timeout response header.]]

Section 10.7., para. 3:
OLD:

    Timeout response values MUST use a Second value or Infinite.
 
    The "Second" TimeType specifies the number of seconds that will
    elapse between granting of the lock at the server, and the automatic
    removal of the lock.  The timeout value for TimeType "Second" MUST
    NOT be greater than 2^32-1.

NEW:

    The "Second" TimeType specifies the number of seconds that will
    elapse between granting of the lock at the server, and the automatic
    removal of the lock.  The timeout value for TimeType "Second" MUST
    NOT be greater than 2^32-1.

Section 10.7., para. 4:
OLD:

    The timeout counter MUST be restarted if a refresh LOCK request is
    successful.  The timeout counter SHOULD NOT be restarted at any other
    time.
 
    If the timeout expires then the lock may be lost.  Specifically, if
    the server wishes to harvest the lock upon time-out, the server
    SHOULD act as if an UNLOCK method was executed by the server on the
    resource using the lock token of the timed-out lock, performed with
    its override authority.  Thus logs should be updated with the
    disposition of the lock, notifications should be sent, etc., just as
    they would be for an UNLOCK request.
 
    Servers are advised to pay close attention to the values submitted by
    clients, as they will be indicative of the type of activity the
    client intends to perform.  For example, an applet running in a
    browser may need to lock a resource, but because of the instability
    of the environment within which the applet is running, the applet may
    be turned off without warning.  As a result, the applet is likely to
    ask for a relatively small timeout value so that if the applet dies,
    the lock can be quickly harvested.  However, a document management
    system is likely to ask for an extremely long timeout because its
    user may be planning on going off-line.
 
    A client MUST NOT assume that just because the time-out has expired
    the lock has been lost.  Likewise, a client MUST NOT assume that just
    because the time-out has not expired, the lock still exists (and for
    this reason, clients are strongly advised to use ETags as well).

NEW:

    See Section 6.6 for a description of lock timeout behavior, and
    Section 9.10.2 for the description of lock refresh requests.

Appendix E., para. 27:
OLD:

 E.3.  Changes Notable to Client Implementors

NEW:

    REMOVED: the TimeoutVal syntax (Timeout request header and "timeout"
    XML element) isn't extensible anymore; only Seconds-* or Infinite are
    allowed.
 
 E.3.  Changes Notable to Client Implementors

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