Subject: timeout types

From: [email-masked] (WJCarpenter)
Date: Fri, 21 Jan 2000 12:18:47 -0800

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?
-- 
[email-masked]   (WJCarpenter)           PGP
[email-masked]                    0x91865119
38 95 1B 69 C9 C6 3D 25  73 46 32 04 69 D6 ED F3

---

From: Jim Whitehead <[email-masked]>
Date: Mon, 24 Jan 2000 10:57:00 -0800

> 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

---

From: "Kaelin Colclasure" <[email-masked]>
Date: Mon, 24 Jan 2000 11:18:40 -0800

----- Original Message -----
From: Jim Whitehead <[email-masked]>
To: WJCarpenter <[email-masked]>; <[email-masked]>
Sent: Monday, January 24, 2000 10:57 AM
Subject: RE: timeout types

> type" that is used in section 13.8.

Are you familiar with the "Lease" technique which I first encountered in
Sun's specifications for Jini?

<http://www.sun.com/jini/specs/lease101.html>

Leases represent a very intuitive (IMO) approach to addressing issues of
resource reservation / locking in distributed architectures. While this
particular specification is of course for a Java implementation of the
concept, there's no reason the idea couldn't be incorporated into a
protocol like WebDAV.

> timeout policy" in 8.10.8.

For all the reasons you cite, and *particularly* because the loosely
specified semantics of "implicit" refreshes breed interoperability
problems, a lease-like mechanism may be worth investigating.

-- Kaelin

---

From: Jim Whitehead <[email-masked]>
Date: Mon, 24 Jan 2000 11:47:53 -0800

> concept, there's no reason the idea couldn't be incorporated into a

Well, I was not familiar with Jini leases, so I took a quick look through
the spec. you referenced.  As near as I can tell, there are many
similarities between the semantics for Jini leases and WebDAV locks.  Jini
leases allow an object to request a lease that lasts forever, or for a
specific time period, similar to WebDAV locks which can be requested for a
specific time period in seconds, or with the value "Infinite".  Jini leases
can be refreshed, as can WebDAV locks, by re-requesting the lock. Jini
leases can be canceled before the time period ends, as can WebDAV locks,
using the UNLOCK method.

Was there some specific Jini lease semantic that you particularly think
WebDAV would benefit from?

- Jim

---

From: "Kaelin Colclasure" <[email-masked]>
Date: Mon, 24 Jan 2000 12:01:08 -0800

----- Original Message -----
From: Jim Whitehead <[email-masked]>
To: Kaelin Colclasure <[email-masked]>; <[email-masked]>
Sent: Monday, January 24, 2000 11:47 AM
Subject: RE: Jini Distributed Leasing Specification (was Re: timeout types)

> WebDAV would benefit from?

Yes.

 a) You can request an "infinite" lease, but you must be prepared for the
    server to return to you instead a finite lease. You must then renew that
    lease before it expires if you want it to persist without interruption.
 b) The renewal of the lease is an explicit action on the part of the
client,
    and is required to occur within a specific time interval. There is no
    implicit anything.

This is, IMHO, significantly less complicated to implement robustly and
correctly than implicit renewal. And of course, truly infinite locks are
highly suspect in a distributed environment. It could be argued that
leases shouldn't permit them at all -- but it suffices to interpret
"infinite" to mean "the longest period a server chooses to tolerate
possibly holding a resource for a client that's never coming back."

-- Kaelin

--
Become a Venture Technologist... <http://www.everest.com/careers/>