- From: <bugzilla@soe.ucsc.edu>
- Date: Sat, 27 Nov 2004 03:40:18 -0800
- To: w3c-dist-auth@w3.org
http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=28 Summary: MOVE vs live properties Product: WebDAV-RFC 2518-bis Version: -06 Platform: Other URL: http://lists.w3.org/Archives/Public/w3c-dist- auth/2004JulSep/0153.html OS/Version: other Status: NEW Severity: normal Priority: P2 Component: 08. HTTP Methods for Distributed Authoring AssignedTo: joe-bugzilla@cursive.net ReportedBy: julian.reschke@greenbytes.de CC: w3c-dist-auth@w3.org 8.10.1 "Live properties described in this document MUST be moved along with the resource, such that the resource has identically behaving live properties at the destination resource, but not necessarily with the same values. If the live properties will not work the same way at the destination, the server MUST fail the request (the client can perform COPY then DELETE if it wants a MOVE to work that badly). This can mean that the server removes a live property if that's the most appropriate behavior for that live property at the destination." The second sentence implies that the MOVE must fail if the live properties can't be moved as well, while the last sentence says that the server may remove the live properties. Update -05: this now reads: "This can mean that the server reports the live property as "Not Found" if that's the most appropriate behavior for that live property at the destination, as long as the live property is still supported with the same semantics." I'm not sure I understand what that means. The contradiction is still there. "A MOVE can be a rename operation, so it's not appropriate to reset live properties which are set at resource creation. For example, the creationdate property value SHOULD remain the same." So can a MOVE be something else then a rename operation? If yes, how does the second sentence then applies? If it doesn't apply always, and the client won't know, why are we mentioning it? Update -06: this has been reworded again, but I still think it's misleading. MOVE may or may not create a new resource (as RFC2518 explicitly allows COPY/DELETE semantics). When it does, the creationdate will change. When it doesn't, it won't. ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is.
Received on Saturday, 27 November 2004 11:40:18 UTC