W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > July to September 2002

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

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>
Message-ID: <JIEGINCHMLABHJBIGKBCEEOFFCAA.julian.reschke@gmx.de>

> 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?


> 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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 20:01:26 UTC