- From: Julian Reschke <julian.reschke@gmx.de>
- Date: Mon, 8 Jul 2002 13:24:43 +0200
- To: <w3c-dist-auth@w3.org>
- Message-ID: <JIEGINCHMLABHJBIGKBCGEHHEOAA.julian.reschke@gmx.de>
> To: Daniel Brotsky <dbrotsky@adobe.com> > Cc: "Clemm, Geoff" <gclemm@Rational.Com>, w3c-dist-auth@w3c.org > Message-ID: <OF7C4220CB.830F87EE-ON85256B41.006F0EFA@pok.ibm.com> > From: "Jason Crawford" <ccjason@us.ibm.com> > Date: 2002年1月14日 15:19:50 -0500 > Subject: RE: root of a lock, was HOW_TO_IDENTIFY_LOCK_OWNER > > > > In addition to Geoff's answer: > > If you are an administrator trying to unlock a resource obtained by > > someone else, you have to be able to figure out which resource to > > unlock. You can't unlock an internal member of a collection that's > > locked by a depth-inifinity lock without knowing which collection was > > actually locked. > > CAN'T? (going back to an old discussion...) RFC2518, 8.11 says [1]: "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. If all resources which have been locked under the submitted lock token can not be unlocked then the UNLOCK request MUST fail. " So do we have agreement that *any* of the URIs affected by a deep lock can be used to do the UNLOCK operation? [1] <http://greenbytes.de/tech/webdav/rfc2518.html#METHOD_UNLOCK>
Received on Monday, 8 July 2002 07:25:15 UTC