Re: Issue 079_UNLOCK_BY_NON_LOCK_OWNER

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:31:40 UTC