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

From: "Jason Crawford" <[email-masked]>
Date: Thu, 1 Aug 2002 12:49:06 -0400

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: "Julian Reschke" <[email-masked]>
Date: Fri, 2 Aug 2002 09:30:48 +0200

"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

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

  J.

---

From: Dan Brotsky <[email-masked]>
Date: Mon, 19 Aug 2002 14:27:00 -0700

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

Sorry to react so late to this; I've been on sabbatical.

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

I'm not saying I necessarily disagree, but I'm worried by the fact that 
this definition distinguishes between COPY and MOVE in a way that's 
quite different from what many other (well-implemented) specs do.  
Consider the following:

1. Many specs define MOVE as the atomic equivalent of COPY followed by 
DELETE.  Wait a minute, actually 2518 does too!  Wouldn't this 
"clarification" break this?

2. (Separate but related issue; don't think it's on the issue list.)  
There is no reason to *require* COPY to create a *new* resource; in 
fact, that's quite a problem for servers that implement copy-on-write 
semantics.  I believe the key sentences in the current RFC are:

Subsequent alterations to the destination resource will not modify
    the source resource.  Subsequent alterations to the source resource
    will not modify the destination resource.

which of course there are many ways to implement.

3. As others have pointed out, a single GET/PROPFIND followed by a 
single PUT/PROPPATCH is very unlikely to do a good copy.  This is 
exactly why we have a separate method for COPY in the first place.

It seems to me that the best clarification we could provide about both 
COPY and MOVE has to do with servers being able to say whether they own 
the destination resource and thus can guarantee the kinds of "property 
preservation" clients are hoping for.  That is, there seem to me to be 
two key cases:

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

Case 2: The source and destination resources are controlled by the same 
"server semantics/process," and thus neither can do better than GET/PUT 
PROPFIND/PROPPATCH.

I don't think we should spend a lot of time trying to put requirements 
on what to do in Case 2, especially since there's no reason for a client 
to think that doing the COPY is going to produce results that are either 
better or more efficient than just doing the four roundtrips!  Instead I 
think we should try to clarify the requirements on Case 1 and we should 
add a way for servers to either say in advance or say after the fact (or 
both) which kind of COPY will/did happen.

     dan

---

From: "Julian Reschke" <[email-masked]>
Date: Tue, 20 Aug 2002 12:42:32 +0200

> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Dan Brotsky
> Sent: Monday, August 19, 2002 11:27 PM
> To: [email-masked]
> Subject: Re: New RFC2518bis draft, COPY / MOVE of live properities
>
>
>

Yes.

> which of course there are many ways to implement.

Yes, but that's an implementation detail. Even if you implement the copy as
copy-on-write, for the *client* it will be a new resource nevertheless.

> ...