Re: New RFC2518bis draft, COPY / MOVE of live properities

On Thursday, August 1, 2002, at 09:49 AM, Jason Crawford wrote:
> Unless I hear otherwise, I'm going to mark COPY_LIVE_PROPS as 
> resolved...

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

Received on Monday, 19 August 2002 17:27:37 UTC