Subject: Bindings, Locks, and MOVE

From: "Slein, Judith A" <[email-masked]>
Date: Thu, 2 Sep 1999 10:23:22 -0400

The authoring team for the bindings spec had a discussion of locks and MOVE
in the context of bindings, and wants to test its conclusions with the
mailing list members.  (For a complete record of the discussion, see the
minutes of 8/31/99, accessible from
http://www.ics.uci.edu/pub/ietf/webdav/.)

AGREED: 
For MOVE, if the source resource is locked (the lock is not inherited from
a parent collection), the lock moves with it to the destination.  If the 
destination resource is locked (the lock is not inherited from a parent
collection), its lock is lost.  
For MOVE, if it's the parent collections that are locked, the resource
being moved inherits the lock of the destination collection.
If a collection is MOVEd, and there are some locked resources in that
collection, the locks on those resources get moved.
We don't require support for cross-server MOVEs where the source resource
is locked, but we will define an optional lock header for use in
responses, so that the destination server can change the lock token and
return the new token with its response.  If the server allows a cross-
server MOVE but elects not to return a lock token value, the client
can do lock discovery to find it out. 
If a cross-server MOVE is allowed in a case where there are multiple
bindings to the source resource, and the source resource is locked, the
result will be that the resource is locked on both servers with the same
lock token in both places.  (If the same lock token cannot be used, the
MOVE must fail.)
For COPY, any locks at the destination are deleted, and no new locks are
created at the destination.  After the COPY, there will be no locks at
the destination except what is inherited from above.

This is a reversal of the position taken in RFC 2518.

Most people's intuition is that a MOVEd resource is the same resource, with
the same state (including its lock state).

The only rationale that has been presented for having locks be lost after a
MOVE is the case of cross-server MOVEs.  The source server and destination
server may use different URI schemes for lock tokens, so that the
destination server may be unwilling to keep the same lock token for the
MOVEd resource.

We can make support for cross-server MOVEs of locked resources optional, and
allow the destination server to replace the lock token with a different lock
token.  We'll provide a response header for it to use to report the new lock
token.

AGREED: We'll change the language related to protecting the
Request-URI to SHOULD.  We intend this to protect the entire path,
including the final segment.  This does impact the definition of write
locks in RFC 2518, which will have to change.  It's no longer that a
write lock MUST prevent MOVE and DELETE, but that it SHOULD prevent
them.

This discussion began with Yaron's comment that saying that "it MUST NOT be
possible for a principal other than the lock owner to make a locked resource
inaccessible via the URI mapping used to lock the resource" is too strong.
It may make sense for write locks as defined in RFC 2518, but may not make
sense for other sorts of locks that don't restrict MOVE and DELETE.

The user expectation would be that the Request-URI used to lock the resource
would continue to work for the duration of the lock, so we should go as far
as is practical toward protecting the Request-URI.

Locks can disappear anyhow due to administrator actions, and it is quite
unlikely that anyone will interfere with the Request-URI while a lock is in
force, so it's ok to weaken the normative language from "MUST NOT" to
"SHOULD NOT".

But we want to be consistent for the whole Request-URI.  That would mean
weakening the definition of write lock in RFC 2518, so that a write lock
only SHOULD prevent other principals from MOVE or DELETE on the locked
resource, not MUST.

--Judy

Judith A. Slein
Xerox Corporation
[email-masked]
(716)422-5169
800 Phillips Road 105/50C
Webster, NY 14580

---

From: "Slein, Judith A" <[email-masked]>
Date: Tue, 7 Sep 1999 10:19:04 -0400

Thanks for bringing the discussion back to earth.

I agree with you that the compromise of saying that servers SHOULD protect
the path of the Request-URI used in locking a resource is a poor one.  It
doesn't respond to the issue that was raised, and it needlessly muddies the
waters for clients, which now don't know whether the path will be protected
or not.

I like your suggestion that we keep the MUST language, but state that it
applies only to write locks.

--Judy

> -----Original Message-----
> From: Greg Stein [mailto:[email-masked]]
> Sent: Friday, September 03, 1999 3:24 AM
> To: [email-masked]
> Subject: Re: Bindings, Locks, and MOVE
> 
> 
> This whole thread (post-Judy's message) seems to be picking out a very
> minor detail of her post. Personally, I find this nit-picking 
> of detail
> counter to the goal of her original post: "test its 
> conclusions with the
> mailing list members."
> 
> For myself (and mod_dav), the first "AGREED" portion makes complete
> sense, and I do agree with it.
> [btw, is *anybody* going to be implementing cross-server MOVE/COPY? is
> it necessary to have that feature in the spec at all? of the 
> umpteen DAV
> servers out there now, I don't know any that do this or plan 
> to do this.
> It would be nice to cut the thing and not worry about it.]
> 
> The second "AGREED" portion does not make a whole lot of sense. The
> commentary states that the position is too strong [because it 
> might not
> make sense with other types of locks]. Are there other locks 
> out there?
> Do people have concrete, useful examples? I haven't heard of anything
> besides a write-lock yet. Regardless, I think it should be enforced in
> the spec that a write-lock MUST have guaranteed protection of the
> Request-URI. Put in some language that says other locks can define the
> MUST/SHOULD nature of protection. Otherwise, leave it in the intuitive
> state: a write lock says that others cannot monkey with your URI.
> 
> Cheers,
> -g
> 
> Edgar Schwarz wrote:
> > 
> > On Thu, 2 Sep 1999, Geoffrey M. Clemm wrote:
> > 
> > >    From: [email-masked]
> > >
> > >    <JS>
> > >    </JS>
> > >    I believe that this is not specific to any particular 
> type of locks.  All
> > >    clients need to insure that they have at the very 
> least a way to unlock
> > >    the the locks they have created.  I assume that to 
> unlock (a resource), we
> > >    have to provide a URI of a (the?) resource locked by 
> that lock... so if
> > >    someone else changes the URI, it's
> > >    very likely that we're not going to be able to figure 
> out what the new
> > >    URI is... and will have to leave the lock around until 
> it times out.
> > >
> > > <gmc> Since the server needs to deal with this in case 
> the client just
> > > neglects to remove the lock, and if having another client 
> MOVE your
> > > locked resource is a rare occurrence (which I believe it is), then
> > > this does not seem to be especially problematical.
> > Would it be possible to say:
> >   If a locked resource is moved the server SHOULD create a indirect
> >   reference resource which should exist for some sensible time.
> > 
> > Yes I know, it's complicating the server :-)
> > I imagine the above happening perhaps when somebody is reorganizing
> > a directory structure and deep in the collections there are some
> > locked resources.
> > So the lock owner at least has a decent chance to find out where his
> > resource has gone to.
> > 
> > Regards, Edgar
> > 
> > --
> > [email-masked] ON/EMS1, 07191/13-3382         
> Niklaus Wirth:
> > Privat kann jeder soviel C programmieren oder Videos 
> ansehen wie er mag.
> > Albert Einstein:  Mach es so einfach wie moeglich, aber 
> nicht einfacher.
> 
> --
> Greg Stein, http://www.lyra.org/
>

---

From: "Yaron Goland (Exchange)" <[email-masked]>
Date: Tue, 7 Sep 1999 17:49:07 -0700

Phew!!! I couldn't believe what I was reading regarding write locks. What
use is a write lock that only sometimes is a write lock? Yikes. I'm glad
that is dead.

However there is still a point in the original post that concerns me. Let's
see if I understand the proposal:

When copying a resource into a tree that is currently locked then the lock
on that tree is lost?

Is that the proposal for how to handle locks at the destination of a copied
resource? That is my reading of the paragraph Judy provided.

		Yaron

> From: Slein, Judith A [mailto:[email-masked]]
> Sent: Tue, September 07, 1999 7:19 AM
> To: 'Greg Stein'; [email-masked]
> Subject: RE: Bindings, Locks, and MOVE
> 
>

---

From: [email-masked]
Date: Wed, 8 Sep 1999 08:53:11 -0400

Copying a resource into a destination collection that is locked requires the
principal to own the lock, and provide its lock token in an If header. The
resouce inherites the lock of its new parent collection, the lock is not removed
from the parent. However, if the resource was locked, then the lock is not
copied. The lock state of the new destination resource is determined by its new
parent collection, not any lock the source resource might have had.

"Yaron Goland (Exchange)" <[email-masked]> on 09/07/99 08:49:07
PM

To:   "'Slein, Judith A'" <[email-masked]>, "'Greg Stein'"
      <[email-masked]>, [email-masked]
cc:

          Yaron

---

From: [email-masked]
Date: Wed, 8 Sep 1999 11:11:50 -0400

The WebDAV spec says that locks are lost on MOVE. So if the source resource is
locked, then the MOVE request must include the lock token, and the lock must be
owned by the requesting principal. Otherwise the delete portion of the move will
fail. Since MOVE is a best effort method, the copy to the destination will work,
even if the source can't be deleted. As is the case with COPY, the lock on the
destination resource is determined by its new parent collection, not by any lock
state it may have had. This could be taken to mean that the new resource is not
the same resource moved to a new location, but a different resource.

"Slein, Judith A" <[email-masked]> on 09/08/99 09:34:03 AM

To:   "'Yaron Goland (Exchange)'" <[email-masked]>,
      [email-masked]
cc:

The intention is that if a resource is copied or moved into a tree that is
locked, the lock on the tree remains in force.

We didn't discuss the case where you are doing a MOVE, and the resource
being moved is locked, and it is being moved into a collection that is
locked.  The lock on the collection will certainly stay in force, but we
need to decide whether the lock on the resource being MOVEd will be lost or
whether the MOVE will fail.  I guess my own opinion is that the MOVE should
fail, since that maintains a consistent position that the state of a MOVEd
resource should be unaffected by the move; if its lock state would have to
be changed, the move should fail.

Judith A. Slein
XR&T/Xerox Architecture Center
[email-masked]
8*222-5169

> From: Yaron Goland (Exchange) [mailto:[email-masked]]
> Sent: Tuesday, September 07, 1999 8:49 PM
> To: 'Slein, Judith A'; 'Greg Stein'; [email-masked]

---

From: "Slein, Judith A" <[email-masked]>
Date: Wed, 8 Sep 1999 11:46:48 -0400

As I noted in the message that started this thread, our proposal contradicts
what RFC 2518 says about preserving locks on a MOVE.  We would like to see
the WebDAV spec changed when it goes to draft status to say that locks are
*not* lost on a MOVE.

Judith A. Slein

> From: [email-masked] [mailto:[email-masked]]
> Sent: Wednesday, September 08, 1999 11:12 AM
> To: [email-masked]

---

From: Ray Patch <[email-masked]>
Date: Wed, 8 Sep 1999 10:15:57 -0700

How do I get removed from this DL?

Thanks,
Ray Patch
[email-masked] <mailto:[email-masked]> 

		-----Original Message-----
		From:	John Stracke [mailto:[email-masked]]
		Sent:	Friday, September 03, 1999 8:00 AM
		To:	[email-masked]
		Subject:	Re: Bindings, Locks, and MOVE

		[email-masked] wrote:

		> Proposed extensions to PROPPATCH:
		>
		> 1. Extend the DAV:set and DAV:remove elements to include
information describing
		> how the client wishes to handle errors. The DTD additions
would be:

		I like this idea; I just have a syntactic quibble:

		> <!ELEMENT mustsucceed (#PCDATA | href+)>
		>
		> If an updatebehavior is not included, it is equivalent to
specifying
		> <mustsucceed>*</mustsucceed>

		It might be better if, rather than using "*", you defined an
<all/> element meaning
		the same thing.  For now, "*" is simple enough; but, if we
add more wildcards
		eventually, then it gets messier; we'd have to add more
possible values, which
		starts getting into defining a separate syntax, with a
separate parser.  Simpler to
		use XML tags and let the existing parser handle it.

		--
	
/============================================================\
		|John Stracke    |http://www.ecal.com|My opinions are my
own.|
		|Chief Scientist
|===========================================|
		|eCal Corp.      |Campbell's has it wrong--it's "Never
|
		[email-masked]|underestimate the power of *chocolate*".
|
	
\============================================================/

---

From: "Yaron Goland (Exchange)" <[email-masked]>
Date: Wed, 8 Sep 1999 13:05:11 -0700

The reason that locks are lost on MOVEs is that the overwhelming majority of
existing systems can not handle moving locks on MOVEs. We could, of course,
have said locks SHOULD NOT be lost on moves. But this sort of language is
exactly the type of language the destroys interoperability. When I write a
client I am going to write it to either demand that locks move properly on
moves in the average case (with exceptions handled as force 10 failures) or
I'm going to write it to assume that locks never work on MOVE and set up my
UI and APIs appropriately.
 their UI and internal code in order to compensate. 

We will be consistent.

We will be uniform.

We will use "MUST."

If you want to change the language to say that locks MUST move then we can
discuss this, although I think preventing the majority of existing systems
in the world from supporting WebDAV is probably a bad idea. If you want to
use the Mandatory mechanism, I think that would be a great idea. But the
requirement absolutely will not be a SHOULD.

		Yaron

P.S. Phew... I haven't had a good rant in a while. Feels good. =)

> Sent: Wednesday, September 08, 1999 8:47 AM
> To: [email-masked]'; [email-masked]

---

From: "Yaron Goland (Exchange)" <[email-masked]>
Date: Wed, 8 Sep 1999 13:05:25 -0700

Music to my ears.

> Sent: Wednesday, September 08, 1999 5:53 AM
> To: [email-masked]

---

From: [email-masked]
Date: Thu, 9 Sep 1999 09:25:54 -0400

Yaron,
I guess I don't see the issue. See comments below.

"Yaron Goland (Exchange)" <[email-masked]> on 09/08/99 08:41:47
PM

To:   Jim Amsden/Raleigh/IBM@IBMUS, [email-masked]
cc:

Sigh... every day, in every way, I wish like hell I had never written that
damn "COPY followed by a DELETE" language.

A server CAN NOT implement a cross server MOVE as a WebDAV COPY method
followed by a WebDAV DELETE method. The reason that this isn't possible is
that the MOVE requires atomic behavior and it requires that the resource at
the destination be the exact same resource (within reason) as at the source.
Therefore, for a cross server MOVE to be possible between two unrelated
servers a new protocol would have to be invented which could guarantee the
WebDAV semantics.
<jra>
A WebDAV MOVE is a best effort operation, so it would seem that this is
consistent with non-atomic operation (which might miss resources that were added
or changed after the move began). DAV4J does the MOVE as an atomic operation
whether its from a client of another server acting as a client, so it wouldn't
have this problem anyway. As far as having the destination be exactly the same
as the source, I don't know what "within reason" means. If it means has the same
GUID, or is effectively a new reference to the same resource in some
server-dependent way, then no, I can't probably do that. DAV4J makes a new
resource at the destination that has the same contents as the source, but not
necessarily the same character encoding, and the same properties if possible.
The only issue is conversion between live and dead properties when the servers
involved support different sets (a potential interoperability problem).

It seems this is at least a useful interpretation of the spec.
</jra>
In the WebDAV charter you will find the following entry in the list of
things not in scope for WebDAV:

*HTTP server to server communication protocols

The reason this line was put in the charter was that in the beginning a lot
of folks wanted to enable server to server communication so it would be
possible to do things like cross-server MOVEs. WebDAV decided to focus
solely on the issue of client/server communication and thus ruled
server/server communication out of scope. If you wish to do cross-server
MOVEs you will need a new protocol because WebDAV can't do it.

          Yaron

P.S. Stop laughing Jeff! =)

> Sent: Wednesday, September 08, 1999 8:12 AM
> To: [email-masked]

---

From: [email-masked]
Date: Thu, 9 Sep 1999 22:57:25 -0400

I'm not sure if it was even an doubted, but I agree with Yaron that we must say
that locks either MUST move as a result of the MOVE or that they MUST NOT move
as a result of a MOVE operation.

------------------------------------------
Phone: 914-784-7569,   [email-masked]

---

From: [email-masked]
Date: Fri, 10 Sep 1999 12:36:50 -0400

Do we think clients should be able to effect a cross server "move" with GET,
PROPFIND/PUT, PROPPATCH/DELETE? Seems like a minimal requirement for authoring
and publishing. If so, then wouldn't we like the server's MOVE to just something
similar in a single method to reduce network traffic and client complexity? Are
we making MOVE way too complicated, full of special cases, etc. I continue to
believe that any method whose semantics require a list of if-then-else's is
missing some underlying fundamental principal, will be difficult to implement,
difficult to test, introduce interoperability problems, and will be hard for
clients to use. Move with locks and references seems to have crossed the line.

John Stracke <[email-masked]> on 09/10/99 11:16:38 AM

To:   [email-masked]
cc:

"Yaron Goland (Exchange)" wrote:

> If you wish to do cross-server

Disturbing thought from the peanut gallery: cross-host MOVE (i.e., between two
URLs with different hostnames) is not necessarily cross-server, because they
could be hosted on the same machine.  So, sometimes, something that looks like
a cross-server MOVE may work.  But usually it won't.  And, in some cases, a
user may find it works for a while and then stops, when his admin splits the
server up.  Or vice versa.  Fun, no? :-)

--
/============================================================\
|John Stracke    |http://www.ecal.com|My opinions are my own.|
|Chief Scientist |===========================================|
|eCal Corp.      |I'm a .sig virus...and, boy, am I tired!   |
[email-masked]|                                           |
\============================================================/

---

From: "Yaron Goland (Exchange)" <[email-masked]>
Date: Fri, 10 Sep 1999 10:51:46 -0700

To quote from section 8.9 of RFC 2518:

   The MOVE operation on a non-collection resource is the logical
   equivalent of a copy (COPY), followed by consistency maintenance
   processing, followed by a delete of the source, where all three
   actions are performed atomically.  

MOVE is not a best effort operation. It is an atomic operation which can
conceptually be broken into several steps. However the user is guaranteed
that all the steps occur or none of them occur. An example may help here:

T0 - User sends in a MOVE from server a to server b
T1 - Server a issues a PUT onto server b
T2 - Server a issues a PROPPATCH onto server b
T3 - Network connection between a & b goes down
T4 - User accesses server a and b and finds both servers contain a copy of
the resource!

There are also a lot of implicit state in a resource that a PUT/PROPPATCH
won't necessarily copy over. For example, I would expect the creation date
at the destination to be the same as at the source.

If you use a PUT/PROPPATCH/DELETE to implement MOVE then you are almost
certainly not compliant with WebDAV. In practice this may not matter. I can
imagine any number of systems where this hack may be useful. But it has no
place in a standard.

		Yaron

> Sent: Thursday, September 09, 1999 6:26 AM
> To: Yaron Goland (Exchange)
> Cc: [email-masked]

---

From: [email-masked]
Date: Fri, 10 Sep 1999 16:21:25 -0400

By best effort, I was refering to section 8.8.3 which states that "... the
server SHOULD try to finish as much of the original copy operation as posible."
In this spirit, failure of the delete and the results in step T4 seem to be
consistent.

"Yaron Goland (Exchange)" <[email-masked]> on 09/10/99 01:51:46
PM

To:   Jim Amsden/Raleigh/IBM@IBMUS
cc:   [email-masked]

          Yaron

---

From: "Yaron Goland (Exchange)" <[email-masked]>
Date: Fri, 10 Sep 1999 14:58:39 -0700

You have taken a statement completely out of context. RFC 2518 is not the
bible and was most certainly not divinely inspired. As such one must read
each statement within the context of the sentence in which it is written,
the paragraph in which it is included and the section in which it is stated.

The section you are quoting from is 8.8.3 which is titled "COPY for
collections" and only applies to the behavior of copy across multiple
resources in a collection.

However the original point you made was regarding the behavior of a single
MOVE method on a single resource. Thus any language in 8.8.3 clearly does
not apply.

In the case of a single MOVE/COPY method on a single resource the result
must be atomic and must be complete success or complete failure where
success/failure is defined by the headers included in the request. There is
no "best effort" about it. Nothing, anywhere in the spec, abrogates this
requirement in the least.

"best effort", as defined in 8.8.3, only applies in the singular case when
one is copying multiple resources in a single copy command as the result of
issuing the copy against a collection. In that singular case it is
permissible for some of the copies to succeed and for others to failure.
However each individual copy must completely succeed or completely fail.

Therefore the language in 8.8.3 explicitly prevents the scenario described
in T4 and hence explains why it is impossible to fully replicate the
COPY/MOVE behavior using the client originated method sequences previously
discussed.

		Yaron

> Sent: Friday, September 10, 1999 1:21 PM
> To: [email-masked]
> > > > > > > >    This discussion began with Yaron's comment 
> that saying
> > > > > > that "it MUST NOT be

---

From: [email-masked]
Date: Wed, 15 Sep 1999 14:09:58 -0400

I'll just respond to take what Judith and Geoff just said and apply it directly
to Kevin's example...

  <kw>
  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.
  <kw>

<jlc>
I think the point of COPY is to create more resources.  So unless I
misunderstand you, the COPY/MOVE to /x/y.html would ba allowed.  In the case of
MOVE... I think you end up with the same number that you started with.  IOW's
both operations would be allowed.

BTW, I think it's important to highlight the fact that as currently defined, the
destination of a COPY/DELETE is implicitly DELETED as the first substep of
carrying out the method.
</jlc>

  <kw>
  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)
  </kw>

<jlc>
Same as above.  I believe you can copy/move to /x/y.html
</jlc>

  <kw>
  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)
  <kw>

<jlc>
I believe that final MOVE/COPY is not allowed against /a/b.html because it's
preceeded by an implicit delete which affects that state of /a/ which is locked.
</jlc>

---

From: "Geoffrey M. Clemm" <[email-masked]>
Date: Thu, 16 Sep 1999 12:24:31 -0400

From: [email-masked]

   <jc/> Geoff, please check me if I'm wrong... but I think kevin is
   talking about COPY/MOVE'ing ***TO** the multiply bound resource, not
   from.  As currently written, the COPY/MOVE does a delete on the
   destination right up front... so the binding to a shared object is
   lost.  A PUT to either URI of the resource doesn't break their ability
   to share the resource.

<gmc>
Ooops!  Jason is completely right.  Sorry about the bandwidth wastage.
So I'd like to retract my earlier posting, and just agree with Kevin
that a COPY that preserves destination bindings is a useful operation
that is currently not provided by the protocol.

As a form of penance, I will propose a solution to this problem:

Add "DAV:merge" as a new potential value of the Overwrite header
when used with the COPY request.

The semantics COPY with Overwrite=DAV:merge is to "merge" the source
resource into the destination resource.  In case of non-collection
resources, this is just the equivalent of a PUT and a PROPPATCH into
the Destination.  In case of collection resources, it means
recursively PUT/PROPPATCH from the members of the source collection
into the corresponding member of the destination collection.
</gmc>

Any takers?

Cheers,
Geoff

   From: Kevin Wiggen <[email-masked]>

   <scenario-summary/>
   /~kwiggen/projectX/spec.html" and /~john/projectX/fgd/dfgdfg/dfgdg/spec.html
   are bindings to the same resource.

   <kw/> However if Kevin tries to simply COPY or MOVE
   /~kwiggen/projectX/spec_mine.html to /~kwiggen/projectX/spec.html, his
   BIND will be deleted, and Kevin and John will no longer be working on
   the same document.  All this and Kevin and John will probably not be
   any the wiser and blame each other for lack of updates :)

   <kw/> I believe this is a major FLAW with MOVE/COPY and it really
   comes out in BIND.  If the purpose is to have the ability for the same
   resource to exist in the namespace hierarchy (as the spec states in
   its introduction), then I would assume that BINDS last through
   MOVE/COPY just as they do through PUT and PROPPATCH.

   <kw/> The overwrite flag does not help in this situation.  If it is false,
   it means do not overwrite as before.  Overwrite to T means "Create me
   my own resource" in this case, and I believe that is not the intended
   behavior of the user.

---

From: [email-masked]
Date: Wed, 22 Sep 1999 22:11:22 -0400

<jra>
This is not the only rational for loosing locks. It is possible that the
resource will be moved from one repository to another in the same WebDAV server,
or from one pyysical drive to another. That is, the actual server implementation
may change depending on the source and/or destination resources and/or the URLs
used to access them. DAV4J supports multiple repository managers in the same
server so clients can access resources from them without being aware of how the
resources are actually stored.

Unfortunately, MOVE is sometimes the same resource in a new location, and
sometimes a new resource. Cross server MOVEs are almost certainly new resources.
Depending on server implementations, MOVE within the same server might be too. I
don't think the semantics of MOVE can depend on whether the resource is actually
copied or not. Note that it is also possible that the supported live properties
may change from location to location in the same server as well as across
servers for the same reasons. If we want to control this behavior, we have to
have two moves, one that copies and one that renames. Then servers can fail the
operations if they can't support them.

Finally, much of the justification for protocol changes is based on "user
expectation". I would submit that the COPY/MOVE/LOCKing semantics are getting so
complicated that most users will not be able to determine if their expectation
is being meant or not. I continue to believe that MOVE and COPY need to be
treated as a server convenience to reduce client/server interaction, and their
semantics should be defined completely in terms of more primitive methods like
GET/PROPFIND and PUT/PROPPATCH with or without DELETE. If this can't be done,
then there might be something wrong with these methods, not COPY and MOVE.
</jra>