- From: Dan Brotsky <dbrotsky@adobe.com>
- Date: Mon, 19 Aug 2002 14:27:00 -0700
- To: w3c-dist-auth@w3c.org
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