W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > July to September 1999

RE: [Moderator Action] Questions on Webdav Servers

From: Jim Whitehead <ejw@ics.uci.edu>
Date: Sun, 15 Aug 1999 16:16:17 -0700
To: Geoffrey Clemm <geoffrey.clemm@rational.com>, WebDAV WG <w3c-dist-auth@w3.org>
Message-ID: <NDBBIKLAGLCOPGKGADOJGEPKCCAA.ejw@ics.uci.edu>
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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 2 June 2009 18:43:51 GMT