Subject: RE: Raw meeting notes from WebDAV WG meeting

From: "Jim Whitehead" <[email-masked]>
Date: Thu, 20 Mar 2003 13:09:12 -0800

Jason Crawford writes:
> <<
> * Discussion of "First problem" slide. What should be the behavior on
>   a LOCK on an indirectly locked resource? Should the lock remove the
>   entire depth lock, or should it be redirected, or should it fail?
>   Rough consensus for failure, error code to be determined later.
> >>
> Jim, could you publicly clarify this one.  I'm not sure what it's refering
> to.

Sure. For example, say you have the following set of resources:

         C1
       / | \
      a  C2 b
         / \
        d  e

C1, C2 are collections
a, b, d, e are non-collection resources
C1 contains a, C2, b
C2 contains d, e

If a Depth infinity lock is taken out on C1, using the terminology from the
meeting (really from Geoff Clemm's GULP proposal), resource C1 is directly
locked, and resources a, C2, b, d, e are indirectly locked (that is, they
were not the target of the LOCK request).

Given this terminological background, the question is, what is the behavior
of "UNLOCK" (the raw meeting notes are in error -- they say LOCK, and should
say UNLOCK) if applied to any of a, C2, b, d, or e? The three choices
discussed were:

1) remove the entire depth lock (i.e., is equivalent to an UNLOCK on C1)
2) be redirected to C1 using HTTP redirection (3xx)
3) fail (4xx)

The rough consensus in the meeting was that the response should fail (choice
#3).

- Jim

---

From: "Julian Reschke" <[email-masked]>
Date: Thu, 20 Mar 2003 22:34:26 +0100

> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Jim Whitehead
> Sent: Thursday, March 20, 2003 10:09 PM
> To: WebDAV
> Subject: RE: Raw meeting notes from WebDAV WG meeting
>
>
>
>
> Jason Crawford writes:
> > <<

In theory, this makes a lot of sense (UNLOCK should be applied to the URL to
which the original LOCK request was sent).

In practice, old clients that want to break a lock (after finding it using
lock discovery) may get into trouble by that change (if it is a change),
because in RFC2518, there was no cheap way to find the root of a lock.

Note that issue "UNLOCK_WHAT_URL" (on the issues list) says that you can use
any of the URLs protected by the lock.

Julian
--
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760