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

RE: Bindings, Locks, and MOVE

From: Slein, Judith A <JSlein@crt.xerox.com>
Date: Wed, 15 Sep 1999 11:32:53 -0400
Message-ID: <8E3CFBC709A8D21191A400805F15E0DBD24449@crte147.wc.eso.mc.xerox.com>
To: "'Kevin Wiggen'" <wiggs@wiggenout.com>, ccjason@us.ibm.com, w3c-dist-auth@w3.org
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:wiggs@wiggenout.com]
> Sent: Wednesday, September 15, 1999 1:01 AM
> To: ccjason@us.ibm.com; w3c-dist-auth@w3.org
> 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
> 
Received on Wednesday, 15 September 1999 11:33:28 GMT

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