- From: <bugzilla@soe.ucsc.edu>
- Date: Thu, 9 Feb 2006 14:34:17 -0800
- To: w3c-dist-auth@w3.org
http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=229
julian.reschke@greenbytes.de changed:
What |Removed |Added
----------------------------------------------------------------------------
AssignedTo|julian.reschke@greenbytes.de|elias@cse.ucsc.edu
------- Additional Comments From julian.reschke@greenbytes.de 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.
Received on Thursday, 9 February 2006 22:34:26 UTC