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: Julian Reschke <julian.reschke@gmx.de>
Date: Sun, 04 Jul 2004 11:45:29 +0200
Message-ID: <40E7D1B9.7040701@gmx.de>
To: WebDAV <nnw3c-dist-auth___at___w3.org@smallcue.com>
Cc: Jason Crawford <ccjason@us.ibm.com>, Lisa Dusseault <nnlisa___at___osafoundation.org@smallcue.com>

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.
> ...


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.


<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
Received on Sunday, 4 July 2004 05:46:06 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:01:30 UTC