W3C home > Mailing lists > Public > ietf-dav-versioning@w3.org > January to March 2002

RE: Copy/Overwrite (section 1.7)

From: Clemm, Geoff <gclemm@rational.com>
Date: Mon, 18 Mar 2002 12:09:40 -0500
Message-ID: <3906C56A7BD1F54593344C05BD1374B103F8B07C@SUS-MA1IT01>
To: "Ietf-Dav-Versioning@W3. Org" <ietf-dav-versioning@w3.org>
   From: Julian Reschke [mailto:julian.reschke@greenbytes.de]

   given two collections with version controlled members:

   - a with member VCRs m1 and m2
   - b with member VCRs m2 and m3

   What is the expected result for

   COPY a
   Destination-URI: b
   Overwrite: T

   (let's assume no auto-versioning for now)

   Based on RFC2518 only I would expect a collection b with members "m1" and

That is correct.

   However, RFC3253 clarifies that COPY/Overwrite updates (and doesn't

That is only for the case where there is a destination resource
corresponding to a source resource.  In case the destination resource
does not correspond to the source resource, the expected (from 2518)
thing happens, i.e. the destination resource is removed.  So for
example, since there is no "m3" resource in "a", following the
COPY, there is no "m3" resource in "b".

 so I'd expect the following members of "b":

   - m1 (newly created, whether it's versioned or not depends on the
   versioning behaviour of the server)
   - m2 (updated when m2 already was checked out, untouched when checked-in)
b/m2 must be updated to have the content and dead properties of a/m2,
or else the COPY (or at least, that part of the COPY if your COPY does
best effort) MUST fail, and be reported as failing in the COPY response.
   - m3 (unchanged)
No, b/m3 must not be mapped to any resource following the COPY.

Received on Monday, 18 March 2002 12:10:19 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:55:48 UTC