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: Geoffrey M Clemm <geoffrey.clemm@us.ibm.com>
Date: Mon, 31 May 2004 19:17:44 -0400
To: w3c-dist-auth@w3.org
Message-ID: <OF919D205C.EBB830FD-ON85256EA5.007FC52E-85256EA5.007FF91D@us.ibm.com>
Changing back is fine with me.
Cheers,
Geoff

Julian wrote on 05/31/2004 09:13:33 AM:
> 
> Hi,
> 
> 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).
> 
> Best regards, Julian
> 
> -- 
> <green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
> 
Received on Monday, 31 May 2004 19:18:21 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 2 June 2009 18:44:06 GMT