Re: GULP vs RFC251bis, was: [Bug 54] Locks vs multiple bindings

+1 for Julian's suggestion about how to make progress.

In particular, I suggest we provide some kind of deadline for
identifying such instances of where GULP incorrectly describes
current locking behavior of the majority of current implementations.
If no such instances are identified I suggest we just adopt
the GULP text as currently written, so that we can close down
this thread and make progress on the remaining other issues.

Cheers,
Geoff

Julian wrote on 12/16/2005 02:42:13 PM:

> During today's teleconference, we came across another disagreement, 
> where it was questioned that GULP's [1] statement about URLs being 
> protected by a LOCK:
> 
> " - If a request causes a directly locked resource to no longer be
>      mapped to the lock-root of that lock, then the request MUST
>      fail unless the lock-token for that lock is submitted in the
>      request.  If the request succeeds, then that lock MUST have been
>      deleted by that request."
> 
> indeed reflects what servers do.
> 
> I just tested a MOVE on a collection containing one locked child 
> resource, and 4 out of 4 tested servers (Xythos, Apache, MS IIS 5.1, SAP 

> KM) rejected the request. All except IIS returned a 423 (IIS returned a 
> 207 with a 423 status contained).
> 
> Thus I'll conclude that GULP here indeed describes what servers do (test 

> case attached).
> 
> We can probably go on like this for a long time, but at this point I 
> don't see any way to make progress here unless those who dislike GULP 
> come up with concrete examples of where it fails to describe running 
> code, and then optimally make suggestions about how to fix this.
> 
> Best regards, Julian
> 
> 
> [1] 
<http://lists.w3.org/Archives/Public/w3c-dist-auth/2005OctDec/1003.html>
> [attachment "url_protection.js" deleted by Geoffrey M 
Clemm/Lexington/IBM]