Re: GULP 5.6 vs issue UNLOCK_WHAT_URL (65)

Julian Reschke wrote:

> I just noticed that in
> 
> <http://lists.w3.org/Archives/Public/w3c-dist-auth/2004JanMar/0001.html>
> 
> we write...:
> 
>   "An UNLOCK request deletes the lock with the specified lock token.
>   The request-URL of the request MUST identify the resource that
>   is directly locked by that lock.  After a lock is deleted,
>   no resource is locked by that lock."
> 
> This was a change to the previous GULP version. However, the discussion 
> attached to issue entry UNLOCK_WHAT_URL 
> (<http://www.webdav.org/wg/rfcdev/issues.htm>) seems to indicate that we 
> agreed upon allowing any URL protected by the lock to be used as request 
> URL.
> 
> 1) We should agree on one of the two; and fix the other document 
> accordingly.
> 
> 2) RFC2518 seems to allow both interpretations:
> 
>    "The UNLOCK method removes the lock identified by the lock token
>    in the Lock-Token request header from the Request-URI, and all
>    other resources included in the lock."
> 
> 3) Back when I tested this, both Apache/moddav and Xythos were 
> implementing this, and so are we (I think). Microsoft IIS doesn't 
> support deep locks, so it's not relevant here.
> 
> Therefore it seems that we should undo that particular change from GULP 
> 5.5 for the sake of interoperability with older clients that may rely on 
> it (this seems to be harmless).

Adding to the confusion, I just find out that RFC2518bis-05 says it 
needs to be directly locked as well (well, I guess it *tries* to say 
that, see... 
<http://lists.w3.org/Archives/Public/w3c-dist-auth/2004AprJun/0115.html>).

Can we please make a decision *and* make sure that it's tracked on the 
issues list? An issues list that is not only out of sync but even 
contradicts the latest draft really doesn't help much :-)

Best regards, Julian

-- 
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760

Received on Monday, 31 May 2004 09:52:20 UTC