- From: <bugzilla@soe.ucsc.edu>
- Date: Sat, 7 Jan 2006 14:05:08 -0800
- To: w3c-dist-auth@w3.org
http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=106 julian.reschke@greenbytes.de changed: What |Removed |Added ---------------------------------------------------------------------------- Version|-08 |-10 ------- Additional Comments From julian.reschke@greenbytes.de 2006-01-07 14:05 ------- The new text in <http://greenbytes.de/tech/webdav/draft-ietf-webdav-rfc2518bis-10.html#rfc.section.8.9.4> reads: "8.9.4 COPY and Overwriting Destination Resources If a COPY request has an Overwrite header with a value of "F", and a resource exists at the Destination URL, the server MUST fail the request. When a server executes a COPY request and overwrites a destination resource, the exact behavior MAY depend on many factors, including WebDAV extension capabilities (see particularly [RFC3253]). For example, when an ordinary resource is overwritten, the server could delete the target resource before doing the copy, or could do an in-place overwrite to preserve live properties. When a collection is overwritten, the membership of the destination collection after the successful COPY request MUST be the same membership as the source collection immediately before the COPY. Thus, merging the membership of the source and destination collections together in the destination is not a compliant behavior. In general, if clients require the state of the destination URL to be wiped out prior to a COPY (e.g. to force live properties to be reset), then the client could send a DELETE to the destination before the COPY request to ensure this reset." I think this is good. I would replace the "MAY" in the 1st sentence of the 2dn paragraph by "may", though. ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact.
Received on Saturday, 7 January 2006 22:05:11 UTC