Subject: RE: IETF meeting: Refreshing locks

From: "Clemm, Geoff" <[email-masked]>
Date: Sat, 23 Feb 2002 18:53:42 -0500

The paragraph referred to was in section 9.8:

   The timeout counter SHOULD be restarted any time an owner of the lock
   sends a method to any member of the lock, including unsupported
   methods, or methods which are unsuccessful.  However the lock MUST be
   refreshed if a refresh LOCK method is successfully received.

Unfortunately, I cannot remember the rationale for removing this
paragraph, although it might have been that servers aren't actually
doing this in practice?

Cheers,
Geoff

-----Original Message-----
From: Jason Crawford [mailto:[email-masked]]
Sent: Monday, February 18, 2002 7:01 PM
To: Julian Reschke
Cc: [email-masked]
Subject: IETF meeting: Refreshing locks

What does the following text from the SLC IETF meaning mean?

> Refreshing Locks....
>
> Consensus was to delete paragraph on lock refresh.
> Eric - clients seem to be expecting locks to hang around, when they
expire it causes problems.

------------------------------------------
Phone: 914-784-7569,   [email-masked]

---

From: Stefan Eissing <[email-masked]>
Date: Mon, 25 Feb 2002 09:58:21 +0100

> paragraph, although it might have been that servers aren't actually

There were several issues in this:
1. unsupported methods might not even be seen by the WebDAV server
    application (or recognized as WebDAV methods).
2. Refreshing locks on PROPFIND by _any_ client (PROPFIND does not
    check on If: headers) will give unpredictable timeout behavior.
    Checking with PROPFIND if a lock is still there has counterproductive
    side effects.

That's the, most likely incomplete, list I remember.

//Stefan