Re: LOCK Scenarios

<JC>
In my previous response I voted against retaining a lock for /x/y/z.html.
One other thing I'd like to check...   Is it possible to do a MOVE
operation that replaces a binding to a collection with a binding to a
non-collection?  (This relates to your discussions with JimW over
/x/y/ and /x/y being interchangeable.)
<jra>
You can MOVE a resource over a collection or the other way around. The semantics
are that the overwrite header must be "T", and if so the destination is deleted
before the MOVE.
</jra>

If so...  there might not even be a collection at /x/y after the move
which makes keeping a null lock at /x/y/z.html even odder.  To date,
all null locks have had collection resources at their PARENT URI.
<jra>
All DAV resources have collection resources at the PARENT URI.
</jra>

I'd vote that for now we limit the things so that the only lock that we'd
consider retaining is at the DELETE's request URI.  Any ancestor lock
will be retained.  Any descendent lock will not.
<jra>
Yet another special case. The current spec has no such special cases. Inheriting
a depth infinity lock from the destination parent collection is not a special
case, its part of what it means to be a memeber of a collection.
</jra>

Note: all of our discussion retaining destination locks also applies
to an overwrit'ing BIND.
</JC>

Received on Tuesday, 17 August 1999 16:21:22 UTC