Subject: rfc2518 issue: LOCK_REFRESH_BY_METHODS

From: "Jason Crawford" <[email-masked]>
Date: Fri, 10 Aug 2001 14:41:13 -0400

It sounds like we're winding down on the locknull discussions, so here's
the next issue....

Jim Amsden brought up the following issue.  I don't have a record of us
resolving it, so let's do that.

The specification requires a lock to be refreshed if any method is
executed, by anybody, on a locked resource.  This can cause some
performance problems.  More importantly, the semantics of this refresh do
not seem to be right -- why should a random GET by a third party cause all
locks to be refreshed?

The text in question seems to be:

   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.

In section 9.8 of RFC2518.

Also...

   contact information for the owner of the lock.  The server has an
   activity-based timeout policy in place on this resource, which causes
   the lock to automatically be removed after 1 week (604800 seconds).

in section 8.10.8 seems to be alluding to the same behavior.

Do we want to change 2518?

J.

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

---

From: "Jim Amsden" <[email-masked]>
Date: Fri, 10 Aug 2001 15:24:46 -0400

And there's the issue associated with lock owner (not the owner element of
the lock discovery which is a lock owner display name). Should the locked
resource be accessed by any principal who has the lock token, or only the
principal that issued the LOCK method to create the lock token. If any user
can issue a PROPFIND to get the DAV:lockdiscovery and therefore the lock
token, and then use that lock token to do anything to the locked resource,
the usefulness of WebDAV locking would be limited.

On the notion of refreshing locks, users create, refresh, and release
locks. The less the server does on their behalf the better. Having timeouts
on locks is fine, but let's keep it simple. A user locks a resource with a
timeout that generally represents how long they expect to keep the lock and
therefore limit access to the resource by others. To have this timeout
reset on every successful method invocation would make lock timeouts very
non-deterministic and much more difficult for users to predict what will
happen when. I think locks timeouts should only be refreshed when the user
says to refresh them.

                    Jason Crawford                                                                            
                                         To:     [email-masked]                                         
                    08/10/2001           cc:     [email-masked]                                           
                    02:41 PM             From:   Jason Crawford/Watson/IBM@IBMUS                              
                                         Subject:     rfc2518 issue: LOCK_REFRESH_BY_METHODS(Document link:   
                                         Jim Amsden)                                                          

                                                                                                              

Also...

J.

---

From: "Clemm, Geoff" <[email-masked]>
Date: Fri, 10 Aug 2001 17:24:31 -0400

I agree with Jim.  Timeouts should only be reset by an explicit
request to do so, not as a side-effect of a request that uses
the lock token.

Cheers,
Geoff

-----Original Message-----
From: Jim Amsden [mailto:[email-masked]]
Sent: Friday, August 10, 2001 3:25 PM
To: [email-masked]
Subject: Re: rfc2518 issue: LOCK_REFRESH_BY_METHODS

 

                    Jason Crawford

                                         To:     [email-masked]

                    02:41 PM             From:   Jason
Crawford/Watson/IBM@IBMUS                              
                                         Subject:     rfc2518 issue:
LOCK_REFRESH_BY_METHODS(Document link:   
                                         Jim Amsden)

 

Also...

J.

---

From: "Jason Crawford" <[email-masked]>
Date: Sat, 11 Aug 2001 19:51:02 -0400

Hey Geoff...

Could you make an explicit proposal as to how the spec should change?

BTW... I don't care if the server choses to do this or not.  I doubt
refreshing the lock creates a functional problem since I doubt a client
would be written to wait for a time out and choke if it didn't unlock the
resource.  OTOH, I don't see the point in encouraging servers to refresh
the lock either.   If a server developer/administrator discovers a reason
that this refreshing policy is good, they can use it, but we don't need to
encourage it since it might be pointless and costly.

 So my recommendation would be to silent on this... or perhaps somehow
express flexibility.

Anyway, perhaps you could suggest what change to 2518 you'd like... :-)

J.

---

From: "Clemm, Geoff" <[email-masked]>
Date: Sun, 12 Aug 2001 22:26:18 -0400

I'd just delete the paragraph in 9.8 that states:

The last sentence is redundant, since it is already specified in the
LOCK semantics.

Cheers,
Geoff

-----Original Message-----
From: Jason Crawford [mailto:[email-masked]]
Sent: Saturday, August 11, 2001 7:51 PM
To: Clemm, Geoff
Cc: [email-masked]
Subject: RE: rfc2518 issue: LOCK_REFRESH_BY_METHODS

Hey Geoff...

J.

---

From: "Jason Crawford" <[email-masked]>
Date: Tue, 14 Aug 2001 01:15:30 -0400

Sounds good to me Geoff.   Do we have any other comments?  Agreement?

-----------------------------------------------------------------------------------------------------------

Cheers,
Geoff

---

From: "Hall, Shaun" <[email-masked]>
Date: Mon, 20 Aug 2001 09:40:22 +0100

Agreed with Geoff.

We never liked the statement anyway :-) (could be abused too easily for a
start).

Shaun Hall
Xerox Europe

> Sent: 18 August 2001 20:05
> To: WebDAV (E-mail)
> Again.  I'd like at least one more supportive comment before 
> I file this
> one as resolved.    Please pipe up.  :-)
> 
> 
> --------------------------------------------------------------
> ---------------------------------------------
> 
> 
>