Subject: Re: [Moderator Action] Questions on Webdav Servers

From: "Geoffrey Clemm" <[email-masked]>
Date: Wed, 11 Aug 1999 16:29:36 -0400

From: Jim Whitehead <[email-masked]>

>Kevin Wiggen writes:
> ...
>> 3)  MOVE/COPY to a destination that is locked.  8.10.5 states "... a
>> successful DELETE of a resource MUST cause all of its locks to be
>> removed."
>> and 8.8.4 states that overwrite set to T will do a DELETE....
>> Then will the
>> LOCK on the destination be lost??  This seems wrong to me.  If the
>> destination is LOCKED, then after a MOVE/COPY which might delete the
>> resource, I would assume the resource is still locked.
>
>If the destination of a COPY/MOVE is locked, and you submit the lock token
>of the destination lock in the If header, then the intent of RFC 2518 is
>that the destination resource should be locked.  This is stated in the
>second paragraph of section 7.7.

I agree that section 7.7 makes it clear that if you are *inheriting* a lock
from
a collection that *contains* the destination, then that inherited lock is
valid following a COPY/MOVE.  This makes sense since the locked collection
still exists following the COPY/MOVE.  But I do not see anything in 7.7 (or
in 7.5) that
either states or implies that a lock that was on the destination itself
remains
following the COPY/MOVE.  So as currently written, I believe that the spec
supports
Kevin's interpretation.

Cheers,
Geoff

---

From: Jim Whitehead <[email-masked]>
Date: Sun, 15 Aug 1999 16:16:17 -0700

If this is the case, then RFC 2518 should be amended to make this so.  Our
intent was to ensure that locks at the destination stay active after
copy/move (provided the destination lock is given in the If header), whether
the lock is a singleton, or a hierarchy lock.

- Jim

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Geoffrey Clemm
> Sent: Wednesday, August 11, 1999 1:30 PM
> To: Jim Whitehead; WebDAV WG
> Subject: Re: [Moderator Action] Questions on Webdav Servers
>
>