- 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