Call for consensus on UNLOCK Request-URI being lock root

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.

Part of the rationale for #2 in the original consensus was to make sure  
that clients understood the scope of the lock they were attempting to  
remove -- so that the entire collection, if previously marked as  
locked, would now be shown as unlocked, rather than just the resources  
covered by the Request-URI.

Please indicate your preference by July 6.

Lisa

On Jun 21, 2004, at 10:31 AM, Julian Reschke wrote:

>
> Lisa Dusseault wrote:
>
>> I'm fine with 1 and 2, but I don't understand problem #3.
>> What this text attempts to say is that the server SHOULD redirect an  
>> UNLOCK request to the correct URI if the UNLOCK request has the wrong  
>> URI for the lock token -- that's the ideal response.  If the server  
>> can't do that, then as Plan B, the server MAY [or SHOULD?] return a  
>> simple error.
>> What's wrong with a specification having a Plan B if the software  
>> can't do Plan A for some reason?  Returning errors is the typical  
>> Plan B anyway...
>> I agree the text needs a little more specifics about what kind of  
>> redirect -- suggestions?
>
> Well, if in the context of an HTTP related spec you talk about  
> "redirecting" something, many will read that as having to do with a  
> 3xx status code. I'm still not sure whether this is what you intend to  
> say or not.
>
> If, on the other hand, you're saying that the server SHOULD accept the  
> UNLOCK even if the request URI is only indirectly locked (and just do  
> the unlock then), then it doesn't make sense to add any more text. As  
> Geoff pointed out recently about text *I* did write, saying "server  
> SHOULD do 'x' and MAY do not('x')" is bad specification text; it only  
> confuses the audience.
>
> Anyway, quoting myself in
>
> <http://lists.w3.org/Archives/Public/w3c-dist-auth/2004AprJun/ 
> 0170.html>:
>
> "OK,
>
> here are some actual test results:
>
> a) Apache/moddav: allows UNLOCK on indirectly locked resources,
> b) Xythos: same,
> c) SAP Enterprise Portal: same,
> d) Microsoft IIS: no support for depth infinity locks.
>
> Thus the current text in the issues resolution "Resolved that you can
> specify any URL locked by the lock you want to unlock" does indeed
> reflect current implementation experience, and this is what spec
> revisions should be saying.
>
> Thus:
>
> 1) RFC2518bis should undo that change, and
> 2) GULP should be updated accordingly (I'll do that for my in-document
> copy of GULP at
> <http://greenbytes.de/tech/webdav/draft-reschke-webdav-locking- 
> latest.html#rfc.section.C>."
>
>
> ...and that's what I did with (a) my draft and (b) GULP (they both are  
> now consistent with what the issues list states as working group  
> consensus, see issue 65).
>
> Best regards, Julian
> -- 
> <green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
>

Received on Monday, 21 June 2004 13:38:03 UTC