Re: LOCK Scenarios

<JC>
  BTW, I propose we use the phrases, "rooted at the URI"
vs "inherited at the URI/resource" when talking about
these locks.  As far as vocabulary goes, there are also
a few other cases that need vocabulary.  I'll save that
for a seperate note.
</JC>
<jra>
I don't know what either of these phrases mean. A resource is locked or
unlocked. A resource inherites any depth infinity lock of its parent collection,
no matter how it became a member of that collection.
</jra>
<JC>
As I said, I'll save the full vocabulary and lock/resource/URI
discussion for another note.  I'll
just say here that for discussing the differences between
the two proposals, we need terminology that describes
the situation where the two proposals differ.  The "Rooted"
phrase refers to that situation.  The situation where the
earlier LOCK request was originally (to simplify) at the
same URI that is now the destination of the MOVE.
</JC>


<jra>
I don't think the destination URL retains the lock of the resource that used to
be at that destination unless it just happens to have the same depth infinity
locked parent collection.
</jra>
<JC>
Right.  That's where there is a difference of opinion.
</JC>


<jra>
...But this would be a new lock with the timeout reset.
</jra>
<JC>
New lock?  Perhaps I didn't understand what you just said
above about "same.... parent".  Please run that by me again.
<JC>

Received on Wednesday, 18 August 1999 14:27:24 UTC