W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > July to September 2004

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

From: Jason Crawford <ccjason@us.ibm.com>
Date: Sun, 4 Jul 2004 17:22:50 -0400
To: Julian Reschke <nnjulian.reschke___at___gmx.de@smallcue.com>
Cc: <nnw3c-dist-auth___at___w3.org@smallcue.com>
Message-ID: <OF4E8CD666.4FA761EB-ON85256EC7.0074C44E-85256EC7.007573DB@us.ibm.com>
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.
Received on Sunday, 4 July 2004 17:23:24 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 2 June 2009 18:44:06 GMT