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