RE: timeout types

Bill Carpenter writes:
> RFC-2518, example in section 8.10.8, and description of
> DAV:lockdiscovery in section 13.8 mention a "timeout type" for a
> LOCK.  As far as I can tell, the example doesn't show any kind of
> "timeout type" (particularly the one it says it shows), and I don't
> see a description of "timeout type" elsewhere in RFC-2518.
>
> Perhaps the "timeout type" is a holdover from an earlier draft and
> just needs an editorial cleansing?

Well, "timeout type" is used slightly inconsistently within the spec.  In
section 9.8, which defines the Timeout request header, there is a TimeType
BNF production which describes the syntax of the # of seconds the lock will
last, in addition to having an "Other" production, which is intended to
allow extensibility.  So this is one meaning for "timeout type" -- the
TimeType within the Timeout request header.  It is this sense of "timeout
type" that is used in section 13.8.

During the creation of the spec., we had discussions about whether to
support different kinds of lock refresh policies, and potentially having the
ability to say whether the timeout was absolute, or could be refreshed by
actions on the resource.  In the end, the spec. states that locks should be
refreshed by actions on the resource by the lock owner, but this hasn't been
widely implemented (to the best of my knowledge), since it adds a fair
performance penalty to all operations.  There is currently an item on the
DAV issues list "LOCK_REFRESH_BY_METHODS" that suggests the current
SHOULD-level requirement for refreshing the lock timer based on actions by
the lock owner should be removed.  However, it is this notion of locks being
refreshed by user activity that results in the mention of "activity-based
timeout policy" in 8.10.8.

- Jim

Received on Monday, 24 January 2000 14:01:03 UTC