- From: <ccjason@us.ibm.com>
- Date: Mon, 26 Jul 1999 21:47:36 -0400
- To: w3c-dist-auth@w3.org
<prev> > 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. </prev> Note: Although I don't think we deal directly on the topic of locks at the destination in the Adv Coll spec, 7.7 does seem to be in disagreement with the MOVE semantics of the Adv. Coll. proposal. If anyone feels strongly that section 7.7 should remain as is, I suggest that they do a read of the Adv Coll document and then express their opposition. I just don't want our Adv Coll work in this area to surprise anyone. We also should make sure that the Adv Coll document is *clear* on what should happen in this situation. My opinion is that the destination lock should go away as should the locks of any decendent nodes in the URI tree at the destination. I could be persuaded otherwise for a lock on the destination URI/resource specifically though. J.
Received on Monday, 26 July 1999 21:49:16 UTC