RE: root of a lock, was HOW_TO_IDENTIFY_LOCK_OWNER

That is fine with me.

Cheers,
Geoff

-----Original Message-----
From: Julian Reschke [mailto:julian.reschke@gmx.de]
Sent: Monday, July 08, 2002 7:25 AM
To: w3c-dist-auth@w3.org
Subject: RE: root of a lock, was HOW_TO_IDENTIFY_LOCK_OWNER



> 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: Mon, 14 Jan 2002 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 09:51:37 UTC