Subject: RE: Bindings, Locks, and MOVE

From: "Slein, Judith A" <[email-masked]>
Date: Wed, 15 Sep 1999 11:32:53 -0400

I like everything that you say here, but the MOVE / COPY TO cases raise a
red flag for me.  We claim in the bindings spec that the MOVE semantics we
present  is equivalent to the COPY + fixup + DELETE semantics defined in RFC
2518.  But I doubt it when I look at this case.

Leave aside for a minute intuitions about what should really happen, and
just see what would follow from the underlying semantic model:

Suppose we define MOVE as "remove the binding identified by the Request-URI
and add the binding identified by the Destination header".

Now consider your case: /a/b.html and /x/y.html both point to resource R,
and I have an exclusive write lock on /a/b.html.  User2 tries to MOVE
/c/d.html (which points to some other resource S) to /x/y.html.  It seems
this should be possible, because all that is happening is that the binding
y.html in collection /x/ is being replaced with one that binds to a
different resource.  Nothing happens to resource R.

But if we use the COPY + fixup + DELETE semantics for MOVE, resource S would
have to be duplicated, overwriting R.  And this would not be allowed,
because R is locked.

Of course, we can legislate this problem away by, for example, accepting
your proposal that a MOVE or COPY like this one fail no matter which
semantics you use.  But I'm afraid other cases will turn up that reveal
inconsistencies between the 2 models of MOVE.

--Judy

> -----Original Message-----
> From: Kevin Wiggen [mailto:[email-masked]]
> Sent: Wednesday, September 15, 1999 1:01 AM
> To: [email-masked]; [email-masked]
> Subject: RE: Bindings, Locks, and MOVE
> 
> 
> 
> Ahhh  OK so I take back some of my last post.  I am beginning 
> to see clearer
> now.
> 
> Correct me if I am wrong.
> 
> /a/b.html and /x/y.html both point to resource R via BINDS.
> 
> 
> 1)  I take out an "Exclusive Write" lock L1 on /a/b.html.  
> Once this is
> done, user2
> 
> - can READ /a/b.html and /x/y.html (GET)
> - cannot DELETE /a/b.html (LOCKED)
> - can DELETE /x/y.html (will simply remove the binding)
> - cannot PROPPATCH /a/b.html OR /x/y.html (Resource is LOCKED)
> - cannot PUT /a/b.html OR /x/y.html (Resource is LOCKED)
> - can COPY /a/b.html and /x/y.html
> - cannot MOVE /a/b.html (LOCKED)
> - can MOVE /x/y.html (will simply move the binding URI, resource not
> changed)
> - cannot LOCK /x/y.html OR /a/b.html (LOCKED)
> - can PROPFIND /x/y.html and /a/b.html (its a write lock)
> - cannot MOVE or COPY TO /x/y.html or /a/b.html (Destination 
> resource is
> LOCKED) Actually MOVE/COPY TO /x/y.html makes an interesting 
> point of do you
> A) Do the delete first which UNBinds the resource and then 
> complete the
> MOVE/COPY, or B) fail with resource LOCKED.  I think you have to do B
> otherwise you end up with 2 resources where you used to have 1.
> 
> 2)  I take out a "Depth-Infinity Exclusive Write" lock L2 on 
> /a.  Once this
> is done, user2
> 
> - can READ /a/b.html and /x/y.html (GET)
> - cannot DELETE /a/b.html (LOCKED)
> - can DELETE /x/y.html (will simply remove the binding)
> - cannot PROPPATCH /a/b.html OR /x/y.html (Resource is LOCKED)
> - cannot PUT /a/b.html OR /x/y.html (Resource is LOCKED)
> - can COPY /a/b.html and /x/y.html
> - cannot MOVE /a/b.html (LOCKED)
> - can MOVE /x/y.html (will simply move the binding URI, resource not
> changed)
> - cannot LOCK /x/y.html or /a/b.html (LOCKED)
> - can PROPFIND /x/y.html and /a/b.html (its a write lock)
> - cannot MOVE or COPY TO /x/y.html or /a/b.html (Destination 
> resource is
> LOCKED)
> 
> 3)  I take out a "Depth-Zero Exclusive Write" lock L3 on /a.  
> Once this is
> done, user2
> 
> - can READ /a/b.html and /x/y.html (GET)
> - cannot DELETE /a/b.html (/a's namespace is LOCKED)
> - can DELETE /x/y.html (will simply remove the binding)
> - can PROPPATCH /a/b.html and /x/y.html (the resource is NOT Locked)
> - can PUT /a/b.html and /x/y.html (the resource is NOT Locked)
> - can COPY /a/b.html and /x/y.html
> - cannot MOVE /a/b.html (/a's namespace is LOCKED)
> - can move /x/y.html (will simply move the binding URI, resource not
> changed)
> - can LOCK /x/y.html and /a/b.html (they are not Locked)
> - can PROPFIND /x/y.html and /a/b.html (its a write lock)
> - can MOVE and COPY TO /x/y.html and /a/b.html (resource not locked)
> 
> Is this correct??
> 
> Kevin
>

---

From: "Geoffrey M. Clemm" <[email-masked]>
Date: Wed, 15 Sep 1999 12:56:17 -0400

From: "Slein, Judith A" <[email-masked]>

<gmc/> The author of the statement that "MOVE is logically equivalent
to COPY+fixup+DELETE" (who will remain nameless although we all know
who he is :-) has publicly renounced this statement.  The problem of
course is the wonderfully undefined "fixup" stage.  *ANY* semantics is
acceptable for MOVE, for some definition of "fixup".  So let's see if
all is well for this case with some suitably defined value of "fixup".

<gmc/> It doesn't overwrite R.  A COPY to an existing resource will
either fail (if Overwrite=FALSE) or issue a DELETE on the destination
of the COPY.  The DELETE of /x/y.html succeeds just fine (since DELETE
is properly defined to just remove the binding named "y.html" from the
collection "/x"), the COPY proceeds, and then the "fixup" step
replaces the binding to the new resource created by the COPY with a
binding to R, and then a DELETE is issued on the request URL of the
MOVE, which then deletes the binding named "d.html" from the
collection "/c".

<gmc/> I believe there are no inconsistencies here ... just suitably creative
definitions of "fixup" (:-).

Cheers,
Geoff