- From: Clemm, Geoff <gclemm@rational.com>
- Date: Sat, 6 Apr 2002 00:22:14 -0500
- To: "'ietf-dav-versioning@w3.org'" <ietf-dav-versioning@w3.org>
From: Nevermann, Dr., Peter [mailto:Peter.Nevermann@softwareag.com] What happens if the destination header of a COPY or MOVE (with overwrite) identifies a resource with a DAV:checked-in property or a version resource? Are not preconditions like DAV:cannot-modify-version-controlled-content and DAV:cannot-modify-version (see: 3.10) missing in 3.14 and 3.15? These are four different questions: COPY/overwrite to a DAV:checked-in VCR is just like a PUT to a DAV:checked-in VCR. It will succeed if DAV:auto-version is set appropriately, and fail otherwise (see Section 3.14) For a MOVE/overwrite to a DAV:checked-in VCR, the fact that it is a DAV:checked-in VCR is irrelevant ... what matters is whether the collection containing it allows you to remove and add members. If that collection is version-controlled, then section 14.7 applies. COPY/overwrite to a version always fails. This is stated in the definition of a "version resource" in section 1.3: "The content and dead properties of a version never change." I agree that it would have been reasonable to have a DAV:cannot-modify-version precondition on COPY for this case. MOVE/overwrite to a version always fails. This is stated in the definition of a "version resource" in section 1.3: "The server allocates a distinct new URL for each new version, and this URL will never be used to identify any resource other than that version." I agree that it would have been reasonable to have a DAV:cannot-modify-version precondition on MOVE for this case. Cheers, Geoff
Received on Saturday, 6 April 2002 00:22:46 UTC