W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > April to June 2004

Re: GULP 5.6 vs issue UNLOCK_WHAT_URL (65)

From: Julian Reschke <julian.reschke@gmx.de>
Date: Mon, 31 May 2004 15:51:39 +0200
Message-ID: <40BB386B.4040807@gmx.de>
To: w3c-dist-auth@w3.org

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

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

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