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

I believe this definition will work in enough cases for the
implementor to be able to extrapolate what to do in those
multiple-representation cases (and I'll bet is very close to how
Xythos actually does implement its cross-repository MOVE).

In particular, I believe we have to say something to clarify the
distinction between MOVE and COPY, and that this would be a reasonable
compromise between "fully defines every case" (not achievable) and
"undefined" (pretty much what we have in 2518).  But I'm always open
to replacing it with something better!

Cheers,
Geoff

-----Original Message-----
From: Julian Reschke [mailto:julian.reschke@gmx.de]
Sent: Thursday, July 25, 2002 2:02 PM
To: Clemm, Geoff; w3c-dist-auth@w3c.org
Subject: 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 Clemm, Geoff
> Sent: Thursday, July 25, 2002 7:53 PM
> To: w3c-dist-auth@w3c.org
> Subject: RE: New RFC2518bis draft, COPY / MOVE of live properities
>
>
>
> Yes, good point Jason, these constraints should only
> apply to MOVE, and definitely not to COPY.
>
> For COPY, I would like us to use the rfc-3253 semantics,
> i.e. that a COPY is semantically equivalent to a GET/PROPFIND
> followed by a PUT/PROPPATCH, where the PROPFIND/PROPPATCH
> is for all properties that can be PROPPATCH'ed at the destination.

This won't work (in all cases).

The resource may have multiple representations (depending on request
headers), but a simple sequence of GET/PROPFIND-PUT/PROPPATCH will only copy
one of the representations.

Received on Thursday, 25 July 2002 14:14:59 UTC