Subject: Re: Call for consensus on UNLOCK Request-URI being lock root

From: Julian Reschke <[email-masked]>
Date: Sun, 04 Jul 2004 11:45:29 +0200

Julian Reschke wrote:

>> On Monday, 06/21/2004 at 10:37 MST, Lisa Dusseault  wrote:
>>  > This would overturn a consensus that had previously been determined at
>>  > a WG meeting that happened together with an interoperability meeting,
>>  > and the consensus was not challenged on the mailing list at that time.
>>  >
>>  > However, given that we have new information -- actual research!
>>  > (thanks) -- it does make sense to reconsider.
>>  >
>>  > WG members please indicate your old, new, and/ or current preference,
>>  > with reasons if they've not already been stated here:
>>  > 1. Should servers accept an UNLOCK request where the Request-URI names
>>  > any resource covered by the lock named in the lock token?
>>  > 2. Or, should servers redirect that UNLOCK request to the root of the
>>  > lock?
>>  > 3. If something else, please explain.
>>
>>
>> No strong preference so just go with what existing servers do.
> 
> 
> What do you mean by "redirect"? Please be more specific.
> ...

Lisa,

could you please define what you mean by "redirect"? Otherwise it won't 
be possible to say something about that option.

The other option we have is...

3. Server should reject the UNLOCK request if it doesn't address the 
directly locked resource.

As stated before, my preference is 1) for the simple reasons that

- this is what RFC2518 seems to say,
- this is what the issues list says as resolution,
- this is what GULP says after having it synced with the issues list and
- last but not least this is what servers indeed implement.

Julian

-- 
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760

---

From: Jason Crawford <[email-masked]>
Date: Sun, 4 Jul 2004 17:22:50 -0400

On Wednesday, 06/30/2004 at 08:37 ZE2, Julian Reschke wrote:
> Lisa Dusseault wrote:
> 
> > Yes, I read these today, but it was my interpretation that this 
testing
> > applied to the UNLOCK request.  What about LOCK request to refresh a
> > lock?  Does that also work on resources other than the lock root?  I
> > think servers would probably implement them the same way, but I was
> > curious whether you'd tested it explicitly.
> 
> Sorry. Related to this is
> 
<http://lists.w3.org/Archives/Public/w3c-dist-auth/2004AprJun/0191.html>,
> but that is about URLs in tagged "If" headers (where I found that
> servers do not seem to care).
> 
> Right now I'm saying...
> 
> "4.2.3.1 DAV:locks-refreshed postcondition
> 
> Timers associated with the those locks submitted in the "If" request
> header whose lock root is the resource identified by the Request-URI
> MUST be reset to their original value (or alternatively to the new value
> given in the "Timeout" request header)."
> 
> .basically because it seems nobody asked that question before.
> Assuming we'd find out that servers do not care for LOCK/refresh either,
> would we want to relax the spec text?

I'd relax the server side to accept refresh requests at any resource in 
the scope of the lock.   Unless given a reason though, I'd still encourage 
servers to send the refresh requests to the root of the lock.

J.

---

From: Julian Reschke <[email-masked]>
Date: Mon, 05 Jul 2004 01:16:49 +0200

Jason Crawford wrote:

> the scope of the lock.   Unless given a reason though, I'd still 
> encourage servers to send the refresh requests to the root of the lock.

I guess you mean "clients" in the second sentence.

The problem with this approach is that it makes little sense in a 
specification. If we say that servers SHOULD allow refresh against 
indirectly locked resources, it doesn't make sense to tell clients not 
to use it.

Best regards, Julian