- From: Julian Reschke <julian.reschke@gmx.de>
- Date: Tue, 20 Aug 2002 12:42:32 +0200
- To: "Dan Brotsky" <dbrotsky@adobe.com>, <w3c-dist-auth@w3c.org>
> From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Dan Brotsky > Sent: Monday, August 19, 2002 11:27 PM > To: w3c-dist-auth@w3c.org > Subject: 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? Yes. > 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. 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. > ...
Received on Tuesday, 20 August 2002 06:43:04 UTC