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

> 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