Subject: RE: New RFC2518bis draft, COPY / MOVE of live properities

From: "Clemm, Geoff" <[email-masked]>
Date: Fri, 2 Aug 2002 08:42:21 -0400

That warning is fine with me.  There are a variety of ways in 
which the new resource could act differently, and that is one of them.

Cheers,
Geoff
-----Original Message-----
From: Julian Reschke [mailto:[email-masked]]
Sent: Friday, August 02, 2002 3:31 AM
To: Jason Crawford
Cc: Clemm, Geoff; [email-masked]
Subject: RE: New RFC2518bis draft, COPY / MOVE of live properities

"COPY should do the equivalent of a GET/PROPFIND followed by PUT/PROPPATCH."

I think *if* we say something like this we should warn that this may not
produce a new resource that behaves the same under variant handling (because
only one of possible multiple variants would be copied).
-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On
Behalf Of Jason Crawford
Sent: Thursday, August 01, 2002 6:49 PM
To: Jason Crawford
Cc: Clemm, Geoff; [email-masked]
Subject: RE: New RFC2518bis draft, COPY / MOVE of live properities

Unless I hear otherwise, I'm going to mark COPY_LIVE_PROPS as resolved...

Resolved: 8/1/02: COPY should do the equivalent of a GET/PROPFIND followed
by PUT/PROPPATCH. - MOVE should maintain the integrity of the resource in
that all live properties and behaviors should remain live and have the same
semantics at the new location as at the old location. If there is any doubt
"same" is defined according to the resource author's concept of "this
resource".

If you'd like this changed, just speak up. :-)

J.

------------------------------------------
Phone: 914-784-7569

---

From: "Jason Crawford" <[email-masked]>
Date: Fri, 2 Aug 2002 11:22:35 -0400

> which the new resource could act differently, and that is one of them.

Fine with me also. :-)

---

From: "Lisa Dusseault" <[email-masked]>
Date: Mon, 19 Aug 2002 18:23:34 -0400

> Case 1: Both source and destination URLs/resources are controlled by
the
> same "server semantics/process," and thus the source server can do a
> COPY by associating a resource with the destination URL that behaves
> exactly the same as the source resource under all variant forms of
> GET/PROPFIND (modulo locks not being copied and the location being
> different).  In this case MOVE is, in fact, indistinguishable to
WebDAV
> clients from a successful COPY followed by a successful DELETE.
> (Although perhaps delta-V clients might be able to distinguish...)

Not only deltaV clients may be able to distinguish, but ACL clients
could. For example, in Xythos WFS, when a file is copied the server
initializes the ACLs like a new file.  On the other hand when a file is
moved, the server copies the ACLs intact.

Xythos WFS also tracks access logs on files, and when a file is moved we
want to keep the access logs on it, but when it's copied we don't want
to duplicate the access logs, just keep the access logs for the
original.

Overall, the new distinction between MOVE and COPY seems more often
useful than problematic.

Lisa