- From: Geoffrey Clemm <geoffrey.clemm@Rational.Com>
- Date: Wed, 11 Aug 1999 16:29:36 -0400
- To: "Jim Whitehead" <ejw@ics.uci.edu>, "WebDAV WG" <w3c-dist-auth@w3.org>
From: Jim Whitehead <ejw@ics.uci.edu> >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
Received on Wednesday, 11 August 1999 16:33:28 UTC