RE: [Moderator Action] Questions on Webdav Servers

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: w3c-dist-auth-request@w3.org
> [mailto:w3c-dist-auth-request@w3.org]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
>
>
> 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 Sunday, 15 August 1999 19:21:59 UTC